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...) :-(
Greetings,
--
Camaleón
Reply to: