Sat Jul 25 23:30:16 EDT 2009
copper II: apache virtual host configuration
Blogathon 2009 wordcount: 907
So I purchased a dedicated server from serverpronto (the starter+) on advice of Steve, because I was tired of using NFSnet's e-mail forwarding to a gmail account, since that toolchain relies on several people to do their job perfectly, one of which (Google) who doesn't even get paid for privilege. I'd much rather have the whole mess in my hands, so I can get mad at myself when it doesn't work.
But configuring postfix is hard, and apache is easy, so I decided to get apache working first.
The server itself I named copperII, in memory of the late, great, copper.
Moving was a simple matter of four ftp operations, and one scp. The Pointless Four consist of either a single index.html file each, (7chon, bierwagen) or an index and an image. (kyonko, unitinu)
bbot.org, of course, has quite a lot more stuff, and thus required a recursive scp. Amusingly, this had to be done from copperII, and not from my laptop, since a architectural bug requires a fairly insecure workaround to be able to ssh out from ssh.phx.nearlyfreespeech.net. Bizarrely, this presents with the error message "Host key verification failed", when the problem is that it can't open /dev/tty.
I copied each site to its own directory under /srv/www/vhosts/, then proceeded to make a virtual host configuration file for each site in /etc/apache2/vhosts.d/ by editing the provided template file with the information for 7chon.org, then using a simple sed pipe operation of the form "s/target/replacement/g". S means substitute, and the final flag means "globally", or else sed will just replace the first instance of target with replacement, which is hilariously confusing the first time you forget the final g.
copperII:/etc/apache2/vhosts.d # sed s/7chon/unitinu/g 7chon.conf > unitinu.conf
copperII:/etc/apache2/vhosts.d # sed s/org/us/g unitinu.conf
The format of the virtual host config file is fairly straightforward. For minimum functionality, all you have to do it set ServerName to the domain name, then DocumentRoot and the final Directory tag to the full directory path. Once you do that, run httpd2 -t to check the configuration files (it should return "Syntax OK") and whatever distro-specific services manager operation to restart apache. In suse, it's /etc/rc.d/apache2 restart, though you should call it with status first to make sure it's running.
After that all you need to do is change the A records for each domain to point at the IP address of the server and it magically serves different content depending on what the client asks for! Magic!
On copper I set up logging so that bbot.org got its own log file, while the other domains logged to a common file. This is done by setting the CustomLog variable to /path/to/log and type of log, the type of log, if not one of the default log formats, being defined by LogFormat.
bbot.org was told to log to /var/log/apache2/bbot-access and bbot-error using the default combined log format, but the other sites had to use a custom log format that included the name of the site in the common virtual host log file, or else I would get confused, and cry. Fortunately for me, Apache provided an example of a common vhost log format in the documentation, saving me from having to exercise independent thought.
LogFormat "%v %l %u %t \"%r\" %>s %b" commonvhost
CustomLog /var/log/apache2/vhosts-access comonvhost
This started logging to the correct location, but all it actually logged was "comonvhost" over and over, indicating that it had correctly parsed the configuration file, but had ignored the LogFormat setting, for some reason. You should be able to see why.
Correct! As stated in the Official Apache Foundation Documentation for HTTPd 2.0, there is a typo in the CustomLog setting, specifying the log format as "comonvhost" instead of "commonvhost". Apache, slavishly obeying what I told it to do instead of what I wanted it to do, proceeded to log the word "comonvhost" to the access log on every access. Thanks, Apache.
This can be thought of as an example of the age old SQL injection exploit, only implemented in brain matter, and thus impossible to patch. I implicitly trusted the documentation, and thus copy and pasted the code snippet into my configuration file without thinking about it. Thanks, brain.
Next: Awstats, Postfix, and the TF2 Dedicated Server!