A kernel.org update [LWN.net]

By Jonathan Corbet
July 22, 2009

Your editor made a brief visit to the 2009 Linux Symposium, held in Montreal for the first time. One of the talks which could be seen during that short time was an update on kernel.org, presented by John Hawley. It was an interesting look into a bit of infrastructure that many of us rely upon, but which we tend to take for granted.

The "state of the server address" started off with the traditional display of bizarre email sent to kernel.org. Suffice to say, the kernel.org administrators get a lot of strange mail. They also have no qualms about displaying that mail (lightly sanitized) for amusement value.

The board of kernel.org is currently made up of five people: H. Peter Anvin, Jeff Uphoff, Chris Wright, Kees Cook, and Linus Torvalds. Linus, it is said, never attends the board meetings; John assumes that he's busy doing something related to the kernel. Peter continues to serve as the president of the organization, doing the work required to keep it as a nonprofit corporation in good standing. Much of the rest of the work is done by John, who was hired in September, 2008, to be the first full-time system administrator for kernel.org. He is employed by the Linux Foundation to do this job.

Over the last year, kernel.org has handled the mirroring a of a number of major distribution releases. They have added two new distributions (Gentoo and Moblin) to the mirror network, and Slackware is being added into the mix now. A number of new wiki instances have been added to wiki.kernel.org. John says that wikis are easy to create; he encourages relevant projects to ask for a kernel.org wiki if it would be helpful.

Internally, kernel.org runs on ten "disgustingly nice" machines donated by HP. John was strong in his praise of HP and ISC (which provides the bulk of the considerable bandwidth used by kernel.org); without them, kernel.org would not function the way it does. Beyond ISC, there are a couple of machines hosted at the OSU open source lab and one at Umeå University in Sweden. A lengthy process has finally gotten all of these machines upgraded to Fedora 9 - just in time, John noted wryly, for Fedora to end support for that distribution. So another round of upgrades in in the works for the near future.

Another significant change over the last year is the adoption of GeoDNS for the kernel.org domains. GeoDNS enables the DNS server to take the location of the requesting system into account and return the addresses of an appropriate set of servers. So kernel.org users now use local kernel.org mirrors, even if they do not explicitly ask for one using a country-specific host name.

One upcoming initiative is archive.kernel.org. This site is intended to be a permanent archive for older distribution updates. Should somebody find the urge to, say, install Red Hat Linux 5 on a system, it can be satisfied by a visit to archive.kernel.org. Filling in the archive is a work in progress; a number of older distribution releases seem to have fallen off the net. But, experience shows, many of the older releases will be located over time.

Another work in progress is "boot.kernel.org". This site is intended to be a repository of network-bootable distributions. The distributor can create a tiny boot image which does little more than setting up the network and downloading the next stage from boot.kernel.org. The idea here is that it will become easy to boot rescue or live CD distributions from the net. Distributions which support network installation can also be hosted on boot.kernel.org. This feature should be ready for a public launch sometime in the near future.

John closed with more amusing email. But, silliness aside, it seems clear that kernel.org is on a solid foundation. It is supporting our community areas going well beyond the kernel itself, and it looks well set to continue doing so for some time.

(Log in to post comments)

Why Fedora?

Posted Jul 23, 2009 9:19 UTC (Thu) by sasha (subscriber, #16070) [Link]

Being Debian person myself, I should add that there are other long-living distros: CentOS or RHEL (I think RH can afford such a donation to kernel.org ;-), SLES.

Why Fedora?

Posted Jul 23, 2009 11:45 UTC (Thu) by epa (subscriber, #39769) [Link]

There's no reason not to run Fedora provided you are happy to upgrade to the next release at least once a year, and deal with any backwards compatibility problems. (There aren't many, but Fedora does not provide an explicit 'nothing breaks' guarantee - packages do get removed or replaced from one Fedora release to the next.)

That means that upgrading the machines should not be a 'long process' as they report; it is essential to have an automated way to push out the latest distribution and to be able to swap out machines for spares. Otherwise, yes, you are making a rod for your own back.

Why Fedora?

Posted Jul 23, 2009 11:56 UTC (Thu) by Thue (subscriber, #14277) [Link]

How many important servers do you administer? Upgrading to a newer distro is something you want to do as little as possible, to minimize the number of chances for breaking something!

Why Fedora?

Posted Jul 23, 2009 13:06 UTC (Thu) by regala (subscriber, #15745) [Link]

there are more than one way of dealing with upgrades. I, myself, administer some Linux servers and I would prefer Debian, but I can understand that:
1) once a year is not too much or too often
2) 2 years of no "major" upgrades can have you deal with more problems than dealing with a cycle a little shorter.

my experience showed me that 2 years of development in FOSS can bring you more than expected changes of config formats, db on-disk formats...

it is a matter of choice, but 1 year is not that short in FOSS community.

Why Fedora?

Posted Jul 23, 2009 14:51 UTC (Thu) by epa (subscriber, #39769) [Link]

The point is to be in a situation where no one server is 'important'. If you have a render farm, or a webserver farm, you should anyway be able to survive the loss of one or two machines, so it shouldn't be too difficult to upgrade them one after the other using an automated mechanism such as Kickstart. (After testing the new release on your test system, of course.)

If you can't do this, and you have particular machines which have to stay up, and odd bits of configuration meaning you cannot install a new box fully automatically, then Fedora is probably not a suitable choice. (Myself I package almost everything as RPMs, and keep locally modified /etc files in version control, so installing a new server from scratch is not too painful. I would automate it even further if I had more than one box to worry about.)

Why Fedora?

Posted Jul 26, 2009 20:59 UTC (Sun) by jlokier (guest, #52227) [Link]

Those "odd bits of configuration" can add up to a lot of work, if you're running a lot of different things on your servers.

Which creates a dilemma, if you need a newer OS for some service but don't want to break the other services by doing the upgrade.

VMs help a lot with this, but they take a lot of resources and can't always be used.

Why Fedora?

Posted Aug 1, 2009 10:12 UTC (Sat) by Lennie (subscriber, #49641) [Link]

Can I suggest Linux-VServer, it hardly uses any resources.

Why Fedora?

Posted Aug 1, 2009 14:16 UTC (Sat) by jlokier (guest, #52227) [Link]

Linux-VServer and it's apparent successor LXC are much better for resource usage than KVM, it's true.

There is that slight problem that you don't have different kernels under Linux-VServer, so older distros which break with later kernels won't work. The kernel's system call interface is backward compatible, but many other things which "system-level" utilities depend on are not, and those are needed to boot an old distro without spending lots of time tweaking it.

So, not so good for booting old distros, but fine for running applications on those distros provided they don't depend on a booted environment. E.g. it's great for running old versions of GCC.

What KVM is great for is taking an old, working machine (say using a Linux 2.4 kernel or earlier, or Windows of course) and migrating it into KVM on a new machine with almost no work at all.

So: KVM for old Linux images and other OSes where you need a fully booted environment; Linux-VServer or LXC for almost current images, or running applications on old images which don't need a booted environment.

Why Fedora?

Posted Aug 1, 2009 18:47 UTC (Sat) by Lennie (subscriber, #49641) [Link]

I have a feeling you already know this, but just in case:

Actually, most VServers don't need much boot and/or system-level stuff.

You could say it runs only starts/runs those scripts which usually get run at init level 2 or 3.

VServers don't handle anything them selfs, like mounting /tmp or setting up networking. The /dev directory is mostly empty only null and zero and stuff like are needed.

Yes, going from physical to vserver might be more work (stripping out stuff you don't need). I've never seen any problems with kernel-dependencies.

Why Fedora?

Posted Aug 2, 2009 5:29 UTC (Sun) by jlokier (guest, #52227) [Link]

Exactly. For running things which don't need a boot environment, and don't need system daemons like hald and D-Bus running, VServer is pretty good. Running old GCCs falls into that category. (I hope it stays that way).

It's also fine if you already have your apps set up to use it, naturally.

When it's less inviting is when the problem is to keep some old app working that's currently on a real machine running some old distro. KVM is quite good at making that work with minimal effort.

I put mail serving (anything other than a simple configuration) in the latter category, because these days a mail server is a fairly complex affair and will run alongside a couple of spam filtering daemons and virus filtering daemon and some delivery program or other, maybe also user's procmails and perhaps involving the IMAP service too, and undoubtedly depends on a few non-obvious files in /etc as well as the obvious ones. That's the sort of thing I mean by "if I don't have time to touch this now, I can't afford to be updating the OS on this server to a newer version". Repeated prior experience tells me such things break on OS upgrades and can take a long time to get working again with the same behaviour as before.

Why Fedora?

Posted Jul 23, 2009 12:11 UTC (Thu) by Velmont (guest, #46433) [Link]

I guess «eating your own dog food» and thus running fairly new kernels all the time.

Why Fedora?

Posted Jul 23, 2009 14:49 UTC (Thu) by xoddam (subscriber, #2322) [Link]

Fedora 9 was mentioned.

Not that you can't run Fedora 9 on a new kernel, but that would not seem to be a compelling reason for the choice of distribution.

Why Fedora?

Posted Jul 24, 2009 7:29 UTC (Fri) by nix (subscriber, #2304) [Link]

Yeah, but this is a set of machines where if they go down kernel
development basically grinds to a halt, and which doesn't need whizzy new
features except as needed to cope with rising load (and it sounds like
even that is largely handled by adding more machines these days).

Upgrade conservatism is definitely called for here.

boot.kernel.org software

Posted Jul 25, 2009 21:39 UTC (Sat) by bronson (subscriber, #4806) [Link]

Except that I still need to have an optical disk or USB key to run instalinux right? It's like a 30MB download?

This sounds a little different. The next time btrfs fries Linus's laptop, he could just type a line at a BIOS prompt to PXE into a btrfs-friendly rescue image straight off boot.kernel.org. Very cool.

If I'm understanding the article correctly that is...

Archives: yum.

Posted Jul 26, 2009 14:29 UTC (Sun) by kena (subscriber, #2735) [Link]

And that's "yum" as in "yummy," nothing to do with package management.
Every now and then, don't you just yearn to fire up that old SLS or
Slackware from the pre-1.0 kernel release days? Downloading individual
floppies from sunsite.unc.edu?

Okay, that sounds incredibly ironic and/or sarcastic, but sometimes it's
hard to remember how far we've come in the past 15-odd years. Sure, there
are those of the "it was better when I had to etch the bits by hand" camp,
but I have no particular love lost for having to figure out modelines, lack
of an NIS-map aware automounter, and no journaling FS -- not to mention
boot/root floppies in pre-module days.

I bet doing some installs from "back in the day" would be a bit of a
refresher, and maybe even a surprise revelation for those who've only
started using Linux since, say, Y2K.

$.02

-Ken

P.S. Mmmm. Sasteroids.

Archives: yum.

Posted Jul 26, 2009 20:55 UTC (Sun) by jlokier (guest, #52227) [Link]

I don't care for configuring old OSes, and installing isn't that much fun.
I'm not one for playing old games on old platforms.

But I do like having a plethora of old libcs and gccs on different architectures to test against, just to be sure my code isn't too heavily Linux dependent, you know. I have a few other OSes around for the same reason, and a sprinkling of Windows versions. It's just *satisfying* somehow when everything compiles and runs in umpteen environments.