Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
Hi, thanks for the tips. But I don't seem to be able to locally override
the value of AutoCommit for one handle (I only need to use AutoCommit for
one script!). If I follow the instructions on the URL you pointed me to,
and do something like:
my $dbh = DBI-connect (dbi:Pg:dbname=hello, postgres, foo);
my %orig = ();
my attrs = qw(AutoCommit RaiseError);
$orig{$_} = $dbh-{$_} for attrs;
$dbh-{AutoCommit} = 0; $dbh-{RaiseError} = 1;
When I later do the $dbh-commit, it fails with this in my log file:
commit ineffective with AutoCommit enabled at /usr/lib/perl5/.
So is AutoCommit disallowed for overriding (as this seems to suggest)?
Regards
Kirk Bowe.
On Tue, 15 Oct 2002, Perrin Harkins wrote:
Kirk Bowe wrote:
Unfortunately after a couple of hours of moderate use Postgres reaches its
max_clients level (which is set below max httpds in httpd.conf)
This is usually caused by mistakes in your connection calls where they
have slightly different connect info resulting in multiple connections.
At this point there's no
work being done, so presumably the handles aren't being freed.
Database handles are not supposed to be freed. That's the point of
Apache::DBI. However, you should only have one per httpd process.
Does anyone have any tips on how to, at this point, go about detecting
where the handle leak might be (which I'm presuming is the problem)?
http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_Apache__DBI
should Template::Toolkit be avoided altogether when using mod_perl and
database connectivity?
TT is not related to this. It works great with mod_perl.
- Perrin
Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
On Wed, 16 Oct 2002, Kirk Bowe wrote:
my $dbh = DBI-connect (dbi:Pg:dbname=hello, postgres, foo);
my %orig = ();
my @attrs = qw(AutoCommit RaiseError);
$orig{$_} = $dbh-{$_} for @attrs;
$dbh-{AutoCommit} = 0; $dbh-{RaiseError} = 1;
When I later do the $dbh-commit, it fails with this in my log file:
I've always done it this way, further the DBI man states:
Enable transactions (by turning AutoCommit off)
until the next call to commit or rollback. After
the next commit or rollback, AutoCommit will
automatically be turned on again.
Although I usually just do a $dbh-{AutoCommit}=1 to re-enable.
Are you sure that there isn't something else changing the AutoCommit back
on, unintentionally?
Rafiq
--
Senior Programmer
Bookings.nl
--
Me::[EMAIL PROTECTED]||www.dreamthought.com
Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: mod_perl Guide Patch
At 16:19 15/10/2002, Per Einar Ellefsen wrote: At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? Hello - I may have unsub'd from the list by now, so would you mind cc'ing this for me if it doesn't get through and if you think it useful? So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Took me hours to figure it out Cheers lee
posts headers and so on.
Hello: I just subscribed to the list. I don't want to be a pain in the ass so soon, but I've noticed that (at least on yahoo), these posts cannot be automatically replied to the list. They go by default to whoever wrote the original email, thus one has to manually replace that address for [EMAIL PROTECTED] . Also, neither the Subject, the To: or the From: information in the header doesn't mention modperl * , making it hard to filter these emails. Has anyone noticed all this already or is it me? = ___ Eduardo Gomez www.innerlab.com __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello, Caught the problem. It was a unexpected 'print STDOUT' happening in the Cleanup Handler. :-( sorry for the trouble. regards srp You wrote: Envelope-to: [EMAIL PROTECTED] Received: from symonds.net [63.194.20.32] by symonds.net with smtp (Exim 3.35 #1 (Debian)) id 181QC0-0001uo-00; Tue, 15 Oct 2002 04:48:56 -0700 Date: Tue, 15 Oct 2002 04:48:56 -0700 (PDT) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler X-URL: http://www.symonds.net/ Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-UIDL: HH\!TZ!!W[T!+/6!! Status: RO Thanks for reply .. Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. Yes, I understand that. What I am saying is this ... After a successfull internal_redirect(), and return OK my content handler has exited - The content has now reached my client. Now my cleanup handler is executing. I am not understanding why Apache is attempting to write to client now !! Also, by using internal_redirect_handler() you can make r-handler (which is the current handler by default) handle this redirect(). ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED] regards srp
Re: mod_perl Guide Patch
Hello Lee, So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Sure, I understand what you mean now. I'll consider it for inclusion. Thank you for your contribution. -- Per Einar Ellefsen [EMAIL PROTECTED]
istallation problem.
Hello: I am not an expert either with Apache or Perl, so I am probably having some basic problem here. I was forced to intall mod_perl just because of one script that I use for querying Amazon.com and parsing the XML they return. My site was until yesterday hosted by some company, but now I have to use my own web server and trying to make perl work. I had apache installed on w2000, and replaced that instalation with the one provided in the file perl-win32-bin-0.9.exe. I copied everything on top of the other one, including the configuration. Browsing of localhost is fine, and simple Perl tests like hello.pl work, but I have problems with that script. I don't really know what the following means, but it seems the script uses Perl module LWP. The author of the script recommended installing this module like this: perl -MCPAN -e 'install Bundle::LWP' I issued the command with a *.bat file and the command kept looping forever, and had to stop it manually (CTRL+C). Also, the script uses a package called WSParser.pm, which I have in my cgi-bin folder. Maybe someone in this list is an Amazon.com associate and has dealt with these scripts. Anyway, I don't even know how to chmod a file, so maybe this is the first thing I should do. How do I do that? Thanks in advance, and sorry that I am such a newbie here. Ed. __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: posts headers and so on.
Hello Innerlab, At 15:18 16.10.2002, Innerlab wrote: Hello: I just subscribed to the list. I don't want to be a pain in the ass so soon, but I've noticed that (at least on yahoo), these posts cannot be automatically replied to the list. They go by default to whoever wrote the original email, thus one has to manually replace that address for [EMAIL PROTECTED] . This is intentional. You have to use Reply to all. Also, neither the Subject, the To: or the From: information in the header doesn't mention modperl * , making it hard to filter these emails. Use a filter that checks To: and Cc: for the presence of [EMAIL PROTECTED] (which is btw the correct address), and filter based on that. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: posts headers and so on.
I just hit reply now - note that it is AUTOMATICALLY to you, plus [EMAIL PROTECTED] Also note the original headers below: Issac - Original Message - From: Innerlab [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 16, 2002 3:18 PM Subject: posts headers and so on. Hello: I just subscribed to the list. I don't want to be a pain in the ass so soon, but I've noticed that (at least on yahoo), these posts cannot be automatically replied to the list. They go by default to whoever wrote the original email, thus one has to manually replace that address for [EMAIL PROTECTED] . Also, neither the Subject, the To: or the From: information in the header doesn't mention modperl * , making it hard to filter these emails. Has anyone noticed all this already or is it me? = ___ Eduardo Gomez www.innerlab.com __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Problem with CGI.pm and mod_perl 2
Hi,
I have a problem when porting an application from Apache 1.23.x + mod_perl
1.0 to Apache 2.xx + mod_perl 2.0.
One of the scripts receives as argument a filename (with no path info), and
the scripts is suppose to open the file from the same directory in which
the script is located and perform some stuff on it. The code looks
something like:
$cgih = new CGI;
$filename = $cgih-param('filename');
open(FILE, $filename) || die can't open file;
# do some stuff
This code used to work on previous platform, i.e. the file called
filename would be opened from the same directory as the script itself.
Now, the system cannot anymore. If I hardcode the filename with full path,
it works (this was to check whether I had some file permission problems).
Thanks,
Luc
Re: Can I parse content that has been returned to user by simple cgi script?
I want to upgrade my project with implementing some feature. Project was writen for mod_cgi, but I would like to parse content that was generated by my scripts to implement something like SSI or Apache::UCase and etc. PH You can't do that. However, you can run your CGI scripts under PH Apache::PerlRun and then use Apache::Filter on them to do things like PH SSI. This will also make them much faster. PH - Perrin Thank you! Now I've uderstood that it's only way. OK. And last one, could someone point me to documents about troubleshoots which could ocure while using Apache::PerlRun with CGI scripts that was writen only for mod_cgi? Thank you for help. mailto:[EMAIL PROTECTED]
Re: Problem with CGI.pm and mod_perl 2
On Wed, 16 Oct 2002 [EMAIL PROTECTED] wrote:
Hi,
I have a problem when porting an application from Apache 1.23.x + mod_perl
1.0 to Apache 2.xx + mod_perl 2.0.
One of the scripts receives as argument a filename (with no path info), and
the scripts is suppose to open the file from the same directory in which
the script is located and perform some stuff on it.
[ ... ]
This code used to work on previous platform, i.e. the file called
filename would be opened from the same directory as the script itself.
Now, the system cannot anymore. If I hardcode the filename with full path,
it works (this was to check whether I had some file permission problems).
As you've discovered, assuming a value for the current working
directory isn't reliable. Apart from using the full path, one
possibility is to use FindBin, which gives the directory of the
original script, and you can then specify paths relative to that.
However, the perl-5.8 man page for FindBin warns, in part,
If there are two modules using FindBin from different directories
under the same interpreter, this won't work. Since FindBin uses
BEGIN block, it'll be executed only once, and only the first caller
will get it right. This is a problem under mod_perl and other persistent
Perl environments, where you shouldn't use this module. Which also means
that you should avoid using FindBin in modules that you plan to put on
CPAN. The only way to make sure that FindBin will work is to force the
BEGIN block to be executed again:
delete $INC{'FindBin.pm'};
require FindBin;
--
best regards,
randy kobes
Re: Can I parse content that has been returned to user by simple cgi script?
At 16:47 16.10.2002, Ruslan U. Zakirov wrote: I want to upgrade my project with implementing some feature. Project was writen for mod_cgi, but I would like to parse content that was generated by my scripts to implement something like SSI or Apache::UCase and etc. PH You can't do that. However, you can run your CGI scripts under PH Apache::PerlRun and then use Apache::Filter on them to do things like PH SSI. This will also make them much faster. PH - Perrin Thank you! Now I've uderstood that it's only way. OK. And last one, could someone point me to documents about troubleshoots which could ocure while using Apache::PerlRun with CGI scripts that was writen only for mod_cgi? There aren't many problems with Apache::PerlRun, as it goes to great lengths to be a direct equivalent to mod_cgi so that dirty scripts can run. Anyway, the Guide is always here to help. See especially http://perl.apache.org/docs/1.0/guide/porting.html , although a lot of this is for Apache::Registry, which you might want to move on to later. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Can I parse content that has been returned to user by simple cgi script?
AA perldoc cgi_to_mod_perl AA perldoc mod_perl_traps AA http://perl.apache.org/docs/1.0/guide/porting.html PEE There aren't many problems with Apache::PerlRun, as it goes to great PEE lengths to be a direct equivalent to mod_cgi so that dirty scripts can run. PEE Anyway, the Guide is always here to help. See especially PEE http://perl.apache.org/docs/1.0/guide/porting.html , although a lot of this PEE is for Apache::Registry, which you might want to move on to later. Thanks! I think enough information for me and I've answers for all my questions. Thank you all. mailto:[EMAIL PROTECTED]
Memory leak on reload when the 'Pg' driver is preloaded
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
The leak happens when you send SIGUSR1 to the parent. Every time you do
it, you get more memory eaten (multiple megabytes), both in the parent
and (new) children.
It happens with the stock apache-ssl that comes from Debian stable.
Could well be a Debian-specific problem.
Using Debian's static-mod_perled apache-perl eliminates the problem.
evil scripts kill the server...
Moin, moin although it never happened to me i have to fight some rumours. Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? (I doubt it) -- I'm working on it. http://Patterner.de
$r-current_callback() returns wrong handler after subrequest
Hello, $r-current_callback() is returning 'PerlLogHandler', when called from a CleanupHandler after a subrequest was handled. It returns 'PerlHandler' correctly when called from the 'content-handler'. I am using Apache/1.3.23 (Unix) mod_perl/1.26 with PerlFreshRestart On. any clues why this is so ? regards srp
Re: evil scripts kill the server...
Hi Joerg, At 18:06 16.10.2002, Joerg Plate wrote: although it never happened to me i have to fight some rumours. Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? (I doubt it) It depends on what wrong thing you do. mod_perl gives a great deal of freedom, and with freedom comes responsibility. Things like using a lot of memory and the fact that mod_perl scripts/modules can access each others namespaces can make for some problems. You probably want to look at : http://perl.apache.org/docs/general/multiuser/multiuser.html But just throwing an error (because of some unexpected condition, for example), won't kill the whole server. -- Per Einar Ellefsen [EMAIL PROTECTED]
$r-requires
Does anyone have an example of how to use $r-requires? I cannot find Apache::AuthzAge for an example of its use. I'm trying to handle all my location directive specific stuff in a TransHandler and simply want to set require valid-user for some specific paths. Thanks, Rodney Hampton
Re: istallation problem.
On Wed, 16 Oct 2002, Innerlab wrote: Hello: I am not an expert either with Apache or Perl, so I am probably having some basic problem here. I was forced to intall mod_perl just because of one script that I use for querying Amazon.com and parsing the XML they return. My site was until yesterday hosted by some company, but now I have to use my own web server and trying to make perl work. I had apache installed on w2000, and replaced that instalation with the one provided in the file perl-win32-bin-0.9.exe. I copied everything on top of the other one, including the configuration. Browsing of localhost is fine, and simple Perl tests like hello.pl work, but I have problems with that script. I don't really know what the following means, but it seems the script uses Perl module LWP. The author of the script recommended installing this module like this: perl -MCPAN -e 'install Bundle::LWP' The Perl/Apache distribution of perl-win32-bin.exe comes with the LWP suite of modules, so you shouldn't have to install this. Also, the script uses a package called WSParser.pm, which I have in my cgi-bin folder. Maybe someone in this list is an Amazon.com associate and has dealt with these scripts. I'm not familiar with this module, but if it's a problem with finding it, take a look at the entry on keeping and using your own module library under C:\ perldoc perlfaq8 Anyway, I don't even know how to chmod a file, so maybe this is the first thing I should do. How do I do that? This is probably a Unix-specific thing in setting the permissions properly; you most likely don't need this on Win32. -- best regards, randy kobes
Re: evil scripts kill the server...
although it never happened to me i have to fight some rumours. Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? (I doubt it) It depends on what wrong thing you do. In fact the worse you can do is to kill one of the mod_perl processes, not the whole server (which is multiprocess) - at least not under Unix. A new server will be spawned automatically and the clients will only notice some slowdown (and maybe the document contains no data message, if the server died too early). -- Dominique QUATRAVAUX Ingénieur développeur senior 01 44 42 00 35 IDEALX
Re: Memory leak on reload when the 'Pg' driver is preloaded
Using Debian's static-mod_perled apache-perl eliminates the problem. Do you mean you are using the 'so' version that comes with Debian? You should be using the static build of apache/mod_perl
Re: $r-current_callback() returns wrong handler after subrequest
[EMAIL PROTECTED] wrote: Hello, $r-current_callback() is returning 'PerlLogHandler', when called from a CleanupHandler after a subrequest was handled. It returns 'PerlHandler' correctly when called from the 'content-handler'. I am using Apache/1.3.23 (Unix) mod_perl/1.26 with PerlFreshRestart On. any clues why this is so ? yeah, I think it's a bug. IIRC, I found a few situations where current_callback() didn't work quite right, probably when using internal redirects or other subrequest mechanisms. I think I filed a report, which may be in the archives someplace. you can try upgrading to 1.27, but I don't think it was ever fixed (or really investigated). sorry I can't be of more help here. --Geoff
Re: Memory leak on reload when the 'Pg' driver is preloaded
Stathy G. Touloumis wrote: Using Debian's static-mod_perled apache-perl eliminates the problem. Do you mean you are using the 'so' version that comes with Debian? Yes, in the case that failed. The package is called 'libapache-mod-perl'. You should be using the static build of apache/mod_perl You're telling me. :-( By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Used If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. Thanks.
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9raVtnksV4Ys/z5gRAt+TAJwOZXcdnVNoLWLza7NU6eOpCOB+dQCdEliU VDvG6M+qI88/RN/jj7KsCC0= =0/Bl -END PGP SIGNATURE-
Re: evil scripts kill the server...
Hi there, On Wed, 16 Oct 2002, Joerg Plate wrote: although it never happened to me i have to fight some rumours. Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? (I doubt it) Yes, I'm afraid it is. 73, Ged.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. There are still one or two dusty corners but in general thesedays I'd say try it. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. No sense being a damned fool about it. (Somebody remind me who said that:) 73, Ged.
basic www auth
Hi
I'd like to do basic www authentication on my scripts. Apache::Auth::DBI
isn't good since it would waste a database connection, and just add
unnecessary complication. I'd like to do something like:
if (! check ($username, $password)) {
send_unauthorized_http_headers ();
}
I guess I can send the 401 response using $r-header_out, but I still
haven't found out how to get the authentication information: username
and password.
Thanks in advance.
Re: current state of conf/code, feedback?
I was cruising with Apache::DBI, definitely better than the way I had it, but now suddenly I'm getting this error: DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not current thread b0f18c (handles can't be shared between threads and your driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm line 64. What's going on? Perrin Harkins [EMAIL PROTECTED] wrote: Paul Simon wrote: I currently have CGI pages caching on the client side, which is helping some, but I'm also going to experiment with CGI::Cache. There are some mod_perl specific version of this too, like the one from the mod_perl Developer's Cookbook (Apache::CacheContent), but these are mod_perl 1.x and probably require work to get them running on mod_perl 2. Traditionally this has mostly been done with a caching reverse proxy, and that's another angle you could try. What kind of trouble is there for having use DBI and use HTML::Template in both startup.pl and Snoopy.pm (besides being redundant)?None. That is the right thing to do, because it preloads the modules (by having them in startup.pl) and documents the dependencies (by putting in Snoopy.pm). Since Snoopy.pm is the meat and pototoes, should it also be in startup.pl?Yes. Does declaring Class variables, such as the DBI handle, offer any benefits (or pain) of a shared connection? You're getting yourself into major trouble there. You should use Apache::DBI instead. The way you have it now (with the connection code in the "main" section of Snoopy.pm), that database connection will be created when you use the module in startup.pl. Apache will then fork and multiple children will try to share the same $DBH. Disaster.Also, your solution will not try to reconnect if it loses its connection. Apache::DBI will. And you are creating a closure here with your $DBH which might come back to bite you later if your module gets automatically reloaded when you change it.- Perrin
Re: evil scripts kill the server...
Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? Yes, I'm afraid it is. How? -- I'm working on it. http://Patterner.de
Re: current state of conf/code, feedback?
Paul Simon wrote: I was cruising with Apache::DBI, definitely better than the way I had it, but now suddenly I'm getting this error: DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not current thread b0f18c (handles can't be shared between threads and your driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm line 64. What's going on? You'd be better off asking on the DBI list, but it looks to me like your DBD is not thread-safe, or else you opened a connection before the fork (in startup.pl). - Perrin
Re: evil scripts kill the server...
Hi there, On Wed, 16 Oct 2002, Joerg Plate wrote: Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? Yes, I'm afraid it is. How? For example by swallowing all the memory, by consuming all the CPU, and of course by making root access available to the world through careless programming practice... Need I continue? 73, Ged.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
Re: Memory leak on reload when the 'Pg' driver is preloaded
Juha-Mikko Ahonen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. I already have, months ago. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. Huh? I would think that would be a really good reason to yank it. If it were Debian-related, the maintainer could fix it and keep it.
RE: evil scripts kill the server...
-Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:49 PM To: Joerg Plate Cc: [EMAIL PROTECTED] Subject: Re: evil scripts kill the server... Hi there, On Wed, 16 Oct 2002, Joerg Plate wrote: Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? Yes, I'm afraid it is. How? For example by swallowing all the memory, by consuming all the CPU, and of course by making root access available to the world through careless programming practice... Need I continue? Yes you should. You are making it sound like these problem are unique to mod_perl when they are not. While you allude to the real causes of many server problems - careless programming practice - you leave it open like mod_perl somehow intrinsically fosters careless programming or that even worse it is inherently not secure. Like any web server, a poorly configured and poorly programmed mod_perl enable server is prone to failure. Of course some could say that a poorly configed/programmed mod_perl/apache server is better than a well configed/programmed server of another brand. The original poster should know that any server can fail under to proper circumstances and that while technically the rumors are true (and are they really rumors? I don't think there is some hidden agenda in the mod_perl/apache community to hide server security issues) it is also just as true that a problem in a mod_perl script is not going to cause the server to fail completely. And all of that is true with any brand server. That is why you should have a development server to work on new code on, a QC server to test newly released code and a production server (or servers) for code you have tested and a sure is ready for prime-time. And again, that is not true only for mod_perl/apache, but is true for all webservers regardless of brandname.
RE: Memory leak on reload when the 'Pg' driver is preloaded
For what it is worth, we use a DSO mod_perl/apache that we compiled ourselves, on RedHat thought, that is very stable and does not have noticeable memory leaks and have been using it for over 3 years. Just thought I would throw that out there. -Original Message- From: Keith G. Murphy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:02 PM To: mod_perl Mailing List Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
RE: evil scripts kill the server...
Hi there, On Wed, 16 Oct 2002, Joe Breeden wrote: You are making it sound like these problem are unique to mod_perl when they are not. I didn't think I was doing that. I didn't mean to. I have no axe to grind here, and I use mod_perl a great deal. It has never let me down (although I have:). The original poster should know that any server can fail Yes, he should. I think he probably does. And I think we should kill this thread. 73, Ged.
Re: $r-requires
Rodney Hampton wrote: Does anyone have an example of how to use $r-requires? see recipe 13.6 in the cookbook, the code for which can be found here: http://www.modperlcookbook.org/code/ch13/Cookbook/AuthzRole.pm I cannot find Apache::AuthzAge for an example of its use. I'm trying to handle all my location directive specific stuff in a TransHandler and simply want to set require valid-user for some specific paths. $r-requires() is read-only. conditional authentication is a bit counterintuitive - you can't set up authentication where it doesn't already exist because Apache won't run the authentication phase without a Require directive in your httpd.conf. the solution is to turn on authentication for everything, then turn it off where you don't need/want it. see recipe 13.5 in the cookbook for more details. the code for 13.5 can be found here: http://www.modperlcookbook.org/code/ch13/Cookbook/PassLocalIP.pm see also the Satisfy directive http://httpd.apache.org/docs/mod/core.html#satisfy if you're only looking to do conditional authentication based on IP addresses/hostnames. HTH --Geoff
Re: Memory leak on reload when the 'Pg' driver is preloaded
Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? Yes, I'm sure. Red Hat comes with Apache prebuilt for DSO I believe. I have worked on contracts for a number of organizations which use DSO mod_perl in high volume environments (hundreds of thousands of users). There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. What I meant was that some (perhaps slightly unusual in some way) configurations seem to give more problems than others. For example I think that servers using SSL have perhaps been prone to troubles, but it could just as easily be that the people who experienced the problems were not careful to follow what you might say are slightly more complex than usual build procedures. 73, Ged.
Re: basic www auth
Cristóvão Dalla Costa wrote:
Hi
I'd like to do basic www authentication on my scripts. Apache::Auth::DBI
isn't good since it would waste a database connection, and just add
unnecessary complication. I'd like to do something like:
if (! check ($username, $password)) {
send_unauthorized_http_headers ();
}
I guess I can send the 401 response using $r-header_out, but I still
haven't found out how to get the authentication information: username
and password.
you can see all of chapter 13 in the cookbook, but a basic
PerlAuthenHandler and example of using the mod_perl authentication API
can be found here:
http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm
HTH
--Geoff
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? Yes, I'm sure. Red Hat comes with Apache prebuilt for DSO I believe. I have worked on contracts for a number of organizations which use DSO mod_perl in high volume environments (hundreds of thousands of users). Then I take your word for it. (My question was sincere, not argumentative, by the way). There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. What I meant was that some (perhaps slightly unusual in some way) configurations seem to give more problems than others. For example I think that servers using SSL have perhaps been prone to troubles, but it could just as easily be that the people who experienced the problems were not careful to follow what you might say are slightly more complex than usual build procedures. Hmmm. In my case, I replicated the problem with Debian's plain vanilla Apache as well, for the very purpose of simplification. So SSL does not seem to be involved.
Re: Memory leak on reload when the 'Pg' driver is preloaded
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote: Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. That's because I'm having an attack of real life. I haven't had time to look at my Debian bug reports in a month or so now. I don't know why the DSO is leaking in a case when the static module isn't, but it should be fixable; I just need to find five or six hours to sit down with it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Memory leak on reload when the 'Pg' driver is preloaded
Daniel Jacobowitz wrote: On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote: My own bug report is now 47 days old, without apparent followup. Hmmm, I probably should not have posted that. Sounds like a major whine. That's because I'm having an attack of real life. I haven't had time to look at my Debian bug reports in a month or so now. I don't know why the DSO is leaking in a case when the static module isn't, but it should be fixable; I just need to find five or six hours to sit down with it. Thanks, Dan, this really wasn't meant to be a slam-the-developer session. I really, *really* appreciate all the work you've done already. Now I feel tacky. :-( It's not like it was an obvious problem: I only got the DSO to leak when loading the Pg driver. That's pretty obscure.
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9rcZ5nksV4Ys/z5gRAjBQAJwKOUuu4B14yLe1msSNekI0mnPvdACdFMOe
TFLM0arS4L177Y+OuJMAUgM=
=GsvK
-END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko Ahonen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same if
I comment out the Apache::DBI line in addition. This works with plain
apache, or apache-ssl.
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
If I comment it all out including the Apache::Status line, I get neither
the segfault or the leak. (Well, small leak, a few bytes).
So the install_driver masks a bigger problem with Apache::Status?
That's just too weird. But true, I swear.
Is there anyone else out there with Debian stable w/
apache+libapache-mod-perl who can try to reproduce this simple case?
I'd really like either a confirmation or a counterexample. If the
latter, I'd chalk it up to a weirdness on my system (and probably not
even pursue it, since I've moved on to the static version). I'm
pursuing it this far so Dan J. might get some useful feedback.
I've submitted this to debian-isp as well; maybe someone there can try it.
Re: AuthCookieDBI help please.... (more info)
I am still having trouble with Apache::AuthCookieDBI.
I tried moving the PerlSetVar line out of the virtual server to the main server but
nothing in the behavior changed.
Is it possible that the Apache-server-dir_config() code is somehow wrong?
I grepped all the other .pm files on my server and did not find a similar construct
anywhere.
I realize that this begin statement happens when there is not yet a request object.
But is it somehow occurring too early in the startup phase for the vars to ba
available.
I really really want to figure out what's going wrong here - I am about to implement a
workaround where I hardcode the values of the PerlSetVars into the BEGIN block, but
that is very unsatisfying.
Other people use this module commonly, don't they? Is there a module I should be using
instead?
Thanks for your help!
GV
At 08:50 AM 10/11/2002 +0200, Vegard Vesterheim wrote:
On Thu, 10 Oct 2002 17:44:51 -0700 George Valpak [EMAIL PROTECTED] wrote:
At 04:16 PM 10/10/2002 -0700, I wrote:
I am having trouble with Apache:AuthCookieDBI. I hope someone here can help
because I have not been able to find a solution despite extensive searching.
snip
OK, now I am poking in the code.
I modified the BEGIN section for AuthCookieDBI.pm thusly:
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache-server-dir_config() };
#my changes start here
my @list = keys %{ Apache-server-dir_config()};
Apache::log_error(keys:@list);
Apache::log_error( all varrs=$_ );
Apache::log_error( keyfile_vars=@keyfile_vars );
#my changes end here
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache-server-dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, $keyfile ) ) {
Apache::log_error( Could not open keyfile for $auth_nam
e in file $keyfile );
} else {
$SECRET_KEYS{ $auth_name } = KEY;
close KEY;
}
}
}
and restarted the server. the logs show:
[Thu Oct 10 17:34:14 2002] [error] keys:
[Thu Oct 10 17:34:14 2002] [error] all varrs=
[Thu Oct 10 17:34:14 2002] [error] keyfile_vars=
[Thu Oct 10 17:34:14 2002] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux)
mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 configured -- resuming
normal operations
[Thu Oct 10 17:34:14 2002] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Thu Oct 10 17:34:14 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
This to me indicates that the call to Apache-server-dir_config() is not returning
anything at all. A quick look a the eagle book, p 456 does not explain to me why
that should beany thoughts?
I had a similar problem a while ago. Check out this thread:
http://groups.yahoo.com/group/modperl/message/34266
- snip - snip -
I discovered the same thing. I think the problem is that the BEGIN
block as written, only considers parameters defined in the *main
server*. So if you have any PerlSetVar in a Virtual Server, it will
not be found.
A kludgy workaround is to move the PerlSetVar out of any Virtual
Server sections. A better option is to reimplement the mechanism for
populating the SECRET_KEYS hash, so that Virtual Servers are handled
properly.
- snip - snip -
RE: AuthCookieDBI help please.... (more info)
-Original Message-
From: George Valpak [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 3:26 PM
To: Vegard Vesterheim
Cc: [EMAIL PROTECTED]
Subject: Re: AuthCookieDBI help please (more info)
I am still having trouble with Apache::AuthCookieDBI.
I tried moving the PerlSetVar line out of the virtual server to
the main server but nothing in the behavior changed.
Is it possible that the Apache-server-dir_config() code is
somehow wrong?
Move ALL mention of the AuthCookieDBI directives OUT of any Directory,
Location, or VirtualServer blocks. Define the secret key PerlSetVar BEFORE
loading PerlModule directive.
The relevant section of my server config looks like this:
# These must be set
PerlSetVar AdminDBI_DSN dbi:Oracle:STATS
PerlSetVar AdminDBI_SecretKeyFile /etc/httpd/conf/sercret.key
PerlSetVar AdminDBI_SecretKey XXX
# moved BELOW AdminDBI_SecretKeyFile so the directive is available at
# BEGIN{} time
PerlModule Apache::AuthCookieDBI
PerlSetVar AdminPath /admin
PerlSetVar AdminLoginScript /scripts/adminlogin.pl
#PerlSetVar AdminLoginScript /error/adminlogin.html
## more directives here
Hope this helps!
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
RE: AuthCookieDBI help please.... (more info)
Rob - thanks for your response. The relevant part of my http.conf is below. The only
thing I see maybe as different is my dev2Path line - my goal is to protect the
location /directory and and .pl files. Is that line right? Also, you have a PerlSetVar
SecretKey line that does not show up in my perldocs. (module v 1.19)
Thanks - GV
#-
[snip previous virtualhost stuff...]
/VirtualHost
PerlSetVar dev2DBI_SecretKeyFile /home/websites/dev2/signmanage/secretkey
PerlSetVar dev2Path /
PerlSetVar dev2LoginScript /signmanage/login.pl
PerlSetVar dev2DBI_DSN dbi:Pg:dbname=users
PerlSetVar dev2DBI_User someone
PerlModule Apache::AuthCookieDBI
VirtualHost dev2
DocumentRoot /home/websites/dev2
ServerName dev2.gimsnetwork.com
DirectoryIndex index.html
Location /protected
AuthName dev2
AuthType Apache::AuthCookieDBI
PerlAuthenHandler Apache::AuthCookieDBI-authenticate
PerlAuthzHandler Apache::AuthCookieDBI-authorize
Require valid-user
/Location
FilesMatch \.pl$
AuthName dev2
AuthType Apache::AuthCookieDBI
PerlAuthenHandler Apache::AuthCookieDBI-authenticate
PerlAuthzHandler Apache::AuthCookieDBI-authorize
Require valid-user
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/FilesMatch
# This is the action of the login.pl script above.
Files LOGIN
AuthType Apache::AuthCookieDBI
AuthName dev2
SetHandler perl-script
PerlHandler Apache::AuthCookieDBI-login
/Files
At 03:47 PM 10/16/2002 -0700, Rob Bloodgood wrote:
-Original Message-
From: George Valpak [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 3:26 PM
To: Vegard Vesterheim
Cc: [EMAIL PROTECTED]
Subject: Re: AuthCookieDBI help please (more info)
I am still having trouble with Apache::AuthCookieDBI.
I tried moving the PerlSetVar line out of the virtual server to
the main server but nothing in the behavior changed.
Is it possible that the Apache-server-dir_config() code is
somehow wrong?
Move ALL mention of the AuthCookieDBI directives OUT of any Directory,
Location, or VirtualServer blocks. Define the secret key PerlSetVar BEFORE
loading PerlModule directive.
The relevant section of my server config looks like this:
# These must be set
PerlSetVar AdminDBI_DSN dbi:Oracle:STATS
PerlSetVar AdminDBI_SecretKeyFile /etc/httpd/conf/sercret.key
PerlSetVar AdminDBI_SecretKey XXX
# moved BELOW AdminDBI_SecretKeyFile so the directive is available at
# BEGIN{} time
PerlModule Apache::AuthCookieDBI
PerlSetVar AdminPath /admin
PerlSetVar AdminLoginScript /scripts/adminlogin.pl
#PerlSetVar AdminLoginScript /error/adminlogin.html
## more directives here
Hope this helps!
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Apache::AuthcookieDBI issue - NS broswers display login form incorrectly?
For now I have hardcoded the secretkeyfile in AuthcookieDBI.pm (very kludgy an not really what I want for production but for now it will have to do) . This seems to be working in preliminary tests in Opera and IE. But Netscape has a problem, and I am seeing the same problem in 4.7x, 6.2, and 7.0. The browser is getting what appears to be the right html for the login form, but it thinks the content-type is text/plain for some reason. I tried adding a meta tag in the html template to no avail: meta http-equiv=content-type content=text/html I also tries setting the header directly in the response in my login.pl file immediately before sending the header: $r-header_out(content_type= text/html); $r-send_http_header; This also did not change the behavior. Is there a known issue with NS browsers? Thanks, GV
AuthCookieDBI Question
Is there any thinking about there being a security problem or the potential for one with Apache::AuthCookieDBI's Cookie name of Apache::AuthCookieDBI_[NAMEHERE] I from time to time look at the cookies my browsers collect and i have never seen anything simular. -- Gabriel C. Millerd | I think a relationship is like a shark. It has to Script Monkey | constantly move forward or it dies. Well, what we | have on our hands here is a dead shark. --Woody | Allen
Apache::DBI: number of mysql connections vary wildly
Hi, I am using mod_perl (1.24_01) with Apachi::DBI and Mysql (3.23.37).
I am finding that the number of open number of database connections I have
open at one time is varying wildly.
When I first start Apache and Mysql there are only 8 connections made. Why
8? I have specified that there should be 20 Apache child processes. Should
the db connections match that?
After load on the webserver starts, the number of connections grows, usually
to 20 or below. This is fine, I would expect that.
Then, Suddenly, the number of connctions jumps up to 50 or more! Sometimes
this falls back to below 20, but sometimes this keeps climbing. Server load
hits over 50 (99.9% taken by mysql) and the system grinds to a halt.
Since I am using Apache::DBI, I thought there was meant to be 20 db
connections always, and no more or less.
I am pretty sure that we are always disconnecting our database connections
manually (Though doesn't Apache::DBI override that anyway, and keep one open
per apache process?).
Has anybody had similar issues? Any suggestions? Our apache startup script
is below.
Thanks,
John
/etc/httpd/perl/startup.pl
#!/usr/bin/perl
use strict;
# load up necessary perl function modules to be able to call from Perl-SSI
# files. These objects are reloaded upon server restart (SIGHUP or SIGUSR1)
# if PerlFreshRestart is On in httpd.conf (as of mod_perl 1.03).
# only library-type routines should go in this directory.
use lib /harnesslink/live_html/lib;
# make sure we are in a sane environment.
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die GATEWAY_INTERFACE not Perl!;
use Apache::Registry (); # for things in the /programs URL
use Apache::DBI;
use CGI ();
use Data::Dumper ();
use POSIX ();
use Carp ();
use Image::Magick ();
use HTML::Template ();
use Benchmark::Timer ();
use Date::Manip ();
use Class::Date ();
use MD5 ();
use FreezeThaw ();
use File::Scan ();
# pull in things we will use in most requests so it is read and compiled
# exactly once
use DBD::mysql ();
# Create persistant database connections
Apache::DBI-connect_on_init
(
DBI:mysql:harnesslink,
root,
,
{
AutoCommit = 1,
}
);
$Apache::DBI::DEBUG = 1;
1;
Re: $r-requires
Geoffrey Young wrote:
$r-requires() is read-only. conditional authentication is a bit
counterintuitive - you can't set up authentication where it doesn't
already exist because Apache won't run the authentication phase
without a Require directive in your httpd.conf. the solution is to
turn on authentication for everything, then turn it off where you
don't need/want it. see recipe 13.5 in the cookbook for more details.
the code for 13.5 can be found here:
Geoffrey,
Thanks for the tip. Allow me to flesh out this example a bit and the
solution I employed (thanks to Kip Cranford for having some helpful code
I was able to look at). Basically I'm creating a site where /admin and
/advertiser should have login forms for administrative users and
advertisers respectively while everything under / should not require any
type of access control.
Within the PerlTransHandler:
my $action = $r-uri;
#must strip of the leading slash
$action =~ s/^\///;
my ( $type, directions ) = (split /\//, $action);
if ($type eq 'admin'){
my ( $ret, $error_data ) = check_handlers( ['Apache::Control_admin'] );
if ($ret) {
$r-set_handlers( 'PerlAccessHandler' = [\_check_access] );
$r-push_handlers( 'PerlTransHandler' = 'Apache::Control_admin' );
$r-filename( $r-server_root_relative . htdocs );
return DECLINED;
} else {
$r-pnotes( 'ap_error_data_h', $error_data );
my $redir = http://; . $r-pnotes('ap_server_name_s') . /error;
$log-debug(Doing internal redirect to /error);
$r-internal_redirect($redir);
$r-filename( $r-server_root_relative . );
return DONE;
} ## end else
#end type eq ceoadmin
}elsif ($type eq 'advertiser' ){
blah blah blah
Despite not having a location tag anywhere, nor a require valid-user
directive, the above code
is able to accomplish my objective: loading an AccessHandler on the fly
from the TransHandler for specific urls on my site. Although, I must
admit that I'm not sure why it is working. _check_access is within the
same TransHandler module
so my assumption is that the reference to this sub gets executed
immediately and the result (OK DONE or DECLINED) gets shoved into the
set_handlers('PerlAccessHandler' = 'result gets shoved here') and then
my stacked TransHandler proceeds to the next module
(Apache::Control_admin).
Any explanation of why this actually works would be appreciated.
Rodney Hampton
Apache::Session - suggestion for man page
1)I am using Apache::Session::File to maintain state information (just a user_id and a few small items). 2)The man page for Apache::Session indicates that the following regexp should be used to find the session cookie. $cookie =~ s/SESSION_ID=(\w*)/$1/; 3)This $cookie value is then used in a tie statement. I was having intermittant trouble with MD5.pm dying and giving me internal server errors. The log file looked like this: [Wed Oct 16 21:45:47 2002] [error] Died at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Generate/MD5.pm line 40. 4)I found that when I had multiple cookies MD5 would always bomb out because the regexp was just stripping out the words SESSION_ID= 5)I added a few print STDERR statements and the log file looked like this: in common_session_utility 0 cookie is laptop=PadminHash9fa0065cd19a168c598a6ada6ec11917UAdministrator; SESSION_ID=d1a16efb540ac0cb16236f7782183c12 cookie is laptop=PadminHash9fa0065cd19a168c598a6ada6ec11917UAdministrator; d1a16efb540ac0cb16236f7782183c12 after regexp in common_session_utility 1 IN GENERATE MD5 session date is laptop=PadminHash9fa0065cd19a168c598a6ada6ec11917UAdministrator; d1a16efb540ac0cb16236f7782183c12 [Wed Oct 16 21:45:47 2002] [error] Died at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Generate/MD5.pm line 40. 6)After I changed the regexp, things started working well enough. $cookie =~ s/^.*SESSION_ID=(\w*).*$/$1/; 7)I suggest that the man page for Apache::Session so that the regexp example accomodates sites with multiple cookies being set. I hope this makes some sense. Regards, Rodney Hampton
