At present, Mathnet has these SuSE Linux versions deployed:
| Version | Machines | Fraction | Comments |
|---|---|---|---|
| 8.2 | 43 | 35% | Only bamboo |
| 9.2 | 72 | 59% | Standard version |
| 9.3 | 1 | 1% | 1 rogue (callice) |
| 10.0 | 7 | 6% | |
| Total | 123 |
v9.2 came out in September 2004 and we adopted it in December; v10.0 came out in September 2005. It is proposed to adopt v10.0 as our standard version. But to change the version takes a lot of work on our part. What are the reasons for doing so?
Or to put it another way, could we hang on with v9.2 for another year? How often should we upgrade? Why is one year the magic number for upgrades?
I'll answer this question in four areas: what happened in the recent past when we didn't upgrade; how long we can expect Novell to support each version; how big is the difference between v9.2 and v10.0; and one subsystem, Kerberos, that has a major transition in this upgrade.
In the previous millenium Mathnet adopted Solaris 2.6 as our standard operating system. We attempted to keep it up to date with security patches, but got stuck on one key patch, and we failed to solve the problem aggressively. Thus we remained at v2.6 for six or seven years. Stagnation was convenient and comfortable, but we suffered from a lack of vendor support, and our users suffered from the lack of current software, and from hardware that increasingly fell behind modern standards.
Finally a major security threat jarred us awake, and the result was to junk our whole computing infrastructure, with considerable disruption of the users. I hope we don't go through all the work of Project Sunset, and then not take care of the product, lapsing back into sloth. O.S. upgrades are a fact of life, and we should plan to upgrade periodically.
A major reason to upgrade to a new release is so we can continue to receive security patches. How long does Novell support old versions?
Novell has a page
comparing SUSE Linux Enterprise Server 9
(SLES) and SUSE
Linux 10.0
. The most significant differences for us are:
| Issue | SLES | SuSE Linux |
|---|---|---|
| Release every | 18-24 months | 6 months |
| Security patches | Yes | Limited availability |
| Software updates | Yes | No (buy the next release) |
| Lifecycle guarantee | Seven years | None |
In other words, Novell is not making a commitment for how long they will support old versions of SuSE Linux. In a statement of support life cycles, they make no mention of SuSE Linux 10.0; the items on this page are, for example, SLES -- things where you pay for support.
Looking in the Support Database, I tried to identify the date of the first and last patch posted for various SuSE versions. Unfortunately this database covers only SLES and its various predecessors and rebundlings. So it is useless for our purpose.
Restricting only to security patches running from 2002-10-14 to the present, we can see that SuSE's actual support lifetime for a release is 24 to 30 months. However, Novell avoids making a firm commitment on security patches and we can't be sure whether they will continue this schedule.
| Version | First Seen | Last Seen | Lifetime |
|---|---|---|---|
| 7.1 | 2002-10-21* | 2003-05-27 | >9 mos |
| 7.2 | 2002-10-21* | 2003-10-01 | >12 mos |
| 7.3 | 2002-10-21* | 2003-12-04 | >14 mos |
| 8.0 | 2002-10-14* | 2004-08-09 | >24 mos |
| 8.1 | 2002-10-14* | 2005-02-10 | >30 mos |
| 8.2 | 2003-03-25 | 2005-06-09 | 26 mos |
| 9.0 | 2003-10-31 | 2005-12-02* | >25 mos |
| 9.1 | 2004-05-04 | 2005-12-02* | >18 mos |
| 9.2 | 2004-10-26 | 2005-12-02* | >13 mos |
| 9.3 | 2005-04-11 | 2005-12-02* | >7 mos |
| 10.0 | 2005-09-26 | 2005-12-02* | >2 mos |
So in conclusion, if we try to stretch the update interval to 2 years we are pushing the historical limits of product support. In addition, it's certain that the most recent version has the highest priority for being patched, with later versions receiving less and less attention. I'm much more comfortable keeping a version around for 15 months, than trying to stretch it beyond two years.
While for SLES Novell provides product updates
and service
packs
, for the open distro you advance in package versions only when
you upgrade the whole distro. A major reason to go to the bother of a
distro upgrade is to get these later product versions. Here is a
laundry list of packages for which I have noticed significant
improvements. However I do not use KDE, or many of the other packages,
so likely they have improvements of which I am unaware.
For my personal use, comparing v9.3 with v10.0, there are important driver and kernel improvements (e.g. from useless to functioning) in accelerated graphics, wireless networking, SATA discs, and laptop suspend modes. The most recent devices simply do not exist in v9.2, and we're going to have to deal with them on newly purchased workstations. With Windows you get a driver disc with the product; it doesn't work that way on Linux.
In v9.2, hotplugging is kind of a hit or miss thing. In v10.0 the SuSE team have put together a suite of programs that work together pretty reliably so that when you hotplug (or coldplug) a piece of hardware like a USB storage device or your CD burner, the driver is loaded, the device inode is created, you get permission for the device, and (if the device has a filesystem) the filesystem is mounted. Charlie, normally very conservative about OS upgrades, put v10.0 on Ulanda solely because he needed reliable hotplugging.
New printers appear continuously. If we don't upgrade the distro we would have to locate and install PPDs for all printers that we have that were marketed since September 2004.
I don't use Java much, but v9.3 and v10.0 have Sun Java 1.5.0 which appears to coexist much better with the rest of the distro than java-1_4_2-sun-devel; in other words I didn't have to tweak it to get it working.
Gimp-2.2.8 seems to have incremental improvements in integration, and likely bug fixes. I don't use Gimp every day and so I wouldn't be able to state authoritatively what the differences are, but it just feels smoother. I expect that the new KDE and Gnome base packages are similar: incremental but not radical improvements.
So in conclusion, for the most part the users are going to see incremental improvements to their favorite packages. On the other hand the MCG are going to have substantially more hardware supported out of the box if we go to v10.0.
You ask, so why don't we put v10.0 only on new machines? As we've learned from supporting Mozilla and/or Firefox, software packages have different idiosyncracies in different versions, generally worse in the older version, and it helps our support staff to not have to deal with multiple versions on a permanent basis.
For jimc, a major motivation for moving on SuSE 10.0 is to make progress on Kerberos. Up to SuSE 9.2 they used Heimdal (European Kerberos) in the distro. Starting in SuSE 9.3, for obscure political reasons, they have changed to MIT Kerberos. Although Windows, Heimdal and MIT Kerberos clients can interact with a server of any flavor (given compatible versions), and tickets of any flavor should be honored by daemons (such as imapd or Samba) of any flavor, the administrative daemons do not interoperate, and I have my doubts about the password changing daemon (though with rpasswdd this likely can be worked around, at least for UNIX). Thus I would like to get our Kerberos servers upgraded to v10.0, rather than putting more effort into maintaining the existing Heimdal servers.
[Thanks to Harald Milz for pointing out the following: Windows 2003 Server Active Directory passes out arcfour-hmac-md5 keys. SLES9 includes Heimdal-0.61, which can accept des-cbc-md5 but not arcfour-hmac-md5 keys; Heimdal-0.63 has the newer crypto algorithms. //ftp.sernet.de/pub/samba has an instance of Samba-3.0.14a (or later) which is statically linked with the Heimdal-0.63 libraries, enabling use with W2003 AD. But MIT Kerberos in SuSE 9.3 et seq. can handle tickets passed out by W2003 AD.]
So why is it important to do Kerberos at all? First, we want to get
passwords off the net, something that Kerberos does well. Second, we want
to coordinate user indentities and passwords on Windows and UNIX, and Windows
expects to have a Kerberos server. Third, Kerberos provides single
sign-on
; in other words, when you log in you get a ticket vouching for
your identity, which you can present to daemons such as imapd. You can then
retrieve your mail without typing your password again and again and again.
In support of the last point, here is a list of Kerberized and SASLized software in SuSE 10.0. The procedure was to go through i586/*.rpm in SuSE 10.0 with the command rpm -q --requires -p whatever.rpm, and to detect everything (excluding Kerberos itself) that "requires" libgssapi or libsasl2. Although GSSAPI can handle a variety of authentication mechanisms, Kerberos is the only one relevant for us.
A significant point: any client-server application that uses SASL can use SASL's GSSAPI plugin to authenticate by Kerberos. Specifically, Pine is in this category. At present, every time you start Pine and connect to the imap daemon you need to type in your password. If I can get GSSAPI working, the Kerberos ticket will be valid for retrieving mail.