APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

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.


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 more 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:

  package MyApache2::Rocks;
  use strict;
  use warnings;
  use Apache2::RequestRec ();
  use Apache2::RequestIO ();
  use Apache2::Const -compile => qw(OK);
  sub handler {
      my $r = shift;
      print "mod_perl 2.0 rocks!\n";
      print $ENV{REQUEST_URI};
      return Apache2::Const::OK;

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

mod_perl 2.0 rocks!

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

mod_perl 2.0 rocks!

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

to this:

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

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.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> using mod_perl on Debian Linux


More Articles by

Find me on Google+

© Anthony Lawrence

Sat Feb 23 22:20:20 2008: 3699   drag

I am glad your having fun.

Personally I'm a python guy and I've been having fun with the newer WSGI standard that has imerged come out of the insane proliferation of Python-based frameworks. It's cool stuff how much power this sort of stuff gives you.

On a side note when your learning some new program you've installed in Debian using their package system it's usefull know some of the tools available to you for finding installed files quickly. One of those tools is the dpkg-query program. You can just use 'dpkg' as a general front end, but if you want to look up stuff in a man file then you'd use 'man dpkg-query'. Two things to keep in mind is that this tool is for stuff you have installed and that they don't include files automaticly generated by install scripts included in packages. (this was done on a lenny/sid debian install)

So for example looking up stuff about apache packages you've gottent installed.
~$ dpkg -S apache

This lists filenames with 'apache' in it's name. You'll notice that 'apache2.2-common' comes up a lot. (depending on what all you have installed, of course)

So you look at the discription of that file.
~$ dpkg -p apache2.2-common

You get the package name, the priority, the section, the install-size, the maintainer's name and email address, archictecture, version number, what legacy package it replaces, it's dependancies, suggested packages, conflicting packages, filename, size, md5sum for the package, and then, most importantly, the Description.

If it seems like something you were looking for you can then list the entire contents of the package with:
~$ dpkg -L apache2.2-common

Other usefull things is to head out to the /usr/share/doc/<package name> to see developer included documentation, debian provided documentation (including information about changes that deviate from upstream), and often example code and configurations.

When playing around with new software I also like openning up aptitude and using '/' to scan for the packagename. Then when you enter in a package discription you can find usefull information about the package and, what I like, packages that are recommended by that package and packages that depend on that package. I often stumble apon stuff that I later find very usefull.

Sometimes some feature you want may not be present in a package, or you have this patch you want to compile into some program that otherwise you'd just install through apt-get. Or maybe you'd like to backport a package from the testing version of Debian without pulling in a lot of dependancies from that into a stable version of Debian. Well Debian provides for this.

So you can setup extra preferences for repository priorities and package-specific preferences in /etc/apt/preferences (link)

Then you can setup some deb-src entries into your /etc/apt/sources.list file.

To pull in build-time dependancies for a package you can go:
~$ apt-get build-dep apache2.2-common

After that is done then you can pull in the source code for the package. You'll notice that the relationship from source code to binary package is not a one-to-one. The source code package apache2 will provide binary packages apache2, apache2-doc, apache2-mpm-event, apache2-utils, apache2.2-common, and a few others.

The easy way to find out information like that is to look through the pachage web interface at packages.debian.org

Then to get the source code downloaded you make a directory, go into it and run this command:
~/apache-stuff $ apt-get source apache2.2-common

It'll download the upstream source code, package discription files, and debian diff. It'll untar the source code and patch it. At this point you can then go the apache2-2.2.8 directory and do whatever you want to the source code there.

Once your finished and have done everything you want you can then run this command:
~/apache-stuff/apache2-2.2.8 $ dpkg-buildpackage

That will build all the packages avaliable from that source code package, which can take quite a while. The resulting deb files will be put in the parent directory and you can install them using 'dpkg -i package-name.deb'. Dpkg is to low-level to do any dependancy resolution so you may end up with a error if some runtime dependancy package is not installed. This can be resolved with the 'apt-get -f install' which will automaticly try to fix any pending installations.

The only major exception that I can think of is when you want to install a custom kernel. For that I like e to use the make-kpkg command...


Sun Feb 24 11:54:27 2008: 3701   TonyLawrence

Thanks, Drag.

Thu Dec 9 01:42:10 2010: 9151   Questorian


Actually Perl now has PSGI in a similar was to Python WSGI - and Plack is it's implementation:


This is the way to go nowadays - and use a web framweork like Catalyst, Jifty, etc too

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

This post tagged: