Re: bug in mod_perl-1.24 & request->args & request->content
On Mon, 22 Jan 2001, Marc Lehmann wrote:
> Apache.pm documents two methods "args" and "content" that should return
> argument => value pairs (when called appropriately). In fact, args is
> implemented as:
>
> return map { Apache::unescape_url_info($_) } split /[=&;]/, $string, -1;
>
> However, this might return an odd number of values, for example for this url:
>
> httpurl?arg1&arg2=val2
>
> I get (arg1 => "arg2", val2), which is not as documented.
>
> This url format is often used for boolean arguments (CGI.pm creates an
> arg1 => "", while I would prefer arg1 => undef in this case).
>
> So either the documentation or the implementation is in error. I would
> prefer if the implementation were in error ;)
the real error was putting args in-a-scalar-context and the content method
in Apache.pm to begin with. i pointed that out last time this came up and
just punted. the patch below should fix, but the taint test fails with
5.6.0, not sure if its something that 5.6.1-trial1 will fix or not.
probably will wait until after 1.25 to revisit this.
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.61
diff -u -r1.61 Apache.pm
--- Apache/Apache.pm2001/01/25 08:10:16 1.61
+++ Apache/Apache.pm2001/01/26 06:05:52
@@ -38,7 +38,15 @@
my($wantarray,$string) = @_;
return unless defined $string and $string;
if(defined $wantarray and $wantarray) {
- return map { Apache::unescape_url_info($_) } split /[=&;]/, $string, -1;
+my @args;
+local $_;
+for my $pair (split /[&;]/, $string) {
+my($key,$val) = split '=', $pair, 2;
+for ($key, $val) {
+push @args, defined $_ ? Apache::unescape_url_info($_) : undef;
+}
+}
+return @args;
}
$string;
}
Index: t/net/perl/taint.pl
===
RCS file: /home/cvs/modperl/t/net/perl/taint.pl,v
retrieving revision 1.3
diff -u -r1.3 taint.pl
--- t/net/perl/taint.pl 1999/08/04 03:43:00 1.3
+++ t/net/perl/taint.pl 2001/01/26 06:05:53
@@ -18,7 +18,7 @@
my $tests = {
args => sub {
- eval { system $r->args };
+ eval { system scalar $r->args };
die "TaintCheck failed, I can `system \$r->args'" unless $@;
#warn "TRAPPED: `system \$r->args' '$@'\n";
},
bug in mod_perl-1.24 & request->args & request->content
Apache.pm documents two methods "args" and "content" that should return
argument => value pairs (when called appropriately). In fact, args is
implemented as:
return map { Apache::unescape_url_info($_) } split /[=&;]/, $string, -1;
However, this might return an odd number of values, for example for this url:
httpurl?arg1&arg2=val2
I get (arg1 => "arg2", val2), which is not as documented.
This url format is often used for boolean arguments (CGI.pm creates an
arg1 => "", while I would prefer arg1 => undef in this case).
So either the documentation or the implementation is in error. I would
prefer if the implementation were in error ;)
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: possible bug in mod_perl 1.24_01
On Wed, 18 Oct 2000, Michael J Schout wrote:
> I have had an application working under apache 1.3.12/mod_perl 1.24 for several
> months now with no problems.
>
> I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since
> mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then
> try to start apache, it goes into an infinite loop proocessing sections.
thanks for the debugging (and patience), try this patch just applied to
cvs..
prevent $PerlRequire in a section from triggering an endless loop
[Salvador Ortiz Garcia <[EMAIL PROTECTED]>]
Index: src/modules/perl/mod_perl.h
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.h,v
retrieving revision 1.105
retrieving revision 1.106
diff -u -r1.105 -r1.106
--- src/modules/perl/mod_perl.h 2000/10/03 18:19:14 1.105
+++ src/modules/perl/mod_perl.h 2000/12/20 07:24:43 1.106
@@ -491,9 +491,10 @@
#ifdef PERL_SECTIONS
# ifndef PERL_SECTIONS_SELF_BOOT
# ifdef WIN32
-# define PERL_SECTIONS_SELF_BOOT getenv("PERL_SECTIONS_SELF_BOOT")
+# define PERL_SECTIONS_SELF_BOOT \
+ (getenv("PERL_SECTIONS_SELF_BOOT") && !perl_sections_self_boot)
# else
-# define PERL_SECTIONS_SELF_BOOT 1
+# define PERL_SECTIONS_SELF_BOOT !perl_sections_self_boot
# endif
# endif
#endif
RE: possible bug in mod_perl 1.24_01
> -Original Message- > From: Michael J Schout [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 18, 2000 2:54 PM > To: [EMAIL PROTECTED] > Subject: Re: possible bug in mod_perl 1.24_01 > > > I should also have mentioned: > > I am using perl 5.6.0, Linux 2.2.x I have the same config and don't have any problems... however, from the debug output, it looks to me like it is the Include directive that is mucking things up... `@Include' directive is TAKE1, (1 elements) default: iterating over @Include handle_command (Include "/nis.home/mschout/dev/gkgdrs/gkgnsi/conf/httpd.conf"): loading perl module 'Apache'...ok `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: ...etc are any of your configuration files a directory? 1.3.14 will now recurse through any config files that are directories and process all the files within... maybe that is going awry somehow? I suppose my suggestion might be to start stripping down your config file to something basic and add stuff until the looping starts - not much help, I know, but... --Geoff > > I used the same perl / os for both apache1.3.12/mod_perl > 1.24, and apache > 1.3.14/mod_perl 1.24_01. > > Mike >
Re: possible bug in mod_perl 1.24_01
I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
possible bug in mod_perl 1.24_01
I have had an application working under apache 1.3.12/mod_perl 1.24 for several months now with no problems. I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then try to start apache, it goes into an infinite loop proocessing sections. The stack trace from gdb looks like this: #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 1736vfprintf.c: No such file or directory. (gdb) bt #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 #1 0x40105966 in _IO_vfprintf (s=0x401aea20, format=0x8119d18 "loading perl module '%s'...", ap=0xbf801910) at vfprintf.c:1029 #2 0x4010e027 in fprintf (stream=0x401aea20, format=0x8119d18 "loading perl module '%s'...") at fprintf.c:32 #3 0x806d0c0 in perl_require_module () #4 0x806b40c in perl_section () #5 0x806b231 in perl_section_self_boot () #6 0x8068d8e in perl_cmd_require () #7 0x8081f29 in invoke_cmd () #8 0x80822ac in ap_handle_command () #9 0x806acb7 in perl_handle_command () #10 0x806b826 in perl_section () #11 0x806b231 in perl_section_self_boot () #12 0x8068d8e in perl_cmd_require () #13 0x8081f29 in invoke_cmd () #14 0x80822ac in ap_handle_command () #15 0x806acb7 in perl_handle_command () #16 0x806b826 in perl_section () #17 0x806b231 in perl_section_self_boot () #18 0x8068d8e in perl_cmd_require () #19 0x8081f29 in invoke_cmd () #20 0x80822ac in ap_handle_command () #5889 0x806acb7 in perl_handle_command () #5890 0x806b826 in perl_section () #5891 0x806b231 in perl_section_self_boot () #5892 0x8068c6c in perl_cmd_module () #5893 0x8081f29 in invoke_cmd () #5894 0x80822ac in ap_handle_command () #5895 0x80822f8 in ap_srm_command_loop () #5896 0x80827ed in ap_process_resource_config () #5897 0x8085f28 in include_config () #5898 0x808206c in invoke_cmd () #5899 0x80822ac in ap_handle_command () #5900 0x806acb7 in perl_handle_command () #5901 0x806b043 in perl_handle_command_av () #5902 0x806b9d8 in perl_section () #5903 0x808206c in invoke_cmd () #5904 0x80822ac in ap_handle_command () #5905 0x80822f8 in ap_srm_command_loop () #5906 0x80827ed in ap_process_resource_config () #5907 0x8082e74 in ap_read_config () #5908 0x808a745 in main () #5909 0x400d89cb in __libc_start_main (main=0x808a560 , argc=4, argv=0xb914, init=0x8062524 <_init>, fini=0x811741c <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:92 And when I run with "MOD_PERL_TRACE=all" I get a whole bunch of output. It starts out like this: perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok SVt_PV: $Group = `mschout' handle_command (Group mschout): OK SVt_PV: $ServerAdmin = `[EMAIL PROTECTED]' handle_command (ServerAdmin [EMAIL PROTECTED]): OK perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: SVt_PV: $ServerRoot = `/nis.home/mschout/httpd' handle_command (ServerRoot /nis.home/mschout/httpd): OK SVt_PV: $User = `mschout' handle_command (User mschout): OK perl_section: loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok PORTS CONFIGURATION HTTP : 8531 HTTPS: 4531 `@Listen' directive is TAKE1, (2 elements) default: iterating over @Listen handle_command (Listen 8531): OK handle_command (Listen "4531"): OK perl_section: perl_section: SSLVerifyDepth 10 (OK) Limit=no SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key (OK) Limit=no SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt (OK) Limit=no SSLVerifyClient none (OK) Limit=no SSLEngine on (OK) Limit=no handle_command (SetEnvIf "User-Agent" ".*MSIE.*" "nokeepalive" "ssl-unclean-shutdown"): OK perl_section: perl_section: perl_section: perl_section: SVt_PV: $Port = `8531' handle_command (Port 8531): OK perl_section: perl_section: loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok SVt_PV: $DAVLockDB = `/var/tmp/DAVLock.mschout' handle_command (DAVLockDB /var/tmp/DAVLock.mschout): OK `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: SVt_PV: $DAVMinTimeout = `600' handle_command (DAVMinTimeout 600): OK loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: perl_section: perl_section: perl_section: AllowOverride None (OK) Limit=no DAV On (OK) Limit=no Options Indexes (OK) Limit=no perl_section: perl_section: perl_section: `
Re: Bug in mod_perl
On Mon, 9 Oct 2000, Dave Rolsky wrote: > I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive > no output after the \0. Is this a mod_perl or Apache bug? Or is it a > client bug (using Netscape 4.75) or is it the expected behavior. looks ok to me: % telnet localhost 8529 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. GET /foo http/1.0 HTTP/1.1 200 OK Date: Fri, 13 Oct 2000 17:35:52 GMT Server: Apache/1.3.15-dev (Unix) mod_perl/1.24_02-dev Perl/v5.7.0 Connection: close Content-Type: text/plain abc abcdef def Connection closed by foreign host. strace shows the \0 coming across: 5406 read(4, "HTTP/1.1 200 OK\r\nDate: Fri, 13 Oct 2000 17:38:47 GMT\r\nServer: Apache/1.3.15-dev (Unix) mod_perl/1.24_02-dev Perl/v5.7.0\r\nConnection: close\r\nContent-Type: text/plain\r\n\r\nabc\nabc\0def\ndef\n", 4096) = 184
Re: Bug in mod_perl
[EMAIL PROTECTED] (Greg Williams) wrote: >>I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive >>no output after the \0. Is this a mod_perl or Apache bug? Or is it a >>client bug (using Netscape 4.75) or is it the expected behavior. > >It would be expected, I'd assume. perl5-porters discussed this back >in January when phrack ran an article claiming it was a 'bug' with >security implications. To summarize, this isn't really bug, but >merely what you'd expect when the PV gets passed to a C function >which expects a NULL terminated string. > >http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html I think I disagree with not calling this a bug. The entire p5p discussion was about the fact that *system calls* will see \0 as the end-of-string character, which in some cases is kind of a bad thing. However, Dave's code is just trying to send some *data* to the browser. It appears that $r->print (or somewhere down in the Apache code) can't handle embedded nulls, which I think should be either documented or fixed. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Bug in mod_perl
>I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive >no output after the \0. Is this a mod_perl or Apache bug? Or is it a >client bug (using Netscape 4.75) or is it the expected behavior. It would be expected, I'd assume. perl5-porters discussed this back in January when phrack ran an article claiming it was a 'bug' with security implications. To summarize, this isn't really bug, but merely what you'd expect when the PV gets passed to a C function which expects a NULL terminated string. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html .g -- - Crack RC5-64 with Bovine: http://www.distributed.net/rc5/ - #!/bin/perl -sp0777i
Re: Bug in mod_perl
Interesting, the Mason bug report I just filed is obviously mis-filed.
Apache::Registry scripts suffer the same behaviour.
On Mon, 9 Oct 2000, Dave Rolsky wrote:
> Try the following handler:
>
> package Foo;
>
> use Apache::Request;
>
> sub handler
> {
> my $r = shift;
>
> my (@vars) = ( 'abc', "abc\0def", "def" );
>
> $r->send_http_header;
> $r->print("$_\n") foreach @vars;
> }
>
>
> 1;
>
>
> I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive
> no output after the \0. Is this a mod_perl or Apache bug? Or is it a
> client bug (using Netscape 4.75) or is it the expected behavior.
>
> -dave
>
> /*==
> www.urth.org
> We await the New Sun
> ==*/
>
--
[EMAIL PROTECTED] | Drive thy business, or it will drive thee.
http://BareMetal.com/ | - Benjamin Franklin
web hosting since '95 |
Bug in mod_perl
Try the following handler:
package Foo;
use Apache::Request;
sub handler
{
my $r = shift;
my (@vars) = ( 'abc', "abc\0def", "def" );
$r->send_http_header;
$r->print("$_\n") foreach @vars;
}
1;
I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive
no output after the \0. Is this a mod_perl or Apache bug? Or is it a
client bug (using Netscape 4.75) or is it the expected behavior.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Bug? in mod_perl when POST request yields REDIRECT
take 2 on that patch, this one adds a check so ap_setup_client_block() is
only called once. with this part of the fix you can call $r->content
multiple times without hanging:
my $data = $r->content;
$data = $r->content;
however, any calls to $r->content after the first will return undef.
(unless you happen to subclass and override the content method to cache
the read data somewhere)
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:38:34
@@ -954,22 +954,27 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
-if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
- aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r->server,
- "mod_perl: setup_client_block failed: %d", rc);
- XSRETURN_UNDEF;
+if (!r->read_length) {
+if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
+aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r->server,
+"mod_perl: setup_client_block failed: %d", rc);
+XSRETURN_UNDEF;
+}
}
+old_read_length = r->read_length;
+r->read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r->read_length = 0;
-}
+}
+r->read_length += old_read_length;
if (nrd > 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: Bug? in mod_perl when POST request yields REDIRECT
On Wed, 6 Sep 2000, Reif Peter wrote:
> I am using a self written mod_perl module that does proxy requests. It acts
> as content handler and fetches the requestet documents via LWP::UserAgent.
> The program works fine but when the request is a POST request and the
> response is a redirection (301, 302, ...) with a Location: header, no data
> is sent to the browser.
>
> If I don't read the postet data, everything works. So my suspicion is the
> following:
> For any reason, if the module returns a redirecting result code (301, 302,
> ...), mod_perl tries to read again the posted data and waits forever.
>
> My solution is simple: Just set the Content-lengt: header to undef:
>
> $r->header_in('Content-length' => undef);
>
> Is this a bug or a feature?
it's a known issue, from the ToDo:
"- should $r->content unset $r->headers_in('content-length') ?
NOTE: im worried this could break apps who need to know content-length
after data has been read"
looking at mod_perl Changes:
=item 1.00b2 - 07/07/97
...
make compatible with 1.2.1 r->read_length change so we don't hang
on file uploads
the problem is that a drastic api change in Apache was made around that
time, which we had to fit into Perl's api. ap_setup_client_block() and
ap_should_client_block() are only supposed to be called once according to
the api spec. Apache.xs calls them everytime $r->read is called, and the
change above was setting r->read_length = 0; so ap_setup_client_block()
would return true the second time it is called. when a redirect or error
is thrown, ap_discard_request_body() also checks ap_should_client_block()
which returns true because we've set r->read_length = 0;
so, i think a reasonable fix for now is to localize the r->read_length
change with this patch:
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:19:20
@@ -954,7 +954,7 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
@@ -964,12 +964,15 @@
XSRETURN_UNDEF;
}
+old_read_length = r->read_length;
+r->read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r->read_length = 0;
-}
+}
+r->read_length += old_read_length;
if (nrd > 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Bug? in mod_perl when POST request yields REDIRECT
I am using a self written mod_perl module that does proxy requests. It acts
as content handler and fetches the requestet documents via LWP::UserAgent.
The program works fine but when the request is a POST request and the
response is a redirection (301, 302, ...) with a Location: header, no data
is sent to the browser.
If I don't read the postet data, everything works. So my suspicion is the
following:
For any reason, if the module returns a redirecting result code (301, 302,
...), mod_perl tries to read again the posted data and waits forever.
My solution is simple: Just set the Content-lengt: header to undef:
$r->header_in('Content-length' => undef);
Is this a bug or a feature?
I include my module and the part of my server config.
Peter
Server config:
==
SetHandler perl-script
PerlHandler Apache::Proxy_test
Proxy_test.pm:
==
package Apache::Proxy_test;
use strict;
use Apache::Constants qw(:response :methods :http);
use Apache::File ();
use Apache::Log ();
use Apache::ModuleConfig ();
use Apache::Table;
use Apache::URI ();
use LWP::UserAgent ();
my $UA = LWP::UserAgent->new;
sub handler {
my $r = shift;
my $not_modified = $r->meets_conditions == HTTP_NOT_MODIFIED;
#
# create request
#
my $filename = $r->filename();
$filename =~ s/^proxy://;
my $parsed_uri = $r->parsed_uri;
my $query = $parsed_uri->query;
$filename .= "?$query" if $query;
$r->log->debug ("filename: $filename");
my $request = HTTP::Request->new($r->method, $filename);
$UA->agent ($r->header_in ('User-Agent'));
# copy POST data, if any
if($r->method eq 'POST') {
my $len = $r->header_in('Content-length');
my $buf;
my $ret = read(STDIN, $buf, $len);
$request->content($buf);
# next line prevents bug !!!
$r->header_in('Content-length' => undef);
}
$r->log->debug ("subrequest:\n\n", $request->as_string);
#
# evaluate response
#
my $response = $UA->simple_request($request);
if ($response->code != 200) {
$r->log->debug ("response not OK:\n\n",
$response->as_string);
$response->scan(sub {
my ($header, $value) = @_;
$r->log->debug ("Header-out: $header $value");
$r->header_out($header, $value);
});
} else {
$r->content_type($response->header('Content-type'));
$r->status($response->code);
$r->status_line(join " ", $response->code,
$response->message);
$r->send_http_header();
unless ($r->header_only) {
print $response->content;
}
}
$r->log->debug("send:\n\n", $r->as_string);
$r->log->debug("return ", $response->code);
return $response->code;
}
1;
__END__
Fwd: apache_1.3.12 / mod_perl-1.22 ... Bug in mod_perl 1.22 on certain platform ?
Hi
Following to my last email, I tried to build apache_1.3.12 with mod_perl-1.21.
And it worked well with the same makepl_args.mod_perl file .
So does that mean that there is a bug in mod_perl-1.22 ? Or That my conf file
had wrong arguments in it, even if I could build it on an other server (see my
other email)?
Fred
-
here is my make makepl_args.mod_perl file :
#example makepl_args.mod_perl files
#copy this file to $ENV{HOME}/.makepl_args.mod_perl and edit to taste
#mod_perl's Makefile.PL will also look for this file in ./ ../ relative
#to the mod_perl-x.xx source tree
#EVERYTHING=1 will enable:
#ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1
#PERL_STACKED_HANDLERS=1 PERL_METHOD_HANDLERS=1 PERL_TABLE_API=1
EVERYTHING=1
#build against the first apache_x.xx source tree found, without prompts
# DO_HTTPD=1
DO_HTTPD=1
#could tell Makfile.PL exactly where the source is
# APACHE_SRC=/tmp/apache_x.xx/src
APACHE_SRC=../apache_1.3.12/src
#this would configure in mod_proxy, mod_unique_id, mod_info and mod_status
# ADD_MODULE=proxy,usertrack,unique_id,info,status
ADD_MODULE=info,status
#if you wish to use a Configuration file other than what's in the
#apache_x.xx/src directory
# CONFIG=Configuration.custom
#depending on your os and site_perl modules, see mod_perl's INSTALL
# PERL_STATIC_EXTS=...
#apache header files are installed by default, stop that if you wish
# APACHE_HEADER_INSTALL=0
#Apache and Apache::Constants modules will be built as shared libraries
# DYNAMIC=1
DYNAMIC=1
USE_APACI=1
APACI_ARGS=--enable-module=so
#turn on mod_perl tracing
# PERL_TRACE=1
#for perl.c's perl_destruct() which in run by mod_perl during child_exit
#comment from perl.c: /* 0=none, 1=full, 2=full with checks */
#default level is 0
# PERL_DESTRUCT_LEVEL=2
#-add `-g' to EXTRA_CFLAGS
#-turn on PERL_TRACE
#-set PERL_DESTRUCT_LEVEL=2
#-link against libperld if -e $Config{archlibexp}/CORE/libperld$Config{lib_ext}
# PERL_DEBUG=1
#
#experimental features, use at own risk
#but please report success or failure if you try
#try to stop "Use of uninitialized value." with no line/filename info
# PERL_MARK_WHERE=1
--
--
| Frédéric Schwien
| Administrateur WebMails.com
| E-mail: [EMAIL PROTECTED] Solutions Internet/Intranet sécurisées"
|http://www.igtech.fr
|Centre de Formation Agréé
|CheckPoint Software
| 153, avenue Jean Lolive
| 93500 Pantin
| Tél: 33 (0) 1 56 96 01 23
| Fax: 33 (0) 1 56 96 01 33
|Votre Email gratuit et sécurisé : http://www.webmails.com
Re: Bug in mod_perl makefile?
On Thu, 3 Feb 2000, Martin A. Langhoff wrote:
> Hi,
>
> I've just got my apache/modperl setup to work. This little nastie
> took me 2 days to find.
>
> In my /usr/src directory, I had:
> - apache_1.3.3 [dir]
> - apache_1.3.9 [dir]
> - mod_perl-1.21 [dir]
>
> and was compiling modperl/perl with:
> #perl Makefile.PL APACHE_SRC=/usr/src/apache_1.3.9 DO_HTTPD=1
> USE_APACI=1 EVERYTHING=1 PERL_MARK_WHERE=1
> APACI_ARGS=--enable-module=all
> #make && make test && make install
>
> and then a make install from apache_1.3.9
>
> This setup was consistently failing, or rather ...
> - if I added --enable-shared=max apache compiled and started
> unless a call to mod_perl was made. If I tryed to load Embperl in
> httpd.conf, httpd would not start, claiming that Apache::Constants was
> not installed/found/whatever.
> - I upgraded perl, recompiled perl + all the perl modules I had
> + mod-perl + apache again. Several recompiles and shrieks.
>
> Now, today, with a fresh head, I noticed a little message when
> making mod_perl, which said it was 'getting into ../apache_1.3.3'. So I
> renamed the directory to be called old.apache_1.3.3 and recompiled.
>
> Voilá!
>
> So either my APACHE_SRC argument was wrong (I swear I read it in
> Stas' Guide) or the Makefile was ignoring it...
Seems to me like you forgot to make clean before rebuilding stuff. A few
folks reported in the past that starting from clean tar solved their
problems.
As for the APACHE_SRC, the scenario you have described can only happen if
you provided invalid APACHE_SRC paramter. Here is the relevant snippet
from Makefile.PL:
for $src_dir ($APACHE_SRC, <../apache*/src>,
<../stronghold*/src>, ,
"../src", "./src")
{
next unless -d $src_dir;
next if $seen{$src_dir}++;
next unless $vers = httpd_version($src_dir);
unless(exists $vers_map{$vers}) {
print STDERR "Apache version '$vers' unsupported\n";
next;
}
$mft_map{$src_dir} = $vers_map{$vers};
#print STDERR "$src_dir -> $vers_map{$vers}\n";
push @adirs, $src_dir;
$modified{$src_dir} = (stat($src_dir))[9];
last if $DO_HTTPD;
}
If $APACHE_SRC is defined correctly relative to mod_perl src tree, the
'for' loop goes thru only once.
> Now if you find it was my mistake, one way or another, then please
> forgive me for saying the bug was yours [whoever wrote the makefile]
> when it was mine.
The bad thing is that you report about a potential problem, but don't stay
with us to follow up. So I thought twice before replying to your email,
since I feel that I talk to the wall until before you come back from your
vacation...
Enjoy the vacation :)
___
Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Bug in mod_perl makefile?
Hi, I've just got my apache/modperl setup to work. This little nastie took me 2 days to find. In my /usr/src directory, I had: - apache_1.3.3 [dir] - apache_1.3.9 [dir] - mod_perl-1.21 [dir] and was compiling modperl/perl with: #perl Makefile.PL APACHE_SRC=/usr/src/apache_1.3.9 DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 PERL_MARK_WHERE=1 APACI_ARGS=--enable-module=all #make && make test && make install and then a make install from apache_1.3.9 This setup was consistently failing, or rather ... - if I added --enable-shared=max apache compiled and started unless a call to mod_perl was made. If I tryed to load Embperl in httpd.conf, httpd would not start, claiming that Apache::Constants was not installed/found/whatever. - I upgraded perl, recompiled perl + all the perl modules I had + mod-perl + apache again. Several recompiles and shrieks. Now, today, with a fresh head, I noticed a little message when making mod_perl, which said it was 'getting into ../apache_1.3.3'. So I renamed the directory to be called old.apache_1.3.3 and recompiled. Voilá! So either my APACHE_SRC argument was wrong (I swear I read it in Stas' Guide) or the Makefile was ignoring it... Sadly, I'm going holidays tonight, so I can't [and won't] stay here to dissect Makefile.PL, but I thought it was nice to tell the list. Now if you find it was my mistake, one way or another, then please forgive me for saying the bug was yours [whoever wrote the makefile] when it was mine. ml -- -- To understand recursion, one must first understand recursion. -- -- - Martin Langhoff @ S C I M Multimedia Technology - - http://www.scim.net | God is real until - - mailto:[EMAIL PROTECTED] | declared integer -
Re: Fix for Redhat(?) bug in mod_perl install
On Sat, 4 Dec 1999, Autarch wrote: > I don't remember if this has been discussed before but anyway. If you're > running Redhat 6.0 (and maybe 6.1?) there may be some weirdness when you > try to install modperl. Basically, when you go to run make on apache, it > gives it some -L or -I flags that include libgdbm, because your Perl was > compiled with this. However, there is a missing symlink in the /usr/lib > directory. Just do the following to fix it: > > ln -s libgdbm.so.2.0.0 libgdbm.so > > This should probably be added to the guide or something. The failure > message you get is the compile failed the sanity check, with no mention of > libgdbm at all. It's pretty wacky! indeed. I added a sanity check to Makefile.PL that's in the cvs tree for 1.22
Re: Fix for Redhat(?) bug in mod_perl install
> On Sat, 4 Dec 1999, Autarch wrote: > > > I don't remember if this has been discussed before > but anyway. If you're > > running Redhat 6.0 (and maybe 6.1?) > > Just this moment installed a RH-6.1 system. It did > not exhibit this > problem. fwiw, my install of RH6.0 didn't have this problem. remi __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: Fix for Redhat(?) bug in mod_perl install
On Sat, 4 Dec 1999, Autarch wrote: > I don't remember if this has been discussed before but anyway. If you're > running Redhat 6.0 (and maybe 6.1?) Just this moment installed a RH-6.1 system. It did not exhibit this problem. > there may be some weirdness when you > try to install modperl. Basically, when you go to run make on apache, it > gives it some -L or -I flags that include libgdbm, because your Perl was > compiled with this. However, there is a missing symlink in the /usr/lib > directory. Just do the following to fix it: > > ln -s libgdbm.so.2.0.0 libgdbm.so > > This should probably be added to the guide or something. The failure > message you get is the compile failed the sanity check, with no mention of > libgdbm at all. It's pretty wacky! -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: Fix for Redhat(?) bug in mod_perl install
> I don't remember if this has been discussed before but anyway. If you're > running Redhat 6.0 (and maybe 6.1?) there may be some weirdness when you > try to install modperl. Basically, when you go to run make on apache, it > gives it some -L or -I flags that include libgdbm, because your Perl was > compiled with this. However, there is a missing symlink in the /usr/lib > directory. Just do the following to fix it: > > ln -s libgdbm.so.2.0.0 libgdbm.so > > This should probably be added to the guide or something. The failure > message you get is the compile failed the sanity check, with no mention of > libgdbm at all. It's pretty wacky! I have added it already, will show up in a new release. Thank you for sharing this factoid with us! ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org & www.perl.com == www.modperl.com || perl.apache.org single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Fix for Redhat(?) bug in mod_perl install
I don't remember if this has been discussed before but anyway. If you're running Redhat 6.0 (and maybe 6.1?) there may be some weirdness when you try to install modperl. Basically, when you go to run make on apache, it gives it some -L or -I flags that include libgdbm, because your Perl was compiled with this. However, there is a missing symlink in the /usr/lib directory. Just do the following to fix it: ln -s libgdbm.so.2.0.0 libgdbm.so This should probably be added to the guide or something. The failure message you get is the compile failed the sanity check, with no mention of libgdbm at all. It's pretty wacky! -Dave /*== www.urth.org We await the New Sun ==*/
