Re: tinydns/djbdns opinion poll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, Feb 12, 2009, Les Mikesell wrote:
>Bill Campbell wrote:
>>
>>>> That sounds like the kiss of death for any critical service.  Can't it 
>>>> figure out ahead of time that this is going to happen and let the 
>>>> service keep running unchanged with a warning message about needing the 
>>>> update instead?
>>> You're missing the point.  If the service is already running, the
>>> changes won't take effect until you restart the service with the new
>>> binaries. And the whole patching exercise is what maintenance windows
>>> are for, anyway.  Note that it's critical SERVICE, not critical SERVER.
>>> The former is more important than the latter, so ideally you should be
>>> able to take down the latter in order to upgrade one implementation of
>>> the former.
>> 
>> I understand the distinction very well.  In the time we have been using
>> this method, we have never taken down a service for any significant period
>> of time (the services are restarted on installation by the RPM SPEC files'
>> %pre, %post processing).
>> 
>> Of course we don't do things that are likely to take a critical service
>> down without proper prior planning (often found out the hard way on our own
>> systems :-).  If an update is likely to have an impact on operations, it is
>> scheduled during a maintenance window.
>
>In other words you'd dedicated sufficient human resources to undo 
>whatever damage the package management system causes...

Isn't that what our customers are paying us to do?

That has to be true now matter how one is doing updates.

I have personally updated clamav on more than 50 machines in an afternoon
without having any of them down for more than a minute, and that time
mostly because clamav takes a while to restart.

FWIW, we normally have clamav updates installed at all our client sites
with 24 hours of the first notice that there's a new version out from
swatch looking at the freshclamav.log file.  This includes downloading the
new tarball, updating the OpenPKG SRPM, building, testing in-house, and
deployment.  Often this is complete before people on this CentOS list start
asking questions about the update or saying it won't build.

Oh, and these updates are on a variety of Linux systems ranging from SuSE
9.0 Pro, SLES9, SLES10, CentOS 4.5 through CentOS 5.x, and at least one
FreeBSD box -- all from the same SRPM file.

Bill
-- 
INTERNET:   bill@xxxxxxxxxxxxx  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186

It will be of little avail to the people that the laws are made by men of
their own choice if the laws be so voluminous that they cannot be read, or
so incoherent that they cannot be understood.
    -James Madison, Federalist Paper #62
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux