[sf-lug] Linux Server Preferences
Michael Paric
mparic at compbizsolutions.com
Thu Nov 5 18:59:20 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
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
Thanks all for the great feedback; what I'm not sure about is why
Ubuntu sysadmins would be upgrading on every release. Stability to me
is the top priority on a server, especially a headless, no gui
workhorse running key network services. Sure, RHEL/CentOS and the last
Ubuntu LTS release may have older kernels and packages, but is it
really necessary to have your network servers running the latest (and
sometimes *not* the greatest) versions? For the desktop, sure, you
probably want the latest wireless, graphics, disk drivers, but is any
of that is necessary in a server environment? From what I've read on
the Ubuntu site, they've spent a good deal of time making sure an "apt-
get dist-upgrade" from one LTS version to the next is relatively
smooth, especially since you're not dealing with all the cutting-edge
drivers and gui features that play havoc with the system. I'm running
9.10 UNR on my netbook, but wouldn't think about upgrading the server
from 8.04 LTS until the next LTS cycle (even a demonstration system).
--------------------------------------------------------
Michael Paric
mparic at compbizsolutions.com
www.compbizsolutions.com
More information about the sf-lug
mailing list