SLUG Mailing List ArchivesSLUG Mailing List ArchivesMatthew Hannigan wrote:
On Mon, May 23, 2005 at 07:02:24PM +1000, Rick Welykochy wrote:Matthew Hannigan wrote:If you did 'yum update ' regularly (every day, at the very least)) you most likely would not have been hit by this exploit. That is the best way/ path of least pain.Is it? In a production environment?My short answer would be *especially* in a production environment, if production means 'being exposed to the internet'. A fuller answer depends what you perceive the risks are and what other steps you took to protect yourself. If you're running an integrity checker, selinux, chrooted apache, no-exec stack, some lesser known architecture, blah blah blah, you could afford to give yourself a little more time to try out updates on a test/qa server for compatibility first. Were you thinking of compatibility concerns or security of vendor updates? If the latter, well, you either trust them or not really. Fedora/Redhat gpg sign their updates; you should enable that checking at least.
Compatibility concerns. The spectre of a security update introducing more insecurity is rare in my experience. But updates have screwed things up: RH and libc(?) probs years ago, Apple OS X update trounced on dual-boot Linux awhile back, Win XP SP2 broke compatibility with certain apps (apparently with good reason). The basic rule in production (i.e. a service being offered to public/ customers / clients) is to test before deploying changes. There are often too many components and interconnected cross-relationships that have never been tested in *your* specific configuration to have been adequately tested by the update provider. Methinks that blindly accepting updates or auto-updating sans testing can lead to unexpected delights and late nights scratching head at console. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services "I drank what?" - Socrates, 399 BC