unsigned long geek = random();

I just received this in a mail from the publishers of Linux Journal:

For a limited time all international subscriptions to the print edition of Linux Journal will be reduced to the low price of $49.50 for 1 year (a savings of over 30% off the regular price) AND upgraded to include a free digital subscription. As a special bonus you will also receive Linux Journal’s System Administration Special Issue free of charge.

I’ve been a Linux Journal subscriber since the late 90s and can recommend it as one of the better general-interest computer publications. To take advantage of the special offer, visit the Linux Journal site. It seems the promo code to take part in this offer is M96INTL.

Update: Fixed the link to the subscription page, courtesy of Mark at Linux Journal. Whoops!

For those who may have missed yesterday’s announcement, after a long beta and release candidate period, NetBSD 5.0 is finally available.

Andrew Doran has prepared a presentation (PDF) giving a high level overview of changes in 5.0 . Some highlights include:

• Journaling enhancements to FFS (WAPBL)
• Finer-grained locking on SMP systems
• A new kernel module system
• Vastly improved ACPI support
• Many ports using X.Org instead ofXFree86

All in all, this is probably one of the most significant releases in the project’s history – kudos to all involved.

A few days ago I upgraded the Ubuntu partition on my HP Mini-Note 2133 from 8.10 to the release candidate of 9.04 (i386). The upgrade itself went very smoothly, for the most part – I ran Update Manager, answered a few questions and waited for the upgrade to complete. With the fairly pedestrian 1.2Ghz VIA C7 CPU the upgrade took around an hour and a half.

When I rebooted, I spotted the first problem – GRUB presented me with the kernels from 8.10 (2.6.27.*) but not the 9.04 kernel (2.6.28.*). During the installation I had elected not to overwrite GRUB’s menu.lst, thinking that it would still get updated when the kernel package was configured. Oddly, that didn’t happen. My solution was to edit /boot/grub/menu.lst and add entries for the 9.04 default kernel (doing a dpkg-reconfigure on the kernel package would probably also have fixed it).

Once I had booted the correct kernel, I tackled the second problem – X didn’t work. With 8.10 I had been using the proprietary VIA DRM kernel module, which enabled hardware-accelerated 3D on the 2133’s Chrome9 chipset, but it didn’t work with the updated 9.04 kernel. I moved my /etc/X11/Xorg.conf out of the way and restarted X, which then started correctly with sane defaults (newer releases of X.Org no longer require a configuration file). Rather pleasingly, the OpenChrome driver being used by X.Org started with the correct 1280×768 resolution. The one downside of not using the VIA module is that compiz et al. don’t work – not a big issue for now and one that should be rectified once VIA update their DRM kernel module for 9.04’s kernel. One possible workaround is to boot the most recent kernel from 8.10 (which is still installed), but I haven’t tried that yet.

The third problem, and the most annoying, relates to the 2133’s Broadcom wireless. With 8.10 I had been using ndiswrapper and it worked perfectly. For some reason, as soon as I tried to connect to my home wireless network after upgrading to 9.04, WPA authentication failed (I kept getting prompted for my key and the key I entered was never saved). I then switched to using the Broadcom STA driver, which authenticates successfully, but exhibits a few problems of its own – it often looses the connection to my access point and sometimes doesn’t work correctly after resuming from a suspend. I’m going to switch back to using ndiswrapper to see if it’ll work with a bit more coaxing.

Overall, I’m reasonably happy with the upgrade – other than the issues mentioned above, it went smoothly and the system is working well. The only issue that’s really causing me pain at the moment is the wireless (but then it is Broadcom…).

A few months ago while working on a Linux system using XFS, I came across an interesting “feature”. When moving a directory such that its owner changed, the moved directory’s mtime was changed to the current date and time.

For example:

[0] mj@majestic:~/tmp$ mount |grep home
/dev/mapper/data-home on /home type xfs (rw)
[0] mj@majestic:~/tmp$ mkdir test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jun 18 15:28 test
[0] mj@majestic:~/tmp$ touch -t 200801011530 test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test
[0] mj@majestic:~/tmp$ stat test
File: `test'
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-01-01 15:30:00.000000000 +0000
Change: 2008-06-18 15:29:08.173750666 +0100
[0] mj@majestic:~/tmp$ mv test test1
[0] mj@majestic:~/tmp$ ls -ld test1
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test1
[0] mj@majestic:~/tmp$ mv test1 ..
[0] mj@majestic:~/tmp$ ls -ld ../test1
drwxr-sr-x 2 mj mj 6 Jun 18 15:30 ../test1
File: `../test1'
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-06-18 15:30:02.814078187 +0100
Change: 2008-06-18 15:30:02.814078187 +0100


I’d never seen this happen before, so I tried to reproduce the behaviour on systems using ext3, UFS and HFS+ filesystems. None of them updated the moved directory’s mtime when the parent directory changed, which is what one would expect. XFS does have an active mailing list, so I reported my findings and was quickly provided with a patch that fixed the problem. Kudos to the XFS developers for providing a fix so quickly.

Rather odd that no-one had spotted this behaviour in the past though…

pkgsrc doesn’t officially support re-bootstrapping once it’s been installed (ie updating the core packages by doing a fresh bootstrap). There is a way to force one by removing a few core packages first though:
pkg_delete -ff bootstrap-mk-files bmake tnftp pax pkg_install
cd /usr/pkgsrc/bootstrap
./bootstrap


As long as the fresh bootstrap is done using the same parameters as used originally (prefix, database directory, etc), everything should work as before.

I tested this a short while ago on an OS X 10.5 system using a pkgsrc -current tree and it worked perfectly.

In the first part of this short series, I detailed the reasoning behind my need for a new mail server. In this second part, I’m going to detail my mail architecture as well as the software choices I made and why.

All mail for my various domains is delivered to the primary MX, which is a hosted server sitting in the US running Debian GNU/Linux (unfortunately my hosting provider doesn’t support NetBSD). It runs postfix and makes use of a variety of checks within postfix itself as well as postgrey for greylisting. I use a fairly conservative list of RBLs and, in conjunction with greylisting, they stop most spam from being accepted. Why postfix? Well, I stopped using sendmail over ten years ago, and although I’ve had good results with Exim in the past, these days I’m just most comfortable with postfix and it suits my needs perfectly.

The RBLs I use:

• zen.spamhaus.org
• cbl.abuseat.org
• list.dsbl.org

Once mail has been received by my primary MX, it is delivered to local mailboxes, one per user. None of the users read their mail from the US server, however. All the mail is downloaded to the local mail server via SSL-secured POP3 and accessed here, either locally or via IMAP. The local mail server is a Sun Ultra 2 running NetBSD/sparc64 3.1_STABLE.

Software I’m using on the local mail server:

• postfix
• dovecot for IMAP (over SSL) access. There are a number of IMAP/POP3 servers available, but I chose Dovecot because of its clean design, good security record and flexible support for mail storage, amongst other things.
• amavisd-new with spamassasin (with razor and Bayesian filtering enabled) and clamav for content filtering
• getmail to download mail from the US server
• mailgraph for simple reporting

All of the above are available in pkgsrc. As I have already done any RBL-based checks on the MX, I don’t do any of them locally.

Although FreeBSD is a platform supported by pkgsrc, only i386 supported is explicitly mentioned and the most recent bootstrap binaries are for FreeBSD/i386 5.3. Being the adventurous chap I am, I decided to bootstrap from source on my dual CPU Ultra 60 running FreeBSD/sparc64 6.2. In true pkgsrc style, it Just Worked. Since bootstrapping, I’ve build a number of fairly large packages without problem: zsh, ncurses, vim, postfix, perl.

Why pkgsrc and not ports on a FreeBSD system? Well, I have a finely tuned pkgsrc environment that builds packages with my set of defaults (MIT Kerberos support, for example), so I decided to stick with what works well for me.

I’ve uploaded the slides from last night’s *BSD talk to the CLUG wiki – grab ‘em here. Content licensed under a Creative Commons Attribution Share Alike license.