RHEL 6 - Native Tools patching questions

So I have started this conversation with IBM support but I’d like to post this question here as well to see what real understanding people have of the patching process.

I’m very aware of how the patch process works for all of the other OS’s, even the RHEL 5. In all of the other patch sites the action code is very straight forward, it has a prefetch or download command with the patch file and it’s sha1 values and then the install command for that patch. Very straight forward.

RHEL 6 takes this into a completely new direction. I just can’t wrap my brain around it. If you look at any of the action code for the RHEL 6 patches, you won’t see a single line that contains the .rpm package or the yum install command. All of the patch process is wrapped up in some .sh scripts. When patching a system on an internet connected machine, the systems appear to patch properly. The issue that I have is that my machines are not connected to the internet and so I need to pre-cache the files to my BigFix server first and then patch. This is where I’m stumped.

From what it looks like when you initiate a patch it appears that there are some support files that get downloaded from IBM, which seem to include the latest Repository information and some other things. They may or may not be listed on the page linked here, http://sync.bigfix.com/cgi-bin/bfgather/patchesforrhel6nativetools . Once it does that it then scans the patches and searches the Red Hat site for the .rpm’s and any dependencies. Those then get cached and patched.

This leads to new problems, my cache is getting out of hand. Because the .rpm’s are not listed in the action code I have no idea which rpm’s are used with each patch. Using the File Pre-Cache Wizard does not work on RHEL 6.

Does ANYONE have a firm grasp of the entire patch process for RHEL 6? I really need to know what files are being pulled from IBM and what files I need to cache.

Thanks

OK, I don’t know all of RHEL patching, but I do know Windows and Java patching and try to understand how the inner workings of the how fixlets and cache work with the flow of data.

So from what you are explaining, you are looking to cull your cache, and normally you would do that by looking at the hash, and then find the corresponding fixlet that called it to see if it can be removed, but the fixlet calls a wrapper .sh file, and using that, the server pulls down the file.

I have two thoughts on that. First, it doesn’t matter, if the cache is out of control just delete something, if the server needs something and it is missing, it will re-download it. Second, is there a way to find and inspect that wrapper .sh file.

The patch actions for RHEL works in this way:

  1. SelectRepoFiles.sh is invoked in order to resolve which set of repository metadata needs to be downloaded (there are separate set of files for Server, Client and Workstation and both 32 and 64 bit architectures.

  2. These files are requested from IBM sites (software.bigfix.com). Everytime we release a new set of fixlets, a new set of files will be uploaded and fixlet actions will request the latest versions of these files.

  3. Once these files have been downloaded on the endpoint, CreateYumConfig.sh is invoked in order to prepare a the yum configuration to be used. We use a temporary yum configuration to leave the endpoint’s default yum settings/caches etc intact.

  4. Then we invoke ResolveDependencies.sh which triggers yum in the background in order to resolve dependencies. This step involves using a yum plugin that prints out the packages that are going to be needed by yum and terminates yum before it attempts to download any packages. This is the reason why you don’t see a reference to an .rpm file because that list is generated on the spot based on the target packages which the action is trying to patch. The reason for this is other than the target packages, there may be dependency packages which are needed to be installed/updated as part of this patch.

  5. We request the rpm packages requested by yum from RedHat (using something called a download plugin).

  6. Lastly we invoke InstallPackages.sh which invokes yum and forces it to use cached content to install the packages.

The above is a high level picture of how the action works. You can find more details regarding the patching via our patching guide for RHEL.

In case if you have any mirrors of the RedHat repositories or a Satellite server, you can let actions bypass the steps 1-5 above. You can look at http://www-01.ibm.com/support/knowledgecenter/SS6MER_9.1.0/com.ibm.tivoli.tem.doc_9.1/Patch_Man/Patch_Man_RH/c_manage_custom_repositories.html

Otherwise, once you have registered the RedHat download plugin, IEM server will automatically download and propagate down the rpm files. If you are in an airgapped environment, using a custom repository mirror and maintain that is the way to go.

Thank you very much. I haven’t fully read all of the links but a quick glance says this is the information that I’m looking for.

Once I have fully read this if I have any further questions I will reply again but I do have a quick questions.

You said that each time the site version changes the files are requested. Currently the site version is at 105. Where are those files stored? Can I download them manually, so that I can manually cache those files on my air-gapped system?

Thanks

There is a file called EDR_RepodataManifest in the site. That file is the manifest for the metadata needed by the fixlets. The file contains lines in the format:

OS Flavor#architecture#rhn#filename#size#sha1#sha2#url

Based on the OS flavors (server/client/workstation) and architectures you have you can selectively choose the files that needs to be cached.

Since the file is in the site, you don’t need to separately cache it. When you use the airgap tool to gather new versions of all your subscribed sites, the manifest file will be downloaded as a part of that process with patch fixlets, etc.

Just to clarify, if you are using the custom repository mirror or satellite, you don’t even need those metadata files. Yum will directly talk to your mirror/satellite to get both metadata and the .rpm packages from them.

Note that this will bypass IEM caching infrastructure for downloads since yum on the endpoints will connect directly to the repos.

Hello Sahinb,

As mentioned by sinucus,File Pre-Cache Wizard does not work for RHEL 5 & 6 native tools/dependency resolution sites. Is there any workaround to cache the required rpms to local relays before initiating patch deployment?

As you know caching the binaries to local relays will certainly reduce the downtime requires for patching.

Thanks
Raja

Using the content in the Native Tools sites will cause the clients to actually use Yum to download and install the patches. The Relays are not used to download content from these sites. You can, and in my mind, should have a local Repository or Sattelite server configured for your Linux systems. Yum will download the patches from these rather than the Relays.

Thanks Tim for your explanation.