Sun Update Connection - Enterprise 1.0 User's Guide

Chapter 5 Local Inventory

This chapter explains how to set up the Sun Update Connection – Enterprise knowledge base to recognize your local components, both software packages and private files; and how the Local Expansion technology, which generates deployment rules for your local software, is initiated.

Local inventory components are available for use in any job, by any user. Even users with restricted permission can create jobs with local software and local files. However, you will see in this chapter’s procedures that management features of local components are available only to users with full permissions and to the admin user. This is to avoid change conflicts in the Local Inventory.

This chapter covers the following topics:

Terms

This chapter uses the following terms:

Certified Object (CO)

Component that has passed the certification process of the Certification Lab and is available for download and management.

Component

Any logical unit that is, or can be, part of a machine. Such a unit is not only a software component itself, but also any logical construct of the component hierarchy.

Components list

Organizational structure of software in Sun Update Connection – Enterprise, using a hierarchy of logical holders for actual software packages.

Inventory

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

Knowledge Base

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.

Local Expansion technology

Application that generates knowledge for local components unknown to the universal server.

Local Files

Files that you add to the local knowledge base. Categorized as the following:

  • Action – Script or binary that directly causes a change in a host. Defined as a pre-action or a post-action according to its order in a job.

  • Configuration File – Non-action file that can contain user-defined macros.

  • Macro – Script or binary that overwrites a variable with a value, usually taken from a host to localize a file.

  • Probe – Script or binary that runs a test on a host as a job prerequisite.

Local Software (NCO)

Component from a local environment, a third party, or Solaris that has not passed certification and is not permitted to be distributed without a specific license.

Also known as a Non Certified Object (NCO).

Local Inventories – NCOs and Files

For each supported distribution, there is a component inventory.

Inventories include default categories:

Non Certified Object (NCO)

Software packages that are not in the knowledge base of the universal server (such as private, proprietary, and third-party software packages), but are installed on a local machine or for which you have a source, such as a third-party CD.

Local Files

Private scripts, binaries, executables, and configuration files available for environment management.

Your local components, NCOs and Local Files, are added to the knowledge base on your site. They are never pushed outside of your enterprise.

Only users with full permissions or the admin user can set up local inventories. All users can use them in jobs.

Troubleshooting – Local Inventory Management Fails

Description:

An Sun Update Connection – Enterprise command fails with the following error:


Cannot process comand. Reason: another command running.
Cause:

Sun Update Connection – Enterprise is busy handling back-end processes and your new command timed out. This error is most commonly seen while you manage Local Inventories.

Workaround:

Execute the command again, or wait a few minutes before running the command again.

Inventory Panel

The main window is comprised of the Inventory panel and the Jobs panel. To manage Local Inventory, the Inventory panel must be visible.

Figure 5–1 Main Window

This screen capture shows the Main window with the Inventory panel and the Jobs panel.

If the Inventory view is not open when you log into Sun Update Connection – Enterprise, from the View menu, choose Inventory. In the Components list of the Inventory view, find the Local category.

If the Local category is empty, or not visible, check whether Show Installed is selected. If it is, only components installed on selected hosts are shown in the Components list; if none are selected, the Components list shows only COs. Deselect this option to see all Local categories.

Managing Local Categories

In this section, you will learn how to add, edit, and delete categories in the Components list under Local.

Each category can hold package groups and packages, which may be either software or files, depending on the top-level default category under which you create your own categories.

These features are available only to users with full permissions and to the admin user.

Default Local Categories

Expand the Local category to see the default categories. You cannot edit or delete these categories.

User-Defined Local Categories

Under a default category, you create, edit, or delete your own categories. Choose the default category that best describes the software or files that you will be adding to the knowledge base.

Adding Categories

You customize the Local components list by adding your own categories to the default ones under Local.

ProcedureTo Add a Category

  1. In the Components list, under Local, select a default category.

  2. Do one of the following:

    • From the tool bar, click the Add Category button.

    • From the Components menu, choose Local -> Add Category.

    • In the Components list, right-click the selected category and choose Local -> Add Category.

      The Add Category window opens.

    This screen capture shows the Add Category window.
  3. Type a name and description for the new category.

  4. Check distributions to which you want this category to be assigned.

  5. Click Apply.

    The status column indicates when the category is uploaded to the knowledge base.

  6. Click Close.

    The Add Category window closes. You might have to wait until the Components list is updated with the new category; time depends on your local environment configuration.


Example 5–1 Adding a Category with the CLI

The create a new category CLI command puts the category into all distributions (default) if you do not use the -D parameter. To add the category to one specific distribution, use the -D parameter and the name of the distribution. (The -ld command outputs the names of distributions.) See Add Local Category (-alc) Command.


#! /bin/bash

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

echo -n “Type a name for the new category:” 
read newCatName 
echo -n “Enter a desription for the new category:” 
read newCatDesc 
echo “Under which category should this one be added?” 
echo “Valid answers: Local RPMs, Local PKGs, Probes, Pre-actions,” 
echo “Post-actions, Macros, Configuration files,” 
echo “or an existing user category under one of these: /existing_subcategory” 
read parent 

uce_cli -alc -T “$newCatName” -ds “$newCatDesc” -pT “$parent” -u “$user” -p “$password”

Editing Categories

In this procedure, you edit Local categories. You can change the name, description, and list of distribution assignments of any category that you or another user created. You cannot change the default categories.

ProcedureTo Edit a Category

  1. From the Distro drop-down list, select the distribution-architecture holding the component that you want to change.

  2. In the Components list, select the category that you want to change.

  3. Do one of the following:

    • From the tool bar, click the Edit Local Component button.

    • Right-click the selected category and choose Edit.

    • From the Components menu, choose Edit.

      The Category Properties window opens.

    This screen capture shows the Category Properties window.
  4. Edit as needed: Name, Description, selected Distributions.

  5. Click Apply.

    The status column indicates when the category has been changed for each distribution.

  6. Click Close.

    The Category Properties window closes. You might have to wait until the console is updated with the changes. The time depends on your local environment configuration.

Deleting Categories

In this procedure, you delete a user-defined Local categories. Everything inside of the category will be deleted as well. However, if there are many components in the category, the delete function might fail with the another process running error. To ensure this does not occur, delete the contained components before deleting the category.

ProcedureTo Delete a Category

  1. In the Components list, select the category that you want to delete.

  2. Do one of the following:

    • From the tool bar, click the Delete Local Component button.

    • Right-click the selected category and choose Delete.

    • From the Components menu, choose Delete.

      The Delete Local Component window opens.

    This screen capture shows the Delete Local Component window.
  3. Check the distributions from which you want to delete the category.

  4. Click Apply.

    The status column indicates when the category has been deleted from each distribution.

  5. Click Close.

    The Delete Local Component window closes. You might have to wait until the console is updated with the changes. The time depends on your local environment configuration.

Understanding Local Software

In this section, you will learn how to add, edit, and delete local software components that are Non-Certified by the Lab (NCOs). These procedures are available only to users with full permissions or the admin user.

NCO Detection and Rule Generation

If am NCO is installed on a managed host, Sun Update Connection – Enterprise automatically detects it and adds it to your local knowledge base. If the NCO is not yet installed (it is on a CD or other source), you can add it to the knowledge base on demand.

When an NCO is added to the local knowledge base, the Local Expansion technology generates rules for NCO deployment. (Be aware that rules generated on-site are not as rigorous as those created by Sun.)

NCOs in Component Lists

The NCO is placed in the Components list. If it is a new package, it is placed under Local RPMs or Local PKGs. If it is an unknown version of a known package (for example, if your organization creates a proprietary patch for an application), the NCO is placed under Software. You can use the Find feature (see To Find Components) to find it under a Software listing.

NCO Privacy

Your local knowledge base data (the package, its listing, its rules) are never pushed back to the universal server, nor are they overwritten by downloaded updates. The local knowledge base is secured for your private site.

Uploading Linux Software

Though Sun Update Connection – Enterprise should automatically detect NCOs that are already installed on a host in the solution, sometimes you want to manually add your NCOs to your local knowledge base. Procedures for adding RPMs that belong to Linux distributions are slightly different than those for adding Solaris PKGs.

The procedures in this section include the following:

Using Console on Windows

You cannot upload RPMs with a console on Microsoft Windows. Use the Sun Update Connection – Enterprise CLI on a Linux machine to upload RPMs. See Example 5–2.

Adding Undetected Linux Software

In this procedure, you add a local RPM to the knowledge base, when it has not been detected automatically. For example, you would use this procedure for uploading a third-party bundle of components from a CD.

You cannot upload RPMs with a console on Microsoft Windows. Use the Sun Update Connection – Enterprise CLI on a Linux machine to upload RPMs. See Example 5–2.

ProcedureTo Upload a New RPM

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection. The NCOs that you add with this procedure will be added to the inventory of the displayed distribution.

  3. Select Local/Local RPMs/[category].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Software window opens.

    This screen capture shows the Add Software window.
  5. Select a source machine:

    • If the console has access to the RPM, select Console.

    • If a remote managed host has access to the RPM, select Managed Host.


      Note –

      Remote upload is limited to 5 Mbytes. Console upload is unlimited. You should upload from the console whenever possible.


ProcedureTo Upload from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose RPM window opens.

  2. Browse to and select packages you want to add. Use the Control or Shift keys to make a multiple selection from one directory.

  3. Click Open.

    The Choose RPM window closes, and the path names appear in the File Name list of the Add Software window. Add as many packages as you want.

  4. Click Apply.

    The Status column indicates when the upload is done. You might have to wait until the console is updated with the changes. The time depends on your local environment configuration.

ProcedureTo Upload from a Managed Host

If you selected Managed Host, follow this procedure. Note that this procedure upload only one RPM at a time.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the software, and click OK.

    The Host Selection window closes and the host name appears in the Host Name field of the Add Software window.

  3. In the File Name field, type the full path name of the package.

  4. Click Apply.

    The Status column indicates when the upload is done. You might have to wait until the console is updated with the changes; time depends on your local environment configuration.


Example 5–2 To Upload NCOs with the CLI

The Add Software Package command allows you to give a path name of a package for upload. The package should be on the local machine or on a mount point. The Distribution parameter is required in this command (the -ld command outputs a list), and you add the package to a single distribution at a time. See Add Software Package (-asp) Command.


#! /bin/bash

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

echo “The list of active distributions is:” 
uce_cli -ld -u $user -p $password 
echo -n “Type the exact name of the distribution for this software:” 
read distro 
echo -n “Type the source path name of the file:” 
read pathname 
echo -n “Is this software a secured version of a previous one? (y | n)” 
read secure 

if [ “$secure” = “y” ]; then 
   uce_cli -asp -f “$pathname” -secure -D $distro -u “$user” -p “$password” 
else 
  uce_cli -asp -f “$pathname” -D $distro -u “$user” -p “$password” 
fi

Attaching Linux Software to Detected Listings

In this procedure, you learn how to attach a local RPM to an NCO name in the Components list. The name must already be in the Components list.

Table 5–1 Reasons for Performing the Attach Procedure

Environment 

Indicator 

Sometimes a package may be uploaded and automatically attached to the NCO listing, but you want to replace the package with one of your own choosing.

A local component listing that has a package already associated with it, is indicated by the full icon. 

Sometimes the system dependency server may be unable to upload the package itself. Use this procedure to manually attach the correct software with the listing.

A software component listing without an attached software, is indicated by the empty icon. 

Sometimes, after a package was uploaded, the Local Expansion technology may discover that this software has missing local dependencies; its rules require components that are not yet in the knowledge base. Until you fix this issue, the component can not be managed by Sun Update Connection – Enterprise. 

An exclamation point in a red circle, on either a full (has software attached) or an empty (does not have software attached) listing, indicates that there are missing local dependencies. 

Console on Windows

You cannot upload or attach RPMs with a console on Microsoft Windows. Use the Sun Update Connection – Enterprise CLI on a Linux machine to upload RPMs. See Example 5–2.

ProcedureTo Attach an RPM

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection.

  3. Select Local/Local RPMs/[category]/package group/<package>.

  4. Do one of the following:

    • From the tool bar, click the Upload knowledge base File button.

    • Right-click the selected component and choose Local -> Upload.

    • From the Components menu, choose Local -> Upload.

      The Attach Target File window opens.

  5. Check each distribution to which this NCO is applicable.

  6. Select a source machine:

    • If the console has access to the NCO, select Console.

    • If a remote managed host has access to the NCO, select Managed Host.


      Note –

      Remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.


ProcedureTo Attach an RPM from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Attach an RPM from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose RPM window opens.

  2. Browse to and select the relevant package.

  3. Click Open.

    The Choose RPM window closes, and the path name appears in the File Name field of the Attach Target File window.

ProcedureTo Attach an RPM from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the software, and click OK.

    The Host Selection window closes, and the host name appears in the Host Name field of the Attach Target File window.

  3. In the File Name field, type the full path name of the package.

  4. Click Apply.

    The Status column indicates when the upload is done. The Local Expansion technology generates deployment rules for the new package.

Uploading Solaris Software

Solaris software and file formats are not known by Linux. Therefore, the procedures for adding Solaris software to your local knowledge base include creating a tar file of Solaris packages:

Expand the PKG, to create a directory of files; then tar the directory.

Using Sun Update Connection – Enterprise, you will upload the tar file. Sun Update Connection – Enterprise will recognize it as a Solaris software and make the PKG accessible for deployment in jobs.

The procedures in this section include the following:

Using Console on Windows

You cannot upload PKGs with a console on Microsoft Windows. To upload single PKGs, on the SDS machine, use the script created for external upload. See Adding Solaris Software with a Script.

Adding Undetected Solaris Software

In this procedure, you add a Solaris PKG to the knowledge base, when it has not been detected automatically. This procedure is best used for single packages, when you feel more comfortable using the console rather than a command-line.

Before You Begin

When you upload Solaris software, it must be in the form of a tarball, not a PKG.

  1. Make sure the software is a directory of files, not a PKG.

  2. Tar the directory: tar -cf name.tar /path/*

  3. Copy the tarball to the console machine.

    If you are using a console on Microsoft Windows, this procedure is not applicable. See Adding Solaris Software with a Script.

ProcedureTo Upload a Single PKG

  1. Log in with full permissions or as the admin user.

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

  3. Select Local/Local PKGs/[<category>].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Software window opens.

  5. In Upload File From, select Console.

  6. Click the Select File button of the File Name field.

    The Choose RPM window opens. This window has the same name for both Linux (RPM) and Solaris (tarball).

  7. Browse to and select the package you want to add. Use the Control or Shift keys to make a multiple selection from one directory.

  8. Click Open.

    The choose RPM window closes, and the path name appears in the File Name List of the Add Software window.

  9. Click Apply.

    The Status column indicates when the upload is done. You might have to wait until the console is updated with the changes; time depends on your local environment configuration.

  10. If a software component is a security fix for an earlier version (see To Fix Local Software Missing Dependencies), check the Security Fix option.

Adding Multiple Solaris Packages

In this procedure, you add a large amount of Solaris software to your local knowledge base. Use this procedure for upload of Solaris software CDs. This procedure does not use the console; it uses a web application created specifically to make Sun Update Connection – Enterprise support and management of Solaris more efficient. Notice that this procedure is also found in the Administrator’s Guide; it must be done after installation of the Sun Update Connection – Enterprise Agent on a Solaris machine, to enable the system dependency server to recognize Solaris software.

Before You Begin

Make sure of the following:

ProcedureTo Upload Solaris CDs

  1. Open a web browser and in the URL address field, type:


    https://SDS-hostname-or-IP-address:8002/upload.html
  2. In the Package path text box, type the full path to the directory that contains the Solaris software.

    For example, if you specify the /tmp/tmpdsol directory, it should contain all the subdirectories and contents copied from the Products directory on the CD ISO image.


    Note –

    There is no recursive search, so the upload path must be only one level above the software directories.


  3. Click Upload.

    The packages are added to the Solaris knowledge base of the Sun Update Connection – Enterprise system dependency server. The browser window shows the automated actions: reading packages, adding packages, and searching for missing packages.

Adding Solaris Software with a Script

In this procedure, you will use a script from the Sun Update Connection – Enterprise CLI application to upload Solaris software. Use this procedure if you are unfamiliar with Solaris commands and having trouble unpacking the PKGs or tarring the directories.

Before You Begin

Install the latest Sun Update Connection – Enterprise CLI.

The script is /usr/local/uce/cli/bin/pkg_loader.sh

ProcedureTo Upload Solaris Software With pkg_loader

  1. Change to the following directory by typing:


    cd /usr/local/uce/cli/bin/
    
  2. Type the following command:


    Note –

    -p is required and its value is the path of the packages to be uploaded.

    -r is optional and provides a recursive search through the given path.

    -d is optional and provides debugging information.



    ./pkg_loader.sh -p path [ -r ] [ -d ]
  3. Type a Sun Update Connection – Enterprise user name with full permissions.

  4. Type a password for the Sun Update Connection – Enterprise user.

  5. For the channel, type the number of the distribution-architecture, according to the displayed list of Available Channels, to which the packages you want to upload belong.

  6. At the prompt Would you like all found components to be added under specific category?, type y to put the packages in a user-defined category, and then at the Category name prompt, type the name of the category.

    If the category does not yet exist in the Sun Update Connection – Enterprise components list, it will be created. If you type n, the packages are added under a default category in the components list.

    pkg_loader.sh will tar the Solaris package directories. Then it uploads the tarballs to the knowledge base. Sun Update Connection – Enterprise recognizes them as Solaris packages and enables you to deploy them as PKGs.

Attaching Solaris Software to Detected Listings

In this procedure, you learn how to attach a Solaris software to a name in the Components list under Local/Local PKGs. The name must already be in the Components list. Use this procedure to: replace a package with another one; manually upload a package; fix missing dependencies. See Table 5–1 for more explanations of when to use an attach procedure.

Console on Windows

If you are using a console on Microsoft Windows, this procedure is not applicable. See Adding Solaris Software with a Script, or delete an existing component (that you want to replace or fill), and use the scirpt to upload the new PKG.

Before You Begin

When you upload Solaris software, it must be in the form of a tar file, not a PKG.

  1. Make sure the software is a directory of files, not a PKG.

  2. Tar the directory:


    tar -cf name.tar /path/*
    
  3. Copy the tarball to the console machine.

ProcedureTo Upload Solaris Software

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection.

  3. Select Local/Local PKGs/[category]/package group/package.

  4. Do one of the following:

    • From the tool bar, click the Upload knowledge base File button.

    • Right-click the selected component and choose Local -> Upload.

    • From the Components menu, choose Local -> Upload.

      The Attach Target File window opens.

  5. Check the relevant Solaris architecture-distribution.

  6. In the Upload File From options, select Console.

  7. Click the Select File button of the File Name field.

    The Choose RPM window opens.

    This window has the same name for both Linux (RPM) and Solaris (tarball).

  8. Browse to and select the relevant package.

  9. Click Open.

    The Choose RPM window closes, and the path name appears in the File Name field of the Attach Target File window.

  10. Click Apply.

    The Status column indicates when the upload is done. The Local Expansion technology generates deployment rules for the new package.

Editing NCO Listings in Components List

After you have added your local components to the Sun Update Connection – Enterprise knowledge base, remaining management procedures are the same, whether for Local RPMs or for Local PKGs, and on a console of any platform.

This section includes the following procedures:

Editing Local Software Package Groups

In this procedure you edit a package group that Sun Update Connection – Enterprise creates when you add a local component to the knowledge base. Use this procedure to apply a package group to additional distributions.

ProcedureTo Edit a Package Group

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection.

  3. Select Local/Local RPMs | Local PKGs/[category]/package group.

  4. Do one of the following:

    • From the tool bar, click the Edit Local Component button.

    • Right-click the selected component and choose Local -> Edit.

    • From the Components menu, choose Local -> Edit.

      The Package Group Properties window opens.

  5. Change the description or the list of applicable distributions.

  6. Click Apply.

    The Status column displays icons to indicate the success or error.

  7. Click Close.

    The Package Group Properties window closes. Wait for the console to be updated.

Editing Local Software Packages

In this procedure you edit the properties of a local package. Use this procedure to add the software to the knowledge bases of more distributions or to mark a package as a security fix for a previous version.

ProcedureTo Edit a Package

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection.

  3. Select Local/Local RPMs | Local PKGs/[category]/package group/package.

  4. Do one of the following:

    • From the tool bar, click the Edit Local Component button.

    • Right-click the selected component and choose Local -> Edit.

    • From the Components menu, choose Local -> Edit.

      The Package Properties window opens.

  5. If this package is a fix for a previous package, select Security fix (see To Mark Local Software as a Security Fix).

  6. Change the description or the list of applicable distributions.

  7. Click Apply.

    The Status column displays icons to indicate the result of the change.

  8. Click Close.

    The Package Group Properties window closes. Wait until the console is updated with the changes; time depends on your local environment configuration.

Moving a Local RPM to Another Package Group

ProcedureTo Move a Local RPM to Another Package Group

Use the Move Package Group window to reorganize the Local RPMs heirarchy for one or more distributions on your system dependency server.

This procedure applies to local RPMs only. You can only move a local RPM to a different category under the Local RPMs category.

  1. From the Hosts list, select a host or a host group to specify the distribution type.

  2. From the Components list, expand the Local folder and then expand the Local RPMs folder to see the local RPM categories for this distribution.

  3. Expand the local RPM category that contains the RPM that you want to move.

  4. Select the RPM element to move.

    If you select one of the components under the RPM element, the Move option is disabled.

  5. Open the Move Package Group window in one of these ways:

    • From the tool bar, click the Move the Selected Local Component button.

    • From the Components menu, choose Local->Move.

    • In the Components list, right-click the selected package and choose Local->Move.

    The Move Package Group window opens.

  6. Specify the distributions you want affected by this change.

    By default, all distributions are affected by the change.

    To select a subset of the distributions, deselect Select All, and then select one or more distributions.

  7. Select the category to which you want to move the RPM.

    To create a new category under Local RPMs, see To Add a Category.

  8. Click Apply.

  9. Verify that the RPM was moved correctly.

  10. Click Close to close the window.

Deleting NCOs

In this procedure, you remove NCOs from your Local components list or from specific distributions.

Before You Begin

Make sure that the NCO is uninstalled from every host before attempting to remove it from the knowledge base. If it is installed on a managed host, it will be automatically detected and added again to your local knowledge base.

ProcedureTo Delete an NCO

  1. Log in with full permissions or as the admin user.

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

    The Components list shows the components relevant to your selection.

  3. Under Local/Local RPMs | Local PKGs/, select the component that you want to delete.

    It may be a user-defined category, a package-group, or a package.

  4. Do one of the following:

    • From the tool bar, click the Delete Local Component button.

    • Right-click the selected component and choose Delete.

    • From the Components menu, choose Delete.

      The Delete Local Component window opens.

  5. Check the distributions from which you want to delete the NCO.

    You may check any or all distributions, even those that did not have the NCO.

  6. Click Apply.

    The Status column displays icons to indicate the result of the delete.

  7. Click Close.

    The Delete Local Component window closes. Wait until the console is updated.

Managing Local Patches and Dependencies

If you create a homegrown patch for either a CO or an NCO, you can upload your component and mark it as a patch.

For example, your organization has a software developed in-house. Some time later, it is discovered that this software has a security issue. The component is patched to fix the security issue and is packed again.

Without Sun Update Connection – Enterprise, you would have to uninstall every instance of the software and install the new one. With Sun Update Connection – Enterprise, everything is handled automatically. You upload the new version to the knowledge base, and in the Add Software window, you mark the upload as a Security Fix.

You run a Security Check (Running Predefined Profiles). Wherever the earlier version was installed, the agents upgrade it to the secured version.

Using Local Security Fixes

In this procedure you mark a local component as being a security fix for an earlier version.

To Mark Local Software as a Security Fix

In the Add Software window, select Upload as: Security Fix.

If you are using a console on Windows, use the CLI command.

Marking as a Fix in CLI

Execute the CLI -asp command with the -secure option. See Add Software Package (-asp) Command.


#! /bin/bash 

echo -n “Enter your user name:” 
read user 
echo -n “Enter your password:” 
read password 
echo “The list of active distributions is:” 
uce_cli -ld -u $user -p $password 
echo -n “Type the exact name of the distribution for this software:” 
read distro 
echo -n “Type the source path name of the file:” 
read pathname 
echo -n “Is this software a secured version of a previous one? (y | n)” 
read secure 
if [ “$secure” = “y” ]; then 
  uce_cli -asp -f “$pathname” -secure -D $distro -u “$user” -p “$password” 
else 
  uce_cli -asp -f “$pathname” -D $distro -u “$user” -p “$password” 
fi

To Handle a Series of Fixes

If you upload a package and mark it as Security Fix, consider earlier versions:

Fixing Local Dependencies

A dependency is a component that is needed by a package for deployment. This dependent component may be another software component, a file, a symbol, and so on. When you upload packages to your local knowledge base, the Local Expansion technology finds the list of dependencies for each package. If the knowledge base is missing dependencies, use the information given by Sun Update Connection – Enterprise to fix them.

NCOs with missing dependencies are marked with an exclamation point in a red circle icon:

Before You Begin

Before you fix missing dependencies of a marked NCO, you should wait at least two minutes from the time that uploaded succeeded. The Local Expansion technology generates rules for local components on a scheduled basis; if you wait, some of the missing dependencies may be handled automatically.

If the NCO is Solaris software, make sure the dependent components to be uploaded are tarballs and have been copied to the console machine.

ProcedureTo Fix Local Software Missing Dependencies

  1. Log in with full permissions or as the admin user.

  2. From the Components list, select the component marked with an exclamation point in a red circle.

  3. Do one of the following:

    • From the tool bar, click the Details button.

    • Right-click the selected component and choose Details.

    • From the Components menu, choose Details.

      The Component Information window opens.

    This screen capture shows the Component Information window.
  4. Open the Dependencies tab.

    In the Requires section, missing components are marked with an exclamation point in a red circle.

  5. From the Internet or private source, find the packages that provide the missing components.

    If the package is a PKG, expand it and tar the directory.

  6. Add the packages to the local knowledge base.

    When all missing dependencies are uploaded, the icon of the local component changes to standard.

Troubleshooting NCOs

Cannot Attach NCO

Description:

Upload of the Attach procedure failed with the following error:


Package-Name mismatch. Use Add button.
Cause:

The selected component and the RPM you selected to attach have different names.

Workaround:

Use the Add feature instead of Attach.

Attached NCO is Marked with an Exclamation Point in a Red Circle

Description:

Upload succeeded, but the package icon is marked with an exclamation point in a red circle.

The rules of this RPM show that dependent components are missing from the local knowledge base.

Workaround:

See To Fix Local Software Missing Dependencies.

Cannot Find NCO

Description:

Upload of the Attach procedure succeeded, but the NCO is not listed under Local RPMs or under Local PKGs.

A CO (under Software, rather than under Local) has the same name, version, and release. Your NCO was added to the package group of the appropriate name under Software.

Workaround:

Run the Local Software Review predefined test (see Predefined Profiles), or use the Find feature to find this software component and to check that the listing is correct for your component.

Cannot Delete an NCO Component

Description:

When you try to delete a selected Local component, you receive the following error message:


Cannot be deleted.

If an NCO is installed on any managed host within the selected distributions, it will be detected and uploaded again. To prevent Sun Update Connection – Enterprise from undoing your delete command, the message reminds you to uninstall the software component from all hosts before deleting it from the knowledge base.

Workaround:

Do the following:

  1. Open the Inventory panel (View -> Inventory).

  2. From the Components list, right-click the software component and choose Component Properties. The Component Information window opens. In the Installed tab, see the list of all managed hosts that have this component installed.

  3. Create and deploy a job to uninstall this component from the listed hosts.

  4. Return to the main window and delete the component.

Managing Local Files

In this section, users with full or admin permissions add, edit, and delete local files.

Local files are scripts, binaries, executables, and files that are private to your enterprise or otherwise unknown to the universal server. The following table explains the categories.

Table 5–2 Local File Categories

Category 

Description 

Use 

Configuration files 

Installs a version of a configuration file 

Install configuration file versions for efficient change management on a customized environment 

Macros 

Outputs a value into a local configuration file 

Install a local configuration file that includes a macro sign and the sign will be replaced with the local value 

Post-action

Performs an action on the host after the job tasks are carried out 

Run action scripts or binaries on hosts to fulfill a post-job requirement 

Pre-action 

Performs an action on the host before the job tasks are carried out 

Run action scripts or binaries on hosts to fulfill a pre-job requirement 

Probe

Runs a test on a host; if returns success, the job tasks are begun 

Run test on hosts to make sure they can do a job before the tasks begin 

Actions

An action is a script, binary, or executable that does something to a host. You categorize your actions as either Pre or Post.

Pre-actions are run before the tasks of a job begins. If a pre-action finishes successfully, it returns a value of zero and the next actions of the job are carried out. If a pre-action returns a non-zero value, the job stops.

Post-actions are run after the other tasks of a job are completed. If a post-action returns a non-zero value, the job ends with a failure status.

For example, you want to install the Apache server. A prerequisite of Apache installation is that /home be unmounted. After it is installed, you want to run other applications that need /home to be mounted.

You create a pre-action unmount_home.sh:

#!/bin/sh -f
# unmount home from remote server
umount server01:/home
            if [ $?==0]; then exit 0; fi

You create a post-action mount_home.sh:

#!/bin/sh -f
# mount home to remote server
mount server01:/home
            if [ $?==0]; then exit 0; fi

You upload these actions. Then you create a profile to install Apache, and add these actions to the job basket. The job does the following:

  1. runs any probes that you put in

  2. unmounts /home

  3. installs Apache

  4. mounts /home

Writing Actions

Make sure the action returns zero (0) on success.

Make the name of the action understandable and descriptive. You can view it in the Jobs panel as a task that either succeeded or failed.

Uploading Actions

In this procedure you upload an existing executable as a Pre-Action or Post-Action to the knowledge base. You can create a category under Pre-Actions or Post-Actions before uploading an action (see Adding Categories).

ProcedureTo Add an Action

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list select Local/Post-Actions | Pre-Actions/[category].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Post Action or the Add Pre Action window opens.

  5. Type a name for the component that will point to your Post-action or Pre-action. This should not be the complete file name. The name should be a name that is easily understood.

  6. Type a free-text description.

  7. Check each distribution to which this file should be applied.

  8. Select a source machine:

    • If the console has access to the file, select Console.

    • If a remote managed host has access to the file, select Managed Host.


      Note –

      Remote upload is limited to 5 Mbytes. Console upload is unlimited. It is recommended that you upload from the console whenever possible.


ProcedureTo Upload a Post-action or a Pre-action from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Post-action or a Pre-action from a Managed Host.

  1. Click the Select File button of the File Name field. The Choose File window opens.

  2. Browse to and select the relevant file.

  3. Click Open.

    The Choose File window closes, and the path name appears in the File Name field of the Add Pre Action or Add Post Action window.

  4. Click Apply.

    The Status column indicates when the upload is done.

  5. Click Close to close the window, or Reset to add more.

ProcedureTo Upload a Post-action or a Pre-action from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the file, and click OK.

    The Host Selection window closes. The host name appears in the Host Name field of the Add Pre Action or Add Post Action window.

  3. In the File Name field, type the full path name of the file.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.


Example 5–3 Uploading a Post-action or a Pre-action with the CLI

The Add Target Local command is the same for Pre-actions, Post-actions, Configuration files, Macros, and Probes. The following syntax is for Pre-actions and Post-actions. The -tP parameter is for Pre-actions; -tS is for Post-actions. The example script adds a Post-action.

In the CLI syntax, a category under the default Local categories is mandatory. See the procedure: Example 5–1 on for the Add Local Category CLI command. See Add Target Local (-atl) Command.


#! /bin/bash

function login { 
  echo -n “Type your user name:” 
  read user 
  echo -n “Type your password:” 
  read password 
} 

function distro { 
  echo “Active distributions are:” 
  uce_cli -ld -u “$user” -p “$password” 
  echo -n “To which distro should this script be added?” 
  read distro 
  echo 
} 

function category { 
  echo “Under which category should this Post-action be added?” 
  echo “Valid answers: any subcategory under Post-actions. See list:” 
  uce_cli -fc -T “Post-actions” -sons -D $distro -u “$user” -p “$password” #> tmp.file 
  sed “s/ROOT\/Local\/Post-actions//” tmp.file 
  echo -n “Start your answer with / :” 
  read parent #rm tmp.file 
  echo 
} 

function setup { 
  echo -n “Type the full path name of the file to upload:” 
  read pathname 
  echo -n “Type a display name for the local file:” 
  read displayName 
} 

login 
distro 
category 
setup 
uce_cli -atl -f “$pathname” -pT “Post-actions$parent” -tS “$displayName” -D $distro -u “$user” -p “$password”

Probes

A probe is a script or binary that tests whether a host fulfills prerequisites for successful completion of a job.

If a probe returns zero, the next tasks of the job are carried out. This ensures that only hosts that currently meet your requirements will run jobs.

If a probe returns 1, the job fails on the host. The probe name is displayed in the Status window as the point of failure. Now you can easily troubleshoot the host.


Example 5–4 Creating a Probe

You create a probe that tests disk space. It returns zero if there is more than the minimum defined in the script.


#!/bin/csh -f
set minimum_space=10000000000
set actual_space=\Qdf -k | awk ’{print $4}’ | tail -1\Q
if ( $actual_space > $minimum_space ) then
  echo $actual_space
  exit 0
endif
exit 1

Upload this probe. Create a job that includes the probe. The tasks are carried out if the available space of the host meets your requirements.


Writing Probes

Make sure the action returns zero (0) on success and one (1) on failure.

Make the name of the probe a boolean statement, to make it as clear as possible; users will view it in the Jobs panel as a task that either succeeded or failed.

Sun Update Connection – Enterprise might run a probe many times during a job. To ensure that operations are efficient, make sure that your probes are as short and fast as possible.

Uploading Probes

In this procedure you add probes to the local knowledge base. You can create a category under Probes before uploading a probe (see Adding Categories).

ProcedureTo Add a Probe

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list select Local/Probes/[category].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Probe window opens.

  5. Type a display name for the component that will point to your probe.

    This should not be the complete file name, but it should be a name that is easily understood.

  6. Type a free-text description.

  7. Check each distribution to which this file should be applied.

  8. Select a source machine:

    • If the console has access to the file, select Console.

    • If a remote managed host has access to the file, select Managed Host.

      Note: remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.

ProcedureTo Upload a Probe from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Probe from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose File window opens.

  2. Browse to and select the relevant file.

  3. Click Open.

    The Choose File window closes, and the path name appears in the File Name field of the Add Probe window.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.

ProcedureTo Upload a Probe from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the software, and click OK.

    The Host Selection window closes. The host name appears in the Host Name field of the Add Probe window.

  3. In the File Name field, type the full path name of the file.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.


Example 5–5 Uploading a Probe with the CLI

The Add Target Local command is the same for Pre-actions, Post-actions, Configuration files, Macros, and Probes. The following syntax is for Probes.

In the CLI syntax, a category under the default Local categories is mandatory. See the procedure Example 5–1 for the Add Local Category CLI command. See Add Target Local (-atl) Command.


#! /bin/bash

function login { 
  echo -n “Type your user name:” 
  read user 
  echo -n “Type your password:” 
  read password 
} 

function distro { 
  echo “Active distributions are:” 
  uce_cli -ld -u “$user” -p “$password” 
  echo -n “To which distro should this script be added?” 
  read distro 
  echo 
} 

function category { 
  echo “Under which category should this Probe added?” 
  echo “Valid answers: any subcategory under Probes. See list:” 
  uce_cli -fc -T “Probes” -sons -D $distro -u “$user” -p “$password” > tmp.file 
  sed “s/ROOT\/Local\/Probes//” tmp.file 
  echo -n “Start your answer with / :” 
  read parent 
  rm tmp.file 
  echo 
} 

function setup { 
  echo -n “Type the full path name of the file to upload:” 
  read pathname 
  echo -n “Type a display name for the local file:” 
  read displayName 
} 

login 
distro 
category 
setup 
uce_cli -atl -f “$pathname” -pT “Probes$parent” -tR “$displayName” -D $distro -u “$user” -p “$password”

Configuration Files

The configuration files of a Linux or Solaris machine determine everything about the environment: the kernel version, the bootloader, the file system, the printers, and so on. All of these files are writable, to a system administrator with permissions and knowledge. Change management in a Linux or Solaris environment usually includes managing files as well as applications.

A local configuration file is any file that you want to store on the knowledge base and distribute to multiple hosts for simultaneous and consistent configurations. Macros (see Macros) are used to localize these files for values relevant to each managed host.


Example 5–6 Updating Configuration Files

Your enterprise with 200 Linux servers is reorganizing; personnel are changing offices and floors. Everyone wants their machine to print to the closest printer. Instead of reconfiguring every printcap file for every host (probably more than once, as the printers and the staff are moved around the complex), you make different versions of this file.

You change printcap slightly for each version:

# /etc/printcap
# Version for RH 9 on 12th floor West
lp:\
    :sd=/var/spool/lpd/lp:\
    :mx#0:\
    :sh:\
    :rm=printer12
    :rp=pr1:

A second version:

# /etc/printcap
# Version for RH WS3 on 10th floor Main
lp:\
    :sd=/var/spool/lpd/lp:\
    :mx#0:\
    :sh:\
    :rm=printer10
    :rp=pr1:

And so on. You create a file declaration for /etc/printcap. Then you upload the versions of the file to the file declaration.

Now you can change the printer configuration of any host within seconds, by selecting the appropriate version and sending it to the hosts that need it. The contents of their old printcap is overwritten with the contents of the version that you selected.


Creating File Declarations

A file declaration holds a path name for installation on remote hosts. When you select a local Configuration File to install on remote hosts, the file is installed in the path and under the name that is determined by the file declaration. Thus, a file declaration can hold multiple versions of the same file; or different files that you want to be installed in the same path name on different hosts. This allows you to simultaneously manage configuration files of a heterogenous environment.

You can create a sub-category under Configuration Files before uploading a Configuration file (see Adding Categories).

ProcedureTo Add a File Declaration

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list select Local/Configuration Files/[category].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Target File Declaration window opens.

  5. In the Target File path name text-field, type the path name where you want the files that will be held under this declaration to be installed on the target hosts. Do not delete the starting back-slash.

  6. Type a free-text description.

  7. Check each distribution to which this file should be applied.

  8. Click Apply.

    The status column indicates when the file declaration is uploaded to the knowledge base.

  9. Click Close.

    The Add Target File Declaration window closes.

    The file declaration is created. A file with a suffix of -Unknown is also created. This is a placeholder and prevents accidental overwrites.


Example 5–7 Adding a File Declaration with the CLI

You may add a file declaration to all distributions (default; do not use the -D parameter) or to a single distribution. If you choose to add a file declaration to a single specified distribution, you can add the Configuration files only to that distribution. Remember that a file declaration, declares the target path name for installation; it does not upload the file itself.

In the CLI syntax, a category under the default Local categories is mandatory. See the procedure: Example 5–1 on for the Add Local Category CLI command. See Add File Declaration (-afd) Command.


#! /bin/bash 

function login { 
  echo -n “Type your user name:” 
  read user 
  echo -n “Type your password:” 
  read password 
} 
function distro { 
  echo “Active distributions are:” 
  uce_cli -ld -u “$user” -p “$password” 
  echo -n “To which distro should this be added?” 
  read distro echo 
} 
function category { 
  echo “Under which category should this File Declaration be added?” 
  echo “Valid answers: any subcategory under Configuration files. See list:” 
  uce_cli -fc -T “Configuration files” -sons -D $distro -u “$user” -p “$password” > tmp.file 
  sed “s/ROOT\/Local\/Configuration files//” tmp.file 
  echo -n “Start your answer with / :” 
  read parent 
  rm tmp.file 
  echo 
} 
function setup { 
  echo -n “Type the full path name for target installation:” 
  read path name 
} 
login 
distro 
category 
setup 
uce_cli -afd -tfp “$pathname” -pT “Configuration files$parent” -D $distro -u “$user” -p “$password”

Uploading Local Configuration Files

The File Declaration declares the full target path name for installation of a file on hosts; it is not the file itself. In this procedure you upload your local versions of Configuration files to the local knowledge base.

ProcedureTo Add a Local Configuration File

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, select Local/Configuration Files/category/file declaration.

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Configuration File window opens.

  5. Type a display version-name for the file.

    This text field is called Version (rather than Name), because the files that you add to a specific file declaration should all be different versions of one file. The Version value will be displayed in the Components list as a suffix to the file name.

    When you install this file on a remote host, it is installed under the full path name of the file declaration.

  6. Type a free-text description.

  7. Check each distribution to which this file should be applied. Make sure that the file declaration is on all the selected distributions.

  8. Select a source machine:

    • If the console has access to the file, select Console.

    • If a remote managed host has access to the file, select Managed Host.

      Note: remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.

ProcedureTo Upload a Configuration File from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Configuration File from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose File window opens.

  2. Browse to and select the relevant file.

  3. Click Open.

    The Choose File window closes, and the path name appears in the File Name field of the Add Configuration File window.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.

ProcedureTo Upload a Configuration File from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the software, and click OK.

    The Host Selection window closes. The host name appears in the Host Name field of the Add Configuration File window.

  3. In the File Name field, type the full path name of the file.

  4. Click Apply.


Example 5–8 Uploading a Configuration File with the CLI

The Add Target Local command is the same for Pre-actions, Post-actions, Configuration files, Macros, and Probes. The following syntax is for Configuration files. This command creates a file declaration automatically. It cannot be used to add a file to an existing declaration.

In the CLI syntax, a category under the default Local categories is mandatory. See Example 5–1 on for the Add Local Category CLI command. See Add Target Local (-atl) Command.


#! /bin/bash 

function login { 
  echo -n “Type your user name:” 
  read user 
  echo -n “Type your password:” 
  read password 
} 
function distro { 
  echo “Active distributions are:” 
  uce_cli -ld -u “$user” -p “$password” 
  echo -n “To which distro should this file be added?” 
  read distro 
  echo } 
function category { 
  echo “Under which category should this file be added?” 
  echo “A file declaration will be created automatically.” 
  echo “Valid answers: any subcategory under Configuration files. See list:” 
  uce_cli -fc -T “Configuration files” -sons -D $distro -u “$user” -p “$password” > tmp.file 
  sed “s/ROOT\/Local\/Configuration files//” tmp.file 
  echo -n “Start your answer with / :” 
  read parent 
  rm tmp.file 
  echo 
} 
function setup { 
  echo -n “Type the full path name of the file to upload: “ 
  read pathname 
  echo -n “Type a version suffix for this version of the file: “ 
  read version 
  echo -n “Type a display name for the local file: “ 
  read displayName 
} 
login 
distro 
category 
setup 
uce_cli -atl -f “$pathname” -pT “Configuration files$parent” -tF “$displayName” -v “$version” \
-D $distro -u “$user” -p “$password”

Macros

A macro is a short script that outputs a single line. This output replaces a macro sign in a local Configuration file.

The macro value is used to customize a Configuration file for its host machine. You create a job that installs a Configuration file on multiple hosts.

This Configuration file has <^AM^>macro<^AM^> in its content, where macro is the name of the macro in the knowledge base.

Each Agent sees the <^AM^> sign and runs the named macro script. The result of the macro run is a line of local data. The value of the macro is entered in place of the macro sign.


Example 5–9 Using Macros

You are reorganizing your network servers. You will be reconfiguring the /etc/hosts file for multiple hosts, perhaps several times. Instead of changing this file for every host every time, you create versions of this file and upload them as Configuration files. In each version, you replace the specific local host name with: <^AM^>hostname<^AM^>

You create a script named hosname.sh:

#!/bin/sh -f
# find local host name
hostname

You upload hostname.sh as a macro called hostname to the local knowledge base. You send the Configuration file as part of a job. Each agent that receives the file, gets the macro sign, downloads the hostname macro, and executes hostname.sh, which replaces <^AM^>hostname<^AM^> with the real local host name on each host.


Writing Macros

When writing macros:

The value of the macro, that is seen in the Configuration file, is the value that was given when the Configuration file was installed and the agent ran the macro from the knowledge base. If you create a macro that changes its value dynamically (or if you edit the content of the macro file), changes do not apply to the remote host files. If you want to change the content of the Configuration files with a new macro, you will have to upload the macro to the knowledge base and re-install the file on the hosts, letting the agents run the new macro.

Uploading Macros

In this procedure you add macros to the local knowledge base. Use this procedure to store local macro scripts, which will later be automatically downloaded and run on multiple hosts. You can create a category under Macros before uploading a macro (see Adding Categories).

ProcedureTo Add a Macro

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, select Local/Macros/[category].

  4. Do one of the following:

    • From the tool bar, click the Add Component button.

    • Right-click the selected category and choose Local -> Add.

    • From the Components menu, choose Local -> Add.

      The Add Macro window opens.

  5. Type a display name for the component that will point to the macro.

    This should not be the complete file name, but it should be a name that is easily understood.

  6. Type a free-text description.

  7. Check each distribution to which this file should be applied.

  8. Select a source machine:

    • If the console has access to the file, select Console.

    • If a remote managed host has access to the file, select Managed Host.


      Note –

      Remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.


ProcedureTo Upload a Macro from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Macro from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose File window opens.

  2. Browse to and select the relevant file.

  3. Click Open.

    The Choose File window closes, and the path name appears in the File Name field of the Add Macro window.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.

ProcedureTo Upload a Macro from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the file, and click OK.

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

  3. In the File Name field, type the full path name of the file.

  4. Click Apply.

    The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.


Example 5–10 Adding a Macro with the CLI

The Add Target Local command is the same for Pre-actions, Post-actions, Configuration files, Macros, and Probes. The following syntax is for Macros.

In the CLI syntax, a category under the default Local categories is mandatory. See Example 5–1 on Example 5–1 for the Add Local Category CLI command. See Add Target Local (-atl) Command.


#! /bin/bash 

function login { 
  echo -n “Type your user name:” 
  read user 
  echo -n “Type your password:” 
  read password 
} 
function distro { 
  echo “Active distributions are:” 
  uce_cli -ld -u “$user” -p “$password” 
  echo -n “To which distro should this script be added?” 
  read distro 
  echo 
} 
function category { 
  echo “Under which category should this Macro be added?” 
  echo “Valid answers: any subcategory under Macros. See list:” 
  uce_cli -fc -T “Macros” -sons -D $distro -u “$user” -p “$password” > tmp.file 
  sed “s/ROOT\/Local\/Macros//” tmp.file 
  echo -n “Start your answer with / :” 
  read parent 
  rm tmp.file 
  echo 
} 
function setup { 
  echo -n “Type the full path name of the file to upload:” 
  read pathname 
  echo -n “Type a display name for the macro:” 
  read displayName 
} 
login 
distro 
category 
setup 
uce_cli -atl -f “$pathname” -pT “Macros$parent” -tM “$displayName” \
-D $distro -u “$user” -p “$password”

Editing Files

After you have added local files to your knowledge base, you may edit them in various ways. You may edit the files on the knowledge base. Any editing you do will affect the file that is stored to the knowledge base, not the original file.

You may edit the files you installed on managed hosts, making the changes directly on the hosts. These files are known as Host files. You may open and save changes to the content of a Host file using Sun Update Connection – Enterprise, but the changes will not be affected in the knowledge base unless you add the file as a knowledge base file.

Editing Local File Properties

In this procedure, you edit the properties of Configuration files, File Declarations, Macros, Post-actions, Pre-actions, and Probes in the knowledge base. If your environment changes, you can use this procedure to change the distributions to which Local Files are applied.

ProcedureTo Edit Local File Properties

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, under Local/default category/[user category>]/, select the relevant Post-action, Pre-action, Probe, Macro, Configuration file, or File Declaration.

  4. Do one of the following:

    • From the tool bar, click the Edit Local Component button.

    • Right-click the selection and choose Local -> Edit.

    • From the Components menu, choose Local -> Edit.

      A Properties window opens.

  5. Change the list of selected active distributions.

  6. Change any of the displayed properties.

  7. Click Apply.

    The changes are uploaded to the knowledge base. If you added more distributions to the selected list, the file itself is uploaded to the knowledge base of the new distributions.

Editing Knowledge Base Files

In this procedure you edit the contents of a Post-action, Pre-action, Probe, Macro, or Configuration file that has already been uploaded to the local knowledge base.

ProcedureTo Edit a Local File

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, under Local/default category/[user category]/, select the relevant Post-action, Pre-action, Probe, Macro, or Configuration file.

  4. Do one of the following:

    • From the tool bar, click the Open knowledge base File button.

    • Right-click the selected component and choose Local -> Open -> Knowledge Base File.

    • From the Components menu, choose Local -> Open -> Knowledge Base File.

      The Knowledge Base File window opens, displaying the contents of the file that is in the knowledge base.

  5. Make any changes to the contents of the knowledge base file.

  6. Check each distribution to which the changes should be applied.

  7. Click Apply.

    The Status column indicates when the upload is done.

  8. Click Close to close the window, or Reset to make more changes.

Replacing Knowledge Base Files

In this procedure, you attach new files to existing listings of Post-actions, Pre-actions, Probes, Macros, and Configuration files. Use this procedure to replace a knowledge base file with a different one from a managed host.

ProcedureTo Replace Knowledge Base Files

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, under Local/default category/[user category]/, select the relevant Post-action, Pre-action, Probe, Macro, or Configuration file.

  4. Do one of the following:

    • From the tool bar, click the Upload KnowledgeBase File button.

    • Right-click the selected file and choose Local -> Upload.

    • From the Components menu, choose Local -> Upload.

      The Attach Target File window opens.

  5. Select a source machine:

    • If the console has access to the file, select Console.

    • If a remote managed host has access to the file, select Managed Host.


      Note –

      Remote upload is limited to 5 Mbytes. Console upload is unlimited. It is recommended that you upload from the console whenever possible.


ProcedureTo Attach a File from the Console Machine

If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Macro from a Managed Host.

  1. Click the Select File button of the File Name field.

    The Choose File window opens.

  2. Browse to and select the relevant file.

  3. Click Open.

    The Choose File window closes, and the path name appears in the File Name field of the Attach Target File window.

  4. Check the distributions to which you want to apply these changes.

    If you check a distribution that does not have the original file, the attach will fail but no damage will be done.

  5. Click Apply.

    The Status column indicates when the upload is done.

  6. Click Close to close the window.

ProcedureTo Attach a File from a Managed Host

If you selected Managed Host, follow this procedure.

  1. Click the Select Host button of the Host Name field.

    The Host Selection window opens.

  2. Select the managed host that has the file, and click OK.

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

  3. In the File Name field, type the full path name of the file.

  4. Check the distributions to which you want to apply these changes.

    If you check a distribution that does not have the original file, the attach will fail but no damage will be done.

  5. Click Apply.

    The Status column indicates when the upload is done.

  6. Click Close to close the window.

Deleting Knowledge Base Files

You can remove anything that you (or another user) added to the Local knowledge base, but before deletion, make sure the component is not already included in a profile or scheduled job. Deleting a local file that will be referenced later will cause the job to fail. In this procedure you delete Post-actions, Pre-actions, Probes, Macros, Configuration files, or File Declarations.

ProcedureTo Delete a Local File

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. From the Components list, select the component you want to delete.

  4. Do one of the following:

    • From the tool bar, click the Delete Local Component button.

    • Right-click the selected component and choose Delete.

    • From the Components menu, choose Delete.

      The Delete Local Component window opens.

  5. Check the distributions from which you want to delete the component.

    You may leave it on the component list of some distributions and delete it from others, or delete it from all.

  6. Click Apply.

    The Status column indicates when the change is done. You might have to wait until the console is updated with the changes; time depends on your local environment configuration.

Opening Host Files

After you have uploaded Local Configuration files to the knowledge base (see Uploading Local Configuration Files), and installed these files on managed hosts (see Distributing Local Files), you can access the files from the hosts. This feature allows you to view, edit, and save-as the content of files on remote hosts, directly on their hosts.

Make sure that:

ProcedureTo Access a File from a Remote Host

  1. Log in with full permissions or as the admin user.

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

    The Components list shows Local components applied to the selected distribution.

  3. Select a host. You can view files from only one host at a time.

  4. From the Components list, select Local/Configuration files/[category]/file declaration.

    The Configuration files on the knowledge base are versions for knowledge base organization. Select the File Declaration to point to the installed file on the remote host.

    Local

    -->Configuration Files

    ---->[category]

    ------>File Declaration (path name of file on host)

    -------->File version (on knowledge base)

  5. Do one of the following:

    • From the tool bar, click the Open Host File button.

    • Right-click the File Declaration and choose Local -> Open -> Open Host File.

    • From the Components menu, choose Local -> Open -> Open Host File.

      The Remote File Editor window opens. Wait until the contents of the remote file are uploaded and displayed.

  6. Change the text as needed.

  7. Do one of the following:

    • Click Cancel, to close the file without changing it.

    • Click Save As, to save a copy of the file, with any changes included. The Save As window opens, from where you can determine the path name of the copy.

    • Click Save, to overwrite the file on the selected remote host.

      The File Editor window closes.