This chapter describes the predefined profiles and how you can deploy them to run system-wide checks and remote restarts.
The following profiles are described:
Check Bugs Fix
Check Security
Check System
Check Withdrawn Patches
Local Software Review
Perform Restart
Perform Restart + Reconfigure
Upgrade All Components
The procedures in this chapter include some advanced features, which will be explained in more detail in later chapters. They are given here to help you get started with execution of predefined profiles even before you are familiar with the details of Sun Update Connection – Enterprise environment management.
This chapter covers the following topics:
This chapter uses the following terms:
When different components need different dependent components and these dependencies cannot exist on the same system together (for example, two different packages need two different versions of the same library), there is a conflict. Sun Update Connection – Enterprise solves such conflicts by finding a version of the dependent components that works for both base components.
Most Linux and Solaris components depend upon the prior installation of existing libraries or other packages to operate in known system configurations. These other components are dependent components, or dependencies.
Set of compliance mappings provided with Sun Update Connection – Enterprise that performs a full-system check and fix, a remote restart, or a remote restart with reconfiguration.
Sun Update Connection – Enterprise provides various profiles already predefined. While you will be creating profiles that define system functions (profiles for web servers, printer servers, and so on), the predefined profiles check complete systems for specific issues or preform restarts on the remote hosts.
The following table briefly describes the 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.
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” |
Jobs that include predefined profiles function differently than other Complex Jobs. The following tasks explain how to set up and handle these jobs.
In this procedure you deploy predefined profiles on managed hosts, with a policy you created in the previous task. You will use the Complex Jobs feature, but this procedure will give the simplest steps. If you are restricted to run simulation jobs only, you can perform this task by using Simulate instead of Deploy.
The Check System predefined profile, especially, should be run before you use a host as a source in a clone job (see Cloning Inventories), to ensure that you are not cloning a host with dependency issues.
Before you begin a job on a Solaris machine, make sure the PKG deployment preferences are appropriate for your local needs. See Host Preferences – PKGs.
Do one of the following:
From the tool bar, click the New Job button.
From the Jobs menu, choose New.
The New Job window opens.
Type a name for the job.
Choose a job mode:
To discover the list of issues, without touching the hosts, check Simulate.
To discover and fix the issues by changing host inventories, check Deploy.
(If you are restricted to run simulation jobs only, the mode options are disabled. The job will be run in simulate mode.)
Type a free-text description.
Open the Task Editor.
Type a name for the first task of the job.
In the Profile drop-down list, select one of the Predefined Profiles.
Click the Hosts button next to the Hosts field.
The Select Hosts window opens.
Select a host or group and click the Add button.
The host or group is added to the Selected Hosts list.
Add as many hosts and groups as you want.
Click OK.
The Hosts window closes. Selected hosts are displayed in the Hosts field of the Tasks tab.
In the Policy drop-down list, select a policy:
Select the Always ask me policy to be asked for confirmation before anything is done. This also allows you to see the full list of actions and to break up a large job if needed.
Select a policy that you created (Yes to Apply Fixes, for example), if you want the job to be done automatically, without your confirmation.
Click the Add Task button.
The task name appears in the tasks list.
If you want to run multiple predefined profiles on the selected hosts, you can create more tasks, each with a different profile. However, it is recommended that you run only one predefined profile the first time, to ensure that the job is not so big that it times out.
Click OK.
The New Job window closes and the job begins. See the Jobs panel in the main window.
The CLI submit job command is used to deploy or simulate a predefined profile. The example given here deploys the Check System profile with the Always ask me policy. See Submit Job (-sj) Command.
#! /bin/bash echo -n “Enter your user name:” read user echo -n “Enter your password:” read password echo -n “Type a name for this job:” read jobName echo “The list of hosts is:” uce_cli -lah -u “$user” -p “$password” echo “The list of groups is:” uce_cli -lg -u “$user” -p “$password” echo “Do you want to do this check on a host or on a group (h | g)?” read hostgroup echo “Copy the name of a host or group to be checked” read selected uce_cli -sj -j “$jobName” -P “Check system” -C “Always ask me” -$hostgroup “$selected” \ -us -dp -u “$user” -p “$password” |
If you selected the Always ask me policy, or if the job found actions to do on dependencies for which you did not set a policy, the job pauses, waiting for you to confirm or deny suggested fixes.
If your user account has Notify when: Job pauses selected, you will receive an email when you need to confirm actions to continue a job. Therefore, you can schedule the predefined profile to run during idle hours and confirm the actions when you receive notification. See To Create a Full-Permission User Account for details on notification, and To Create a Feature-Rich Complex Job for details on scheduling jobs.
Make sure the Jobs panel of the main window is available: from the View menu, choose Jobs.
From the Jobs list (left-hand frame), click a job name with the confirmation icon.
The tasks of the job appear in the Tasks list (middle frame).
Select a task name with the confirmation icon.
Do one of the following:
From the tool bar, click the Confirmation button.
Right-click the selected task and choose Confirmation.
From the Jobs menu, choose Tasks -> Confirm.
The Confirmation window opens and shows suggested actions.
If a confirmation question deals with a component for which you need more information, select the question and click the Details button.
The Component Information window opens.
Take note of relevant data and then click OK to close the Component Information window and return to the Confirmation window.
In the Confirmation window, select Yes to the questions you confirm and No to those you do not want Sun Update Connection – Enterprise to perform on the selected hosts.
If the job was in Deploy mode, the confirmed actions are done on the selected hosts.
If the job was in Simulate mode, the actions and results are calculated, giving you an accurate estimation of the required changes.
In this procedure you run the predefined profiles that restart remote hosts. This procedure starts with the Notifications category in the Inventory panel.
Before you begin a job on a Solaris machine, make sure the PKG deployment preferences are appropriate for your local needs. See Host Preferences – PKGs.
In the main window, make sure the Inventory panel is visible by choosing Inventory from the View menu.
From the Hosts list, select All Hosts and from the Component list, select Notifications or Restart.
If Restart is marked Installed, there are hosts that should be restarted.
To see the names of these hosts, right-click Restart and then click Details.
The Component Information window opens. The Installed tab lists hosts that need a restart. Make a note of these hosts and close the Component Information window.
From the tool bar, click the New Job button.
The New Job window opens.
Type a name and description for the job.
Click the Deploy radio button.
Open the Task Editor.
Type a name for the task of the job.
In the Profile drop-down list, select Perform Restart (or Perform Restart + Reconfigure, for Solaris hosts, and only if the notification mentioned a needed reconfiguration).
Click the Hosts button next to the Hosts field.
The Select Hosts window opens.
Select the hosts you noted from the Notification or Restart list and click Add.
You can add any host that you want to restart, even if it was not marked in Notifications.
Click OK.
The Hosts window closes. Selected hosts are displayed in the Hosts field of the Tasks tab.
Click the Add Task button.
The task name appears in the tasks list.
Click OK.
The New Job window closes and the job begins. The selected hosts are restarted.
Jobs that execute predefined profiles can build up a list of hundreds of actions to do. This procedure explains how to handle such large jobs, by breaking up a large system-wide fix into smaller, faster jobs. Use this procedure if you get a confirmation list with many actions (for example, more than 30 action items). It is applicable only for predefined profiles; in other jobs, if you answer No to a confirmation question, the Dependency Resolver will search for a different solution or fail the job.
In the Confirmation window, select Yes for some actions and No to others.
Click OK to start the job.
Wait for the job to finish, as shown by the Finished icon in the Jobs list, and then select it.
Do one of the following:
From the tool bar, click the Rerun Job button.
Right-click the job name and choose Run.
From the Jobs menu, choose ReRun.
The Rerun window opens.
Give the job a new, meaningful name and description.
Check the Deploy mode.
Click OK.
The predefined profile runs again. In the Confirmation window of the continuation job, you will see the actions to which you answered No in the previous run of this task.
Answer Yes or No to the actions in the list and click OK to run the job.
You can run a predefined profile in as many jobs as you want.