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.

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.

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

Before possibly wasting time on issues that had already been resolved, I decided to install a new build. Unfortunately releng haven’t released any new builds since early December, which meant I’d have to build a release myself. No problem, except my regular build system (an SMP i386 NetBSD system) has been overheating of late, so I decided to resort to a native build. Not the fastest (none of my sparc64 systems is particularly fast by modern standards), but at least it’d work.

My first build failed with the following error:
*** Failed target: cp-name-parser.c
*** Failed command: /usr/obj/build/tools/4.99/sparc64/bin/nbyacc -o /nfs/src/export/src/netbsd/current/usr/src/gnu/dist/gdb6/gdb/cp-name-parser.c /nfs/src/export/src/netbsd/current/usr/src/gnu/dist/gdb6/gdb/cp-name-parser.y


Hmm… Not too meaningful. Reasoning that my source tree was out of sync, I updated it and kicked off the build again. Same error.

After much head scratching, I guessed that the paths to the input and output files were possibly too long. The long paths are a result of my slightly convoluted filesystem layout as a result of multiple NFS servers. After a failed attempt to use a null mount (which worked, but for some reason the build still used the underlying location), I resorted to mounting the source tree directly in /usr/src and building from it.

Success!
NetBSD enigma.pimp.org.za 4.99.7 NetBSD 4.99.7 (ENIGMA_499) #1: Sun Dec 31 17:52:25 SAST 2006 root@enigma.pimp.org.za:/usr/obj/sys/compile/ENIGMA_499 sparc64


The only slight problem I had was a missing fb1 node in /dev, with the result that XFree86 didn’t even find the second card. After much hair-pulling, I realised what the problem was and ran MAKEDEV std_sparc64 in /dev to fix it. The reason for the missing device node was that my machine had been upgraded from 3.1 to -current and I had neglected to update /dev during the upgrade. Oh well, all’s well that ends well

Dual Creator3Ds are only supported by 4.0 and later – if you try and boot 3.1 and earlier on a machine with a pair of them, you may find your console “disappearing” when the second card is initalised. To get around that, remove the second card, upgrade and then reinstall the card.

Some useful resources:

• My working XF86Config
• The Sun Frame Buffer FAQ
• A guide to setting Sun frame buffer resolution

Update: fixed the broken link to my XF86Config

If a file isn’t found at the local mirror, the pkgsrc fetch Makefile target will fetch it from another (non-local) mirror.

One of the Ultra 60s had a single 360Mhz CPU, 1GiB RAM, a 9GiB disk, gigabit Ethernet and a pair of Creator3Ds. The other had a single 360Mhz CPU, 512MiB RAM, a pair of 18GiB drives and a single Creator3D. The Ultra 2 only had a single 200Mhz CPU, but had 512MiB RAM. The Ultra 1s were pretty low end – both had 143Mhz CPUs, 64MiB RAM and a quad fast ethernet and one had a 2GiB disk, the other being diskless.

I’ve given the one Ultra 60 and the Ultra 2 to Jonathan Groll and the Ultra 1s will probably be given to some deserving homes amongst CLUG members. My Ultra 60 is already running NetBSD-current (currently 4.99.4 kernel and userland) and working well, but more on that in a later post.

It’s incredible, but a few years ago it was impossible to get any moderately decent Sun hardware locally, but these days it seems to be falling from the sky. At rough count I currently have 13 unused Sun machines (6×32-bit, 7×64-bit). Now I just need to get myself a nice Blade 1000, 2000 or 2500 and I’ll be a very happy camper. Of course NetBSD still needs to get working sparc64 SMP and UltraSPARC-III CPU support, but that’s minor stuff

The two systems I got were an Ultra 10, 333Mhz, 256MiB, 9GiB IDE, Creator3D and an Ultra 2, 300Mhz, 256MiB, Creator3D and no disks. I’ve already stripped my Ultra 5 and put its RAM, SCSI controller, disk and USB 2.0 card into the Ultra 10 and it seems noticeably faster – probably a combination of the Creator3D and the extra cache on the 333Mhz CPU (2MiB vs the 256KiB on the Ultra 5’s 360Mhz).

The Ultra 10 is running NetBSD-current (4.99.1) and once Solaris 10 Update 3 has been released, I’ll be installing it on the Ultra 2.