[OpenIndiana-discuss] 3737 days of uptime

[Ben Taylor]

Patching is a bit of arcane art.  Some environments don't have
test/acceptance/pre-prod with similar hardware and configurations, so
minimizing impact is understandable, which means patching only what is
necessary.

I prefer to patch everything when I build, or in environments where I have
test/acceptance/pre-prod as it minimizes issues that I may not know
exists.  It also has the benefit of putting Oracle support in the seat of
not being able to run their explorer analysis tool which always says "your
patches are out of date".  My usual response is "that's good, I got a tool
like that too, and I didn't need you to tell me that".  I had one
experience with a new build, and a network problem, and engineer tells me
my patches are out of date?"   I replied  "Oh, really, What does sed, awk,
and Xvnc have to do with my network problem.?"  guy on the phone mumbles
"uhhh. uhhh.. uhhh."     I told him I also had a patch tool to inform me
what the status of my patches were, and I was pretty sure that none of
those patches had anything to do with my network problem.  Ticket was soon
moved to someone who did more than just run an explorer through a tool.

Ben


On Fri, Apr 5, 2013 at 7:49 PM, David Brodbeck <brodbd at uw.edu> wrote:

> On Wed, Mar 20, 2013 at 4:32 AM, Edward Ned Harvey (openindiana) <
> openindiana at nedharvey.com> wrote:
>
> > It would only bring a tear to my eye, because of how foolishly
> > irresponsible that is.  3737 days of uptime means 10 years of never
> > applying security patches and bugfixes.  Whenever people are proud of a
> > really long uptime, it's a sign of a bad sysadmin.
> >
>
> Depends on the environment it's running in. It might be a closed,
> air-gapped network, for example -- those still exist, especially in
> industrial settings.  In those cases taking the risk of patching a system
> that's not at risk and has been running well would be the irresponsible
> thing to do.  Frankly, on a server that old, powering it down will probably
> destroy it -- a hard disk that's been spinning that long is unlikely to
> spin up again once stopped.
>
> I tend not to blindly patch my production machines, especially during the
> academic term when it might be disruptive to students and to running
> research jobs.  I generally go through the update list and pick and choose
> stuff that is a risk to my installation -- for example, on a file server, I
> might patch Samba but ignore X, because it has no local users and will
> never be running an X server.  Kernel updates for security problems in
> drivers for devices I don't own are another area I ignore.
>
> Generally there has to be a security hole in the kernel that can be used to
> escalate privileges before I'll do a reboot mid-term. This is especially
> true of the Linux kernel, where new kernel versions often bring unexpected
> regressions.
>
>
> --
> David Brodbeck
> System Administrator, Linguistics
> University of Washington
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>