To automate component handling of jobs that deploy a predefined profile, set Yes policies to Software or to Local for specific deployment actions.
Table 7–1 Automating Predefined Profiles|
Profile Name |
Component |
Set YES to: |
|---|---|---|
|
Software and Local |
Apply Fix |
|
|
Software and Local |
Apply Fix |
|
|
Software and Local |
Apply Fix |
|
|
Software and Local |
Upgrade From |
|
|
Software and Local |
Apply Fix, Upgrade From, Downgrade From |
Local Software Review Policy Recommendations
Fully automating the Local Software Review predefined profile without checking what the components are that you are going to replace, is not the best handling method. A better method is to check the local components and set a relevant policy.
When you run the Local Software Review, Sun Update Connection – Enterprise finds the complete list of uncertified components (NCOs) that are listed under Software, rather than under Local RPMs or Local PKGs. This placement is done if you upload an NCO that has the same name as a certified component.
If you are ready to replace local software with certified software (have better deployment rules) from the universal server, set Upgrade From and Downgrade From to Yes.
No Policies for Restart Profiles
Perform Restart and Perform Restart and Reconfigure are different from the profiles. These are not tests. They do not perform actions on individual components, so no policy is relevant.
Ignore File Conflicts Policy
Be wary of setting a Yes policy to the Ignore File Conflicts action. This action needs you to take responsibility for results of forcing an action, regardless of the knowledge base rules. It is recommended that you always leave this action as Ask Me.
Locking Components from Change
If you automate a job with the policy recommended here, you do not have to set the policy to all Software, all Local RPMs, or all Local PKGs. In the components list, set a general policy on categories. Find the package groups or versions that you want to lock from change and give them a No policy. All packages in a category inherit the policy of the parent, except for those with a different policy.
The CLI command to create a policy for a predefined profile is the same as for creating any policy, -aca. The parameter that sets a policy for Apply Fixes is -fix. The following example shows how to set Apply Fixes to Yes for all Software. See Add Policy Attribute (-aca) Command.
#! /bin/bash echo -n “Enter your user name:” read user echo -n “Enter your password:” read password echo -n “Enter the name of a policy or create a new one:” read policyName uce_cli -aca -C “$policyName” -T “Software” -fix yes -u “$user” -p “$password” |