mp2: brief success story
Just for the archives, I'm using mp2 (usually fairly recent CVS pulls) in production on a number of sites I'm hosting on a NetBSD server. These include my cycling coaching website : www.aboc.com.au which uses Template::Toolkit, mp2, my own authentication stuff (not a handler, yet :) ) and MySQL as a backend. I also used it for db-tour.bl.echidna.id.au, also using Template::Toolkit but with no database stuff. It's all pretty low traffic, but I've not had a crash in 4 months, and that's pretty good for development stuff. Thanks heaps to Stas and the mp community for all your work with mp2 and answering my clueless questions :) Carl
Strange (13)permission denied in 1.28
Hi all, I just upgraded from Apache 1.27/mod_perl 1.27 to Apache 1.28/mod_perl 1.28 and am noticing some weird behaviour on Apache::Registry scripts - executing a Registry script ( /webroot/www.domain.com/perl/test.pl ) by calling a URL such as: http://www.domain.com/perl/test.pl/movies/image/1234 pops up a message in the error log that: [Wed Oct 1 14:13:01 2003] [error] [client 217.207.98.119] (13)Permission denied: access to /movies/images/1234 failed because search permissions are missing on a component of the path The script itself seems to run correctly - test.pl is a completely simple dummy which just prints headers and exits. Now, /webroot/www.domain.com/movies/ exists, deliberately has permissions 0700 and is owned by root - but why is Apache or Apache::Registry trying to stat that path at all - and how do I stop it or stop the error messages? any help would be gratefully received; Matthew. Matthew Hodgson [EMAIL PROTECTED] Tel: +44 7968 722968 Arathorn: Co-Sysadmin, TheOneRing.net®
Re: Strange (13)permission denied in 1.28
Matthew Hodgson wrote: Hi all, I just upgraded from Apache 1.27/mod_perl 1.27 to Apache 1.28/mod_perl 1.28 and am noticing some weird behaviour on Apache::Registry scripts - executing a Registry script ( /webroot/www.domain.com/perl/test.pl ) by calling a URL such as: http://www.domain.com/perl/test.pl/movies/image/1234 pops up a message in the error log that: [Wed Oct 1 14:13:01 2003] [error] [client 217.207.98.119] (13)Permission denied: access to /movies/images/1234 failed because search permissions are missing on a component of the path The script itself seems to run correctly - test.pl is a completely simple dummy which just prints headers and exits. Now, /webroot/www.domain.com/movies/ exists, deliberately has permissions 0700 and is owned by root - but why is Apache or Apache::Registry trying to stat that path at all it's apache that is doing that stat call, and it's doing it because your URL has extra path information in it, and that extra path information happens to coincide with an existing directory structure. see httpd_request.c in the apache sources and look for get_path_info. - and how do I stop it or stop the error messages? any help would be gratefully received; reconstruct your URL to test.pl?movies/image/1234 and use $r->args, or use test.pl?/moviefoo/image/1234 and substitute 'movie' for 'moviefoo' in $r->path_info before you use it in your script. HTH --Geoff
Apache::Session::File locks getting stuck
Hi, I have an Apache 1.3.27/modperl 1.27 site using HTML::Mason 1.20 with MasonX::Request::WithApacheSession 0.23 on a Redhat 7.3 system. The site gets about 5,000 hits/day. Each day, a few dozen httpds get stuck waiting for locks on the Apache::Session files. An lsof on the Apache pids reports things like this: httpd 10956 root 11u REG3,2 0 705177 /www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock httpd 10956 root 22u REG3,2 0 705177 /www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock and an strace reveals: flock(11, LOCK_EX I've set things up per the MasonX::Request::WithApacheSession docs and sample files, and I'm not doing anything particularly extraordinary with the sessions. Anyone have any thoughts on how I might fix the problem? Thanks, Dan
Re: Apache::Session::File locks getting stuck
On Wed, 2003-10-01 at 15:53, Dan McCormick wrote: > Each day, a few dozen httpds get stuck waiting for locks on the > Apache::Session files. ... > I've set things up per the MasonX::Request::WithApacheSession docs and > sample files, and I'm not doing anything particularly extraordinary with > the sessions. Anyone have any thoughts on how I might fix the problem? I suggest you switch to the MySQL storage, and use the NullLocker. MySQL updates are atomic, even without the extra locking that Apache::Session adds. The file stuff could be atomic in this way too, but unfortunately it isn't implemented that way. The really bad thing though is that this may indicate that you have scoping problems that are preventing your session objects from being cleaned up. This would result in lost data (since the updates won't get written) even if you fix the locking problem. I suggest you go over the code where you use the session hash very carefully and make sure it goes out of scope at the end. - Perrin
Scope of Apache request object and Apache::Session scoping.
In answer to another question Perrin Harkins <[EMAIL PROTECTED]> wrote: I suggest you go over the code where you use the session hash very carefully and make sure it goes out of scope at the end. I'm sticking a reference to the session hash in the Apache request object: $r->pnotes($auth_name => \%session ); This is under mod_perl 2 I'm doing this in the belief that the request object goes out of scope when Apache finishes handling the request, is this correct? -- -- Matisse Enzer Doodlelab Inc. 415-925-5294 ext. 212 (office) 415-225-6703 (mobile)
Re: Apache::Session::File locks getting stuck
I don't know for sure what may be causing the lockups, but I can think of two things to try: 1) Use Transaction => 1 when tieing your session. 2) Make sure the session is untied after *every* request (i.e. even if a request is aborted, an error occurs in the middle, etc). Otherwise, when the next request tries to tie it it will block. Dan McCormick wrote: Hi, I have an Apache 1.3.27/modperl 1.27 site using HTML::Mason 1.20 with MasonX::Request::WithApacheSession 0.23 on a Redhat 7.3 system. The site gets about 5,000 hits/day. Each day, a few dozen httpds get stuck waiting for locks on the Apache::Session files. An lsof on the Apache pids reports things like this: httpd 10956 root 11u REG3,2 0 705177 /www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock httpd 10956 root 22u REG3,2 0 705177 /www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock and an strace reveals: flock(11, LOCK_EX I've set things up per the MasonX::Request::WithApacheSession docs and sample files, and I'm not doing anything particularly extraordinary with the sessions. Anyone have any thoughts on how I might fix the problem? Thanks, Dan
Re: Scope of Apache request object and Apache::Session scoping.
Good Question. Does $r get freed after every request? In any case, best is to install a PerlCleanupHandler and set untie %$session in it. On Wed, 2003-10-01 at 16:23, Matisse Enzer wrote: > In answer to another question Perrin Harkins <[EMAIL PROTECTED]> wrote: > > > I suggest you go over the code where you use the session hash very > > carefully and make sure it goes out of scope at the end. > > I'm sticking a reference to the session hash in the Apache request object: > > $r->pnotes($auth_name => \%session ); > > This is under mod_perl 2 > > I'm doing this in the belief that the request object goes out of > scope when Apache finishes handling the request, is this correct?
Re: Scope of Apache request object and Apache::Session scoping.
On Wed, 2003-10-01 at 16:23, Matisse Enzer wrote: > I'm sticking a reference to the session hash in the Apache request object: > > $r->pnotes($auth_name => \%session ); > > This is under mod_perl 2 > > I'm doing this in the belief that the request object goes out of > scope when Apache finishes handling the request, is this correct? Yes. That's a good approach to caching the session for the length of a request. - Perrin
[mp2] running make test as unpriveleged user
Hi, Find attached (and inline) a patch for smoother running of "make test" when running as a non-privileged user. This issue came to light while running Gentoo Linux. The Gentoo package system "portage" has the ability to run as a non-root user while building packages. Some file locations were not accessible to that non-root user while running make test. E.g., on Gentoo, mod_cgid defaults to using /var/run/cgisock for its sockets, however, the permissions for /var/run/cgisock on Gentoo are: srwx--1 apache root0 Oct 1 13:14 /var/run/cgisock I used the ScriptSock directive to tell mod_cgid to make the socket file within the self-contained directory tree. Along the same lines, CGI.pm likes to create new temp files in /tmp. I used the SetEnv directive to set TMPDIR environemnt variable to force it to create the temp files in a self-contained directory tree. Comments are welcome. And we really should have a newline at the end of ModPerl-Registry/t/conf/extra.conf.in Index: ModPerl-Registry/t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v retrieving revision 1.10 diff -u -r1.10 extra.conf.in --- ModPerl-Registry/t/conf/extra.conf.in 5 Aug 2003 18:51:10 - 1.10 +++ ModPerl-Registry/t/conf/extra.conf.in 1 Oct 2003 17:22:56 - @@ -145,4 +145,5 @@ SetOutputFilter DEFLATE - \ No newline at end of file + +ScriptSock logs/cgisock Index: t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/t/conf/extra.conf.in,v retrieving revision 1.6 diff -u -r1.6 extra.conf.in --- t/conf/extra.conf.in3 Feb 2003 22:56:19 - 1.6 +++ t/conf/extra.conf.in1 Oct 2003 17:22:57 - @@ -23,3 +23,5 @@ PerlModule Doesnt::Exist +ScriptSock logs/cgisock +SetEnv TMPDIR /tmp -- Haroon Rafique <[EMAIL PROTECTED]> Index: ModPerl-Registry/t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v retrieving revision 1.10 diff -u -r1.10 extra.conf.in --- ModPerl-Registry/t/conf/extra.conf.in 5 Aug 2003 18:51:10 - 1.10 +++ ModPerl-Registry/t/conf/extra.conf.in 1 Oct 2003 17:22:56 - @@ -145,4 +145,5 @@ SetOutputFilter DEFLATE - \ No newline at end of file + +ScriptSock logs/cgisock Index: t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/t/conf/extra.conf.in,v retrieving revision 1.6 diff -u -r1.6 extra.conf.in --- t/conf/extra.conf.in3 Feb 2003 22:56:19 - 1.6 +++ t/conf/extra.conf.in1 Oct 2003 17:22:57 - @@ -23,3 +23,5 @@ PerlModule Doesnt::Exist +ScriptSock logs/cgisock +SetEnv TMPDIR /tmp
Re: [mp2] running make test as unpriveleged user
Haroon Rafique wrote: Hi, Find attached (and inline) a patch for smoother running of "make test" when running as a non-privileged user. This issue came to light while running Gentoo Linux. The Gentoo package system "portage" has the ability to run as a non-root user while building packages. Some file locations were not accessible to that non-root user while running make test. E.g., on Gentoo, mod_cgid defaults to using /var/run/cgisock for its sockets, however, the permissions for /var/run/cgisock on Gentoo are: srwx--1 apache root0 Oct 1 13:14 /var/run/cgisock I used the ScriptSock directive to tell mod_cgid to make the socket file within the self-contained directory tree. Along the same lines, CGI.pm likes to create new temp files in /tmp. I used the SetEnv directive to set TMPDIR environemnt variable to force it to create the temp files in a self-contained directory tree. Comments are welcome. And we really should have a newline at the end of ModPerl-Registry/t/conf/extra.conf.in certainly, but does it break anything? [...] +SetEnv TMPDIR /tmp This is not a portable change. If you have a particular problem with regards to temp dir it needs to be solved where it arises (e.g. using File::Temp), but you don't tell what the problem is, so I can't give you a solution. > +ScriptSock logs/cgisock We don't use mod_cgi in the mod_perl test suite. It's just a left-over from testing. Does this patch fix things for you? Index: t/conf/extra.conf.in === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v retrieving revision 1.10 diff -u -r1.10 extra.conf.in --- t/conf/extra.conf.in5 Aug 2003 18:51:10 - 1.10 +++ t/conf/extra.conf.in1 Oct 2003 21:39:21 - @@ -35,8 +35,6 @@ Alias /registry_oo_conf/ @ServerRoot@/cgi-bin/ Alias /perlrun/ @ServerRoot@/cgi-bin/ -ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ - PerlModule ModPerl::RegistryBB PerlOptions +GlobalRequest __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] running make test as unpriveleged user
On Today at 2:42pm, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> > Comments are welcome. And we really should have a newline at the end of SB> > ModPerl-Registry/t/conf/extra.conf.in SB> SB> certainly, but does it break anything? SB> Hi Stas, Doesn't break anything really, but when I was using the >> operator to tack on some directives at the end of this file not having the newline caused me some grief as the last line and my added line got stuck on the same line (oops that makes it a misspelled directive - sheepish grin :-)) SB> [...] SB> SB> > +SetEnv TMPDIR /tmp SB> SB> This is not a portable change. If you have a particular problem with SB> regards to temp dir it needs to be solved where it arises (e.g. using SB> File::Temp), but you don't tell what the problem is, so I can't give SB> you a solution. I really should spend more time explaining the issue rather than jumping to the solution. Thanks for listening. Here's the issue. As I mentioned Gentoo's pacakge mgmt. system has the capability to build/install as a non-root user. Somewhere down line during the tests, the following tests are failing when run under the non-root user. modules/cgiNOK 3# Failed test 3 in modules/cgi.t at line 41 modules/cgiFAILED test 3 Failed 1/5 tests, 80.00% okay modules/cgiupload..NOK 1# Failed test 1 in modules/cgiupload.t at line 32 modules/cgiupload..NOK 2# Failed test 2 in modules/cgiupload.t at line 32 fail #2 modules/cgiupload..FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Looing at t/logs/error_log, we find: [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink unix domain socket /var/run/cgisock [Wed Oct 01 18:15:18 2003] [error] (98)Address already in use: Couldn't bind unix domain socket /var/run/cgisock ACCESS DENIED unlink:/var/run/cgisock As I mentioned earlier, the permissions for /var/run/cgisock are not accissible by the non-root user. In addition, it is a violation of the sandbox principle. My fix for ScriptSock was meant to appease mod_cgid into creating the cgisock in the logs directory instead which will make it self-contained and won't violate the sandbox. In the case of SetEnv TMPDIR /tmp, CGI.pm uses /tmp as its temporary repository. Access to /tmp is again a violation of the sandbox. I agree that /tmp is not a portable solution but setting TMPDIR is the only way that I can think of to vary CGI.pm's behavior thru the httpd conf file. Perhaps, a kludge like: SetEnv TMPDIR logs would suffice. I believe CGI.pm cleans up after itself anyway. SB> SB> > +ScriptSock logs/cgisock SB> SB> We don't use mod_cgi in the mod_perl test suite. It's just a left-over SB> from testing. Does this patch fix things for you? SB> Nope, the patch had no effect whatsoever in the tests not failing. Regards, -- Haroon Rafique <[EMAIL PROTECTED]>
Re: Apache::Session::File locks getting stuck
On Wed, 1 Oct 2003, Javier Alvarado wrote: > 2) Make sure the session is untied after *every* request (i.e. even if > a request is aborted, an error occurs in the middle, etc). Otherwise, > when the next request tries to tie it it will block. With MasonX::Request::WithApacheSession, this should happen automatically, since the session is stored in the request object, and the request object only lives for a single request. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [mp2] running make test as unpriveleged user
Haroon Rafique wrote: On Today at 2:42pm, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> > Comments are welcome. And we really should have a newline at the end of SB> > ModPerl-Registry/t/conf/extra.conf.in SB> SB> certainly, but does it break anything? SB> Hi Stas, Doesn't break anything really, but when I was using the >> operator to tack on some directives at the end of this file not having the newline caused me some grief as the last line and my added line got stuck on the same line (oops that makes it a misspelled directive - sheepish grin :-)) Sure, please find all the files that miss the end lines and post a patch fixing them, which will gladly apply and try to remember to keeping them in place in the future. SB> [...] SB> SB> > +SetEnv TMPDIR /tmp SB> SB> This is not a portable change. If you have a particular problem with SB> regards to temp dir it needs to be solved where it arises (e.g. using SB> File::Temp), but you don't tell what the problem is, so I can't give SB> you a solution. I really should spend more time explaining the issue rather than jumping to the solution. Thanks for listening. Here's the issue. As I mentioned Gentoo's pacakge mgmt. system has the capability to build/install as a non-root user. Somewhere down line during the tests, the following tests are failing when run under the non-root user. modules/cgiNOK 3# Failed test 3 in modules/cgi.t at line 41 modules/cgiFAILED test 3 Failed 1/5 tests, 80.00% okay modules/cgiupload..NOK 1# Failed test 1 in modules/cgiupload.t at line 32 modules/cgiupload..NOK 2# Failed test 2 in modules/cgiupload.t at line 32 fail #2 modules/cgiupload..FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Looing at t/logs/error_log, we find: [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink unix domain socket /var/run/cgisock [Wed Oct 01 18:15:18 2003] [error] (98)Address already in use: Couldn't bind unix domain socket /var/run/cgisock ACCESS DENIED unlink:/var/run/cgisock As I mentioned earlier, the permissions for /var/run/cgisock are not accissible by the non-root user. In addition, it is a violation of the sandbox principle. My fix for ScriptSock was meant to appease mod_cgid into creating the cgisock in the logs directory instead which will make it self-contained and won't violate the sandbox. In the case of SetEnv TMPDIR /tmp, CGI.pm uses /tmp as its temporary repository. Access to /tmp is again a violation of the sandbox. I agree that /tmp is not a portable solution but setting TMPDIR is the only way that I can think of to vary CGI.pm's behavior thru the httpd conf file. Perhaps, a kludge like: SetEnv TMPDIR logs would suffice. I believe CGI.pm cleans up after itself anyway. I think you mix two to some extent unrelated problems together. Let's solve each problem apart. 1) the three tests above are failing due to the /tmp problem in the sandbox, right? I believe your proposal of using the logs dir is cool. However we want to add a comment of why we do that (self-contained?) and I don't think it'll work without using a fullpath. So it probably should be: + # keep everything self-contained, to avoid problems with sandboxes + SetEnv TMPDIR @t_logs@ running t/TEST -conf should expand @t_logs@ to its full path. To be consistent let's put it in both test suites and eventually we might merge it into Apache-Test so it'll do that by itself. Does it solve the problem with failing tests? If so please post a patch that works for you. Another alternative is to introduce a new directory for Apache-Test: t/tmp and a corresponding -tmp option to override the default, which is probably a cleaner solution in the long run. SB> SB> > +ScriptSock logs/cgisock SB> SB> We don't use mod_cgi in the mod_perl test suite. It's just a left-over SB> from testing. Does this patch fix things for you? SB> Nope, the patch had no effect whatsoever in the tests not failing. 2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink > unix domain socket /var/run/cgisock I'm trying to understand why do we have this problem when we don't use mod_cgid. Is it because mod_cgid gets loaded? but your patch sounds good to me. Again something to consider to merge into the Apache-Test autogenerator. In fact we should probably just do it. Will the following work: ScriptSock logs/cgisock __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Mason] Re: Apache::Session::File locks getting stuck
On Wed, 2003-10-01 at 18:56, Dave Rolsky wrote: > On Wed, 1 Oct 2003, Javier Alvarado wrote: > > > 2) Make sure the session is untied after *every* request (i.e. even if > > a request is aborted, an error occurs in the middle, etc). Otherwise, > > when the next request tries to tie it it will block. > > With MasonX::Request::WithApacheSession, this should happen automatically, > since the session is stored in the request object, and the request object > only lives for a single request. It would still be possible to screw this up if someone copied it into a global or made a closure, intentionally or not. That's what I would look for. - Perrin
mod_perl 2: APR::URI scheme and path_info
Title: mod_perl 2: APR::URI scheme and path_info my $uri = APR::URI->parse; I want to find out what the scheme (http, https) was for the current request. I also want to find out (and maybe set) the path_info What's the right way to do this? -- -- Matisse Enzer Doodlelab Inc. 415-925-5294 ext. 212 (office) 415-225-6703 (mobile)
Re: mod_perl 2: APR::URI scheme and path_info
Matisse Enzer wrote: my $uri = APR::URI->parse; I want to find out what the scheme (http, https) was for the current request. APR::URI->parse($r->pool, $r->uri)->scheme; I also want to find out (and maybe set) the path_info What's the right way to do this? $path_info = $r->path_info; $r->path_info($path_info); __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] running make test as unpriveleged user
On Today at 4:12pm, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> SB> Sure, please find all the files that miss the end lines and post a SB> patch fixing them, which will gladly apply and try to remember to SB> keeping them in place in the future. Really its no big deal. Just one file which is fixed in the attached patch. SB> SB> [...] SB> SB> + # keep everything self-contained, to avoid problems with sandboxes SB> + SetEnv TMPDIR @t_logs@ Seems logical. Attached patch follows this theme. SB> SB> [...] SB> SB> Does it solve the problem with failing tests? If so please post a SB> patch that works for you. Yes, the patch fixes the failing tests/sandbox violations. Find attached. SB> SB> Another alternative is to introduce a new directory for Apache-Test: SB> t/tmp and a corresponding -tmp option to override the default, which SB> is probably a cleaner solution in the long run. All good ideas for the long run. Not familiar with Apache-Test, so can't comment. SB> SB> 2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: SB>Couldn't unlink SB> > unix domain socket /var/run/cgisock SB> SB> I'm trying to understand why do we have this problem when we don't use SB> mod_cgid. Is it because mod_cgid gets loaded? Good question. Here's what I believe is happening. /usr/sbin/apxs2 is the path to my APache eXtenSion tool. During the conf generation process apxs2 is used to figure out the location of the central config file for apache2 (/etc/apache2/conf/apache2.conf). This file does have a: LoadModule cgid_module modules/mod_cgid.so line. References to cgid are then found abundantly in t/conf/apache_test_config.pm (another generated file). Finally, the following section appears in the generated file t/conf/httpd.conf: LoadModule cgid_module "/etc/apache2/modules/mod_cgid.so" Should (and more importantly how do) we attempt to keep cgid out of the conf files? SB> SB> [...] SB> SB> SB> ScriptSock logs/cgisock SB> Attached patch uses the above lines as well. -- Haroon Rafique <[EMAIL PROTECTED]>Index: ModPerl-Registry/t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v retrieving revision 1.10 diff -u -r1.10 extra.conf.in --- ModPerl-Registry/t/conf/extra.conf.in 5 Aug 2003 18:51:10 - 1.10 +++ ModPerl-Registry/t/conf/extra.conf.in 2 Oct 2003 02:45:11 - @@ -145,4 +145,9 @@ SetOutputFilter DEFLATE - \ No newline at end of file + +# keep everything self-contained, to avoid problems with sandboxes + +ScriptSock logs/cgisock + +SetEnv TMPDIR @t_logs@ Index: t/conf/extra.conf.in === RCS file: /home/cvspublic/modperl-2.0/t/conf/extra.conf.in,v retrieving revision 1.6 diff -u -r1.6 extra.conf.in --- t/conf/extra.conf.in3 Feb 2003 22:56:19 - 1.6 +++ t/conf/extra.conf.in2 Oct 2003 02:45:12 - @@ -23,3 +23,8 @@ PerlModule Doesnt::Exist +# keep everything self-contained, to avoid problems with sandboxes + +ScriptSock logs/cgisock + +SetEnv TMPDIR @t_logs@
FAIL mod_perl-1.99_10 MSWin32-x86-multi-thread 4.0
This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to [EMAIL PROTECTED] to keep other test volunteers informed and to prevent any duplicate effort. -- E:\new\mod_perl-1.99_10>perl Makefile.PL MP_AP_PREFIX=C:\Apache2 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = C:\Apache2 Configuring Apache/2.0.46 mod_perl/1.99_10 Perl/v5.8.1 Checking if your kit is complete... Looks good generating script t/TEST Checking if your kit is complete... Looks good Writing Makefile for Apache::Test generating script t/TEST Checking if your kit is complete... Looks good Writing Makefile for ModPerl::Registry Writing Makefile for APR::Base64 Writing Makefile for APR::Brigade Writing Makefile for APR::Bucket Writing Makefile for APR::Date Writing Makefile for APR::NetLib Writing Makefile for APR::OS Writing Makefile for APR::Pool Writing Makefile for APR::SockAddr Writing Makefile for APR::Socket Writing Makefile for APR::String Writing Makefile for APR::Table Writing Makefile for APR::ThreadMutex Writing Makefile for APR::URI Writing Makefile for APR::UUID Writing Makefile for APR::Util Writing Makefile for APR Writing Makefile for Apache::Access Writing Makefile for Apache::CmdParms Writing Makefile for Apache::Command Writing Makefile for Apache::Connection Writing Makefile for Apache::Directive Writing Makefile for Apache::Filter Writing Makefile for Apache::FilterRec Writing Makefile for Apache::HookRun Writing Makefile for Apache::Log Writing Makefile for Apache::Module Writing Makefile for Apache::Process Writing Makefile for Apache::RequestIO Writing Makefile for Apache::RequestRec Writing Makefile for Apache::RequestUtil Writing Makefile for Apache::Response Writing Makefile for Apache::Server Writing Makefile for Apache::ServerUtil Writing Makefile for Apache::SubProcess Writing Makefile for Apache::SubRequest Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for Apache Writing Makefile for ModPerl::Global Writing Makefile for ModPerl::Util Writing Makefile for ModPerl Writing Makefile for ModPerl::WrapXS Writing Makefile for APR Writing Makefile for APR::Const Writing Makefile for APR::PerlIO Writing Makefile for APR Writing Makefile for Apache::Const Writing Makefile for Apache Writing Makefile for ModPerl::Const Writing Makefile for ModPerl Writing Makefile for ModPerl::XS Writing Makefile for mod_perl *** mod_perl dso library will be built as mod_perl.so *** mod_perl static library will be built as mod_perl.lib *** You'll need to add the following to httpd.conf: *** LoadModule perl_module modules/mod_perl.so E:\new\mod_perl-1.99_10>nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd "src/modules/perl" && NMAKE -f Makefile.modperl Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -IE:/new/mod_perl-1.99_10/src/modules/perl -IE:/new/mod_perl-1.99_10/xs -IC:\Apache2/include -IC:\Apache2/include -nolo go -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PE RLIO -DPERL_MSVCRT_READFIX -I"G:\perls\5.8.1\lib\CORE" -DMOD_PERL -DMP_COMPAT_1X -MD -DNDEBUG -O1 -c mod_perl.c && G:\perls\5.8 .1\bin\perl.exe -MExtUtils::Command -e mv mod_perl.obj mod_perl.lo mod_perl.c cl -IE:/new/mod_perl-1.99_10/src/modules/perl -IE:/new/mod_perl-1.99_10/xs -IC:\Apache2/include -IC:\Apache2/include -nolo go -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PE RLIO -DPERL_MSVCRT_READFIX -I"G:\perls\5.8.1\lib\CORE" -DMOD_PERL -DMP_COMPAT_1X -MD -DNDEBUG -O1 -c modperl_interp.c && G:\per ls\5.8.1\bin\perl.exe -MExtUtils::Command -e mv modperl_interp.obj modperl_interp.lo modperl_interp.c cl -IE:/new/mod_perl-1.99_10/src/modules/perl -IE:/new/mod_perl-1.99_10/xs -IC:\Apache2/include -IC:\Apache2/include -nolo go -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PE RLIO -DPERL_MSVCRT_READFIX -I"G:\perls\5.8.1\lib\CORE" -DMOD_PERL -DMP_COMPAT_1X -MD -DNDEBUG -O1 -c modperl_tipool.c && G:\per ls\5.8.1\bin\perl.exe -MExtUtils::Command -e mv modperl_tipool.obj modperl_tipool.lo modperl_tipool.c cl -IE:/new/mod_perl-1.99_10/src/modules/perl -IE:/new/mod_perl-1.99_10/xs -IC:\Apache2/include -IC:\Apache2/include -nolo go -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PE RLIO -DPERL_MSVCRT_READFIX -I"G:\perls\5.8.1\lib\CORE" -DMOD_PERL -DMP_COMPAT_1X -MD -DNDEBUG -O1 -c modperl_log.c && G:\perls\ 5.8.1\bin\perl.exe -MExtUtils::Command -e mv modperl_log.obj modperl_log.lo mod
Re: [mp2] running make test as unpriveleged user
Haroon Rafique wrote: Yes, the patch fixes the failing tests/sandbox violations. Find attached. You get to break the 1.99_11-dev ice ;) Thanks, committed (with some more XXX noise, so we get this to polish later) SB> SB> Another alternative is to introduce a new directory for Apache-Test: SB> t/tmp and a corresponding -tmp option to override the default, which SB> is probably a cleaner solution in the long run. All good ideas for the long run. Not familiar with Apache-Test, so can't comment. I think you will want it in a short run as well (I mean the merging of your patches into the autogenerated httpd.conf), because all other Apache:: modules using Apache::Test will have the same issues. So the next time you encounter this knock again here so we get it into Apache-Test. SB> 2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: SB>Couldn't unlink SB> > unix domain socket /var/run/cgisock SB> SB> I'm trying to understand why do we have this problem when we don't use SB> mod_cgid. Is it because mod_cgid gets loaded? Good question. Here's what I believe is happening. /usr/sbin/apxs2 is the path to my APache eXtenSion tool. During the conf generation process apxs2 is used to figure out the location of the central config file for apache2 (/etc/apache2/conf/apache2.conf). This file does have a: LoadModule cgid_module modules/mod_cgid.so line. References to cgid are then found abundantly in t/conf/apache_test_config.pm (another generated file). Finally, the following section appears in the generated file t/conf/httpd.conf: LoadModule cgid_module "/etc/apache2/modules/mod_cgid.so" That's right, it inherits from the global httpd.conf installed system-wide. Should (and more importantly how do) we attempt to keep cgid out of the conf files? Nuh, you gave us the fix, so we are all set ;) Thank you. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: invoking sub/methods shortcut
[EMAIL PROTECTED] wrote: Can I do something like this? from $sth = getVUser($dbh, $u, $d); return $sth->rows(); to return (getVUser($dbh,$u,$d))->rows(); a move from java->perl ;) Please don't cross-post irrelevant to mod_perl questions in the future. Thank you. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
invoking sub/methods shortcut
Can I do something like this? from $sth = getVUser($dbh, $u, $d); return $sth->rows(); to return (getVUser($dbh,$u,$d))->rows(); a move from java->perl ;) thanks, -rkl
