Image of the glider from the Game of Life by John Conway
Skip to content

Spacewalk/RHN Satellite Registration Script

At work, we have an RHN satellite that is registered against RHN, and pulls down all the updates as necessary for the 32-bit and 64-bit RHEL servers that we have in our network. We currently have 34 RHEL servers in operation, with the expectation to grow past 40, all without virtualization. When we really start taking advantage of Xen and/or KVM, so our developers each have their own sandbox, our RHEL saturation will grow past 200. We need a simple way to manage this. My solution was simple: install clusterssh on my Linux desktop, then write a simple script to automate the regestration. First, the script:

# Register the machine with the local satellite
# Replace '' with the FQDN of your satellite server

rpm -Uvh
sed -i 's/https:\/\/\/\/' /etc/sysconfig/rhn/up2date
sed -i 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/' /etc/sysconfig/rhn/up2date

if rpm -q yum &> /dev/null; then
    yum clean all
    yum -y update
    up2date -u

This script doesn't have much to it, but it sure beats the pants off doing it manually. It installs the SSL certificate necessary for communicating with the satellite. Note: if your date timestamp is not in sync with the satellite, then the SSL certificate will fail validation against the satellite, and you won't be able to continue. It would be ideal if you are taking advantage of NTP, encrypted or unencrypted, to keep all your dates in sync.

After installing the certificate, we make only two edits to the /etc/sysconfig/rhn/up2date file, pointing our updates to our satellite and telling it the certificate that it needs to use. After which, we run 'rhn_register' to register ourselves against the satellite. This will require interaction, specifying your username and password to login to the satellite, and so forth. Lastly, after the registration, we update our system to grab and install the latest packages.


Now, with 200 possible RHEL systems, doing this on each system one by one could be problematic. My solution? I installed clusterssh to manage the large amounts of servers that I'm interacting with. I then created a .csshrc file to store all the profiles that I need. Now, when I'm ready to register the systems, I can do them in bulk, rather than one at a time. Of course, you can have X11 forwarding to your display, if you want, as clusterssh reads the standard SSH config file in your home directory, as clusterssh is just a frontend to multiple SSH connections. This could get messy though, with several popups on your desktop. Your mileage may vary.

Now, the results. I have just registered 16 RHEL 5.2 servers against my satellite in the time in would take me to do one. Good thing for good GNU/Linux tools and a little bit of hackery.

{ 4 } Comments

  1. Robin | March 25, 2009 at 3:15 pm | Permalink

    I've been using puppet for this kind of thing. Basically, after setting up a new server, the first thing I do is install puppet on it, and from then on the puppet master is in control of the entire configuration.

    The most useful thing with this is that should the configuration need to change, I change it in one place and over the next 30 minutes, the change is distributed.

  2. Shane | March 26, 2009 at 7:44 am | Permalink

    As an alternative to clusterssh, I'd like to suggest the Dancer Shell (dsh). I've been using that to admin 50 workstations and it doesn't have the annoyance of lots of windows appearing on my screen. I created an admin account with privileges, created a public/private keypair and put it on all the machines (that's the hardest part, but I have a script if you're interested that uses ssh and sshpass to help get past the manual part in a less secure fashion).

    Now, I just do a command like "dsh -g centos-workstations yum -y update" and they all update themselves. I can also tell dsh to run them in parallel, but I usually like to see the output serially.

  3. Aaron | March 26, 2009 at 9:16 am | Permalink

    @Robin Yeah. Puppet with Cobbler is the way to go, for sure. We haven't gotten to that point yet, although it's on my radar.

    @Shane Looking at DSH, and some of the others like PyDSH, it seems that you can only execute remote non-interactive commands. What if I needed to execute an interactive command on 50 servers, such as rhn_register? Is this possible with DSH?

  4. Eric | September 19, 2009 at 4:48 am | Permalink

    You can use rhnreg_ks instead of rhn_register. Just supply rhnreg_ks with the key from satellite server and you don't have to worry about any pop-ups or changing the up2date file. This can also force your boxes into custom channels if you use those for change control.

    caveat** I changed the if/then format to make it easier to read.. might want to check the logic. I typically use && or || and long single lines, but it's hard on the eyes... Also, this is a force register so it is possible that you could double register the system. They are easy to delete though. You could put another check in for available channels or the sort to prevent that.
    rpm -Uhv http://my_server/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    if [[ `uname -p|grep 64` ]]
    rpm -Uhv http://my_server/pub/up2date-4.7.1-17.el4.x86_64.rpm
    rpm -Uhv http://my_server/pub/up2date-4.7.1-17.el4.i386.rpm
    rhnreg_ks --serverUrl=http://my_server/XMLRPM --force --activationkey=My_Activation_Key_from_Sat_Server

    which yum && yum -y update || up2date -u

Post a Comment

Your email is never published nor shared.