Thanks to Debian bug 407171, if you had mod_proxy installed in apache2, and upgrade to etch, it’ll also install mod_disk_cache, which means your /var partition is going to fill up quite quickly.

This happened to 2 CLUG servers.

I don’t think this is the correct behaviour, and I’m even more suprised to see that it the appearance of the bug is documented in a bug-report.

I've migrated my teeny-weenie Xen web/mail server to Debian/etch. It hasn't even been rebooted (it would be a shame to spoil the uptime :-) ):

It runs Lighttpd, a small and fast little webserver, popular in the Rails world. Lighttpd with PHP-fastcgi is probably faster than apache, and uses much less RAM.

With etch, I've finally been able to get mod_rewrite to work. So my Zapiro archive has nice URLs now :-)

Lighttpd has a very nice configuration style:

It's more logical than apache, but you have to watch out for rewrite->redirect->rewrite loops. So if you change to a clean URL syntax, you can't put in rewrites from index.php?/uglurl to /uglyurl because /uglyurl rewrites back to /index.php?/uglyurl, and you get a loop :-)

I’ve done etch upgrades in the past (i.e. before etch came out), and they were sometimes quite hairy. Especially the transition from ssh to openssh-server and openssh-client. I had a few broken upgrades…

Since etch has come out, I’ve been upgraded a few machines, and it’s a piece of cake. In fact the CLUG webserver and backup-server have been upgraded.

My servers tend to use custom kernels without initrds, so upgrading is quite simple. The release notes seem to cover it pretty well. There are only a couple of gotchas I’ve had:

Upgrade vim with an aptitude install vim before you do any dist-upgrading. Personally, I like to use vimdiff for configuration file changes. This means I can keep the configuration file format and comments of the latest package, and my configuration changes from when the machine was originally set up. If vim is half installed, you can’t run vimdiff…

When you are done, you might need to purge hotplug:

You can also remove non-US from your sources.list.

I spent a lovely weekend morning setting up monitoring on servers - yes, what fun :-)

I like all my servers to run logcheck, smartmontools, sysstat, and lm-sensors.

logcheck means watching your email every hour, and adding in yet more ignore rules for things your server thinks it’s perfectly OK to spit out.

smartmontools means waiting to see which attributes it’s going to complain about, making sure it’s set up to mail you about bad sectors, and getting this all in inside the 128-character line-length limit.

And lm-sensors, well that takes a lot of tweaking, to get all the alarms to stop ringing, labelling the right temperatures, and ignoring the disconnected pins.

Ugh, it’s painful work, but it helps in the long-run…

I finally found a good blog post on the subject of getting Postfix to do SMTP-AUTH via SASL.

I went one step further, and instead of moving /var/run/saslauthd/ to the Postfix chroot, I did a bind mount:

/etc/fstab:

Postfix was announcing methods like CRAM-MD5 which can’t be supported by the PAM backend, so I restricted them down to PLAIN and LOGIN (over TLS only, obviously):

/etc/postfix/sasl/smtpd.conf:

Now, it’s working nicely, and I can IMAPS and SMTP-AUTH-TLS to my mail server from anywhere.