8.4. Registration and Updates

8.4.1. Registering Systems

This section describes the RHN 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 RHN, 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. Refer to Section 6.4.6.1 Managing Activation Keys for full descriptions of this process.

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

1. 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.

2. On the following page, select the base channel you created at the end of Section 8.2 Satellite Server Preparation/Configuration.

3. After creating the key, click its name in the Activation Keys list to enhance its RHN settings by associating software and configuration channels and system groups.

4. Open a terminal on the client system to be registered and switch user to root.

5. 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 --user username --serverUrl=http://your-satellite.example.com/XMLRPC --activationkey=25ad3d099e69ff1a3c6dc60d7479c0f6

   Be sure to replace the argument of each option with values appropriate to your organization.

6. Go back to the website, click the name of the activation key, and ensure the new system appears within the Activated Systems tab.

8.4.2. Obtaining Updates

Package updates in UNIX are handled much differently than in 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 RHN tools on UNIX systems. (Note: RHN 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 RHN 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 RHN Channel Management 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.

Furthermore, Red Hat recommends you 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.

RHN 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. RHN 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.

8.4.2.1. Uploading Packages to the Satellite

RHN 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. RHN created solaris2mpm to translate Solaris packages, patches, and patch clusters to a format that the Satellite can understand.

8.4.2.1.1. solaris2mpm

As mentioned briefly in Section 8.1.4 Differences in Functionality, solaris2mpm is part of RHN 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:

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.

Table 8-1. solaris2mpm options

8.4.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 RHN Push to upload them to the channel you created for them.

8.4.2.2. Updating Through the Website

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. Refer to Section 8.5 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.

On Red Hat Enterprise Linux systems, the rhnsd daemon, which instructs the client system to check in with RHN, 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: 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 Table 8-2. rhnsd Options