190 Chapter 8. UNIX Support GuideBe sure to replace the argument of each option with values appropriate to your orga-nization.6. Go back to the website, click the name of the activation key, and ensure the newsystem appears within the Activated Systems tab.8.4.2. Obtaining UpdatesPackage updates in UNIX are handled much differently than in Linux. For instance, Solarisrelies on Patch Clusters to update multiple packages at once, while Red Hat operating sys-tems use Errata Updates to associate upgrades with specific packages. In addition, Solarisuses answer files to automate interactive package installations, something Linux doesn’tunderstand, while Red Hat offers the concept of source packages. For this reason, this sec-tion seeks to highlight differences in using RHN tools on UNIX systems. (Note: RHN doesnot support Solaris answer files in the current release; such support is planned for futurereleases.)Despite inherent differences, such as the lack of Errata, the channel and package manage-ment interfaces within the RHN website on the Satellite work largely the same for UNIXsystems. All software channels designed to serve UNIX variants can be constructed almostexactly as the custom channels described in the RHN Channel Management Guide. Themost 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 childchannels depending on their nature. For example, on Solaris, installation packages shouldgo in the Solaris base channel, while patches and Patch Clusters should go in a child chan-nel of the Solaris base channel. Extra installation packages can go in a separate Extras childchannel.RHN treats patches similarly to packages; they are listed and installed in the same way andwith the same interface as normal packages. Patches are ’numbered’ by Solaris, and willhave names like "patch-solaris-108434". The version of a Solaris patch is extracted fromthe original Solaris metadata, and the release is always 1.Patch Clusters are bundles of patches that are installed as a unit. RHN keeps track ofthe last time that a Patch Cluster was installed successfully on a system. However, PatchClusters are not tracked on the client as installed entities so they do not appear in theinstalled 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 always1 and the epoch is always 0.8.4.2.1. Uploading Packages to the SatelliteRHN does not provide UNIX content; any Solaris packages, patches or Patch Clusters mustbe uploaded to the Satellite in a format that it understands from a client system. That pack-age can then be managed and distributed to other systems. RHN created solaris2mpm
