Just a quick note on some Apache stuff I figured out last night. Those of you who either aren’t technical or aren’t likely to be near Apache might want to skip this one. Ditto for the folks that already know Apache well. Moving along…
The problem I was trying to solve was actually fairly simple. We at RedMonk have multiple domains: redmonk.com, red-monk.com, monkchips.com, peopleoverprocess.com, tecosystems.org and so on. When we were running on top of a managed server, setting up new domains was the province of the managed server interface. Point this domain to this directory, and done.
On our coloed box, however, all the above domains know to do is resolve to our machine. So since our switch, monkchips.com and tecosystems.org, specifically, have been resolving to the basic redmonk.com rather than redmonk.com/jgovernor and redmonk.com/sogrady respectively. With me so far?
In essence, our problem was one of redirection. I needed to redirect incoming requests to another subdirectory on our machine. Seemed pretty simple, particularly because I have some experience with that in the form of Apache .htaccess files. A couple of quick searches led me to conclude that a .htaccess file placed in the root of our webserver that contained the following:
Redirect 301 http://www.tecosystems.org /sogrady
Should turn the redirection trick nicely. You Apache folks in the back of the room snickering at me, pipe down – I’m a confessed Apache noob.
After trying this, I was immediately presented with a very basic problem in that it didn’t work. As in, nothing happened. tecosystems.org continued resolving to redmonk.com as if the .htaccess wasn’t even there.
Back to the forums I went, and I discovered that my .htaccess file was not active for a simple reason: the default Ubuntu Apache config turns it off. The config for an Apache server in Ubuntu reads:
Options FollowSymLinks
AllowOverride None
I’ve bolded the ‘None’ because that was the problem. The none tells Apache that nothing – .htaccess files included – can override the standard configuration. It ignores the .htaccess file, in other words. So that was relatively easily remedied by changing AllowOverride None to AllowOverride All. Patting myself on the back for being so terribly clever, I hopped on a browser, headed to redmonk.com and was presented with an HTTP 500. That’s a problem.
After a bit of trial and error, I discovered that it was in fact the redirection line that was causing the problem. As soon as I removed that, everything was kool & the gang and resolving. Except for the fact, of course, that I still did not our vanity domains working properly.
More research led to the discovery of Apache’s virtual hosts facility. I was loathe to try this because my last experience with the functionality on a Solaris 10 box was while not technically classifiable as a disaster, not terribly fruitful either. But it seemed like the best option available to me.
On Dapper – the version of Ubuntu we’re running as our production server – the Apache file is split up, and the virtual hosts are located in a separate directory – /etc/apache2/sites-enabled, in our case. After looking at the default, and a couple of examples online, I thought that it didn’t look all that difficult, so I created a file (I’d display it, but don’t know how to escape everything in MT) called 001-tecosystems, dropped it in /etc/apache2/sites-enabled, and restarted Apache (/etc/init.d/apache2 restart). What does that do? Go hit www.tecosystems.org and see. As I’ve been told, Apache can be easy to configure – if you know how to do it.
Despite the success in getting the basic domain work done, there are still a couple of problems. The virtual host set up seems to break relative links; the blog templates, for example, were unable to find their CSS files until I provided them an absolute (http://www.redmonk…) path. Normally, this wouldn’t be a problem – as the CSS fix demonstrates – but as covered the other day, Dojo doesn’t like absolute paths so the tooltips over at sogrady.org have broken. Also, I have yet to get subdomains (wiki.redmonk.com) working via a virtual host. When I tried to set up one for the wiki, it loaded wiki.redmonk.com but appended index.php on a dozen or more times. So no joy on that score.
So overall, Apache’s not too difficult to work with. A little obscure and esoteric at times, but manageable. The real question is whether the above – as I’ve contended previously – seems like an opportunity, and if so, for whom? More on that later.
