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!

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.

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…).

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…

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.

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.

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.

My boot server is running NetBSD 3.1 and I booted FreeBSD 6.2, so if you’re using different software you may need to make some adjustments. YMMV.

1. On the boot server, configure rarpd(8) as usual, adding the entry for your machine’s MAC address to /etc/ethers. For example (for a machine called test02):
   08:00:20:b2:2f:b6 test02
2. Extract the FreeBSD base fileset to the appropriate location on your boot server (for example, /export/install/fb62_sp64).
3. Extract the FreeBSD GENERIC kernel fileset to boot/ in your diskless filesystem.
4. Within your diskless root, symlink boot/GENERIC to boot/kernel (boot/GENERIC is a directory that contains the kernel and its modules).
5. Put boot/loaders from the diskless filesystem into your tftp root directory and symlink it to your machine’s IP address in hex. For example, the filename for 192.168.1.92 is C0A8015C.
6. Export your diskless root filesystem via NFS and add the necessary dhcpd.conf stanza. For example:
host test02.pimp.org.za {
hardware ethernet 08:00:20:b2:2f:b6;
fixed-address 192.168.1.92;
option host-name "test02";
option root-path "/export/install/fb62_sp64";
}
7. Boot your machine – “boot net” from the PROM should do it.

A few tips:

• It’s normally a good idea to update the machine’s OpenBoot PROM to the latest release. Old PROMs often have subtle bugs.
• Extracting FreeBSD filesets is simple:
cat 6.2-RELEASE/base/base.* > /tmp/base.tar.gz
tar -xzvpf /tmp/base.tar.gz -C /export/install/fb62_sp4


Update: Fixed incorrect command to extract sets (thanks John Messenger!)

My plan is to put together at least two dual CPU machines, one running FreeBSD and another probably running OpenSolaris. *sigh* If only NetBSD supported SMP on 64-bit SPARC systems.

My feeling is that Microsoft is trying to spread FUD and scare large firms
that are considering FOSS. Companies are going to be dissuaded from using
FOSS if there is a risk that they may have to pay unknown “future
royalties” because the software they’re using violates a Microsoft patent.

I wonder if this will all just mysteriously blow over in a few months,
without Microsoft ever having released the details of the patents
supposedly violated. By which time, of course, enough FUD will be spread in
the market, particularly amongst those who don’t fully understand FOSS,
that Microsoft will have achieved exactly what they wanted to with their
disinformation campaign.

For some reason, I thought it bore reprinting here. Yes, I do love a good conspiracy theory.

• The mbox format has a number of limitations (locking, performance, etc), although it is convenient to have a mail folder housed in a single file. Using mbox format also prevents me from using a client that doesn’t support it.
• I have no convenient external access to my mail – if I’m not with a laptop, trying to read mail via an ssh connection from a mobile phone is rather uncomfortable.

To finally move into the 21st century, over the past few weeks I’ve put in place a new Sun Ultra 2 mail server, running NetBSD/sparc64. Over the next few days I’ll be discussing the configuration of the new server, focusing in particular on some of the challenges faced when using a slightly, er, unusual platform.

A snippet from my updated configuration file:

        username user1 with password "pass1" is user1 here ssl fetchall
                sslfingerprint "BA:34:74:B6:7F:EF:A7:88:7C:7A:D1:8B:79:C5:10:D9"
                sslcertpath /etc/openssl/certs
                smtphost mail.relay.co.za
        username user2 with password "pass2" is user2 here ssl fetchall
                sslfingerprint "BA:34:74:B6:7F:EF:A7:88:7C:7A:D1:8B:79:C5:10:D9"
                sslcertpath /etc/openssl/certs
                smtphost mail.relay.co.za

Now, why on earth does one have to specify an SSL fingerprint, certificate path and mail server for each user? Wouldn’t it make more sense to have a global default and individual overrides where necessary? Chalk this up as another reason why I should move to getmail. Yes, I know I could add the functionality myself, but I really do need to move away from using an abomination before God to fetch my mail.

Note to self: this is the second “sucks” post in two days. Must remember to be more positive.