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:
This chapter uses the following terms:
Component that has passed the certification process of the Certification Lab and is available for download and management.
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.
Organizational structure of software in Sun Update Connection – Enterprise, using a hierarchy of logical holders for actual software packages.
(1) List of components installed on a managed host. (2) List of components on the universal server.
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.
Application that generates knowledge for local components unknown to the universal server.
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.
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).
For each supported distribution, there is a component inventory.
Inventories include default categories:
Hardware – Contains local hardware information.
Software – Contains COs, indicated by the certified component icon:
Running Kernel – Lists the active KernelBase. Search under Software for other installable kernel components
Notifications – Lists actions to be done, such as restart, on specific hosts
Local – This chapter deals with the Local category and the components it may contain, indicated by the Local component icon:
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.
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.
An Sun Update Connection – Enterprise command fails with the following error:
Cannot process comand. Reason: another command running. |
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.
Execute the command again, or wait a few minutes before running the command again.
The main window is comprised of the Inventory panel and the Jobs panel. To manage Local Inventory, the Inventory panel must be visible.
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.
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.
Expand the Local category to see the default categories. You cannot edit or delete these categories.
Local RPMs or Local PKGs – Your local software components (NCOs)
Macros – Scripts that pull data from hosts to replace macro signs in local Configuration files
Pre-actions – Executables that do something to a host before the tasks of a job begin
Post-actions – Executables that do something to a host after the tasks of a job finish
Probes – Executables that test a pre-requisite condition of a host, to see whether a job should begin
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.
You customize the Local components list by adding your own categories to the default ones under Local.
In the Components list, under Local, select a default category.
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.
Type a name and description for the new category.
Check distributions to which you want this category to be assigned.
Click Apply.
The status column indicates when the category is uploaded to the knowledge base.
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.
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” |
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.
From the Distro drop-down list, select the distribution-architecture holding the component that you want to change.
In the Components list, select the category that you want to change.
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.
Edit as needed: Name, Description, selected Distributions.
Click Apply.
The status column indicates when the category has been changed for each distribution.
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.
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.
In the Components list, select the category that you want to delete.
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.
Check the distributions from which you want to delete the category.
Click Apply.
The status column indicates when the category has been deleted from each distribution.
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.
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.
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.)
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.
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.
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:
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.
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.
Log in with full permissions or as the admin user.
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.
Select Local/Local RPMs/[category].
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.
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.
Remote upload is limited to 5 Mbytes. Console upload is unlimited. You should upload from the console whenever possible.
If you selected console, follow this procedure. If you selected Managed Host, go to To Upload from a Managed Host.
Click the Select File button of the File Name field.
The Choose RPM window opens.
Browse to and select packages you want to add. Use the Control or Shift keys to make a multiple selection from one directory.
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.
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.
If you selected Managed Host, follow this procedure. Note that this procedure upload only one RPM at a time.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the package.
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.
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 |
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. |
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows the components relevant to your selection.
Select Local/Local RPMs/[category]/package group/<package>.
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.
Check each distribution to which this NCO is applicable.
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.
Remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.
If you selected console, follow this procedure. If you selected Managed Host, go to To Attach an RPM from a Managed Host.
Click the Select File button of the File Name field.
The Choose RPM window opens.
Browse to and select the relevant package.
Click Open.
The Choose RPM window closes, and the path name appears in the File Name field of the Attach Target File window.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the package.
Click Apply.
The Status column indicates when the upload is done. The Local Expansion technology generates deployment rules for the new package.
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:
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.
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.
When you upload Solaris software, it must be in the form of a tarball, not a PKG.
Make sure the software is a directory of files, not a PKG.
Tar the directory: tar -cf name.tar /path/*
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select the Solaris distribution-architecture.
Select Local/Local PKGs/[<category>].
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.
In Upload File From, select Console.
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).
Browse to and select the package you want to add. Use the Control or Shift keys to make a multiple selection from one directory.
Click Open.
The choose RPM window closes, and the path name appears in the File Name List of the Add Software window.
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.
If a software component is a security fix for an earlier version (see To Fix Local Software Missing Dependencies), check the Security Fix option.
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.
Make sure of the following:
You have standard NFS or direct access to the PKGs from the system dependency server machine. The CD is in the CD-ROM of the SDS machine; or the SDS has direct access to Solaris files. This procedure does not support FTP or HTTP.
Directories and files to be uploaded are readable by the nobody user.
If the software is in PKG format, expand the PKGs. Each creates a directory (and possible sub-directories) and places there the files of the package.
Open a web browser and in the URL address field, type:
https://SDS-hostname-or-IP-address:8002/upload.html |
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.
There is no recursive search, so the upload path must be only one level above the software directories.
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.
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.
Install the latest Sun Update Connection – Enterprise CLI.
The script is /usr/local/uce/cli/bin/pkg_loader.sh
Change to the following directory by typing:
cd /usr/local/uce/cli/bin/ |
Type the following command:
-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 ] |
Type a Sun Update Connection – Enterprise user name with full permissions.
Type a password for the Sun Update Connection – Enterprise user.
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.
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.
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.
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.
When you upload Solaris software, it must be in the form of a tar file, not a PKG.
Make sure the software is a directory of files, not a PKG.
Tar the directory:
tar -cf name.tar /path/* |
Copy the tarball to the console machine.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows the components relevant to your selection.
Select Local/Local PKGs/[category]/package group/package.
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.
Check the relevant Solaris architecture-distribution.
In the Upload File From options, select Console.
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).
Browse to and select the relevant package.
Click Open.
The Choose RPM window closes, and the path name appears in the File Name field of the Attach Target File window.
Click Apply.
The Status column indicates when the upload is done. The Local Expansion technology generates deployment rules for the new package.
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:
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows the components relevant to your selection.
Select Local/Local RPMs | Local PKGs/[category]/package group.
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.
Change the description or the list of applicable distributions.
Click Apply.
The Status column displays icons to indicate the success or error.
Click Close.
The Package Group Properties window closes. Wait for the console to be updated.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows the components relevant to your selection.
Select Local/Local RPMs | Local PKGs/[category]/package group/package.
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.
If this package is a fix for a previous package, select Security fix (see To Mark Local Software as a Security Fix).
Change the description or the list of applicable distributions.
Click Apply.
The Status column displays icons to indicate the result of the change.
Click Close.
The Package Group Properties window closes. Wait until the console is updated with the changes; time depends on your local environment configuration.
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.
From the Hosts list, select a host or a host group to specify the distribution type.
From the Components list, expand the Local folder and then expand the Local RPMs folder to see the local RPM categories for this distribution.
Expand the local RPM category that contains the RPM that you want to move.
Select the RPM element to move.
If you select one of the components under the RPM element, the Move option is disabled.
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.
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.
Select the category to which you want to move the RPM.
To create a new category under Local RPMs, see To Add a Category.
Click Apply.
Verify that the RPM was moved correctly.
Click Close to close the window.
In this procedure, you remove NCOs from your Local components list or from specific distributions.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows the components relevant to your selection.
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.
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.
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.
Click Apply.
The Status column displays icons to indicate the result of the delete.
Click Close.
The Delete Local Component window closes. Wait until the console is updated.
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.
In this procedure you mark a local component as being a security fix for an earlier version.
In the Add Software window, select Upload as: Security Fix.
If you are using a console on Windows, use the CLI command.
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 |
If you upload a package and mark it as Security Fix, consider earlier versions:
Maintain a series of Security Fixes by keeping all versions marked as Security Fix. All packages are considered secure.
Edit properties of previous packages by unmarking the earlier versions. Sun Update Connection – Enterprise considers only the latest marked package as secure.
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 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.
Log in with full permissions or as the admin user.
From the Components list, select the component marked with an exclamation point in a red circle.
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.
In the Requires section, missing components are marked with an exclamation point in a red circle.
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.
Add the packages to the local knowledge base.
When all missing dependencies are uploaded, the icon of the local component changes to standard.
Upload of the Attach procedure failed with the following error:
Package-Name mismatch. Use Add button. |
The selected component and the RPM you selected to attach have different names.
Use the Add feature instead of Attach.
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.
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.
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.
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.
Do the following:
Open the Inventory panel (View -> Inventory).
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.
Create and deploy a job to uninstall this component from the listed hosts.
Return to the main window and delete the component.
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 |
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 |
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 |
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:
runs any probes that you put in
unmounts /home
installs Apache
mounts /home
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.
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).
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list select Local/Post-Actions | Pre-Actions/[category].
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.
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.
Type a free-text description.
Check each distribution to which this file should be applied.
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.
Remote upload is limited to 5 Mbytes. Console upload is unlimited. It is recommended that you upload from the console whenever possible.
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.
Click the Select File button of the File Name field. The Choose File window opens.
Browse to and select the relevant file.
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.
Click Apply.
The Status column indicates when the upload is done.
Click Close to close the window, or Reset to add more.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the file.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
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” |
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.
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.
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.
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).
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list select Local/Probes/[category].
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.
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.
Type a free-text description.
Check each distribution to which this file should be applied.
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.
If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Probe from a Managed Host.
Click the Select File button of the File Name field.
The Choose File window opens.
Browse to and select the relevant file.
Click Open.
The Choose File window closes, and the path name appears in the File Name field of the Add Probe window.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the file.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
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” |
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.
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.
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).
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list select Local/Configuration Files/[category].
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.
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.
Type a free-text description.
Check each distribution to which this file should be applied.
Click Apply.
The status column indicates when the file declaration is uploaded to the knowledge base.
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.
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” |
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, select Local/Configuration Files/category/file declaration.
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.
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.
Type a free-text description.
Check each distribution to which this file should be applied. Make sure that the file declaration is on all the selected distributions.
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.
If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Configuration File from a Managed Host.
Click the Select File button of the File Name field.
The Choose File window opens.
Browse to and select the relevant file.
Click Open.
The Choose File window closes, and the path name appears in the File Name field of the Add Configuration File window.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the file.
Click Apply.
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” |
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.
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.
When writing macros:
Make sure that the name of the macro script is the same as the macro sign in the files.
Make sure the macro outputs the appropriate string.
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.
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).
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, select Local/Macros/[category].
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.
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.
Type a free-text description.
Check each distribution to which this file should be applied.
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.
Remote upload is limited to 5Mb; console upload is unlimited. It is recommended that you upload from the console whenever possible.
If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Macro from a Managed Host.
Click the Select File button of the File Name field.
The Choose File window opens.
Browse to and select the relevant file.
Click Open.
The Choose File window closes, and the path name appears in the File Name field of the Add Macro window.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the file.
Click Apply.
The Status column indicates when the upload is done. Click Close to close the window, or Reset to add more.
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” |
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.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, under Local/default category/[user category>]/, select the relevant Post-action, Pre-action, Probe, Macro, Configuration file, or File Declaration.
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.
Change the list of selected active distributions.
Change any of the displayed properties.
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.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, under Local/default category/[user category]/, select the relevant Post-action, Pre-action, Probe, Macro, or Configuration file.
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.
Make any changes to the contents of the knowledge base file.
Check each distribution to which the changes should be applied.
Click Apply.
The Status column indicates when the upload is done.
Click Close to close the window, or Reset to make more changes.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, under Local/default category/[user category]/, select the relevant Post-action, Pre-action, Probe, Macro, or Configuration file.
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.
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.
Remote upload is limited to 5 Mbytes. Console upload is unlimited. It is recommended that you upload from the console whenever possible.
If you selected console, follow this procedure. If you selected Managed Host, go to To Upload a Macro from a Managed Host.
Click the Select File button of the File Name field.
The Choose File window opens.
Browse to and select the relevant file.
Click Open.
The Choose File window closes, and the path name appears in the File Name field of the Attach Target File window.
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.
Click Apply.
The Status column indicates when the upload is done.
Click Close to close the window.
If you selected Managed Host, follow this procedure.
Click the Select Host button of the Host Name field.
The Host Selection window opens.
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.
In the File Name field, type the full path name of the file.
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.
Click Apply.
The Status column indicates when the upload is done.
Click Close to close the window.
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.
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
From the Components list, select the component you want to delete.
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.
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.
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.
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:
The file is installed on the managed host
The managed host is online
Log in with full permissions or as the admin user.
From the drop-down list in the tool bar, select a distribution-architecture.
The Components list shows Local components applied to the selected distribution.
Select a host. You can view files from only one host at a time.
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)
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.
Change the text as needed.
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.