Re: $ENV{'REMOTE_USER'} getting clobbered?
On Wed, Nov 28, 2001 at 04:31:07PM -0800, Kenny Smith wrote:
> Hello,
>
> I'm using mod_perl as a replacement for CGI. We are getting strange behavior
> where $ENV{'REMOTE_USER'} isn't being set correctly.
>
> The script is protected by an .htaccess type of authentication, so when I
> log in as 'kenny', $ENV{'REMOTE_USER'} should be equal to 'kenny'. However,
> every once in awhile, $ENV{'REMOTE_USER'} will be equal to someone else's
> login name, even though I'm still logged in as 'kenny' when I execute the
> script. Does that make sense?
>
> This system was working fine for 2 months or more, but recently the number
> of users and the load on the machine has increased, and we have started
> seeing the problem.
>
> My theory is that %ENV is shared between requests and user 'bob' is
> executing the script in the middle of my execution and $ENV{'REMOTE_USER'}
> is getting overwritten in my execution with 'bob'. I believe the script is
> taking longer to execute due to the load time which increases the window of
> opportunity for REMOTE_USER to be clobbered.
>
> Software involved:
>
> apache 1.3.12
> mod_perl 1.24
> solaris 5.7
> perl 5.005_03
I believe that we fixed an environment corruption bug (at least for the
DSO case, possibly static) sometime right after 1.24 was released.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
RE: %ENV & push_handlers
well, something isn't quite right... you aren't by chance using method
handlers are you?
at this point, you may want to post (some) code and/or the relevant snippet
from your httpd.conf.
using push_handlers with pnotes has never been a problem for me
# from some handler somewhere
$r->pnotes(foo => 'bar');
$r->push_handlers(PerlCleanupHandler => sub {
warn shift->pnotes('foo');
});
works no problemo...
--Geoff
-Original Message-
From: Terry Moran
To: Geoffrey Young
Sent: 6/27/01 7:57 PM
Subject: Re: %ENV & push_handlers
Geoff:
I really appreciate the help. I got a chance to play around some
more,
and it looks like this %ENV block is very specific to using
push_handlers,
and moreover that it's blocking pnotes & notes methods of the mod_perl
API
as well. I was thinking maybe it was a version thing, but I'm at
mod_perl
1.25, so that looks like it checks out. What I'm left with is getting a
work-around, and I have one. I'm just going to need to push_handler my
templating mod in order to give it the proper %ENV, or pnotes values (if
I
can find the time to translate into it that is, unfortunately an
important
part of design ;) ).
Anyhow, I get the feeling that push_handlers is somehow acting as a
subrequest - which would explain all of this. Not that I've found that
documented. I really appreciate the background on this - thanks!!!
Terry
Geoffrey Young wrote:
> sure...
>
> pnotes was documented after the eagle book was published, but it's my
> favorite method :)
>
> I dunno why %ENV is misbehaving - IIRC there were some reports in
older
> mod_perls, but I thought it was taken care of recently.
>
> at any rate, %ENV is a resource drain - you're better off with
pnotes.
> besides, they can hold references too, which makes life oh, so much
> better...
>
> my %hash;
> $r->pnotes(FOO => \%hash);
>
> my $href = $r->pnotes('FOO');
>
> --Geoff
>
> -Original Message-
> From: Terry Moran
> To: Geoffrey Young
> Sent: 6/27/01 3:51 PM
> Subject: Re: %ENV & push_handlers
>
> Geoff:
>
> Thanks so much for the fast response! My version of the Eagle Book
> doesn't even list that command, but it'll work like a charm. Just
leaves
> me wondering why %ENV jumps around like that...
>
> Thanks again!
>
> Terry
>
> Geoffrey Young wrote:
>
> > > -Original Message-
> > > From: Terry Moran [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, June 27, 2001 3:39 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: %ENV & push_handlers
> > >
> > >
> > > To all:
> > >
> > > I am putting together a site utilizing stacked handlers where
> the
> > > first of the modules uses the push_handlers call in order to
> > > dynamically
> > > choose a processing module. This 'pushed' handler then goes about
> > > processing the request & filling up the %ENV with information for
> the
> > > next in the stack to use to produce the actual page. However,
after
> a
> > > couple of hours of working with this set-up, I'm finding that
> > > nformation
> > > that is placed in the %ENV hash during the 'pushed' handler's
> > > processing
> > > stage are lost by the time the Templating module goes to look
> > > for them.
> > > Can anyone confirm that they've seen this, or can someone
> > > suggest a fix?
> > > I seem to be quite at a loss as to what to do...
> >
> > since you are already using $r->push_handlers use $r->pnotes instead
> of
> > %ENV.
> >
> > --Geoff
> >
RE: %ENV & push_handlers
> -Original Message- > From: Terry Moran [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 27, 2001 3:39 PM > To: [EMAIL PROTECTED] > Subject: %ENV & push_handlers > > > To all: > > I am putting together a site utilizing stacked handlers where the > first of the modules uses the push_handlers call in order to > dynamically > choose a processing module. This 'pushed' handler then goes about > processing the request & filling up the %ENV with information for the > next in the stack to use to produce the actual page. However, after a > couple of hours of working with this set-up, I'm finding that > nformation > that is placed in the %ENV hash during the 'pushed' handler's > processing > stage are lost by the time the Templating module goes to look > for them. > Can anyone confirm that they've seen this, or can someone > suggest a fix? > I seem to be quite at a loss as to what to do... since you are already using $r->push_handlers use $r->pnotes instead of %ENV. --Geoff
Re: %ENV via PerlTransHandler
On Wed, 21 Mar 2001, Paul Evad wrote:
> question: how does one access the environment variables when using
> mod_perl as a transhandler?
>
> I notice that
>
> $r->subprocess_env->do(sub {
> my($key, $value) = @_;
> $r->warn("$key => $value\n");
> 1;
>});
>
> gives two different sets of results when used via a transhandler or via
>
> PerlTransHandler Apache::Kudos::Test # yields near to nothing in subprocess_env
%ENV is normally not setup until later on, you can make it happen sooner
by calling subprocess_env in a void context:
$r->subprocess_env;
RE: %ENV via PerlTransHandler
-Original Message- From: Paul Evad To: [EMAIL PROTECTED] Sent: 3/21/01 1:36 PM Subject: %ENV via PerlTransHandler > >question: how does one access the environment variables when using >mod_perl as a transhandler? > what kind of stuff are you expecting HTTP_REFERER and company via PerlSetupEnv On? I'm not sure, but maybe this gets populated after translation (which might make sense since it is unknown that the file is a cgi script until after translation). haven't checked it, though, and I stopped relying on those long ago... --Geoff
RE: %ENV via PerlTransHandler
> question: how does one access the environment variables when using
> mod_perl as a transhandler?
[ SNIP transhandler vs content handler diffs ]
> Is there a better way to get at ENV stuff than subprocess_env?
The setup of %ENV is a convenience for CGI programmers. In fact, other than
loading/caching scripts, most of what Apache::Registry does is emulate the
CGI environment by setting up the %ENV hash and STDIN/STDOUT.
But the information that is placed into %ENV is all copied from the request
record (which is normally not available to CGI scripts), e.g.:
sub handler {
my $r = shift;
# $ENV{REMOTE_ADDR}
print $r->connection->remote_addr;
# $ENV{DOCUMENT_ROOT}
print $r->document_root;
# $ENV{REQUEST_URI}
print $r->uri;
}
These methods are all documented in the various mod_perl/Apache::*, plus the
guide, plus the Quick Reference card lists them.
Hope this helps!
L8r,
Rob
Re: %ENV
Geoffrey Young ([EMAIL PROTECTED]) said something to this effect on 03/15/2001:
> > Gene Dascher ([EMAIL PROTECTED]) said something to
> > this effect on 03/15/2001:
> > > Well, with the subprocess_env(), I can see the key that I
> > set in my cgi now,
> > > but the value that I set the key to is a Hash reference
> > that I need to use
> > > in my cgi. Unfortunately, all I get now is ENV{'TEST_VAR'} =
^^^
> > > HASH(0x860a278), and I can't pull my values out.
> >
> > I'm running into this as well, but with a different Apache::Table
> > object. It seems that Apache::Table stringifies its values, which
> > makes it useless for applications like this.
>
> pnotes is the way to go for non-string objects. It is simple (unlike the
> Data::Dumper example) and cleans itself up at the end of each request, which
> is nice.
I was under the impression (see the underlined piece above) that
the original idea was to be able to access the environment
variable from outside mod_perl, specifically in a CGI script. If
that is not the case, then pnotes is the best way to go.
(darren)
--
The glue that holds a Unix system together is the skilled human
being who understands how it works. The virtue of Unix is that it is
consistently understandable and configurable by anyone with a certain
minimum skillset
-- itsbruce (http://www.kuro5hin.org/?op=user&tool=info&uid=7232)
RE: %ENV
> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 15, 2001 8:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: %ENV
>
>
> Gene Dascher ([EMAIL PROTECTED]) said something to
> this effect on 03/15/2001:
> > Well, with the subprocess_env(), I can see the key that I
> set in my cgi now,
> > but the value that I set the key to is a Hash reference
> that I need to use
> > in my cgi. Unfortunately, all I get now is ENV{'TEST_VAR'} =
> > HASH(0x860a278), and I can't pull my values out.
>
> I'm running into this as well, but with a different Apache::Table
> object. It seems that Apache::Table stringifies its values, which
> makes it useless for applications like this.
Apache::Table stringifies all of its values becuase it is really a C
structure in Apache (or somesuch - I'm not a C guy). This is why notes()
(an Apache::Table object) can only hold string values and why pnotes is not
an Apache::Table object. The Eagle book explains it pretty well.
pnotes is the way to go for non-string objects. It is simple (unlike the
Data::Dumper example) and cleans itself up at the end of each request, which
is nice.
my %hash = ();
$r->pnotes(Foo => \%hash);
my $href = $r->pnotes('Foo');
my %old_hash = %$href;
HTH
--Geoff
Re: %ENV
Gene Dascher ([EMAIL PROTECTED]) said something to this effect on 03/15/2001:
> Well, with the subprocess_env(), I can see the key that I set in my cgi now,
> but the value that I set the key to is a Hash reference that I need to use
> in my cgi. Unfortunately, all I get now is ENV{'TEST_VAR'} =
> HASH(0x860a278), and I can't pull my values out.
I'm running into this as well, but with a different Apache::Table
object. It seems that Apache::Table stringifies its values, which
makes it useless for applications like this.
The only Apache piece that doesn't stringify is pnotes, which is
only available to Perl handlers.
Another option is:
my $value_to_save = {
a => 1,
b => 2,
c => [ 3, 4, 5 ],
};
my $d = Data::Dumper->new([ $value_to_save ]);
$d->Indent(0)->Purity(1)->Terse(1)->Deepcopy(1);
$r->subprocess_env('TEST_VAR' => $d->Dump);
And then in whatever you use the value in:
my $restored_value = eval $r->subprocess_env('TEST_VAL');
$r->subprocess_env('TEST_VAL') looks something like (as a string):
{"a" => 1,"b" => 2,"c" => [3,4,5]}
You could also use Storable, but that is not a part of the
default install like Data::Dumper is, so I avoid it if I can.
(darren)
--
Make no laws whatever concerning speech, and speech will be free; so soon
as you make a declaration on paper that speech shall be free, you will have
a hundred lawyers proving that "freedom does not mean abuse, nor liberty
license"; and they will define and define freedom out of existence.
-- Voltarine de Cleyre (19th Century French anarchist)
RE: %ENV
> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 15, 2001 7:19 AM
> To: modperl
> Subject: Re: %ENV
>
>
[snip]
> Try fiddling with $r->subprocess_env; I've had good results
> that way. e.g.:
>
> $r->subprocess_env('TEST_VAR', 1);
>
> I haven't tried using %ENV, but I was under the impression it was
> tied to the same internal Apache::Table object as
> $r->subprocess_env,
I don't think that is right, since that would mean that you could do
case-insensitive lookups on %ENV...
#!/usr/bin/perl
my $r = shift;
$ENV{Foo} = 'Foo';
$r->subprocess_env(Bar => 'Bar');
my $env_foo = $ENV{Foo};
my $env_bar = $ENV{BAR};
my $sp_foo = $r->subprocess_env('FOO');
my $sp_bar = $r->subprocess_env('BAR');
$r->send_http_header('text/plain');
print "env_foo is: $env_foo\n";
print "env_bar is: $env_bar\n";
print "sp_foo is: $sp_foo\n";
print "sp_bar is: $sp_bar\n";
yields:
env_foo is: Foo
env_bar is:
sp_foo is:
sp_bar is: Bar
< which means that setting $ENV{'TEST_VAR'}
> should work as well.
that's right, though :)
If you are going to get $r anyway, you are better off using pnotes() to
stash stuff, since it takes less overhead than populating %ENV with
subprocess_env().
--Geoff
>
> Make sure you are setting this in the parent request, if you are
> in a subrequest:
>
> $r = ($r->is_main) ? $r : $r->main;
>
> (darren)
> --
> The world is coming to an end! Repent and return those library books!
>
RE: %ENV
Well, with the subprocess_env(), I can see the key that I set in my cgi now,
but the value that I set the key to is a Hash reference that I need to use
in my cgi. Unfortunately, all I get now is ENV{'TEST_VAR'} =
HASH(0x860a278), and I can't pull my values out.
Thanks for the help; it looks like we are headed in the right direction.
Now, is there any way to set an ENV key to a hash or hash reference and use
that later on in a cgi program?
Thanks,
Gene
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 15, 2001 6:19 AM
To: modperl
Subject: Re: %ENV
Gene Dascher ([EMAIL PROTECTED]) said something to this effect on
03/15/2001:
> Is the ENV hash sanitized and repopulated between the time the Perl*Auth
> handlers are run and the requested cgi is executed? I am setting an ENV
key
> in one of my handlers that I'd like to use in a cgi that resides in a
> protected directory. Is it possible to retain that variable throughout
the
> entire process, or will it always get wiped out?
>
> Example:
> I use my browser to call a cgi that is in a protected directory. In the
> PerlAuthenHandler, I set $ENV{'TEST_VAR'} = 1. I can pull the value of
> $ENV{'TEST_VAR'} in the PerlAuthzHandler, but when I try and fetch the
value
> in the cgi that I called, the key 'TEST_VAR' does not exist.
Try fiddling with $r->subprocess_env; I've had good results that way. e.g.:
$r->subprocess_env('TEST_VAR', 1);
I haven't tried using %ENV, but I was under the impression it was
tied to the same internal Apache::Table object as
$r->subprocess_env, which means that setting $ENV{'TEST_VAR'}
should work as well.
Make sure you are setting this in the parent request, if you are
in a subrequest:
$r = ($r->is_main) ? $r : $r->main;
(darren)
--
The world is coming to an end! Repent and return those library books!
Re: %ENV
Gene Dascher ([EMAIL PROTECTED]) said something to this effect on 03/15/2001:
> Is the ENV hash sanitized and repopulated between the time the Perl*Auth
> handlers are run and the requested cgi is executed? I am setting an ENV key
> in one of my handlers that I'd like to use in a cgi that resides in a
> protected directory. Is it possible to retain that variable throughout the
> entire process, or will it always get wiped out?
>
> Example:
> I use my browser to call a cgi that is in a protected directory. In the
> PerlAuthenHandler, I set $ENV{'TEST_VAR'} = 1. I can pull the value of
> $ENV{'TEST_VAR'} in the PerlAuthzHandler, but when I try and fetch the value
> in the cgi that I called, the key 'TEST_VAR' does not exist.
Try fiddling with $r->subprocess_env; I've had good results that way. e.g.:
$r->subprocess_env('TEST_VAR', 1);
I haven't tried using %ENV, but I was under the impression it was
tied to the same internal Apache::Table object as
$r->subprocess_env, which means that setting $ENV{'TEST_VAR'}
should work as well.
Make sure you are setting this in the parent request, if you are
in a subrequest:
$r = ($r->is_main) ? $r : $r->main;
(darren)
--
The world is coming to an end! Repent and return those library books!
RE: env in background process
Thanks for looking at it.
I prefer "%ENV = ();" in PerlCleanupHandler handler. (as i don't have to
modify so many scripts).
I don't think it has any negative effect ...
-Niraj
> -Original Message-
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 26, 2000 3:32 PM
> To: Niraj Sheth
> Cc: [EMAIL PROTECTED]
> Subject: RE: env in background process
>
>
> On Tue, 15 Aug 2000, Niraj Sheth wrote:
>
> > so why dump_env is getting both?
> > If I either uncomment "local %ENV = %ENV;" in script or put
> "%ENV = ();"
> > in PerlCleanupHandler then dump_env is working fine.
> > I tried both Apache::PerlRun and Apache::Registry which same result.
>
> oh whoops, you did send a test case. i think the problem is
> that mod_perl
> only clears the Perl side of %ENV, so the underlying C
> environ array is
> not modified. if we do that than other problems pop up. the best
> approach for the moment is to use:
>
> local $ENV{FOO1} = 'foo1';
>
> print `dump_env`;
>
RE: env in background process
On Tue, 15 Aug 2000, Niraj Sheth wrote:
> so why dump_env is getting both?
> If I either uncomment "local %ENV = %ENV;" in script or put "%ENV = ();"
> in PerlCleanupHandler then dump_env is working fine.
> I tried both Apache::PerlRun and Apache::Registry which same result.
oh whoops, you did send a test case. i think the problem is that mod_perl
only clears the Perl side of %ENV, so the underlying C environ array is
not modified. if we do that than other problems pop up. the best
approach for the moment is to use:
local $ENV{FOO1} = 'foo1';
print `dump_env`;
Re: env in background process
On Mon, 14 Aug 2000, Niraj Sheth wrote:
> Hi,
>
> I am having very strange problem with environment variables.
>
> >From Apache::PerlRun script(cgi) I am setting env and firing background
> process ..
> system("$command &") (or print `$command &`;)
>
> now looks like environment variable being persistence b/w different
> requests ONLY in background process. so it's looks to me that mod_perl
> is setting proper "Perl Level" env but failing to reset env at "c level"
> or "process level". I know it's sounds very weird.
> /perl-status?env is printing correctly but my background process
> ($command) is printing few extra env, which i set it in different cgi
> script.
>
> e.g. "script1.pl" is setting $ENV{foo1} = "foo1" and firing print
> `command1 &`;
> and "script2.pl" is setting $ENV{foo2} = "foo2" and firing print
> `command2 &`;
>
> after few hits both env(foo1 and foo2) are visible to both background
> processes.
> while /perl-status?env is displaying correctly.
> Here command1 and command2(perl scripts) are just printing env
>
> Apache/1.3.9 (Unix) mod_perl/1.21
with the test case below, i get the expected results:
env is missing MOD_PERL
all of %ENV should be inherited except for this one. if you have a
small test case that i can drop in and run (small like the one below),
i'll take a look.
my $r = shift;
$r->send_http_header;
local $ENV{PATH} = '/usr/bin';
$ENV{PACKAGE} = __PACKAGE__;
my @env = `env`;
my %env;
for (@env) {
chomp;
my($k,$v) = split '=';
$env{$k} = $v;
}
while (my($k,$v) = each %ENV) {
next if exists $env{$k};
print "env is missing $k\n";
}
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affectsmod_cgi scripts
On Tue, 6 Jun 2000, Ben Cohen wrote:
> This was certainly a weird bug ( I think it was a bug ).
> Even setting PerlSetEnv in httpd.conf didn't help.
> The PATH would be properly set until the first time a mod_perl
> script modified its PATH at which point all other
> scripts including mod_cgi scripts would 'inherit' this
> new PATH.
you should be able to cure this simply by localizing:
local $ENV{PATH} = "/bin:/usr/local/bin";
is that not the case?
RE: env in background process
On Wed, 23 Aug 2000, Sheth, Niraj wrote: > Didn't get any reply yet on this, so I think i am doing something very > stupid ... i'm still catching up with plenty of unanswered mail in my modperl mailbox, including yours, doing the best i can.
RE: env in background process
Didn't get any reply yet on this, so I think i am doing something very
stupid ...
Can anyone try it and tell me if gets the same result?
Thanks,
Niraj
> -Original Message-
> From: Niraj Sheth [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 15, 2000 11:03 AM
> To: [EMAIL PROTECTED]
> Subject: RE: env in background process
>
>
> Follow up on this.
>
> script1.pl(set FOO1 env)
> ===
> #!/usr/local/bin/perl
>
> print "Content-type: text/html\n\n";
> print "PID = $$\n";
> print "SCRIPT1 with FOO1\n";
>
> #local %ENV = %ENV;
>
> $ENV{FOO1} = "foo1";
> print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;
>
> $command = "dump_env";
> print `$command &`; # put it in the background
>
> -- end
>
> script2.pl(set FOO2 env)
> ===
> #!/usr/local/bin/perl
>
> print "Content-type: text/html\n\n";
> print "PID = $$\n";
> print "SCRIPT1 with FOO2\n";
>
> #local %ENV = %ENV;
>
> $ENV{FOO2} = "foo2";
> print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;
>
> $command = "dump_env";
> print `$command &`; # put it in the background
>
> -- end
>
> dump_env
> ===
> #!/usr/local/bin/perl
>
> print "$0 @ARGV\n";
>
> print map { "$0 $_ = $ENV{$_}\n"; } sort keys %ENV;
>
> --end
>
> running "httpd -X" i will get FOO1 and FOO2 both from the print
> statement of dum_env.
> while script1.pl is ONLY printing FOO1 which is correct as well as
> script2.pl is ONLY printing FOO2 which is also correct.
>
> so why dump_env is getting both?
> If I either uncomment "local %ENV = %ENV;" in script or put
> "%ENV = ();"
> in PerlCleanupHandler then dump_env is working fine.
> I tried both Apache::PerlRun and Apache::Registry which same result.
>
> I would appreciate any help.
>
> -Niraj
>
> > -Original Message-
> > From: Niraj Sheth [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 14, 2000 12:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: env in background process
> >
> >
> > Hi,
> >
> > I am having very strange problem with environment variables.
> >
> > >From Apache::PerlRun script(cgi) I am setting env and firing
> > background
> > process ..
> > system("$command &") (or print `$command &`;)
> >
> > now looks like environment variable being persistence b/w different
> > requests ONLY in background process. so it's looks to me
> that mod_perl
>
> > is setting proper "Perl Level" env but failing to reset env
> > at "c level"
> > or "process level". I know it's sounds very weird.
> > /perl-status?env is printing correctly but my background process
> > ($command) is printing few extra env, which i set it in
> different cgi
> > script.
> >
> > e.g. "script1.pl" is setting $ENV{foo1} = "foo1" and firing print
> > `command1 &`;
> > and "script2.pl" is setting $ENV{foo2} = "foo2" and firing print
> > `command2 &`;
> >
> > after few hits both env(foo1 and foo2) are visible to both
> background
> > processes.
> > while /perl-status?env is displaying correctly.
> > Here command1 and command2(perl scripts) are just printing env
> >
> > Apache/1.3.9 (Unix) mod_perl/1.21
> > Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
> > Platform:
> > osname=solaris, osvers=2.6, archname=sun4-solaris
> > uname='sunos nlsun268 5.6 generic_105181-14 sun4u sparc
> > sunw,ultra-4
> > '
> > hint=recommended, useposix=true, d_sigaction=define
> > usethreads=undef useperlio=undef d_sfio=undef
> > Compiler:
> > cc='gcc', optimize='-O', gccversion=2.8.1
> > cppflags='-I/usr/local/include'
> > ccflags ='-I/usr/local/include'
> > stdchar='unsigned char', d_stdstdio=define, usevfork=false
> > intsize=4, longsize=4, ptrsize=4, doublesize=8
> > d_longlong=define, longlongsize=8, d_longdbl=define,
> > longdblsize=16
> > alignbytes=8, usemymalloc=y, prototype=define
> > Linker and Libraries:
> > ld='gcc', ldflags =' -L/usr/local/lib'
> > libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
> > libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
> > libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
> > Dynamic Linking:
> > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> > cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
> >
> >
> > Any comments?
> >
> > Thanks,
> > Niraj
> >
>
RE: env in background process
Follow up on this.
script1.pl(set FOO1 env)
===
#!/usr/local/bin/perl
print "Content-type: text/html\n\n";
print "PID = $$\n";
print "SCRIPT1 with FOO1\n";
#local %ENV = %ENV;
$ENV{FOO1} = "foo1";
print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;
$command = "dump_env";
print `$command &`; # put it in the background
-- end
script2.pl(set FOO2 env)
===
#!/usr/local/bin/perl
print "Content-type: text/html\n\n";
print "PID = $$\n";
print "SCRIPT1 with FOO2\n";
#local %ENV = %ENV;
$ENV{FOO2} = "foo2";
print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;
$command = "dump_env";
print `$command &`; # put it in the background
-- end
dump_env
===
#!/usr/local/bin/perl
print "$0 @ARGV\n";
print map { "$0 $_ = $ENV{$_}\n"; } sort keys %ENV;
--end
running "httpd -X" i will get FOO1 and FOO2 both from the print
statement of dum_env.
while script1.pl is ONLY printing FOO1 which is correct as well as
script2.pl is ONLY printing FOO2 which is also correct.
so why dump_env is getting both?
If I either uncomment "local %ENV = %ENV;" in script or put "%ENV = ();"
in PerlCleanupHandler then dump_env is working fine.
I tried both Apache::PerlRun and Apache::Registry which same result.
I would appreciate any help.
-Niraj
> -Original Message-
> From: Niraj Sheth [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 14, 2000 12:10 PM
> To: [EMAIL PROTECTED]
> Subject: env in background process
>
>
> Hi,
>
> I am having very strange problem with environment variables.
>
> >From Apache::PerlRun script(cgi) I am setting env and firing
> background
> process ..
> system("$command &") (or print `$command &`;)
>
> now looks like environment variable being persistence b/w different
> requests ONLY in background process. so it's looks to me that mod_perl
> is setting proper "Perl Level" env but failing to reset env
> at "c level"
> or "process level". I know it's sounds very weird.
> /perl-status?env is printing correctly but my background process
> ($command) is printing few extra env, which i set it in different cgi
> script.
>
> e.g. "script1.pl" is setting $ENV{foo1} = "foo1" and firing print
> `command1 &`;
> and "script2.pl" is setting $ENV{foo2} = "foo2" and firing print
> `command2 &`;
>
> after few hits both env(foo1 and foo2) are visible to both background
> processes.
> while /perl-status?env is displaying correctly.
> Here command1 and command2(perl scripts) are just printing env
>
> Apache/1.3.9 (Unix) mod_perl/1.21
> Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
> Platform:
> osname=solaris, osvers=2.6, archname=sun4-solaris
> uname='sunos nlsun268 5.6 generic_105181-14 sun4u sparc
> sunw,ultra-4
> '
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef useperlio=undef d_sfio=undef
> Compiler:
> cc='gcc', optimize='-O', gccversion=2.8.1
> cppflags='-I/usr/local/include'
> ccflags ='-I/usr/local/include'
> stdchar='unsigned char', d_stdstdio=define, usevfork=false
> intsize=4, longsize=4, ptrsize=4, doublesize=8
> d_longlong=define, longlongsize=8, d_longdbl=define,
> longdblsize=16
> alignbytes=8, usemymalloc=y, prototype=define
> Linker and Libraries:
> ld='gcc', ldflags =' -L/usr/local/lib'
> libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
> libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
> libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
>
>
> Any comments?
>
> Thanks,
> Niraj
>
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affectsmod_cgi scripts
On Tue, 6 Jun 2000, Ben Cohen wrote:
> Thanks to all for the helpful suggestions.
>
> Gunther Birzniek from the list suggested a solution that I've
> now tried and it works perfectly:
>
>
> {begin quote}
>
> I assume you are running with Apache:Registry?
>
> You could also save off the $ENV{PATH}...
>
>
> Go to the line that reads:
>
> eval { &{$cv}($r, @_) } if $r->seqno;
Ugh... Hate that syntax - can we patch it to:
eval { $cv->($r, @_) } if $r->seqno;
It's so much less cryptic.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
Ben Cohen writes:
> Go to the line that reads:
>
> eval { &{$cv}($r, @_) } if $r->seqno;
I love perl :)
Dirk
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
[EMAIL PROTECTED] (Ben Cohen) wrote:
>{begin quote}
>
>I assume you are running with Apache:Registry?
>
>You could also save off the $ENV{PATH}...
>
>
>Go to the line that reads:
>
> eval { &{$cv}($r, @_) } if $r->seqno;
>
>
>And before it have something like
>
>$ENV{OLD_PATH} = $ENV{PATH}
>
>and after it
>
>$ENV{PATH} = $ENV{OLD_PATH}
>
>
>{end quote}
A better solution would be to do "local $ENV{PATH} = $ENV{PATH};". Let
Perl clean up after you, especially if your script dies in mid-run.
The same technique is used for $^W in RegistryNG.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
Thanks to all for the helpful suggestions.
Gunther Birzniek from the list suggested a solution that I've
now tried and it works perfectly:
{begin quote}
I assume you are running with Apache:Registry?
You could also save off the $ENV{PATH}...
Go to the line that reads:
eval { &{$cv}($r, @_) } if $r->seqno;
And before it have something like
$ENV{OLD_PATH} = $ENV{PATH}
and after it
$ENV{PATH} = $ENV{OLD_PATH}
{end quote}
This was certainly a weird bug ( I think it was a bug ).
Even setting PerlSetEnv in httpd.conf didn't help.
The PATH would be properly set until the first time a mod_perl
script modified its PATH at which point all other
scripts including mod_cgi scripts would 'inherit' this
new PATH.
The reason the mod_perl script modifying its path was to appease
the perl taint checking and help ensure a more secure environment.
I could be totally mistaken in doing this and for some strange
reason mod_perl scripts in my install seem to run with taint checking
on by default.
Thanks again to all those who responded with very
helpful suggestions,
-Ben
--
DO NOT LOOK INTO LASER
WITH REMAINING EYE
(random sig #14)
Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
On Sun, 4 Jun 2000, Ben Cohen wrote:
> The problem is that when a mod_perl script modifies the PATH
> environment variable, this change seems to become global and
> affects even plain old mod_cgi scripts.
While I also wonder (as another respondent did) why a mod_perl script would
need to alter its 'PATH', I can think of a couple solutions that might work:
Probably the simplest is to localize your $ENV{'PATH'} changes
(i.e. local $ENV{'PATH'} = '/bin:/usr/bin' ) in your code.
More complicated and less nice solution:
Write a FixupHandler that sets the PATH to some 'clean' value.
Something like this:
sub handler {
my $r = shift;
$ENV{'PATH'} = '/bin:/usr/bin';
$r->subprocess_env('PATH', $ENV{'PATH'}); # just to be sure mod_cgi gets it
return DECLINED;
}
...and then have it triggered by a in your httpd.conf.
Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
| I know that the old CGI scripts probably shoudn't rely on PATH
| but they do and there are too many to fix right away.
To rely on $ENV{PATH} is one thing. But why would a mod_perl script ever
need to *change* it?
Ime
