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

Re: Lenny (Debian 5.0) approaching end of life

On Mon, 09 Jan 2012 14:47:03 -0400, francis picabia wrote:

> On Sat, Jan 7, 2012 at 7:20 AM, Camaleón <noelamac@gmail.com> wrote:


>>> disturbances?
>>> Have you upgraded a Debian from old->new stable before?
>> (...)
>> Nope, never ever. In Spanish I would say "jamás de los jamases" :-)
>> In do run in place upgrades on my testing computers that now runs on a
>> perpetual Debian "testing" but on production systems I would never do a
>> distribution upgrade and not because is not going to work (I know
>> Debian has one of the best in site upgrades available in linux with the
>> plus of release notes which help a lot to minimize the risks) but I'm a
>> very conservative sysadmin and one of my mottos is "always keep a
>> running system" so overwriting something that is working is something
>> that the mere thought gives me gooseflesh.
>> Of course, I can do this way because I don't have thousand machines to
>> administer not have to remotely access to them, in such case I would
>> reconsider the in place upgrade path :-)
> We run about 5 servers with Debian which have been upgraded in place,
> from Lenny to Squeeze.  A couple started life as Debian 3.0 and have
> been upgraded a version a few times.  The services offered from these
> servers varies.  One is an INN news server. One is our DHCP/DNS server
> for a network with up to 5000 nodes on it.  Another 3 servers provide
> web sites and programming platforms.
> We upgrade in place because it works, and because we can't afford to buy
> a new server for every OS life cycle.


Nice to know the upgrade path (instead a full pararel install) does the 
work for you. I understand every sysadmin has developed his/her own 
maintenance techniques and sticks to those that have been working for his/
her setups over the years.

> The issues with services breaking can be mitigated by testing on a VM
> instance with your usual configuration in advance. For example, I tested
> our DHCP config and DNS config on a VM system with squeeze versions of
> bind and ISC DHCP.

I personally don't like using VM for this purpose because they don't 
provide reliable results (what usually fails when upgrading from a older 
version to another are hardware related problems more than problematic 
services). In the end, software issues are usually easier to solve than  
hardware compatibility problems (like buggy drivers).

> The other part we can take advantage of is to do the upgrade work
> between busy cycles, and for us that means when students are away. The
> downtime for my last upgrade, of the DNS/DHCP was about 30 minutes,
> mainly due to the requirement of fiddling around with kernel needs (the
> rootdelay=9 issue I mention in another thread).

I also try to reduce the downtime for the installation of a new release 
by performing the migration on holidays or over the weekends when users 
are not at the office.

> The other thing I try to do, keeping in mind Camaleón's mentioning of
> conservative practises, is to have a fall back plan for anything
> important.  Websites can be migrated to another system temporarily
> during an upgrade.  I can set up secondary DNS and have another system
> ready to start with a copy of our DHCP config.  In the case of a service
> like INN, no one would notice if it is down for awhile, and people can
> live without it for some time if needed.

That would be great but I don't have secondary machines for balancing all 
of the services (I wish I had!) so this is not always possible :-)

> I feel my practises are also conservative, but in the direction of
> keeping prepared for a zero day exploit.  I know Debian is quick to
> patch security problems, but I can't be ready to do so with an
> unsupported version of Debian.  Patching the problem may also be
> possible outside of the Debian packages, but if I need to act quickly on
> several systems and it is time consuming to determine what chain of
> dependencies may need updates, I'd prefer to avoid downtime caused by
> flawed emergency patching methods.


Yup, running an unsupported (unpattched) system is a high risk, even more 
if it is providing external services (web hosting, e-mail...) :-(



Reply to: