Thanks for the feedback, Doc.
As for your note about the 'uname' issue -- we were considering wrapping
'uname' with a script that uses the kSplice API to query the effective
kernel version. It would not be as effective as having the actual
uname() system call return the effective version, but in our case it
would satisfy our auditing tool, which runs in userland as a script (and
thus doesn't make uname() system calls directly).
Have you had any experience with the kSplice API?
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 13:31, Robert G. (Doc) Savage wrote:
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
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
