[sf-lug] Linux Server Preferences
Rick Moen
rick at linuxmafia.com
Thu Nov 5 18:16:49 PST 2009
Quoting jim (jim at well.com):
> i use ubuntu server on a 1U supermicro.
> main reason is support/cost ratio: better
> than centOS or Red Hat. people with good
> skills, as a group, seem to prefer the debian
> flavor.
I'd actually like to pick your brain, on that, if you have a moment.
Some years ago, a now-long-vanished SVLUG vice-president decided to use,
for the replacement Web server site, a Linode virtual-machine image of
Ubuntu Server. I think it was an image of 5.04 Hoary Hedgehog at the
time. He did this without consulting with anyone -- and, in the
time-honoured fashion of executives everywhere, then dropped out and
let other people deal with the consequences of his decisions. ;->
In particular, that system was dropped on _me_, and I was told to fit
all of SVLUG's operations -- Web site, Mailman mailing lists with almost
a decade of history, SMTP e-mail with intensive antispam, DNS
authoritative nameservice, and shell accounts -- into a 64 MB RAM
virtual machine with 3 GB hard disk. The VP breezily pronounced that it
shouldn't be a problem, shortly before dropping out of sight.
That functionality spec was, in fact, completely impossible with only 64
MB of RAM, but I sure tried. First, using NSD rather than BIND9 saved a
ton of RAM for namservice, and I can strongly recommend it for
authoritative-only roles. Second, we went with Lighttpd rather than
Apache httpd for Web service, which again saved hugely on RAM.
Shoehorning the e-mail and mailing list services into that tiny box had
to be abandoned, and split off to elsewhere. If nothing else, the RAM
required for meaningful spam-rejection was prohibitively high and would
have killed the machine, and the mailing lists' back-posting archives
alone would have accounted for all the disk space.
Initially, I had to construct my own Ubuntu-ised packages for NSD and
Lighttpd (and, if memory serves, a couple of other things such as
related libs(?)), because they didn't exist in Ubuntu. Later, some or
perhaps all of those packages (can't remember) started being built for
Ubuntu, but for a couple of years they were local packages only.
But, anyway, getting back to the point, every time Ubuntu had a release,
I had to carry out what, by _Debian_ standards, struck me as a
ludicrously manual and somewhat nerve-wracking system upgrade. That is:
# sed -i 's/hoary/breezy/' /etc/apt/sources.list
# apt-get update
# apt-get dist-upgrade
...and, maybe I'm just being paranoid, but I really held my breath,
every time, lest something crucial break -- especially when I had
substantial parts of the system as locally built packages.
On my Debian-based servers, instead of having to reference named
branches such as etch, lenny, squeeze, I can just leave the _functional_
term "testing" or "stable" or "unstable" (whichever one local policy
dictates), to remain an approximately fixed amount of rawness away from
the bleeding edge. These functional names are implemented as symlinks:
:r! lftp -e ls ftp://ftp.debian.org/debian/dists/
cd ok, cwd=/debian/dists
lrwxrwxrwx 1 1176 1176 4 Feb 09 2009 Debian4.0r8 -> etch
lrwxrwxrwx 1 1176 1176 5 Feb 14 2009 Debian5.0.3 -> lenny
-rw-r--r-- 1 1176 1176 534 Sep 04 18:54 README
drwxr-sr-x 5 1176 1176 4096 May 23 17:31 etch
drwxr-xr-x 5 1176 1176 4096 May 23 17:31 etch-m68k
drwxr-sr-x 5 1176 1176 110592 Nov 05 23:54 etch-proposed-updates
drwxr-sr-x 19 1176 1176 4096 Nov 05 23:55 experimental
drwxr-xr-x 5 1176 1176 4096 Sep 04 21:11 lenny
drwxr-xr-x 5 1176 1176 73728 Nov 05 23:54 lenny-proposed-updates
lrwxrwxrwx 1 1176 1176 4 Feb 14 2009 oldstable -> etch
lrwxrwxrwx 1 1176 1176 21 Feb 14 2009 oldstable-proposed-updates -> etch-proposed-updates
lrwxrwxrwx 1 1176 1176 22 Feb 14 2009 proposed-updates -> lenny-proposed-updates
lrwxrwxrwx 1 1176 1176 12 Aug 04 2008 rc-buggy -> experimental
drwxr-xr-x 19 1176 1176 4096 Nov 05 23:55 sid
drwxr-xr-x 17 1176 1176 4096 Nov 05 23:55 squeeze
drwxr-xr-x 5 1176 1176 4096 Nov 05 23:55 squeeze-proposed-updates
lrwxrwxrwx 1 1176 1176 5 Feb 14 2009 stable -> lenny
lrwxrwxrwx 1 1176 1176 22 Feb 14 2009 stable-proposed-updates -> lenny-proposed-updates
lrwxrwxrwx 1 1176 1176 7 Feb 14 2009 testing -> squeeze
lrwxrwxrwx 1 1176 1176 24 Feb 14 2009 testing-proposed-updates -> squeeze-proposed-updates
lrwxrwxrwx 1 1176 1176 3 Nov 10 2007 unstable -> sid
The point is, if I point my /etc/apt/sources.list entries at "stable", which
today is a symlink to lenny, then whenever squeeze gets declared the new
stable branch, my system will smoothly and transparently move from lenny
to squeeze without my having to do a manual and somewhat nerve-wracking
supervised upgrade.
I consider it less nerve-wracking because it's the job of Debian's
Release Manager to make sure that, e.g., squeeze is in really good
shape _and_ is a really smooth upgrade from the current incarnation of
lenny, and do the cutover only then -- with the result that all systems
that track "stable" in /etc/apt/sources.list make the jump at the
optimal time with good quality control. And they have a really good
track record for actually doing that -- well.
But I've never seen any such mechanism in Ubuntu:
:r! lftp -e ls ftp://ftp.ubuntu.com/ubuntu/dists/
cd ok, cwd=/ubuntu/dists
drwxr-xr-x 6 1000 1000 4096 Oct 22 05:18 dapper
drwxr-xr-x 6 1000 1000 4096 Oct 22 05:18 dapper-backports
drwxr-xr-x 6 1000 1000 4096 Oct 23 04:45 dapper-proposed
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 dapper-security
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 dapper-updates
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 hardy
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 hardy-backports
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 hardy-proposed
drwxr-xr-x 6 1000 1000 4096 Jul 17 04:41 hardy-security
drwxr-xr-x 6 1000 1000 4096 Jul 17 04:41 hardy-updates
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 intrepid
drwxr-xr-x 6 1000 1000 4096 Feb 21 2009 intrepid-backports
drwxr-xr-x 6 1000 1000 4096 Nov 04 06:31 intrepid-proposed
drwxr-xr-x 6 1000 1000 4096 Nov 26 2008 intrepid-security
drwxr-xr-x 6 1000 1000 4096 Nov 13 2008 intrepid-updates
drwxr-xr-x 6 1000 1000 4096 Nov 12 2008 jaunty
drwxr-xr-x 6 1000 1000 4096 Sep 28 04:45 jaunty-backports
drwxr-xr-x 6 1000 1000 4096 Nov 03 06:09 jaunty-proposed
drwxr-xr-x 6 1000 1000 4096 Jul 02 04:51 jaunty-security
drwxr-xr-x 6 1000 1000 4096 May 14 04:40 jaunty-updates
drwxr-xr-x 6 1000 1000 4096 Apr 25 2009 karmic
drwxr-xr-x 6 1000 1000 4096 Apr 23 2009 karmic-backports
drwxr-xr-x 6 1000 1000 4096 Oct 30 06:17 karmic-proposed
drwxr-xr-x 6 1000 1000 4096 Nov 03 06:09 karmic-security
drwxr-xr-x 6 1000 1000 4096 Oct 31 05:47 karmic-updates
drwxr-xr-x 6 1000 1000 4096 Oct 31 05:46 lucid
drwxr-xr-x 6 1000 1000 4096 Oct 30 07:08 lucid-backports
drwxr-xr-x 6 1000 1000 4096 Oct 30 07:08 lucid-proposed
drwxr-xr-x 6 1000 1000 4096 Oct 30 07:08 lucid-security
drwxr-xr-x 6 1000 1000 4096 Oct 30 07:08 lucid-updates
So, my understanding is: There's no automated mechanism for smoothly
moving Ubuntu Server from the current stable branch to further ones,
right? I have to:
1. Find out there's been a new release.
2. Get its name (karmic, lucid...).
3. Edit /etc/apt/sources.list
4. Use apt-get (or aptitude) to do a semi-manual upgrade, and hope
for the best. (This isn't an X11 system, so "Upgrade Manager",
etc., is not in the picture.)
Am I missing something?
--
Rick Moen "Names of fictional places are capitalized:
rick at linuxmafia.com Narnia, Oz, San Francisco, etc."
-- FakeAPStylebook
More information about the sf-lug
mailing list