RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote: > OK, can you describe the problem a little more clearly? The "Testing user > file" bit doesn't seem to come from anywhere - any ideas where it's coming > from??? I had assumed it was coming from Apache, but your question made me suspicious. After a little digging, I discovered it's coming from a userv script that is used to restart development apache daemons so all us lowly developers don't need to have su priveleges ;). I won't bother you with the details, except to say it didn't permit adding config directives. Having fixed that, the server restarts fine, which means the new directives are getting read properly, but when I try to hit that development vhost with my browser the child segfaults. Which is where I'm stuck now. > > > > Details: > > > > > > > > mod_perl version used is 1.23 > > > > > > There have been some fairly serious config directives bugs fixed since > > > then. I suggest an upgrade. > > > > I'll look into it, but my sysadmins are worried that upgrading is going to > > break, in strange and obscure ways, the multiple live commercial sites we > > have running on our servers. Are there any resources available I might be > > able to use to reassure them? > > No! They have every right to be concerned. Don't try this stuff on a live > server, seriously. I do it on axkit.org (at least I did it on axkit.org when > it was live), but there was never anything business critical on there except > documentation. Don't worry, it's all happening on an isolated development server, I was just wondering whether there are any resources that indicate what things might break when upgrading from 1.23 to 1.24. But if I can't get this working soon time pressure will force me to use the functional but much less elegant PerlSetVar method, and an upgrade will be irrelevant. Any advice (from anyone) on how to fix the segfault problem would still be appreciated, though. Many thanks to all for the advice I've received already. -mike -- Michael Styer [EMAIL PROTECTED] phone: 020 7603 5723107 Shepherd's Bush Rd fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote:
> > -Original Message-
> > From: Michael Styer [mailto:[EMAIL PROTECTED]]
> >
> > In Makefile.PL I have:
> I'm assuming you have more than that... :-)
Yes. :)
It actually looks like this:
package ConfigModule;
use ExtUtils::MakeMaker;
use Apache::ExtUtils qw(command_table);
use Apache::src ();
my @directives = (
{ name => 'ConfigDirective',
errmsg => 'name of the handler module',
args_how => 'TAKE1',
req_override => 'RSRC_CONF'
}
);
command_table(\@directives);
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
## required makefile stuff
);
> > and in ConfigModule.pm I have:
> >
> > sub NewConfigDirective ($$$) {
> > my ($cfg, $parms, $arg) = @_;
> > $cfg->{'NewConfigDirective'} = $arg;
> > }
> >
> >
> > One clue I've found as to where something might be going wrong is that
> > when I comment out the 'args_how' line in Makefile.PL and run 'perl
> > Makefile.PL' I get this error:
> >
> > Can't determine prototype for
> > `ConfigModule::NewConfigDirective': at
> >
> > /usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
>
> That's because ConfigModule.pm isn't loaded at the time. You'd have to
> require() it or use() it.
Even when the makefile is declared as 'package ConfigModule;' initally?
It seems strange that I would need to write 'package Foo; use Foo;'. Maybe
I don't understand how that works. Would I need a 'use lib ...' statment
there so Makefile.PL would know where to look for ConfigModule.pm?
> > So it looks as though something isn't reading ConfigModule.pm on
> > WriteMakefile or on command_table and possibly not
> > registering the handler for the new directive, which might explain why
> > I'm getting a syntax error in the httpd.conf file when the server
> > starts. But what would be causing that to happen? I'm afraid I'm not
> > familiar enough with the MakeMaker mechanism to figure out what's
> > going on. Then again, I'm not sure that's really the problem, so
> > disregard it if you think it's a red herring.
>
> Are you getting a ConfigModule.xs file written and compiled OK?
Yeah, there don't seem to be any problems writing and compling
ConfigModule.xs. I can get through make, make test, and make install
without any problems; it's just when it comes to starting the server that
I run into the problem.
> > Details:
> >
> > mod_perl version used is 1.23
>
> There have been some fairly serious config directives bugs fixed since then.
> I suggest an upgrade.
I'll look into it, but my sysadmins are worried that upgrading is going to
break, in strange and obscure ways, the multiple live commercial sites we
have running on our servers. Are there any resources available I might be
able to use to reassure them?
Thanks for your help.
-mike
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
More problems with custom config directives (LONG)
Hi there,
I'm another person in the short but persistent line of people who can't
seem to get custom configuration directives to work.
I'm working with the Eagle book on this, and I've read all the relevant
threads I can find in the list archives, but since I'm having a slightly
different problem from the one my fellow strugglers were having, the
advice given to them didn't work for me.
The symptom:
On starting httpd, I get this response:
Testing user file: NewConfigDirective argumentToDirective
I tried doing away with the PerlModule directive and using the workaround
suggested by Doug MacEachern on June 9 2000, which was to put these
statements in the conf file:
delete $INC{'/path/to/ConfigModule.pm'};
require ConfigModule;
but when I do that, I get this:
Testing user file: delete $INC{'Apache/VI/Config.pm'}
In Makefile.PL I have:
package ConfigModule;
## ... (as directed by Eagle)
my @directives = (
{ name => 'NewConfigDirective',
errmsg => 'argument to config directive',
args_how => 'TAKE1',
req_override => 'RSRC_CONF'
}
);
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg->{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for `ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
According to the Eagle book, I should be able to get rid of the 'args_how'
line as long as I provide a prototype in the subroutine definition, but it
seems I can't.
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not registering the handler
for the new directive, which might explain why I'm getting a syntax error
in the httpd.conf file when the server starts. But what would be causing
that to happen? I'm afraid I'm not familiar enough with the MakeMaker
mechanism to figure out what's going on. Then again, I'm not sure that's
really the problem, so disregard it if you think it's a red herring.
Any advice anyone can give would be very much appreciated.
-mike
=
Details:
mod_perl version used is 1.23
perl version used is 5.005_03
apache version used is 1.3.11
$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.5-22, archname=i686-linux
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL'
ccflags ='-Dbool=char -DHAS_BOOL'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=true, libperl=libperl.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/perl5/lib/5.00503/i686-linux/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at Aug 22 1999 14:02:34
@INC:
/usr/perl5/lib/5.00503/i686-linux
/usr/perl5/lib/5.00503
/usr/perl5/lib/site_perl/5.005/i686-linux
/usr/perl5/lib/site_perl/5.005
.
$ /usr/sbin/httpd -V
Server version: Apache/1.3.11 (Unix)
Server built: Feb 1 2000 21:17:00
Server compiled with
-D EAPI
-D EAPI_MM
-D EAPI_MM_CORE_PATH="/var/run/httpd.mm"
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FCNTL_SERIALIZED_ACCEPT
$ /usr/sbin/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
possible error in Eagle book? (was RE: help with $r->headers_in->do()method)
On Fri, 17 Aug 2001, Geoffrey Young wrote:
> > I've got a question for the mod_perl world about the behavior of the
> > $r->headers_in->do(sub {...some code...}) method.
> it probably won't matter, but do() iterates through the table and exits
> either when the list is exhausted or the subroutine returns a non-true value
>
> $r->headers_in->do(sub {
> $request->header(@_);
> #print STDERR "header passed: (@_)\n";
> 1;
> });
>
> like the Eagle book does and see if that helps. Otherwise, there might be
> something going on internally with Apache where the proxy headers are
> stripped. I don't do proxies, so I'm not that familar with the mechanics of
> them...
>
> --Geoff
Thanks Geoff. In fact, it did matter, and solved the problem.
In the process, I've found what seems to be a mistake, or at least an
oversight, in the Eagle book... (a good workman and all, I know, but bear with
me)
On page 475, it has do() explained exactly as Geoff stated above,
i.e. that the subroutine reference passed to it must return a true value
or the iteration will stop.
But on page 380, it has the following code as part of example 7-12:
$r->headers_in->do(sub {
$request->header(@_);
});
>From what I can see, HTTP::Request->header returns undef when
setting a header value, so while this code isn't strictly incorrect, it
won't pass the full header set, just the first header-value pair.
Is this right? I'm fairly new at this, so if anyone else would mind
checking this out, I'd appreciate it.
Thanks.
-mike
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
help with $r->headers_in->do() method
Hi there.
I've got a question for the mod_perl world about the behavior of the
$r->headers_in->do(sub {...some code...}) method.
I'm writing a proxy handler, and am getting strange results when trying to
pass headers from the initial request to the proxied request. The problem
is that the two blocks of code below are supposed to do the same
thing, and look as though they definitely should do the same thing, but
don't.
If anyone has any answers or suggestions, I'd love to hear them.
Thanks in advance for any advice you might have.
-mike styer
=
## initial header printout
my @headers = $r->headers_in;
print STDERR "original headers: \n";
while (my ($f, $v) = each %headers) { print STDERR "$f: $v\n"; }
## block (1)
print STDERR "\nPassing headers: ...\n";
$r->headers_in->do(sub {
$request->header(@_);
#print STDERR "header passed: (@_)\n";
});
print STDERR "\nPROXY request:\n".$request->as_string."\n";
## block (2)
print STDERR "\nPassing headers: ...\n";
$r->headers_in->do(sub {
$request->header(@_);
print STDERR "header passed: (@_)\n";
});
print STDERR "\nPROXY request:\n".$request->as_string."\n";
=
The only difference between those two blocks is the fact that the print
STDERR "header passed: (@_)\n"; line is commented out in the second block.
But they produce significantly different output, for no reason that's
apparent to me.
The output from these blocks is (formatted for easier reading):
original headers:
Connection: Keep-Alive
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Encoding: gzip
Accept-Charset: iso-8859-1,*,utf-8
Cookie: visited=yes
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
Host: proxy.server.net
Passing headers: ...
PROXY request:
GET http://proxied.site.com/
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Passing headers: ...
header passed: (Accept image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, image/png, */*)
header passed: (Accept-Charset iso-8859-1,*,utf-8)
header passed: (Accept-Encoding gzip)
header passed: (Accept-Language en)
header passed: (Connection Keep-Alive)
header passed: (Cookie visited=yes)
header passed: (Host proxy.server.net)
header passed: (User-Agent Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686))
PROXY request:
GET http://proxied.site.com/
Connection: Keep-Alive
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding: gzip
Accept-Language: en
Host: proxy.server.net
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
Cookie: visited=yes
As you can see, the headers don't get passed on the first try, without the
print STDERR statement. As far as I can tell, there's NO reason why
printing the values to STDERR should affect whether they get passed on,
but it seems to be having that affect.
I'm stumped, so like I said, any help would be most appreciated.
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
