Re: mod_perl and chroot
On Sun 10 Feb 2008, James Breat wrote: > to resolve handler `ModPerl::Registry': Can't locate > ModPerl/Registry.pm in @INC (@INC contains: > /usr/lib/perl5/5.8.8/i486-linux-thread-multi /usr/lib/perl5/5.8.8 > /usr/lib/perl5/site_perl/5.8.8/i486-linux-thread-multi > /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl . > /usr/local/srv/apache2) at (eval 2) line 3.\n" > > locate Registry.pm returns: > /usr/lib/perl5/site_perl/5.8.8/i486-linux-thread-multi/ModPerl/Registry.pm I don't think that is true for your new root. So either copy all needed modules to it or load them *before* the chroot call. AFAIK mod_chroot installs a PostConfig handler at APR_HOOK_REALLY_LAST+10, that means really_really_last. Anything before that runs in the original root and hence can load modules, see http://perl.apache.org/docs/2.0/user/handlers/server.html#Server_Life_Cycle Torsten
Re: Apache 2.2.6, mod_perl 2.0.3 msvcrt.dll start problem
Hi guys, thank you very much for all the interest in the issue, but could one of you summarise and tell me what I should do ? Should I - go back to ActivePerl 8.8.820 (instead of 8.8.22 currently) ? - do something else (like what Jan Dubois said below ? (or is that just for the people creating the binary mod_perl package ?) - use another combination altogether ? (I cannot compile under Windows) As per below, my immediate problem is solved, but it would be nice to have the "clean" solution for future reference. Thanks, André P.S. In the meantime, under Windows XP SP 2 German, I did try the de-install of ActivePerl 8.2.822, re-install of ActivePerl 8.2.820, and re-install mod_perl using the "mpinstall" script, and everything works fine, including starting Apache (2.2.8) as a service The error with msvcrt.dll does not appear anymore. I tried a dozen Apache service startup cycles and got no error. The same procedure, same Perl 8.8.820 but with Apache 2.2.6 works fine too on another Windows XP SP2, Spanish workstation, which also had some problems with AP 8.8.822. William A. Rowe, Jr. wrote: Jan Dubois wrote: http://downloads.activestate.com/ActivePerl/Windows/5.8/ActivePerl-5.8.8.822-MSWin32-x86-280952-symbols.zip The symbols.zip file should be unpacked in the C:\Perl directory, or wherever you installed ActivePerl as it contains .pdb file for both the bin and the lib subtree. All symbols should then automatically fall into the correct places. Excellent, thanks Jan!!!
Re: [RFC] Apache2::DirBasedHandler
I uploaded a .02 release last night which i think will make something like this even easier to accomplish. This version adds a function called uri_to_function, which takes a RequestRec (or derived) object, and an array of uri_bits and returns a function name that should be used to to handle that request. I don't really know REST, but from my limited knowledge it seems to me that it would be good to be able to easily separate code for post, get, put, and delete to the same URI. So with this new version, if you subclass uri_to_function to work like this: return join(qq[_],(lc($r->method),@$uri_bits)) . qq[_page]; then you can very easily achieve that seperation. I also uploaded Apache2::DirBasedHandler::TT, which is a subclass of DirBasedHandler that will pass a Template object, and a base set of TT vars into each function call. It's more or less just in illustration of how i thought one might use the init function in Apache2::DirBasedHandler. Feedback welcome Adam Quoting André Warnier <[EMAIL PROTECTED]>: I'm not a guru in the matter either, but it sounds interesting. It looks like it could give a way to do things REST-like, but simpler. [EMAIL PROTECTED] wrote: The first version of this is now on CPAN, if anyone is interested in it. Adam
Re: Trying to configure Apache2::Request
On Feb 10, 2008 1:57 AM, Mag Gam <[EMAIL PROTECTED]> wrote: > doc.pl looks like this: > #!/usr/bin/perl -w > use strict; > use CGI; > use APR::Request::Apache2 (); > > > print "Content-type: text/html\n\n"; > print "Hello"; my $r = shift; > my $req = Apache2::Request->new($r, POST_MAX => "1M"); Also, don't print your Content-type header. Use CGI or $r to do it. - Perrin
Re: Trying to configure Apache2::Request
Nice, Thanks! Just figured this out... A known disadvantage to Perl method calls is that they are slower than direct function calls. It is possible to resolve method calls at compile time, rather than runtime, making method calls just as fast as subroutine calls. However, there is certain information required for method look ups that are only known at runtime. To work around this, compile-time hints can be used, for example: my Apache2::Request $r = shift; Tells the Perl compiler to expect an object in the C class to be assigned to C<$r>. A patch has already been submitted to use this information so method calls can be resolved at compile time. However, the implementation does not take into account sub-classing of the typed object. Since the mod_perl API consists mainly of methods, it would be advantageous to re-visit the patch to find an acceptable solution. On Feb 10, 2008 12:06 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Feb 10, 2008 1:57 AM, Mag Gam <[EMAIL PROTECTED]> wrote: > > doc.pl looks like this: > > #!/usr/bin/perl -w > > use strict; > > use CGI; > > use APR::Request::Apache2 (); > > > > > > print "Content-type: text/html\n\n"; > > print "Hello"; > > my $r = shift; > > > my $req = Apache2::Request->new($r, POST_MAX => "1M"); > > Also, don't print your Content-type header. Use CGI or $r to do it. > > - Perrin >
Re: Question about open()
I am taking the Apache2::Request method, and will integrate the DB solution
as Chandra mentioned.
#!/usr/bin/perl -w
use strict;
use CGI;
use Apache2::Request;
use Data::Dumper;
print "Content-type: text/html\n\n";
my Apache2::Request $r = shift;
my $docroot = $r->document_root('/var/www/html/perl');
print $docroot;
For some reason, its still defaulting to /var/www/html. I need it to goto
/var/www/html/perl
Any thoughts?
On Feb 7, 2008 5:14 PM, Chandrakumar Muthaiah <[EMAIL PROTECTED]>
wrote:
>
> Perrin Harkins wrote:
> > On Feb 6, 2008 10:06 PM, Mag Gam <[EMAIL PROTECTED]> wrote:
> >
> >> Currently, when I open a file I have to use the
> >> absolute path (/var/www/appname/top.inc). Is it possible for me to use
> just
> >> 'top.inc'?
> >>
> >
> > You can either use DocumentRoot
> > (
> http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_document_root_
> )
> > or use ModPerl::RegistryPreFork which will chdir to the directory your
> > script is in just like a normal CGI script does. That would let you
> > use files relative to the script.
> >
> > - Perrin
> >
>
> Few quirks with document root. Your application may not be hosted under
> document root. you may have all your templates and customizations some
> where else.
>
> I think better option would be to define the template/support files
> location in Directory Configuration or in a Database configuration
> table. That would be more staple solution.
>
> in your .htaccess or on the Location/Directory Configuration put a line
> that says
>
> PerlSetVar AppsSupportFiles "/home/httpd/support/site1/template"
>
>
> and access this parameter from your $r->dir_config('AppsSupportFiles')
>
>
> I think this may be more customizable and scalable solution to your
> problem
>
> -Chandra
>
Re: Trying to configure Apache2::Request
On Feb 10, 2008 12:14 PM, Mag Gam <[EMAIL PROTECTED]> wrote: > my Apache2::Request $r = shift; > Tells the Perl compiler to expect an object in the C > class to be assigned to C<$r>. A patch has already been submitted to > use this information so method calls can be resolved at compile time. That didn't work out. You should not do this. Just use the normal "my $r" syntax. - Perrin
Re: Question about open()
On Feb 10, 2008 12:24 PM, Mag Gam <[EMAIL PROTECTED]> wrote:
> my $docroot = $r->document_root('/var/www/html/perl');
Why are you trying to change the DocumentRoot?
- Perrin
Re: Question about open()
Thanks for the quick response Perrin.
I am trying to change DocumentRoot because, currently I am using open() to
load templates for my website. I have header, menu, footer in 3 seperate
files, and I generate content like that. It works fine now, just not too
dynamic when I want to move the stuff around. I have
open("/var/www/perl/header.file") hardcoded, which is a pain. I just want
open ("header.file").
If I do open("header.file") its trying to read from DocumentRoot ie.
/var/www/header.inc, which does not exist.
On Feb 10, 2008 12:32 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Feb 10, 2008 12:24 PM, Mag Gam <[EMAIL PROTECTED]> wrote:
> > my $docroot = $r->document_root('/var/www/html/perl');
>
> Why are you trying to change the DocumentRoot?
>
> - Perrin
>
Running a mod_perl script at the domain root
I've spent at least a couple of hours trying to figure this out and reading manuals, to no avail, hence asking here. I hope it's not too obvious :-). I'm running a mod_perl (2.0.2) script from the root of my domain. My Apache (2.2.3) configuration is as follows. . . . PerlOptions +Parent PerlSwitches -T -I/var/www/testsite SetHandler perl-script PerlResponseHandler TestSite My script takes the whole URI and uses that as part of the input to tell it which part of the site the user wants to visit (such as / for the home page or /account to manage their contact details). The problem is that, because the script overrides the whole domain, a request for /logo.png or the CSS file will not work properly. I have tried using mod_rewrite to combat this, to no avail. I think the problem is that when I was using mod_python on a different site (a MoinMoin wiki as it happens), the handling of the request is different; it'd be more like the following: # map /wiki static files to Moin htdocs RewriteRule ^/wiki/(.*)$ /var/www/agdev-wiki/htdocs/$1 [last] # map everything else to server script RewriteRule ^(.*)$ /var/www/agdev-wiki/moinmodpy.py$1 In this case, I can successfully use mod_rewrite because I can send the request to a certain script. I can't see how to send the request to a certain location, as would appear to be required by the mod_perl setup. Could someone direct me to instructions or an example Apache config where they're running a mod_perl script at the domain root? Thanks very much for your time, best regards, P.S. My site is now running much faster under mod_perl (albeit without CSS or a logo at the moment :-)) -- mod_perl really does seem to rock maximally and I'm looking forward to getting it all working smoothly. -- Matthew Tylee Atkinson <[EMAIL PROTECTED]>
Re: Running a mod_perl script at the domain root
There are a couple of ways you can tackle this sort of thing.
1) You can modify TestSite to return DECLINED for any request that you
want to be handled by the filesystem rather than your handler. ie
if $r->uri =~ m|\css$| {
return Apache2::Const::DECLINED;
}
2) If you've got all your CSS and images in directories dedicated to
those tasks, then you can add locations blocks that SetHandler
default-handler. ie:
SetHandler perl-script
PerlResponseHandler TestSite
SetHandler default-handler
SetHandler default-handler
There are likely other ways to handle it too.
Adam
Matthew Tylee Atkinson wrote:
I've spent at least a couple of hours trying to figure this out and
reading manuals, to no avail, hence asking here. I hope it's not too
obvious :-).
I'm running a mod_perl (2.0.2) script from the root of my domain. My
Apache (2.2.3) configuration is as follows.
. . .
PerlOptions +Parent
PerlSwitches -T -I/var/www/testsite
SetHandler perl-script
PerlResponseHandler TestSite
My script takes the whole URI and uses that as part of the input to tell
it which part of the site the user wants to visit (such as / for the
home page or /account to manage their contact details).
The problem is that, because the script overrides the whole domain, a
request for /logo.png or the CSS file will not work properly.
I have tried using mod_rewrite to combat this, to no avail. I think the
problem is that when I was using mod_python on a different site (a
MoinMoin wiki as it happens), the handling of the request is different;
it'd be more like the following:
# map /wiki static files to Moin htdocs
RewriteRule ^/wiki/(.*)$ /var/www/agdev-wiki/htdocs/$1 [last]
# map everything else to server script
RewriteRule ^(.*)$ /var/www/agdev-wiki/moinmodpy.py$1
In this case, I can successfully use mod_rewrite because I can send the
request to a certain script. I can't see how to send the request to a
certain location, as would appear to be required by the mod_perl setup.
Could someone direct me to instructions or an example Apache config
where they're running a mod_perl script at the domain root?
Thanks very much for your time,
best regards,
P.S. My site is now running much faster under mod_perl (albeit without
CSS or a logo at the moment :-)) -- mod_perl really does seem to rock
maximally and I'm looking forward to getting it all working smoothly.
Re: Apache 2.2.6, mod_perl 2.0.3 msvcrt.dll start problem
On Sun, 10 Feb 2008, Foo JH wrote: William A. Rowe, Jr. wrote: Foo JH wrote: Andre, I've recently set up a test based very closely on your platform: AP2.2.8 AP5.8.8 Build 822 MP2.0.3 You mention a VC 2005 build of httpd, which build of MP? 2005? Not sure which uwinnipeg is built against, msvcrt or msvcr80. But my recent observation is that if you use AS Perl, which is built against msvcrt, it's likely best to use modperl built against msvcrt as well. I'm doubting httpd's clib has a whole lot to do with it. I know. ApacheLounge uses a different (newer) compiler, and the implications can be quite risky. I've started on this path since the earlier 2.2.x when modperl on the ASF binaries has been unreliable, and support on the mailing list confirmed my experience more than resolved it. Why don't you give it a try and see if you're having it better? I think characterizing the ASF binaries as unreliable with mod_perl is misleading - there were some recent problems with restarts, etc. on Win32 that have been looked into and addressed for the 2.2.8 release. Concerning the recommendation to try the ApacheLounge binaries, I'd offer two cautionary notes: - As you say, the ApacheLounge binaries use a different compiler version which may in itself introduce some problems. - As well, the latest ApacheLounge binary distribution contains some changes: http://www.apachelounge.com/forum/viewtopic.php?p=9752 from the official ASF 2.2.8 sources, which isn't apparent from the title "Apache 2.2.8 available" on http://www.apachelounge.com/ I think it's fair to say the mod_perl developers will only provide support for official ASF versions of Apache. -- best regards, Randy Kobes
Re: Question about open()
I do keep my templates in other directories also.
1. If your directories are relative to the document root, and you can
take advantage of this fact by rendering a variable to remember the
template path.
2. If your template directories have nothing in common with the document
root, then you can set the variable via SetPerlVar within http.conf.
That takes the 'hard' out of your code. :)
Mag Gam wrote:
Thanks for the quick response Perrin.
I am trying to change DocumentRoot because, currently I am using
open() to load templates for my website. I have header, menu, footer
in 3 seperate files, and I generate content like that. It works fine
now, just not too dynamic when I want to move the stuff around. I have
open("/var/www/perl/header.file") hardcoded, which is a pain. I just
want open ("header.file").
If I do open("header.file") its trying to read from DocumentRoot ie.
/var/www/header.inc, which does not exist.
On Feb 10, 2008 12:32 PM, Perrin Harkins <[EMAIL PROTECTED]
> wrote:
On Feb 10, 2008 12:24 PM, Mag Gam <[EMAIL PROTECTED]
> wrote:
> my $docroot = $r->document_root('/var/www/html/perl');
Why are you trying to change the DocumentRoot?
- Perrin
Re: Apache 2.2.6, mod_perl 2.0.3 msvcrt.dll start problem
Randy, I think characterizing the ASF binaries as unreliable with mod_perl is misleading - there were some recent problems with restarts, etc. on Win32 that have been looked into and addressed for the 2.2.8 release. The intent of my earlier response was not to undermine the quality of the ASF builds. I have been relying on the ASF binaries since 1.3 (even though it was not recommended for Windows). And it's only in the recent months that I have come to depend on another source until some of my key needs (on the binaries) are resolved. So please take it as just a layman sharing his experience and resolution on the problems. Moving forward, I do see that there's some conversation about recompiling modperl based on the newer releases of ActivePerl. That's a very encouraging move. - As you say, the ApacheLounge binaries use a different compiler version which may in itself introduce some problems. Agreed. To date I still don't know what mess I've gotten myself into by using this hybrid stack. It's still looking good and I'm crossing my fingers. Maybe it's finally my lucky year... - As well, the latest ApacheLounge binary distribution contains some changes: http://www.apachelounge.com/forum/viewtopic.php?p=9752 from the official ASF 2.2.8 sources, which isn't apparent from the title "Apache 2.2.8 available" on http://www.apachelounge.com/ Noted. I think it's fair to say the mod_perl developers will only provide support for official ASF versions of Apache. Since mod_perl is an ASF project, I guess it can't be helped. Personally I do applaud the 2nd take on the Win32 binaries that AL took. Having said that, at the end of the day everyone lives and dies with the ASF development.
