Matthew 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
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
