Re: Sun Solaris login bug patches out

From: Viraj Alankar (
Date: 01/02/02

Date: Wed, 2 Jan 2002 11:48:58 -0500
From: Viraj Alankar <>

On Sun, Dec 30, 2001 at 08:16:17AM -0800, John Nemeth wrote:
> On May 19, 9:00am, Cy Schubert - ITSD Open Systems Group wrote:
> } In message <>, "Mike
> } D. Kail" writes:
> } >
> } > i, personally, am of the 'anti-M$' mentality that one shouldn't reboot a
> } > unix box ``just because''.
> }
> } That doesn't make any sense at all. A UNIX box with a high uptime is
> } indicative of that box not being maintained with the latest security
> If we were talking about L* boxes then I would agree. However, we
> aren't. Security patches for the kernel and libc are few and far
> between on most versions of UNIX. Heck, ignoring that festering pit
> known as CDE which shouldn't be running on servers anyways, security
> patches of any kind only show up every few months. And, of course, if
> it is a patch for a service that you don't run, then you don't need to
> worry about it. With the exception of kernel and libc patches, there
> is rarely any need to reboot. I like being able to do 99% of my
> maintenance on 24x7 production servers without having to make them
> unavailable. A machine with a long uptime often is indicative of a
> highly capable administrator (or, the machine doesn't do anything).

I agree to an extent but I many times look at rebooting as a safety
precaution. For example if I make some configuration changes (adding
interfaces, patches, etc), I like to be sure that upon reboot everything comes
up properly and the machine is in the same state as it was before the reboot.

In my situation, it is not unlikely that something goes wrong late at night
(hardware failure, etc), and I don't want other things to crop up when
diagnosing such an issue and a machine is rebooted. I need to be sure that a
reboot results (or at least tries to result) in the same state.

Another reason is certain patches may enable (or disable) services after they
are applied, make certain filesystem changes that only show a problem after a
reboot, etc. When you are rebooting a machine a year after you've made some
changes, it's difficult to pinpoint what happened in the past year that may be
causing a problem now.

Yes, in 24x7 shops it is sometimes impossible to do this frequently, however
just because of the above reasons I prefer scheduling a little downtime after
the changes rather than an unexpected longer downtime later if at all

So to me it is more safety precaution than anything else.