Chapter 4. Red Hat Satellite and Solaris-specific Information

This is a section on using Red Hat Satellite with Solaris systems.

4.1. UNIX Support Guide

This chapter documents the installation procedure for, and identifies differences in, Red Hat Network functionality when used to manage UNIX-based client systems. Red Hat Network offers UNIX support to help customers migrate from UNIX to Linux. Because of the limited scope of this task, the features offered for UNIX client management are not as comprehensive as those available for managing Red Hat Enterprise Linux systems.

Subsequent sections specify supported UNIX variants, Red Hat Network features supported by the UNIX management system, the prerequisites for managing a UNIX system with Red Hat Network, as well as the installation procedure for UNIX clients.

4.1.1. Supported UNIX Variants

The following UNIX variants, versions, and architectures are supported by Red Hat Satellite:

Table 4.1. Supported Solaris Architectures and Versions

Solaris Version	sun4m	sun4d	sun4u	sun4v	sun4us	x86
Solaris 8	yes	no	yes	n/a	no	no
Solaris 9	yes	n/a	yes	n/a	no	yes
Solaris 10	n/a	n/a	yes	yes	no	yes

4.1.2. Prerequisites

These items are needed to obtain UNIX support:

Red Hat Satellite 5.0 or later
A Satellite certificate with Management entitlements
Management entitlements for each UNIX client
Red Hat Network packages for UNIX including python, pyOpenSSL, and the Red Hat Network Client packages
Sunfreeware packages that provide supporting libraries
Note
Some of these packages are available via the Red Hat Satellite. See Section 4.1.7.1, “Downloading and Installing Additional Packages” for the complete list.

4.1.3. Included Features

The following features are included in the UNIX support service level agreement as they exist within Red Hat Network:

The Red Hat Network Service Daemon (rhnsd), which triggers rhn_check according to a configurable interval
The Red Hat Network Configuration Client (rhncfg-client), which executes all configuration actions scheduled from the Satellite
The Red Hat Network Configuration Manager (rhncfg-manager), which allows command line administration of Red Hat Network configuration channels
The rhn_check program, which checks in with the Satellite and performs any actions scheduled from the server
All Management-level functionality, such as system grouping, package profile comparison, and use of the System Set Manager to administer multiple systems at once
A Provisioning feature called Remote Command which enables users to schedule root-level commands on any managed client through the Satellite's website, if the client allows this action

4.1.4. Differences in Functionality

The following Red Hat Network features work differently in a UNIX environment:

The Red Hat Update Agent for UNIX offers a much smaller set of options than its Linux counterpart and relies upon the operating system's native toolset for package installation, rather than rpm - See Section 4.1.8.2.4, “Updating From the Command Line” for the precise list of options.
The Red Hat Network Push application has been similarly modified to upload native UNIX file types, including packages, patches, and patch clusters.
Since Solaris package, patch and patch cluster files are different from RPM files, the channel upload mechanism is somewhat different.There are two applications in the rhnpush package for Solaris:
- The first, solaris2mpm, is an Red Hat Network utility that creates an MPM file for each Solaris package or patch. The neutral format of the MPM file allows the Satellite to understand and manage the uploaded files.
- The second, rhnpush, has been extended so that it can handle MPM as well as RPM files. Otherwise, it operates identically to the Linux version of rhnpush.
The Channels tab of the Red Hat Network website has been augmented to accommodate the storage and installation of native UNIX file types.

4.1.5. Excluded Features

The following Red Hat Network features are not available with the UNIX support system:

All Provisioning-level functionality, such as kickstarting and package rollback, with the exception of configuration file management
All Errata-related options, since the concept of Errata Updates is not understood in UNIX
Source files for packages

Answer files are not supported. Support for such files is planned for a future release.

There is also no support for IPv6 for Solaris systems.

Additionally, relocating RHAT*.pkg files during installation is not supported.

4.1.6. Satellite Server Preparation and Configuration

Configure the Satellite to support UNIX clients before the required files are available for deployment to the client systems. This can be accomplished in one of two ways, depending on whether you have installed your Satellite server:

During the Satellite installation:
Enable UNIX support on the Satellite by checking the "Enable Solaris Support" box on the Red Hat Satellite configuration screen during the installation process.
After the Satellite has been installed:
Enable UNIX support by configuring the Satellite after it has been installed. To do so, select Admin in the top menu bar, then select Satellite Configuration in the left navigation bar. In the screen that follows, check the Enable Solaris Support box.
Click the Update button to confirm the change.
Finally, create a base channel to which your client systems may subscribe. Red Hat Network does not provide UNIX content, satellite-sync cannot be used to create the channel.
To create a Solaris channel, login to the web interface of the Satellite as either a Satellite Administrator or a certificate authority. Navigate to the Channel tab, followed by the Manage Software Channels from the left navigation bar. Click the create new channel link in the upper right of the resulting screen. Provide a name and label for your new channel, and select either SPARC Solaris or i386 Solaris as the architecture, depending on the architecture of the client.

4.1.7. UNIX Client System Preparation

Before your UNIX-based client systems benefit from Red Hat Network, they must be prepared for connection:

Download and install gzip and the required third-party libraries.
Download the Red Hat Network application tarball from the Satellite to the client and install the contents.
Next, deploy the SSL certificates required for a secure connection.
Configure the client applications to connect to the Red Hat Satellite.

Once finished, your systems will be ready to begin receiving Red Hat Network updates. The following sections explain these steps in detail.

4.1.7.1. Downloading and Installing Additional Packages

This section steps you through the process of downloading and installing third-party applications and the Red Hat Network applications from the Satellite onto the UNIX client.

Of primary importance is the Red Hat Update Agent for UNIX (up2date), which provides the link between your client systems and Red Hat Network. The UNIX-specific version of the Red Hat Update Agent is limited in functionality compared to its Linux counterpart but still enables system registration and facilitates package installs and patches. See Section 4.1.8, “UNIX Client Registration and Updates” for a full description of the tool's options.

Note

It may be useful to enter the command bash when first logging into the Solaris client. If the BASH shell is available, it will make the system's behavior as Linux-like as possible.

4.1.7.1.1. Installing Third-Party Packages

Installation of the Red Hat Network applications cannot proceed unless the following utilities and libraries are present:

gzip
libgcc
openssl
zlib

The gzip utility is provided by the SUNW gzip package and may be downloaded from http://www.sunfreeware.com.

On recent versions of Solaris, the necessary libraries are provided by the following natively installed packages:

SUNWgccruntime
SUNWopenssl*
SUNWzlib

For older Solaris versions, the following required packages may be downloaded from http://www.sunfreeware.com:

SMClibgcc or SMCgcc
SMCossl
SMCzlib

To verify if a package is installed on the client, use the pkginfo command. For example, to check for a package that contains "zlib" in the name, run the following command:

# pkginfo | grep zlib

Note

Solaris package archive names differ from the name of the installed package. For example, the package archive libgcc<version>-sol<solaris-version>-sparc-local.gz becomes SMClibgcc after installation

4.1.7.1.2. Configuring the Library Search Path

To allow the Solaris client to use the libraries installed in the previous step, you must add their location to the library search path. To do so, first check the current library search path:

# crle -c /var/ld/ld.config

Make a note of the current Default Library Path. Next, modify the path to also include the components shown below. Note that the -l option resets the value, rather than appending it, so if there already were values set on your system, prepend them to the -l parameter.

On sparc:

 # crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib

On x86:

# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib:/usr/sfw/lib

4.1.7.1.3. Downloading Red Hat Network Client Packages

Download the appropriate tarball of packages from the /var/www/html/pub/ directory of your Satellite. If you are able to use a GUI web browser like Mozilla, navigate to the /pub directory of the Satellite and save the appropriate tarball to your client:

http://your-satellite.example.com/pub/rhn-solaris-bootstrap-<version>-<solaris-arch>-<solaris-version>.tar.gz

If you must download the tarball from the command line, it should be possible to use ftp to transfer the file from the Satellite to the client.

Using gzip, decompress the tarball. You should have the following packages:

RHATpossl
RHATrhnrcfg
RHATrhnrcfga
RHATrhnrcfgc
RHATrhnrcfgm
RHATrhnc
RHATrhnl
RHATrpush
RHATsmart

SMClibgcc and SMCosslg may also be included in the tarball.

4.1.7.1.4. Installing the Red Hat Network Packages

Change to the uncompressed directory and use the UNIX variant's native installation tool to install each package. For example, on Solaris, use the pkgadd command. Answer "yes" to any prompts during package install.

Here is how a typical installation might proceed:

# pkgadd -d RHATpossl-0.6-1.p24.6.pkg all
# pkgadd -d RHATpythn-2.4.1-2.rhn.4.sol9.pkg all
# pkgadd -d RHATrhnl-1.8-7.p23.pkg all
...

Note

Use the -n option for pkgadd to run the command in non-interactive mode. However, this may cause the installation of some packages to fail silently on Solaris 10.

Continue until each package is installed in the Red Hat Network-specific path: /opt/redhat/rhn/solaris/.

4.1.7.1.5. Including Red Hat Network Packages in the PATH

In order to make the Red Hat Network packages available at each login, you may wish to add them to your PATH. To do so, add these commands to your login script:

# PATH=$PATH:/opt/redhat/rhn/solaris/bin
# PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin
# PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin
# export PATH

To enable access to the Red Hat Network client command man pages, add them to your MANPATH. To do so, add the following commands to your login script:

# MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man
# export MANPATH

Alternatively, you can also access the man pages from the command line, with the following command:

# man -M /opt/redhat/rhn/solaris/man <man page>

Finally, add the Red Hat Libraries to your PATH as you did with libgcc, openssl and zlib.

crle -c /var/ld/ld.config -l <current library paths>:/opt/redhat/rhn/solaris/lib

4.1.7.2. Deploying Client SSL Certificates

To ensure secure data transfer, Red Hat strongly recommends the use of SSL. The Red Hat Satellite eases implementation of SSL by generating the necessary certificates during its installation. The server-side certificate is automatically installed on the Satellite itself, while the client certificate is placed in the /pub/ directory of the Satellite's Web server.

To install the certificate, follow these steps for each client:

Download the SSL certificate from the /var/www/html/pub/ directory of the Red Hat Satellite onto the client system. The certificate will be named something similar to RHN-ORG-TRUSTED-SSL-CERT. It is accessible via the web at the following URL: https://your-satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT.
Move the client SSL certificate to the Red Hat Network-specific directory for your UNIX variant. For Solaris, this can be accomplished with a command similar to:
```
 mv /path/to/RHN-ORG-TRUSTED-SSL-CERT /opt/redhat/rhn/solaris/usr/share/rhn/ 
```

When finished, the new client certificate will be installed in the appropriate directory for your UNIX system. If you have a large number of systems to prepare for Red Hat Network management, you may script this entire process.

Now you must reconfigure the Red Hat Network client applications to refer to the newly installed SSL certificate. See Section 4.1.7.3, “Configuring the Clients” for instructions.

4.1.7.3. Configuring the Clients

The final step before registering your client systems with Red Hat Network is to reconfigure their Red Hat Network applications to use the new SSL certificate and obtain updates from the Red Hat Satellite. Both of these changes can be made by editing the configuration file of the Red Hat Update Agent, which provides registration and update functionality.

Follow these steps on each client system:

As root, change to the Red Hat Network configuration directory for the system. For Solaris, the full path is /opt/redhat/rhn/solaris/etc/sysconfig/rhn/.
Open the up2date configuration file in a text editor.
Find the serverURL entry and set its value to the fully qualified domain name (FQDN) of your Red Hat Satellite:
```
serverURL[comment]=Remote server URL
serverURL=https://your-satellite.example.com/XMLRPC
```
Ensure the application refers to the Red Hat Satellite even when SSL is turned off by also setting the noSSLServerURL value to the Satellite:
```
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your-satellite.example.com/XMLRPC
```
With the up2date configuration file still open, find the sslCACert entry and set its value to the name and location of the SSL certificate described in Section 4.1.7.2, “Deploying Client SSL Certificates”, for example:
```
sslCACert[comment]=The CA cert used to verify the ssl server
sslCACert=/opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
```

Your client systems are now ready for registration with Red Hat Network and management by your Satellite.

4.1.8. UNIX Client Registration and Updates

Now that you have installed Red Hat Network-specific packages, implemented SSL, and reconfigured your client systems to connect to the Red Hat Satellite, you are ready to begin registering systems and obtaining updates.

4.1.8.1. Registering UNIX Systems

This section describes the Red Hat Network registration process for UNIX systems. You must use the rhnreg_ks command to accomplish this; the use of activation keys for registering your systems is optional. These keys allow you to predetermine settings within Red Hat Network, such as base channels and system groups, and to apply those automatically to systems during their registration.

Since activation key generation and use is covered extensively in other chapters, this section focuses on differences when applying them to UNIX variants.

To register UNIX systems with your Red Hat Satellite, accomplish the following tasks in this order:

Log into the Satellite's web interface and click the Systems tab in the top navigation bar followed by Activation Keys in the left navigation bar. Then click the create new key link at the top-right corner of the page.
On the following page, select the base channel you created at the end of Section 4.1.6, “Satellite Server Preparation and Configuration”.
After creating the key, click its name in the Activation Keys list to enhance its Red Hat Network settings by associating software and configuration channels and system groups.
Open a terminal on the client system to be registered and switch user to root.
Use rhnreg_ks along with the --activationkey option to register the client with the Satellite. The string of characters that make up the key may be copied directly from the Activation Keys list on the website. The resulting command will look something like the following:
```
rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
```
Go back to the website, click the name of the activation key, and ensure the new system appears within the Activated Systems tab.

4.1.8.2. Obtaining Updates

Package updates in UNIX are handled differently compared to Linux. For instance, Solaris relies on Patch Clusters to update multiple packages at once, while Red Hat operating systems use Errata Updates to associate upgrades with specific packages. In addition, Solaris uses answer files to automate interactive package installations, something Linux doesn't understand, while Red Hat offers the concept of source packages. For this reason, this section seeks to highlight differences in using Red Hat Network tools on UNIX systems. (Note: Red Hat Network does not support Solaris answer files in the current release; such support is planned for future releases.)

Despite inherent differences, such as the lack of Errata, the channel and package management interfaces within the Red Hat Network website on the Satellite work largely the same for UNIX systems. All software channels designed to serve UNIX variants can be constructed almost exactly as the custom channels described in the Red Hat Satellite Getting Started Guide. The most significant difference is the architecture. When creating a UNIX software channel, ensure you select the base channel architecture appropriate for the systems to be served.

Break down your packages into base and child channels depending on their nature. For example, on Solaris, installation packages should go in the Solaris base channel, while patches and Patch Clusters should go in a child channel of the Solaris base channel. Extra installation packages can go in a separate Extras child channel.

Red Hat Network treats patches similarly to packages; they are listed and installed in the same way and with the same interface as normal packages. Patches are 'numbered' by Solaris, and will have names like "patch-solaris-108434". The version of a Solaris patch is extracted from the original Solaris metadata, and the release is always 1.

Patch Clusters are bundles of patches that are installed as a unit. Red Hat Network keeps track of the last time that a Patch Cluster was installed successfully on a system. However, Patch Clusters are not tracked on the client as installed entities so they do not appear in the installed packages or patches list. Patch Cluster names look like "patch-cluster-solaris-7_Recommended". The version is a datestring, such as "20040206", the release is always 1 and the epoch is always 0.

4.1.8.2.1. Uploading Packages to the Satellite

Red Hat Network does not provide UNIX content; any Solaris packages, patches or Patch Clusters must be uploaded to the Satellite in a format that it understands from a client system. That package can then be managed and distributed to other systems. Red Hat Network created solaris2mpm to translate Solaris packages, patches, and patch clusters to a format that the Satellite can understand.

4.1.8.2.1.1. solaris2mpm

As mentioned briefly in Section 4.1.4, “Differences in Functionality”, solaris2mpm is part of Red Hat Network Push for Solaris. The content that is pushed to a Solaris channel on the Satellite must first be in .mpm format.

A .mpm file is an archive containing a description of the package data and the package or patch itself. The solaris2mpm command must be run on the client, never the Satellite.

Note

solaris2mpm requires free space equal to three times the size of any package, patch, or patch cluster it is converting. Normally, space in /tmp/ will be used for this purpose. However, the --tempdir option allows you to specify another directory if necessary.

Multiple files may be specified on the command line of solaris2mpm. Below is a usage example:

# solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm

Because no other directory was specified, the resulting .mpm files are written to the /tmp/ directory. Note that the name of the resulting .mpm files includes the architecture of the client on which it was created. In this case, this was SPARC Solaris. The general format of mpm file names is:

name-version-release.arch.mpm

Patch clusters are "exploded" - .mpm files are generated for each patch in the cluster, as well as a top-level "meta" .mpm file containing information about the cluster as a whole.

Below are the options of solaris2mpm:

Table 4.2. solaris2mpm options

Option	Description
`--version`	Displays the program's version number and exits
`-h, --help`	Displays this information and exits
`-?, --usage`	Prints program usage information and exits
`--tempdir=<tempdir>`	Temporary directory to work from
`--select-arch=<arch>`	Selects the architecture (i386 or SPARC) for multi-arch packages.

4.1.8.2.1.2. rhnpush with .mpm Files

The Solaris version of rhnpush works like the standard utility, but with the added ability to handle .mpm files. Below is a usage example:

% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \
RHATrpush-3.1.5-*.mpm
 Red Hat Network password:
 Connecting to http://testbox.example.com/APP
 Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm
 Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm

Note

Patch cluster .mpm files must be pushed either concurrently with or after - never before - the .mpm files for the patches contained in that cluster.

Use solaris2mpm on each of the packages, patches, or patch clusters you wish to manage via the Satellite, then use Red Hat Network Push to upload them to the channel created for them.

4.1.8.2.2. Updating Through the Web Interface

To install packages or patches on an individual system, click the name of the system in the Systems category, select the packages from the Upgrade or Install lists of the Packages or Patches tab, and click Install/Upgrade Selected Packages.

To run a remote command while installing the package, click Run Remote Command rather than Confirm. See Section 4.1.9, “Using Remote Commands” for instructions.

To install packages or patches on multiple systems at once, select the systems and click System Set Manager in the left navigation bar. Then, in the Packages tab, select the packages from the Upgrade or Install lists and click Install/Upgrade Packages. To complete the action, schedule the updates.

4.1.8.2.3. rhnsd

On Red Hat Enterprise Linux systems, the rhnsd daemon, which instructs the client system to check in with Red Hat Network, automatically starts at boot time. On Solaris systems, rhnsd does not start at boot time by default. It can be started from the command line in this way:

rhnsd --foreground --interval=240

The default location for rhnsd is /opt/redhat/rhn/solaris/usr/sbin/rhnsd. Below are the available options for rhnsd on Solaris:

Table 4.3. rhnsd Options

Option	Description
`-f, --foreground`	Run in foreground
`-i, --interval=MINS`	Connect to Red Hat Network every MINS minutes
`-v, --verbose`	Log all actions to syslog
`-h, --help`	Give this help list
`-u, --usage`	Give this help list
`-V, --version`	Print program version

4.1.8.2.4. Updating From the Command Line

Like the website, command line use of the Red Hat Update Agent is affected by the limitations of UNIX package management. That said, most core functions can still be accomplished through the up2date command. The most significant difference is the absence of all options regarding source files. See Section 4.1.8.2.4, “Updating From the Command Line” for the precise list of options available for UNIX systems.

The command line version of the Red Hat Update Agent accepts the following arguments on UNIX systems:

Table 4.4. Update Agent Command Line Arguments

Argument	Description
`--version`	Show program version information.
`-h`, `--help`	Show this help message and exit.
`-v`, `--verbose`	Show additional output.
`-l`, `--list`	List the latest versions of all packages installed.
`-p`, `--packages`	Update packages associated with this System Profile.
`--hardware`	Update this system's hardware profile on Red Hat Network.
`--showall`	List all packages available for download.
`--show-available`	List all the packages available that are not currently installed.
`--show-orphans`	List all the packages currently installed that are not in channels the system is subscribed to.
`--show-channels`	Show the channel names along with the package names where appropriate.
`--installall`	Install all available packages. Use with `--channel`.
`--channel=CHANNEL`	Specify which channels to update from using channel labels.
`--get`	Fetch the package specified without resolving dependencies.

4.1.9. Using Remote Commands

With UNIX support, Red Hat Network offers the flexibility of issuing remote commands on client systems through the Satellite's website. This feature allows you to run virtually any (compatible) application or script on any system in your domain without ever having to open a terminal.

4.1.9.1. Enabling Commands

With the flexibility this tool offers comes great risk and the responsibility to mitigate that risk. For all practical purposes, this feature grants a root BASH prompt to anyone with administrative access to the system on the website.

This can be controlled, however, through the same config-enable mechanism used to determine which systems can have their configuration files managed by Red Hat Network.

In short, you must create a directory and file on the UNIX system that tells Red Hat Network it is acceptable to run remote commands on the machine. The directory must be named script, the file must be named run, and both must be located in the /etc/sysconfig/rhn/allowed-actions/ directory specific to your UNIX variant.

For instance, in Solaris, issue this command to create the directory:

 mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script

To create the requisite file in Solaris, issue this command:

 touch /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script/run

4.1.9.2. Issuing Commands

You may schedule a remote command in a variety of ways: on an individual system, on multiple systems at once, and to accompany a package action.

To run a remote command on an individual system by itself, open the System Details page and click the Remote Command subtab. (Note that this subtab only appears if the system has a Provisioning entitlement.) On this page, establish the settings for the command. You may identify a specific user, group, and timeout period, as well as the script itself. Select a date and time to begin attempting the command, and click the Schedule Remote Command link.

Similarly, you may issue a remote command on multiple systems at once through the System Set Manager. Select the systems, go to the System Set Manager, click the Provisioning tab, and scroll down to the Remote Command section. From there you may run a remote command on the selected systems at once.

To run a remote command with a package action, schedule the action through the Packages tab of the System Details page and click Run Remote Command while confirming the action. Use the radio buttons at the top to determine whether the command should run before or after the package action, establish the settings for the command, and click Schedule Package Install/Upgrade.

Note that installing multiple packages that have different remote commands requires scheduling the installs separately or combining the commands into a single script.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.