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:
Perl
delete $INC{'/path/to/ConfigModule.pm'};
require ConfigModule;
/Perl
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
default file locations cut
$ /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
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:
snip abbreviated makefile code listing
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
RE: More problems with custom config directives (LONG)
-Original Message-
From: Michael Styer [mailto:[EMAIL PROTECTED]]
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.
:-)
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'
}
);
I'm assuming you have more than that... :-)
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.
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?
Details:
mod_perl version used is 1.23
There have been some fairly serious config directives bugs fixed since then.
I suggest an upgrade.
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
-Original Message- From: Michael Styer [mailto:[EMAIL PROTECTED]] 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? Nah, you can do require(ConfigModule.pm) and it'll work. 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. 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??? 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. Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
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. The (possibly a slightly obvious point) way I'd recommend dealing with this is to test everything on your development machine(s), make sure it all works, and the upgrade hasn't broken anything, and then upgrade the live systems, with plans to revert if it all goes wrong, and so on - the same way you'd make any other serious upgrade to an important live system. If you don't have systems you can test everything out on, you have a serious problem and should probably deal with this first. Michael http://www.iii.co.uk Interactive Investor International is a leading UK Internet personal finance service that provides individuals with the capability to identify, compare, monitor and buy online a number of financial products and services. Interactive Investor Trading Limited, a subsidiary of Interactive Investor International plc, is regulated by the SFA.
RE: More problems with custom config directives (LONG)
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 22, 2001 6:41 AM To: 'Michael Styer'; Matt Sergeant Cc: [EMAIL PROTECTED] Subject: RE: More problems with custom config directives (LONG) [snip] 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. well, I think this really depends on your situation. directive handlers are not as robust as they could be, we all know that. but I've had Apache::Dispatch (which uses directive handlers) running in production since December without any issues. bottom line is (as always) never put anything into production that hasn't been sufficiently stressed in development. --Geoff
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)
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. you'll want to move to at least 1.25 with directive handlers (well, actually 1.24_01 IIRC) due to a major bug fix, the nature of which is escaping me this morning but can be found in the archives. --Geoff
RE: custom config directives
it's actually really quite simple. just take a look at the several modules on CPAN that use it. Apache::Dispatch, Apache::RefererBlock, and Apache::Language all come to mind. for the names and meaning of the constants involved, check out http_config.h. other than that, there really isn't another source of documentation that I know about (yet ;) HTH --Geoff -Original Message- From: brian moseley To: [EMAIL PROTECTED] Sent: 7/14/01 2:19 AM Subject: custom config directives is there any good thorough documentation on building custom config directives other than what's in the eagle book? i left mine back in au and i don't really want to buy another one :)
Re: custom config directives
is there any good thorough documentation on building custom config directives other than what's in the eagle book? i left mine back in au and i don't really want to buy another one :) You're in luck, that chapter is on-line: http://www.modperl.com/book/chapters/ch8.html
custom config directives
is there any good thorough documentation on building custom config directives other than what's in the eagle book? i left mine back in au and i don't really want to buy another one :)
FINALE: (or finally!) Re: Can't create custom config directives(long)
And the really GOOD NEWS!!! When I upgraded to mod_perl 1.24, the problem
went away. It all works like it's suppossed to now.
--On 06/09/00 12:02:40 -0700 Doug MacEachern [EMAIL PROTECTED] wrote:
On Thu, 8 Jun 2000, Rob Tanner wrote:
MirrorWiseKeyFile', perhaps mis-spelled or defined by a module not
included in the server configuration
...
PerlModule Apache::MirrorWise
this is becoming a common problem, try this bandaid, instead of that
PerlModule line:
Perl
delete $INC{'Apache/MirrorWise.pm'};
require Apache::MirrorWise;
/Perl
-- Rob
_ _ _ _ __ _ _ _ _
/\_\_\_\_\/\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_//\/_/
/\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
Re: Can't create custom config directives (long)
On Thu, 8 Jun 2000, Rob Tanner wrote:
MirrorWiseKeyFile', perhaps mis-spelled or defined by a module not
included in the server configuration
...
PerlModule Apache::MirrorWise
this is becoming a common problem, try this bandaid, instead of that
PerlModule line:
Perl
delete $INC{'Apache/MirrorWise.pm'};
require Apache::MirrorWise;
/Perl
Can't create custom config directives (long)
Hi All,
(This message is VERY long --I'm trying to include as much information as I
can)
Back on June 3 I posted a message about a problem I was having installing
custom configuration directives. Since then, I have been going over
everything with a fine tooth comb -- which was probably not worth the
effort at all because the whole process (at least as explained in the eagle
book) is a piece of cake. Basically, perl does all the hard work and all I
do is a couple of tables.
Last night I rebuilt apache and mod_perl (versions 1.3.12 and 1.23
respectively -- mod_perl being compiled in and not a dso) in order to build
mod_perl with the PERL_TRACE option, and also to discover if there was
something flaky in the previous build. If the latter is the case, the
flakiness carried over since it still fails.
Basically, when you invoke httpd as a daemon, it starts up successfully,
parses the httpd.conf file, finds no problem and returns with an exit code
of '0', meaning that it found no problem and forked off the daemonm copy.
Thus, apachectl reports that apache was successfully started. Howver, the
daemon dies quickly and reports in the error_log:
MirrorWiseKeyFile', perhaps mis-spelled or defined by a module not
included in the server configuration
If I actually mess with the directive, spell it wrong or add or remove an
argument, when apache originally parses the httpd.conf file it finds reason
to complain, and apachectl does not come back and report a successful
startup. Rather, it report an error, run "apachectl configtest" to see the
error. Also, when I add various debug hooks into the callback for the
directive, I can confirm that it's being invoked and getting the argument
(it's a TAKE1). So, whatever is going on is something else, and it's
happening after the initial fork.
I have included the debug output below, tracing was set to "all".
[root@cheshire apache]# bin/httpd -X
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
PerlRequire: arg=`conf/startup.pl'
attempting to require `conf/startup.pl'
loading perl module 'Apache::Constants::Exports'...ok
perl_cmd_fresh_restart: 1
perl_cmd_setenv: 'PERL_DESTRUCT_LEVEL' = '-1'
perl_cmd_setenv: 'DBMauthFile' = 'private/authen/passwdMD5'
loading perl module 'Apache'...ok
PerlModule: arg='Apache::MirrorWise'
loading perl module 'Apache::MirrorWise'...ok
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::MirrorWise'
pushing `Apache::MirrorWise' into `PerlHandler' handlers
blessing cmd_parms=(0xbfffda68)
However, in the error log we read:
Syntax error on line 16 of /usr/local/apache/conf/perl.conf:
Invalid command 'MirrorWiseKeyFile', perhaps mis-spelled or defined by a
module not included in the server configuration
This is the perl.conf file that contains the directive:
PerlRequire conf/startup.pl
PerlFreshRestart On
#Location /hello/world
# SetHandler perl-script
# PerlHandler Apache::Hello
#/Location
#
PerlSetEnv PERL_DESTRUCT_LEVEL -1
PerlSetEnv DBMauthFile private/authen/passwdMD5
#
PerlModule Apache::MirrorWise
SetHandler perl-script
PerlHandler Apache::MirrorWise
#
MirrorWiseKeyFile conf/keyfile
Anybody have any ideas?
Thanks,
Rob
ATTACHED HISTORY:
Here follows the original post and a dialogue I had with another member of
the list. His suggestions were helpful, but did not resolve the issue.
Hi all,
I'm trying to create several custom configuration directives, and have
pretty mucg followed the eample in the eagle book (pp 387-394).
I start Apache up -- get no configuration complaints and apachectl comes
back saying Apache started. The info messages in the error log,
however, indicate otherwise. To wit:
Invalid command 'MirrorWiseKeyFile', perhaps mis-spelled or defined by a
module not included in the server configuration
In Makefile.PL, I include:
my @directives = (
{ name = 'MirrorWiseKeyFile',
errmsg = 'location of password DB key file',
args_how = 'TAKE1',
req_override = 'OR_ALL' },
{
a second directive here but not yet
added to httpd.conf },
);
command_table(\@directives);
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
'NAME' = __PACKAGE__,
'VERSION_FROM' = 'MirrorWise.pm',
'INC' = Apache::src-new-inc,
'INSTALLSITEARCH' = $install_here,
'INSTALLSITELIB'= $install_here,
);
1;
The $install_here, above, is simply a scalar set to the module root
in the Apache doc root (currently:
RE: Problems with custom config directives in user written modules
I cannot seem to get custom configuration directives to work in
apache (1.3.11) modperl (1.21). I would presume the examples in the
book do not work either. I found someone having similar problems
in the list archives, to which Doug provided a workaround which also
does not work.
Any advice about this issue is helpful. Please reply to me directly as
well.
In Makefile.PL:
my @directives = (
...
{ name= 'Directive4',
errmsg = 'Anything',
args_how= 'RAW_ARGS',
req_override= 'OR_ALL',
},
);
In the httpd.conf file:
Perl
require Apache::TestDirective;
delete $INC{'Apache/TestDirective.pm'};
/Perl
#PerlModule Apache::TestDirective
Why are you using 'require', and not the PerlModule line you commented
out?
Directive4 foo
What comes back:
Invalid command 'Directive4', perhaps mis-spelled or defined by a
module not included in the server configuration
--
Eric
Re: Problems with custom config directives in user written modules
Eric Cholet [EMAIL PROTECTED] writes:
Perl
require Apache::TestDirective;
delete $INC{'Apache/TestDirective.pm'};
/Perl
#PerlModule Apache::TestDirective
Why are you using 'require', and not the PerlModule line you commented
out?
It appeared to work. =)
In searching the mail archives I found reference to this problem
before. The above was provided by Doug.
Neither method actually works.
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
The opinions expressed above are entirely my own
Better the demon that makes you improve than the angel who threatens.
Re: Problems with custom config directives in user written modules
Following up to myself I am. Firstly, that was Directive3 (not Directive4). Directive3 returns OK. $ bin/apachectl configtest works just fine, no problems. $ bin/apachectl start is where it fails to find the command, looks like in some related child process. It seems to be that the command does not add properly on a child restart (probably calling ap_read_config again). If I can figure out how to get gdb attached, I might be able to provide even more data. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own Compassion will cure more sins than condemnation.
Problems with custom config directives in user written modules
I cannot seem to get custom configuration directives to work in
apache (1.3.11) modperl (1.21). I would presume the examples in the
book do not work either. I found someone having similar problems
in the list archives, to which Doug provided a workaround which also
does not work.
Any advice about this issue is helpful. Please reply to me directly as
well.
In Makefile.PL:
my @directives = (
...
{ name= 'Directive4',
errmsg = 'Anything',
args_how= 'RAW_ARGS',
req_override= 'OR_ALL',
},
);
In the httpd.conf file:
Perl
require Apache::TestDirective;
delete $INC{'Apache/TestDirective.pm'};
/Perl
#PerlModule Apache::TestDirective
Directive4 foo
What comes back:
Invalid command 'Directive4', perhaps mis-spelled or defined by a
module not included in the server configuration
Other details are...Modperl built with:
perl Makefile.PL APACHE_SRC=/usr/local/webadmin/${APACHE} DO_HTTPD=1
USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 PERL_TRACE=1
and Apache built with:
./configure \
"--with-layout=Apache" \
"--prefix=/usr/local/www" \
"--enable-module=most" \
"--enable-shared=max" \
"--activate-module=src/modules/extra/mod_macro.c" \
"--activate-module=src/modules/perl/libperl.a" \
$ bin/httpd -V
Server version: Apache/1.3.11 (Unix)
Server built: Jan 30 2000 17:23:31
Server's Module Magic Number: 19990320:6
Server compiled with
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FLOCK_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT="/usr/local/webadmin"
-D SUEXEC_BIN="/usr/local/webadmin/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
-D DEFAULT_LOCKFILE="logs/httpd.lock"
-D DEFAULT_XFERLOG="logs/access_log"
-D DEFAULT_ERRORLOG="logs/error_log"
-D TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
-D ACCESS_CONFIG_FILE="conf/access.conf"
-D RESOURCE_CONFIG_FILE="conf/srm.conf"
$ bin/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_macro.c
mod_perl.c
$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=freebsd, osvers=3.3-release, archname=i386-freebsd
uname='freebsd somehost.org 3.3-release freebsd 3.3-release #0: sun nov 21
22:33:17 pst 1999 [EMAIL PROTECTED]:usrsrcsyscompilekern i386 '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O', gccversion=2.7.2.3
cppflags='-I/usr/local/include -DPERL_EMERGENCY_SBRK -DDEBUGGING_MSTATS
-DPACK_MALLOC -DTWO_POT_OPTIMIZE'
ccflags ='-I/usr/local/include -DPERL_EMERGENCY_SBRK -DDEBUGGING_MSTATS
-DPACK_MALLOC -DTWO_POT_OPTIMIZE '
stdchar='char', d_stdstdio=undef, usevfork=true
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=y, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-ldb -lm -lc -lcrypt
libc=/usr/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under freebsd
Compiled at Nov 22 1999 16:25:57
%ENV:
PERL5LIB="/home/dave/lib/perl"
@INC:
/home/dave/lib/perl
/usr/local/lib/perl5/5.00503/i386-freebsd
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
The opinions expressed above are entirely my own
True freedom requires taking responsibility for your own life. That
frightens the hell out of too many people. They prefer to have Big
Brother holding a safety net for them, and they'll sell their own
birthright and their children's as well to keep it. --F. Paul Wilson
