[Tfug] Machine Rehabilitation

[Claude Rubinson]

On Fri, Jul 20, 2007 at 04:33:44PM -0700, Andrew Ayre wrote:
> Claude Rubinson wrote:
> > Here's the thing.  Once you install, you simply stop worrying about it.
> > Having pointed your sources.list to ../debian stable main, the next
> > time that a stable version is released, your system will be seamlessly
> > upgraded.  No muss, no fuss, and no worrying about your system no
> > longer being supported.  Granted, it's a very different way of
> > thinking about it but in the end it means that you stop worrying about
> > your operating system and just focus on your work.
> > 
> > Rick Moen has a nice discussion of the concept of releases in Debian
> > over at http://linuxmafia.com/faq/Debian/releases-unimportant.html
> > 
> > Hope this helps,
> > 
> > Claude
> 
> Hi Claude,
> 
> Please bear with me while I try to understand how this works. I think I
> am misunderstanding something important.

I'm not the best person to answer these questions as I'm only doing
minimal admin on a couple of personal systems at this point but I'll
pass along what I recall.

> 
> We have a server in a farm that uses Sarge. We just upgraded it to Etch
> and it was a significant ordeal. Here are all the upgrade steps involved:
> 
> http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html
> 
> During the upgrade we were faced with a lot of decisions, mainly about
> configuration files, but it seems some applications, like Courier for
> example, changed the way they are structured.

That does happen but, in general, Debian devs do a pretty good job of
letting you retain your old settings and warning you if some form of
breakage will occur.  But, it is true that if you're not used to the
system, all the questions about what to do when the package has a new
version of a conf file can be a bit overwhelming.

Regarding the configuration settings, if it was asking questions that
you didn't need to answer, could it be that you had your debconf
priority level set higher than needed?

> The result was that our email system, subversion and apache all broke.
> When we rebooted the server grub didn't point to the new kernel so we
> had to use the emergency TTY interface to get it running again.

I don't recall hearing about regular problems upgrading apache from
sarge to etch but I don't pay much attention to the upgrade issues, so
I may have missed it.

The grub problem seems especially odd, assuming that you hadn't
substantially messed with the grub menu.  I recall that I had some
problems when I switched over from lilo to grub, but it sounds like
you were previously using grub.

One thing to make sure that you do when you do a major upgrade on a
Debian system is to keep it piecemeal as much as possible.  So before
doing anything else, you want to make sure that your system is up to
date on the old release.  Then, point your sources to the new release,
update, then upgrade.  The upgrade will upgrade only those packages
that won't break anything.  Then and only then do you do a
dist-upgrade.  (In the latest versions of aptitude, I believe that
they've renamed these to "safe-upgrade" and "full-upgrade" or
something like that; the legacy terms still work though.)

> So far from stopping worrying about it my colleague has now set
> sources.list to point to etch, not stable. This means that eventually we
> will become out of date again.

That should be fine.  Just make sure that you've also got the security
repos in your sources.list, so that you're getting all of the security
updates as quickly as possible.

> His argument is that if we let the repo change "behind our back"
> then when we go to upgrade something someday we will be suddenly
> faced with 100s of upgrades of dependencies, breaking of
> configuration files, etc.  He would prefer to install new software
> only from backports because it is a less drastic change.

Possibly.  There's always a question about whether pulling from
backports or maintaining a mixed-release system is the better
solution.  And the answer depends upon your specific circumstances.

>From what I've seen, conservative people who absolutely need to
guarantee uptime prefer backports because it does tend to be more
stable.  But release upgrades become more of a hassle because you've
got a bunch of software that's noting being pulled from Debian
proper.  (In a sense, it makes Debian a bit more like RedHat where
you've got packages from a bunch of different repos.)

A mixed stable/testing (or testing/unstable) system, on the other
hand, keeps you within Debian proper and gives you access to more
up-to-date software but can be a bit more unstable.  Also, if you pull
a newer package that has a lot of dependencies, it'll need to upgrade
all of those dependencies.  So, there's a tendency for mixed systems
to want to shift toward the more unstable stream.

The solution is judicious use of apt's pinning mechanism.  The pinning
mechanism is something that still seems to be undervalued (I don't use
it nearly enough myself).  Essentially, it permits you to include any
repos in your sources.list and specify the conditions under which you
wish to permit software upgrades.  So, if you need/want a specific
version of subversion, you specify that and apt won't allow anything
to happened that would disrupt that.  On the other hand, you can
specify the conditions under which you would permit an upgrade to
occur.

Come to think of it, this is another way that you could upgrade
piecemeal, although I haven't heard of the mechanism being used in
this way.  But, basically, you would add the new repos to your
sources.list and only upgrade what you felt was safe/necessary, until
you were ready for the more volatile upgrades.

Speaking of which, also make sure to include the volatile repos as
well as security for your Etch systems.  Volatile houses fast moving
targets such a spam filtering data patterns, etc.

> 
> It's hard for me to argue against this because of the hassle we went
> through upgrading from Sarge to Etch.

I'm sorry to hear that you had so much difficulty in upgrading your
system.  Do you have enough detailed information to send some bug
reports into Debian.  They should know when a problem like this
occurs.

> So from our point of view right now the Debian system doesn't seem
> to remove upgrade hassles.

In a lot of ways, the issue comes down to when do you want to deal
with upgrade tasks.  On my laptop, for example, I track the testing
branch (well, mostly; I think that I've got a few things pinned to
stable and pretty sure that some pulled from unstable--but, see?,
that's the point, I set it once and then don't have to really think
about it again).  In any case, since packages are upgraded under
testing fairly frequently, I upgrade my system on a daily basis as
part of my
"I've-just-come-into-the-office-and-won't-do-any-real-work-for-the-first-hour-or-so"
routine and deal with any admin tasks at that time.

I place greater value on the stability of my server, however, so it,
on the other hand, simply tracks stable and gets security updates as
necessary.  Whenever I upgrade the server to the next stable release,
I'll have to deal with any configuration changes at that time.  It
shouldn't be much of a hassle, as my server is pretty stripped down
and has very few customizations but, still, there will certainly be
issues to deal with and address.  The nice thing is that I get to
choose when and where to deal with any upgrade hassles that do arise.
(And, if I really want to put things off, the old-stable release will
exist for some time.)

Debian really kind of is a beast of its own.  There are some things
that I don't like about it (in particular, as I've previously
mentioned to others, I don't care for the new emphasis on abstracting
functions.  There just appears to be greater and greater levels on
indirection in the Debian system, which I find to be more confusing
than helpful).  On the other hand, I've been with Debian so long now
that whenever I do consider moving to a new distro, I find them all to
be confusing, foreign, and scary.

Perhaps this is (partly) why Ubuntu has gained such rapid mindshare.
It's built on the very flexible Debian base but looks more like a
traditional release, giving it, for many people, the best of both
worlds.

Again, I'm not the best person to be addressing your issues and
concerns as I'm not seriously admining any machines.  But this is how
I see and admin my own.

Claude