Re: mod_perl and apache instll ok, but....
If you are seeing the mod_perl token in the server response headers or the server startup: http://perl.apache.org/docs/1.0/guide/install.html#Checking_the_error_log http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_telnet but not in the script: http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script that means only one thing: You're calling the script under mod_cgi and not mod_perl. Re-check again that you make the request to a location configured to be run under Apache::Registry and also that you don't override the mod_perl settings with ScriptAlias setting later in httpd.conf. Stas, sorry for watsting your time. I just needed to be pointed in the right direction. My problem was that I was Aliasing the same directory as ScriptAlias for my mod_perl test, I moved the test program to a perl directory and aliased it from there and it worked like a charm. Thank you!! I learned something very valuable today. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache instll ok, but....
Matt Lopresti wrote:
I am worried about the ENV{MOD_PERL} var not being set. What would cause
that not to get set? Is it a perms issue? In the conf file the User is
nobody and the Group is nobody. I am doing the entire make as root.
If you are seeing the mod_perl token in the server response headers or
the server startup:
http://perl.apache.org/docs/1.0/guide/install.html#Checking_the_error_log
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_telnet
but not in the script:
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script
that means only one thing: You're calling the script under mod_cgi and
not mod_perl. Re-check again that you make the request to a location
configured to be run under Apache::Registry and also that you
don't override the mod_perl settings with ScriptAlias setting later in
httpd.conf.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache instll ok, but....
I am worried about the ENV{MOD_PERL} var not being set. What would cause
that not to get set? Is it a perms issue? In the conf file the User is
nobody and the Group is nobody. I am doing the entire make as root.
Stas Bekman wrote:
Matt Lopresti wrote:
I am using RedHat 7.2, apache 1.3.27, mod_perl 1.27. Everything
istalls correctly and make test is all a go. I then start the server,
run a print env script and I dont get a MOD_PERL env and the gatway
interface is CGI/1.1, I am however getting the server software env
with mod_perl/1.27. I also added the the script in httpd.conf and
took out the she bang line to perform another test, no go, internal
server error. I do this process as root.
What's the relevant section of your httpd.conf, where a is
configured to run under mod_perl handler? You probably run scripts
under mod_cgi. Did you look at:
http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server
http://perl.apache.org/docs/1.0/guide/getwet.html#A_Simple_Apache_Perl_Content_Handler
The .conf file looks good.
Here is how I built mod_perl and apache:
% tar xzvf apache_1.3.27.tar.gz
% tar xzvf mod_perl-1.27.tar.gz
% cd mod_perl-1.27
% perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \
DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 (I have also used the USE_DSO=1)
% make && make test && make install
% cd ../apache_1.3.27
% make installd
I'm not sure what "installd" is, but the rest looks good.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache instll ok, but....
Matt Lopresti wrote: I am using RedHat 7.2, apache 1.3.27, mod_perl 1.27. Everything istalls correctly and make test is all a go. I then start the server, run a print env script and I dont get a MOD_PERL env and the gatway interface is CGI/1.1, I am however getting the server software env with mod_perl/1.27. I also added the the script in httpd.conf and took out the she bang line to perform another test, no go, internal server error. I do this process as root. What's the relevant section of your httpd.conf, where a is configured to run under mod_perl handler? You probably run scripts under mod_cgi. Did you look at: http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server http://perl.apache.org/docs/1.0/guide/getwet.html#A_Simple_Apache_Perl_Content_Handler Here is how I built mod_perl and apache: % tar xzvf apache_1.3.27.tar.gz % tar xzvf mod_perl-1.27.tar.gz % cd mod_perl-1.27 % perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 (I have also used the USE_DSO=1) % make && make test && make install % cd ../apache_1.3.27 % make installd I'm not sure what "installd" is, but the rest looks good. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] Input Filter virus scan (more info)
Chris Hoffmann wrote: [...] My need is to scan incoming data. If anyone has used "mod_vscan" on incoming data or know if the "All-in-One Filter" example located at; http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter can do this please contact me. I'm not familiar with mod_vscan and you don't specify how the scan filter works, but I see no reason why it shouldn't work, as long as all you need is an access to the request's headers. Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. Also all-in-one filter is an example of how to snoop on the data going through the filter, since you don't need the output filter, you can use a simpler only-input connection filter: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Output_Filters One more thing that needs to be figured out is how to make the filter abort the normal request processing if the virus is discovered and return a 40x response. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Sticky pnotes with Apache::Registry
David Kaufman wrote: "John Heitmann" <[EMAIL PROTECTED]> wrote ... in fact, i've avoided using pnotes after seeing similar inconsistencies and reading reports of others having them, too. that was a while back, though. I've used pnotes extensively for exactly this sort of thing and have found it to be extremely reliable and always cleaned up. I've never seen this problem before, but it does seem to be related to the directory index somehow. Sorry I can't offer a specific solution. I would suggest checking the code for any other possible sources of leaks, i.e. an unintentional closure that holds onto a copy of the DBI handle. > maybe Apache::Session (or CGI::Session) can handle these needs? No, Apache::Session is for storing data between requests, which is exactly the opposite of what he's trying to do. It can't handle storing DBI handles anyway, because Storable can't serialize them. - Perrin
Re: Sticky pnotes with Apache::Registry
"John Heitmann" <[EMAIL PROTECTED]> wrote ... > Hello, > > I am seeing an issue where it appears that the contents of pnotes does > not get destroyed when code is run inside of Apache::Registry. I first > noticed this when I saw that connections to our db remained open after > a request was finished (we store the dbi handle in pnotes for > inter-request caching) > [...] > I can work around this particular instance of the problem pretty > easily. We can use Apache::DBI and we will only ever have one > connection sticking around (as it is now there is a connection per > request which is pretty awful)... yes, Apache::DBI is the preferred method of cachng/pooling db connections efficiently. I've used it on many large projects and have never experienced the problem you're seeing. in fact, i've avoided using pnotes after seeing similar inconsistencies and reading reports of others having them, too. that was a while back, though. sorry i can't offer more specific advise on pnotes (beyond "don't rely on pnotes"), but maybe Apache::Session (or CGI::Session) can handle these needs? -dave
Re: Sticky pnotes with Apache::Registry
John Heitmann <[EMAIL PROTECTED]> writes: [...] > DirectoryIndex index.pl > > DocumentRoot /tmp/web_directory > > > AddHandler perl-script .pl > PerlHandler Apache::Registry > [...] > That httpd.conf combined with the code in the previous mail placed in > a file named "index.pl" and placed in /tmp/web_directory/ will exhibit > the problem nicely. I see nothing in the list archives or web site > about mod_dir or DirectoryIndex. mod_dir does an internal redirect, which creates a new request_rec struct and a new request_config. I *think* the problem is that when mod_perl runs its cleanup handler, it runs on the *original* request_rec + request_config, which doesn't have the new pnotes. So they never get cleaned up by mod_perl's per_request_cleanup(). This might be a bug within apache itself. -- Joe Schaefer
mod_perl and apache instll ok, but....
I am using RedHat 7.2, apache 1.3.27, mod_perl 1.27. Everything istalls correctly and make test is all a go. I then start the server, run a print env script and I dont get a MOD_PERL env and the gatway interface is CGI/1.1, I am however getting the server software env with mod_perl/1.27. I also added the the script in httpd.conf and took out the she bang line to perform another test, no go, internal server error. I do this process as root. Here is how I built mod_perl and apache: % tar xzvf apache_1.3.27.tar.gz % tar xzvf mod_perl-1.27.tar.gz % cd mod_perl-1.27 % perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 (I have also used the USE_DSO=1) % make && make test && make install % cd ../apache_1.3.27 % make installd Thanks in advance. Matt
Re: Sticky pnotes with Apache::Registry
Oops, typo in my comment
On Sunday, January 5, 2003, at 07:25 AM, John Heitmann wrote:
$r->pnotes("lemming" => undef) if 0; #if 1 then destroy is never called
That should be "# if 0 then DESTROY is never called."
I've tracked it down further. When I run
http://server_name:8080/index.pl the problem does not occur. When I run
http://server_name:8080/ with mod_dir set to automatically run
index.pl, then the problem occurs. Here is a really pared down
httpd.conf file that is the smallest example I can generate:
# Start
ClearModuleList
AddModule mod_mime.c
AddModule mod_dir.c
AddModule mod_perl.c
DirectoryIndex index.pl
DocumentRoot /tmp/web_directory
AddHandler perl-script .pl
PerlHandler Apache::Registry
# Site specific stuff here for completeness but greeked out
User me
PidFile /tmp/me.httpd.pid
Listen 8080
# This just loads Apache::Registry, DBI and DBD::mysql
PerlRequire /tmp/lib/startup.pl
# End
That httpd.conf combined with the code in the previous mail placed in a
file named "index.pl" and placed in /tmp/web_directory/ will exhibit
the problem nicely. I see nothing in the list archives or web site
about mod_dir or DirectoryIndex.
TIA,
John
Sticky pnotes with Apache::Registry
Hello,
I am seeing an issue where it appears that the contents of pnotes does
not get destroyed when code is run inside of Apache::Registry. I first
noticed this when I saw that connections to our db remained open after
a request was finished (we store the dbi handle in pnotes for
inter-request caching). Are there times when pnotes is expected not to
be destroyed? This same example works correctly when placed in a method
handler.
I'm running perl 5.8, mod_perl 1.27, Apache 1.3.27, and a stock RedHat
Linux 7.3 install on a vanilla x86 desktop.
Here is a really simple snippet that shows the "problem" (I just may
not understand how pnotes works).
my $r = Apache->request();
my $dbh = DBI->connect("DBI:mysql:database=blah blah blah...");
$r->pnotes("our_dbh_cache" => $dbh);
# Test destruction with a simpler case also
my $lemming = Lemming->new();
$r->pnotes("lemming" => $lemming);
$r->pnotes("lemming" => undef) if 0; #if 1 then destroy is never called
$r->send_http_header();
$r->print("Hello");
package Lemming;
sub new {
my $class = shift;
return bless {}, $class
}
sub DESTROY {
warn ("Aieee!!!");
}
1;
If the "if 0" is changed to "if 1" then it works as I expect and
"Aieee!!!" is dumped to the error log at the end of the request. If it
is run as written, then under Apache::Registry Lemming::DESTROY is
never called and the db connection sticks around indefinitely.
I can work around this particular instance of the problem pretty
easily. We can use Apache::DBI and we will only ever have one
connection sticking around (as it is now there is a connection per
request which is pretty awful), or we could just not cache the dbh.
That example is from old code and we don't care about it too much. The
real reason I'm mailing this list is that I'm seeing problems elsewhere
in our full system built with method handlers rather than
Apache::Registry. In that system data stored in pnotes may also be
leaking. I haven't been able to fully nail down those larger problems
enough yet to include any more detail, but I'm hoping this small
example will shed light on the larger issue.
Thanks for any help,
John
