[Spacewalk-list] looking for kernel mangement recommendations

Thu Dec 20 12:02:07 UTC 2012

I used to do patch management at a big hosting company (all this was with Satellite 5.3 , I'm assuming things like this haven't changed since), where we had 4 system levels (DEV, TEST, ACCEPTANCE and PROD) each with their own schedules.

What I did was

- Make a structure with parent + child channels
- Clone these for each system level
- Subscribe the system to the level applicable
- Now when patch day for a level is up, do a sync from the master channel to the clone channel for that level (either an automatic full or a manual package-by-package, in which case you can hold back whatever you want)
- Apply all updates to the systems for that level

This has the added advantage that systems will always show as fully patched in your system status tab
--
Jan-Albert van Ree

[cid:imaged07af5.JPG at f14ef2f4.4ebba3c2][cid:imaged0de05.JPG at 9ddf42d2.4f8ad5ed]

Jan-Albert van Ree

Linux System Administrator

MSuG MARIN Support Group

MARIN

        2, Haagsteeg

E J.A.v.Ree at marin.nl<mailto:J.A.v.Ree at marin.nl> P.O. Box 28     T +31 317 49 39 11
M +31652598885  6700 AA Wageningen
T  +31 317 49 35 48     The Netherlands I  www.marin.nl<http://www.marin.nl>

MARIN news: Annual student design & sailing contest<http://www.marin.nl/web/News/News-items/Annual-student-design-sailing-contest.htm>

This e-mail may be confidential, privileged and/or protected by copyright. If you are not the intended recipient, you should return it to the sender immediately and delete your copy from your system.

________________________________
From: spacewalk-list-bounces at redhat.com [spacewalk-list-bounces at redhat.com] on behalf of Snyder, Chris [Chris_Snyder at sra.com]
Sent: Wednesday, December 19, 2012 21:47
To: Spacewalk-list at redhat.com
Subject: [Spacewalk-list] looking for kernel mangement recommendations

Am looking for suggestions for how to manage RHEL5 kernel updates with Spacewalk.

My team has a small set of REHL5 hosts (<30) that we’ve been simply managing updates via our own local internal repos and manual execution of yum when needed. Our internal repos are generated via mrepo and consist of all updates provided by the RHN upstream, selected packages from EPEL, RPMforge, etc. and some of our own in-house created RPMs.   So far this has worked well for us.

Additionally, our business requirements have us applying all pertinent, NON-KERNEL updates once a month to all hosts.  Kernels may  only be updated once a quarter.  We control this via a custom /etc/yum.conf on each host which defines and exclusion of ‘kernel*’.  This means that to update kernel packages on a host, yum must be explicitly run with the argument ‘—disableexcludes=all’.   Again, this has worked well for us; kernels are not applied when they shouldn’t be.

We are now looking to move to Spacewalk for a more centralized package management solution.  I’ve already created one channel per repository in our mrepo setup, loaded all the packages into Spacewealk, and have registered all the hosts with those software channels.  Packages can be installed and updated on all the hosts either through the Spacewalk GUI or yum on the hosts.

Life is good so far, but I’m not sure how best to manage our kernel vs non-kernel updates on our hosts.   I’d really like some recommendations on how best to accomplish this. As I see it, two options immediately come to my mind.

1)      Leave my custom yum.conf with an exclusion for ‘kernel*’ packages on each host. I know that when packages are pushed via the Spacewalk GUI, the yum libraries are used to actually do the package installs/updates so that my defined exclusions in yum.conf will still be honored. Then I can push as many packages from the Spacewalk GUI without ever worrying if I’m pushing a kernel package or not.  However, to actually install/update kernel packages on the hosts, a human would actually have to run ‘yum –disableexclude=all’ on the host or through the remote command function of the Spacewalk GUI.  This seems the safest option, but it would mean that we are going to do a more ‘manual’ update process once a quarter for the kernel updates.

2)      Replace the custom yum.conf with a stock yum.conf and when packages are to be pushed via the Spacewalk GUI, simply have as part of the our standard operating procedures that whoever is pushing packages, they have to ensure that no kernel packages are to be pushed.   While this would be a better solution from the aspect of being able to push any package I want from the Spacewalk GUI, but this one would require people to pay close attention to what packages they are pushing at any time, and mistakes do happen and I wouldn’t be surprised if the occasional kernel package was updated when it shouldn’t be.  This is not my preferred solution.

I’m sure there’s something that could be done with cloning channels, but I admit, I haven’t investigated this much, it seems that this would be a very ugly solution as it would probably involve having to clone our core RHEL channel (minus any kernel updates) once a month, then update all hosts to use the cloned RHEL channel, or something like that.  This just feels like  it’s the wrong direction and would involve lots of effort and potentially raise risk of something going very wrong.  But, I’m open to any and all suggestions how you would handle this.

Thx
Chris.

--
Chris Snyder
SRA Senior Linux Geek
Energystar Network O+M Team
ESTAR Issues: https://estar18.energystar.gov/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20121220/cf3a8ed1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imaged07af5.JPG
Type: image/jpeg
Size: 1069 bytes
Desc: imaged07af5.JPG
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20121220/cf3a8ed1/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imaged0de05.JPG
Type: image/jpeg
Size: 1622 bytes
Desc: imaged0de05.JPG
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20121220/cf3a8ed1/attachment-0001.jpe>