On Mon, 09 Jan 2012 14:47:03 -0400, francis picabia wrote: > On Sat, Jan 7, 2012 at 7:20 AM, Camaleón <noela...@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 -- 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/jehonh$r4p$9...@dough.gmane.org
