On 13/01/2012 18:23, Christopher J Petrolino wrote:
Hello list,
Hi!
I am new to Spacewalk and while it seems like a fantastic tool I am
struggling with a few basic concepts. I have done a fair amount of
reading and I still seem to be hitting a brick wall so I am hoping
someone can at least point me in the right direction.
Question one - I have setup the common channels using the common
channels script in the spacewalk-utils package. More specifically I
have setup the common Channels for Centos 5. My question is what is
the 'correct way' to handle minor releases? In other words if I
understand the setup properly I have created channels for Centos 5.0,
now I want to add Centos 5.7. I'm a little confused as to what the
'right way to do this is'.
One limitation you'll run into when you start adding 3rd party repos
(EPEL etc) is that you can't have one child channel added to multiple
parents; you can't have one EPEL channel added to both EL5.6 and EL5.7
parent channels if you had two parent channels.
The only way to do this is via cloning channels, which gets messy.
Also, when you create a separate parent channel for each point release,
if you subscribe a system to another base channel (for a new point
release), it'll unsubscribe from all the child channels too.
This isn't that much of a problem, but it does add some extra steps to
the procedure and gets frustrating when you need to keep track of which
repos a given system was subscribed to before made the change.
The way round both of these is to have one parent channel for each major
release but not put any packages in it, then have point release and
updates child channels which sync with the appropriate point release URL
tree (ie: not the /5/ symlinked URL), along with other channels for 3rd
party repos.
Moving to new point release is a much shorter process which happens in
one go. The Change Channel Membership page allows you to unsubscribe
from one channel, and subscribe to another in one go without affecting
other channels.
Eg:
CentOS 5 (i386)
|- CentOS 5.6 (i386)
|- CentOS 5.6 (i386) - Updates
|- CentOS 5.7 (i386)
|- CentOS 5.7 (i386) - Updates
|- EPEL for EL 5 (i386)
CentOS 6 (i386)
|- CentOS 6.1 (i386)
|- CentOS 6.1 (i386) - Updates
|- CentOS 6.2 (i386)
|- CentOS 6.2 (i386) - Updates
|- EPEL for EL 6 (i386)
and so on...
You can, or course, just use one set of channels for each major release
and sync with the /5/ repo. This does cause headaches if you want to
remove old packages though since its harder to work out which packages
are from which point release. If you use the method above, its easy to
delete the old channels.
Finally there's the CR (Continuous Release) repository which adds
another way to skin the proverbial cat. Personally I only use this when
we're waiting for a new point release.
Question two - I want to make spacewalk aware of my various Cent
installs on my network and make those installs aware of spacewalk. If
I understand correctly I first install the Spacewalk client and then
use the 'rhnreg_ks' command to accomplish this. Am I understanding
this correctly?
I use cobbler, with its DNS and DHCP management turned on, along with
kickstart profiles (and activation keys) to provision most of my
servers. For those that existed before I setup Spacewalk, I've written a
script which I run on that server which does the following:
- Adds (temporarily) a small yum repo which contains the bare minimum
set of RPM's I need to install the Spacewalk client utilities, rhnrek_ks
being the main one, then installs those packages.
This repo is created by copying the relevant RPM's to
/var/www/html/pub/<repo>/ on the Spacewalk server itself, then running
createrepo on it.
- Remove/disable all existing yum repositories (I actually remove the
contents of the .repo files so they don't get removed by an update to
the centos-release RPM). Doing this stops yum from looking at Internet
sources which defeats the point of using Spacewalk imho.
- Import the RPM GPG signing keys for the repositories I'm going to
subscribe the system to. These would usually get added as part of the
kickstart; Spacewalk can't do this after install.
- Perform an rhnreg_ks against an suitable activation key. This
registers the system against Spacewalk and the activation key dictates
what base/child channels the system is registered to. Configuration
files get deployed as well (ntp.conf and so on) at this point and
initial group membership happens via the activation key too.
Once the script has completed, the system should appear in Spacewalk,
ready for management.
Typically I'll do a "yum update" at this point.
Forgive the very basic questions but I am just not quite getting it
for some reason.
Spacewalk does do things in a funky way sometimes, but on the whole its
great.
Hope my comments help shed some light on things :)
Mark.
P.S. If you want a copy of the script, just shout - I'll dig it out when
I'm back at work on Monday.
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
