Re: Sun Solaris login bug patches out

From: Viraj Alankar (valankar@ifxcorp.com)
Date: 01/02/02


Date: Wed, 2 Jan 2002 11:48:58 -0500
From: Viraj Alankar <valankar@ifxcorp.com>
To: focus-sun@securityfocus.com

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 <200112242238.fBOMcka01006@marathon.verancecorp.com>, "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
possible.

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

Viraj.



Relevant Pages

  • Windows XP home edition
    ... >Can you access safe mode via the BIOS? ... >To prevent resets interupting the downloading of patches ... >Turn off Automatic Reboot, if you haven't already. ... >virus forum.Even if you elect to reformat,please report ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Patch your damn computers already!!!
    ... >libssl, etc.), as well as all kernel patches. ... >requires console access; a remote reboot doesn't. ... > Bill> time is critical for the clients. ... and the client had about 1200 domains spread over 2 systems. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: WSUS/Reboot
    ... > service and bouncing the entire box. ... Ever have a box reboot with an error ... > notice is immediate application of patches that don't need reboots. ... > systems is to drop the service in question, apply patches and restart ...
    (Focus-Microsoft)
  • Re: Sun Solaris login bug patches out
    ... Sometimes the patches are not needed, ... don't require a reboot after installation. ... if you have to wait for the regular scheduled time to install ... an important patch, that may make matters worse also -- being a slave to ...
    (Focus-SUN)
  • Re: Patch your damn computers already!!!
    ... Bill> to reboot the system. ... I usually reboot for all core library updates (e.g., libc, libm, ... libssl, etc.), as well as all kernel patches. ... Bill> time is critical for the clients. ...
    (comp.unix.bsd.freebsd.misc)