Nevis Linux Distribution Status
I received an e-mail from the Fedora Legacy project; here's the key
paragraph from that message. Basically, the Fedora Legacy project is
The way things worked before this: Redhat (and later Fedora) would
release a free version of their Linux, and would support it for about
18 months. The Fedora
Legacy project would pick up the release at that point, and would
supply security patches and critical bug fixes for another 18 months.
This would give each release a "lifetime" of about 3 years.
With Fedora Legacy shutting down, this gives each new Fedora Core
release a lifetime of 18 months. My impression is that this may be too
short a lifetime for our work at Nevis; every new release brings
issues with library incompatibilities, new GCC versions, etc. (Misha
Leltchouk can tell you about all the problems we've had getting the
ATLAS Athena software to work on Fedora Core 3.)
Why Fedora Core?
the Fedora Core
distribution for use at Nevis for the following reasons:
- The ATLAS folks would be content with CERN Scentific Linux; the
D0 group might prefer Scientific Linux
Fermi; I'm not sure which flavors the DOE or Auger groups would
like. Fedora Core seemed a reasonable compromise between the needs of the
different research groups.
- The Scientific Linux
distributions seemed slow to include drivers for the latest hardware.
I once tried to install CERN Scientific Linux 3 on a laptop, and got
into problems with the screen drivers; Fedora Core 1 worked just fine. The Fedora Core distribution
seemed ideal for those folks who'd first buy a desktop/laptop with all
the latest hardware, and
then ask me to install Linux on it.
What to do?
In past month or so, I've worked on upgrading all the remaining
systems running Redhat 9 to Fedora Core 4 or 6. It will take another few
days to finish up. I plan to finish this work.
Here are some alternatives:
- Move to Scientific
Linux (the base distribution, not the FNAL- or CERN-specific ones). When I look at their roadmap,
I see that Scientific Linux 5 will be released in the first quarter of
2007, and will be supported until Oct-2010.
- It means that we don't rush into
anything. A lot can happen in three months; perhaps someone else will
pick up the Fedora Legacy work.
- We'd be working with a distribution that's fairly close to what
at least two big labs use: FNAL and CERN.
- It may be pushing it to rush to SL5; e.g., the ATLAS Athena group
probably doesn't want to think about SLC5 until after the beam
turns on. SL4, with a little less than two more years of support,
may be enough.
- There still may be support issues for the latest hardware;
e.g., SL4 may not be able to handle 802.11n wireless cards in
laptops (or maybe it can; I don't know).
- We continue to work with the supported versions of Fedora Core,
which means relatively frequent OS upgrades; every box would be
upgraded at least once every 18 months.
The assumption here is that the standardized
compilers and other tools I try to maintain would be enough to
keep us from revising our code and scripts for every OS upgrade.
- The primary reason for active OS support is security patches. We
can reduce the risk and the need for active security patches by moving
the Nevis systems behind a gateway (the "BNL" approach). To access
most systems from outside Nevis, you'd have to ssh to the gateway,
then ssh to the system you wanted.
A few Nevis systems (the gateway, the web server, the mail server)
that were "visible" to the outside world would require frequest Fedora
Core upgrades; the rest could stay as they are.
This is the option that the Auger chose for a couple of their boxes
that had to remain at Redhat 9.
The advantage of this approach is that "things don't change"; there's
a value to stability.
The disadvantages: It's a pain to have to login twice (although there
are ways to work around this with scripts). File transfers and other
activities all have to go through the gateway computer. If the
gateway computer were to go off-line (e.g., for an OS upgrade), no one
could login to Nevis from the outside (we could solve this issue by having more than
- We spend the money and buy licenses for Redhat Enterprise Linux. This
gets us up to seven years of support for whatever distribution we
The only advantage I see to this approach is the relative stability it
would provide for our systems.
The disadvantages: It could wind up costing a lot of money; my last
estimate ranged from $1000-$7000. The hardware support issue would
remain, and would grow worse over the years if we stuck with one
release. I'm not happy with Redhat's model for applying patches,
which requires someone to sit at the box and click on an icon; the
existing Nevis cluster has patches applied automatically.
My own preference keeps wavering between options 1 and 2. Let me know
what you think.