Re: PerlTransHandler
On Tue, 19 Oct 1999, Mark Cogan wrote:
> >> On Tuesday, October 19, 1999 4:13 AM, William Deegan
> [SMTP:[EMAIL PROTECTED]] wrote:
> >> > How can I change the environment variables that get passed to a perl
> >> > script running under Apache::Registry from a PerlTransHandler?
> >> >
> >> > I'm using the PerlTransHandler to do a sort of dynamic mod_rewrite
> >> > functionality.
[...]
> Use the %ENV hash in perl. The environment is shared between the whole
> request, so setting $ENV{whatever} in the PerlTransHandler will make it
> visible to the content handler down the line.
I'd suggest using $r->subprocess_env() instead.
We have a somewhat similar situation where we have a PerlTransHandler
that sets certain environment variables that CGI scripts depend on
(yes, plain mod_cgi while we have mod_perl -- but that's another story).
I guess %ENV will work in many situations, but it might bite you later
when you can't figure out why a particular env variable isn't getting set
in certain situations (speaking from experience).
See the explanation on pages 454-455 in the Eagle book.
Problems with dynamically-loaded perl modules under Solaris 2.5.1
I'm having problems with modules that use DynaLoader (Data::Dumper and Storable, specifically) under mod_perl on Solaris machines. These modules work fine in standalone scripts, or when run under mod_cgi or mod_fastcgi, but as soon as I put a "use Storable" in a mod_perl handler, I get this in my error log: [Tue Oct 26 11:21:33 1999] [error] Can't load '/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so' for module Storable: ld.so.1: ./httpd: fatal: relocation error: file /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. BTW I get an identical message if I put a "use Storable" inside a section in my httpd.conf. After searching the mailing list archive, I see that this sort of thing can happen if mod_perl was compiled against the "wrong" version of perl on the system. So just to make sure, I removed all remnants of an older 5.004 install, remade mod_perl, and I'm still getting the errors. My setup: Solaris 2.5.1 (Sparc) gcc 2.95 perl 5.005_03 (compiled with above gcc, as were the below) apache 1.3.9 (with all modules compiled statically) mod_perl 1.21 (EVERYTHING=1) mod_fastcgi 2.2.2 I'm not having this problem with an otherwise nearly identical setup under Redhat Linux 5.x (the differences being OS, of course, and gcc 2.7.2.3). Any help appreciated.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Wed, 27 Oct 1999, Francesc Guasch wrote: > what's the ld version you use ?, make sure you compiled perl using the > solaris hints you can find in the perl sources. I've got GNU ld 2.9.1, but the perl Configure said GNU ld won't build perl, so it used /usr/ccs/bin/ld (version 3.0). I compiled perl using all the "solaris_2" hints except I chose NOT to use perl's malloc. Just to restate this, everything works wonderfully otherwise with this version of perl. It's only a problem when I do something like "use Data::Dumper;" inside a mod_perl handler. Update: I downgraded to perl 5.004_05, and suddenly everything works. I'd like to use 5.005_03 though. Any clues?
hostname sanitation in PerlTransHandler or anywhere else
We use a TransHandler to (among other things) manage name-based virtual
hosts (simply put, given the incoming Host: header plus URI, map to a file).
We (of course) sanitize the incoming URI and Host. It works fine.
I "save" the sanitized hostname like so:
$r->header_in('Host',$host);
$r->subprocess_env('SERVER_NAME',$host);
$r->parsed_uri->hostname($host);
I used to use just the first line, but I added the other two thinking
they might fix our problems...
First problem (somewhat minor):
$ENV{'SERVER_NAME'} remains "unsanitized" (i.e., it's still exactly what
the client sent in the "Host:" header). This is not a big deal because the
sanitized host gets set properly in $ENV{'HTTP_HOST'}. Scripts can just
use that variable instead.
Second problem (bigger):
For logging, we use CLF with the virtual host name tacked on the front
of the line (using %V in the LogConfig). Yes we have "UseCanonicalName On"
and I've read http://apache.org/docs/mod/core.html#usecanonicalname so I
know that %V and SERVER_NAME get set to whatever the client sends.
(and I can't turn it off, because then %V is always ServerName, and
suddenly no "virtual hosts").
I experimented by putting the host sanitation in a PostReadRequestHandler.
Same results. I thought this phase was "...where you can examine HTTP
headers and change them before Apache gets a crack at them" (TPJ #9, p.6).
Here's the relevant bit of Apache code (1.3.9) in http_core.c in the
ap_get_server_name() function:
if (d->use_canonical_name == USE_CANONICAL_NAME_OFF) {
return r->hostname ? r->hostname : r->server->server_hostname;
}
There's no $r->hostname method in mod_perl that I can find, and
unfortunately $r->server->server_hostname is read-only.
I can only think of a couple options: hack http_core.c to do what I want,
or write a custom LogHandler that uses the sanitized host.
Is there any other way?
PS: I'd still like to hear from anyone who is running mod_perl on
Solaris 2.5.1 with Perl 5.005_03 -- I don't want to stick with 5.004 forever.
Re: hostname sanitation in PerlTransHandler or anywhere else
On Fri, 29 Oct 1999, I wrote: > I can only think of a couple options: hack http_core.c to do what I want, > or write a custom LogHandler that uses the sanitized host. We've decided on another option: if you're sending a Host: header that needs "sanitation," then either 1) you're trying to run some kind of "exploit" or 2) you're using a very broken browser. We're going to just punt and send you a 404 right there. The end. BTW, it was a broken client calling itself "NetAttache/2.5" that started this whole thing.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
I did some experimenting with my Solaris2.5.1/mod_perl/Data::Dumper/Storable problem that I wrote about last week. A grid: | mod_perl 1.21 | 1.21-dev (19991101174047) -+---+-- perl5.004_05 | works fine| didn't try perl5.005_03 | doesn't work | doesn't work perl5.005_62 | won't compile | works fine! All versions of perl compiled with all solaris hints. So is this a 5.005_03-specific bug? Any word on 5.005_04?
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Mon, 13 Dec 1999, Doug MacEachern wrote: > are you still stuck on this? Yes. To reiterate: Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. Everything works fine EXCEPT when I try to "use" a dynamically loaded module (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no trouble using these modules in regular perl scripts, mod_cgi scripts, or mod_fastcgi scripts. > did you link mod_perl static or dso? if dso, try static. All of my Apache modules are compiled statically. > you can also try configuring Perl with -Dusemymalloc=n, > but that comes with a large performance hit. I've tried it both ways, using perl's malloc or Solaris', and both give me the same result in my error logs: [Tue Dec 14 08:36:01 1999] [error] Can't load '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so' for module Data::Dumper: ld.so.1: /usr/local/web/bin/httpd: fatal: relocation error: symbol not found: main: referenced in /usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. All I need to do is add "use Data::Dumper;" in a handler to trigger this. And as I mentioned in my previous messages, this same setup works fine under Linux and FreeBSD. I can also get the problem to go away on Solaris by downgrading perl to 5.004_05 or upgrading it to 5.005_62. A co-worker who understands Perl internals better than I do seems to have tracked it down to a problem with Dynaloader's dlopen() call, though looking at ext/Dynaloader/dl_dlopen.xs in the various Perl sources there have apparently been no changes to it since 1994(?!). So maybe the problem lies elsewhere. Perl has caused my C skills to atrophy so we're getting into territory I don't really understand. Would something like gdb help diagnose the problem?
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Thu, 16 Dec 1999, Eugene Miretskiy wrote: > Recently I experienced similar problems on Solaris. > > I had to rebuild perl as shared libperl.so Perl library for mod_perl > to work -- see perl intall manpages. Thanks! This appears to have fixed my problem (though it may have broken CPAN.pm -- it keeps saying "Package comes without Makefile.PL" even though it does -- but this is off-topic -- forget I even mentioned it). "Compile statically" is like a mantra* on this list (at least when it comes to apache modules), so it never occurred to me that building perl itself like this would work better than the static build. * another mantra of course being "don't use Redhat's prebuilt RPMs"
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Tue, 21 Dec 1999, Doug MacEachern wrote: > this sounds an awful lot like the common solaris linker vs. gnu linker > problem. what does 'perl -V:ld' say your linker is? make sure it's gnu > (gcc) and that Apache is using the same. $ perl -V:ld ld='gcc'; What I don't understand is that when I "./Configure" perl it always says: NOTE: You are using GNU ld(1). GNU ld(1) will not build Perl. I'm arranging to use /usr/ccs/bin/ld by including -B/usr/ccs/bin/ in your gcc -B/usr/ccs/bin/ command. (Note that the trailing "/" is required.) ...so it tells me that it can't use GNU ld, and then does it anyway, apparently. Perl's Configure script also warns me that my GNU make has its set-GID bit set and I should remove it. So I "chmod 755 make". Then I get: *** WHOA THERE!!! *** Your C compiler "gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/" doesn't seem to be working! You'd better start hunting for one and let me know about it. This topic is veering away from mod_perl (though the problem only manifests itself under mod_perl for me), so I'm going back to the libperl.so solution suggested earlier since that seems to work. Whatever the problem is, it appears to be fixed in the development version of Perl at least.
Re: Finding if SSL is enabled on backend ..
On Thu, 6 Jan 2000, Joseph R. Junkin wrote: > Actually, I am wrong, the HTTP_REFERER is the previous referring > document, not the current URL so this does not solve my problem. Again, > if anyone knows a way to determine if SSL is activated on the backend, > please let me know. > > > > Hi all, > > > I have a two machine setup: > > > (A) A frontend running mod_ssl, mod_rewrite and mod_proxy. > > > (B) A backend mod_perl machine server not running SSL that is > > > proxypassed to from the frontend > > > > > > Problem: I need to know within my mod_perl backend server whether or not > > > SSL is active on the frontend, because if not I won't permit login. > > > > > > So how can I find out from the backend server (B) whether or not the > > > frontend (A) is running in SSL? I dealt with a situation somewhat like this recently. The first problem would be that even though you are encrypting between the client and the front-end proxy, your communication between proxy and backend is in the clear which sort of defeats the purpose of SSL. If you're certain that nobody can sniff your local network, then I guess you can overlook this, but I wouldn't take any chances. What we ended up trying (I should note here that we don't have this system in production yet, so keep that in mind) was to have the frontend machine set up an encrypted link to the backend through ssh port forwarding. First we start an ssh that forwards the fronend's localhost:80 to the backend's localhost:80. Then have the frontend SSL server ProxyPass everything to localhost:80 and then have the backend only allow connections from localhost. Look at the ssh man page and learn about its -L and -R options if this doesn't make sense. I suppose you could have your frontend server, say, insert a magic header that says "hey, I'm running SSL", but you can't trust anything you get from incoming headers (including HTTP_REFERER). Forget I even suggested it.
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: Simple program _setting_ REMOTE_ADDR - SOLUTION
On Fri, 23 Jun 2000, Steve van der Burg wrote:
> Taking your remote_ip hint, and reading the Eagle a bit more closely,
> I came up with this:
>
> In httpd.conf:
>
>
> PerlAccessHandler LHSC::FakeRemoteIP
>
Why an Access handler? I realize it works, but a more appropriate
phase would be PerlFixupHandler, since you aren't doing any access
control in your module. A couple other nitpicky points: you probably
should return 'DECLINED' at the end, not 'OK', in case there are more
handlers that want to do something during that phase and it also probably
would be a good idea to restore the "real" address after so your logs
show the actual client IP. Something like this:
package FakeIP;
use strict;
use Apache::Constants 'DECLINED';
sub handler {
my $r = shift;
$r->notes('true_client_ip', $r->connection->remote_ip);
$r->connection->remote_ip('1.2.3.4');
$r->push_handlers('PerlLogHandler' =>
sub {
my $r = shift;
$r->connection->remote_ip($r->notes('true_client_ip'));
return DECLINED;
}
);
return DECLINED;
}
1;
Re: Reading config
On Mon, 19 Jun 2000, Matt Sergeant wrote: > On Mon, 19 Jun 2000, Edwin Pratomo wrote: > > > > how to get configuration values at run-time, such as DirectoryIndex? > > I don't think you can - that configuration directive is specific to > mod_index, and only mod_index can access it, AFAIK. Yes you can: http:[EMAIL PROTECTED]
RE: The Eagle has landed!
On Wed, 12 Jul 2000, Greg Leidreiter wrote:
> Firstly becuase the Eagle book seems very rigorous to me, and such an
> oversight as forgetting to push a path into @INC should have been picked up
> well before now. I've never heard mention of this problem...
mod_perl automatically adds {ServerRoot} and {ServerRoot}/lib/perl to @INC.
> Moreover, Stein
> and MacEachern *do* address the issue of having to add another lib path. In
> my understanding that's exactly the point of the BEGIN block in startup.pl -
> it's just that for some reason this doesn't seem to be getting picked up
> properly.
According to pages 500-501 in the Eagle book, changes made to @INC from
PerlRequire'd code don't stick.
> Secondly, when I added the push ... directive to perl.conf the server
> repeatedly failed to start (which may provide a clue to those of you out
> there who know a lot more than I do) even though it came up with Syntax OK
> under httpd -t.
Watch out for those @INC push()es in your configs.
I used to have one of those in mine, and every time I did a kill -USR1,
@INC grew, though I didn't realize this at first. Then I found out about
{ServerRoot}/lib/perl, moved my modules there, and dumped the @INC
modifications.
Unexpected pnotes() behavior
I had a situation where a pnotes() key set in one phase had a value I
did not expect in a later phase. Here's a small module that I wrote
as a HeaderParserHandler to illustrate:
package Ii::Apache::pnotes;
use Apache::Constants 'OK';
sub handler {
my $r = shift;
$r->push_handlers('PerlFixupHandler' => \&other_phase);
my $n = 'I set this during the '.$r->current_callback." phase\n";
$r->notes('sample_note', $n);
printf STDERR '%s: %s', $r->current_callback(), $n;
$n = "I set this to something else before returning.\n";
return OK;
}
sub other_phase {
my $r = shift;
printf STDERR '%s: %s',
$r->current_callback(), $r->notes('sample_note');
return OK;
}
1;
__END__
...and here's what I get in my error_log:
PerlHeaderParserHandler: I set this during the PerlHeaderParserHandler phase
PerlFixupHandler: I set this to something else before returning.
If I s/pnotes/notes/ then I get what I expected:
PerlHeaderParserHandler: I set this during the PerlHeaderParserHandler phase
PerlFixupHandler: I set this during the PerlHeaderParserHandler phase
I had gotten into the habit of using pnotes() all the time no matter
what sort of value I was passing around, but it seems that if it's going
to be a regular scalar, notes() is how it must be, or I've got to be careful
not to change that variable after I set the pnotes() field. The behavior
surprized me because I wasn't passing a reference, yet pnotes() acts like
I did. In case anyone's wondering: apache 1.3.12, mod_perl 1.24.
Re: .htacess security
On Thu, 3 Aug 2000, Ken Williams wrote: > [EMAIL PROTECTED] (Rob Giseburt) wrote: > >Are .htaccess files secure? I don't want users to be able to use > >... sections or any other mod_perl constructs (setting scripts > >to run via the Registry, for example) in .htaccess files. However, I need > >..htaccess files turned on so users can password protect directories > >site-wide (so I can't shut .htaccess files off completely.) > > I assume you need sections in your main httpd.conf? If not, you can > just shut it off altogether. > > Alternatively, you might want to shut it off and use a templating system to > generate your httpd.conf file(s) so they don't have sections in them. > > >One extra question: Can I turn on mod_perl SSI and have normal SSI calls at > >the same time? In other words, can I have one page (file.pshtml maybe) > >parsed by perl-extended SSI and another (file.shtml) be parsed by normal > >(without perl, mod_ssi?) SSI? > > I'm not sure (I think probably not), but you can get the same effect if > you use Apache::SSI for some pages and regular mod_ssi for the others. It also depends on what you mean by "mod_perl SSI". If Rob is talking about Ken's Apache::SSI handler, that's one thing, but compiling PERL_SSI=1 to add #perl extentions to "regular" mod_include is another. Setting up Apache::SSI to handle some files and mod_include to handle others is not a problem. But is it possible to selectively allow #perl in only some mod_include files? If you're worried about people using sections in .htaccess files, you're going to have to worry about in SSI files too.
Re: ignore header_only()?
On Fri, 4 Aug 2000, Vivek Khera wrote:
> > "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>
> NT> I see some programmers don't check header_only(). Are there
> NT> bad things in store if you don't? Or will Apache or the browser
> NT> simply ignore the body that gets created?
>
> My experience is apache just tosses the body for you. The programmer
> check is mainly an optimization from where I sit.
No, apache will send a body if you generate it even if the client just
sends a HEAD request. Example:
Head.pm:
package Head;
use strict;
use Apache::Constants 'OK';
sub handler {
my $r = shift; $r->content_type('text/plain'); $r->send_http_header;
print 'header_only() is ', ($r->header_only) ? "true\n" : "false\n";
return OK;
}
1;
httpd.conf:
===
LoadModule mime_modulelibexec/mod_mime.so
ClearModuleList
AddModule mod_mime.c
AddModule mod_so.c
AddModule mod_perl.c
SetHandler perl-script
PerlHandler Head
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2000 17:17:47 GMT
Server: Apache/1.3.12 (Unix) mod_perl/1.24
Connection: close
Content-Type: text/plain
header_only() is true
Connection closed by foreign host.
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2000 17:17:52 GMT
Server: Apache/1.3.12 (Unix) mod_perl/1.24
Connection: close
Content-Type: text/plain
header_only() is false
Connection closed by foreign host.
A mod_proxy ProxyPass frontend will discard the body if given a "HEAD"
request though.
Re: proxying name-based virtual hosts
On Thu, 10 Aug 2000, Roger Espel Llima wrote:
> I'm trying to set up a proxy front-end server to my heavy mod_perl
> backend, and I'm having some trouble with name-based virtual hosts.
>
> Basically, with a rule like "RewriteRule ^/(.*) http://10.36.1.10/$1 [P]",
> the proxy sends an http request to 10.36.1.10:80, but setting the Host:
> http header to "10.36.1.10", not what the client supplied.
>
> The mod_perl guide suggests having statements on the
> front-end, and redirecting each hostname to a different port on the
> backend. This is inconvenient for me, because I'd have to change the
> app logic on the backend (which currently uses $r->header_in("Host")
> directly).
>
> Ideally, what I'd like is to have the front-end server not check or
> touch Host: at all, and pass it unaltered to the backend, which knows
> what to do with it. Does anyone know of a way to do this?
>
> If that's not possible, I'd settle for the backend getting it in a new
> header (eg. X-Original-Host), using an approach similar to
> mod_proxy_add_forward.c.
I ended up adding this to mod_proxy_add_forward.c:
ap_table_set(r->headers_in, "X-Original-Host",
ap_table_get(r->headers_in, "Host"));
(right after the line that adds the "X-Forwarded-For" header).
Then on the backend, I've got a TransHandler that essentially does an
$r->headers_in->set('Host' => $r->header_in('X-Original-Host')),
along with setting $r->connection->remote_ip to the "X-Forwarded-For"
header. I should note that it only does this if it "trusts" these
headers, in my case if the request is coming from 127.0.0.1 I trust it.
A nice plus is that the mod_perl backend server acts the same way
whether there's a proxy in front of it or not.
BTW I haven't tried this, but I would have had I not already had something
in place, since it's more flexible:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/lolkahcling/[EMAIL PROTECTED]
[OT] Re: Nimda worm
On Tue, Sep 18, 2001 at 04:07:59PM -0700, Nick Tonkin wrote: > > Heh, as Nat maybe saw the worm doesn't always request ?/c+dir, so until I > can figure out a better way to identify it we'll have to go with > cmd.exe|root.exe Here's a sample Nimda hit (courtesy of 'nc -l -p 80' -- try it yourself on a net-connected machine not already running a web server and just wait a few seconds): GET /scripts/root.exe?/c+dir HTTP/1.0 Host: www Connnection: close Note the "Host: www" header. You can trap this one by setting up a virtualhost called 'www'.
