Re: Apache::Perfmon 0.011
On Mon, 21 Aug 2000, Lupe Christoph wrote: On Sunday, 2000-08-20 at 23:45:55 +0200, Stas Bekman wrote: Lupe, It seems to be broken. I cannot open the package. I've uploaded it again, and will be testing it myself. To be sure you get it, I'm attaching the tarball, it's minor, anyway. Thanks, Lupe. A few comments followed by the answer to your original question. make install Manifying blib/man3/Apache::Changes.3 Manifying blib/man3/Apache::Perfmon.3 Manifying blib/man3/Apache::README.3 Installing /usr/lib/perl5/site_perl/5.005/Apache/Perfmon.pm Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod Installing /usr/lib/perl5/man/man3/Apache::Changes.3 Installing /usr/lib/perl5/man/man3/Apache::Perfmon.3 Installing /usr/lib/perl5/man/man3/Apache::README.3 All these: Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod Installing /usr/lib/perl5/man/man3/Apache::Changes.3 Installing /usr/lib/perl5/man/man3/Apache::README.3 shoudn't happen. It misleads since you install Apache/Changes.pod and Apache/README.pod which can be interpeted as mod_perl base files. And of course there is no need to install these system wide. All you want is: Installing /usr/lib/perl5/site_perl/5.005/Apache/Perfmon.pm Installing /usr/lib/perl5/man/man3/Apache::Perfmon.3 The logfile is opened only once for each apache subprocess. This is done to reduce the overhead caused by this module, but it also means that logfile rotation can be painful. Why don't you open it at the server startup (when you preload Apache::Perfmon) and all the children will inherit the opened FH. Now the name -- it should be different. You've picked a name which is too generic, while it explores only one side of performance measuring. Doug has already a module called Apache::TimeIt from his book, whose idea is more or less the same. It was presented as an example and therefore has almost no code in it :) Since I work my self on Apache::Benchmark module, I'm thinking about putting all the performance monitoring and benchmarking modules under the same roof. Apache::Benchmark sounds like a good choice to me. Therefore I would suggest calling your module Apache::Benchmark::CPU and Apache::Benchmark::Handler (hmm, I think that it can be a good idea to have these two functions separated, therefore I've suggested these two different modules). I know that people aren't favorite of modules whose names are of more than 2 levels deepnees, but in order to insure a healthy ground for the future emerging modules, this "sacrificing" is a due. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re[2]: [OT] mod_proxy tuning info?
Hello Edward, ñðåäà, 16 àâãóñòà 2000 ã., you wrote: EM Yes, I have read that part of the mod_perl guide. I'm looking for a more EM detailed discussion on mod_proxy configuration and performance. EM But it doesn't answer the questions I have regarding the use of mod_proxy: EM * What affect does CacheGcInterval have on performance? mod_proxy garbage collector virtually don't work with large sites. I have to remove cache files manually via crontab. EM * Does setting CacheDirLevels to a high value cause a performance hit? EM * Does setting CacheDirLength to a small value increase performance? Don't think those two play a big role in mod_proxy performance. EM * How does performance scale with 1GB, 2GB, or 4GB of memory? It doesn't matter, as long as mod_proxy doesn't do memory caching. EM * How do you determine the overall hit rate? The hit rate from ram? The EM hit EM rate from disk? see previous. EM * There are dynamic pages I want cached for a certain TTL. There are other EM dynamic pages I don't want cached at all. Do I have to use the NoCache EM directive on all the directories/files I don't want cached? Or is there a EM more effective way to do this? Check patches at: http://www.w-m.ru/~ilya/source/apache/xfire_patches1.3.9.tar.gz There's some functionality additions. Note: it doesn't work with apache versions other than 1.3.9. Best regards, Ilyamailto:[EMAIL PROTECTED]
Re: setting LD_LIBRARY_PATH via PerlSetEnv does not work
It worked like a charm! If PerlSetEnv could not do it, I think this should be documented in the guide. I could not find any mention about ldconfig in the modperl guide. May be I missed it somehow. The procedure on linux is very simple: # echo $ORACLE_HOME/lib /etc/ld.so.conf # ldconfig Thanks Richard On Sun, Aug 20, 2000 at 08:11:50PM -0700, Yann Ramin wrote: As far as FreeBSD goes, LD_LIBRARY_PATH is not searched for setuid programs (aka, Apache). This isn't a problem for CGIs since they don't do a setuid (and are forked off), but Apache does, and mod_perl is in Apache. I think thats right anyway :) You could solve this globaly by running ldconfig (I assume Linux has it, FreeBSD does). You'd be looking for: ldconfig -m your directory here Hope that helps. Yann Richard Chen wrote: This is a redhat linux 6.2 box with perl 5.005_03, Apache 1.3.12, mod_perl 1.24, DBD::Oracle 1.06, DBI 1.14 and oracle 8.1.6. For some odd reason, in order to use DBI, I have to set LD_LIBRARY_PATH first. I don't think I needed to do this when I used oracle 7. This is fine on the command line because I can set it in the shell environment. For cgi scripts, the problem is also solved by using apache SetEnv directive. However, this trick does not work under modperl. I had tried PerlSetEnv to no avail. The message is the same as if the LD_LIBRARY_PATH is not set: install_driver(Oracle) failed: Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.8.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169. at (eval 27) line 3 Perhaps a required shared library or dll isn't installed where expected at /usr/local/apache/perl/tmp.pl line 11 Here is the section defining LD_LIBRARY_PATH under Apache::Registry: PerlModule Apache::Registry Alias /perl/ /usr/local/apache/perl/ Location /perl PerlSetEnv LD_LIBRARY_PATH /u01/app/oracle/product/8.1.6/lib SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On allow from all /Location Does anyone know why PerlSetEnv does not work in this case? How come SetEnv works for cgi scripts? What is the work around? Thanks for any info. Richard -- Yann Ramin[EMAIL PROTECTED] Atrus Trivalie Productionswww.redshift.com/~yramin Monterey High IT www.montereyhigh.com ICQ 46805627 AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer (yes, this .signature is way too big) "All cats die. Socrates is dead. Therefore Socrates is a cat." - The Logician THE STORY OF CREATION In the beginning there was data. The data was without form and null, and darkness was upon the face of the console; and the Spirit of IBM was moving over the face of the market. And DEC said, "Let there be registers"; and there were registers. And DEC saw that they carried; and DEC seperated the data from the instructions. DEC called the data Stack, and the instructions they called Code. And there was evening and there was a maorning, one interrupt... -- Rico Tudor William Safire's Rules for Writers: Remembe
Re: setting LD_LIBRARY_PATH via PerlSetEnv does not work
On Mon, 21 Aug 2000, Richard Chen wrote: It worked like a charm! If PerlSetEnv could not do it, I think this should be documented in the guide. I could not find any mention done. thanks for the tip! about ldconfig in the modperl guide. May be I missed it somehow. The procedure on linux is very simple: # echo $ORACLE_HOME/lib /etc/ld.so.conf # ldconfig Thanks Richard On Sun, Aug 20, 2000 at 08:11:50PM -0700, Yann Ramin wrote: As far as FreeBSD goes, LD_LIBRARY_PATH is not searched for setuid programs (aka, Apache). This isn't a problem for CGIs since they don't do a setuid (and are forked off), but Apache does, and mod_perl is in Apache. I think thats right anyway :) You could solve this globaly by running ldconfig (I assume Linux has it, FreeBSD does). You'd be looking for: ldconfig -m your directory here Hope that helps. Yann Richard Chen wrote: This is a redhat linux 6.2 box with perl 5.005_03, Apache 1.3.12, mod_perl 1.24, DBD::Oracle 1.06, DBI 1.14 and oracle 8.1.6. For some odd reason, in order to use DBI, I have to set LD_LIBRARY_PATH first. I don't think I needed to do this when I used oracle 7. This is fine on the command line because I can set it in the shell environment. For cgi scripts, the problem is also solved by using apache SetEnv directive. However, this trick does not work under modperl. I had tried PerlSetEnv to no avail. The message is the same as if the LD_LIBRARY_PATH is not set: install_driver(Oracle) failed: Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.8.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169. at (eval 27) line 3 Perhaps a required shared library or dll isn't installed where expected at /usr/local/apache/perl/tmp.pl line 11 Here is the section defining LD_LIBRARY_PATH under Apache::Registry: PerlModule Apache::Registry Alias /perl/ /usr/local/apache/perl/ Location /perl PerlSetEnv LD_LIBRARY_PATH /u01/app/oracle/product/8.1.6/lib SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On allow from all /Location Does anyone know why PerlSetEnv does not work in this case? How come SetEnv works for cgi scripts? What is the work around? Thanks for any info. Richard -- Yann Ramin [EMAIL PROTECTED] Atrus Trivalie Productions www.redshift.com/~yramin Monterey High ITwww.montereyhigh.com ICQ 46805627 AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer (yes, this .signature is way too big) "All cats die. Socrates is dead. Therefore Socrates is a cat." - The Logician THE STORY OF CREATION In the beginning there was data. The data was without form and null, and darkness was upon the face of the console; and the Spirit of IBM was moving over the face of the market. And DEC said, "Let there be registers"; and there were registers. And DEC saw that they carried; and DEC seperated the data from the instructions. DEC called the data Stack, and the instructions they called Code. And there was evening and there was a maorning, one interrupt... -- Rico Tudor William Safire's Rules for Writers: Remembe _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Anyone get Apache::PerlVINC to work?
I have managed to get Apache::PerlVINC to work on the following configuration: Apache/1.3.6 (Unix) mod_perl/1.21 mod_ssl/2.3.5 OpenSSL/0.9.3a but never on Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.8 OpenSSL/0.9.4 I am still not sure why it doesn't work on the second config (seemed a problem with mod_ssl), but as that is our production box I don't really want Apache::PerlVINC on there anyway. I don't think this will help you very much, but I thought I mention it anyway. Kees
Re: expiring pages with mod_perl
Jamie Krasnoo wrote: Sorry for the newbie question but could anyone tell me how to expire pages so a user can't use the back button to get back to that page? There is a good summary here: http://www.pacificnet.net/~johnr/meta.html Note the failure of IE4 to follow basic Pragma syntax (and their workarounds). In my experience, IE4 and IE5 - under certain circumstances - still seem to cache stuff at will. Regards Andreas -- | Andreas Schiffler [EMAIL PROTECTED] | | Senior Systems Engineer - Deskplayer Inc., Buffalo | | 4707 Eastwood Cres., Niagara Falls, Ont L2E 1B4, Canada | | +1-905-371-3652 (private) - +1-905-371-8834 (work/fax) |
HELP: problem with environment in different instances of mod_perl ?
hi folks, i have a problem which seems to occurs just in some of the instances of mod_perl. most of the time the script runs right, but sometimes it shows the error: Can't locate Lib/Mail.pm in @INC (@INC contains: ... when i press "reload" and send the form-data again it works, if i press reload several times, the error shows up again after the 2nd-5th time. "Lib/Mail.pm" is located in . , so it seems to be a problem with the environment, any ideas ? (i hardcoded the path into the script as a workaround, but would prefer a clean solution.) i'm using: Server: Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.4 OpenSSL/0.9.5 httpd.conf-part is: Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI Authtype Basic ... /Location thx arnim - Arnim Rupp Fon: +49-6221-13801-15 Connector GmbH Fax: +49-6221-13801-10 Hertzstrasse 2 Mail: [EMAIL PROTECTED] 69126 HeidelbergWeb: www.connector.de Germany Priv: www.rupp.de
RE: setting LD_LIBRARY_PATH via PerlSetEnv does not work
I ran into this exact same problem this weekend using: -GNU ld 2.9.1 -DBD::Oracle 1.06 -DBI 1.14 -RH Linux 6.0 -Oracle 8i Here's another, cleaner (I think) solution to your problem: after running perl Makefile.PL, modify the resulting Makefile as follows: 1. search for the line LD_RUN_PATH= 2. replace it with LD_RUN_PATH=(my_oracle_home)/lib (my_oracle_home) is, of course, the home path to your oracle installation. In particular, the file libclntsh.so.8.0 should exist in that directory. (If you use cpan, the build directory for DBD::Oracle should be in ~/.cpan/build/DBD-Oracle-1.06/ if you're logged in as root.) Then, just type make install, and all should go well. FYI, setting LD_RUN_PATH has the effect of hard-coding the path to (my_oracle_home)/lib in the resulting Oracle.so file generated by the DBD::Oracle so that at run-time, it doesn't have to go searching through LD_LIBRARY_PATH or the default directories used by ld. The reason I think this is cleaner is because this way, the Oracle directory is not hardcoded globally into everyone's link paths, which is what ldconfig does. For more information, check out the GNU man page on ld: http://www.gnu.org/manual/ld-2.9.1/html_mono/ld.html or an essay on LD_LIBRARY_PATH: http://www.visi.com/~barr/ldpath.html cheers, Ed -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, August 21, 2000 6:51 AM To: Richard Chen Cc: Yann Ramin; [EMAIL PROTECTED] Subject: Re: setting LD_LIBRARY_PATH via PerlSetEnv does not work On Mon, 21 Aug 2000, Richard Chen wrote: It worked like a charm! If PerlSetEnv could not do it, I think this should be documented in the guide. I could not find any mention done. thanks for the tip! about ldconfig in the modperl guide. May be I missed it somehow. The procedure on linux is very simple: # echo $ORACLE_HOME/lib /etc/ld.so.conf # ldconfig Thanks Richard On Sun, Aug 20, 2000 at 08:11:50PM -0700, Yann Ramin wrote: As far as FreeBSD goes, LD_LIBRARY_PATH is not searched for setuid programs (aka, Apache). This isn't a problem for CGIs since they don't do a setuid (and are forked off), but Apache does, and mod_perl is in Apache. I think thats right anyway :) You could solve this globaly by running ldconfig (I assume Linux has it, FreeBSD does). You'd be looking for: ldconfig -m your directory here Hope that helps. Yann Richard Chen wrote: This is a redhat linux 6.2 box with perl 5.005_03, Apache 1.3.12, mod_perl 1.24, DBD::Oracle 1.06, DBI 1.14 and oracle 8.1.6. For some odd reason, in order to use DBI, I have to set LD_LIBRARY_PATH first. I don't think I needed to do this when I used oracle 7. This is fine on the command line because I can set it in the shell environment. For cgi scripts, the problem is also solved by using apache SetEnv directive. However, this trick does not work under modperl. I had tried PerlSetEnv to no avail. The message is the same as if the LD_LIBRARY_PATH is not set: install_driver(Oracle) failed: Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.8.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169. at (eval 27) line 3 Perhaps a required shared library or dll isn't installed where expected at /usr/local/apache/perl/tmp.pl line 11 Here is the section defining LD_LIBRARY_PATH under Apache::Registry: PerlModule Apache::Registry Alias /perl/ /usr/local/apache/perl/ Location /perl PerlSetEnv LD_LIBRARY_PATH /u01/app/oracle/product/8.1.6/lib SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On allow from all /Location Does anyone know why PerlSetEnv does not work in this case? How come SetEnv works for cgi scripts? What is the work around? Thanks for any info. Richard -- Yann Ramin [EMAIL PROTECTED] Atrus Trivalie Productions www.redshift.com/~yramin Monterey High ITwww.montereyhigh.com ICQ 46805627 AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer (yes, this .signature is way too big) "All cats die. Socrates is dead. Therefore Socrates is a cat." - The Logician THE STORY OF CREATION In the beginning there was data. The data was without form and null, and darkness was upon the face of the console; and the Spirit of IBM was moving over the face of the market. And DEC said, "Let there be registers"; and there were registers. And DEC saw that they carried; and DEC seperated the data from the instructions. DEC called the data Stack, and the
Producing an error page
Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264
RE: Producing an error page
http://perl.apache.org/guide/snippets.html#Redirecting_Errors_to_the_Client HTH --Geoff -Original Message- From: Jay Strauss [mailto:[EMAIL PROTECTED]] Sent: Monday, August 21, 2000 9:56 AM To: [EMAIL PROTECTED] Subject: Producing an error page Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264
Re: Producing an error page
Have a look at CGI::Carp. Jay Strauss wrote: Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? Cheers -- Tim Sweetman
Re: Producing an error page
On Mon, 21 Aug 2000, Jay Strauss wrote: --- #!/usr/bin/perl -w use strict; use diagnostics; Try adding: use CGI::Carp; # send error messages to browser ($first, $second) = @ARGV; Try: my ($first, $second) = @ARGV; You may also want to check "my" in a Perl book, just so you know what it does :-) // Flemming -- Flemming Mahler Larsen, Tele Danmark Internet http://projekt.tele.dk.net/about/mahler.html // +45 3527 9013
ANNOUNCE: mod_perl Guide ver. 1.26
A new version of the mod_perl guide has been released. CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.26.tar.gz size: 451448 bytes md5: 37a07ec5f147f75ed9b5b2fc8359adeb Online: HTML: http://perl.apache.org/guide/ PDF : http://perl.apache.org/guide/mod_perl_guide.pdf.gz (size: 641pp) CVS : http://stason.org/guide-snapshots/ This "early" release was mainly triggered by decoupling the guide from it's build code. The build code is now generic (decoupled from the guide) and can be used for any documentation project. The new module is called Pod::HtmlPsPdf and will be announced shortly. Changes: * mod_perl guide's build process is now completely migrated into an external module, distributed in package Pod::HtmlPSPdf. * install.pod: Raven SSL installation notes updated (Doug, Geoffrey Young) * troubleshooting.pod: install_driver(Oracle) failed: Can't load '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, Richard Chen) * security.pod: a code sample in "Non authenticated access for internal IPs, Authenticated for external IPs" is corrected (Will Trillich) * porting.pod: "CHECK Blocks" (Doug) * scenario.pod: "The dual server installation scenario was complete rewritten, to accomodate a better in my opinion directories layout and simpler installation process" * perl.pod: "Exception Handling for mod_perl" was improved by Matt Sergeant. * Minor corrections: o config (Ron Pero) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
[H/OT] ANNOUNCE: Pod::HtmlPsPdf ver 0.01
[H/OT] == half / off topic :) I've just released the Pod::HtmlPsPdf (which used to be a part of the guide's building code). It's off topic since it has nothing to do with mod_perl. It's on topic since you need it to build the guide (and soon other mod_perl docs). CPAN: file: $CPAN/authors/id/S/ST/STAS/Pod-HtmlPsPdf-0.01.tar.gz size: 118932 bytes md5: d90736fc993fe71fdaaa0988ee2a16e4 NAME Pod::HtmlPsPdf - documentation projects builder in HTML, PS and PDF formats SYNOPSYS pod2hpp [options] configuration_file_location Options: -hthis help -vverbose -ipodify pseudo-pod items (s/^* /=item */) -screate the splitted html version -tcreate tar.gz -pgenerate PS file -dgenerate PDF file -fforce a complete rebuild -aprint available hypertext anchors -ldo hypertext links validation -mexecuted from Makefile (forces rebuild, no PS/PDF file, no tgz archive!) DESCRIPTION This code knows to do following with a collection of your POD files. 1 Generate HTMLs 2 Generate a split version HTML, creating html file for each pod section, and having everything interlinked of course. This version is used best for the search. 3 Generate a single book-like version in PostScript format 4 Generate a single book-like version in PDF format 5 Complete the POD on the fly from the files in POD format. This is used to ease the generating of the presentations slides, so one can use `*' instead of a long =over/=item/.../=item/=back strings. The rest is done as before. Take a look at the special version of the html2ps format to generate nice slides in *conf/html2ps-slides.conf*. You can customise the look and feel of the HTML files, PS and therefore the PDF by tweaking the template files in *./tmpl* directory. You can change look and feel of the PS (PDF) versions by modifying *./conf/html2ps.conf*. Be careful that if your documentation that you want to put in one PS or PDF file is very big and you tell html2ps to put the TOC at the beginning you will need lots of memory because it won't write a single byte to the disk before it gets all the HTML markup converted to PS. To generate HTML this code use a slightly modified version of the `Pod::Html' code and than does a lot of massage on the resulting HTML. I've tried to keep the pod2html code modified as little as possible, so when a new versions of the original `Pod::Html' module will be released I'll be able to merge the changes with my version. EXTENDED POD SYNTAX I've extended the POD syntax to accomodate my own needs. Note that this can be always converted back to the standard POD. To see the extended syntax, refer to the *docs/extended_pod.pod* in the package distribution. CONFIGURATION All you have to prepare is a single config file that you then pass as an argument to `pod2hpp': pod2hpp [options] /full/path/to/config/file Use the file *project.config* supplied in the directory *sample*. Modify it to be suit your documentation project layout. Note that *sample/bin/build* script automatically locates your project's directory, so you can move your project around filesystem without changing anything. *sample/README.sample* explains the layout of the directories. The easiest way to learn to use this package is to look at the `Apache::mod_perl_guide' package available at CPAN. I've developed the package `Pod::HtmlPsPdf' especially for `Apache::mod_perl_guide'. PREREQUISITES All these are not required if all you want is to generate only the html version. * ps2pdf Needed to generate the PDF version * Storable Perl module available from CPAN (http://cpan.org/) Allows source modification control, so if you modify only one file you will not have to rebuild everything to get the updated HTML/PS/PDF files. SUPPORT Notice that this tool relies on two tools (ps2pdf and html2ps) which I don't support. So if you have any problem first make sure that it's not a problem of these tools. Note that while `html2ps' is included in this distribution, it's written in the old style Perl, so if you have patches send them along, but I won't try to fix/modify this code otherwise. I didn't write this utility. This package works for me on Linux RedHat and Mandrake systems. I release it only to share. Unfortunately I don't have time to help with each available platform. If you have a problem, please don't contact me. I'm not going to solve it. If you solve the problem, I'll gladly accept the patch for others to benefit. Remember that this is a free software. BUGS Huh? Probably
RE: Producing an error page
Jay, although others have recommended you look at the mod_perl guide and
CGI::Carp, I don't think these are exactly what you're looking for. The
errors you are getting are generated because of 'use strict;' and occur at
compile time; CGI::Carp is capable of redirecting errors to the browser (if
you type "use CGI::Carp 'fatalsToBrowser'"). Hence your script doesn't get
to run at all, and it doesn't produce anything on standard output. Your web
server redirects this STDOUT to the web browser and redirects STDERR to its
error log. Also, you never print a valid content-type header on STDOUT so
your web server can't grok it anyway. What you need to do is send your
ERRORS to STDOUT instead of STDERR and precede their output with
"Content-Type: text/plain\n\n". I am not totally sure this is possible
(it's a very odd thing to do) but you might try inserting this at the top of
your script (BEFORE 'use strict;'):
BEGIN { print "Content-Type: text/plain\n\n"; *STDERR = *STDOUT }
This is a BEGIN block which is evaluated at compile time.
I'll give this a try, and you can too. But I wouldn't be surprised if this
just resulted in weirder behavior. Chances are what you want to do isn't
really the best thing for your situation, perhaps you could describe your
reason for wanting this behavior. Good luck!
shimon.
p.s. This wasn't really a mod_perl related question, perhaps this wasn't the
best forum to ask it.
Jay Strauss said:
Hi,
I'm asking this again, due to lack of response (but I can't
believe no one out
there knows how to do this).
How do I produce an error page (in HTML), when I call the script
from a browser,
that looks just like the error screen I get when I run a script
at the command
line?
That is, if I run the following script from the command line:
---
#!/usr/bin/perl -w
use strict;
use diagnostics;
($first, $second) = @ARGV;
exit;
---
I'll get a whole bunch of messages telling me I "use strict" and I have
variables that I didn't define with "my".
But, if I call it from my browser, I just get back a "Internal
Server Error"
page. Instead I want all the diagnostics messages.
Thanks
Jay
Jay Strauss
[EMAIL PROTECTED]
(h) 773.935.5326
(c) 312.617.0264
RE: setting LD_LIBRARY_PATH via PerlSetEnv does not work
On Mon, 21 Aug 2000, Ed Park wrote: I ran into this exact same problem this weekend using: -GNU ld 2.9.1 -DBD::Oracle 1.06 -DBI 1.14 -RH Linux 6.0 -Oracle 8i Here's another, cleaner (I think) solution to your problem: after running perl Makefile.PL, modify the resulting Makefile as follows: 1. search for the line LD_RUN_PATH= 2. replace it with LD_RUN_PATH=(my_oracle_home)/lib (my_oracle_home) is, of course, the home path to your oracle installation. In particular, the file libclntsh.so.8.0 should exist in that directory. (If you use cpan, the build directory for DBD::Oracle should be in ~/.cpan/build/DBD-Oracle-1.06/ if you're logged in as root.) Then, just type make install, and all should go well. FYI, setting LD_RUN_PATH has the effect of hard-coding the path to (my_oracle_home)/lib in the resulting Oracle.so file generated by the DBD::Oracle so that at run-time, it doesn't have to go searching through LD_LIBRARY_PATH or the default directories used by ld. The reason I think this is cleaner is because this way, the Oracle directory is not hardcoded globally into everyone's link paths, which is what ldconfig does. For more information, check out the GNU man page on ld: http://www.gnu.org/manual/ld-2.9.1/html_mono/ld.html or an essay on LD_LIBRARY_PATH: http://www.visi.com/~barr/ldpath.html Updated. Thanks Ed! Is there a way to set LD_RUN_PATH automatically during the: perl Makefile.PL stage, compared to a manual modification of the resulting Makefile? like: perl Makefile.PL LD_RUN_PATH=/foo/bar/lib ? cheers, Ed -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, August 21, 2000 6:51 AM To: Richard Chen Cc: Yann Ramin; [EMAIL PROTECTED] Subject: Re: setting LD_LIBRARY_PATH via PerlSetEnv does not work On Mon, 21 Aug 2000, Richard Chen wrote: It worked like a charm! If PerlSetEnv could not do it, I think this should be documented in the guide. I could not find any mention done. thanks for the tip! about ldconfig in the modperl guide. May be I missed it somehow. The procedure on linux is very simple: # echo $ORACLE_HOME/lib /etc/ld.so.conf # ldconfig Thanks Richard On Sun, Aug 20, 2000 at 08:11:50PM -0700, Yann Ramin wrote: As far as FreeBSD goes, LD_LIBRARY_PATH is not searched for setuid programs (aka, Apache). This isn't a problem for CGIs since they don't do a setuid (and are forked off), but Apache does, and mod_perl is in Apache. I think thats right anyway :) You could solve this globaly by running ldconfig (I assume Linux has it, FreeBSD does). You'd be looking for: ldconfig -m your directory here Hope that helps. Yann Richard Chen wrote: This is a redhat linux 6.2 box with perl 5.005_03, Apache 1.3.12, mod_perl 1.24, DBD::Oracle 1.06, DBI 1.14 and oracle 8.1.6. For some odd reason, in order to use DBI, I have to set LD_LIBRARY_PATH first. I don't think I needed to do this when I used oracle 7. This is fine on the command line because I can set it in the shell environment. For cgi scripts, the problem is also solved by using apache SetEnv directive. However, this trick does not work under modperl. I had tried PerlSetEnv to no avail. The message is the same as if the LD_LIBRARY_PATH is not set: install_driver(Oracle) failed: Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.8.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169. at (eval 27) line 3 Perhaps a required shared library or dll isn't installed where expected at /usr/local/apache/perl/tmp.pl line 11 Here is the section defining LD_LIBRARY_PATH under Apache::Registry: PerlModule Apache::Registry Alias /perl/ /usr/local/apache/perl/ Location /perl PerlSetEnv LD_LIBRARY_PATH /u01/app/oracle/product/8.1.6/lib SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On allow from all /Location Does anyone know why PerlSetEnv does not work in this case? How come SetEnv works for cgi scripts? What is the work around? Thanks for any info. Richard -- Yann Ramin[EMAIL PROTECTED] Atrus Trivalie Productionswww.redshift.com/~yramin Monterey High IT www.montereyhigh.com ICQ 46805627 AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer (yes, this .signature is way too big) "All cats die. Socrates is dead. Therefore Socrates is a cat." - The Logician
Re: Anyone get Apache::PerlVINC to work?
sorry for the late reply but.. i've never personally used PerlVINC on any version of mod_perl 1.24, i had experienced the silent death on startup problem myself with both versions of VINC. upgrading Apache::ExtUtils fixed it for me. the fix is not part of any official mod_perl release. ie you have to get it from the cvs snapshot. http://perl.apache.org/from-cvs/modperl/ you dont need to install the whole thing, just the latest version of Apache::ExtUtils. its needed for when you compile and install PerlVINC. the version you need is 1.04 and the version that comes with mod_perl 1.24 is 1.03. just run this on the command line to see which version you have: perl -MApache::ExtUtils -e'print $Apache::ExtUtils::VERSION."\n";' even with this, i dont know for sure that it (VINC) will work with any version mod_perl before 1.24. i simply dont have the time to test against every version. if you cant get it to work with 1.22, maybe it is time for an upgrade. dave On Sat, 19 Aug 2000, Stas Bekman wrote: On Fri, 18 Aug 2000, Tom Lancaster wrote: That's the version I'm using, and it's in the docs for that module that the problem I'm having is described. It claims to be fixable by using the latest ExtUtils. I guess not :( Oh, Ok. I thought I've been using an older version of it. I suppose I'd better update my mod_perl. Definitely worth to give it a try. Stas Bekman wrote: On Fri, 18 Aug 2000, Tom Lancaster wrote: I get the behaviour described in the BUGS section of the docs: server silently fails to start. However, I'm using the latest version of Apache::ExtUtils, as recommended. Also using mod_perl 1.22, Apache 1.3.12, Apache::ASP 2.03. Has anyone got PerlVINC to work with this combo? Use the latest version, it's not a part of the Apache::ExtUtils, but distributed in a separate package: Module id = Apache::PerlVINC CPAN_USERID DAVEM (Dave Moore [EMAIL PROTECTED]) CPAN_VERSION 0.02 CPAN_FILED/DA/DAVEM/Apache-PerlVINC-0.02.tar.gz MANPAGEApache::PerlVINC - Allows versioning of modules among directories or v-hosts. It's about a time to upgrade the mod_perl server as well :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org -- Dave Moore Web Application Developer mailto:[EMAIL PROTECTED] ePALS Classroom Exchange http://www.epals.com/ Connecting more than 1.9 million students and teachers in 182 countries!
Re: PerlAuthenHandler -- doesn't get there...? SOLVED
[ previous discussion snipped ] httpd.conf or .htaccess (PerlModule hasta be in httpd.conf, from my experience)-- PerlAccessHandler My::Auth::access_handler PerlSetVar Intranet "10.10.10.1 = userA, 10.10.10.2 = userB" PerlAuthenHandler My::Auth::authen_handler AuthName realm AuthType Basic Require valid-user order deny,allow deny from all # # add 'order/deny', and we're done (as far as i can tell) # Before any changes to the Guide solidify out of this, I'd like to know that we're not pushing bad information into it. - order, deny, allow are all handled by mod_access, which worries about hostname- and IP address-based restrictions. - AuthType Basic is handled right in the core Apache code, where it, along with digest, is special-cased for in http_request and elsewhere. You aren't really doing Basic auth with your module, are you? That is, you're not putting the Auth-Required headers into your responses (to cause the browser to prompt for credentials) if you don't see the Basic auth headers in the requests, right? I'm using Apache::AuthCookie, not doing this from scratch, so that clouds things a bit for me, but I've been looking at Apache's behaviour a lot. Here's my test config (for Apache::AuthCookie): Location /some/where AllowOverride None Options +ExecCGI SetHandler cgi-script AuthType Site::AuthCookieHandler AuthName Testing PerlAuthenHandler Site::AuthCookieHandler-authenticate PerlAuthzHandler Site::AuthCookieHandler-authorize require valid-user /Location Notice that there are no order, allow, deny directives in sight, and this works as it should. If I truss apache while I hit this spot with a request, I see the results of the handlers being invoked, which in AuthCookie's case is a redirection to a login form. If I replace "AuthType Site::AuthCookieHandler" with "AuthType Basic", the handlers don't get invoked, and I instead see this error from apache: configuration error: couldn't check user. No user file?: /some/where This comes from http_request.c, which is responding to "AuthType Basic". It's giving an error because I haven't told it where to find a user file (AuthUserFile) or database (AuthDBMUserFile) to check requests against, but I've requested Basic auth. ...Steve -- Steve van der Burg Information Services London Health Sciences Centre (519) 685-8300 ext 35559 [EMAIL PROTECTED]
Re: Producing an error page
Sorry,
I didn't explain my question well. But thanks for all the response.
I left "my" out of my example on purpose, to illustrate a typical (in my case)
programming error.
To restate what I'm asking:
Is there any way to redirect everything that would normally be sent to the
screen, when I run from the command line, to an HTML page when I call my script
from the browser (on a script by script basis).
I've tried the suggestions so far:
cgi::carp
http://perl.apache.org/guide/snippets.html#Redirecting_Errors_to_the_Client
BEGIN { print "Content-Type: text/plain\n\n"; *STDERR = *STDOUT }
None of these methods will print the diagnostic messages, and typically only
print the line number at which I died.
I'm not in a production environment, so I don't mind getting a bunch of ugly
errors to my browser.
Thanks again
Jay
Jay Strauss
[EMAIL PROTECTED]
(h) 773.935.5326
(c) 312.617.0264
- Original Message -
From: "Jay Strauss" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 21, 2000 8:56 AM
Subject: Producing an error page
Hi,
I'm asking this again, due to lack of response (but I can't believe no one out
there knows how to do this).
How do I produce an error page (in HTML), when I call the script from a
browser,
that looks just like the error screen I get when I run a script at the command
line?
That is, if I run the following script from the command line:
---
#!/usr/bin/perl -w
use strict;
use diagnostics;
($first, $second) = @ARGV;
exit;
---
I'll get a whole bunch of messages telling me I "use strict" and I have
variables that I didn't define with "my".
But, if I call it from my browser, I just get back a "Internal Server Error"
page. Instead I want all the diagnostics messages.
Thanks
Jay
Jay Strauss
[EMAIL PROTECTED]
(h) 773.935.5326
(c) 312.617.0264
Re: Milage may vary comments
On Fri, 18 Aug 2000, George Sanderson wrote: snip 2) 'Do not': "PerlFreshRestart On" in httpd.conf. Curiously enough, "PerlFreshRestart On" has always worked for me, even on the production servers. It's pretty damn useful too, giving servers a graceful restart everytime you upload a module... it'd be a pain to have to fully restart the server every time, that would mean like 10 seconds of downtime for the whole site. It's even more useful if you want to cache a large quantity of data in ram with the root process and then periodically refresh that data. I agree! What was happening to me, was that with "PerlFreshRestart On", I would get a segmentation fault every time used AutoIndex.pm. I removed the directive and the problem went away. I have seen other references to memory leaks and such. If anyone has suggestions as to why the "PerlFreshRestart On" would aggervate segment faults, I would like to here them. Some perl modules don't take well to being reinitialized. Stas mentions it in the guide, and it's been noted quite a few times here on the mailing list. Personally, I've never run into any modules that gave me any problems but I know they are out there. -- Douglas Leonard [EMAIL PROTECTED]
Apache::Icon fix
with the patch below, Apache::Icon/Apache::AutoIndex works fine for me. running apache_1.3.13-dev, mod_perl-1.24_01-dev, perl-current (5.7.0-dev) mod_perl built with EVERYTHING=1, USE_DSO=1 copy-n-pasted config from Apache::AutoIndex/README: PerlModule Apache::Icon PerlModule Apache::AutoIndex PerlTransHandler Apache::AutoIndex::transhandler PerlHandler Apache::AutoIndex kill -HUP works just fine too. --- Icon.xs 1999/01/18 19:21:46 1.1.1.1 +++ Icon.xs 2000/08/21 16:50:04 @@ -18,6 +18,12 @@ PROTOTYPES: DISABLE +void +END() + +CODE: +ap_remove_module(icon_module); + Apache::Icon new(class, r=default_r) char *class
Re: cgis and subrequests
On Sun, 20 Aug 2000, Alex Menendez wrote: unfortunately, I am not entirely sure what a cgi is going to output all the time. The cgi might try to do a redirect using the Location field. Therefore, I don't think I can simply send_http_headers as type text/html... right, my $lookup = $r-lookup_uri( $uri ); $r-send_http_header( 'text/html' ); so just change that line to: $lookup-send_http_header; and you'll get the content-type and headers generated by the subrequest. if there's a bug, it's in the book, subrequest-run() is not supposed to include headers in the output.
Re: send_http_header and subrequests
On Wed, 14 Jun 2000, Paul J. Lucas wrote:
The second example on p. 128 of the Eagle book sets the content
type and send the HTTP headers itself before running a
subrequest.
However, on p. 468, the documentation for the run() method says
in part:
When you invoke the subrequest's response handler in
this way, it will do everything a response handler is
supposed to, includinf sendinf the HTTP headers and the
document body. ... If you arevoking the subrequest
urn() method from within your own content handler, you
must not sen the HTTP headers and document body
yourself ...
These seem to contradict each other. From testing, however, it
seems as though the example on p. 128 is correct and the
documentation on p. 468 isn't. Is this true?
right, subrequest-run does not output headers.
my $sub_r = $r-lookup_file( $full_path );
my $status = $sub_r-status();
unless ( $status == DOCUMENT_FOLLOWS ) {
$r-log_error( "Can't look up $full_path" );
return $status;
}
$r-send_http_header( $sub_r-content_type() );
does it help if you change that to:
$sub_r-send_http_header;
?
Re: httpd.conf directive PerlHandler Apache::Hello-handler errors
On Thu, 10 Aug 2000, Ken Williams wrote:
To clarify - some handlers can be called using object-oriented
techniques, and some can't. The switch for this behavior is that the
handler is prototyped with ($$).
or with newer Perls:
sub handler : method {...}
Re: Cant set args to $r-arg(undef);
On Sun, 13 Aug 2000, Greg Cope wrote: Dear All Although this in no longer important to me, I cannot appear to reset $r-arg to an empty value. i think i already mentioned (but this message is not marked as replied), this is fixed in cvs.
Re: my transhandler runs only once in each child ?!?
On Mon, 14 Aug 2000, Matt Sergeant wrote:
On Sun, 13 Aug 2000, Greg Cope wrote:
Apache-push_handlers("PerlTransHandler", \transhandler);
push_handlers is temporary, not permanent. And this line only gets
executed once.
of course, if you wanted something like that, your module (if loaded at
startup) can do this:
{
package Apache::ReadConfig;
push @PerlTransHandler, join '::', __PACKAGE__, 'transhandler';
}
Re: Errors from Apache.pm
On Wed, 16 Aug 2000 [EMAIL PROTECTED] wrote: All, I am seeing the following errors in my apache error log. These have appeared since moving to a Linux/mod_perl1.24 combination (from NT/1.23) so I don't know if they come from 1.24 or from the -w switch being handled better under unix. Anyone know what these are and how to get rid of them ? I had a look but I really don't feel confident enough do start playing around with this module :-) [Wed Aug 16 17:45:12 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. [Wed Aug 16 17:45:12 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. [Wed Aug 16 17:45:13 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. that line is in send_cgi_header(), which means you've configured PerlSendHeader On. how is your code sending headers? looks like something that send_cgi_header() can't parse.
Re: mod_perl-1.24 - Make FAILS!
On Thu, 17 Aug 2000, Stephen Marriott wrote: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of `union semun' Perl version 5.005_03 built for i386-linux (2.0.36) this problem has been reported in the past, upgrading to a newer kernel has cured.
Re: Anyone get Apache::PerlVINC to work?
On Sat, 19 Aug 2000, Stas Bekman wrote: On Fri, 18 Aug 2000, Tom Lancaster wrote: I get the behaviour described in the BUGS section of the docs: server silently fails to start. However, I'm using the latest version of Apache::ExtUtils, as recommended. Also using mod_perl 1.22, Apache 1.3.12, Apache::ASP 2.03. Has anyone got PerlVINC to work with this combo? Use the latest version, it's not a part of the Apache::ExtUtils, but distributed in a separate package: the suggestion was to upgrade Apache::ExtUtils (to cvs version, w/ bug fix), which generates PerlVINC.xs.
Re: Anyone get Apache::PerlVINC to work?
Doug MacEachern wrote: the suggestion was to upgrade Apache::ExtUtils (to cvs version, w/ bug fix), which generates PerlVINC.xs. Where can I find this?
Re: cgis and subrequests
h,
I have tried what you suggested and it is still not generating the
headers. I have tried calling the send_http_header function both before
and after the handler switch and it still is not working. I think it is
bug but I am not sure. At any rate, here is some of the module code and
the http.conf directives:
my $uri = $r-uri;
unless(!$r-args) {
$uri = $uri .'?'.$r-args;
}
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-send_http_header;
$subr-run();
my $status = $subr-status;
$subr-print(create_img_tag($file,$SCRIPT_ON,$status));
return $status;
Files ~ "\.(html|htm|shtml|fhtml)$"
SetHandler perl-script
PerlHandler Macromedia::AddStatImage
/Files
Files ~ "\.(cgi|pl|sh)$"
SetHandler perl-script
PerlHandler Macromedia::AddStatImage
PerlSetVar is_cgi 1
/Files
any ideas?
-amen
On Mon, 21 Aug 2000, Doug MacEachern wrote:
On Sun, 20 Aug 2000, Alex Menendez wrote:
unfortunately, I am not entirely sure what a cgi is going to output all the
time. The cgi might try to do a redirect using the Location field. Therefore,
I don't think I can simply send_http_headers as type text/html...
right,
my $lookup = $r-lookup_uri( $uri );
$r-send_http_header( 'text/html' );
so just change that line to:
$lookup-send_http_header;
and you'll get the content-type and headers generated by the subrequest.
if there's a bug, it's in the book, subrequest-run() is not supposed to
include headers in the output.
Passing a hash to a cgi outside a form?
Hi there!
Sorry for this question which might sound easy to
you, but, does anyone know :
How can a CGI pass and receive a hash without a
form?
Please have a look at the
following simple scripts :
This is test.cgi
---
#!/usr/bin/perl
use CGI;
$list-{'value1'} =
'apple';$list-{'value2'} = 'fruit';
print "Location: test2.cgi?list=$list
\n\n";--
This is test2.cgi
--
#!/usr/bin/perl
use CGI qw (:standard);
print header;
$list = param('list');
foreach (keys
%{$list}){ print "KEY IN LIST
= ",$_,br;}
--
Thank you for your help
!
Re: param quirk
At 3:37 PM -0700 8/16/2000, Michael Blakeley wrote:
But the problem is that
[EMAIL PROTECTED]
also comes through as
email=mike [EMAIL PROTECTED]
instead of
[EMAIL PROTECTED]
Never mind; my test wasn't correct. Apparently wget decodes the input
URL before performing the fetch (it's lost some credibility with me).
Just for the record, the better test is to telnet directly to the
server port:
$ telnet localhost 80
GET /test?email=foo%2bbar HTTP/1.0
HTTP/1.1 200 OK
Server: Apache/1.3.9 (Unix) mod_perl/1.24
email=foo+bar
$ telnet localhost 80
GET /test?email=foo+bar HTTP/1.0
HTTP/1.1 200 OK
Server: Apache/1.3.9 (Unix) mod_perl/1.24
email=foo bar
The "test" handler is pretty obvious, but here's the heart of it:
my $tab = $r-{apr}-parms;
for (keys %$tab) {
$r-print("$_=" . $tab-{$_} . "\n");
}
Anyway, I wanted to close the loop in case anyone was wondering about
my sanity (it comes and goes).
-- Mike
Re: cgis and subrequests
whoops. yeah, $subr-send_http_header won't work for the same reason send_http_header() calls within run() do not. you'll just need to propagate subrequest info like so: my $subr = $r-lookup_uri($uri); $r-send_http_header($subr-content_type); $subr-run;
Re: Anyone get Apache::PerlVINC to work?
On Mon, 21 Aug 2000, Tom Lancaster wrote: Doug MacEachern wrote: the suggestion was to upgrade Apache::ExtUtils (to cvs version, w/ bug fix), which generates PerlVINC.xs. Where can I find this? % perldoc mod_perl_cvs
Building mod_perl and mod_jserv into same apache
We need to have mod_perl and mod_jserv in the same httpd file. I can build apache 1.3.9 for either mod_perl or mod_jserv using the appropriate make commands from the install docs and they work fine. I've tried to build a mod_perl httpd and then use ./configure \ --prefix=/usr/local/apache \ --activate-module=src/modules/jserv/libjserv.a on a apache build but then I get a mod_jserv httpd and mod_perl is gone. If I try to activate-module for both mod_perl and mod_jserv I get a lot of mod_perl errors. Suggestions would be appreciated. Jeff
Re: Producing an error page
The stuff that the server sends back comes from STDOUT if CGIs or within mod-perl, either $req-print or a regular print since it is tied. The error messages go to STDERR which apache redirects internalls so that the messages go to the error log. I don't know that it's possible and I'm certain it's not a good idea to try and circumvent that and send STDERR to the browser. And besides that, you'd still have to send content-type headers. I suppose you could write one perl program that executes your perl program of interest from within an eval block and capture the output that way. But isn't simply looking at the error log easier? -- Rob --On Monday, August 21, 2000 8:56 AM -0500 Jay Strauss [EMAIL PROTECTED] wrote: Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264 _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED]
Re: cgis and subrequests
ok, what about cgi's that generate Location: headers. Am I out of luck here? should I contemplate changing src for ap_run_sub_req thanx, -amen On Mon, 21 Aug 2000, Doug MacEachern wrote: whoops. yeah, $subr-send_http_header won't work for the same reason send_http_header() calls within run() do not. you'll just need to propagate subrequest info like so: my $subr = $r-lookup_uri($uri); $r-send_http_header($subr-content_type); $subr-run;
Re: Passing a hash to a cgi outside a form?
you can't do this, dude. test.cgi dies and so do all it's pointers to
structures in memory.
try looking at Apache::Registry or mod_perl with the Apache::Filter
mod.
Or if you want to keep these things as cgi's look at LWP which lets you
make http requests from within perl programs.
However, I would probably just make some subroutines that both cgis could
use via require or use. the memory structures still are destroyed when the
cgi dies.
It really depends if your intent is to reuse code or pass a
structure that is already in memory. if it is the former, look at LWP or
the subroutine example. if it is the former, checkout the mod_perl and
Filter stuff.
hope this helps,
-amen
On Mon, 21 Aug 2000, perl wrote:
Hi there!
Sorry for this question which might sound easy to you, but, does anyone know :
How can a CGI pass and receive a hash without a form?
Please have a look at the following simple scripts :
This is test.cgi
---
#!/usr/bin/perl
use CGI;
$list-{'value1'} = 'apple';
$list-{'value2'} = 'fruit';
print "Location: test2.cgi?list=$list \n\n";
--
This is test2.cgi
--
#!/usr/bin/perl
use CGI qw (:standard);
print header;
$list = param('list');
foreach (keys %{$list})
{
print "KEY IN LIST = ",$_,br;
}
--
Thank you for your help !
Re: cgis and subrequests
On Mon, 21 Aug 2000, Alex Menendez wrote:
ok, what about cgi's that generate Location: headers. Am I out of luck
here? should I contemplate changing src for ap_run_sub_req
doh, right, headers are not added until run(). no need to change
ap_run_sub_req, we can support this. with the patch below you can say
$subr-run(1), where 1 enables send_http_header() within subrequests.
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 19:38:32
@@ -1996,10 +2003,15 @@
"Apache::SubRequest::DESTROY(0x%lx)\n", (unsigned long)r));
int
-run(r)
+run(r, allow_send_header=0)
Apache::SubRequest r
+int allow_send_header
CODE:
+if (allow_send_header) {
+r-assbackwards = 0;
+}
+
RETVAL = run_sub_req(r);
OUTPUT:
Re: Centralized Caching
The BerkeleyDB module hasn't implemented DB-Env's USE_SYSTEM_MEMORY FLAG yet, but we've been using it (via tied hashes) for caching SSI output. It's about 100 times faster than using IPC::Shareable, and won't create shared memory segments behind your back. Unfortunately the eagle book's use of IPC::Shareable doesn't match the current version of this module. (AFAIK, there's little you can do now to keep IPC::Shareable from eating up your shared memory). It's not appropriate for mod_perl use. I would strongly recommend BerkeleyDB if you're only sharing variables, not objects. Be careful when compiling/installing BerkeleyDB on RedHat6.*, though! It's not compatible with Redhat's GNU libc ( it breaks nsswitch, and something else if you try naively installing it with the 'prefix=/usr' flag. Trust me- and read the install docs! ) -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
RE: Building mod_perl and mod_jserv into same apache
You have to activate both modules in order to build them into apache. I've built both together successfully. Your description suggests that your problem exists on the mod_perl side. What errors are you getting on the mod_perl side? --Original Message-- From: "Jeff Warner" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: August 21, 2000 6:56:18 PM GMT Subject: Building mod_perl and mod_jserv into same apache We need to have mod_perl and mod_jserv in the same httpd file. I can build apache 1.3.9 for either mod_perl or mod_jserv using the appropriate make commands from the install docs and they work fine. I've tried to build a mod_perl httpd and then use ./configure \ --prefix=/usr/local/apache \ --activate-module=src/modules/jserv/libjserv.a on a apache build but then I get a mod_jserv httpd and mod_perl is gone. If I try to activate-module for both mod_perl and mod_jserv I get a lot of mod_perl errors. Suggestions would be appreciated. Jeff
Re: Passing a hash to a cgi outside a form?
You might also try Data::Dumper to create eval-able expressions - hashes, arrays, and other complex objects. Dana
Re: Building mod_perl and mod_jserv into same apache
On Mon, 21 Aug 2000, Jeff Warner wrote: We need to have mod_perl and mod_jserv in the same httpd file. I can build apache 1.3.9 for either mod_perl or mod_jserv using the appropriate make commands from the install docs and they work fine. I've tried to build a mod_perl httpd and then use ./configure \ --prefix=/usr/local/apache \ --activate-module=src/modules/jserv/libjserv.a on a apache build but then I get a mod_jserv httpd and mod_perl is gone. If I try to activate-module for both mod_perl and mod_jserv I get a lot of mod_perl errors. Suggestions would be appreciated. http://perl.apache.org/guide/install.html#Installation_Scenarios_for_mod_p I think it should be easy to apply these notes to your case. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Apache::Session and performance question
Hi all,
We have a fairly simple handler responsible for maintaining
state on our web server. Unfortunately, when we activate
it, server performance drops to about 1/10th of what it is
without. After going through the handler and commenting
out parts and benchmarking (rinse, repeat), Apache::Session
appears to be the culprit.
I can't believe that the use of this module should have so
great an effect. We have to be doing something
incorrectly. Any advice would be greatly appreciated.
package Carescout::SessionHandler;
use strict;
use Apache;
use Apache::Session::DBI;
sub handler {
my ( $r ) = shift;
my ( $cookie ) = $r-header_in('Cookie') || undef;
$cookie =~ s/SESSION_ID=(\w*)/$1/o;
my ( %session );
tie %session, 'Apache::Session::DBI', $cookie,
{DataSource = 'dbi:mysql:cs',
UserName = 'nobody',
Password = ''
};
if ( ! $session{ acl } ) {
$session{ acl } = '0';
}
if ( ! $session{ uid } ) {
$session{ uid } = '99';
}
if ( ! $session{ services } ) {
$session{ services } = '0';
}
$r-subprocess_env( 'SESSION_ID' = $session{
_session_id } );
$r-subprocess_env( 'UID' = $session{ uid } );
$r-subprocess_env( 'ACL' = $session{ acl } );
$r-subprocess_env( 'SERVICES' = $session{ services }
);
my ( $session_cookie ) = "SESSION_ID=$session{
_session_id };path=/;";
tied( %session)-make_modified();
untie %session;# not sure if we need this
$r-header_out("Set-Cookie" = $session_cookie ) if !
$cookie;
}
1;
__END__
Thanks,
Chris
Re: Apache::Perfmon 0.011
On Monday, 2000-08-21 at 10:41:51 +0200, Stas Bekman wrote: On Mon, 21 Aug 2000, Lupe Christoph wrote: A few comments followed by the answer to your original question. Thanks! make install Manifying blib/man3/Apache::Changes.3 Manifying blib/man3/Apache::Perfmon.3 Manifying blib/man3/Apache::README.3 Installing /usr/lib/perl5/site_perl/5.005/Apache/Perfmon.pm Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod Installing /usr/lib/perl5/man/man3/Apache::Changes.3 Installing /usr/lib/perl5/man/man3/Apache::Perfmon.3 Installing /usr/lib/perl5/man/man3/Apache::README.3 All these: Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod Installing /usr/lib/perl5/man/man3/Apache::Changes.3 Installing /usr/lib/perl5/man/man3/Apache::README.3 shoudn't happen. It misleads since you install Apache/Changes.pod and Apache/README.pod which can be interpeted as mod_perl base files. And of course there is no need to install these system wide. All you want is: Blush. I didn't even use make install... I'll have to check how to suppress the installation of the PODs. Maybe I'll just leave them out of the dist and include Changes/README and their HTML versions. The logfile is opened only once for each apache subprocess. This is done to reduce the overhead caused by this module, but it also means that logfile rotation can be painful. Why don't you open it at the server startup (when you preload Apache::Perfmon) and all the children will inherit the opened FH. Meanwhile I thought about the situation where you have several virtual hosts, and want separate logging for each. I'll have to use a hash by the server name. I'll put that in later this week. Now the name -- it should be different. You've picked a name which is too generic, while it explores only one side of performance measuring. Doug has already a module called Apache::TimeIt from his book, whose idea is more or less the same. It was presented as an example and therefore has almost no code in it :) Mine has little more if any at all. :-) I can't find Apache::TimeIt with a cursory look in the book, so I'll have to browse some more when I have the time. Since I work my self on Apache::Benchmark module, I'm thinking about putting all the performance monitoring and benchmarking modules under the same roof. Apache::Benchmark sounds like a good choice to me. Hmm. Apache::Benchmark sounds more like a benchmark driver to me. Apache::Instrumentation or so? Apache::Probe? Therefore I would suggest calling your module Apache::Benchmark::CPU and Apache::Benchmark::Handler (hmm, I think that it can be a good idea to have these two functions separated, therefore I've suggested these two different modules). Sorry, I can't see where you want to divide this. The module has two probes (I'm beginning to like that word), and little more. Of course you could divide it in a realtime and a CPU probe... BTW, I forgot to put in a PREREQ_PM and a paragraph in the Requirements section of the README mentioning Time::HiRes. I know that people aren't favorite of modules whose names are of more than 2 levels deepnees, but in order to insure a healthy ground for the future emerging modules, this "sacrificing" is a due. I'm not opposed to this at all. Actually I've been thinking about Apache::Authfoo as Apache::Auth::foo for some time... Another shot at a good name: Apache::Probe::Simple? Leaving room for Apache::Probe::Sophisticated. ;-) I haven't registered this module with CPAN mainly because I was unsure of the appropriate name myself, and because I wasn't sure if somebody hadn't already written Apache::Probe::Sophisticated... Lupe -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur | | qbbzfnlref unir orra cebira jebat lrg ntnva." "qvq lbh frr gung | | gbb?" "ubhfgba. jr unir n ceboyrz." User Friendly 2000-01-01 |
RE: $r-get_handlers bug/oversight?
On Wed, 16 Aug 2000, Geoffrey Young wrote:
ack... so the alias only goes one way? I guess it makes sense that we
can't know at run time what the Init handler stands for, but how come
get_handlers('PerlInitHandler') comes up blank? Isn't it just a table
entry?
it's not in the get/set handler lookup table. just use
PostReadRequest/HeaderParser for now, we'll see about making Init do the
right thing with get/set handlers later.
well, it got the handler ok, but I couldn't set it properly:
#!/usr/bin/perl
my $r = shift;
$r-set_handlers(PerlCleanupHandler = [\cleanup]);
$r-send_http_header('text/plain');
print "done";
sub cleanup {
warn "hi";
}
is a no go. same with using ['My::Cleanup'] as the arg...
ok, fixed, problem described in new Apache.xs comment:
/* since register_cleanups are fifo, and the already registered
* mod_perl_end_cleanup() runs PerlCleanupHandlers, PerlCleanupHandler
* needs to maintain the refcnt itself
*/
I also noticed that the patch didn't fix the get_handlers() coderef bug:
#!/usr/bin/perl
my $r = shift;
$r-push_handlers(PerlCleanupHandler = sub { warn "hi"; });
#my $handlers = $r-get_handlers('PerlCleanupHandler');
$r-send_http_header('text/plain');
print "done";
uncomment the get_handlers() line and the cleanup handler never runs and you
get "Attempt to free unreferenced scalar"
i see the problem, perl_handler_merge_avs() did not increment the
reference counts during av_push(). below is the current patch against cvs
which fixes both problems. thanks for testing geoff!
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.103
diff -u -r1.103 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 22:33:32
@@ -73,12 +73,6 @@
void (*set_func) (void *, void *, SV *);
} perl_handler_table;
-typedef struct {
-I32 fill;
-AV *av;
-AV **ptr;
-} perl_save_av;
-
static void set_handler_dir (perl_handler_table *tab, request_rec *r, SV *sv);
static void set_handler_srv (perl_handler_table *tab, request_rec *r, SV *sv);
@@ -101,77 +95,78 @@
{HandlerDirEntry("PerlFixupHandler", PerlFixupHandler)},
{HandlerDirEntry("PerlHandler", PerlHandler)},
{HandlerDirEntry("PerlLogHandler", PerlLogHandler)},
+{HandlerDirEntry("PerlCleanupHandler", PerlCleanupHandler)},
{ FALSE, NULL }
};
-static void perl_restore_av(void *data)
-{
-perl_save_av *save_av = (perl_save_av *)data;
-
-if(save_av-fill != DONE) {
- AvFILLp(*save_av-ptr) = save_av-fill;
-}
-else if(save_av-av != Nullav) {
- *save_av-ptr = save_av-av;
-}
-}
-
static void perl_handler_merge_avs(char *hook, AV **dest)
{
int i = 0;
HV *hv = perl_get_hv("Apache::PerlStackedHandlers", FALSE);
SV **svp = hv_fetch(hv, hook, strlen(hook), FALSE);
AV *base;
-
+
if(!(svp SvROK(*svp)))
return;
base = (AV*)SvRV(*svp);
for(i=0; i=AvFILL(base); i++) {
SV *sv = *av_fetch(base, i, FALSE);
- av_push(*dest, sv);
+ av_push(*dest, SvREFCNT_inc(sv));
}
}
+#define avptr_from_offset(ptr, tab) \
+(AV **)((char *)ptr + (int)(long)tab-offset)
+
static void set_handler_base(void *ptr, perl_handler_table *tab, pool *p, SV *sv)
{
-AV **av = (AV **)((char *)ptr + (int)(long)tab-offset);
+int do_register_cleanup = 0;
+AV **av = avptr_from_offset(ptr, tab);
-perl_save_av *save_av =
- (perl_save_av *)palloc(p, sizeof(perl_save_av));
-
-save_av-fill = DONE;
-save_av-av = Nullav;
-
-if((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
- if(AvTRUE(*av)) {
- save_av-fill = AvFILL(*av);
- AvFILLp(*av) = -1;
- }
-}
-else if(SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
- if(AvTRUE(*av))
- save_av-av = av_copy_array(*av);
- *av = (AV*)SvRV(sv);
- ++SvREFCNT(*av);
+if ((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
+if (!*av) {
+do_register_cleanup = 1;
+}
+if (*av SvREFCNT(*av)) {
+SvREFCNT_dec(*av);
+}
+*av = newAV();
+}
+else if (SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
+*av = (AV*)SvRV(sv);
+++SvREFCNT(*av);
+do_register_cleanup = 1;
}
else {
- croak("Can't set_handler with that value");
+croak("Can't set_handler with that value");
+}
+
+/* since register_cleanups are fifo, and the already registered
+ * mod_perl_end_cleanup() runs PerlCleanupHandlers, PerlCleanupHandler
+ * needs to maintain the refcnt itself
+ */
+if (do_register_cleanup strNE(tab-name, "PerlCleanupHandler")) {
+register_cleanup(p, (void*)*av, mod_perl_cleanup_av, mod_perl_noop);
}
-save_av-ptr = av;
-register_cleanup(p,
Re: Apache::Session and performance question
On Mon, 21 Aug 2000, Chris Brooks wrote: We have a fairly simple handler responsible for maintaining state on our web server. Unfortunately, when we activate it, server performance drops to about 1/10th of what it is without. After going through the handler and commenting out parts and benchmarking (rinse, repeat), Apache::Session appears to be the culprit. I can't believe that the use of this module should have so great an effect. We have to be doing something incorrectly. Any advice would be greatly appreciated. You are using Apache::DBI, right? Going to the database on every single request is going to be expensive. If the rest of your application doesn't normally hit the database it makes sense for this to have a significant impact. - Perrin
problem with mod_proxy/mod_rewrite being used for the front-end proxy
This isn't entirely on-topic but it's a solution often suggested for mod_perl
users so I suspect there are other users here being bitten by the same
problems. In fact the manner in which problems manifest are such that it's
possible that many mod_perl users who are using mod_rewrite/mod_proxy to run
a reverse proxy in front of their heavyweight perl servers have a security
problem and don't even know it.
The problem is that the solution written in the mod_rewrite guide for a
reverse proxy doesn't work as advertised to block incoming proxy requests.
RewriteRule^(http|ftp)://.* - [F]
This is supposed to block incoming proxy requests that aren't specifically
created by the rewrite rules that follow.
The problem is that both mod_rewrite and mod_proxy have changed, and this
seems to no longer catch the incoming proxy requests. Instead mod_rewrite
seems to see just the path part of the URI, ie, /foo/bar/baz.pl without the
http://.../.
I've even tried using ${THE_REQUEST} which actually matches, and says it's
forcing the response to be forbidden, then it happily proxies the request
anyways!
I'm using a
Directory proxy:*
deny from all
/Directory
Directory proxy:http://127.0.0.1/
allow from all
/Directory
section to at least avoid being an open proxy to the outside world, but I
cannot find any way in 1.3.12 to refuse all proxy requests coming from the
outside.
If you're not aware of the problem at all and have merely followed the advice
of the mod_rewrite guide you are probably an open proxy, allowing attackers to
use your web server to attack other sites anonymously.
--
greg
Re: Apache::Perfmon 0.011
Lupe Christoph [EMAIL PROTECTED] writes: Hmm. Apache::Benchmark sounds more like a benchmark driver to me. Apache::Instrumentation or so? Apache::Probe? Profile or even just Prof. I looked at this and really like the idea. Unfortunately I need to recompile my Apache to use it. What I think it needs is, a way to gather the statistics in a hash based on the request. That way I can make a web page that pokes around in the hash table and reports the average and maximum time taken by page. I'm not clear how or if that can be done in a separate module like this that doesn't know how the requests are dispatched. Either a regexp needs to be provided that returns the key to use for the hash, or else something similar needs to be integrated into packages like CGI and Apache::ASP. (Which was the approach I was planning on taking myself.) I like this approach better though, so it would be neat to see it polished. -- greg
Apache.pm failed to load
I think I followed the directions, and I also added "PerlModule Apache" in httpd.conf, but I still get the error "Apache.pm failed to load!." when trying to start httpsd. I am on Sol 2.7, gcc 2.8.1 apache-1.3.12 and openssl_0.9.5 and mod_perl-1.24. I have performed the steps outlined in this page with the exception noted below. Any help is greatly appreciated. http://perl.apache.org/guide/install.html#Source_Configuration_perl_Makef Under the section for mod_perl and apache-ssl (+openssl) Configure and install openssl: % cd openssl-x.x.x % ./config % make make test make install Patch Apache with SSLeay paths % cd apache_x.xx % tar xzvf ../apache_x.x.x+ssl_x.xx.tar.gz % FixPatch Do you want me to apply the fixed-up Apache-SSL patch for you? [n] y Now edit the src/Configuration file if needed and then configure: % cd ../mod_perl-x.xx % perl Makefile.PL USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_SRC=../apache_x.x.x/src Build, test and install: % make make test make install % cd ../apache_x.x.x % make certificate % make install make cert and make install steps I skipped. I had a prior version of apache-ssl I am replacing. Here is what the perl library has: # find /opt/local/lib/perl5 -name Apache /opt/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Apache /opt/local/lib/perl5/site_perl/5.005/Apache # ls /opt/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Apache AuthenSmb Sandwich # ls /opt/local/lib/perl5/site_perl/5.005/Apache AuthenSmb.pm Sandwich.pm # find /opt/local/lib/perl5 -name Apache.pm /opt/local/lib/perl5/5.00503/CGI/Apache.pm # cp /opt/local/lib/perl5/5.00503/CGI/Apache.pm . ..still didn't work.
Re: Apache::Icon fix
I have to admit that a lot of this stuff is a mistry. Recap: My configuration is: apache_1.3.12/mod_perl-1.24/Perl-5.6.0/linux-2.2.14. (I have mod_perl linked statically.) with Apache::AutoIndex.pm loaded. Doug, could you please explain what problem(s) your patch solved? I applied the patch below to Apache-Icon-0.02\Icon.xs, but all the Apache processes still die when I do "kill -HUP ###" on the Apache root PID. I noticed that when the order of the httpd.conf following two directives is (as you stated): PerlModule Apache::Icon PerlModule Apache::AutoIndex "apachectl start" produces the same error_log entry as my "kill -HUP ###", namely: Syntax error on line 156 of /usr/local/apache/conf/httpd.conf: Invalid command 'IndexOptions', perhaps mis-spelled or defined by a module not included in the server configuration However, with the order of the two directives reversed (as follows): PerlModule Apache::AutoIndex PerlModule Apache::Icon The launch is just fine. [The SIGHUP still fail however:[ Recap: My configuration is: apache_1.3.12/mod_perl-1.24/Perl-5.6.0/linux-2.2.14. (I have mod_perl linked statically.) I noticed that you are using development code with DSO. Perhaps I am missing some other patch that would alow it to work. Is the stability of DSO mod_perl improving? I remember reading that when httpd is started, it runs the init twice in order to verity that it can survive a SIGHUP. If this is the case, why would the SIGHUP fail? At 10:04 AM 8/21/00 -0700, Doug MacEachern [EMAIL PROTECTED] wrote: with the patch below, Apache::Icon/Apache::AutoIndex works fine for me. running apache_1.3.13-dev, mod_perl-1.24_01-dev, perl-current (5.7.0-dev) mod_perl built with EVERYTHING=1, USE_DSO=1 copy-n-pasted config from Apache::AutoIndex/README: PerlModule Apache::Icon PerlModule Apache::AutoIndex PerlTransHandler Apache::AutoIndex::transhandler PerlHandler Apache::AutoIndex kill -HUP works just fine too. --- Icon.xs 1999/01/18 19:21:46 1.1.1.1 +++ Icon.xs 2000/08/21 16:50:04 @@ -18,6 +18,12 @@ PROTOTYPES: DISABLE +void +END() + +CODE: +ap_remove_module(icon_module); + Apache::Icon new(class, r=default_r) char *class
Re: problem with mod_proxy/mod_rewrite being used for the front-end proxy
According to Greg Stark: This isn't entirely on-topic but it's a solution often suggested for mod_perl users so I suspect there are other users here being bitten by the same problems. In fact the manner in which problems manifest are such that it's possible that many mod_perl users who are using mod_rewrite/mod_proxy to run a reverse proxy in front of their heavyweight perl servers have a security problem and don't even know it. The problem is that the solution written in the mod_rewrite guide for a reverse proxy doesn't work as advertised to block incoming proxy requests. RewriteRule^(http|ftp)://.* - [F] This is supposed to block incoming proxy requests that aren't specifically created by the rewrite rules that follow. The problem is that both mod_rewrite and mod_proxy have changed, and this seems to no longer catch the incoming proxy requests. Instead mod_rewrite seems to see just the path part of the URI, ie, /foo/bar/baz.pl without the http://.../. Setting ProxyRequests off should disable any explict proxy requests from clients. It does not stop ProxyPass or RewriteRule specified proxying. My server logs a 302 error and sends a redirect to http://www.goto.com/d/home/p/digimedia/context/ (interesting - I didn't know where it was redirecting before...). I do see quite a few of these in my logfiles, mostly trying to bump up the ad counters on some other sites, I think. Les Mikesell [EMAIL PROTECTED]
Re: Building mod_perl and mod_jserv into same apache
According to Stas Bekman: On Mon, 21 Aug 2000, Jeff Warner wrote: We need to have mod_perl and mod_jserv in the same httpd file. I can build apache 1.3.9 for either mod_perl or mod_jserv using the appropriate make commands from the install docs and they work fine. I've tried to build a mod_perl httpd and then use ./configure \ --prefix=/usr/local/apache \ --activate-module=src/modules/jserv/libjserv.a on a apache build but then I get a mod_jserv httpd and mod_perl is gone. If I try to activate-module for both mod_perl and mod_jserv I get a lot of mod_perl errors. Suggestions would be appreciated. http://perl.apache.org/guide/install.html#Installation_Scenarios_for_mod_p I think it should be easy to apply these notes to your case. It does work to build them together, but if you are using the two-apache scheme it makes more sense to put jserv in the front end. Apache uses a proxy-like mechanism to pass the requests on to the jserv running in a separate process. It doesn't make much sense to have the larger mod_perl httpd waiting for the responses. Les Mikesell [EMAIL PROTECTED]
Re: Producing an error page
At first, when I read the first message, I said to myself; (self) Why would anyone want an error page with all the Perl HTML STDOUT/STDOUT stuff mixed up together? However, after reading and thinking some more, . . . (just from a conceptional point of view and not from an implementation view point), , , what a powerful concept! If you (a developer) could regain the Perl command line style of output from the web server (itself) without having to piece together the STDOUT/STDERR during a debugging effort. Now, lets say that you had an Apache module that output a web page that looked just like the stuff you could see from the browsers "View/(Page)Source" with the STDERR output included. All one would have to do, is configure the DEBUG handler in the httpd.conf, which would in turn produce what appeared as HTML code with STDOUT included all within a HTML page. The STDERR output would be distinguished, with lets say: STDERR Opps got an error here or something. \STDERR I'm sure you would also want a submit (DEBUG) button which could generate the above, on-demand for form pages and such. (Kind of a DEBUG on demand option.) Is this what is being discussed here? (This is probably, not a mod_perl topic, but then again, it could be:-). At 12:04 PM 8/21/00 -0700, you wrote: The stuff that the server sends back comes from STDOUT if CGIs or within mod-perl, either $req-print or a regular print since it is tied. The error messages go to STDERR which apache redirects internalls so that the messages go to the error log. I don't know that it's possible and I'm certain it's not a good idea to try and circumvent that and send STDERR to the browser. And besides that, you'd still have to send content-type headers. I suppose you could write one perl program that executes your perl program of interest from within an eval block and capture the output that way. But isn't simply looking at the error log easier? -- Rob --On Monday, August 21, 2000 8:56 AM -0500 Jay Strauss [EMAIL PROTECTED] wrote: Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264
RE: When will PerlLogHandler *not* run
Needless to say, I find that under certain conditions that I'm not completely sure of, the loghandler doesn't run and the object does get undef'ed (I know this from using perl-status and from the fact that the process in question doesn't give me any timing statistics from then on). The question is, what combination of events could cause the log handler not to run once I've pushed it, yet leave the process intact to handle another request? -Paul Weiss Whoops. I meant to say "the loghandler doesn't run and the object *doesn't* get undef'ed." Sorry about that. -P
Re: Producing an error page
i may be coming in late here, so forgive me if this has been mentioned: use CGI::Carp qw(fatalsToBrowser); not sure if everything you want will be sent to the browser, but it is better than a standard 500 error, and you can read the errors from the log easier. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ George Sanderson wrote: STDERR Opps got an error here or something. \STDERR I'm sure you would also want a submit (DEBUG) button which could generate the above, on-demand for form pages and such. (Kind of a DEBUG on demand option.) Is this what is being discussed here? (This is probably, not a mod_perl topic, but then again, it could be:-). At 12:04 PM 8/21/00 -0700, you wrote: The stuff that the server sends back comes from STDOUT if CGIs or within mod-perl, either $req-print or a regular print since it is tied. The error messages go to STDERR which apache redirects internalls so that the messages go to the error log. I don't know that it's possible and I'm certain it's not a good idea to try and circumvent that and send STDERR to the browser. And besides that, you'd still have to send content-type headers. == --snip-- How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264
Re: When will PerlLogHandler *not* run
On Aug 21, 2000 at 23:45:48 -0400, Paul G. Weiss twiddled the keys to say: Needless to say, I find that under certain conditions that I'm not completely sure of, the loghandler doesn't run and the object does get undef'ed (I know this from using perl-status and from the fact that the process in question doesn't give me any timing statistics from then on). The question is, what combination of events could cause the log handler not to run once I've pushed it, yet leave the process intact to handle another request? -Paul Weiss Whoops. I meant to say "the loghandler doesn't run and the object *doesn't* get undef'ed." This may or may not have any bearing on this question, but something I've seen is that $r-register_cleanup() will stop responding sometimes. After a while a whole pile of cleanups from one given child will just do their thing one after another. I've always wondered why that is. Why doesn't that child just hang instead of storing up all the registered cleanups? Rick Myers[EMAIL PROTECTED] The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer.
Re: cgis and subrequests
hey, guys
just for the recordI finally got this thing to work. However, it does
have some bizarre behavior. After compiling the patch,
$subr-run(1) returns headers without calling the send_http_header method.
This holds true for static files and for cgis that only set the content type
header. For cgis that add any additional header like Location, the headers
are not returned unless you explicitly call send_http_header. I know that
our cgi's at most only alter the Location header in addition to content
type...so...I coded around this with the following:
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-run(1);
if($subr-header_out('Location')) {
$subr-send_http_header;
} else {
$r-print(create_img_tag($file,$SCRIPT_ON,$status));
}
my $status = $subr-status;
return $status;
if I always called send_http_header, a second set of HTTP headers would be
appended to static documents and to cgis that only change the content type
header.
Just an FYI...
-amen
Doug MacEachern wrote:
On Mon, 21 Aug 2000, Alex Menendez wrote:
ok, what about cgi's that generate Location: headers. Am I out of luck
here? should I contemplate changing src for ap_run_sub_req
doh, right, headers are not added until run(). no need to change
ap_run_sub_req, we can support this. with the patch below you can say
$subr-run(1), where 1 enables send_http_header() within subrequests.
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 19:38:32
@@ -1996,10 +2003,15 @@
"Apache::SubRequest::DESTROY(0x%lx)\n", (unsigned long)r));
int
-run(r)
+run(r, allow_send_header=0)
Apache::SubRequest r
+int allow_send_header
CODE:
+if (allow_send_header) {
+r-assbackwards = 0;
+}
+
RETVAL = run_sub_req(r);
OUTPUT:
ANNOUNCE: Apache::Compress 1.002 (new module)
Hi all, The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-Compress-1.002.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-Compress-1.002.tar.gz size: 10708 bytes md5: 7fef7de82d46083a1b0f2ea1492d2faf Here's the documentation. I'd appreciate any feedback from people who use the module, if only to tell me that it works or doesn't work. --- NAME Apache::Compress - Auto-compress web files with Gzip SYNOPSIS PerlModule Apache::Compress # Compress regular files FilesMatch "\.blah$" PerlHandler Apache::Compress /FilesMatch # Compress output of Perl scripts PerlModule Apache::Filter FilesMatch "\.pl$" PerlSetVar Filter on PerlHandler Apache::RegistryFilter Apache::Compress /FilesMatch DESCRIPTION This module lets you send the content of an HTTP response as gzip- compressed data. Certain browsers (Netscape, IE) can request content compression via the `Content-Encoding' header. This can speed things up if you're sending large files to your users through slow connections. Browsers that don't request gzipped data will receive regular noncompressed data. This module is compatibile with Apache::Filter, so you can compress the output of other content-generators. TO DO Compress::Zlib provides a facility for buffering output until there's enough data for efficient compression. Currently we don't take advantage of this facility, we simply compress the whole content body at once. We could achieve better memory usage if we changed this (at a small cost to the compression ratio). See Eagle book, p.185. AUTHOR Ken Williams, [EMAIL PROTECTED] Partially based on the work of several modules, like Doug MacEachern's Apache::Gzip (in the Eagle book but not on CPAN), Andreas Koenig's Apache::GzipChain, and an unreleased module by Geoffrey Young and Philippe Chiasson. SEE ALSO perl(1), mod_perl(1), Apache::Filter(3)
When will PerlLogHandler *not* run
I have a timing module which is designed to only create a
single object. It works according to the following pseudo-code
package TimeIt;
sub begin
{
my $this = get_object(shift);
my $op = shift;
# store start time in object
...
}
sub end
{
my $this = get_object(shift);
my $op = shift;
# store end time in object
...
}
sub output
{
my $this = get_object(shift);
# format timing info as a string
return $string;
}
# if method was called as a class method return the global
# object if it exists, otherwise create it
sub get_object
{
my $obj = shift;
return $obj if ref($obj); # a real object
# $obj is class name
return $object if $object; # a global
$object = TimeIt-new;
Apache-push_handlers('PerlLogHandler', \loghandler);
return $object;
}
sub loghandler
{
my $r = shift-last;
if ($object)
{
my $output = $object-output; # generate output
$r-notes('TIMEITOUTPUT', $output);
# the LogFormat uses %{TIMEITOUTPUT}n
undef $object;
}
return DECLINED;
}
The web page then uses it as follows:
TimeIt-begin('foo');
foo(@args);
TimeIt-end('foo');
for as many things as it wants to time.
Basically the log handler is responsible for resetting the object
so that the next request will create it again. As you can see,
if the loghandler doesn't run, all is lost, because subsequent
requests see $object already defined and don't recreate it.
Needless to say, I find that under certain conditions that I'm not
completely sure of, the loghandler doesn't run and the object does
get undef'ed (I know this from using perl-status and from the fact
that the process in question doesn't give me any timing statistics
from then on). The question is, what combination of events could
cause the log handler not to run once I've pushed it, yet leave the
process intact to handle another request?
-Paul Weiss
P.S. I know that the *real* way to fix this problem would be to use
an init handler to undef the object. Unfortunately I don't have
complete control over the httpd.conf file ( a political rather than
a technical problem ) and so I'm trying to solve this problem using
Perl code alone.
cvs commit: modperl-site/guide CHANGES config.html control.html correct_headers.html help.html index.html index_long.html install.html mod_perl_guide.pdf.gz performance.html perl.html porting.html scenario.html security.html snippets.html strategy.html troubleshooting.html obvious.html
sbekman 00/08/21 06:18:23 Modified:guideCHANGES config.html control.html correct_headers.html help.html index.html index_long.html install.html mod_perl_guide.pdf.gz performance.html perl.html porting.html scenario.html security.html snippets.html strategy.html troubleshooting.html Removed: guideobvious.html Log: * mod_perl guide's build process is now completely migrated into an external module, distributed in package Pod::HtmlPSPdf. * install.pod: Raven SSL installation notes updated (Doug, Geoffrey Young) * troubleshooting.pod: install_driver(Oracle) failed: Can't load '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, Richard Chen) * security.pod: a code sample in "Non authenticated access for internal IPs, Authenticated for external IPs" is corrected (Will Trillich) * porting.pod: "CHECK Blocks" (Doug) * scenario.pod: "The dual server installation scenario was complete rewritten, to accomodate a better in my opinion directories layout and simpler installation process" * perl.pod: "Exception Handling for mod_perl" was improved by Matt Sergeant. * Minor corrections: o config (Ron Pero) Revision ChangesPath 1.26 +26 -0 modperl-site/guide/CHANGES Index: CHANGES === RCS file: /home/cvs/modperl-site/guide/CHANGES,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- CHANGES 2000/08/05 20:48:04 1.25 +++ CHANGES 2000/08/21 13:18:00 1.26 @@ -2,6 +2,32 @@ ### mod_perl Guide CHANGES file ### ### +08.21.2000 ver 1.26 + +* mod_perl guide's build process is now completely migrated into an + external module, distributed in package Pod::HtmlPSPdf. + +* install.pod: Raven SSL installation notes updated (Doug, Geoffrey + Young) + +* troubleshooting.pod: install_driver(Oracle) failed: Can't load + '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, + Richard Chen) + +* security.pod: a code sample in "Non authenticated access for + internal IPs, Authenticated for external IPs" is corrected (Will + Trillich) + +* porting.pod: "CHECK Blocks" (Doug) + +* scenario.pod: "The dual server installation scenario was complete + rewritten, to accomodate a better in my opinion directories layout + and simpler installation process" + +* perl.pod: "Exception Handling for mod_perl" was improved by Matt. + +* Minor corrections: + o config (Ron Pero) 08.05.2000 ver 1.25 1.28 +11 -10modperl-site/guide/config.html Index: config.html === RCS file: /home/cvs/modperl-site/guide/config.html,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- config.html 2000/08/05 20:48:04 1.27 +++ config.html 2000/08/21 13:18:00 1.28 @@ -52,7 +52,7 @@ LIA HREF="#Alias_Configurations"Alias Configurations/A UL - LIA HREF="#Running_CGI_PerlRun_and_Regist"Running CGI, PerlRun, and Registry Scripts located in the same Directory/A + LIA HREF="#Running_CGI_PerlRun_and_Regist"Running CGI, PerlRun, and Registry Scripts Located in the Same Directory/A /UL LIA HREF="#_Location_Configuration"lt;Locationgt; Configuration/A @@ -808,7 +808,7 @@ P where latter directive invokes mod_cgi. You shouldn't use the CODEScriptAlias/CODE directive unless you want the request to be processed under mod_cgi. -Therefore when you configure a mod_perl sections use +Therefore when you configure mod_perl sections use CODEAlias/CODE instead. P @@ -818,8 +818,9 @@ A HREF="././config.html#Perl_Handlers"Perl*Handlers/A for more information about handlers for the various request phases. P -When you have decided what methods to use to run your scripts and where you -will keep them, you can add the configuration CODEdirective(s)/CODE to EMhttpd.conf/EM. They will look like those below, but they will of course reflect the +When you have decided which methods to use to run your scripts and where +you will keep them, you can add the configuration CODEdirective(s)/CODE +to EMhttpd.conf/EM. They will look like those below, but they will of course reflect the locations of your scripts in your file-system and the decisions you have made about how to run the scripts: @@ -846,7 +847,7 @@ P [ BFONT SIZE=-1A HREF="#toc"TOC/A/FONT/B ] HR -CENTERH3A NAME="Running_CGI_PerlRun_and_Regist"Running CGI, PerlRun, and Registry Scripts located in
cvs commit: modperl ToDo
dougm 00/08/21 10:40:22 Modified:.ToDo Log: todo Revision ChangesPath 1.246 +8 -0 modperl/ToDo Index: ToDo === RCS file: /home/cvs/modperl/ToDo,v retrieving revision 1.245 retrieving revision 1.246 diff -u -r1.245 -r1.246 --- ToDo 2000/08/17 21:19:34 1.245 +++ ToDo 2000/08/21 17:40:19 1.246 @@ -3,6 +3,14 @@ (well, close to it anyhow) --- +- replace Apache::StatINC with Apache::ModuleReload? + +- ken f's send_header patch + +- ken w's Apache::test patch + +- Makefile.PL options should be saved into a .pm installed file + - allow $r-server-uid($new_uid) ? [Rob Giseburt [EMAIL PROTECTED]]
