On Tue, 2010-12-14 at 12:33 -0600, Paul Krizak wrote: > We're looking at it in our environment too. Very interested in any > experience good/bad. > > > Paul Krizak 7171 Southwest Pkwy MS B200.3A > MTS Systems Engineer Austin, TX 78735 > Advanced Micro Devices Desk: (512) 602-8775 > Linux/Unix Systems Engineering Cell: (512) 791-0686 > Global IT Infrastructure Fax: (512) 602-0468 > > On 12/14/10 12:05, Musayev, Ilya wrote: > > We are considering ksplice (rebootless kernel update) in production. > > We are looking for a non-biased real world examples. Does anyone use > > it in their environment for prod or non prod? What issues have you > > experienced if any? Any suggestions? Your feedback is appreciated.
Paul / Ilya, I've been testing Ksplice for a couple of months on Fedora 13 and 14 machines. It just works pretty much as advertised. You get access to a repo at ksplice.com and a toolbar icon that alerts you when an update is available. It will apply on-the-fly patches to a running kernel to correct designated problems. If you have to reboot, any previously applied patches will be automatically re-applied with no manual intervention required. The only "gotcha" about using ksplice is that there aren't any "ksplice-aware" auditing tools available yet. Applying a ksplice patch is not the same as installing a new rpm. It doesn't add anything to /boot, update your rpm or yum databases, nor does the new patch version show up with 'uname'. So, if your security auditing software relies on the rpm database and uname, it will continue to show your kernel at a prior (and vulnerable) version number. To bridge that gap, you're going to have to apply Red Hat's update rpms and schedule a reboot sometime. Thus in practice you won't be able to achieve 100.000000% uptime using ksplice. --Doc Savage Fairview Heights, IL _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
