You can deploy, or simulate deployment, of predefined profiles in jobs. When setting up the job, you include a policy. A policy determines how the job handles dependencies. During predefined profiles, all components are considered dependencies, so the policy determines the trends and automation of the deployment of the predefined profile as a whole.
In this procedure you create a policy designed to be used in jobs that deploy predefined profiles.
Log in as any user.
Do one of the following:
From the tool bar, click the Policies button.
From the Tools menu, choose Policies.
The Policies window opens.
Click the New button.
The Policy Editor window opens.
Select a distribution and type a name for the policy.
Set the policy according to the policy recommendations.
See Policy Recommendations for Predefined Profiles.
To set a policy, select an item in the Components list and then select a predefined answer (Ask Me, Yes, No) for the listed Sun Update Connection – Enterprise actions (Install, Uninstall, Upgrade From, Downgrade From, Apply Fix, Ignore File Conflict).
To make this policy applicable to multiple distributions, click the Multi Distro button.
Click OK.
The Policy Editor window closes. The new policy is listed in the Policies window.
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” |