[Spacewalk-list] New to spacewalk

[Christopher J Petrolino]

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 <m.watts at linux-corner.info> 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
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list