Perl Config for VirtualHosts
Hi
Folks,
I've been
grappling with this for a while, and was wondering if anyone could help me
out...
I'm trying
to set up a series of VirtualHost sections in httpd.conf using Perl. I want to
set the PerlHandler for the VirtualHost to "perl-script", but I want to define
several Location sections with the PerlHandler set to
"default-handler".
I'm using a
structure like this to define the VirtualHost sections (the $xp is an XPath
object using Matt Sergeant's XML::XPath module):
$region =
$xp->findvalue("./\@region",
$instance); $address =
$xp->findvalue("./address",
$instance); $sitename =
$xp->findvalue("./name",
$instance); $admin =
$xp->findvalue("./admin",
$instance); $ext =
$xp->findvalue("./ext", $instance);
$VirtualHost{"$sitename:8080"} =
{
ServerAdmin =>
"$admin",
DocumentRoot =>
"/home/httpd/web/$appname/web/pub",
ServerName =>
"$sitename",
ErrorLog =>
"/home/httpd/var/logs/apache/$appname.error_log",
TransferLog =>
"/home/httpd/var/logs/apache/$appname.transfer_log",
PerlSetVar => "Region
$region",
SetHandler =>
"perl-script",
PerlHandler =>
"HTML::Mason",
};
Now this
works great - everything is cool. However if I add the following to the
$VirtualHost{} assignment:
Location => [ "/ext" => {
SetHandler => "default-handler" } ],
Or if I try
to set up an assignment outside that structure with:
$VirtualHost{"$sitename:8080"}->{Location} = ( [ "/ext" => {
SetHandler=> "default-handler"
},
"/images" => { SetHandler => "default-handler"
},
] );
I get an error
like:
[Sat Apr 21
23:06:30 2001] [error] (22)Invalid argument: : Invalid command
'Location', perhaps mis-spelled or defined by a module not included in the
server configuration
I'm really not
sure about my structure syntax - I've got an Alias directive I managed to get
working, and modelled the Location stuff after it, but I just can't get this
sucker to go. I'm finding the mod_perl guide a little vague, talking only
about Location as a discreet variable (which I assume is server global?),
and I'm just not getting how to do this within the scope of a
VirtualHost...
Steve
RE: Perl Config for VirtualHosts oops!
Argh - don't you hate reading over your posts _after_ you send them? > I'm trying to set up a series of VirtualHost sections in httpd.conf > using Perl. I want to set the PerlHandler for the VirtualHost to > "perl-script", but I want to define several Location sections with > the PerlHandler set to "default-handler". s/PerlHandler/SetHandler/; 8^| Steve
RE: Dynamic loading of development libraries
Hi Brian, I've been over this a few times in our environment - and the best solution I've been able to come up with has been to run multiple Apache servers. Our environment involves simultaneous HEAD and branch development on our Framework, as well as HEAD and branch development of applications based on the Framework. We've got a multi-server development environment (dev only, preview, and production) with CVS commits auto-published to the dev and preview servers, according to CVS branch. Our dev server has to support a stable CVS branch of the Framework in order to facilitate stable application development. As a result, we're about to begin maintaining multiple Apache processes, one per branch of the Framework (HEAD, stable release branch, tagged release) in order to maintain a clean environment and predictable application quality. Applications can be simultaneously tested on the current Framework or a past tagged release, as well as the stable branch and even the trunk. My reasoning against solutions such as Apache::PerlVINC and StatINC is that I want the environment in which an application is tested and developed to be as close as possible to the final deployment environment. I even encourage our developers to work with the proxy front-end so that they can see what their cache-control and other headers are doing (of course, the back-end Apache processes are always available to them on a different port). IMHO these modules, while in many circumstances are quite useful, are not applicable to our strict development environment. And while they may well work okay in this environment, I don't want to take the chance because - I'm a paranoid S.O.B. 8^) Luckily, RAM is cheap these days... Steve -Original Message- From: Brian Ferris [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 03, 2001 12:30 PM To: [EMAIL PROTECTED] Subject: Dynamic loading of development libraries I'm currently a developer for an on-line publication using Apache / mod_perl / Mason. We currently have about six developers working on the project and I have been running into problems with concurrent work on the Perl libraries that power our site. We use CVS to manage revisions, but the only way for a developer to see if their code is working is to run it on our webserver. However, mod_perl's very purpose is to keep one copy of your modules loaded from the start. StatINC addresses this problem to a certain extent, but it fails when you have multiple versions of a Perl module that you want to load depending on which user is requesting. I sort of got around this by modifying my Mason handler to examine the requested URI ( ex. /dev/user_name/blah.html ) and loading the appropriate module for that user. Basically, this involved modifying the @INC paths in the handler, requiring the modules, and then calling the StatINC handler sub to reload any modified modules. This sort of screams hack and it never worked that well. Processes would load the proper module for one user, and then use that same module to serve another user who was looking for his own modules. Chaos ensued... I have a few ideas as to what I should try next. Perhaps limiting RequestsPerChild to 1, such that libraries don't get reused? I don't know what the ramifications of this are. Short of running a webserver for each user (a bad solution in my opinion) does anyone have ideas? Thanks, Brian Ferris
RE: HTML Mason 1.0 setup
Hi Rob,
> I've been using HTML::Mason under mod_perl on my site for
> awhile, using
> 0.89, and I like it lots. :-) So when the new 1.0 came out,
Me too 8^) I'm a Mason junkie for going on 4 years now I think - since 0.4
8^)
> I went to go
> upgrade, and broke EVERYTHING.
There are some very specific differences. Make sure that you are setting up
the ApacheHandler correctly - you may need to compare the handler included
in the distribution. Most importantly make sure you have
use HTML::Mason::ApacheHandler;
I did not see this in your sample attachment.
> Not only that, but, I haven't been able to make sense out of
> what Mason
> wants for its dir heirarchy, anyway:
> First, comp_root (apparently) needs to be the same as
> DocumentRoot, which
> seems horribly insecure... if I could find another way to do
> it, I would,
This is not correct - I use a drastically different component root than my
document root on all of my installations, specifically for security reasons.
Make sure you un-comment the lines in the handler.pl for:
chown ( scalar(getpwnam "nobody"), scalar(getgrnam "nobody"),
$interp->files_written );
Substitute the "nobody" for the user & group your web server runs under. The
transient files created by Mason will need to be writable by that user, and
the Mason handler will take care of the permissions issues for you.
> Why can't I have
> /home/httpd/html
> /home/httpd/components(instead of /home/httpd/html/components)
> /home/httpd/mason (instead of /home/httpd/html/mason)
I would generally use a directory structure like:
AppName/web/pub/ (document root, public HTML documents and top-level Mason
components)
AppName/web/elements/ (non top-level Mason components)
And then set the component root to AppName/web, allowing you to use absolute
references in your <& &> and $m->comp calls such as
$m->comp("/elements/banner.html"), or <& /elements/footer.html &>
This ensures that banner.html and footer.html are NOT accessible directly
via the web server.
My Mason Interpreter object is usually set up like:
my $interp = new HTML::Mason::Interp (parser=>$parser,
allow_recursive_autohandlers=>undef,
comp_root=>'/home/www/AppName/web',
data_dir=>'/var/masondata');
Then my VirtualHost directive sets:
DocumentRoot /home/www/AppName/pub
Check out that use directive I noted at the top - it might be your sticking
point.
Good Luck!
Steve
RE: is morning bug still relevant?
Greetings, > to say "ping doesn't work in all cases" without qualifiying why and/or > which drivers that applies to. We've had to write our own ->ping method for the MySQL DBD driver. Our developer tried to track down a maintainer for the DBD::msql/mysql module to submit a diff, but to no avail. It was easier to patch the MySQL driver than to start putting driver conditionals in our own code (our stuff runs on Oracle & MySQL). Steve
RE: [certification]
> You miss the point. > > It's not about credentials in a boolean sense. It's about > probability and > statistics. That's exactly true - in fact I'd go so far to say that the probably and statistics vary for each type of certification. I trust an M.D.'s certification far greater than I trust an MCSE certification, because I can be pretty sure the doctor completed his education and had to actually think a little to accomplish that. The MCSE, not so much. A few months of memorization (quickly forgotten) does not mean the same as 7 years in med school. It all comes down to what certifications the employer trusts. We (in effect the M.D.'s employer) trust their medical degree. Not because some company ran a marketing campaign to tell us that we should, but from our own experience, and the experience of others. However, Microsoft simply runs an ad campaign telling employers that they can trust MCSE's - and why should they believe otherwise? 8^( Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
