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











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> using mod_perl on Debian Linux


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

#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>
 

to this:

  <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.




If this page was useful to you, please help others find it:  





3 comments




More Articles by - Find me on Google+



Click here to add your comments
- no registration needed!




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 http://wiki.debian.org/AptPreferences

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

gravatar
Thanks, Drag.







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

gravatar


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

http://search.cpan.org/perldoc?PSGI
http://search.cpan.org/perldoc?Plack

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

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

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. We appreciate comments and article submissions.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

pavatar.jpg

This post tagged:

       - Blogging
       - Linux
       - Perl
       - Web/HTML


















My Hard Truths about Easy Money on the Internet will show you how to make money on the Internet!

book graphic Internet Income guide


Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)