Apache/perl package install and testing (e.g. mod-perl and Mason)

Posted by mwarnock on Wed 17 Aug 2005 at 14:11

Tags:

I would like to install Mason (libhtml-mason-perl) on my plain-vanilla debian stable (Sarge) system. I tried Mason on an old apache-1.3 setup and LOVED it, much nicer than PHP on many fronts. I am an old linux/apache/perl user (formerly redhat), but pretty new with Debian, Apache2, and Mason. I am working my way up several learning curves at once, so please be patient with me.

Please bear in mind that I often administer remotely over ssh (often over a broadband link with significant latency delays) on relatively low-powered machines, so I tend to favor minimalist command-line and text-based tools over curses-, web-, and X-based tools, which can be annoyingly slow for interactive use, require a larger disk/memory footprint, and may introduce security issues.

I have installed apache2, libhtml-mason-perl, libapache2-mod-perl2, and speedy-cgi-perl, all per the Debian package info for Mason. I may not have installed them in the right order, though, as I have pieced together what I needed as time went on (having started with apache 1.3, not apache2, which requires different dependencies). I note for example that I still have an /etc/apache directory, though it has nothing in it, all the apache2 files are in /etc/apache2. Should install order make a difference?

I have created Mason test files to be served by apache2. I have added the documented Mason directives to the appropriate vhost config file to get Mason loaded, as follows:

PerlModule HTML::Mason::ApacheHandler
<Directory /home/www/vhosts/sbrx.com/html>
        SetHandler perl-script
        PerlHandler HTML::Mason::ApacheHandler
</Directory>

Note that I changed the "<Location />" directive to a more specific "<Directory>" command to limit Mason parsing to this particular vhost directory only. According to the docs as I understand them, anything in that directory should now be parsed by Mason. (I'll worry about filename-specific action later.)

Apache2 loads without complaint, but does not parse (just transmits) the Mason code. Obviously, something in the module chain is not loading or parsing the files as it should. I don't have the same problem with PHP, which I assume fits in the apache toolchain in a similar way. Nor did I have this problem with Apache1, though Apache2 is much more SysV-like in its config architecture, with drop-in module directories and such, rather than the big httpd.conf file of apache1, so maybe I'm just missing something, config-wise. I'm not sure where I should be looking for mod_perl, if it isn't in

I suspect mod_perl may not be loaded, so that PerlModule may be ignored, or else something in Mason is not quite right. Any ideas?

I can't find a flag in the apache2 binary (httpd in the apache docs) that lists modules that are loaded dynamically (only precompiled), nor anything in any log files (as far as I can tell, apache only logs to its "errors" and "access" logs, nothing much in /var/log/messages or elsewhere that I know of). I can get a list of vhosts, but that seems to be about all in the way of "what is apache REALLY doing?" info. Asking Apache2 to parse the config files only gives a "Syntax OK" message, which doesn't help much. Am I missing something?

So I have several related questions for you apache/perl gurus familiar with the "Debian Way":

1) How can I know what dynamic apache modules are in fact loaded and active?

2) More specifically, how can I know if mod_perl is working properly, and whether it has loaded Mason (or any other needed Perl module)?

3) Should an "apt-get install libapache2-mod-perl2" have correctly installed, loaded, and configured mod_perl, or is there something more I need to do, and if so, where would I find Debian documentation of such things? For example, server-info needs to be separately enabled to have it load, and other modules might be similar. If you install a module like mod_perl2, does Debian assume you want it loaded by default, or do you have to do something else?

4) Is there any kind of "debug" mode for apache, where you can submit a http request in some form, and have apache either log or otherwise explain exactly what it does in terms of "Location" or "Directory" directives, request-handlers, and similar magic, before it actually serves the request?

5) How best do I manage Apache/Perl modules, and Debian packages? I often find I need an Apache or CPAN module (like php4, mod_perl, DBI, DBD::Pg, or Mason) but I don't know offhand if there is a Debian package, or if so, exactly what it is named. There is a temptation to just install perl modules through CPAN, and of course the perl/apache docs always say "compile your own". This of course leads to "update hell" later. Am I right in concluding that I should almost always use the Debian package (unless I really need some different compile-time option)?

6) Is there anything in Debian packages that does the kind of live internal testing that CPAN modules (usually) do on install, to ensure they are working right?

7) What is the easiest way to find the correct debian name of a package I need, or to search available packages by keyword, so I can readily see what the options are? I'm thinking of a "man -k" analog, but for available debian packages, not installed commands. For example, is there an easy way to search the available package list for anything containing "mason" or "perl" or "DBI (and) perl", especially where case and word order often get munged in package names? You really have to hate searching debian.org (when search works) or googling (or worse yet, in lynx over ssh) for this kind of info which is probably readily available locally after an "apt-get update".

8) I find myself a bit confused by the plethora of package tools: apt-get, dpkg, and countless other command-line tools, not to mention the frontends (aptitude, synaptic, etc) which I find confusing and awkward to use. Maybe I just need more time. Are there some good primers or references out there for the use of the debian package tools, especially in the area of "how do I find, install, and configure the right package, with all appropriate dependencies (should be automatic), recommendations, suggestions, in the right package order, and make sure it all works as it should?"

9) Is there an easy way to reconfigure a package more interactively on a one-off basis if it seems to be broken, perhaps having it re-examine its environment to see if there are some new packages installed that would affect the configuration (e.g. recommended/suggested packages you might have added since install)?

Sorry about the length of the post. Thanks in advance for any pointers. I'm obviously still getting used to Debian, but really like what I have learned so far, and this site has had some great ideas on it.

 

 


Posted by Steve (82.41.xx.xx) on Wed 17 Aug 2005 at 13:36
[ Send Message | View Steve's Scratchpad | View Weblogs ]

I'm afraid I can't help you with all your questions, but every little bit helps, right?1. Listing Loaded Modules

You can see which modules are built into your Apache/Apache2 server by running:

/usr/sbin/httpd -l

The dynamic modules can obviously differ, but you can enable the server-info handler for Apache/Apache2 and list them. Since you mention Apache2 we'll use that.

Run :

root@lappy:/etc/apache2# a2enmod info
Module info installed; run /etc/init.d/apache2 force-reload to enable.

Then uncomment out hte relevent lines in /etc/apache2/apache2.conf:

<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from .your_domain.com
</Location>

Now you can restart the server with:

/etc/init.d/apache2 force-reload

(If you're just testing locally you might as well use "Order deny, All", "Deny from none", and "Allow from all" instead).

That should show you which modules are loaded, along with their current configuration. (This is very similar to the monitoring Apache with mod_status which was previously covered.

2. mod_perl testing

I'd suggest perhaps looking at the mod_perl book for setup/debugging techniques. (Although I'm not sure how relevent it is since it appears to cover only mod_perl 1.x)

Failing that perhaps a more focussed group like the venerable Perl Monks?

5. Managing Perl Modules

Personally I don't like mixing Debian packages with CPAN packages, partly because it tends to eat up space invisibly in ~/.cpan but more seriously because it's harder to migrate machines with "hidden software" upon them.

Typically I will just build Debian packages of Perl modules, as that way things are simpler for me.

The Debian Perl policy does setup the naming scheme for Perl packages which can be summerized as:

FOO::Bar   becomes   libFOO-BAR-perl

e.g. HTML::Template is libhtml-template-perl, and DBI is libdbi-perl. There may be exceptions but I've never encountered them ..

7. Searching Packages

Two answers to this:

The first is more likely to be of use to you, but the second may be more important in the future.

8. Debian Package Tools

There are several articles introducing these topics posted upon the site, along with related ones.

Anyway the Debian package tools are to be layered upon lower level tools.

At the lowest level is the binary .deb file, which is manipulated with the dpkg tool. If you're familiar with RedHat's RPM format then the .deb is analogous. (If you wish you can read the gory details of manipulating Debian binary packages.)

Packages can be installed with :

dpkg --install foo.deb

Once installed you can remove it with:

dpkg --remove nameOfPackage

(The minor suprise here is that you install with the filename of the .deb file; but uninstall with the name of the package).

As a layer above the dpkg foundation the apt-get, and aptitude tools will allow you to install a package just by its name.

So rather than having to download the foo_xxx_i386.deb file manually to install it you instead download a list of available package with:

apt-get update     /   aptitude update

Then once you have the lists of available packages, and their dependencies, either command can determine for itself the full name of the actual deb file which is required and its location within the Debian archive.

Installation then proceeds, along with any dependencies once you run one of:

apt-get install foo    / aptitude install foo

The .deb file(s) will be downloaded and installed in a similar way to the "dpkg --install ....deb" method; the relevent packages first being downloaded to /var/cache/apt/archives (Where it will stay until you run "apt-get clean", or "apt-get autoclean".)

(The list of packages which are downloaded, being specified in the file /etc/apt/sources.list will be kept in /var/lib/apt/lists/)

9. Reconfiguring Packages

I'm not sure I fully understand your question; but to reconfigure a single package interactively run:

dpkg-reconfigure packageName

(As root)

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by mwarnock (66.87.xx.xx) on Wed 17 Aug 2005 at 16:42
[ Send Message ]
Thanks for a very helpful post.

I have (and have read and used) the mod_perl book, but as you say, it is pretty 1.x-specific.

Your "finding packages with apt-cache search" was just what the doctor ordered for a long frustration as a debian newbie. Thank you.

I also was not aware aptitude could be used with command-line arguments. I find the curses interface big, clunky and awkward, with too many modes with inconsistent nav keys. Maybe I just need more time with it, but command line use looks good right now.

Looks like I need to spend more time browsing around this site, it seems just full of gems. Thanks for a great source of Debian help.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.236.xx.xx) on Wed 17 Aug 2005 at 14:43
Hi there!

I can't answer everything either, but I can say one thing: You shouldn't use the libapache2-mod-perl2 that's in Sarge. Unfortunately, the packages weren't updated in time for the release, so Sarge contains a pre-release which is incompatible with the final mod_perl 2... :-( So, any code that's uptodate with mod_perl 2 won't run on Sarge, and any code you develop on Sarge for mod_perl 2 won't run on any other OSes... Nasty situation...

However, nobse has made a backport, which is currently in incoming on backports.org. The libapache2-mod-perl2 packages work for me, but the libapreq2 that I also depend upon doesn't.

So, well, this isn't straightforward, I'm afraid, but it may help.


Cheers,

Kjetil

[ Parent | Reply to this comment ]

Posted by mwarnock (66.87.xx.xx) on Wed 17 Aug 2005 at 16:27
[ Send Message ]
Thanks for all the help. I guess I had used server-status under 1.3 but not server-info. server-info seems to provide much of the apache debugging/configuration info I was looking for, and it does appear to show that mod_perl isn't even loading.

As a Debian newbie, I guess I don't understand how backports/fixes work. Is this a known bug that will be fixed in the distribution (given some more time)? Or do stable packages only get security fixes, no matter how horrendously broken they may be in terms of functionality? Do I need to watch "backports" sites for this kind of thing?

Please explain your last two sentences a bit further, if you don't mind, please. Is it the "backported" libapache2-mod-perl2 packages that work for you, while libapreq2 doesn't? Isn't libapreq2 required for mod_perl2? I read that libapreq2 contains the perl language interface to apache, and I assumed you couldn't run mod_perl without it?

I just read the following at MasonHQ.com:

In mod_perl version 1.999022 (2.0.0-RC5), there was a big renaming of the namespace of the mod_perl2 API. This was not backward compatible, and many modules, such as libapreq2, CGI, and HTML::Mason had to be updated to support the new API. If you upgrade to mod_perl-2.0.0 and are using any of the modules below, you will also have to upgrade the modules to the versions indicated. CGI 3.08 libapreq2 2.05 HTML::Mason 1.30 Support for mod_perl-2.0.0 has been released as Mason-1.29_02 (or newer). If you get errors about the Apache2::Request object, you have two choices: 1) install libapreq2, or 2) change MasonArgsMethod to "CGI". Apache2::Request is part of the libapreq2 package. It is still in the development stage, so to find it on CPAN, you must search for "libapreq2", and not for "Apache2::Request". Mason 1.27 (released 10/28/2004), contains support for Apache/mod_perl-1.99.

The current debian Mason package is 1.27. Maybe it is just easier to forget about apache2 and go back to apache 1.3... :^(

[ Parent | Reply to this comment ]

Posted by cfry (204.153.xx.xx) on Thu 18 Aug 2005 at 15:27
[ Send Message ]
Note that I recently uploaded Mason 1.30 to Debian. It is currently in unstable, but should drop into testing next week. Hope you enjoy it!

Charles

[ Parent | Reply to this comment ]

Posted by Anonymous (209.161.xx.xx) on Sun 7 May 2006 at 05:28
I successfully installed and configured
the stable (libhtml-mason-perl 1.26-1) mason.

The instructions are in:
/usr/share/doc/libhtml-mason-perl/README.Debian.gz
(Using HTML::Mason with SpeedyCGI)

[ Parent | Reply to this comment ]

Posted by Anonymous (68.38.xx.xx) on Fri 15 Sep 2006 at 02:42
You can run the lynx -dump -head http://localhost/ command to dump the headers that the server displays. If mod_perl is installed properly, you will see mod_perl/version information in the header information. (apt-get install lynx)

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1045 votes ~ 6 comments )