Sun Update Connection - Enterprise 1.0 User's Guide

Chapter 8 Inventories

This chapter describes the details of inventories and explains how to control hosts through management of individual components.

The following topics are covered:

Terms

This chapter uses the following terms:

Cost-Effective

Manner in which the dependency resolver decides which solution is optimal for a host; cost effectiveness is measured in number of deployment changes needed by any one solution to fulfill a given request.

dependency resolver (DR)

Set of patented algorithms to describe a solution for a job. Initiated by the agent application when a job is received.

Deploy Mode

Job mode that can change host inventory.

Inventory

(1) List of components installed on a managed host. (2) List of components on the universal server.

Knowledge Base

Sub-system of the Sun Update Connection – Enterprise system dependency server, acts as a proxy server for the universal server, keeping dependency rules for CO deployment on managed hosts.

A local knowledge base is a private, on-site only, collection of NCO listings and their deployment rules as generated by the Local Expansion technology.

Policy

Set of confirmation rules for the implementation of the dependency resolver and level of automation of dependency handling.

Simulate Mode

Job mode that produces a test of what would have happened if the job had been in deploy mode.

Understanding Inventories

Sun Update Connection – Enterprise provides access to the inventory of certified components (COs) in the universal server. Each supported distribution has its own knowledge base inventory.

You also have access to the inventory of every managed host, both COs and Non-Certified Components (NCOs). The agent on a host scans the machine and brings you an inventory of all installed components.

You can view the inventory of a managed host within the inventory of the universal server, quickly seeing what can be upgraded, installed, replaced, or uninstalled.

The inventory is displayed in the Components list layout. The levels are:

Category – software components grouped together by function
Package group – Holder of versions of a software
Package – Points to one software component in the knowledge base

An inventory can contain different types of packages. The types are:

Certified Objects (CO) – Under the Software category. COs are components certified by the Certification Lab. In Solaris, Software includes PKGs from the CDs and Sun Freeware.
Non Certified Objects (NCO) – Under the Local RPMs and Local PKGs categories. NCOs are private, proprietary, or third-party components.
Local Files – Under the Local/Pre-actions, Post-actions, Macros, Probes, and Configuration files categories. Local Files are private files, scripts, executables, binaries that you use often on multiple hosts.

Inventory jobs focus on the component level. You select a component from the inventory and then apply a setting to it. The component settings are described in the following tables.

Table 8–1 Inventory Component Settings on Packages (RPM, PKG, NCO, Local File)


Setting	Result if Package Installed	Result if Package Not Installed
Required	Nothing is done.	DR finds solution to install it.
Not Allowed	DR finds solution to uninstall it.	Nothing is done.
Upgrade	If there is a newer version for an installed package, the package is upgraded. If there is more than one version newer than this package, the most cost-effective version is chosen.	Nothing is done.

Table 8–2 Inventory Component Settings on Categories and Package Groups


Setting	Result if Packages Installed	Result if Packages Not Installed
Required	If at least one package is installed, nothing is done.	If no package in category/group is installed, the one that is most cost-effective is installed.
Not Allowed	All packages within category/group are uninstalled.	If no package in category/group is installed, nothing is done.
Upgrade	All installed packages within category/group are upgraded if newer versions exist.	Nothing is done.

For example, you want to install the cURL utility on your FTP servers. You select the FTP group in the Hosts list. In the Components list, you select curl and apply the Required setting to it. You right-click the action and choose Run on Selected Hosts. The job installs curl on the FTP hosts that do not have it yet. It also makes sure that a list of dependent components is installed.

You can see the list of dependencies. Open the Inventory window, right-click the curl version you want to install and choose Details. The Dependencies tab of the Component Information window lists the components that are required by curl.

Viewing Inventories

To View the Inventory of the universal server

Each agent discovers the installed inventory on its managed host and sends it to the dependency manager (DM), which updates the console. This procedure describes the Inventory panel of the console’s main window.

From the View menu, make sure Inventory is selected.

From the drop-down list on the tool bar, select a distribution-architecture.

The Components list shows the components of the selected distribution.

Make sure no host is selected in the Hosts list, and that the Show Installed Components button is deselected.

The Components list shows all components in the knowledge base of the selected distribution.

To see more information about a selected component, do one of the following:
- From the tool bar, click the Details button.
- Right-click the selection and choose Details.
- From the Components menu, choose Details.
The Component Information window opens.

To View the Installed Inventory of Selected Hosts

From the View menu, make sure Inventory is selected.

In the Hosts list, select a managed host, group, or multiple hosts and groups (use Shift or Control to select multiple items).

From the drop-down list in the tool bar, select a distribution-architecture.

The Components list shows the components of the selected distribution.

Choose the type of list you want to view:
- Filtered – Click the Show Installed Components button, if you want to see only those components which are installed on the selected managed hosts.
- Complete – Leave this button deselected, if you want to see all components available for download.

Further Understanding

If you are a user with permissions restricted to specific groups, you see only the hosts of your authorized groups.
Components that are Solaris patches might have a Notifications category in the Rules tab of the Component Information window, which explains if the host must be restarted (and possibly reconfigured) to apply the patch or to complete a successful installation of the patch.
If you have a local, private version of a certified component, it is not listed under Local, but under Software. The name of your component is namebuild-date. You can use the Local Software Review predefined profile to find these components (see Predefined Profiles).
Some distributions contain components with the same name on multiple architectures. In the Inventory display, these components are named namearchitecture
Components are marked with different installation indicators:
- Installed – At least one package of this package group or category is installed on at least one selected managed host
- No Installed mark – Component is not installed on any selected managed host but is available for installation from the universal server
- A ratio – Some, but not all, selected hosts have this component installed
  - The first number shows how many of the selected hosts have this component installed
  - The second number shows how many hosts were selected
    
    For example, you select 105 hosts from different groups. The System Environment component is marked with (Installed 93/105). 93 of the selected hosts have System Environment components installed on them.

Viewing an Inventory with the CLI

The CLI command to view an inventory is for one specific host at a time. It outputs package names only, not categories or package-groups. See List Host Inventory (-lhi) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “The list of hosts is:” 
uce_cli -lah -u “$user” -p “$password” 
echo -n “Copy the name of the host whose inventory you want to see:” 
read hostname 

uce_cli -lhi -h “$hostname” -u “$user” -p “$password”

Saving Inventories

To Save an Inventory

In this procedure, you save an inventory of a host or of a group. Saving an inventory allows you to restore a host to a previous state if needed, or to clone the inventory of a host or a group onto another host (see Restoring Managed Hosts). Sun Update Connection – Enterprise automatically saves inventories before deploying a job on a host. Automatic inventories have this naming convention:

For a host: hostname_Job_jobname_yymmdd_time
For a group: groupname_Job_jobname_yymmdd_time

Use this procedure to save an inventory record with a meaningful name.

Before You Begin

Before saving an inventory, you should run the Check System predefined profile on the host or group. This will ensure that the saved inventory does not have dependency issues. If you will be managing Solaris hosts, you should run the Check Withdrawn Patches profile. This will replace withdrawn Solaris patches with appropriate operating software. See Chapter 7, System Management Profiles.

From the Hosts list, select a single host or a group.

Do one of the following:
- From the tool bar, click the Save Inventory to File button
- Right-click the selected host or group and choose Save Inventory ->To File.
- From the Hosts menu, choose Save Inventory ->To File.
  
  A dialog box opens with the date entered in the text-entry box.

Type a name for this inventory and then click OK.

Example 8–1 Saving a Host Inventory with the CLI

The CLI command to save host inventory saves a record of the inventory of a single host. See Save Host Inventory (-shi) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “The list of hosts is:” 
uce_cli -lah -u “$user” -p “$password” 
echo -n “Copy the name of the host whose inventory you want to save:” 
read hostname 
echo -n “Type a name for the inventory record:” 
read savedInven 

uce_cli -shi -h “$hostname” -s “$savedInven” -u “$user” -p “$password”

Example 8–2 Saving a Group Inventory with the CLI

The CLI command to save group inventory saves a record of the inventory for each host of the group. This does not create a composite record. It creates a separate file for each host.The files are named according to this convention hostname_suffix_mmddyyyytime. You create the suffix, a name or number to identify this as a group inventory save. See Save Group Inventory (-sgi) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “The list of groups is:” 
uce_cli -lg -u “$user” -p “$password” 
echo -n “Copy the name of the group whose hosts inventories you want to save:” 
read groupname 
echo -n “Type a group suffix for the inventory saves:” 
read suffix 

uce_cli -sgi -g “$groupname” -sn “$suffix” -u “$user” -p “$password”

Inventory Jobs

You can manipulate inventory components to create quick jobs. Use Inventory jobs to install, uninstall, upgrade, or downgrade specific components.

Although Inventory jobs are quickly created and deployed, more control and features are available with Complex jobs, which options offer more efficient environment management. For more details, see Chapter 11, Complex Jobs.

Creating Inventory Jobs

To Change the Inventory of a Host or Group

This procedure explains how to create an inventory job to manage the installed components of hosts.

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.

From the View menu, make sure Inventory is selected.

From the drop-down list on the tool bar, select a distribution-architecture.

The Components list changes to display components of the selected distribution.

In the Hosts list, select groups or hosts.

In the Components list, select a component.

Assign an action to the selected component.

Do one of the following:
- From the tool bar, click the Required, Not Allowed, or Upgrade button.
- Right-click the selected component and choose Required, Not Allowed, or Upgrade.
- From the Components menu, choose Required, Not Allowed, or Upgrade.
  
  See Table 8–1 for more explanations of these options.
  
  The action-component setting appears in the Actions list.

Enter as many component actions as you want.

To make the inventory job applicable to hosts of different distributions:
- To select specific components from different distributions, change the selection of the drop-down list of distributions in the tool bar. Find the relevant components and add the action settings to the Actions list.
- To let Sun Update Connection – Enterprise find components from other distributions that are comparable to the ones you have in the Actions list, click the Multi Distribution button (see To Align Component Settings for Multiple Distributions).

Do one of the following:
- From the tool bar, click the Run Job button.
- Right-click in the Actions list and choose Run on Selected Hosts.
- From the Actions menu, choose Run on Selected Hosts.
The Run Job window opens.

Give the job a name and an optional, free-text description.

Select a mode for the job:
- Deploy – Do the actions on the selected hosts
- Simulate – Simulate the actions to estimate job time and full job actions
  
  (If you have restricted permissions to run simulation only jobs, these options are disabled. The job will be run in simulate mode.)

Click OK.

The Run Job window closes. The job starts.

Comparing Inventories

To Compare Inventories

The Inventory Comparison feature shows the differences of installed components between two hosts. The hosts must be of the same distribution-architecture, both in console and in CLI commands.

Comparing inventories offers the following features:

Check that managed hosts of same functions have same software.
Run a job that replicates the software deployment of one host to another.
Rollback a managed host to a saved inventory.
Compare the inventory of a host with the inventory of a group of hosts. Make a single host like the rest of the hosts in a group.

There are different types of inventories to choose from. The following table describes each type.
- Current Inventory – Installed software as-is
- Automatically Saved Inventory – Before a job, Sun Update Connection – Enterprise automatically saves a record of the inventory of selected hosts
  
  indicated by AU: at the beginning of the inventory name
- Saved Host Inventory – User initiated saved record of the inventory of a selected host
- Saved Group Inventory – User-initiated saved record of the inventory of a group; a composite list of software installed on all hosts of the group

Before You Begin

Before comparing inventories, you should run the Check System profile on the host or group. This will ensure that the source inventory does not have dependency issues. If you will be managing Solaris hosts, you should run the Check Withdrawn Patches profile. This will replace withdrawn Solaris patches with appropriate operating software. See Chapter 7, System Management Profiles.

In addition, if you will be comparing Solaris machines, you should edit the PKG settings (see Host Preferences – PKGs) to ensure that the deployment operates as expected.

Make sure the Inventory panel is open in the main window. From the View menu, choose Inventory.

Do one of the following:
- From the tool bar, click the Compare Inventories button.
- Right-click in the Hosts list and choose Compare Inventories.
- From the Hosts menu, choose Compare Inventories.
The Inventory Comparison window opens.

Click the Host Select button to the right of the Target host field.

The Host Selection window opens.

Select the host you want to change and then click OK.

The Host Selection window closes. The selected host name appears in the Target host field.

From the Inventory drop-down list, select a stored inventory or the current inventory.

If you want to create a job from the comparison, select Current Inventory.

Click the Host Select button to the right of the Source field.

The Host Selection window opens.

Select the managed host you want to use as the source and then click OK.

The Host Selection window closes. The selected host name appears in the Source field.

From the Inventory drop-down list, select a saved inventory.

(If the source host is different from the target host, you can select the current inventory.)

In the Filter section, select the types of components you want to be in the comparison:
- Software packages
- Hardware drivers
- Configuration Files
- whether you want the comparison to ignore differences in Versions of the same packages

Click Compare.

The results of the inventory comparison are displayed.

Under the See section of the Inventory Comparison window, select Tasks to Make Target like Source.

If the results include at least one difference between the selected inventories which can be converted to an action (differences in configuration files cannot be converted), more features are available. See the following procedures.

Example 8–3 Comparing Inventories with the CLI

The compare host inventories CLI command outputs two lists: what is installed in the source inventory and not in the target inventory, and what is in the target inventory and not in the source inventory.

Both hosts must be of the same distribution. Both the source host and the target host may be the same host, but the inventories must be different.

If you do not use the -s or the -ts parameters, the current inventories are used by default. See Compare Hosts and Inventories (-chi) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “What distribution are you working on?” 
uce_cli -ld -u “$user” -p “$password” 
echo -n “Copy the distribution name you want:” 
read distroGroup 
echo “The list of hosts in this distribution is:” 
uce_cli -lgh -g “$distroGroup hosts” -u “$user” -p “$password” 
echo -n “Copy the name of the source host:” 
read sourcehost 
echo -n “Copy the name of the target host:” 
read targethost 

echo “The list of saved inventories is:” 
uce_cli -lss -g “$distroGroup hosts” -u “$user” -p “$password” 
echo -n “Copy the name of the source inventory:” 
read sourceInven 
echo -n “Copy the name of the target inventory:” 
read targetInven 

uce_cli -chi -h “$sourcehost” -s “$sourceInven” -t “$targethost” -ts “$targetInven” \
-u “$user” -p “$password”

Cloning Inventories

To Clone Software Inventory

If the results of a Compare Inventory include differences which can be converted to tasks, and if the target inventory is a Current Inventory of a host, you can make the target inventory like the source inventory. This operation does not dump everything on the target as a traditional clone feature would. It allows for a more secure job. It shows you which components are on the source that are not on the target, and could be installed; and which are on the target which could be uninstalled.

Compare a source inventory to the Current Inventory of a target host.

If the source inventory can be cloned onto the target inventory, the Make Target Like Source button is enabled.

Click Make Target like Source.

The Run Job window opens.

The actions under Deploy source’s inventory on target->Profile Data show the components to be installed, uninstalled, upgraded, or downgraded on the target to make its inventory similar to the source inventory.

You may continue with the job now, if this is the only type of action to be done:
- Comparison is of Linux inventories
- Differences are of software, not Solaris patches
- Tasks are for only install, with no uninstall of Solaris patches
  
  If the tasks displayed in the Run Job window include Maintain target’s patches, see Patch Management in Solaris Comparisons before continuing with this procedure.

Type a new name for the job.

Select Deploy or Simulate.

Click OK.

The job installs, uninstalls, upgrades, and downgrades components on the target managed host to make its inventory consistent with that of the source.

Patch Management in Solaris Comparisons

Solaris patches are installed and handled differently than Linux components. An inventory comparison will result in patch comparisons only if the selected inventories have identical software components.

If patches are compared and differences found:

If the only actions to take on patches are to install them on the target, you may continue the job; return to Step 3.
If there is at least one patch which should be uninstalled from the target, you should understand implicit patch installations before continuing with the job.

For example, patch *-05 is installed on a Solaris machine. It is upgraded to patch *-20. All of the patches between 05 and 20 are implicitly installed. They are not on the machine, but the machine is affected as though they were. If you uninstall 20, you lose those effects and go back to 05; but according to what you have seen, you might believe that 19 should be on the machine.

To handle implicit patch installations, Sun Update Connection – Enterprise will first uninstall the patch that was not in the source and then install a comparable patch seen on the inventory of the source.

You see the following in the Run Job window:
Maintain target’s patches -> Profile Data ->Install patch

Troubleshooting Clone Inventory Jobs

Cannot Create Solaris Patch Job
- Situation – The job cannot be created because there are conflicts in patch management actions.
- Error – Cannot create job due to patch conflicts.
- Explanation – One Solaris patch can affect multiple software. In one job, you could see tasks to both install the patch for one software and uninstall the same patch for another software. This job cannot be done through the Compare Inventory feature.
Job Too Big
- Situation – If the job contains too many actions, the following message is displayed
- Error – The job exceeds the recommended size of 20 tasks. Do you want to continue?
- Explanation – For every action that is sent as part of a job, more actions are added, to automatically handle dependency issues. If a job contains too many actions, there is a larger possibility that the job will fail on timeout.
- Solution – You can click Continue and try to run the job as is. Or, you can break up the job into smaller ones:
  1. Click Cancel and then delete some of the actions from the panel.
  2. Click Make Target like Source again and run the job.
  3. Create a job to run the remaining actions.
  Note –
  You can change the default minimum of 20 actions in the Preferences window (see Console Preferences – Jobs).
No Tasks for Job
- Situation – The job cannot be created because there are no actions, even if the comparison did find some differences.
- Explanation – Some differences in inventory will not be translated into actions.
  
  These are the following:
  - Uninstall Local files
  - Install Local Unrecognized files
  - Change hardware support components
- Solution – Rerun the comparison filter. If such components are the only differences between the two inventories, they are actually already very similar.
  
  If you still want to make the managed hosts duplicates of each other, select the Difference between inventories radio button, take note of the list of differences, and create separate jobs to complete the cloning.
Cannot Locate Software Component
- Situation – The job cannot be created because the components that you selected cannot be located.
- Error – Cannot locate the following components.
  
  Make sure they are added to the Local Components tree.
- Explanation – The components that you selected are known because the SDS added them to the knowledge base. However, the software component itself was not uploaded, or was removed from the local machines. Therefore, there is no available software to be installed.
- Solution – To add the software component to the knowledge base:
  1. Log into the console as an user with full permissions or as admin.
  2. From the Components list, select Local/Local RPMs or Local/Local PKGs and then click Attach.
  3. In the Attach Target File window, browse to the managed host and path where the software component is stored and then click OK.

Restoring Managed Hosts

To Roll Back an Inventory

After you run a job and decide that the changes are not what you need, you can roll back the component inventory of a managed host to a previously saved inventory. Inventories are saved automatically before job changes, and you can save an inventory on demand (see Saving Inventories).

Make sure the Inventory panel is open in the main window by choosing Inventory from the View menu.

Do one of the following:
- From the tool bar, click the Compare Inventories button.
- Right-click in the Hosts list and choose Compare Inventories.
- From the Hosts menu, choose Compare Inventories.
The Inventory Comparison window opens.

Click the Host Select button to the right of the Target host field.

The Host Selection window opens.

Select the host you want to restore and then click OK.

The Host Selection window closes. The selected host name appears in the Target host field.

From the Inventory drop-down list, select Current Inventory.

Click the Host Select button to the right of the Source field.

The Host Selection window opens.

Select the same managed host you want to restore and then click OK.

The Host Selection window closes. The selected host name appears in the Source field.

From the Inventory drop-down list, select the optimal stored inventory of the host or of a group to which the host belongs.

Filter the inventories for the type that you want to restore, or select all the inventory options.

Note –
If the hosts are Solaris machines, you can rollback only Software or only Patches at one time.

Click Compare.

Check the results of the inventory comparison. If the differences between the inventories can be converted to component management tasks, the Make Target like Source button is enabled.

Click Make Target like Source.

The Run Job window opens.

In the Run Job window, select Deploy and then click OK.

The restore job begins.

If you are a user with restricted permissions to run only simulation jobs, you do not have this option.)

Example 8–4 Restoring a Host with the CLI

The CLI command submit compare job can clone the inventory (or part of it) from one host or saved inventory to another host. It can also restore a host to a previously saved inventory. This example shows a restore inventory job. See Submit Compare Job (-scj) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “What distribution are you working on?” 
uce_cli -ld -u “$user” -p “$password” 
echo -n “Copy the distribution name you want:” 
read distroGroup 
echo “The list of hosts in this distribution is:” 
uce_cli -lgh -g “$distroGroup hosts” -u “$user” -p “$password” 
echo -n “Copy the name of the host to restore:” 
read host 

echo “The list of saved inventories is:” 
uce_cli -lss -g “$distroGroup hosts” -u “$user” -p “$password” 
echo -n “Copy the name of the inventory to which $host is be restored:” 
read sourceInven 

uce_cli -scj -h “$host” -s “$sourceInven” -t “$host” -j “Restore $host” -C “Always ask me” \
-dp -u “$user” -p “$password”

Saving Inventory Settings as Profiles

To Save Inventory Settings as a Profile

Inventory jobs allow you to quickly manage hosts based on specific components. You can also manage hosts using Complex Jobs (see Chapter 11, Complex Jobs), which allow for more features in one management task. To do this, you need a profile. In this procedure, you save a inventory action list as a re-usable profile.

Make sure the Inventory panel is open in the main window by choosing Inventory from the View menu.

From the drop-down list on the tool bar, select a distribution-architecture.

The Components list changes to display components of the selected distribution.

In the Components list, select a component.

Assign an action to the selected component.

Do one of the following:
- From the tool bar, click the Required, Not Allowed, or Upgrade button.
- Right-click the selected component and choose Required, Not Allowed, or Upgrade.
- From the Components menu, choose Required, Not Allowed, or Upgrade.
  
  The action-component setting appears in the Actions list.

Enter as many component settings as you want.

To make the inventory job applicable to hosts of different distributions:
- To select specific components from different distributions, change the selection of the drop-down list of distributions in the tool bar. Find the relevant components and add the action settings to the Actions list.
- To let Sun Update Connection – Enterprise find components from other distributions that are comparable to the ones you have in the Actions list, click the Multi Distribution button.
  
  See To Align Component Settings for Multiple Distributions.

Do one of the following:
- From the tool bar, click the Save As Profile button.
- Right-click in the Actions list and choose Save as Profile.
- From the Actions menu, choose Save as Profile.
The Profile Editor window opens.

Type a new name for the profile, and type a free-text description.

Check that the component actions in the bottom panel are what you want. You can change the profile before saving it.

Click OK.

The profile is saved. The Profile Editor closes.

Example 8–5 Saving a Host Inventory as a Profile

This Copy Inventory to Profile CLI command takes a host as a parameter. Everything that is installed on the host is marked as Required in the profile. All remaining components in the knowledge base of the distribution of the selected host that are not installed on that host are marked as Not Allowed in the profile. Use this profile to make an inventory cloning job on multiple hosts.

Note that in the following script example, the existence of a policy is assumed.

Make sure to execute a Check System for dependency issues before you save the inventory as a profile, either in the CLI or in the console. In addition, if the host is a Solaris machine, execute a Check Withdrawn Patches profile. See Convert Inventory to Profile (-cip) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “The list of hosts is:” 
uce_cli -lah -u “$user” -p “$password” 
echo -n “Copy the name of the host you want:” 
read host 
echo “The inventory of this host will be saved as a profile.” 
echo -n “Type a name for this profile:” 
read profileName 

echo “Checking $host for dependency issues....” 
uce_cli -sj -P “Check system” -C “YesToAll” -h “$host” -dp -u “$user” -p “$password” 
# Always run the System Test for Dependency Issues before saving an inventory. 
# YesToAll is a policy that says Yes to all actions on SW and Local. 
uce_cli -cip -h “$host” -P “$profileName” -u “$user” -p “$password”

Example 8–6 Saving a Saved Inventory as a Profile

This Copy Snapshot as Profile CLI command takes the name of a saved inventory (known as a snapshot in the CLI) as a parameter. Everything that was installed on the host when the inventory was saved, is marked as Required in the profile. This profile could be used for a mass clone job.

Make sure to execute a Check System for dependency issues before you save the inventory as a profile, either in the CLI or in the console. In addition, if the host is a Solaris machine, execute the Check Withdrawn Patches profile. See Convert Snapshot to Profile (-csp) Command.

#! /bin/bash

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 

echo “The list of hosts is:” 
uce_cli -lah -u “$user” -p “$password” 
echo -n “Copy the name of the host you want:” 
read host 

echo “The saved inventories of this host are:” 
uce_cli -lss -h “$host” -u “$user” -p “$password” 
echo -n “Copy the saved inventory that you want to save as a profile” 
read inven 
echo -n “Type a name for this profile:” 
read profileName

echo “Checking $host for dependency issues....” 
uce_cli -sj -P “Check system” -C “YesToAll” -h “$host” -dp -u “$user” -p “$password” 
# Always run the System Test for Dependency Issues before saving an inventory. 
# YesToAll is a policy that says Yes to all actions on SW and Local. 
uce_cli -csp -h “$host” -s “$inven” -P “$profileName” -u “$user” -p “$password”

Inventory Jobs with Local Scripts and Files

Efficient system and network administrators often maintain a repository of scripts that they use to run typical host management tasks. They might also keep a repository of configuration files that they have changed for various situations, allowing them to quickly manage peripherals and do other frequent environment modifications.

Sun Update Connection – Enterprise allows you to store your scripts and files in your local Sun Update Connection – Enterprise knowledge base, as explained in Managing Local Files. The following tasks show how you can easily create Inventory jobs to execute your scripts or install your file versions on multiple hosts. Using such techniques, you could manage complex, time-consuming tasks with one-click and be done within minutes: route fifty computers to a new printer, add nodes to a cluster, change the dynamics of on-demand services, and so on.

Executing Scripts on Hosts

To Execute a Local File on Multiple Hosts

In this procedure you will run Probes, Pre-actions, and Post-actions on managed hosts, using Inventory jobs. You could include these files in jobs that include installation components (RPMs, PKGs); this procedure shows the difference between Sun Update Connection – Enterprise install of installations and Sun Update Connection – Enterprise install of executions. The local file you want must already be in the Components list, under Local.

Make sure the Inventory panel is open in the main window by choosing Inventory from the View menu.

From the drop-down list on the tool bar, select a distribution-architecture.

The Components list changes to display components of the selected distribution.

In the Hosts list, select the hosts upon which you want to execute the script.

In the Components list, expand Local and then expand the relevant category: Probes, Pre-actions, or Post-actions.

Select the probe or action that you want.

Do one of the following:
- From the tool bar, click the Required button.
- Right-click the selected file and choose Required.
- From the Components, choose Required.
  
  The action setting appears in the Actions list.

Add as many Probes, Pre-actions, or Post-actions as you want.

To execute the files on hosts of different distributions:
- To select specific files from different distributions, change the selection of the drop-down list of distributions in the tool bar. Find the relevant files and add the action settings to the Actions list.
- To let Sun Update Connection – Enterprise automatically add the same files that you uploaded to multiple distributions, click the Multi Distribution button. See To Align Component Settings for Multiple Distributions.

Do one of the following:
- From the tool bar, click the Run Job button.
- Right-click in the Actions list and choose Run on Selected Hosts.
- From the Actions menu, choose Run on Selected Hosts.
The Run Job window opens.

Type a name and description for the job.

Check the bottom panel of the Run Job window and make sure it will execute the actions or probes you want. Although the action says Install, the actions and probes are not installed, but are executed on the remote hosts.

Select Deploy mode. As this job will execute scripts, a simulation will not do anything on the hosts.

Click OK.

The job begins.

Probes are executed first.

If they succeed, Pre-actions are executed next.

If the Pre-actions succeed, Post-actions are executed.

Distributing Local Files

To Install Configuration Files on Multiple Remote Hosts

In this procedure you will install local Configuration files on managed hosts with an inventory job. The version you want must already be on the Components list, under Local/Configuration files. If the file has a macro sign in its contents, make sure the appropriate macro is also uploaded to the knowledge base. You do not need to add the macros to the inventory job; macros are called and executed automatically by Sun Update Connection – Enterprise.

Make sure the Inventory panel is open in the main window by choosing Inventory from the View menu.

From the drop-down list on the tool bar, select a distribution-architecture.

The Components list changes to display components of the selected distribution.

In the Hosts list, select hosts on which the files will be installed.

In the Components list, under Local/Configuration files select the file version that you want.

Do one of the following:
- From the tool bar, click the Required button.
- Right-click the selected file and choose Required.
- From the Components menu, choose Required.
  
  The action setting appears in the Actions list.

To install the files on hosts of different distributions:
- To select specific files from different distributions, change the selection of the drop-down list of distributions in the tool bar. Find the relevant files and set them to Required.
- To let Sun Update Connection – Enterprise automatically add to the Actions list the same files that you uploaded to multiple distributions, click the Multi Distribution button. See To Align Component Settings for Multiple Distributions.

Do one of the following:
- From the tool bar, click the Run Job button.
- Right-click in the Actions list and choose Run on Selected Hosts.
- From the Actions menu, choose Run on Selected Hosts.
The Run Job window opens.

Type a name and description for the job.

Select Deploy mode.

Click OK.

The job begins.

The files that were uploaded to the knowledge base are installed on the remote hosts in the path names provided by the File Declaration of each Configuration file version.

If a Configuration file has a macro sign, the macro is called after file installation. The macro executes, and its output replaces the macro sign in the Configuration file.

Example 8–7 Distributing Local Files

Your File Declaration is /etc/printcap and the local File is printcap_01. Use this job to install printcap_01 on ten hosts. On the hosts, it installs a file named /etc/printcap that has the contents of printcap_01. The contents of each existing printcap file are overwritten with the contents of printcap_01.