I'm also curious about the PSP since we use it heavily in our
infrastructure.
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 15:32, Musayev, Ilya wrote:
Jerry
Thanks for the feedback. Speaking of HP PSP which it looks like you
are using (im assuming and could be wrong), are you running full
blown PSP and is that only issue you noticed? I was told that Ksplice
ignores 3rd party modules and they should remain unaffected.
Interested to know what happens as im still debating if i should
install psp on linux servers. The reason for us to avoid PSP is
mostly support based, I'd rather goto Redhat for support than HP.
Come to think about it, i feel a bit more confident just running
ksplice and never upgrading the underlying kernel, this way, if any
issue arrise, ksplice remove all that is needed and no reboot.
Ilya Musayev Sr. Systems Engineer | WebMD
On Dec 14, 2010, at 4:12 PM, "Jerry"<[email protected]> wrote:
I have> 500 machines under my control, about 445 of them are
connected to uptrack (rhel 4& 5). We used ksplice to block a few
root exploits before we had a chance to reboot machines. Since we
are still testing we rolled out the new kernel anyway but I've run
for weeks ksplice'd without a problem. The only problem I did run
into was when applying a specific splice relating to 32-bit I had
to stop some processes. HP's modified IPMI seems to cause some
problems as well. All other updates seemed to go fine and once we
passed the kernel that included those fixes we didn't have that
issue applying new updates.
As far as vulnerability reporting we're working with the ksplice
API (a restful interface) and our local security team to mark
nessus vulnerabilities as null based on CVE numbers. I'd love to
have nessus or other tools just realize a box is kspliced, but you
can work around this by mapping in CVE numbers to nessus
vulnerabilities since ksplice is telling you which CVEs they are
repairing. This would require some local tool that is producing
audit reports that could be modified, homegrown or otherwise.
From a stability standpoint, given the price it's almost
ridiculous this product isn't an option when you buy Red Hat or
other distro's. It's like forgetting to check off "sport tires"
when you bought that sports car.
It's also valuable as an insurance plan running in a mode where
I've got no splices because I can sleep better knowing even if I
ignore most of the CVEs, that reaaaaly bad one can be avoided with
a massive script pretty quickly. And you can un splice something
too, and yes it works. It even works on a VERY busy system.
Hope this helps. p.s. some of my systems have 50+ splices applied
right now.
_______________________________________________ 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
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
