Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: > Thanks for the leads. My concentration definitely lapsed over the make test > failure. > I ran make install regardless and all was well. I attempted to start the > server without success. > Here's the error message from the error_log > > [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's > fully qualified domain name, using 127.0.0.1 for ServerName add to /etc/hosts: 127.0.0.1 localhost.localdomain localhost > [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid > overwritten -- Unclean shutdown of previous Apache run? > [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 > configured -- resuming normal operations > [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So it starts normally. > perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas > I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may > have to try installing Perl 5.6.1 again. > I'll report the results. If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have installed perl into /usr/local/bin and /usr/bin comes earlier in the path so it picks 5.6.0. Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries though I can see that you will have dependencies problems. __ 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
test
test
Re: Problems with Apache/Mod_perl Server
Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. Thanks, Alfred, Stas Bekman wrote: > Alfred Vahau wrote: > > Hello, > > > > I am posting this matter to the list because it takes so long from my > > end of the world to download the relevant information for trouble > > shooting. My problem is as follows: > > > > I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I > > followed all the instructions in the mod_perl guide on how to set up the > > server and had it running successfully without any problems. > > Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. > > I downlloaded from the mirror site at nagoya. > > I am following the same instructions which are, after uncompressing > > them: > > > > 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ > > DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 > > > > Everthing goes smoothly. Then: > > > > 2. make && make test && make install > > > > The executiion is smooth until the test part which I believe fails and > > hence the install leg is aborted? > > > > The error output at the end is: > > > > ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > > httpd listening on port 8529 > > will write error_log to: t/logs/error_log > > letting apache warm up...\c > > done > > /usr/bin/perl t/TEST 0 > > still waiting for server to warm up...not ok > > server failed to start! (please examine t/logs/error_log) at t/TEST line > > 95. > > make: *** [run_tests] Error 9 > > > > The t/logs/error_log reads > > > > [notice] Destruction->DESTROY called for $global_object > > Prototype mismatch: sub Socket::INADDR_ANY vs () at > > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. > > Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at > > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. > > Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at > > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. > > Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at > > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. > > [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, > > report any problems to [no address given] > > [...] > > > I think the failure is due to incomplete mod_perl installation. > > of course. You run: > > make && make test && make install > > 'make test' fails, and therefore 'make install' is not run. simply run it. > > regarding the failing 'make test', you say that you run 5.6.1, and the > error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess > you have libs from 5.6.0 installed and they get on the way. > > __ > 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: mod_perl 2.0 api and extending method in Apache
Alexandre Dulaunoy wrote:
> Hello,
>
> I have look around the documentation of mod_perl 2.0 and I'm looking if
> it's possible with the current mod_perl API to add a method (like GET,
> HEAD) in apache to extend the functionnaly of the HTTP server ?
>
> There is also some possibility with the new framework to add new protocol
> (like the echo example in the mod_perl doc). But I just want to extend
> existing (or add new) method... Is it possible ?
I'm not sure what you mean by extending, but look at mod_dav which
extends the HTTP protocol: modules/dav/main/mod_dav.c (inside the
httpd-2.0 repository).
In mod_perl 2.0 you can support new request methods, by simply
registering them. e.g. let's support the method 'TNT' in the response
handler:
SetHandler perl-script
PerlResponseHandler Apache::Extend
package Apache::Extend;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile => 'OK';
use constant METHNAME => 'TNT';
sub handler {
my $r = shift;
$r->content_type('text/plain');
Apache::method_register($r->pool, METHNAME);
print "Called with Method: " . $r->method;
Apache::OK;
}
1;
Now, let's call:
perl -le 'require LWP::UserAgent; print
LWP::UserAgent->new->request(HTTP::Request->new("GET",
"http://localhost:8002/extend/";))->content;'
Called with Method: GET
__
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: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: > Hello, > > I am posting this matter to the list because it takes so long from my > end of the world to download the relevant information for trouble > shooting. My problem is as follows: > > I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I > followed all the instructions in the mod_perl guide on how to set up the > server and had it running successfully without any problems. > Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. > I downlloaded from the mirror site at nagoya. > I am following the same instructions which are, after uncompressing > them: > > 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ > DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 > > Everthing goes smoothly. Then: > > 2. make && make test && make install > > The executiion is smooth until the test part which I believe fails and > hence the install leg is aborted? > > The error output at the end is: > > ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...\c > done > /usr/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > make: *** [run_tests] Error 9 > > The t/logs/error_log reads > > [notice] Destruction->DESTROY called for $global_object > Prototype mismatch: sub Socket::INADDR_ANY vs () at > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. > Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. > Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. > Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at > /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. > [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, > report any problems to [no address given] [...] > I think the failure is due to incomplete mod_perl installation. of course. You run: make && make test && make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ 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
Problems with Apache/Mod_perl Server
Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make && make test && make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction->DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] 3. Then I backup into the apache_1.3.26 directory and issue make install I am congratulated for a successful installation. 4. The I issue (as root) /usr/local/apache/bin/apachectl start and the error message from the /usr/local/apache/logs/error_log [Tue Jul 30 16:01:52 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Apache.pm failed to load!. [Tue Jul 30 16:37:55 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Tue Jul 30 16:37:55 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. [Wed Jul 31 12:27:57 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 12:27:57 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. I think the failure is due to incomplete mod_perl installation. As I pointed out earlier, the earlier versions of mod_perl and apache were installed successfully. I was configuring the httpd.conf file to run some cgi scripts which did not execute very well but I think can fix that. I've spent the past 48 hours trying to trouble shoot the trouble as much as I can but access to information is so very frustrating from this end of the world.. I am using Perl 5.6.1 on Linux 7.1. I installed the mod_perl and apache packages which came with the box but did not use them so had them unstalled. Any pointers to where I can start meaningful trouble-shooting would be greatly appreciated. Thanks in advance, Alfred Vahau School of Natural and Physical Sciences Uni. PNG
Re: $r->dir_config->(un)set issue...
Does that mean that
$r->dir_config is not the same as $r->server->dir_config ?
A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
On Wed, 2002-07-31 at 12:50, Stas Bekman wrote:
> s/$r->dir_config/$r->server->dir_config/?
>
> What's really needed is probably PerlUnSetEnv.
>
> simran wrote:
> > Hi All,
> >
> > I have a situation where it is convinent for me to define a global
> > "PerlSetVar" in my httpd.conf and then unset it for particular virtual
> > hosts.
> >
> > I used to use the following configuration successfully:
> >
> >
> > httpd.conf
> > --
> >
> >
> > use Apache::Server;
> > Apache->server->dir_config->unset("MyVar");
> >
> >
> > -
> >
> > That stopped working for me ever since we compiled
> > Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
> >
> >
> > Has anyone else had the same issue?
> >
> > On a similar note:
> >
> > The following pices of code do not work:
> >
> > -
> > code sample 1
> > --
> >
> > 1. sub handler {
> > 2.my $r = instance Apache::Request(shift);
> > 3.
> > 4.$r->dir_config(MyVar => undef);
> > 5.
> > 6.$r->dir_config->unset("MyVar");
> > 7.
> > 8.$r->dir_config->set(MyVar => undef);
> > 9.
> > 10. }
>
> s/$r->dir_config/$r->server->dir_config/?
>
> What's really needed is probably PerlUnSetEnv.
>
> > None of lines 4, 6 or 8 actually unset the variable.
> >
> > A collegue tells me that if a "true" value (for the key MyVar) is not
> > passed to set then it ends up returning the value of MyVar - but then
> > how i want to set the value of MyVar to be false. I would have though
> > that unset/set would have specifically done what i told them to
> > unset/set rather than do fancy things with truth values...
> >
> > Ideas anyone?
> >
> > simran.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
>
>
> __
> 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: $r->dir_config->(un)set issue...
simran wrote:
> Hi All,
>
> I have a situation where it is convinent for me to define a global
> "PerlSetVar" in my httpd.conf and then unset it for particular virtual
> hosts.
>
> I used to use the following configuration successfully:
>
>
> httpd.conf
> --
>
>
> use Apache::Server;
> Apache->server->dir_config->unset("MyVar");
>
>
> -
>
> That stopped working for me ever since we compiled
> Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
>
>
> Has anyone else had the same issue?
>
> On a similar note:
>
> The following pices of code do not work:
>
> -
> code sample 1
> --
>
> 1. sub handler {
> 2.my $r = instance Apache::Request(shift);
> 3.
> 4.$r->dir_config(MyVar => undef);
> 5.
> 6.$r->dir_config->unset("MyVar");
> 7.
> 8.$r->dir_config->set(MyVar => undef);
> 9.
> 10. }
s/$r->dir_config/$r->server->dir_config/?
What's really needed is probably PerlUnSetEnv.
> None of lines 4, 6 or 8 actually unset the variable.
>
> A collegue tells me that if a "true" value (for the key MyVar) is not
> passed to set then it ends up returning the value of MyVar - but then
> how i want to set the value of MyVar to be false. I would have though
> that unset/set would have specifically done what i told them to
> unset/set rather than do fancy things with truth values...
>
> Ideas anyone?
>
> simran.
>
>
>
>
>
>
>
>
>
>
>
>
--
__
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: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Josh Chamas wrote: > My only problem with Apache::DBI for a benchmark is its > default ping of the db per connect(). Oh, you're right I wasn't thinking about that. It is important in a benchmark to be testing equivalent functionality as much as possible, although it's very difficult to do. > I spent hours ( & 12 lines of code :) ) > writing an overly simple database connection pooling manager > for the JSP benchmarks where a standard one seems to be > lacking in JDBC & JNDI I thought that JDBC had a pooling capability now. I also thought Resin had something built in. I would use those if possible. Stick with Apache::DBI for mod_perl though. I would never tell anyone to roll their own database persistence for performance instead of using Apache::DBI. Pinging the database connection is good, and all systems should do it if they don't already. - Perrin
Re: mod_perl2 & DBD::Oracle problem
Atsushi Fujita wrote:
> Hi all,
>
> I am trying to use DBD::Oracle1.12 on mod_perl2.
> But it doesn't work fine.
> It shows error as following in error_log at $dbh = DBI->connect.
>
> [error_log]
> DBI->connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
> ORACLE_HOME and NLS settings etc. at
> /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
> [Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot connect:
> (UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
> NLS settings etc.at
> /yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
>
>
>
> [test1.cgi]
> use DBI;
>
> my $dsn = 'dbi:Oracle:';
> my $user = 'username/password';
> my $password = '';
>
> $ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
> $ENV{'ORACLE_SID'} = 'ynt0';
> $ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
>
> print "ORACLE_HOME=$ENV{'ORACLE_HOME'}\n";
> print "ORACLE_SID=$ENV{'ORACLE_SID'}\n";
> print "NLS_LANG=$ENV{'NLS_LANG'}\n";
> print "DSN=$dsn$ENV{'ORACLE_SID'}\n";
>
> $dbh = DBI->connect("$dsn$ENV{'ORACLE_SID'}", $user, $password)
> or die "Cannot connect: ".$DBI::errstr;
> ...
>
>
> At first, I suspect that the reason is %ENV in this script.
> But I set surely, and this output as following.
>
> [Broser output HTML]
> ORACLE_HOME=/u01/app/oracle/product/9.0.1
> ORACLE_SID=ynt0
> NLS_LANG=japanese_japan.ja16euc
> DSN=dbi:Oracle:ynt0
>
> Internal Server Error
> The server encountered an internal error or misconfiguration and was unable to
> complete your request.
>
>
>
> And if I turned off the mod_perl, it works fine on normal CGI-script.
> This error occurred only mod_perl.
> (I tested mod_perl1.26 & apache 1.3.26, it worked fine...)
>
> My machine is as following.
> - perl5.6.1(non thread)
> - DBI-1.30
> - DBD-Oracle-1.12
> - mod_perl1.99_04(DSO build)
> - apache2.0.39(prefork)
>
>
> [httpd.conf](is this wrong??)
> LoadModule perl_module modules/mod_perl.so
> ...
>
> PerlModule ModPerl::Registry
>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
>
>
>
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some other way to reproduce the problem without depending on Oracle
being installed?
Can you please test with the following two approaches:
1.
instead of using ModPerl::Registry, use Apache::Registry. Of course
configure to use Apache::Registry.
use Apache::compat;
use Apache::Registry; # hopefull you have mod_perl 1.0 installed
any change when you use the Apache::Registry from 1.0? Currently the
only difference (mainly) is that ModPerl::Registry doesn't chdir() into
the script's dir. (which eventually will change)
2. use a mod_perl handler
__
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: Apache::Status patch, in diff -u format (finally ;)
DH wrote:
> Index: Status.pm
> ===
> RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
> retrieving revision 1.26
> diff -u -r1.26 Status.pm
> --- Status.pm 23 May 2002 16:14:56 - 1.26
> +++ Status.pm 30 Jul 2002 12:39:07 -
> @@ -514,6 +514,7 @@
> mkdir $dir, 0755 unless -d $dir;
>
> (my $thing = $r->path_info) =~ s:^/::;
> +$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
> my $type = "dot";
> my $file = "$dir/$thing.$$.gif";
Thanks, committed
__
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: Fwd: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
>>You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
>>while not under mod_perl. You said this:
>>
>>
>>
>>>That's normal. You cannot test modules that use mod_perl API without
>>>running them inside mod_perl server. I've the same problem as you've
>>>reported. This test suite is simple broken.
>>>...
>>>All Apache:: module authors should be moving to use the new Apache::Test
>>>framework soon, since it lets you test the code under running mod_perl
>>>server and works with both versions of httpd/mod_perl.
>>
>>
>>This is exactly my situation. I develop a module which requires Apache::DBI,
>>so I include it in my Makefile.PL like this:
>>
>>WriteMakefile(
>>'PREREQ_PM'=> {
>>'Apache::DBI' => 0,
>>},
>>);
>>
>>But that prints a warning because Apache::DBI can't find Apache::module(),
>>which is only available under mod_perl.
>>
>>My question:
>>1) Can you tell me (or guide me toward some information) how I can properly
>>add Apache::DBI as a prerequisite so that it doesn't print a warning (which
>>is the subjet of 90% of user emails)?
>>2) How can I test my module running Apache::DBI with Apache::Test?
I'll answer these in reverse:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an interesting problem. It seems that nobody has asked this
question before. Here is my take on it. If you like this solution I'll
add it to the docs.
Makefile.PL
---
use ExtUtils::MakeMaker;
# set prerequisites
my %prereq = (
Foo => 1.56,
);
# Manually test whether Apache::DBI is installed and add it to the
# PREREQ_PM if it's not installed, so CPAN.pm will automatically fetch
# it. If Apache::DBI is already installed it will fail to get loaded by
# MakeMaker because it requires the mod_perl environment to load.
eval { require Apache::DBI };
if ($@ && $@ !~ /Can't locate object method/) {
$prereq{Apache::DBI} = '';
}
WriteMakefile(
NAME => 'Apache::SuperDuper',
VERSION_FROM => 'SuperDuper.pm',
PREREQ_PM => \%prereq,
# ...
);
__
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: Subject: Re: hiding perl code
> You are correct. If you... > > use Hidden::Module > > then use Data::Dumper to reconstruct most of the raw code. This would be > about as useful as decompiling 'B' code. If you had access to the > intrepreter directly, you could probably even capture the decrypt stream > before perl compiles it, but all of that would take a degree of > sophistication that is better used to make real money instead of > hacking stuff apart. > > How about BZS::VeryObscure :-) Be it BZS::VeryObscure or BZS::VeryVeryObscure, all I was asking for is to tell the thruth in the docs probably somewhere at the top. I agree that for certain purposes this module may satisfy those who use it, but not all of them. __ 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: make test problem error 111
Hi, I reinstalled perl 5.6.1 with the following modules - HTML-Parser-3.26.tar.gz - libnet-1.12.tar.gz - libwww-perl-5.65.tar.gz - MIME-Base64-2.12.tar.gz - URI-1.19.tar.gz - Digest-MD5-2.20.tar.gz and followed the instructions I used before to install apache,mod_perl + mod_ssl and it worked for me... Thanks for your help Padraic - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Padraic Woods" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, July 30, 2002 4:35 AM Subject: Re: make test problem error 111 > Padraic Woods wrote: > > Hi, > > I'm trying to install apache + mod_perl + mod_ssl but get a error after > > running make test, I've tried skiping the make test but get a > > segmentation fault when I try starting apache. > > [...] > > > ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > > > > httpd listening on port 8529 > > > > will write error_log to: t/logs/error_log > > > > () gets absurdforkletting apache warm up...\c > > that's an interesing message: gets absurdfork > where does it come from? > > no error_log is bad, > have you tried following the install notes in: > http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___op enssl_ > > if you get a segfault, please follow the instructions at: > http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems > > > __ > 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 > >
Fwd: Re: Apache::DBI as a prerequisite
Could you please take a look at this problem? Thanks.
- Forwarded message from Stas Bekman <[EMAIL PROTECTED]> -
Date: Mon, 29 Jul 2002 09:56:05 +0800
From: Stas Bekman <[EMAIL PROTECTED]>
Reply-To: Stas Bekman <[EMAIL PROTECTED]>
Subject: Re: Apache::DBI as a prerequisite
To: Simon Perrault <[EMAIL PROTECTED]>
Simon, please repost to the modperl list and we will discuss it there.
Thanks.
Simon Perrault wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
> while not under mod_perl. You said this:
>
>
>>That's normal. You cannot test modules that use mod_perl API without
>>running them inside mod_perl server. I've the same problem as you've
>>reported. This test suite is simple broken.
>>...
>>All Apache:: module authors should be moving to use the new Apache::Test
>>framework soon, since it lets you test the code under running mod_perl
>>server and works with both versions of httpd/mod_perl.
>
>
> This is exactly my situation. I develop a module which requires Apache::DBI,
> so I include it in my Makefile.PL like this:
>
> WriteMakefile(
> 'PREREQ_PM'=> {
> 'Apache::DBI' => 0,
> },
> );
>
> But that prints a warning because Apache::DBI can't find Apache::module(),
> which is only available under mod_perl.
>
> My question:
> 1) Can you tell me (or guide me toward some information) how I can properly
> add Apache::DBI as a prerequisite so that it doesn't print a warning (which
> is the subjet of 90% of user emails)?
> 2) How can I test my module running Apache::DBI with Apache::Test?
>
> Thanks a lot
>
> - --
> Simon Perreault <[EMAIL PROTECTED]>
> Web: http://www.linuxquebec.com/~nomis80
> PGP: $Web/nomis80.gpg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9QwYAqaCdwBMK2KkRAt+pAJ9knR94Tz5jmBFCyO/hL/fNWwHzmwCfZSl0
> 66Chb76wE6YcgR6JbxYpQEc=
> =4xfy
> -END PGP SIGNATURE-
--
__
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
- End forwarded message -
--
Simon Perreault <[EMAIL PROTECTED]>
Web: http://www.linuxquebec.com/~nomis80
PGP: $Web/nomis80.gpg
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Perrin Harkins wrote: > > To answer the original question, I don't think Apache::DBI is much > overhead at all. It amounts to little more than a hash lookup. > Certainly less work than the the thread synchronization required for > connection pooling. > My only problem with Apache::DBI for a benchmark is its default ping of the db per connect(). For a benchmark that is little more that a ping itself, this might not be fair to cause 2 pings. In this light, I might want to just use a global like: $dbh ||= DBI->connect(); I just did a quick test, and these were the results: Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - mod_perl HelloDB MySQL Apache::DBI my_hellod 451.3 9042 20.040.002216 191 16092 mod_perl HelloDB MySQL Global $dbh my_hellod 570.2 11418 20.020.001754 191 15296 My question is is this a fair optimization for a benchmark like this. I tend to not over optimize the benchmarks as a rule, but I spent hours ( & 12 lines of code :) ) writing an overly simple database connection pooling manager for the JSP benchmarks where a standard one seems to be lacking in JDBC & JNDI, so I'm not sure using a mod_perl global instead of Apache::DBI would be skewing things. The PHP test I had to do nothing, connection persistence is enabled by default. Thanks for the feedback & still looking for more! --Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Dennis Haney wrote: >>The bias in the test is even a little slanted towards the JSP >>benchmarks since the trivial connection pooling I used there is >>nothing like the Apache::DBI overhead in the mod_perl test, when I >>could have just used a persistent global $dbh instead. ( maybe I >>should? ) > > > I believe you should. It is the most common setup using mod_perl, if > you are concerned about performance, anyway. I think you got confused by the wording. The most common setup with mod_perl is to use Apache::DBI, which is what he used in the test. To answer the original question, I don't think Apache::DBI is much overhead at all. It amounts to little more than a hash lookup. Certainly less work than the the thread synchronization required for connection pooling. - Perrin
re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
> The bias in the test is even a little slanted towards the JSP
> benchmarks since the trivial connection pooling I used there is
> nothing like the Apache::DBI overhead in the mod_perl test, when I
> could have just used a persistent global $dbh instead. ( maybe I
> should? )
I believe you should. It is the most common setup using mod_perl, if
you are concerned about performance, anyway.
--
Dennis
use Inline C => qq{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
Subject: Re: hiding perl code
>> BZS::License performs a similar load operation to BZS::Loader. First, >> however it looks for a hash pointer in the caller program called >> $ptr2_License. >> The hash contains the path to the License file and an optional >>'private' key >> list of modules which will decrypt only with the 'private' key. B, > I thought that somebody has already said here that you cannot hide your > perl code. if you have an access to the perl interpreter you can dump > the source code after it was decrypted. > > wouldn't it be a good idea to add the truth to the POD so not to mislead > the crowd? I've read through the doc but didn't see a word mentioning > this "little" caveat. > > Shouldn't the module be renamed to BZS::Obscure::...? ;) You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Michael
[ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Hey, The Apache Hello World Benchmarks are updated at: http://chamas.com/bench/ They now include 2 C Apache API benchmarks which show the fastest the benchmarks can run at, and how mod_perl is not much slower! Also included is a new HelloDB benchmark which is a trivial connection/query of a MySQL database. Again, mod_perl should make you proud, beating out the competition. The bias in the test is even a little slanted towards the JSP benchmarks since the trivial connection pooling I used there is nothing like the Apache::DBI overhead in the mod_perl test, when I could have just used a persistent global $dbh instead. ( maybe I should? ) Regards, Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Trouble with RegistryCooker.pm modper2.0
Kent, Mr. John wrote: > Greetings, > > Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per > http://perl.apache.org/docs/2.0/user/install/install.html > > When attempting to run modperl get: > > [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of > uninitialized value in concatenation (.) or string at > /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl > /RegistryCooker.pm line 549. > > This seems to be related to PerlSwitches -T which was in earlier releases > but now is commented out Mea Culpa, please try again the cvs version, should be ok now. __ 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: Apache::Reload - filtering include directories
Harry Danilevsky wrote: > I did send the patch to Matt couple of days ago, but haven't heard back > yet. Matt is on vacation > I suppose I can also brace myslef, add namespaces, and clean up my own > code. That's a good idea. > As for the versioning, if this patch could be useful in both mod_perl > 1.* and 2.0, > can it be applied to both distributions? I don't quite understand why > installing > Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll > try to think some more about it. Because Apache::Reload is distributed on CPAN and is not a part of mod_perl 1.0. And a genetically modified version is included in mod_perl 2.0. The right solution is probably to make Apache::Reload a part of mod_perl 1.0 as well and kill the CPAN version, or simply have a higher number on it. So people won't need to install it manually. __ 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
Trouble with RegistryCooker.pm modper2.0
Greetings, Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per http://perl.apache.org/docs/2.0/user/install/install.html When attempting to run modperl get: [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of uninitialized value in concatenation (.) or string at /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl /RegistryCooker.pm line 549. This seems to be related to PerlSwitches -T which was in earlier releases but now is commented out Thanks, John Kent
Re: Apache::Reload - filtering include directories
I did send the patch to Matt couple of days ago, but haven't heard back yet. I suppose I can also brace myslef, add namespaces, and clean up my own code. As for the versioning, if this patch could be useful in both mod_perl 1.* and 2.0, can it be applied to both distributions? I don't quite understand why installing Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll try to think some more about it. Stas Bekman wrote: > Harry Danilevsky wrote: > >> I certainly agree with attaching a common prefix to a library, but >> what if I am already dealing >> with a bunch of modules written without prefix, and enough >> application code using those packages ? >> I suppose I could change the code, or alias names in symbol table, or >> do some other trick; >> I just figured that one extra directive, plus one patched line was a >> cheap solution to my >> problems. >> >> I guess if nobody else sees any value in it, I'll just keep the >> private patched version for myself :-) > > > No, no, I was asking whether you can re-use the existing options > without adding new ones. Nobody has asked for this feature since the > package was created. It certainly has a value. e.g. you may want to > watch only Apache:: packages from a certain private directory. > > I guess you should send the patch to Matt and I'll sync the version in > mod_perl 2.0 (CC me). Though we need to figure out how to resolve the > versioning conflict. so when you ask for Apache::Reload from CPAN.pm, > it won't install mod_perl 2.0. Ideas? >
Re: Apache::Reload - filtering include directories
Harry Danilevsky wrote: > I certainly agree with attaching a common prefix to a library, but what > if I am already dealing > with a bunch of modules written without prefix, and enough application > code using those packages ? > I suppose I could change the code, or alias names in symbol table, or do > some other trick; > I just figured that one extra directive, plus one patched line was a > cheap solution to my > problems. > > I guess if nobody else sees any value in it, I'll just keep the private > patched version for myself :-) No, no, I was asking whether you can re-use the existing options without adding new ones. Nobody has asked for this feature since the package was created. It certainly has a value. e.g. you may want to watch only Apache:: packages from a certain private directory. I guess you should send the patch to Matt and I'll sync the version in mod_perl 2.0 (CC me). Though we need to figure out how to resolve the versioning conflict. so when you ask for Apache::Reload from CPAN.pm, it won't install mod_perl 2.0. Ideas? > Stas Bekman wrote: > >> Harry Danilevsky wrote: >> >>> Two reasons : >>> >>> 1. My site-specific modules don't necessarily have a common >>> namespace (or even several namespaces); >>> they just all live in /site/lib. Without a ReloadDirectories-like >>> filter every time I add another module, >>> say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, >>> and restart the server. >> >> >> >> That's the thing. It's a good idea to alway use some prefix package >> name in all your modules, to avoid future clashes with other modules. >> And it automatically solves your problem with Apache::Reload. >> >>> 2. Much more obscure, related to HTML::Mason. As I mentioned in my >>> post: >>> >>> In Mason components are precompiled and cached, so that perl code >>> doesn't have to be re-parsed for every request. >>> The cached files are require(d), and they end up in %INC. >>> It appears from ReloadDebug's output that those cached files are >>> being checked by Apache::Reload, >>> and if they have been modified - they'll be reloaded. The problem is, >>> if the code has a syntax >>> error, that error will occur when Apache::Reload re-require()s that >>> file, and the error message >>> will be printed to a log file, not to the browser - which is what >>> Mason would do. >>> So your browser will simply tell you that 'Internal error has occurred' >>> ReloadDirectories will simply ignore them, and let Mason deal with >>> modified files. >> >> >> >> If you tell Apache::Reload to look only at certain namespaces, this >> problem doesn't exist anymore. >> >>> Am I still missing something ? >>> >>> >>> Harry Danilevsky >>> [EMAIL PROTECTED] >>> >>> Stas Bekman wrote: >>> [...] > Anyway, I decided to add another directive to Apache::Reload > > PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf" Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules "Apache::* My::*" Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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 >>> >>> >>> >>> >>> >> >> >> > -- __ 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: Apache::Reload - filtering include directories
I certainly agree with attaching a common prefix to a library, but what if I am already dealing with a bunch of modules written without prefix, and enough application code using those packages ? I suppose I could change the code, or alias names in symbol table, or do some other trick; I just figured that one extra directive, plus one patched line was a cheap solution to my problems. I guess if nobody else sees any value in it, I'll just keep the private patched version for myself :-) Stas Bekman wrote: > Harry Danilevsky wrote: > >> Two reasons : >> >> 1. My site-specific modules don't necessarily have a common >> namespace (or even several namespaces); >> they just all live in /site/lib. Without a ReloadDirectories-like >> filter every time I add another module, >> say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, >> and restart the server. > > > That's the thing. It's a good idea to alway use some prefix package > name in all your modules, to avoid future clashes with other modules. > And it automatically solves your problem with Apache::Reload. > >> 2. Much more obscure, related to HTML::Mason. As I mentioned in my >> post: >> >> In Mason components are precompiled and cached, so that perl code >> doesn't have to be re-parsed for every request. >> The cached files are require(d), and they end up in %INC. >> It appears from ReloadDebug's output that those cached files are >> being checked by Apache::Reload, >> and if they have been modified - they'll be reloaded. The problem is, >> if the code has a syntax >> error, that error will occur when Apache::Reload re-require()s that >> file, and the error message >> will be printed to a log file, not to the browser - which is what >> Mason would do. >> So your browser will simply tell you that 'Internal error has occurred' >> ReloadDirectories will simply ignore them, and let Mason deal with >> modified files. > > > If you tell Apache::Reload to look only at certain namespaces, this > problem doesn't exist anymore. > >> Am I still missing something ? >> >> >> Harry Danilevsky >> [EMAIL PROTECTED] >> >> Stas Bekman wrote: >> >>> [...] >>> Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf" >>> >>> >>> >>> >>> Apache::Reload allows you to define which modules to reload using >>> the patterns like so: >>> >>> PerlSetVar ReloadAll Off >>> PerlSetVar ReloadModules "Apache::* My::*" >>> >>> Is there any reason why you cannot use this approach? >>> >>> I've no objection to your proposal, just wondering whether the >>> existing features can be used instead. >>> >>> __ >>> 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: I can see Apache.pm, why can't he?
Dennis Daupert wrote: > What's up with this? I'm trying to load Apache::DBI on startup. > > I have apache and mod_perl installed, and running ok, > and have installed additional modules, including the > Apache::Bundle. > > When I put the line in mod_perl.conf, > > PerlModule Apache::DBI > > I can't start the web server. Dennis: Doctor, I think my server is sick, it cannot start Doctor: Does it have a high temperature? http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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: Apache::Reload - filtering include directories
Harry Danilevsky wrote: > Two reasons : > > 1. My site-specific modules don't necessarily have a common namespace > (or even several namespaces); > they just all live in /site/lib. Without a ReloadDirectories-like filter > every time I add another module, > say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and > restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. > 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: > > In Mason components are precompiled and cached, so that perl code > doesn't have to be re-parsed for every request. > The cached files are require(d), and they end up in %INC. > It appears from ReloadDebug's output that those cached files are being > checked by Apache::Reload, > and if they have been modified - they'll be reloaded. The problem is, if > the code has a syntax > error, that error will occur when Apache::Reload re-require()s that > file, and the error message > will be printed to a log file, not to the browser - which is what Mason > would do. > So your browser will simply tell you that 'Internal error has occurred' > ReloadDirectories will simply ignore them, and let Mason deal with > modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. > Am I still missing something ? > > > Harry Danilevsky > [EMAIL PROTECTED] > > Stas Bekman wrote: > >> [...] >> >>> Anyway, I decided to add another directive to Apache::Reload >>> >>> PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf" >> >> >> >> Apache::Reload allows you to define which modules to reload using the >> patterns like so: >> >> PerlSetVar ReloadAll Off >> PerlSetVar ReloadModules "Apache::* My::*" >> >> Is there any reason why you cannot use this approach? >> >> I've no objection to your proposal, just wondering whether the >> existing features can be used instead. >> >> __ >> 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 > > > -- __ 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: apache/mod_perl help
Dinesh Patel wrote: > I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for > apache-2.0.39. > > version 1.27 of mod_perl was compiled using : > > CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ > DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 > > make > > The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS > enabled! It's too early to upgrade to mod_perl 2.0. Not all features are implemented (which is the case with sections). For more info see: http://perl.apache.org/docs/2.0/user/index.html > I have compiled the new version of mod_perl without the PERL values, > > The httpd.conf was edited to include : > # mod_perl stuff > Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSetupEnv On > Options ExecCGI > > PerlWarn On > PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl > > however when i try and start the apache server i get the error : > > Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: > Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not >included in the server configuration > > > > Any help would be appreciated > > Regards > > Dinesh Patel -- __ 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: Apache2 CWD Non-threaded MPM
Joshua Bernstein wrote: > Hey All, > > After much hassle, I blew away my threaded MPM under Apache2 because > mod_perl didn't seem to be accepting or processing the . (period) in my > @INC path so that scripts called like: > > require "blah.cgi" > > were not being found in the include path. I understand there are still > issues with SafeCWD'ing in a threading enviroment, but now that the MPM > is prefork, it isn't threaded anymore. Any reason why mod_perl 2, still > doesn't recognize the . in my @INC path? You are talking about ModPerl::Registry, not mod_perl 2.0 in general. ModPerl::Registry will always do the same thing, be it the prefork mpm or the threaded mpm. Because the same code should run identically no matter what the mpm is used. Therefore if chdir() cannot be used with the threaded mpm it won't work with the prefork mpm as well. Solution 1: Subclass ModPerl::Registry as ModPerl::RegistryPreFork and do whatever is fine with prefork. Subclassing the new registry family is extremely easy, though the API hasn't been frozen yet. See ModPerl::RegistryCooker for more info. Solution 2: Arthur Bergman is working on ex::threads::safecwd, which should resolve the problem for threaded mpms. So once it's available we can use chdir() in ModPerl::Registry again. __ 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: apache mod_perl + suid question
Thanks a lot. That "really" does help. regards, -Tushar -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 6:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: apache mod_perl + suid question [EMAIL PROTECTED] wrote: > Hello, > > I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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: Apache::Reload - filtering include directories
Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: > [...] > >> Anyway, I decided to add another directive to Apache::Reload >> >> PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf" > > > Apache::Reload allows you to define which modules to reload using the > patterns like so: > > PerlSetVar ReloadAll Off > PerlSetVar ReloadModules "Apache::* My::*" > > Is there any reason why you cannot use this approach? > > I've no objection to your proposal, just wondering whether the > existing features can be used instead. > > __ > 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
RES: Segmentation fault
Hello Stas, I will look for those information. Anyway, it does not works under pure mod_perl too. Regards, Vitor -Mensagem original- De: Stas Bekman [mailto:[EMAIL PROTECTED]] Enviada em: terca-feira, 30 de julho de 2002 06:04 Para: Vitor Cc: [EMAIL PROTECTED] Assunto: Re: Segmentation fault Vitor wrote: > Hello Folks, > > I am having a big problem here. > > While i try to open a new Mail::CClient connection, i get these message : > > [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation > fault (11) > > I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without > shared libraries, and HTML::Mason templating system. > > I don't know if is a callback problem, because to login, Mail::CClient uses > a login callback. > > It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ 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
Apache::Status patch, in diff -u format (finally ;)
Index: Status.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
diff -u -r1.26 Status.pm
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 30 Jul 2002 12:39:07 -
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r->path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
my $type = "dot";
my $file = "$dir/$thing.$$.gif";
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
apache/mod_perl help
I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel
Re: apache mod_perl + suid question
[EMAIL PROTECTED] wrote: > Hello, > > I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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: hiding perl code
Michael Robinton wrote: > see attached [...] > BZS::License performs a similar load operation to BZS::Loader. First, > however it looks for a hash pointer in the caller program called $ptr2_License. > The hash contains the path to the License file and an optional 'private' key > list of modules which will decrypt only with the 'private' key. B, a I thought that somebody has already said here that you cannot hide your perl code. if you have an access to the perl interpreter you can dump the source code after it was decrypted. wouldn't it be a good idea to add the truth to the POD so not to mislead the crowd? I've read through the doc but didn't see a word mentioning this "little" caveat. Shouldn't the module be renamed to BZS::Obscure::...? ;) __ 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: Re: Problems using Perl v 5.8
Hi, thanks for your help. Now everything works fine using mod_perl 1.27. :) Lino .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -Messaggio originale- Da: Stas Bekman [mailto:[EMAIL PROTECTED]] Inviato: martedi 30 luglio 2002 05.21 Cc: Pasquale Pagano; Modperl Oggetto: Re: Problems using Perl v 5.8 [EMAIL PROTECTED] wrote: > > Does it help to update mod_perl to 1.27? and if not, please send to the list the shortest possible script that reproduces the problem. > "Pasquale Pagano" <[EMAIL PROTECTED]> on 07/29/2002 > 12:35:10 PM > > To: "Modperl" <[EMAIL PROTECTED]> > cc:(bcc: Wesley Sheldahl/Lex/Lexmark) > Subject: Problems using Perl v 5.8 > > > Hi, > We have some problems using: > 1) Perl v 5.8 > 2) Mod_Perl v 1.26 > 3) Apache v 1.3.26 > > In particular: > > a) if we use simple CGI, everything works fine; > b) if we use a custom handler for mod_perl, everything works fine; > > but if we try to use our CGI via Apache::Registry or Apache::PerlRun handler > the code is ran correctly but we are able to send back to the browser only > the HTTP header (everything else is missed). > > Here below an example of the http response > > -__- > > HTTP/1.1 200 OK > Date: Mon, 29 Jul 2002 17:20:02 GMT > Server: Apache/1.3.26 (Unix) mod_perl/1.26 > Transfer-Encoding: chunked > Content-Type: text/html; charset=ISO-8859-1 > > 0 > > -__- > > Any of you have some hints?? > > Any help will be welcome, > Regards, > Lino > > > PS: The same code works fine using Perl v 5.7.2. > > > .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > Pasquale Pagano > CNR - Istituto di Elaborazione della Informazione > Via G. Moruzzi, 1 - 56124 Pisa,Italy > Area della Ricerca CNR di Pisa > Tel +39 050 3152891 > E-mail: [EMAIL PROTECTED] > .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > > > > > -- __ 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: PerlSendHeader and $r->header_out
Rafiq Ismail (ADMIN) wrote:
> Hi People With Functioning Brain Cells,
>
> I'm having a brief period of grief, which I'm sure I've been through
> before.
>
> I have this situation where I set a cookie using:
> $r->header_out('Set-Cookie'=>$cookie);
>
> Now this is all fine, however I'm having a major problem in getting my
> header into the right place.
Have you tried using Apache::Cookie or CGI::Cookie? If these work for
you, either stick to them or look at how their work.
__
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: mod_perl with a perl built with -Dusethreads, will it work?
Brian wrote: > I would like to install Sendmail::Milter which needs a perl built with > thread support. Last time I tried to use a perl built with thread > support (5.6.x), mod_perl didn't like it. Is this still the case with > 5.8.0? Is anybody using mod_perl with a perl built with -Dusethreads? > > Thanks, > > Brian > > -- > Linux 2.4.18 > libc 2.1.3 > apache 1.3.26 > mod_perl 1.27 apache cvs mod_perl cvs linux 2.4.18-6mdksmp glibc 2.2.5-10mdk works fine __ 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: T switch is ignored modperl2.0
Kent, Mr. John wrote:
> Greetings,
>
> I have put PerlSwitches -T in my httpd.conf file, yet keep getting the
> following warning
> in the server's error_log:
>
> [Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
> 'PerlSwitches -T' in httpd.conf
>
> Any suggestions?
the cvs version or the next release won't complain anymore. currently -T
on shebang line is simply ignored, but will complain again in the future
when we will have a flag indicating whether the taint mode is on or not.
in perl 5.8.0 it's easy:
% perl5.8.0 -Te 'print ${^TAINT}'
in older Perls one need to parse PerlSwitches to find -T and set some
magic flag (was $Apache::__T in mod_perl 1.0).
__
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
Apache2 CWD Non-threaded MPM
Hey All, After much hassle, I blew away my threaded MPM under Apache2 because mod_perl didn't seem to be accepting or processing the . (period) in my @INC path so that scripts called like: require "blah.cgi" were not being found in the include path. I understand there are still issues with SafeCWD'ing in a threading enviroment, but now that the MPM is prefork, it isn't threaded anymore. Any reason why mod_perl 2, still doesn't recognize the . in my @INC path? -Joshua Bernstein Systems Analyst University of Arizona Tucson, Arizona, USA
Re: Change program name of httpd process
Oleg Shaikhatarov wrote: > Hello, all! > > I need to change proctitle (called $PROGRAM_NAME or $0 in perl) of httpd > process from mod_perl. Simple change of $0 variable works well for > standalone perl program, but don't work under mod_perl. I'm not sure if > it's possible, but if anyone have an idea how to do this please help. please give us some more details. What do you do and what doesn't work. e.g. Apache::Registry sets $0 to the location of the currently processed script. Why cannot you do the same? __ 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: Apache::Status bugfix ( "::" doesn't play well in filenames)
thanks, but how about sending a patch using diff?
http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
> sub noh_b_graph {
> my $r = shift;
> require B::Graph;
>
> untie *STDOUT;
>
> my $dir = $r->server_root_relative(
>$r->dir_config("GraphDir") || "logs/b_graphs");
>
> mkdir $dir, 0755 unless -d $dir;
>
> (my $thing = $r->path_info) =~ s:^/::;
> $thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
>
> ## the line above you should add
> ## the line before it is # 516
>
> __
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
--
__
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: multiple definitions of symbol __dig_vec
m31 wrote: > I'm running mod_perl/1.25 with perl/5.6.1, I also have the php module > 4.1.2 installed too. They were both compiled as a dso with apxs. When I > try to connect to mysql with DBI->connect via mod_perl I get the > following errors: > > dyld: /usr/sbin/httpd multiple definitions of symbol __dig_vec > /usr/libexec/httpd/libphp4-4.1.2.so definition of __dig_vec > /Library/Perl/darwin/auto/DBD/mysql/mysql.bundle definition of __dig_vec > > Has any-one else had similar problems?? a wild guess: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#_exit_signal_Segmentation_fault__11___with_mysql -- __ 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: Segmentation fault
Vitor wrote: > Hello Folks, > > I am having a big problem here. > > While i try to open a new Mail::CClient connection, i get these message : > > [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation > fault (11) > > I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without > shared libraries, and HTML::Mason templating system. > > I don't know if is a callback problem, because to login, Mail::CClient uses > a login callback. > > It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ 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: Apache::Reload - filtering include directories
[...] > Anyway, I decided to add another directive to Apache::Reload > > PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf" Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules "Apache::* My::*" Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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: Win32: Apache2+modperl2 STDERR not going to error.log?
Alessandro Forghieri wrote: > Greetings. > > I am using the binary distribution "Apache/2.0.40-dev (Win32) > mod_perl/1.99_05-dev Perl/v5.8.0" from uwinnipeg. OS is NTsp6 > > httpd.conf is basically unmodified. > > I have noticed that carp'ing or warn'ing or even printing to stderr from a > Registry script does not send anything to error.log. The same from CGI does > produce the expected log records - verified on printenv. > > Also I am under the impression that the same does *NOT* happen on Win2K, but > I cannot confirm it right now. > > Is this a known issue with this version, a by-design thing, or is it just > me? FWIW, there are no problems on linux. Do you have the same problem with v5.6.1? Meanwhile try using the logging methods if possible: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.html __ 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: Mention LoadFile in the mp2 docs?
Alessandro Forghieri wrote: > Greetings. > > From: > http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl > > [...] > Win32 users need to make sure that the path to the Perl binary (e.g., > C:\Perl\bin) is in the PATH environment variable. > [...] > > Is it not true that the directive LoadFile "C:\foo\perl58.dll" makes path > modifications unnecessary? I guess the generic doc should simply redirect win32 users to http://perl.apache.org/docs/2.0/os/win32/config.html and not bother providing incomplete info. But I don't see that doc mentioning this issue. Randy? > If so, it should perhaps be mentioned here. (With caveats, as situations > where Registry scripts are handled by one - LoadFil-ed - perl version and > CGI scriptse by another one - or not at all - would probably be > confusing...). > > Cheers, > alf -- __ 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: section: under - whats wrong here?
[EMAIL PROTECTED] wrote:
> Hi,
>
> In a regular Apache configuration style, this works for me:
>
>
>
> PerlSetEnv PERL5LIB /opt/capmon/inc:/usr/local/httpd/htdocs/capmon/cgi
> PerlSendHeader On
> SetHandler perl-script
> PerlHandler Apache::Registry
>
>
>
> Now why doesn't this work in a section, :
>
> $Directory = {
> '/usr/local/httpd/htdocs/capmon/' => {
> 'Files' => {
> '_*.mod' => {
> 'PerlHandler' => 'Apache::Registry',
> 'PerlSendHeader' => 'On',
> 'PerlSetEnv' => [
> 'PERL5LIB',
> '/opt/capmon/inc:/usr/local/httpd/htdocs/capmon/cgi'
> ],
> 'SetHandler' => 'perl-script'
> }
> }
> }
> };
>
> It gives no errors, but just doesn't treat it as CGI. As far as I can see,
> it is *exactly* equivalent to the section at the top, isn't it?
>
> In a section, this works *does* work:
>
> $Files = {
> '_*.mod' => {
> 'PerlHandler' => 'Apache::Registry',
> 'PerlSendHeader' => 'On',
> 'PerlSetEnv' => [
> 'PERL5LIB',
> '/opt/capmon/inc:/usr/local/httpd/htdocs/capmon/cgi'
> ],
> 'SetHandler' => 'perl-script'
> }
> };
>
> But it isn't limited to the /usr/local/httpd/htdocs/capmon/ directory.
>
> How do I restrict it to a particular directory?
>
> I've read the
> http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl
>
> section
> and
> http://modperl.com:9000/book/chapters/ch8.html#Configuring_Apache_with_Perl
> and especially from the last reference, I've tried to follow the "Directive
> is a Nested Block " section exactly. Are there any other pointers?
Peter, there are two problems:
1. you misread the usage explanations
It cannot be:
$Directory = { }
it must be:
%Directory = ().
Reread
http://modperl.com:9000/book/chapters/ch8.html#Configuring_Apache_with_Perl
again for the explanation. It seems that you've snipped the part from
the virtual host examples but didn't set the right type for Directory.
2. It seems that there is a bug in the code that handles the Files
sections when they are nested inside another section. I'll post a
separate report regarding this to the dev list.
here is a workaround that should solve your problem:
$Directory{'/usr/local/httpd/htdocs/capmon/'} = {
FilesMatch => {
'\.pl$' => {
'Options'=> '+ExecCGI',
'SetHandler' => 'perl-script',
'PerlSendHeader' => 'On',
'PerlHandler'=> 'Apache::Registry'
},
},
};
add 'PERL5LIB' etc...
> P.S: When you subscribe to this mailing list, or when you look for the FAQ
> on Google, you are pointed towards:
> http://perl.apache.org/faq/
> But this is a 404...
This doc has been dissolved into various docs, spread across various
dirs, so it's impossible to add a rewrite rule. Hence the 404. I'll fix
the mailing list doc to reflect the reality. Thanks for the report.
Hopefully Google will catch up with the changes on the site soon.
__
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
