This is part two of an ongoing series called, "The RHN Satellite Survival Guide."
Before diving into system registration, take some time to set up a new organization and think through your workflow. You will have a better long-term experience by doing this work up front instead of trying to retrofit it. Managing when and how patches and updates from Red Hat are made available to systems and environments is one of the strongest arguments one can make for bringing Satellite into your shop.
So you've installed your shiny new Satellite, sync'd your first base channel, set up your sync'ing cron job, and now it's time to register your systems and get a-patchin'!
Whoa, not so fast!
The first thing to do is create a new organization. You may think, "We're a small team with just one set of servers, no need to complicate things with organizations," but I'm not the only one who thinks doing so is a good idea. While you can skip ahead to page 61 for the Organizations discussion, go ahead and read the whole presentation. Thomas Cameron is a really knowledgeable and eloquent presenter, even on paper.
Now that you've created your first organization and added your sync'd base channel, let's talk about how you are actually going to use this Satellite machine for updates (and for now, just updates). So let's grab a white board and an eraser, or at least a pen and paper. There are a few questions you need to answer about how you deploy standard operating environments, from a current state and a desired state. They are:
• Do you want systems to drink from the Satellite fire hose: unfiltered patches as soon as they are available?
• Do you have different logical environments like development, test, staging, customer acceptance, and production?
• Is there a testing and CM process in place for patching systems?
• Do you have systems that need different versions of things than provided by the base RHEL stream like PHP?
• Do you use any other outside repositories to provide special tooling?
• Do you roll your own code that gets deployed to any systems?
Add to this mix one key factor: systems can only be subscribed to a single base channel. It's also a good time to review the docs, specifically the Channel Management Guide. This is by no means a comprehensive list, but it should get you thinking on the right track.
A Sample Workflow
I'm going to make up a workflow here and talk about some of the command line tooling that doesn't get detailed treatment in the docs, specifically: spacewalk-clone-by-date
MyOrg has three logical environments: dev, test, and prod. Everything is RHEL 6.2 Server (for ISV support reasons) with Cluster Suite and the developer's use Asciidoc for documentation. We've seen some issues with Amanda so we need to make sure we don't make it available*. We're going to stay simple with naming conventions and use the environment as a prefix to identify the clones.
First, find the labels for all the source parent and child channels we need. In this case, we need:
rhel-x86_64-server-6 (Main Server channel)
rhel-x86_64-server-ha-6 (HA Add on channel)
rhn-tools-rhel-x86_64-server-6 (Extra Satellite client tools)
rhel-x86_64-server-supplementary-6 (for Asciidoc)
Next, since we need 6.2, I'm going to approximate by using the date that 6.2 was dropped. A trip to the Internet tells me it was 2011-12-06 (YYYY-MM-DD is the format we want).
In order to skip Amanda we need to add a pattern to remove like: 'amanda.*'
Building a complete command line to create our dev channels would look like this:
# spacewalk-clone-by-date -l rhel-x86_64-server-6 dev-rhel-x86_64-server-6 -l rhel-x86_64-server-ha-6 dev-rhel-x86_64-server-ha-6 -l rhn-tools-rhel-x86_64-server-6 dev-rhn-tools-rhel-x86_64-server-6 -l rhel-x86_64-server-supplementary-6 dev-rhel-x86_64-server-supplementary-6 -d 2011-12-06 -r 'amanda.*' -u MyOrg-admin
Note the user name (-u MyOrg-admin) tacked on the end. You specify which organization you are acting in by modifying that org admin user name.
Once we had dev created and working the way we want, we use a simpler command line to create the test channel using dev not upstream as the source.
# spacewalk-clone-by-date -l dev-rhel-x86_64-server-6 test-rhel-x86_64-server-6 -l dev-rhel-x86_64-server-ha-6 test-rhel-x86_64-server-ha-6 -l dev-rhn-tools-rhel-x86_64-server-6 test-rhn-tools-rhel-x86_64-server-6 -l dev-rhel-x86_64-server-supplementary-6 test-rhel-x86_64-server-supplementary-6 -d `date +%F` -u MyOrg-admin
Note here that we don't have to remove Amanda since the dev channel doesn't have it. That's why we aren't using upstream bases further down the chain.
That's a lot to recall every time we need to clone a new channel, so we'll create a config file that has all that info. Spacewalk-clone-by-date will kick you a sample if you pass the -m option, but here's one that will work for the dev channel:
{
"username":"demo-admin",
"assumeyes":true,
"skip_depsolve":false,
"security_only":false,
"blacklist": {
},
"removelist": {
"ALL":["amanda.*"]
},
"channels":[
{
"rhel-x86_64-server-6":"adev-rhel-x86_64-server-6",
"rhel-x86_64-server-ha-6":"adev-rhel-x86_64-server-ha-6",
"rhel-x86_64-server-supplementary-6":"adev-rhel-x86_64-server-supplementary-6",
"rhn-tools-rhel-x86_64-server-6":"adev-rhn-tools-rhel-x86_64-server-6"
}
]
}
To use this config file, save it as something like dev_config, and our command line will now look like:
# spacewalk-clone-by-date -d 2011-12-06 -c ~/dev_config
Create a new config for every channel, or if you are updating multiple channels at once, you can add a new channel block section between the brackets.
At this point, it's "wash, rinse, repeat." Prod gets built from test in the same fashion. If you need a more updated version for app servers vs. database servers, don't restrict to specific dates of releases. You could automate the initial push with a weekly cronjob. You could investigate blacklisting to prevent updates of particular packages, say pegging a specific python release.
You can use the GUI to push updates to channels as well, so you can add specific errata to the dev channel before it's stamped approved, or to prod to fix critical security issues.
There's a community script, spacewalk-manage-channel-lifecycle, that may provide a different starting point to do much the same set of work. It uses the APIs to manage channels along the same lines and could be a good entry to expanding your use of the APIs.
*This is a hypothetical scenario, not picking on Amanda
Related Blog Posts
