Nevis Linux Distribution Status

What's changing

I received an e-mail from the Fedora Legacy project; here's the key paragraph from that message. Basically, the Fedora Legacy project is shutting down.

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?

I chose the Fedora Core distribution for use at Nevis for the following reasons:

What to do?

Short term

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.

Long term

Here are some alternatives:

  1. 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.

    The advantages:

    The disadvantages:

  2. 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.

  3. 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 one gateway).

  4. We spend the money and buy licenses for Redhat Enterprise Linux. This gets us up to seven years of support for whatever distribution we pick.

    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.