unsigned long geek = random();

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.

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.

I’ve been network booting SPARC systems for a while now, ever since my last run in with a faulty floppy drive on a SPARCstation 2. NetBSD makes it easy – the standard installation includes a diskless client filesystem which can simply be extracted onto the boot server. It wasn’t quite so straightforward with FreeBSD, so here are a few pointers…

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!)

Just a quick reminder about the topic of tonight’s CLUG talk – BSD Unix, given by, er, yours truly. The talk starts at 6:30pm, at the UCT Chemical Engineering Lecture Theatre.

Thanks to a lead from Mark, I now have even more Sun Ultra 60s – another five, for the princely total of R450 (about $60). They are of varying hardware specification, but I have 1×300Mhz CPU, 2×360Mhz CPUs and 2×450Mhz CPUs, somewhere in the region of 2.5GiB RAM and a few 4 and 9GiB disks. All the machines have dual width Elite3D framebuffers. All in all, a pretty good deal

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.

I’ve been using basically the same approach for my personal mail for over twelve years – a curses-based client (currently mutt), mail storage in mbox format and reading my mail on the mail server itself, logged in via ssh. As can well be imagined, it’s starting to get a little long in the tooth:

• 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.