Archive for April, 2007

Sysadmins must be able to use a compiler.

Published at April 3, 2007 in All Posts. 2 Comments

Chris Josephes over on the O’Reilly Sysadmin blog just posted an article titled “It wouldn’t hurt you to use the compiler”, about sysadmins who won’t install anything that didn’t come prepackaged.

As a *nix admin, it used to be assumed that compiling software was part of the job.  While I’ve now reached the point where I avoid compiling things unless absolutely necessary, that’s more because vendor packaging has improved and using those packages greatly reduces my workload.  If I choose to compile something when there’s a vendor package available, I’m effectively nominating myself as a maintainer of a forked version of the package.  There needs to be a pretty good reason before I feel like doing this.

On the other hand, not being capable of doing this would be pretty scary.  Sometimes when things break it’s because of a bug in the software.  The bug might already be fixed upstream, you may even be communicating with developers who’ve fixed it in their source - but if you’re relying on someone to package it up for you before you can use it, you’re out of luck.

Also, there are times when you need to squeeze the most performance out of an application that you can, and usually this means compiling a version which is custom built for your environment.  Obviously if you can’t compile software yourself, this won’t be an option.

Finally, compiling software is frequently the only way to try out the latest versions of software you’re already using, or to get your hands on new tools that may be able to solve a problem in your environment.

Chris mentioned a couple of interview questions he asks prospective sysadmins in order to determine whether or not they understand the process of building software.  I’ve asked similar questions myself; and while our current environment includes users who sometimes need support when compiling their own code, I wouldn’t consider hiring a sysadmin in any position if they didn’t have at least a basic grasp of how to compile something from scratch.

A minor overhaul..

Published at April 1, 2007 in All Posts. 0 Comments

I just updated my Wordpress install for this blog, as it was running an old version. While I was at it I decided to install K2, even though I’d made a deal with myself that I wasn’t allowed to do anything with the layout until I’d actually started producing some content! So, I’m naughty.

Once Wordpress was updated I started having issues with the Apache rewrite rules it generates. The rules looked just fine to me, but they’re failed to determine whether a requested URI mapped to a real file. The generated rules look like this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  #RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

That translates to “Rewrite all requests that don’t map to a real file or directory through to index.php”. The reason for this is that template content (images, stylesheets etc) live under /wp-content/, which is a real directory, but other things (such as /about, or URLs to individual entries) don’t actually exist in the filesystem.

However, what was happening on my blog was that everything was redirecting to index.php - including requests for stylesheets, the admin pages, and so on. This meant that “virtual” URLs produced the right content, but it all looked terrible. Plus, because wp-admin is a real directory I was unable to access the admin site.

After about two hours trying to figure out what was going wrong (with a RewriteLog turned on and gradually raised to RewriteLogLevel 5 ) I eventually twigged. Wordpress, in an effort to be as user friendly as possible, generates its rules for use in a .htaccess file. I dislike .htaccess files in general, and hate the thought of doing Rewrites from inside them, so I move the rules into my VirtualHost container instead.

This worked fine on my other blog (varrqnuht.net), but those rules were set up ages ago. The old ruleset is 40 lines long, but the new one is just the one rule with two conditions shown above. Somewhere along the line the Wordpress guys must have started parsing the REQUEST_URI to grab the info they need rather than using apache to rewrite the request as a query string.

That’s an improvement, but because their generated ruleset assumes it will be running in the Directory or .htaccess context, they only have to worry about relative paths. However I’ve moved the rules into the top level of my VirtualHost container, so now the %{REQUEST_FILENAME} is being treated as an absolute path - and that’s not going to work!

The fix is easy (once you’ve figured out what the problem is - usually the hardest part). I just prepend the document root to the rules, like this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  #RewriteBase /
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

So simple, and so frustrating to have wasted a couple of hours trying to sort it out! Plus, instead of writing the post I’d intended to write, I’ve written this instead. But hey, content is content!