Re: Trouble using dir_config for PerlSetVar inside Perl section
Hi Geoff -
> > and this does not work either:
> >
> > push @{$Location{"/"}->{PerlSetVar}}, ["CFG", "/path/to/file"];
> > $PerlRequire = "startup.pl";
> >
>
[snip]
>
> what may be happening is that your dynamic configuration may be putting your
> PerlSetVar into a per-directory scope instead of a per-server scope, since
> your config is now in a section. meaning, Apache->server->dir_config
> is (rightfully) empty because now your configuration is in
> Apache->request->dir_config. of course, you can't get at $r->dir_config at
> startup, so you're pretty much SOL.
>
> try looking at $r->dir_config('CFG') in a request and see if your value is
> there. if it is, then I guess my theory is right, and there is little that
> can be done about it.
Thanks, you're right about what is happening. Since I need to set the
config file path dynamically in httpd.conf and I need to access it in
startup.pl, I ended up using an environment variable instead:
PerlPassEnv CFG
$ENV{CFG} ||= "/path/to/file";
$PerlRequire = "startup.pl";
I had to use PerlPassEnv outside the Perl section - using something like:
push @PerlSetEnv, ["CFG", "/path/to/file"];
inside the Perl section seems to have the same issues with per-directory
scope as PerlSetVar.
Thanks,
Larry
Re: Trouble using dir_config for PerlSetVar inside Perl section
Larry Leszczynski wrote:
Hi all -
I'm having trouble using server->dir_config in my startup.pl to read
variables set by PerlSetVar inside a Perl section. I'm using Perl 5.6.1,
Apache 1.3.27, and mod_perl 1.27.
[snip]
and this does not work either:
push @{$Location{"/"}->{PerlSetVar}}, ["CFG", "/path/to/file"];
$PerlRequire = "startup.pl";
It seems like this should work, right?
you may be running into an odditity of PerlSetVar. internally, mod_perl has
logic to merge per-server and per-directory PerlSetVar attributes, doing it
itself instead of relying on Apache. while this is good under most
circumstances, I think you've uncovered someplace where it doesn't work as
well as you'd like.
what may be happening is that your dynamic configuration may be putting your
PerlSetVar into a per-directory scope instead of a per-server scope, since
your config is now in a section. meaning, Apache->server->dir_config
is (rightfully) empty because now your configuration is in
Apache->request->dir_config. of course, you can't get at $r->dir_config at
startup, so you're pretty much SOL.
try looking at $r->dir_config('CFG') in a request and see if your value is
there. if it is, then I guess my theory is right, and there is little that
can be done about it.
HTH
--Geoff
Trouble using dir_config for PerlSetVar inside Perl section
Hi all -
I'm having trouble using server->dir_config in my startup.pl to read
variables set by PerlSetVar inside a Perl section. I'm using Perl 5.6.1,
Apache 1.3.27, and mod_perl 1.27.
In startup.pl I have:
my $file = Apache->server->dir_config("CFG") || "";
warn "Missing path to config file in httpd.conf" unless $file;
In httpd.conf, this works just fine:
PerlSetVar CFG /path/to/file
PerlRequire startup.pl
and this works fine too:
PerlSetVar CFG /path/to/file
$PerlRequire = "startup.pl";
But this does not work (CFG is not set in startup.pl):
push @{$Location{"/"}->{PerlSetVar}}, ["CFG", "/path/to/file"];
PerlRequire startup.pl
and this does not work either:
push @{$Location{"/"}->{PerlSetVar}}, ["CFG", "/path/to/file"];
$PerlRequire = "startup.pl";
It seems like this should work, right? I'm pretty sure the syntax of the
"push" is OK because if I modify the syntax I get a message:
(2)No such file or directory: : PerlSetVar takes two arguments,
Perl config var and value
Thanks,
Larry Leszczynski
[EMAIL PROTECTED]
perl section does not override conf default
Hi
I have an httpd.conf like this for what concerns icons
(this is default apache conf)
#Alias /icons/ "c:/apback/icons/"
#
#Options Indexes MultiViews
#AllowOverride None
#Order allow,deny
#Allow from all
#
later in the conf I have a perl section redefining the above :
[...]
push @Alias, ['/icons/'=>"$MY::basePath/icons/"];
$Directory{$MY::basePath.'/icons'}={
Options=>'Indexes Multiviews',
AllowOverride=>'None',
Order=>'allow,deny',
Allow=>'from all'
};
$Location{"/icons/"}=
{
SetHandler=>'default-handler',
};
the problem is that
if I do not comment out apache default conf section,
handler is well reset to default handler but the alias
and directory directive are not overriden by the perl section
so icons are sought in default c:/apback/icons directory
instead of the special one indicated by $MYbasepath.
is it normal ?
thanks
pascal
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)"
Re: Perl Section Bug?
On 13 Feb 2002, Salvador Ortiz Garcia wrote: > Ok, I found it. Right now all Location, Directory and Files are afected > by being "upgraded" at random to the Match versions. > > Can you please test the following patch for perl_config.c: You might be intersted to know that this patch also fixes strange problems I was having with sections as well. Here is a link to the email where I reported the bug: http://www.geocrawler.com/archives/3/182/2001/2/200/5185227/ Doug looked at it for a while, but nothing obvious jumped out at him either so it just got listed as a ToDo :). Applying the patch you sent in this tread to mod_perl 1.26 makes the problem go away. Mike
Re: Perl Section Bug?
On Wed, 2002-02-13 at 20:44, Salvador Ortiz Garcia wrote: > Ok, I found it. Right now all Location, Directory and Files are afected > by being "upgraded" at random to the Match versions. Ugly. > Can you please test the following patch for perl_config.c: Yes, that does indeed correct the problem. Thank you. > Right now I'm working in a more radical patch to fix other minor > problems related to sections handling. Can I assume that the fixes will be in 1.27? Does Doug have plans for another release soon? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl Section Bug?
On Wed, 2002-02-13 at 13:44, David Wheeler wrote:
> On Fri, 2002-02-08 at 20:25, Salvador Ortiz Garcia wrote:
> > Yes, It's a bug in Sections. Confirmed in 1.26.
>
>
>
> > I'm digging into it.
>
> Thanks. I'm glad to know that I'm not imagining things. We've just found
> a place in Bricolage where the Location directive *does* work as
> expected. So you're right -- it's worse. Ugh.
>
> Thanks,
>
> David
Ok, I found it. Right now all Location, Directory and Files are afected
by being "upgraded" at random to the Match versions.
Can you please test the following patch for perl_config.c:
===
--- perl_config.c Tue Jul 10 20:47:15 2001
+++ perl_config.c.new Wed Feb 13 22:40:27 2002
@@ -1166,6 +1166,7 @@
char *tmpkey;
I32 tmpklen;
SV *tmpval;
+void *old_info = cmd->info;
(void)hv_iterinit(hv);
while ((tmpval = hv_iternextsv(hv, &tmpkey, &tmpklen))) {
char line[MAX_STRING_LEN];
@@ -1195,6 +1196,7 @@
if(errmsg)
log_printf(cmd->server, ": %s", errmsg);
}
+cmd->info = old_info;
/* Emulate the handling of end token for the section */
perl_set_config_vectors(cmd, cfg, &core_module);
}
@@ -1511,9 +1513,7 @@
void *dummy = perl_set_config_vectors(cmd, config, &core_module);
void *old_info = cmd->info;
-if (strstr(key, "Match")) {
- cmd->info = (void*)key;
-}
+cmd->info = (void*)strstr(key,"Match");
if(strnEQ(key, "Location", 8))
perl_urlsection(cmd, dummy, hv);
===
Right now I'm working in a more radical patch to fix other minor
problems related to sections handling.
Regards
Salvador Ortiz.
Re: Perl Section Bug?
On Fri, 2002-02-08 at 20:25, Salvador Ortiz Garcia wrote: > Yes, It's a bug in Sections. Confirmed in 1.26. > I'm digging into it. Thanks. I'm glad to know that I'm not imagining things. We've just found a place in Bricolage where the Location directive *does* work as expected. So you're right -- it's worse. Ugh. Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl Section Bug?
Yes, It's a bug in Sections. Confirmed in 1.26.
But it is worse.
With the following in httpd.conf try /info vs /status vs /status/info vs
/info/status, with and without the commented part, (if one section
fails, if two sections works)
$Location{'/status'} = {
SetHandler => 'server-status',
Allow => 'from localhost'
};
#
#
$Location{'/info'} = {
SetHandler => 'server-info',
Allow => 'from localhost'
};
I'm digging into it.
Regards,
Salvador Ortiz.
On Fri, 2002-02-01 at 20:56, David Wheeler wrote:
> Okay, let me try again.
>
> I have a simple module I've written that demonstrates the problem. here
> it is:
>
> package MyTest;
> our $VERSION = '0.1';
> use Apache;
>
> sub one {
> print STDERR "One\n";
> print STDOUT "One\n";
> return Apache::OK;
> }
>
> sub two {
> print STDERR "Two\n";
> print STDOUT "Two\n";
> return Apache::OK;
> }
>
> package Apache::ReadConfig;
> use strict;
> use warnings;
>
> our $NameVirtualHost = '*:80';
>
> our %VirtualHost = ('*:80' => {
> ServerName => '_default_',
> DocumentRoot => '/usr/local/apache/htdocs',
> Location => {
> '/one' => {
> SetHandler => 'perl-script',
> PerlHandler=> 'MyTest::one'
> },
> '/two' => {
> SetHandler => 'perl-script',
> PerlHandler=> 'MyTest::two'
> }
> }
> });
>
>
> Now, if I execute this from httpd.conf by simply calling
>
> PerlModule MyTest
>
> Here's what I get for my requests:
>
> URL Prints
> === ==
> http://myserver/one One
> http://myserver/two Two
> http://myserver/one/foo One
> http://myserver/two/foo Two
> http://myserver/one/two One
> http://myserver/one/twofoo One
> http://myserver/one/two/foo One
> http://myserver/two/one One
> http://myserver/two/onefoo One
> http://myserver/two/one/foo One
>
> It's the last three requests that are the problem. Because I'm hitting
> the '/two' location, I expect each of those examples to print "Two". But
> because they each have "one" in the URL, they all print "One"!
>
> Why is this? It seems to be acting like LocationMatch directives rather
> than Location. Could this be a bug in how the Perl sections work? If
> not, how do I get that last request to print "Two" instead of "One"?
> Even if it *is* a bug, how do I get the proper behavior?
>
> TIA,
>
> David
>
> --
> David Wheeler AIM: dwTheory
> [EMAIL PROTECTED] ICQ: 15726394
>Yahoo!: dew7e
>Jabber: [EMAIL PROTECTED]
>
Re: Perl Section Bug?
On Fri, 2002-02-01 at 18:56, David Wheeler wrote: > Why is this? It seems to be acting like LocationMatch directives rather > than Location. Could this be a bug in how the Perl sections work? If > not, how do I get that last request to print "Two" instead of "One"? > Even if it *is* a bug, how do I get the proper behavior? Okay, in a way, I've answered my own question. Prepending "^" to the front of each Location directive corrects the problem. However, I still think that this is a bug, because AFAIK, Location directives aren't supposed to use regular expressions unless they have the '~' character in them. I'm not sure how one would include that in Perl sections, but it seems better to require that Perl sections interpret Location directives as literal strings and LocationMatch directives as regular expressions Make sense? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.(sm)
Perl Section Bug?
Okay, let me try again.
I have a simple module I've written that demonstrates the problem. here
it is:
package MyTest;
our $VERSION = '0.1';
use Apache;
sub one {
print STDERR "One\n";
print STDOUT "One\n";
return Apache::OK;
}
sub two {
print STDERR "Two\n";
print STDOUT "Two\n";
return Apache::OK;
}
package Apache::ReadConfig;
use strict;
use warnings;
our $NameVirtualHost = '*:80';
our %VirtualHost = ('*:80' => {
ServerName => '_default_',
DocumentRoot => '/usr/local/apache/htdocs',
Location => {
'/one' => {
SetHandler => 'perl-script',
PerlHandler=> 'MyTest::one'
},
'/two' => {
SetHandler => 'perl-script',
PerlHandler=> 'MyTest::two'
}
}
});
Now, if I execute this from httpd.conf by simply calling
PerlModule MyTest
Here's what I get for my requests:
URL Prints
=== ==
http://myserver/one One
http://myserver/two Two
http://myserver/one/foo One
http://myserver/two/foo Two
http://myserver/one/two One
http://myserver/one/twofoo One
http://myserver/one/two/foo One
http://myserver/two/one One
http://myserver/two/onefoo One
http://myserver/two/one/foo One
It's the last three requests that are the problem. Because I'm hitting
the '/two' location, I expect each of those examples to print "Two". But
because they each have "one" in the URL, they all print "One"!
Why is this? It seems to be acting like LocationMatch directives rather
than Location. Could this be a bug in how the Perl sections work? If
not, how do I get that last request to print "Two" instead of "One"?
Even if it *is* a bug, how do I get the proper behavior?
TIA,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Final form of config code [Was: RE: What the heck actuallyhappens in a perl section?]
Thanks to those who helped out with this. Nobody quite got the case of
beer, but here's the final form, just in case anyone ever needs
something similar to this in the future. It's pretty ugly still (and I
know there are some better ways for some of this), but I could see it
being useful in ISP/hosting situations.
//Thomas
Thomas K. Burkholder
[EMAIL PROTECTED]
PerlInitHandler Apache::StatINC
PerlModule Apache::DBI
use IO::File;
use Data::Dump;
#use Apache::PerlSections ();
# convert this to per-user match later
while(my ($name,undef,undef,undef,undef,undef,undef,$dir) =
getpwent()) {
my $filename = "$dir/perl/mod_perl_setup";
my $file = IO::File->new("< $filename");
if ($file) {
my $inc = '';
$_ = <$file>;
s/(.*)\s*=\s*(.*)\s*$/$inc = "$1 $2"/e;
my $pv = '';
$_ = <$file>;
s/(.*)\s*=\s*(.*)\s*$/$pv = "$1 $2"/e;
while (<$file>) {
my ($key, $value);
s/(.*)\s*=\s*(.*)\s*$/($key, $value) = ($1,$2)/e;
# print "mapping $key to $value\n";
my %loc = (
PerlSetEnv => $inc,
PerlSetVar => $pv,
SetHandler => 'perl-script',
PerlHandler => $value
);
$Location{"$name/public_perl/$key"} = \%loc;
}
$file->close();
}
}
#print Apache::PerlSections->dump;
endpwent();
Re: What the heck actually happens in a perl section?
Geoffrey Young wrote
> I'm surprised that this works at all... what's in @kv at this point? if
> it's only two values then it might work if there is some magic behind the
> scenes, but generally you can't store references in PerlSetVars without
> having them stringified. Maybe PerlAddVar would work for you, though...
I found an example that did this almost exactly the way I did... then lost
the URL to the example. Anyway, replacing it with a string (so you only
ever get the last key-value pair in the file) works for defining the
variable (See new source appended).
> maybe something like Apache::Storage would help as well...
Looked at it, seemed too heavyweight for something that was just key=value.
> for general debugging see man Apache::PerlSections and the
> Apache::PerlSections->dump method. There's also an entire section on
> debugging sections in the Eagle book.
Don't have the Eagle book yet (buying it today). The PerlSections->dump
looks right according to the documentation on Apache::PerlSections - but I
still get the confused multiple loading problem - it's like a bunch of the
locations are all matching to the one location that generates mutliple
sub-frames.
Ok, the problem seemed to be that I had a bunch of keys '/areaj-foo' and one
key '/areaj' - and somehow, the Location match on just '/areaj' was
capturing all of them. I had a hunch and changed the key to 'areaj-areaj'
so that there wouldn't be any spurious matches, and it worked!
This *is* a bug, right? Location is supposed to be an exact match, isn't
it?
Geoff- thanks for the help. It wasn't quite 'full-case-of-beer' help, but I
definitely owe you one.
//Thomas
Thomas K. Burkholder
[EMAIL PROTECTED]
The code:
use IO::File;
use Data::Dump;
use Apache::PerlSections ();
# convert this to per-user match later
my $filename = "/home/burkhold/perl/PerlSetVar";
my $file = IO::File->new("< $filename");
my $str = '';
if ($file) {
my $ref;
while (<$file>) {
$ref=undef;
s/(\w+)\s*=\s*(.*)\s*$/$str = "$1 $2"/e;
}
$file->close();
}
my $mapping = getMapping();
my ($key, $value);
while (($key, $value) = each(%$mapping)) {
print "got $key = $value\n";
my %loc = (
PerlSetVar => $str,
SetHandler => 'perl-script',
PerlHandler => $value
);
$Location{$key} = \%loc;
}
print Apache::PerlSections->dump;
sub getMapping {
my $filename = "/home/burkhold/perl/mod_perl_mapping";
my $file = IO::File->new("< $filename");
my %result = ();
if ($file) {
while (<$file>) {
my ($key, $value);
s/(.*)\s*=\s*(.*)\s*$/($key, $value) = ($1,$2)/e;
print "mapping $key to $value\n";
$result{$key} = $value;
}
$file->close();
}
return \%result;
}
The data:
/home/burkhold/perl/mod_perl_mapping:
/areaj-areaj=AreaJ::AreaJ
/areaj-genpage=AreaJ::GenPage
/areaj-search=AreaJ::Search
/areaj-genimg=AreaJ::GenImage
/areaj-genfooter=AreaJ::GenFooter
/areaj-login=AreaJ::Login
/areaj-genlogin=AreaJ::GenLogin
/areaj-logout=AreaJ::Logout
/areaj-gensearch=AreaJ::GenSearch
/areaj-modmany=AreaJ::ModMany
/areaj-getpage=AreaJ::GetPage
/areaj-mark=AreaJ::Mark
/areaj-genpasswd=AreaJ::GenPasswd
/areaj-passwd=AreaJ::Passwd
/areaj-genmanageuser=AreaJ::GenManageUser
/areaj-selandredir=AreaJ::SelectAndRedirect
/areaj-genusertagtree=AreaJ::GenUserTagTree
/areaj-edit=AreaJ::EditImage
/areaj-gendelete=AreaJ::GenDelete
/areaj-delete=AreaJ::Delete
/areaj-genupload=AreaJ::GenUpload
/areaj-upload=AreaJ::Upload
/areaj-ensure=AreaJ::Ensure
/areaj-genheader=AreaJ::GenHeader
/areaj-gennewuser=AreaJ::GenNewUser
/areaj-newuser=AreaJ::NewUser
/home/burkhold/perl/PerlSetVar:
areajpassword=areaj
RE: What the heck actually happens in a perl section?
> -Original Message-
> From: Thomas K. Burkholder [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 17, 2001 6:40 AM
> To: [EMAIL PROTECTED]
> Subject: What the heck actually happens in a perl section?
>
>
> Hi again,
>
> I'm still beating my head against perl sections. Using PerlSetVar
> inside $Location seems really flaky - constants work,
> variables vanish.
> And using $Location{$key} = {...} causes odd spurious
> multiple-matching
> behaviour from a single matching hit. Frankly, I'm at a loss. I'm
> about ready to give up. Anyone have any clue what the heck
> really goes
> on inside sections? I will personally overnight-fedex
> a case of
> fine microbrewery beer with my compliments to anyone who can
> show me how
> to make this work. Really.
what is basically going on is that the contents of the section are
being read into the Apache::ReadConfig namespace which then inserts
Apache::ReadConfig globals into the Apache configuration.
>
>
> PerlSetEnv PERL5LIB /home/burkhold/perl/local/share/perl/5.6.0
> PerlInitHandler Apache::StatINC
> PerlModule Apache::DBI
> # this should be put in a LocationMatch
>
> use IO::File;
> use Data::Dump;
> # convert this to per-user match later
> my $filename = "/home/burkhold/perl/PerlSetVar";
> my $file = IO::File->new("< $filename");
> my @kv = ();
> if ($file) {
> while (<$file>) {
> s/(\w+)\s*=\s*(.*)\s*$/push @kv, "$1 $2"/e;
> }
> $file->close();
> }
> my $mapping = getMapping();
> my ($key, $value);
> # The following works
> # $Location{'/areaj'} = {
> # PerlSetVar => \@kv,
I'm surprised that this works at all... what's in @kv at this point? if
it's only two values then it might work if there is some magic behind the
scenes, but generally you can't store references in PerlSetVars without
having them stringified. Maybe PerlAddVar would work for you, though...
maybe something like Apache::Storage would help as well...
for general debugging see man Apache::PerlSections and the
Apache::PerlSections->dump method. There's also an entire section on
debugging sections in the Eagle book.
HTH
--Geoff
[snip]
What the heck actually happens in a perl section?
Hi again,
I'm still beating my head against perl sections. Using PerlSetVar
inside $Location seems really flaky - constants work, variables vanish.
And using $Location{$key} = {...} causes odd spurious multiple-matching
behaviour from a single matching hit. Frankly, I'm at a loss. I'm
about ready to give up. Anyone have any clue what the heck really goes
on inside sections? I will personally overnight-fedex a case of
fine microbrewery beer with my compliments to anyone who can show me how
to make this work. Really.
PerlSetEnv PERL5LIB /home/burkhold/perl/local/share/perl/5.6.0
PerlInitHandler Apache::StatINC
PerlModule Apache::DBI
# this should be put in a LocationMatch
use IO::File;
use Data::Dump;
# convert this to per-user match later
my $filename = "/home/burkhold/perl/PerlSetVar";
my $file = IO::File->new("< $filename");
my @kv = ();
if ($file) {
while (<$file>) {
s/(\w+)\s*=\s*(.*)\s*$/push @kv, "$1 $2"/e;
}
$file->close();
}
my $mapping = getMapping();
my ($key, $value);
# The following works
# $Location{'/areaj'} = {
# PerlSetVar => \@kv,
# SetHandler => 'perl-script',
# PerlHandler => 'AreaJ::AreaJ'
#}
# But this doesn't - I get strange, multiple-retry behaviour
# each location match seemingly generating many others
while (($key, $value) = each(%$mapping)) {
$Location{$key} = {
# This works:
# PerlSetVar => [[ areajpassword => areaj ]],
# This doesn't, even though \@kv is *identical* to above constant defn.
#PerlSetVar => \@kv,
SetHandler => 'perl-script',
PerlHandler => $value
}
}
sub getMapping {
my $filename = "/home/burkhold/perl/mod_perl_mapping";
my $file = IO::File->new("< $filename");
my %result = {};
if ($file) {
while (<$file>) {
my ($key, $value);
s/(.*)\s*=\s*(.*)\s*$/($key, $value) = ($1,$2)/e;
print STDERR "mapping $key to $value\n";
$result{$key} = $value;
}
$file->close();
}
return \%result;
}
mod_perl_mapping:
/areaj=AreaJ::AreaJ
/areaj-genpage=AreaJ::GenPage
/areaj-search=AreaJ::Search
/areaj-genimg=AreaJ::GenImage
/areaj-genfooter=AreaJ::GenFooter
/areaj-login=AreaJ::Login
/areaj-genlogin=AreaJ::GenLogin
/areaj-logout=AreaJ::Logout
/areaj-gensearch=AreaJ::GenSearch
/areaj-modmany=AreaJ::ModMany
/areaj-getpage=AreaJ::GetPage
/areaj-mark=AreaJ::Mark
/areaj-genpasswd=AreaJ::GenPasswd
/areaj-passwd=AreaJ::Passwd
/areaj-genmanageuser=AreaJ::GenManageUser
/areaj-selandredir=AreaJ::SelectAndRedirect
/areaj-genusertagtree=AreaJ::GenUserTagTree
/areaj-edit=AreaJ::EditImage
/areaj-gendelete=AreaJ::GenDelete
/areaj-delete=AreaJ::Delete
/areaj-genupload=AreaJ::GenUpload
/areaj-upload=AreaJ::Upload
/areaj-ensure=AreaJ::Ensure
/areaj-genheader=AreaJ::GenHeader
/areaj-gennewuser=AreaJ::GenNewUser
/areaj-newuser=AreaJ::NewUser
/home/burkhold/perl/PerlSetVar:
areajpassword=areaj
Re: Perl Section questions
On Wed, 31 May 2000, Kees Vonk 7249 24549 wrote:
> I have two questions about perl sections:
>
> 1) Has setting an entry in the %ENV hash in a perl section
>the same effect as using a SetEnv (or PerlSetEnv)
no, %ENV is cleared at startup, you need to use the *Env directives for
any you want to stick around.
>directive (What btw is the difference between SetEnv and
>PerlSetEnv, both seem to effect %ENV in the same way.)
SetEnv doesn't happen until the fixup phase, PerlSetEnv happens asap, so
those variables are available before then, e.g. in PerlAuthenHandler for
$ENV{ORACLE_HOME} + Apache::AuthenDBI
> 2) If the order of directives in a Location section matters
>(see recent discussion on Apache::PerlVINC), does that
>mean I cannot use Perl Sections to configure that because
>the order of hash keys is unreliable.
you can use:
$PerlConfig .= <httpd_conf(...);
to generate config that must have order preserved.
Perl Section questions
I have two questions about perl sections: 1) Has setting an entry in the %ENV hash in a perl section the same effect as using a SetEnv (or PerlSetEnv) directive (What btw is the difference between SetEnv and PerlSetEnv, both seem to effect %ENV in the same way.) 2) If the order of directives in a Location section matters (see recent discussion on Apache::PerlVINC), does that mean I cannot use Perl Sections to configure that because the order of hash keys is unreliable. Kees
Re: Perl Section...
w trillich ([EMAIL PROTECTED]) said something to this effect:
> > while($domain = $sth->fetchrow_array)
> > {
> > $PerlConfig .= <<"CONFIG";
> >
> > ServerName www.$domain
> > ServerAdmin webmaster@$domain
> > ServerAlias $domain
> > DocumentRoot $baseDir/www.$domain/htdocs/
> >
> >
> > CONFIG
> > }
>
> doesn't $sth->fetchrow_array() return a reference to an
> array, instead of a simple scalar?
> $row = $sth->fetchrow_array;
> foreach $col ( @$row ) { ... }
> ?
fetchrow_array returns a list. fetchrow_arrayref returns a list ref.
if you call fetchrow_array and are expecting one results ('select foo
from bar') you can assign it a scalar.
darren
--
To do nothing is to be nothing.
RE: Perl Section...
> -Original Message-
> From: w trillich [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 20, 2000 11:51 AM
> To: modperl
> Subject: Re: Perl Section...
>
>
> > while($domain = $sth->fetchrow_array)
> > {
> > $PerlConfig .= <<"CONFIG";
> >
> > ServerName www.$domain
> > ServerAdmin webmaster@$domain
> > ServerAlias $domain
> > DocumentRoot $baseDir/www.$domain/htdocs/
> >
> >
> > CONFIG
> > }
>
> doesn't $sth->fetchrow_array() return a reference to an
> array, instead of a simple scalar?
nope, that would be $sth->fetchrow_arrayref() ;)
> $row = $sth->fetchrow_array;
> foreach $col ( @$row ) { ... }
> ?
>
Re: Perl Section...
> while($domain = $sth->fetchrow_array)
> {
> $PerlConfig .= <<"CONFIG";
>
> ServerName www.$domain
> ServerAdmin webmaster@$domain
> ServerAlias $domain
> DocumentRoot $baseDir/www.$domain/htdocs/
>
>
> CONFIG
> }
doesn't $sth->fetchrow_array() return a reference to an
array, instead of a simple scalar?
$row = $sth->fetchrow_array;
foreach $col ( @$row ) { ... }
?
RE: Perl Section...
> -Original Message-
> From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 19, 2000 5:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Perl Section...
>
>
> I have $sth->finish in there right before the disconnect and it sill
> gives me the message. If it is just a warning message then there must
> be something else wrong. Is there something else that would cause it
> not to work. I gave mod_perl the "PERL_SECTIONS=1" option when I
> compiled it.
hmmm... the DBI code looks ok... my immediate suspicion is that something is
wrong with your here document (though it looks ok here) and your finish and
disconnect are getting slurped, so when $dbh goes out of scope and gets
cleaned up, you get the error... that would explain why your vhosts don't
show up as well. Of course, that's just a suspicion, and since it works on
another server, I'm probably wrong...
try adding
DBI->trace(6,"/path/to/trace_log");
before you connect and send me the trace file...
you also might want to echo $PerlConfig out and make sure it's being
populated properly (if you haven't already)
HTH
--Geoff
>
> Here is a small snippit of how my script works to set up the virtuals:
>
>
>
> use DBI;
>
> my $db = ;
> my $user = ;
> my $password = ;
> my $baseDir = ;
>
> my $dbh = DBI->connect($db, $user, $password) || die $DBI::errstr;
>
> my $sth = $dbh->prepare("SELECT domain FROM domain") || die
> $dbh->errstr;
> $sth->execute() || die $sth->errstr;
>
> my($domain);
> while($domain = $sth->fetchrow_array)
> {
> $PerlConfig .= <<"CONFIG";
>
> ServerName www.$domain
> ServerAdmin webmaster@$domain
> ServerAlias $domain
> DocumentRoot $baseDir/www.$domain/htdocs/
>
>
> CONFIG
> }
> $sth->finish;
> $dbh->disconnect;
>
>
>
> Again, it works fine on another machine with the apache rpm.
>
> Thanks,
> Bryan Opfer
>
>
> Geoffrey Young wrote:
> >
> > > -Original Message-
> > > From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 19, 2000 3:27 PM
> > > To: Modperl List
> > > Subject: Perl Section...
> > >
> > >
> > > Anyone know what this error would mean:
> > >
> > > DBI handle cleared whilst still active at
> > > /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195.
> > > dbih_clearcom (h 0x83b1900, com 0x81b6d50):
> > >FLAGS 0x211: COMSET Warn AutoCommit
> > >TYPE 1
> > >PARENT undef
> > >KIDS 0 (0 active)
> > >IMP_DATA undef in 'DBD::mysql::dr'
> >
> > this is a problem with your DBI script - it basically means
> that you still
> > have a cursor open when you disconnected...
> >
> > try calling $sth->finish before $dbh->disconnect - it
> should go away.
> >
> > at any rate, it's just a warning...
> >
> > --Geoff
> >
> > >
> > >
> > > This error comes up in my apache error log. I have a Perl
> > > section in my
> > > httpd.conf that sets up all my virtual hosts.
> > >
> > > Apache starts up fine, but the virtual hosts are not set
> up and I get
> > > that error in the error log. I am using Apache 1.3.12
> compiled from
> > > source.
> > >
> > > I have the same setup on another machine with Apache 1.3.9
> > > (RPM) and it
> > > works fine.
> > >
> > > DBI is version 1.13.
> > >
> > > Thanks,
> > > Bryan Opfer
> > >
>
Re: Perl Section...
I have $sth->finish in there right before the disconnect and it sill
gives me the message. If it is just a warning message then there must
be something else wrong. Is there something else that would cause it
not to work. I gave mod_perl the "PERL_SECTIONS=1" option when I
compiled it.
Here is a small snippit of how my script works to set up the virtuals:
use DBI;
my $db = ;
my $user = ;
my $password = ;
my $baseDir = ;
my $dbh = DBI->connect($db, $user, $password) || die $DBI::errstr;
my $sth = $dbh->prepare("SELECT domain FROM domain") || die
$dbh->errstr;
$sth->execute() || die $sth->errstr;
my($domain);
while($domain = $sth->fetchrow_array)
{
$PerlConfig .= <<"CONFIG";
ServerName www.$domain
ServerAdmin webmaster@$domain
ServerAlias $domain
DocumentRoot $baseDir/www.$domain/htdocs/
CONFIG
}
$sth->finish;
$dbh->disconnect;
Again, it works fine on another machine with the apache rpm.
Thanks,
Bryan Opfer
Geoffrey Young wrote:
>
> > -Original Message-
> > From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 19, 2000 3:27 PM
> > To: Modperl List
> > Subject: Perl Section...
> >
> >
> > Anyone know what this error would mean:
> >
> > DBI handle cleared whilst still active at
> > /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195.
> > dbih_clearcom (h 0x83b1900, com 0x81b6d50):
> >FLAGS 0x211: COMSET Warn AutoCommit
> >TYPE 1
> >PARENT undef
> >KIDS 0 (0 active)
> >IMP_DATA undef in 'DBD::mysql::dr'
>
> this is a problem with your DBI script - it basically means that you still
> have a cursor open when you disconnected...
>
> try calling $sth->finish before $dbh->disconnect - it should go away.
>
> at any rate, it's just a warning...
>
> --Geoff
>
> >
> >
> > This error comes up in my apache error log. I have a Perl
> > section in my
> > httpd.conf that sets up all my virtual hosts.
> >
> > Apache starts up fine, but the virtual hosts are not set up and I get
> > that error in the error log. I am using Apache 1.3.12 compiled from
> > source.
> >
> > I have the same setup on another machine with Apache 1.3.9
> > (RPM) and it
> > works fine.
> >
> > DBI is version 1.13.
> >
> > Thanks,
> > Bryan Opfer
> >
RE: Perl Section...
> -Original Message- > From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 19, 2000 3:27 PM > To: Modperl List > Subject: Perl Section... > > > Anyone know what this error would mean: > > DBI handle cleared whilst still active at > /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195. > dbih_clearcom (h 0x83b1900, com 0x81b6d50): >FLAGS 0x211: COMSET Warn AutoCommit >TYPE 1 >PARENT undef >KIDS 0 (0 active) >IMP_DATA undef in 'DBD::mysql::dr' this is a problem with your DBI script - it basically means that you still have a cursor open when you disconnected... try calling $sth->finish before $dbh->disconnect - it should go away. at any rate, it's just a warning... --Geoff > > > This error comes up in my apache error log. I have a Perl > section in my > httpd.conf that sets up all my virtual hosts. > > Apache starts up fine, but the virtual hosts are not set up and I get > that error in the error log. I am using Apache 1.3.12 compiled from > source. > > I have the same setup on another machine with Apache 1.3.9 > (RPM) and it > works fine. > > DBI is version 1.13. > > Thanks, > Bryan Opfer >
Perl Section...
Anyone know what this error would mean: DBI handle cleared whilst still active at /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195. dbih_clearcom (h 0x83b1900, com 0x81b6d50): FLAGS 0x211: COMSET Warn AutoCommit TYPE 1 PARENT undef KIDS 0 (0 active) IMP_DATA undef in 'DBD::mysql::dr' This error comes up in my apache error log. I have a Perl section in my httpd.conf that sets up all my virtual hosts. Apache starts up fine, but the virtual hosts are not set up and I get that error in the error log. I am using Apache 1.3.12 compiled from source. I have the same setup on another machine with Apache 1.3.9 (RPM) and it works fine. DBI is version 1.13. Thanks, Bryan Opfer
