Chapter 12. UNIX Support Guide2085. 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 liston the website. The resulting command will look something like the following:rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af6. Go back to the website, click the name of the activation key, and ensure the new system appearswithin the Activated Systems tab.12.4.2. Obtaining UpdatesPackage updates in UNIX are handled much differently than in Linux. For instance, Solaris relies onPatch Clusters to update multiple packages at once, while Red Hat operating systems use ErrataUpdates to associate upgrades with specific packages. In addition, Solaris uses answer files toautomate interactive package installations, something Linux doesn't understand, while Red Hat offersthe concept of source packages. For this reason, this section seeks to highlight differences in usingRHN 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 managementinterfaces within the RHN website on the Satellite work largely the same for UNIX systems. Allsoftware channels designed to serve UNIX variants can be constructed almost exactly as the customchannels described in the RHN Channel Management Guide. The most significant difference is thearchitecture. When creating a UNIX software channel, ensure you select the base channel architectureappropriate for the systems to be served.Furthermore, Red Hat recommends you break down your packages into base and child channelsdepending on their nature. For example, on Solaris, installation packages should go in the Solarisbase channel, while patches and Patch Clusters should go in a child channel of the Solaris basechannel. 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 thesame 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 timethat a Patch Cluster was installed successfully on a system. However, Patch Clusters are not trackedon the client as installed entities so they do not appear in the installed packages or patches list. PatchCluster 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.12.4.2.1. Uploading Packages to the SatelliteRHN does not provide UNIX content; any Solaris packages, patches or Patch Clusters must beuploaded to the Satellite in a format that it understands from a client system. That package canthen be managed and distributed to other systems. RHN created solaris2mpm to translate Solarispackages, patches, and patch clusters to a format that the Satellite can understand.
