<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Am looking for suggestions for how to manage RHEL5 kernel updates with Spacewalk.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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. <o:p></o:p> <o:p> </o:p> 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. <o:p></o:p> <o:p> </o:p> <![if !supportLists]>1) <![endif]>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. <o:p></o:p> <o:p> </o:p> <![if !supportLists]>2) <![endif]>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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Thx<o:p></o:p> Chris.<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Chris Snyder<o:p></o:p> SRA Senior Linux Geek Energystar Network O+M Team ESTAR Issues: <a href="https://estar18.energystar.gov/">https://estar18.energystar.gov/</a><o:p></o:p> <o:p> </o:p> </div> </body> </html>