finding "context" in mod_perl handler
Hi. Supposing I have this kind of setup PerlAuthenhandler My::AuthModule ... ... PerlAuthenhandler My::AuthModule ... and a request is made for "/xyz", and as a result the module is called, is there some way in My::AuthModule::handler(), by which I can find out that, in *this* instance, I am being called in the "context" of the directive above, as opposed to the case ? I mean, I could do something like respectively PerlSetVar context "location:/xyz" and PerlSetVar context "dir:/some/path" and then check the var in the handler, but there has to be a better/cleaner way, no ? Thanks André
Re: mod_perl crashes with Perl 5.10
Hi Philippe, (Sorry for the delay with my answer - I'll be quick from now on) Thank you for your interest to help me with this crasher. On Tue, Apr 07, 2009 at 22:17:27 -0400, Philippe M. Chiasson wrote: > On 29/3/09 15:30, Jozef Kosoru wrote: > > Hello, > > > > I tested my mod_perl application using following combinations recently: > > > > * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 > > Perl/v5.10.0 > > (default Debian Lenny packages, mpm-prefork) > > > > * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0 > > (apache, apreq and mod_perl compiled from sources, mpm-prefork) > > > > and I see a crash of Apache process on each request. > > Just to be sure, is that a 32/64 bit platform ? This is 32 bit. I can check on 64 bit. > > Here's the backtrace: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xb7ce0ad0 (LWP 11196)] > > 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 > > (gdb) bt > > #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 > > #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 > > #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10 > > #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, > > p=0x9ad4578, > > r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101 > > Hrm, if at all possible, while in gdb, could you dump more information from > that frame ? > > (gdb) info locals Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7cf9ad0 (LWP 8233)] 0xb7c0b095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10 (gdb) info locals No symbol table info available. Any clue? > Also, I'd love to see as much of the arguments as possible, expecially > handler, r and args > > (gdb) print *handler > (gdb) print *r > (gdb) print *args Same with others: (gdb) print *handler No symbol "handler" in current context. (gdb) print *r No symbol "r" in current context (gdb) print *args No symbol "args" in current context Do I have to recompile Perl with some special debug symbols? > Thanks. > > Also, one thing that always help narrow things down is if you could > boil down your application to a small enough test case that you could > share it with us. I was trying to do so but haven't succeded with any minimalized test-case yet. But it's not really so much code anyway and it's all GPL. I'll try to make an easy package of it. Regards, Jozef -- Jozef Kosoru http://zyzstar.kosoru.com
Re: finding "context" in mod_perl handler
André Warnier wrote: Hi. Supposing I have this kind of setup PerlAuthenhandler My::AuthModule ... ... PerlAuthenhandler My::AuthModule ... and a request is made for "/xyz", and as a result the module is called, is there some way in My::AuthModule::handler(), by which I can find out that, in *this* instance, I am being called in the "context" of the directive above, as opposed to the case ? I mean, I could do something like respectively PerlSetVar context "location:/xyz" and PerlSetVar context "dir:/some/path" and then check the var in the handler, but there has to be a better/cleaner way, no ? The first thing i'd try is checking $r->location. I'm not sure what that does for the Directory instance, but in the Location instance it'll return '/xyz'. I don't know of a comparable way to do the same thing with Directory directives. Adam
[Fwd: [yapc] Official Call for Proposals for YAPC|10 ends Friday, 24 April 2009]
FYI. Original Message Subject: [yapc] Official Call for Proposals for YAPC|10 ends Friday, 24 April 2009 Date: Tue, 21 Apr 2009 11:26:34 -0400 From: Robert Blackwell To: y...@pm.org The official Call for Proposals for YAPC|10 ends Friday, 24 April 2009. http://yapc10.org/yn2009/cfp.html You can also follow YAPC|10 on Twitter. http://twitter.com/yapc10. Robert Blackwell YAPC|10 412.235.1533 ___ yapc mailing list y...@pm.org http://mail.pm.org/mailman/listinfo/yapc
Re: cannot LoadModule mod_perl on apache2.2
Jeff Zhuk wrote: Andre, Another thing that maybe related: I can start Apache without the line loading the mod_perl Then I would expect that my perl script will be executed. I have these lines in the httpd.conf: Alias /perl/ "C:/Tomcat/webapps" Very bad ! Probably never even gets here. I'd have to recheck when things happen between Alias and a Location, but off the top of my head, I'd say that the first thing that happens is the Alias, so it will never match the Location. SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders But perl is not executed. I see the source text instead (my scripts should produce html) Of course. What do you think about this? A whole lot, but not nice things. The reason I say Very Bad above, is this : Suppose you have an operational Tomcat on your system (which the above line tends to indicate). Then suppose you have a webapp under Tomcat : TOMCAT_DIR/webapps/admin and suppose that in the web.xml of that webapp is a very secret password. Then by accessing you server via the URL "/perl/admin/WEB-INF/web.xml", I can view/download that web.xml whenever I want. (and any other file under your Tomcat webapps for that matter. Never, ever give access to your Tomcat dirs via Apache that way, you completely bypass any Tomcat security. Move your perl scripts somewhere else entirely, not even directly under the DocumentRoot of Apache either. For example, move them to c:/Apache/perl. Then do this Alias /perl/ c:/apache/perl/ Order allow,deny Allow from All > SetHandler perl-script > PerlResponseHandler ModPerl::Registry > Options +ExecCGI > PerlOptions +ParseHeaders of course, this does not solve your problem loading mod_perl, but it would be a first step.
Re: Undefined subroutine error
On Tue, Apr 14, 2009 at 01:56:57PM -0400, Perrin Harkins wrote: > On Tue, Apr 14, 2009 at 1:34 PM, Roberto C. Sánchez > wrote: > > On Tue, Apr 14, 2009 at 01:21:09PM -0400, Perrin Harkins wrote: > >> On Tue, Apr 14, 2009 at 12:48 PM, Roberto C. Sánchez > >> wrote: > >> > As far as loading the module, I have tried: > >> > > >> > - "PerlModule Example::Image" in .htaccess > >> > - "use Example::Image;" in the main HTML::Mason component > >> > >> Either of those should be ok. If you decide to export the sub later, > >> you'd need to call it from Mason. > >> > > I'm not sure what you mean by this. > > Well, read up about exporting and then it should make more sense. > Perl has namespaces, and when you export a sub you need to export it > to the namespace where you want to call it, which is Mason in this > case. > So, on a lark I tried moving the "PerlModule Example::Image" from the .htacess file to the virtual host configuration. I then restarted apache. So far, it seems to have been working for several days. In the past, the problem would usually manifest itself within 8 hours or so of an apache restart. Could this have something to do with threading? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Undefined subroutine error
On Tue, Apr 21, 2009 at 12:22 PM, Roberto C. Sánchez wrote: > So, on a lark I tried moving the "PerlModule Example::Image" from the > .htacess file to the virtual host configuration. I then restarted > apache. So far, it seems to have been working for several days. In the > past, the problem would usually manifest itself within 8 hours or so of > an apache restart. Why were you putting it in a .htaccess file? Were you trying to avoid loading it until people access a certain directory? > Could this have something to do with threading? Are you using a threaded MPM? That's not recommended unless you're on Windows because of memory consumption. I haven't heard any bug reports about this kind of behavior on threads though. - Perrin
Re: finding "context" in mod_perl handler
On Tue, Apr 21, 2009 at 6:16 AM, André Warnier wrote: > I mean, I could do something like respectively > PerlSetVar context "location:/xyz" > and > PerlSetVar context "dir:/some/path" > > and then check the var in the handler, but there has to be a better/cleaner > way, no ? That's what I would do. Easy and foolproof. - Perrin
Re: finding "context" in mod_perl handler
On Tue, Apr 21, 2009 at 1:47 PM, Perrin Harkins wrote: > On Tue, Apr 21, 2009 at 6:16 AM, André Warnier wrote: >> I mean, I could do something like respectively >> PerlSetVar context "location:/xyz" >> and >> PerlSetVar context "dir:/some/path" >> >> and then check the var in the handler, but there has to be a better/cleaner >> way, no ? > > That's what I would do. Easy and foolproof. Assuming of course that you care about Directory xyz vs Location xyz. If they're totally different URLs, then checking the location is all you need. - Perrin
Re: finding "context" in mod_perl handler
André Warnier wrote: Hi. Supposing I have this kind of setup and then check the var in the handler, but there has to be a better/cleaner way, no ? Thanks André http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_path_info_ Just get the info from the request object within the handler? David
Re: Undefined subroutine error
On Tue, Apr 21, 2009 at 01:30:58PM -0400, Perrin Harkins wrote: > On Tue, Apr 21, 2009 at 12:22 PM, Roberto C. Sánchez > wrote: > > So, on a lark I tried moving the "PerlModule Example::Image" from the > > .htacess file to the virtual host configuration. I then restarted > > apache. So far, it seems to have been working for several days. In the > > past, the problem would usually manifest itself within 8 hours or so of > > an apache restart. > > Why were you putting it in a .htaccess file? Were you trying to avoid > loading it until people access a certain directory? > I have the .htaccess in subversion, but not the virtual host config. > > Could this have something to do with threading? > > Are you using a threaded MPM? That's not recommended unless you're on > Windows because of memory consumption. I haven't heard any bug > reports about this kind of behavior on threads though. > I'm actually using apache2-mpm-prefork. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: cannot LoadModule mod_perl on apache2.2
Please, keep these messages on the list. Jeff Zhuk wrote: Andre, 1. you are right about security. I actually have my JBoss running in a different space and only use this directory as static and perl root. I narrowed down the problem of running test.pl by directly providing the first line in the test.pl file: #!c:/Perl/bin/perl.exe This made the trick and allowed the script to work with Apache. I have a lot of scripts and would not like to hardcode this line there. When I switch to mod_perl I'll need to replace this line with the pointer to perl58.dll or perl510.dll, right? No, don't do that. But maybe an additional word of explanation: (Purists, I am simplifying, I know). When you are running cgi-bin scripts without mod_perl, what happens is : Apache uses the system default shell to run the script. The system shell looks at the first line of the script, to determine which program should run the script. Then the shell does an exec() of that program, with the path of the script as argument. This allows for cgi-bin scripts that are either perl, or any other language (even a simple shell script). This is all rather heavy and inefficient, because Apache has to start another process, that process loads a shell, the shell then loads a whole new perl interpreter, and that perl interpreter first compiles and then runs your script. Then your script is done and exits, perl exits, the additional process exits, and everything is forgotten. And each time you call your script, the same happens again. All in all, it is rather a wonder that it still works relatively fast. When you run under mod_perl, the situation is fundamentally different. First, Apache at startup will load a perl interpreter once and for all. Then you tell Apache that in some directory, any files being run always have to be run by that interpreter (that's what you do with "SetHandler perl-script"). So Apache 1) does not have to load a new shell each time 2) this shell does not have to load perl because perl is already there and Apache can tell it to run the script file right away. So only for that reason, things already go much faster. For the sake of discussion, let's say that this already gains a factor 10 in speed, at least. In addition, under some conditions perl will compile the script the first time it runs it, and keep the compiled code cached in memory. The next time the same script is run, perl can just re-execute the cached compiled code. That is much faster again. Let's say that this is another cumulative factor 10. So with both, you have a factor 10 X 10 = 100. The next step would be to make, if possible and if it makes sense, your script into a mod_perl Apache module. Then it would be loaded and compiled when Apache starts, and become an integral part of Apache. That would be another (smaller) boost in performance, but mainly it allows you to write code that is much closer to the Apache "innards", and that can directly intervene in the inner Apache request cycle, which opens up lots of possibilities to do smart things like rewriting URLs, doing customised authentication, filtering input and output, etc.. , all of this quite fast. That is the real power of mod_perl. Apart from writing Apache add-on modules directly in C, mod_perl is the closest you'll get to the Apache insides. Other languages don't even come close (no matter what the php and python guys may believe). And of course, lots of people have already done lots of things like that, for just about any problem under the sun. Have a look here for more ideas : http://cpan.uwinnipeg.ca/search?query=apache2&mode=dist Any way to move this line to httpd.conf? No, and you don't need to. Or rather, it's already done. As explained above, that is what the line "SetHandler perl-script" is already doing for you. 2. I think, you are right again when you say that it has nothing to do with mod_perl loading. I suspect that my Perl install is not correct enough. Running Perl from the console I see some libraries missing. I think that while loading mod_perl, Apache cannot find some support from Perl. Do you think this might be the reason? I have no idea, but since you are under Windows, it's not really hard to re-install everything. I plan to re-install ActivePerl. Would you recommend 5.8 or 5.10? Usually I would recommend the latest one available, but I am still happily using mostly 5.8. I recently had a couple of problems with 5.10 in a mod_perl context (had to change a couple of lines somewhere in a script or mod_perl module) but don't remember what exactly. Try perl 5.10 first. You can always downgrade if you have a problem. Following the procedure as indicated here is the easiest : http://perl.apache.org/docs/2.0/os/win32/install.html#toc_PPM_Packages - save your apache/conf directory somewhere - de-install Apache and perl - re-install Apache 2.2.x - re-install perl 5.10 from
Re: [OT] cannot LoadModule mod_perl on apache2.2
André Warnier wrote: I strongly suggest that in the process of installing Apache, you pick a sensible installation directory, without spaces in the name, like your prior c:/apache. This will always save you some aggravation at some point, and a lot of quotes always. I can still not figure out why the Apache for Windows packagers decided to follow the assinine MS customs. Come to think of it, that space between "Program" and "Files" has got to be the most uselessly expensive nothing in the history of computing.
config? internal_redirect wants internal_re.al
Hi, I'm getting the following error in response to a call to internal_redirect of Apache2::SubRequest: Can't locate auto/Apache2/Request/internal_re.al in @INC which, of course, it won't since, on my Debian Lenny system, /usr/lib/perl5/auto/Apache2 doesn't even have a Request subdirectory. This question came up 4 years ago in the Mason users list, and Jonathan Swartz suggested it might be a mod_perl configuration issue. The only thing is, I have 2 virtual hosts using the same configuration and the same code. Redirects work fine for one and not the other. (Well, OK, machines are deterministic and there is some difference that escapes me.) Does anyone have a suggestion how to go about addressing this problem? My server looks like this: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 and the Apache location is SetHandler perl-script PerlHandler MyApp::Mason DefaultType text/html Thank you. Mark
