[Spacewalk-list] New to spacewalk

[Mark Watts]

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.