On Sat, Jan 7, 2012 at 7:20 AM, Camaleón <noela...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+AKB6Ef0W3CtrWXrur2KxEczM5pmaD7mFN2KAYoZ=psxv0...@mail.gmail.com
