mod_perl on Debian

I've mentioned before that I'm thinking of bringing my webhosting in-house. As part of that, I installed Debian in a virtual machine here and started configuring it to be a web server.

The first task with any unfamiliar OS is to find where they put Apache. You might look in /etc/httpd, but that's not where it is on Debian. You could flail around looking everywhere, but a "find / -name httpd.conf" is how I found Debian's /etc/apache2 directory.

This had a structure I hadn't seen before, but it was pretty easy to figure out. I edited the 000-default file in "sites-enabled" to change DocumentRoot and ScriptAlias to where I wanted the web files to live and added Options Include so that I could use includes.

By the way, if you read almost any web resource on include files, they'll tell you NOT to do what I did next, which was to add "AddOutputFilter INCLUDES .html". The reasoning behind that is that Apache shouldn't have to scan every file for includes; you should restrict includes to a special extention (like .shtml) and tell Apache only to scan those files. Well, sure, but almost EVERY one of my pages has at least one "include", so I ignore that advice. Modern hardware generally makes that advice all but meaningless for most of us anyway.

Debian has this "a2enmod" method for adding Apache modules. All it really does is make a link from a file in /etc/apache2/mods-available to the same name in mods-enabled; the main apache2.conf does a "Include /etc/apace2/mods-enabled/*.load" and a "Include /etc/apace2/mods-enabled/*.conf". Of course you could put your own "Include" in manually, but this scheme does make for a clean config file, so I used a2enable to enable mod_speling and mod_include. After this I restarted Apache and confirmed that everything was working correctly so far. It was, so it was time to move on to mod_perl.

Mod_Perl

I have steadfastly ignored mod_perl for many years. There have been good reasons for that:

• I don't like to make significant changes to my running server. Mod_perl could break things, so I'd rather play with it before cutting it loose. I could do that on my hosted server, but it's not really convenient to put up an experimental server there.
• I did once try mod_perl 1.0. I don't remember what happened, but it was bad, scary, and I ripped it out of httpd.conf instantly.
• You have to be careful with coding for mod_perl because any sloppy variables can come back to bite you. I'd need to check and clean up a lot of code before I could implement this.
• Although using mod_perl is obviously more efficient (no constant recompiling on every access), modern hardware again makes the inefficiency unimportant: the systems are moee than fast enough without mod_perl.

But there's actually a deeper reason: there's no point in doing half a job.

What I mean is this: I could easily implement mod_perl to just run my existing scripts. I might have to clean up a few things as noted above, but I'm not all that sloppy, so it's probably not much. But given the power of mod_perl, it seems almost silly to me to just use it for that. Mod_perl lets you hook into Apache at every phase and that's just what I want: there's really no point in having Apache load a page that has an Include directive in it that references a Perl program that Apache will run with mod_perl. Why not skip a few steps and turn mod_perl loose before Apache loads anything?

>If you just want to run existing scripts, the Registry Scripts section of "Getting Your Feet Wet with mod_perl" will show you how to do that.

Indeed, why not? Well, for one thing because the documentation for mod_perl assumes that you know a lot about Apache, a lot about Perl, and for mod_perl 2.0, it also assumes that you already know a lot about mod_perl 1.0. It's extremely annoying to have to start by reading documentation about an older version - you know this is going to bring at least some things into your head that you'll immediately have to throw away when you finally get to the current documentation.

Moreover, I dislike reading on-line docs. Yeah, I know, odd thing for someone running this kind of website to say, but to my mind, web pages are great for short, quick and to the point information and very annoying for long and complicated expositions. When it comes to the latter, I'd rather have a book. Or two, or three.. so that's what I did: I visited Amazon and ordered three mod_perl books. Of course I'll review them here later, but my ultimate goal is to provide documentation for what I learn.

This isn't about doing it "better". I'm sure the docs at http://perl.apache.org/docs/ are excellent for those with the right background, but they are not right for me. I'm a dabbler: I'm not a Perl expert, not an Apache expert. I know what I want to do, and I can glean enough from those docs to know that I can do what I want with mod_perl, but those docs are not written for dabblers. That's my goal: a dabbler's introduction to using mod_perl for more than running existing cgi scripts.

However, my initial goal (to avoid unnecessary page loads is actually easy enough to do. Following the docs at Getting Your Feet Wet with mod_perl, I created and configured the Rocks.pm handler module as directed. However, I added one more line to it:

 #file:MyApache2/Rocks.pm
   #----------------------
   package MyApache2::Rocks;
   
   use strict;
   use warnings;
   
   use Apache2::RequestRec ();
   use Apache2::RequestIO ();
   
   use Apache2::Const -compile => qw(OK);
   
   sub handler {
       my $r = shift;
   
       $r->content_type('text/plain');
       print "mod_perl 2.0 rocks!\n";
       print $ENV{REQUEST_URI};
       return Apache2::Const::OK;
   }
   1;
 

When I attempted to access http://localhost/rocks/foo.html, the result was what I hoped for:

 mod_perl 2.0 rocks!
 /rocks/foo.html
 

And of course access like http://localhost/rocks/Nosuch/nosuch.html also gave me the right response:

 mod_perl 2.0 rocks!
 /rocks/Nosuch/nosuch.html
 

My bet is that I can access that page location without looking in $ENV; the important thing is that I can now process that whole request entirely in Perl: no pointless intermediate load of a file with the Include in it. More to the point is this: I can change their suggested configuration from this:

   <Location /rocks>
       SetHandler perl-script
       PerlResponseHandler  MyApache2::Rocks
   </Location>
 </pre>
 

to this:

 <pre>
   <Location />
       SetHandler perl-script
       PerlResponseHandler  MyApache2::Rocks
   </Location>
 

Now ALL access to localhost (including cgi-bin access) goes through this handler. And that means that I can handle all requests through one Perl script, parsing the REQUEST_URI and acting appropriately.

That's enough by iteslf for me to do 99% of what I want; I'm sure I can pick up the rest from the books and other web resources. That's definitely the direction I want to go.

So that's where I am right now. I've ordered a handful of books, and uniformed agents will soon bring them to my door. I'll read, digest, experiment, and possibly read more. Then I will return here and try to produce a guide that the rest of you who don't want to become either Apache or Perl experts might have a chance of understanding.

In the meantime I'm playing and picking up what I can from the on-line docs. It's a lot of fun, actually: as I start to realize more about the power this gives over Apache, I keep getting up from my chair and laughing out loud.. this is wonderful stuff.