FANTASTIC INFO!!!! I cannot thank you enough for the help. The suggestion for managing the channels makes total sense and is a great idea I'm sold.
On Fri, Jan 13, 2012 at 5:31 PM, Mark Watts <[email protected]> wrote: > 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 _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
