The new Apache HTTPD server, v2.4, was recently released. I wouldn't say I've rushed out to try it, but I'm doing what I can to get the new stuff to work like the old stuff.

One thing I've not done is embraced the Ubuntu-managed Apache installation. I'm not quite savvy with the way they implement the different modules I want, nor am I quite comfortable with trying to blend my configuration with theirs. Probably more because I've dragged an ages old configuration with me through the ages and made just enough changes with each upgrade to make it work.

What's so tricky about my Apache configuration? For starters, there are over 30 virtual hosts tied to a few dozen domains. Any of these may be showing static pages or images, running a PHP (like this blog) or PERL (like Bugzilla) script, be tied to a Subversion or Git repsitory, or fronting a Tomcat server.

I've been compiling my own Apache server for, well, ever. I include some helpful things like mod_speling, and I'm required to have somethings like mod_dav (for Subversion). I prefer mod_jk to using a proxy to get to Tomat, mostly because Tomcat then has access to everything in the request. I have added some things because I needed to play with them for work (like mod_security). I've also weeded out some of the modules I don't use or want making things fat. I've chosen some modules to be statically linked, but most are dynamically loaded.

My reservations with taking the package-managed version from the Ubuntu repository start with the package-managing way to select modules. I'm sure they do a fine job of managing requirements (like Subversion requiring mod_dav), but I'm not sure that the modules are trimmed of some of the fat. I guess I'm not quite as concerned about what's statically or dynamically linked, but I want to be sure that I have what I need.

I'm also not quite comfortable with the way that Ubuntu steps on the configurations of some of the servers it installs. Until recently, because it hadn't installed Apache, it left the configuration files alone. In one of the recent updates, as I already blogged, it deleted the /etc/init.d/apache script I'd created to start and stop the server. It hasn't yet stepped on the other configuration files, but I've had it stomp on my Sendmail and Dovecot enough to really make me consider outsourcing my e-mail.

A final reason I maintain some of those servers from source is that the repositories often lag behind the current releases a little more than I wanted to. And, like my Sendmail server, it can be the case that the repository maintainers decide to go a different direction, which can leave me in a lurch (I've still not crammed enough into postfix or exim to know how to handle the virtual domains, virtual users, milters, and other tweaks I've got).

Plus, building and configuring the servers from the ground up has both satisfied a hobby need of mine, and kept me intimately familiar with the software. Yes, I have run into many peers who can't configure a web server, even when installed using some package management, and not even when given a GUI tool (I will use Webmin for some things, I admit, but for ease, not because I don't understand the underlying configurations).

That all said, I started with my straight download of the HTTPD software, and using the last config.nice, started building the new software. I got the HTTPD to build easily enough, and even got a few of the modules to install. I added an updated PHP and ModSecurity. I had a little hiccup with the updated Subversion, but a few Google searches led me to the sed -i 's#save_errno#aprerr#' subversion/mod_dav_svn/util.c I needed to do to get that to work.

I copied the necessary configuration files to a new folder, and tweaked the copy of the new httpd.conf to include my server's name and such. I touched up the other files to reflect the configuration changes, and gave the server a try. It failed the first time because I missed a few "deny from all" that needed to be changed to "require all denied" instead. Fixing all of those allowed the server to start.

A quick test revealed a few of the sites worked, but some returned "forbidden" errors. I restarted the old server and looked through the configuration again. I can't see any configuration or permission differences between the different virtual hosts. The PHP didn't launch, instead serving PHP source instead of HTML; likewise PERL failed to render, instead returning the source. The pass-through to Tomcat worked just fine, and the Subversion folders correctly asked for authentication, but then failed to deliver the project browsing.

I've got a few more ideas, but I don't want to leave the web server down for so long. My sites tend not to get too much traffic, but there are a few that do (and Google or someone always seems to be spidering something).

I'll give it a whirl in a VM until I get it to behave. Heck, maybe I'll even give the package-managed deployment a shot.