Creating a local RPM site for Isolated Red Hat Servers - Part II

In my previous post, I discussed one option of downloading, but NOT installing, required and marked packages for a RedHat Server. In the first Part, I included a script that would create a directory and download the rpm files to this directory specifically. I had tested this script on an RHEL 5.5 machine.

This post is continuation of the Part I and makes the assumption that the reader now has, in at least some fashion, downloaded the rpm files that are needed to patch a system that can't (or doesn't) touch the internet. This system is assumed to be mirrored by the system that we used to download patches. So....

Using the script from Part I, and today's date, we should have a folder /vpmt/updates/2011_01_04/ that contains all of the currently needed rpm files. What are we supposed to do with these files, other than just stare at them?

I am so glad you asked, and I hope that you are prepared for a long, LONG, drawn out answer. Please understand that there is a LOT of work required in updating an offline system from patches downloaded to a mirrored online system. So...

1. Copy the files to a disk
2. Copy the files from the disk to the offline system
3. Open a terminal window and navigate to the folder where you copied the rpm files to in step 2
4. Execute (as root, or with su) chmod 755 *.rpm
5. Execute (as root, or with su) rpm -Uvh *.rpm from the directory where the files were copied


...and those five steps, ALL five long and tedious steps, are all that should be required to install the patches that you downloaded on the first system. Now, I know what you are thinking: "What about all the dependencies that are bound to be present?" This is where the way rpm works and its options come into play.

More to follow about RPM.

Creating a local RPM site for Isolated Red Hat Servers - Part I

Some of us do, or have had to, work with multiple networks. Some of the organizations I have had the pleasure of working in have had some networks that were completely isolated from any network access but still need have their patching level maintained.

One reason for this type of set-up is when you have an isolated network that still has the requirement of being regularly updated. In set-ups such as this, it is often helpful to have a mirrored set-up that can in fact pull updates when required.

We can try to just run the yum command in a terminal. However, if you just run yum update based on the default yum.conf file, then the system will only ask [y/N] if you want the updates to be applied. Answering N does NOT download the update files, unfortunately. So what is the answer? A script, like the one below should provide the first part of a viable solution. The below script requires that the yum-downloadonly package be installed.

Script to download but not install updates for all packages marked for update

#########################################
# FileName: Get_Yum_Updates.sh #
# Comments: Tested on RHEL5.5 x86_x64 #
#########################################

#!/bin/bash

#create a unique name for folder and file names
RunDate=`date %y_%m_%d`
#Set up filenames unique to day that script is run
InitUpdateCheckFile="Yum_Check_Update_Init_20${RunDate}.txt"
FinalUpdateCheckFile="Yum_Check_Update_Final_20${RunDate}.txt"
DiffBriefFile="Yum_Diff_Brief_20${RunDate}.txt"
DiffFullFile="Yum_Diff_Fill_20${RunDate}.txt"

#create new directory for rpm files
DownloadDir="/vpmt/updates/20${RunDate}"
mkdir ${DownloadDir}
#cd to new directory for diff purposes
cd ${DownloadDir}

#before downloading anything, let's see what's needed
#and pipe this list to our first check update file
yum check-update > ${InitUpdateCheckFile}

#now, lets run the yum command that we REALLY want
yum --downloaddir="${DownloadDir} --downloadonly update

#for one final check that nothing was installed, let's
#run another check-update and now pipe it to the final
#check-update listing file
yum check-update > ${FinalUpdateCheckFile}

#becuase it can be helpful for further CM actions or
#for when files need to be updated on multiple machines
#here is a setup for the diff options

#first, lets diff, with the brief switch, the two check update files
diff --brief ${InitUpdateCheckFile} ${FinalUpdateCheckFile} > {$DiffBriefFile}

#here we could test the size of DiffBrief File and end the script
#if the size is 0, meaning that there were no changes (as a result
#of our yum command above) between what packages need to be updated .
#However, for just an example of a defualt diff operation
diff ${InitUpdateCheckFile} ${FinalUpdateCheckFile} > {$DiffFullFile}



#end
exit 0
###################################################



The above script should be fairly easy to understand. A few other notes on the script should be made. The first one is the variable for the DownloadDir: this can be set to whatever directory you want.../vpmt/updates/ just happens to be where I would put the rpm files downloaded by the yum operation.

Secondly, the actual yum command CAN take other parameters. One of the more notable ones is the --skip-broken. The --skip-broken switch tells the yum operation to skip packages with dependency issues/problems. Another convenient switch is the -y option. This option uses an equivalent of the assume-yes configuration option. If you are only downloading, and are not worried about the exact size of the total download, this option is nice as it allows you to walk away and the script will finish without your help.

One final note on the above script: the comment about testing the size of the diff --brief file is NOT the only test we could do to make this script more robust. We could in fact test for things such as our directory already existing, testing for specific permissions on the directory, and even (with a few more lines) testing to see if any previous download folders created by the script contain any of the patches we need. The bottom line is that this script is not an "end all" cure for getting AND tracking your patching program. I merely offer it as a starting point.

Once this script has been executed succesfully, the following should exist:
1) a folder: /vpmt/updates/20[the date]
- for example: /vpmt/updates/2011_1_3/
- This directory should contain:
I. All downloaded RPMs from the yum operation
II. Metacache data from the yum operation
III. The txt files we created from running the check-update switch and the diff operations.

What do we do, and what can we do, with this folder and its contents I will leave for a different day (but I will say that the focus will be on creating a DVD of the RPMs and using the localinstall option of yum. I will say that we can now use the check-update files created here to monitor CM operations. These files can be explicity massaged with another script to create an action item list on all packages that were updated from this newly created folder.

I noticed that it has been about three months since I have posted ANYTHING to my blog. With any luck, and purely for my own memory only, I can keep it more updated from now on. I do intend to add a second part to this post (and maybe some updates to this one) when I get a little more time this week. I would also like to play around kickstart files in the near future.

One final note: I hope that everyone's New Year and Christmas days were safe and enjoyable! --dw