unsigned long geek = random();

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.

This week I flew domestically within the UK and encountered British Airways’ strange special meals policy for the first time. According to their website:

Special meal requests cannot be made for travel on any of the following services: all UK Domestic flights, Euro Traveller flights from the UK to Paris, Luxembourg, Dusseldorf, Jersey, Cologne, Amsterdam & Brussels, and passengers travelling on any flight on a stand-by or waitlist basis.

That’s rather poor (and rather strange, if you ask me). Heck, in South Africa BA even have extra vegetarian meals on their domestic flights for those who haven’t requested them in advance. I’m not at all impressed, but unfortunately BA seem to be the only airline that fly from Gatwick to Manchester.

Update: If you ask, they do have vegetarian meals onboard, even if you can’t pre-book one.

After much procrastination, today I finally moved my blog over to its new URL – http://mjturner.net/blog. All old URLs should redirect correctly, assuming my Apache mod_rewrite fu is strong enough…

I’ve been quiet for the past few months, but I’m still very much alive and well. One of the major reasons for being so quiet is that a month ago my family and I traded the sun and sea of Cape Town for the bright lights of London. We’re still getting settled (everything seems to take sooo long!), but things have been going very well so far. More on the move in future posts.

For those in the area, we’re now living in Horley, Surrey (near Gatwick).

With our recent acquisition of a number of Sun Ultra 60s, Jonathan and I have been doing a fair amount of CPU swapping to max out our machines.

Something odd that we’ve both noticed is that when we put a 450Mhz CPU into a machine that we didn’t receive with a 450Mhz CPU, it wouldn’t boot up. There’s no mention of CPU speed jumpers in the service manual, so we both put it down to different motherboard revisions, phases of the moon and the lack of a chicken sacrifice.

A few days ago I discovered the Sun 450 MHz UltraSPARC-II Module Upgrade guide, which details the CPU speed jumper settings for the Ultra 60 (see pages 3-5 and 3-6). Bah. Why doesn’t Sun bother documenting these things in the service manual?

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.