wnd's weblog

Using obscure Apache 2 modules can mean asking for trouble. Why would’ve known?

Today, I upgraded chikan.katei.fi to Debian GNU/Linux Squeeze. I prepared for the opration by going through release notes and reading about possible caveats. Everything went smoothly from upgrading the kernel to upgrading to GRUB2. Because I generally tend to believe that Debian maintainers know it better than me, I often choose to replace my own configuration files with maintainer versions – only to merge my settings manually. When I was supposed to be finished, I realised that my Apache 2 configuration wasn’t quite working as intended.

I spent quite some time trying to figure out why my virtual hosts were not working. More precisely, why could Apache 2 find the configuration files and accept DocumentRoot but not find the actual files it was serving. I also noticed that disabling ChrootDir option would make things work just like magic. Eventually I realised that Apache root process was chrooted to one directory and the workers in another under the main root. This didn’t look healthy as symlinks at worker root could no longer be followed.

A quick run of querybts revealed that Apache 2.2.10 had introduced a new configuration option: ChrootDir. This caused mod_chroot to chroot the main process and Apache to chroot the workers one step deeper. At first I tried disabling mod_chroot, but I wasn’t happy with Apache main process being in the wild, and decided that built-in ChrootDir wasn’t the way.

After some consideration I decided to compile a special version of mod_chroot (or libapache2-mod-chroot). A version that would use configuration keyword ModChrootDir instead. I know this was ugly but at least it did the trick. It did the trick quite painlessly, I might add.

Lesson learned: Using obscure Apache 2 modules can be asking for trouble. mod_chroot hasn’t been updated for nearly four years so I should’ve known better. Perhaps I should see if using built-in chroot would be a good idea after all.