Sha1 to real filename mapping/Understanding new RHEL patching method

Usage and Config Patch
1

Not really sure which forum this best fit under, but that’s the least important worry. I’ve mentioned my situation many times on this forum over the years so some might be familiar with my situation, but here it goes.

I’m in a totally 100% air-gapped environment where we use Custom sites and not the native sites. We take the patches from “patches for RHEL 7” and copy them to our custom site and then distribute this custom site to our customers. This is done because we need to personally vet each patch and only distribute authorized patches… So we run into a few problems by doing this.

  1. BigFix does not have any method for matching sha1 files to their real filename counterpart. It’s assumed that you’ll just always download the files you need so who cares if we purge the sha1 folder. Because I’m air-gapped I have to distribute every patch that could possibly be used and if I miss 1 single file, the stupid baselines stop processing because BigFix won’t skip trying to download files and move along, so I err on the side of caution and try not to delete files unless I’m 100% sure they will never be needed again. I saw a post from about a year ago from jgstew about using session relevance to match against prefetch commands. That helps, but I wrote my own scripts back in 2012 for that, but they fall short when the scripts don’t use those commands (I’m looking at you “Patches for RHEL x”). Does anyone have any other method? Maybe the action details is storing something in one of the tables in the BFEnterprise db?

Here are my own session relevance scripts. (Just in case they help someone else)
//unique values of (if (it as lowercase contains “add prefetch item name”) then ((parenthesized part 2 of it & “|~|” & parenthesized part 1 of it) of matches (regexes “add\s+prefetch\s+item\s+name=(\S+)\s+sha1=(\S+)\s+size”) of it) else (if (it as lowercase contains “prefetch”) then ((parenthesized part 2 of it & “|~|” & parenthesized part 1 of it) of (matches (regexes “prefetch\s+%22?([^%22]\S+[^%22])%22?\s+sha1:(\S+)”) of it)) else ((parenthesized part 1 of it & “|~|” & parenthesized part 3 of it) of (matches (regexes “continue\s+if.*sha1\s+of\s+it\s+=\s+%22(\S+)%22.*of\s+file\s+%22(__Download\)?(\S+)%22”) of it)))) of (action scripts of bes actions; scripts of actions of bes fixlets whose (display name of site of it = “my site”))
//unique values of ((parenthesized part 1 of it & “|~|” & parenthesized part 3 of it) of (matches (regexes “continue\s+if.*sha1\s+of\s+it\s+=\s+%22(\S+)%22.*of\s+file\s+%22(__Download\)?(\S+)%22”) of it)) of (action scripts of bes actions; scripts of actions of bes fixlets whose (display name of site of it = “my site”))
// unique values of (matches (regexes “continue\s+if.*sha1\s+of\s+it\s+=\s+%22(\S+)%22.of\s+file\s+%22(__Download\)?(\S+)%22") of it) of (scripts of actions of bes fixlets whose (display name of site of it = “my site”))
//unique values of (matches (regexes "prefetch.\n”) of it) of (scripts of actions of bes fixlets whose (display name of site of it = “my site”))

  1. Red Hat… What is there to say about the frustrations behind RHEL patching… So, I had a decent method of patching RHEL before they up and changed something, AGAIN… What is used to do was rather simple. I wrote .bat script to process the sites.

:: Grabs the latest Patches for Red Hat 6 Native from Bigfix
wget http://sync.bigfix.com/cgi-bin/bfgather/patchesforrhel6nativetools
:: Finding the version number
call jrepl “(?:Version: )(\d*$)” $1 /jmatch /f patchesforrhel6nativetools /o sitever.txt
:: Grabbing the version and inserting it into the URL for all the site files
set /p ver=<sitever.txt
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/EDR_RepodataManifest -P .\Site
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/CreateYumConfig.sh -P .\Site
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/InstallPackages.sh -P .\Site
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/ResolveDependencies.sh -P .\Site
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/SelectRepoFiles.sh -P .\Site
wget http://sync.bigfix.com/bfsites/patchesforrhel6nativetools_%ver%/yum-iemplugin.py -P .\Site
:: Running the Bigfix archive utility to compress the files
d:\tools\bfarchive -a “D:\wget\Site” “D:\wget\rhel.tmp”
:: Running the sha calculation and dumping the file into the sha1 folder and writing the actionscript into a .txt file
py “D:\tools\make-prefetch.py” D:\wget\rhel.tmp > %ver%_action.txt
:: Doing a regex to find the RHEL 6 Server download URLs and outputting to a txt file
call jrepl “http://.+6Server.+x86_64.+” “$0” /jmatch /f .\Site\EDR_RepodataManifest /o results.txt
:: Calling wget and downloading the URLs from the previous command
wget -i results.txt -P .\RHEL
cd .\RHEL
:: Using a for loop to process the directory and pipe it into the sha calculation tool.
for %%i in ("*") do (set fname=%%i) & call :rename
goto :eof
:rename
:: The previously downloaded files are prefixed with a datestamp. This will trim the datestamp off
ren “%fname%” "%fname:~13%"
py “D:\tools\make-prefetch.py” %fname:~13% >> …%ver%_action.txt
goto :eof

So, it looks complicated but it’s rather simple, I just download the site info, parse it, grab the Repo data and boom, I get all the files I need to process Red Hat patches. I just throw those into the sha1 folder and I’m off to the races.

No more… With the latest updates that Red Hat has done to move to certificate based patching this old process no longer works. Now when I patch, it downloads 20+ files and creates an ungodly mess of unnecessary files that I don’t want to keep and I can’t keep track of them. Does anyone have a good handle on how in the world this new patching works for RHEL 6 and 7?

Just for clarification, the development server that I work on with a simulated lab of endpoints IS connected to the internet. The production servers that I patch are the ones that are air-gapped.

Thanks

2

You probably should open a PMR to make sure you have all your issues handled, but here’s a little detail on how I’m dealing with my airgap and some warnings from my own support call.

First off, the fixlets in the new RHSM patching model requires that the client be subscribed to the “Patches for RHEL x” site. You can use custom copies of the fixlets, but they depend on Site Files attached to the RHEL site to do some of their client-side processing.

You’ll need to use the RHSMDownloadCacher tool to download and create a repository for your RHEL patches. Have you gotten that to work yet? The download files don’t live directly in sha1 anymore. The new RHSMProtocol:// handler requires that it exists as a YUM repository (which the RHSMDownloadCacher generates.

To use the repository in an Airgap, you must host a copy of the repository directly on the BigFix Server (Windows), or to local storage or NFS mount on Linux. You install the RHSM Download Plug-In on your Airgapped BigFix Server. Once that’s done, under the BES Server installation directory, you’ll get a DownloadPlugins folder that will contain the RHSMProtocol folder. Edit the plugin.ini to point to your airgapped repositor and set the localCacheOnly option. I changed the following lines in mine:

[UA]
; Original entry had forwardslash at CurrentSiteData/DLRHELRepoList.json
primaryRepoListFile=D:\Program Files (x86)\BigFix Enterprise\BES Server\GatherDBData\gather\Patching Support\CurrentSiteData\DLRHELRepoList.json
localCache = D:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\CustomSites\RHEL_Repo
localCacheOnly = yes
rootCertDir = certs

Beneath the RHSMProtocol directory, I created a “certs\cert_set_1” folder, containing my RHSM certificates. Strictly-speaking I don’t know whether that’s required on the Airgap side, or only on the Internet-facing BES server, but I have it on both.

The RHSMDownloadCacher does indeed download a lot - it builds an entire repository mirroring everything available from RHSM. I don’t think there’s any way around that; I’ve asked for options like “only Relevant fixlets” but I don’t think there’s going to be any motion on that. The RHSMDownloadCacher is also unnecessarily slow in that it also validates by checksum all of the existing files in the download repository, and it looks like a future version will add an option to skip the validation. In my environment it takes about 5-6 hours nightly to run the download cacher. I’m hosting about 160 GB of patches in my repo, covering only RHEL 6 Server and Workstation, x86_64. I like your scripts, and maybe you can try to parse the fixlets and use the “download specific package by name” parameter for the cacher, but the client does its own dependency resolution and may download dependent packages during the action so be ready for that.

3

The RHSM Cacher tool has been updated so it doesn’t do SHA1 verification on each run by default. Instead, you can run it using a flag --verifyExistingPkgChecksum to force it to verify the SHA1 checksum of already downloaded packages.

The RHSM download cacher is available from the BigFix Support site.

2 Likes
4

Thanks much, I’ll be giving it a try shortly!