Re: Lenny (Debian 5.0) approaching end of life
On Sat, Jan 7, 2012 at 7:20 AM, Camaleón <noelamac@gmail.com> wrote:
> On Fri, 06 Jan 2012 19:33:42 -0500, Tony Baldwin wrote:
>
>> On Thu, Jan 05, 2012 at 04:36:49PM +0100, Camaleón wrote:
>
> (...)
>
>>> > Why can't you use squeeze?
>>> > --
>>> > Sent from my Android phone with GMX Mail. Please excuse my brevity.
>>>
>>> Indeed, I do can, but I prefer to accomodate the span-life of the next
>>> installation round to match the longest support cycle possible with the
>>> less disturbances for me (admin) and my users :-)
>>>
>>>
>> 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.
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.
We did have a couple of little surprises, like the path to the dhcp
leases changing (impacts NetReg and dhcpstatus script).
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).
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.
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.
Upgrading to a new system is ideal, and for some complex systems
using software developed in house and third party, it is the only way
to go ahead. However, we can't always afford to buy new systems for
each OS life cycle. Especially for purely open source
based services where the upgrade path is common to the
open source user community and for which google hints abound,
an upgrade in place is a good fit.
Reply to: