unsigned long geek = random();

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 sent this to the rescue list this evening, in response to a discussion about the Microsoft patent infringement claims against open source software:

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.

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.

As part of my mail server rebuild (to be discussed in a future series of posts), I’ve been upgrading some of my mail system configuration files. One of them is fetchmail.conf, the configuration file for fetchmail, which I use to fetch mail from my mail server. It required a few changes after the upgrade to version 6.3.8 and a few changes in my environment.

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.

I’ve obviously been living in a cave for a while, but I only recently discovered that Panix are offering “virtual colocation” via Xen virtual machines. One very nice feature – they offer NetBSD in addition to the customary Linux. Pricing is competitive and they also offer a free backup service, which is a nice addition. Not quite sure why their default NetBSD virtual machine includes X11 though?

I’ve been having some problems with my workstation lately, some of which I’ve attributed to running bleeding edge software on a non-mainstream platform. Yes, NetBSD-current on a sparc64 machine is not always a recipe for success. The major problems were bus errors when running certain X applications (primarily fluxbox) and some X applications not building shared libraries.

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