Congratulations to the Ubuntu team, on a successful gutsy release. While gutsy is currently a little buggy for me, the millions of eyes will hopefully find all the bugs responsible… (and I must get around to filing the relevant launchpad bugs)
I run a teeny weeny little mirror (by International standards, for South Africa, it’s OK), so I’ve followed the release process, and been hanging out on #ubuntu-mirrors since last night. Preparing an Ubuntu release is quite an undertaking. In total, each mirror needs to carry around 20-30 CD images, and 4 DVD images. That’s reasonable chunk of data, and it takes a lot of coordination for everybody to get it.
I see many distros release, we normally pick them up automatically, and notice their presence the next day. But there’s definitely something special about Ubuntu releases. They have the feel of a release. The tension builds up the night before, and the #ubuntu-release-party channel fills up (when I popped in, around 500 people). Then, a few hours before the release is announced, people start noticing that it’s on the mirrors. Pointing this out on the release-party channel is not allowed (it would disturb the otherwise rowdy party of 500 users pressing F5 every 10 seconds), but pretty quickly, before the release is even announced, all the mirrors that carry Ubuntu CDs get flat-lined. If they don’t, then it’s a sign that their hardware isn’t up to scratch, and they have to find & fix their bottlenecks. On the #ubuntu-mirrors channel, you can see sysadmins from around the world showing off graphs of flat-lined, multi-gigabit links and sharing server tuning tips. If you want any experience in widely-distributing large files, run an ubuntu mirror at release-time, you’ll gain the experience fast.
I don’t know if this massive assault means Ubuntu is the most popular distribution out there. Most Ubuntu users don’t need the new ISO. They rather need click the big “upgrade” button, and hammer their local mirror to the tune of about a gigabyte. Ubuntu is based on Debian’s awesome package management system, that (if used correctly) should never require a re-install. There are Debian systems out there that were installed once, back in the 90s, and have been upgraded (both distro versions and hardware) continuously since then. Do people not know that, or do they want the thrill of booting up with the new Gutsy CD? Debian is widely considered to be the most popular distribution, and a Debian release hardly raises eyebrows (other than somebody saying “Debian released? Has hell frozen over?”, and scheduling an upgrade for some time in the next 6 months). If nothing else, this shows how different distributions’ user-base can be, while being technically very similar.
I’ve done my bit to help out the Ubuntu release:
Now, as the release traffic dies down again (i.e. heavy but not quite flat-lining), I hope the sysadmins and release-party-goers sleep well, you all deserve it.
I remember somebody asking how to do this on the CLUG lists a while back. But here’s the problem:
You’ve got an automated backup system, but you want offsite backups. DVDs are too small, external hard drives are the only option. You want the user to be able to plug in the firewire disk, have the backup start automatically, and let them know when it’s done.
Here’s how I implemented it:
The backups are implemented with backup-manager, they backup into
The external hard drive connects by firewire. Running
udevinfo -a -p /sys/block/sdd on it showed me it’s ID:
I created this UDEV rule file
And the relevant fstab entry:
And the backup script
I’ve just discovered memdisk. It’s part of the
syslinux package on Debian/Ubuntu, and hides in
Memdisk lets you boot a floppy image, via grub or pxelinux. In this modern era of computers without floppy drives, it means you can do BIOS updates without having to go through the whole procedure of turning a floppy image into a bootable CD.
In PXELINUX, the config file would look like this:
In Grub, like this:
Thanks ThinkWiki for the idea.
Caveat emptor: apparently some flash tools don’t like memdisk, so YMMV
The preferred way to do this is with IMAP Namespaces. My natural approach would be to create something like a Maildir tree
/srv/mail/shared, and make this the “public” namespace. Then set filesystem permissions on subtrees of that, to define who can see what. Unfortunately, dovecot uses strict Maildir++, and won’t let you create mailboxes inside each other (on the filesystem)
/Foo/Bar is stored as a Maildir called
.Foo.Bar, so subtrees don’t exist, so this isn’t an option. The up-comming dbox format should allow something like this, but it isn’t usable yet.
My solution was to create multiple namespaces. One for each shared mailbox. Users are given permission to use them via file-system permissions (i.e. group membership), example:
INDEX mean that dovecot’s metadata is stored in the user’s personal Maildir, so users who don’t have permission to see the shared mailbox don’t get errors.
The permissions of the mailbox should be done as follows:
If you want a common subscription list, you have to manually symlink:
Seems to work well. (at least with thunderbird)
Finally, it’s got easy to install the codecs we can legally use in this country:
Medibuntu now has a
non-free-codecs package, an all-in-one virtual package.
Personally, I’m still in favour having them there by default, and the installer removes them if you select a patent-encumbered country as your time-zone, but I can see why people are wary of that approach….