Policies for Predefined Profiles

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.

Creating Policies for Predefined Profiles

In this procedure you create a policy designed to be used in jobs that deploy predefined profiles.

To Create a Policy for Predefined Profiles

1. Log in as any user.

2. Do one of the following:

   • From the tool bar, click the Policies button.

   • From the Tools menu, choose Policies.

   The Policies window opens.

3. Click the New button.

   The Policy Editor window opens.

   

4. Select a distribution and type a name for the policy.

5. 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).

6. To make this policy applicable to multiple distributions, click the Multi Distro button.

   See To Align Component Settings for Multiple Distributions.

7. Click OK.

   The Policy Editor window closes. The new policy is listed in the Policies window.

Policy Recommendations for Predefined Profiles

To automate component handling of jobs that deploy a predefined profile, set Yes policies to Software or to Local for specific deployment actions.

• 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.

Creating a Policy With the CLI

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”