Re: [OT] Persistant MySQL connections in Apache 2
Issac Goldstand wrote: This is really a C API thing, but I was wondering if Apache2::DBI people can help me shed some light on this... I'm not sure what's the Apache2::DBI question, but we (Tim, Hugo, Eric at el.) have discussed the Apache::DBI for threaded apps at the last TPC and the conclusion was that we need to write a generic Perl Thread::DBI module to work with threaded Perl and then use Apache::DBI on top of it. Some of this was discussed on the dbi-dev list, but as far as I know nothing was developed so far. If you want to discuss the design, which is not trivial, and implementation, it's probably the best to do that on the dbi-dev list. - Original Message - From: Kent Fitch To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 5:37 AM Subject: Re: [apache-modules] Persistant MySQL connections in Apache 2 Hi Issac, From: Issac Goldstand Subject: [apache-modules] Persistant MySQL connections in Apache 2 Hi all, I'm a rookie C API programmer (mod_perl was just so much *easier* most of the time :-)), and am working on coding a module to with in my front-end Apache 2/mod_proxy server. The idea of the module is to provide access to the front-end server with a list of blacklisted IPs which are stored in a MySQL database. So I'm thinking the module's child_init should open the connection to the MySQL database and then the access_handler can grab the MySQL connection from the child-pool. Yes, but beware that in a threaded Apache run-time, there could be many threads fo execution processing many requests simultaneously in your child process, so you'll have to arrange to lock the connection whilst a thread is using it and possibly have a pool of them. See Thread Safety http://httpd.apache.org/docs-2.0/developer/thread_safety.html But the problem is that I would *like* for the connections to the database be closed before the pool is simply swept clean upon destruction. I would think that that would be a good thing to do - maybe I'm wrong... Yes - you should register a cleanup function on the pool you allocate the data structures for the connection(s) from in your init. See these notes on pooling (which may be a bit 1.3-ish and hence out of date, but the ideas are relevant): http://httpd.apache.org/docs-2.0/developer/API.html#pools and see the apr_pool_cleanup_register api Kent Fitch -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mp2.0 w/Apache 2.0, DBI setup??
Robert Kohler wrote: Randy Kobes wrote: On Mon, 18 Nov 2002, Robert Kohler wrote: I am having difficulty getting Apache 2.0.43, perl 5.6.1, and mod_perl 1.99_07 to work together. Trying to authenticate users based on a MySQL table. All compiles and installs. I installed Apache-DBI-0.89 perl module. In configuring, I keep getting Seg faults. Can someone let me know if I am even setting up the config file correctly for Apache. Seems I have searched all the archives, and keep getting conflicting information... Are you using the latest versions of DBI and DBD::mysql? If not, does this still happen with the latest versions? DBI 1.21 DBD::mysql 2.0.11 Note the most current, but I can't modify this as it is in production currently. I can try testing on a completely different system if need be. As Randy has mentioned you need DBI-1.30 and your problem should go away. It did for me :) -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
ApacheCon mod_perl 2.0 presentation's handouts
If you come to ApacheCon and plan to go to the mod_perl 2.0 presentation on Wed, after the lunch, here are the handouts if you want to print them. The conference organizers won't give printed versions, in order to cut costs. So here it's: http://stason.org/talks/apachecon2002/presentation/mod_perl-2.0-presentation-handouts.pdf.gz If you come to my mod_perl 2.0 by example tutorial on Monday, I believe you will be given a printed copy of the handouts, so no need to bring your own copy. Older presentations/tutorials are available at the usual location: http://stason.org/talks/ See you next week. p.s. If you are looking for us Eric and I are staying in the room #1801 at Alexis Park Resort. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Namespace problem
Thomas Hilbig wrote: I am having a namespace problem that is a slight twist to that described in the 1.0 docs http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs My problem is even simpler, but worse. If I have two CGI programs using the same required script. Initially one works without any problems. Then if I call up the other script, each time I get an error saying the subroutine cannot be found. Refresh the browser and it works, but then the first one starts to give an error; Error message: Undefined subroutine ModPerl::ROOT::ModPerl::Registry::home_httpd_qx_2dbin_gdtest1::goodDay called at /home/httpd/qx-bin/gdtest1 line 7. It's not any different, please read that section again. You must be hitting different children hence you see the problem with the first script. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Hellp! mod_perl worked fine then added modssl and now apachewon' t start
Mitchel, Jennifer (Jem) wrote: Hi all, I am still new to all of this. I had Apache 1.3.22 with mod_perl included and the Authenitcation hook enabled. Everything was fine. Then I imstalled my OpenSSL and generated my key, got my server certificate from my csr etc fine. The certificate has been verified. I then with mod_ssl-2.8.5-1.3.22 did ./configure \ --with-apache=/web/server/apache/1.3.22-source \ --with-ssl=/web/server/OpenSSL/0.9.6g \ --with-crt=/web/server/OpenSSL/0.9.6g/bin/serverPEM.crt \ --with-key=/web/server/OpenSSL/0.9.6g/bin/server.key \ --prefix=/=/web/server/apache/1.3.22 This went fine. make went fine. Because I used with-crt/with-key I skipped make certificate (yes serverPEM.crt and server.key are the real certificate and private key) make install goes fine. I stop Apache fine. Once start I get the following error Syntax error on line 1008 of /web/server/apache/1.3.22/conf/httpd.conf: Invalid command 'PerlModule', perhaps mis-spelled or defined by a module not included in the server configuration /web/server/apache/1.3.22/bin/apachectl start: httpd could not be started Please review: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Help - SEGFAULTS on 'PerlModule' after version upgrade
Rafiq Ismail (ADMIN) wrote: Ugggh: My software works with the 'original server settings', (apache 1.3.24/mod_perl 1.26) see below(1), under linux. It doesn't work with 'new server settings', (apache 1.3.26 / mod_perl 1.26) see below(2), under freeBSD. Symptoms: With the new build, I get seg faults with 'some' of the PerlModules included through PerlModule in various virtualhosts. Other modules work. These packages all run with strict and do not include any XS besides what may hide under the cover with DBI, Date::Calc and Template. I also have a headache. The packages were happily being included into my old build and there is nothing unusual about them. An strace displays the last couple of lines before a segfault as follows: See, http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems you need to send the gdb backtrace, not the strace's output. FWIW, I've had segfaults on 'use DBI' with mod_perl 2.0/perl 5.8.0, which have gone after I've updated the DBI package. Try to do the same. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: @INC + use Lib
Pierre Smolarek wrote: I've been having problems with use lib. I read the extract at http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl and realised that you can hardcode INC via httpd.conf or startup.pl. however, i tried adding PerlSetEnv PERL5LIB to a .htaccess file but that doesn't seem to work!? INC is hardcoded at the server startup and gets reset after each request. Is there someway to isolate the paths to specific virtualhosts or directories? I tried adding it within a directory command in httpd.conf but it didn't seem to work. Look at: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ http://perl.apache.org/docs/1.0/guide/modules.html#Apache__PerlVINC___Allows_Module_Versioning_in_Location_blocks_and_Virtual_Hosts __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Cleanup question
Jan Theofel wrote: Hello, I have a shop system wirtten in Perl which I now must switch to mod_perl bevor going live. The code is written with use strict and I think it is in biggest parts a good source. ;-) The question I have now is, that I have to switch the error handling. Until now, I display an error message to the users web browser and then die(). As I know, this is not a good idea unter mod_perl, especially because I use references on lager data structures and some objects in my code. I searched the web for a documentation about that topic and found some things wwhich are somehow confusing to me. Perhaps someone of you knows a documentation which explains who to do this properly? You can die() under mod_perl. See: http://perl.apache.org/docs/1.0/guide/porting.html#die___and_mod_perl Other relevant pages to read: http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_Errors_to_the_Client_Instead_of_error_log http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Customized___DIE___hanlder __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: AB Segfault on mod_perl Handler
Richard Clarke wrote: List, Does anyone know why apache ab might segfault when accessing one particular mod_perl handler on my site? Is this something I could be doing wrong in my handler (I can't think what.. the page works find in all browsers). Richard, this has nothing to do with mod_perl, other than triggering a bug in ab. Which is not a *mod_perl* problem. You want to post a proper bug report including a core stack backtrace to the httpd-dev list. See: http://httpd.apache.org/lists.html#http-dev __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Peek and perl 5.8.0
John Siracusa wrote: Does anyone have Apache::Peek working with perl 5.8.0? I can't get it to build, and I can't find the symbols it's (apparently) missing anywhere in perl 5.8.0's header files. Example: [...] Doug MacEachern has hacked Devel::Peek 0.95 to work with mod_perl. The current Apache::Peek version is 0.9501. It works with Perl versions 5.8.0 and mod_perl 1.x. The attached package is a similar hack that works with Perl 5.8.0 and mod_perl 1.x. Doug's hack doesn't compile with perl 5.8.0, since Devel::Peek, which it copies, has been heavily rewritten and uses internally APIs which didn't exist before. I took a different approach and instead of overriding PerlIO functions (the approach which doesn't work anymore) I've simply supplied a very simple PerlIO layer that only knows to write data to the client using the request_rec object. I've done only very basic testing, so bugs are possible. Let me know if you spot any. I'm not sure what's the best approach to take in order to distribute this package. Whether to somehow extend it to support Perl 5.8.0 and thus merge with Doug's version, or simply distribute it separately. Ideas and patches are welcome. TODO: The tests weren't adopted to use Apache::Test yet. Patches are welcome. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Apache-Peek-1.00_035008.tar.gz Description: application/gzip
Re: Quota module for Perl
Peter Kehl wrote: Hi, i am trying to install the Quota module for Perl, but following error occurs: I´ve installed RedHat 7.1 mod_perl 1.24_01-2 perl 5.6.0-12 Has anyone got an idea? Certainly. Quota.pm has nothing to do with mod_perl. Please ask the author of that module. Thank you. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: HELP with mod_perl version
Alan Chung wrote:
Hi,
I have tried to upgrade my apache from 1.3.12 to 1.3.26 and openssl from
0.9.5a to 0.9.6g.
But when I upgraded mod_perl from 1.24 to 1.26 (it seems that I have
to), it could be compiled with no error but httpd couldn't be started
with the following error:
Apache.pm version 1.26 required!
/usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is version 1.27
Perhaps you forgot to 'make install' or need to uninstall an old version?
Found: /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm
From the error, it looks like I need to fall back to order version for
mod_perl (?),
So I did try to uninstall the current Perl and mod_perl and reinstall
again.
I even tried the different version of mod_perl (1.25, 1.27) but with the
same error.
Could anyone give me an advice?
Looks like you have either messed up several installations of mod_perl
or have forgotten to install the latest binary, which explains why it
requires 1.26. Check the timestamp on the httpd binary or the .so module
if you are using DSO. And go again through the install steps as
explained at http://perl.apache.org/docs/1.0/guide/install.html
If you want to make a complete cleanup of all older Apache modules prior
to installing the new ones, you could use find(1) to assist you to find
the older Apache:: modules. Something like the following:
find /usr/lib/perl5 -name 'Apache*'
and then deleting them if you are sure that this is what you want:
find /usr/lib/perl5 -name 'Apache*' -exec rm {} \;
Though be careful that you have a backup of things before you attempt to rm.
Notice that you don't have to uninstall *Perl* but only Apache modules.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:stas;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] Apache::SubProcess deFUNct sub-process
Imago wrote: Apache::SubProcess does not appear to be 'fully' working. This is quite possible. This module is a complete rewrite of the 1.x version. I've added some basic tests, but if you can supply a test that fails that'd be of a great help. Just remember that it should be as short as possible. See t/response/TestApache/subprocess.pm which is run as: t/TEST apache/subprocess Thanks! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: installing a signal handler in module ..
Sylbert L wrote: Hi .. I need to catch a custom signal in my module. How do I do this ? I tried writing a signal handler .. put it into my Responsehandler module .. but it doesn't seem to work. Is this possible ? How do I achieve this ? If you don't describe what your problem is, how can we possibly help you? Here is an example of using a custom sighandler to figure out where a process hangs: http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Prevision
Udlei Nattis wrote: when will be finished modperl2? The short answer: Never. The long answer: mod_perl 1.0 hasn't been yet finished. Even though it's a robust piece of sw it's a work in progress. New features are added and bugs are fixed. So it's an ongoing process. It all depends on what features do you need and whether they have been already implemented in mod_perl 2.0. If certain features are missing, you should either submit patches that add them or gently bug the dev list that you need a certain feature which hasn't been ported/implemented yet, certainly after you've lurked on the list for a while, and actively participate in its testing once it has been added. Here are several known issues: mod_perl 2.0 doesn't implement args() and content() functions as they were in 1.0. It provides a perl (slower) backcompat implementation that is added to help people migrate their code to 2.0. Apache::Request should provide this functionality when it's ready. The C apreq library for Apache 2.0 has been developed and in the good shape. Due to many reasons we want this C library to be included in the httpd core, but it didn't happen so far. Certainly the Perl glue code (Apache::Request/Cookie) won't be written before the fate of the C library is known. I hope that this issue is going to be resolved asap. Registry scripts should work just fine with ModPerl::Registry. The only issue is with CWD, which is not thread-safe. There is a workaround module in works, which I think hasn't been released by Arthur Bergman yet. Once it's released registry scripts will work as is. If you are using the threaded mpm, there are many other potential issues with threads. I'll discuss them at my mod_perl 2.0 tutorial and presentations at ApacheCon next week. Stop by if you are interested. Other then that the majority of the 1.0 features has been implemented I think. And certainly there are heaps of new features that are already available. Come to my talks where I'll cover the most interesting ones. See the modperl-2.0/todo/* and modperl-2.0/STATUS for the lists of things that haven't been done yet and let us know if something is missing from these lists. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Where do you specify APR::HOOK...
Erich Oliphant wrote: Hi, I am trying to place a handler at the end of the list of PerlLogHandler's. I know I want to use APR::HOOK_REALLY_LAST but I'm not sure how or where to specify it for my handler. I tried PerlLogHandler My::Handler APR::HOOK_REALLY_LAST in the httpd.conf file w/ no success. Should it be in the handler code itself? That API doesn't exist yet in mod_perl 2.0. I believe the reason for that is that Apache hooks ordering API wasn't finalized yet. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2.0 Apache::Cookie
Rafael Amer Ramon wrote: Hi. I'm trying to upgrade my apache+mod_perl server form versions 1.3.27 (Apache) and 1.27 (mod_perl) to versions 2.0.43 and 2.0 but I have a problem with cookies. With mod_perl 1.27 I use Apache::Cookie from libapreq-1.0 and I cannot fount a similar module for mod_perl 2.0. It wasn't ported to 2.0 yet. The C core is almost completed though. Does anybody knows how I can handle cookies, send and get values, in a mod_perl 2.0 handler? Try using CGI::Cookie or check other similar modules on CPAN. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [BUG] Losing GET/POST-data
[...] Basically we are losing data sent to a mod_perl program. We request the page page.fxml?name=aladress=swedenproblem=huge. When our program receives this request it will only be page.fxml without any of the arguments sent. [...] I haven't followed the original thread, so I apologize if I repeat somebody else here. But from your description I'd suggest the following: You have to narrow the problem down after you are able to reproduce the problem at will. That means that you should use try to emulate multiply requests, for example with ab. See: http://perl.apache.org/docs/1.0/guide/performance.html#Benchmarking_Applications If you are able to do that and you know that the problem is on the server side and not caused by the clients who mess up with hidden fields or form elements. Next try to figure out who's causing the problem (assuming that it's a server side prob). e.g. this section uses three different ways to extract params: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param Do you get the problem with all of them? Hope this helps. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp 2] Bug report - mod-perl install process.
Ian Stuart wrote: Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1 I believe that the install process does not test for the presence (or lack of..) of the apache_server_root/modules directory. This causes a problem during the mod_perl installation as the pseudo-command cp $SOURCE/mod_perl.so $SERVER/modules creates a large file called modules, not a file called mod_perl.so within a directory called modules [...] Indeed, it doesn't. Thanks for the report. Does the following patch solve the problem? I'm not quite sure how portable it is, but neither ExtUtils::MakeMaker nor %Config provide entries for test_d and mkdir. Index: lib/Apache/Build.pm === RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v retrieving revision 1.107 diff -u -r1.107 Build.pm --- lib/Apache/Build.pm 29 Aug 2002 02:00:56 - 1.107 +++ lib/Apache/Build.pm 11 Nov 2002 15:37:06 - -1057,6 +1057,7 lib: $(MODPERL_LIB) install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Compilation problems with mod_perl
Benny Jensen wrote: Hello, I'm trying to compile mod_perl for apache2. But i got a error message that i dont know how to solve. The following message is what i get: /LD_RUN_PATH= cc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status / APR.so exist in following map: //usr/local/lib/perl/5.8.0/Apache2/auto/APR/APR.so/ If anyone could help me to solve it it's looking for libapr, not APR. You must have messed up the apache build step or missed it completely and don't have apache built yet. Review the installation steps at: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_Installing_Prerequisites __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: SafeCWD Status
Josh Bernstein wrote: Whats the staus of the cwd and SafeThread? Will it work with a threaded MPM in Apache 2 yet and safely change to the working directory of the perl script (safecwd). Arthur Bergman has started ex::threads::safecwd, but I'm not sure in what state the development of this module is. I remember he was asking for somebody to take over it, since he had too many p5p things to do. You can see the logic of this module in this article, second page: http://www.perl.com/pub/a/2002/06/11/threads.html?page=2 If you have the tuits to finishing it up, feel free to contact Arthur and offer help. As for SafeThread I haven't heard of this module in the perl land. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: httpd defunct - where are these zombies coming from?
Tim Gardner wrote: I'm having trouble with zombies. Red Hat 7.1 on a Dell server with 1 GB memory. The following ps output shows a somewhat typical output. Sometimes there are no zombies, but most of the time there are several, and often as many as this. Performance often seems sluggish, and I am assuming that this is because of this problem, though I don't know that for sure. Turning off the database lowers usage and decreases the number of zombies, but I don't know if this is due to the database or to the lower usage. I can't figure out what is going on. Any help / suggestions would be much appreciated. [...] check http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl in particular http://perl.apache.org/docs/1.0/guide/performance.html#Avoiding_Zombie_Processes my guess is that you use fork or its variations which leaves zombies. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: perl5/i386-linux/CORE/perl.h small fix, dont know where tosend it
[EMAIL PROTECTED] wrote: Hi All, just started to play with perl2 + apache2 and after getting borred with warnings about redefinition of macro VOIDINFO, I've putted there #ifndef - I don't know how to make patch files, but if any maintainer reads this, can you please add following to perl5/i386-linux/CORE/perl.h ? #ifndef VOIDUSED #define VOIDUSED 1 #endif Martin, please always specify the version of the sw you are talking about? How are we supposed to guess which perl version you are talking about? In any case, this warning has been solved in perl 5.8.0 and you will still see it with 5.6.1. The problem with fixing 5.6.1 is that its successor 5.6.2 may be released or not at an unknown date. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to detect a broken connection using mod_proxy
giorgos wrote: hi all, i am running standard setup with one plain apache with mod_proxy and a mod_perl apache to which all mod_perl requests are directed by the proxy module. i want to be able to detect when the client connection breaks but all standard recipes like the one mentioned in p.147 of the cookbook don't work due the use of mod_proxy. does anyone know of a trick to detect when the connection is broken in such a scenario so that i can free up cpu resources? (i have a set of 4 heavy sql stm's. after each one of them i would like to check if the client is still there so that i will proceed to the next one or just return OK and forget about the request). As far as I know you can't do that, since mod_proxy doesn't cooperate with the backend. Anybody knows of similar to mod_proxy modules that do play nicely with the backend regarding aborted connections? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Makefile 'PERL=' definition.. 1.99_07, and previous releases
Lester Vecsey wrote:
In the Makefile that gets generated there are some PERL= and FULLPERL=
statements that get set to whichever perl you ran on the original
Makefile.PL file. For example I ran /usr/bin/perl-5.8.0-threaded on it, and
they got set properly. The problem is theres an additional 'MakeMaker macro
section' down lower in the Makefile that gets generated that just seems to
always default to /usr/local/bin/perl, instead of any custom one that is
specified when running the original perl on Makefile.PL.
I just thought I'd point this out and ask if this was intentional or an
oversight. I manually changed it and was able to finish doing a 'make
install', which was previously hanging up on the 'pure_install' section
because it invoked the wrong perl executable.
So that takes care of the problem I posted about a week ago ;) Now off to
finish testing this version of mod_perl.so..
--
# --- MakeMaker macro section:
MODPERL_MAKEFILE = Makefile.modperl
#PERL = /usr/local/bin/perl
PERL = /usr/bin/perl-5.8.0-threaded
APACHE_PREFIX =
MOD_INSTALL = $(PERL) -I$(INST_LIB) -I$(PERL_LIB) -MModPerl::MM \
-e ModPerl::MM::install({ARGV},'$(VERBINST)',0,'$(UNINST)'
mailto:{;ARGV},'$(VERBINST)',0,'$(UNINST)');
If you look at Makefile.PL it has the following code:
ModPerl::MM::WriteMakefile(
[...]
macro = {
[...]
PERL = $build-perl_config('perlpath'),
which essentially does:
require Config;
PERL = $Config{perlpath},
meaning that your perl's Config.pm is wrong. Check what you get when you
run:
% /usr/bin/perl-5.8.0-threaded -V:perlpath
does it print '/usr/bin/perl-5.8.0-threaded' or '/usr/local/bin/perl'
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:stas;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] compatibility suggestion
Josh Chamas wrote:
Hey mod_perl users/developers,
In short what I think we need is for the modperl2 perl-script
configuration directive to automagically load the Apache::compat
layer, please read below for why.
I am working on the Hello World benchmarks to get them running
against mod_perl2 so we can get some numbers comparing mod_perl1
against it, and meanwhile having to port to Apache2/mod_perl2
for the first time, in this case all of the benchmarks.
What struck me odd was that even the simplest of handlers would
not run directly under mod_perl/1.99_05-dev, as in:
sub handler {
my($r) = shift;
$r-content_type('text/html');
$r-send_http_header();
$r-print('Hello ');
$r-print('World');
200;
}
In this case the error was about content_type() not being implemented
which I could fix by adding:
use Apache::compat;
Many functions were renamed because they were renamed in Apache 2.0 API.
Worse, some functions are now have gone (e.g., send_fd). mod_perl keeps
a consistent API with Apache API.
Because some functions are no longer supported by Apache and were
replaced by similar functionalities which don't map 1:1 to the old
functions, Apache::compat provides a slower perl implementation for
them, but in the long run for production use you don't want to use
Apache::compat.
If it is the case that even the most trivial of applications
need Apache::compat, then why not load the Apache::compat layer
automatically? If performance is an issue, or code bloat or
what not, then perhaps *Apache::compat* layer could be added
only in case of using the *perl-script* config directive,
instead of the new modperl directive.
As Doug explained on the dev list, perl-script handler is the normal
mod_perl handler, it's not a backcompat handler.
Just load the Apache::compat if you need it while the dust settles down.
CGI.pm 2.89 already does that.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:stas;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Browse localhost
Dermot Paikkos wrote: Hi, I have noticed that since I installed mod_perl (v1.26) I can no longer point my browser at http://localhost. Previously I could view locally stored htdocs by either using http://localhost/doc_name.html or http://servername/doc_name.html. Is this normal or is my install not 100%? I can `telnet localhost 80` and get a server response with mod_perl showing. I get a server error if I point a browser from a different machine at the mod_perl server. I installed mod_perl into an existing apache server using apxs and everything=1. You must have configured Location / to be handled by mod_perl. Fix that by using some other location for mod_perl handlers/scripts and you will get your normal DocRoot back. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache 2.x
Jay Thorne wrote: Are there plans to make the new mod_perl backwards compatible? I tried a few months ago to move my faily large app to apache 2.x and mod perl and far far too many things are different. I'd love to experiment with the new code base, but this lack of compatibility is a show stopper for me. I don't have the time to re-code the entire thing. Failing that, is there a way to at least get print to work? Or have later mod_perl releases fixed that? Have you read the online docs? This should answer all your questions: http://perl.apache.org/docs/2.0/user/compat/compat.html#top if something is missing/unclear/wrong please let us know. Apache::compat includes most of the back-compat subs, but some are still missing. If you find such please report to the list. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2/httpd2 perlio test fail register_cleanup CGI.pm error
Philip Burrow wrote:
Hi all. Read some nice things about mod_perl so I thought I'd try it. I
tried mp1 with the latest 1.x of Apache but Apache just seg faulted if I
tried to run it. So, I went on to httpd 2.x. Couple of problems though.
Firstly, it fails 11/11 of the apr/perlio.t tests during make test. All
other tests are fine.
Can you please run:
t/TEST -v apr/perlio
and also send the errors from t/logs/error_log.
without a detailed report we cannot know what the problem is.
Also in the future please use t/REPORT script to report problems, as
explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Secondly, I get this error in the log when I try to
run a CGI that uses CGI.pm:
ModPerl::Registry: Can't locate object method register_cleanup via
package
Apache::RequestRec at /usr/local/lib/perl5/5.8.0/CGI.pm line 270.
this method is defined in Apache::compat. What happens if you add
PerlModule Apache::compat
in httpd.conf. The latest CGI.pm (2.89?) loads this module automatically:
if ($mod_perl::VERSION = 1.99) {
require Apache::compat;
} else {
require Apache;
}
The CGI in question works fine without mod_perl.
I'm using the startup script specified on
http://perl.apache.org/docs/2.0/user/config/config.html and have
configured
Apache as per that page. I have installed perl 5.8.0 from source as
per your
documentation on the site. All related modules are latest versions from
CPAN.
Versions of software: RedHat 7.2, httpd 2.0.42, mod_perl 1.99_07, CGI.pm
2.89, kernel 2.4.19.
If this still doesn't help, can you please post a *short* CGI script
that reproduces the problem?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:stas;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make test fails
Kelton Joyner wrote: I am trying to upgrade to Apache 1.3.27 with mod_perl 1.27. I am currently running Apache 1.3.20 and mod_perl 1.26 on an HP-UX machine with hpux 10.20 with perl v5.6.1 built for PA-RISC1.1 . I ran configure on Apache to generate a config file with the additional modules I wanted, then did configure for mod_perl with the following perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Then make make test make install The make worked with no errors. make test resulted in the following error output [...] Syntax error on line 3 of /usr/src/mod_perl-1.27/t/conf /httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration done Looks like you have messed up the installation steps when configuring apache separately. Please refer to: http://perl.apache.org/docs/1.0/guide/install.html#The_Flexible_Way __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make error compiling mod_perl on RH7.1
Witchy wrote: Hi all, Trying to compile mod_perl 2.0 for my RH7.1/Apache 2.0.39 server and it falls over with this error: apr_perlio.c: In function `apr_perlio_apr_file_to_glob': apr_perlio.c:573: `IoTYPE_WRONLY' undeclared (first use in this function) apr_perlio.c:573: (Each undeclared identifier is reported only once apr_perlio.c:573: for each function it appears in.) apr_perlio.c:577: `IoTYPE_RDONLY' undeclared (first use in this function) make[3]: *** [apr_perlio.o] Error 1 make[3]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR/PerlIO' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 When I ran 'perl Makefile.PL' etc with the correct location for my apache setup the only thing it complained about was the fact I was using Perl 5.6.0 and it recommended 5.6.1 or above. Before I trawl the dependencies tree trying to install a later version has anyone seen that problem before and do I really need to upgrade my perl installation? As somebody else has pointed out you won't have a problem if you run Perl 5.6.1 or higher. Let me check with other developers if 2.0 will eventually require 5.6.1 which is much better thatn 5.6.0. Or whether we should backport things to 5.6.0 as well. The reason is that macros IoTYPE_WRONLY and IoTYPE_RDONLY were introduced in 5.6.1. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Errors after converting /cgi-bin to PerlRun
Frank Naude (FJ) wrote: Hi, I'm trying to convert my /cgi-bin directory to PerlRun as it only contain Perl scripts. However, after doing so, I get numerous errors like this: [Wed Nov 6 11:34:21 2002] [error] Can't locate object method uri via package Apache::PerlRun at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 212. I think it happens when processing a require FILE; contruct. [...] My software versions: Embedded Perl version v5.6.0 for Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 [...] Would it be much of a trouble to upgrade to the latest mod_perl version 1.27? Most likely this problem has been fixed long time ago. [...] __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: newbie:How to get form input in mod_perl 2 since Apache::requestis not implemented yet ?
BuffaloRC Club wrote: Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. If you want to play with 2.0 it's cool, but you may find that it's not yet ready for production, as not all APIs are available yet. On the other hand 1.27 is a *very* robust version. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Apache::compat is the only way to go for now (if you don't use CGI.pm). See http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_content_ Apache::Request for Apache 2.0 is in works. The C version is pretty much completed, but it's not clear how it's going to be distributed. Once this clears out the perl glue code will be written. Join the [EMAIL PROTECTED] if you want to help and be the first one to know of new developments. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help getting started ..
Sylbert L wrote: Hi, I'm just getting started with mod_perl. Was trying out the Apache::CommandServer sample code provided in the documentation, but I seem to get this error : Can't locate object method run_access_checker via package Apache::RequestRec at . add: use Apache::HookRun (); in mod_perl 2.0 methods are spread across many modules for the maximum performance and modularity. Once the API docs will be created you will just have to search for the method in question and load the module that has it. For now the easiest way is to grep the WrapXS dir: .../modperl-2.0 grep -Ir run_access_checker WrapXS WrapXS/Apache/HookRun/HookRun.xs:ap_run_access_checker(r) WrapXS/Apache/HookRun/HookRun.c:XS(XS_Apache__RequestRec_run_access_checker); /* prototype to pass -Wmissing-prototypes */ WrapXS/Apache/HookRun/HookRun.c:XS(XS_Apache__RequestRec_run_access_checker) WrapXS/Apache/HookRun/HookRun.c:Perl_croak(aTHX_ Usage: Apache::RequestRec::run_access_checker(r)); WrapXS/Apache/HookRun/HookRun.c:RETVAL = ap_run_access_checker(r); WrapXS/Apache/HookRun/HookRun.c: newXS(Apache::RequestRec::run_access_checker, XS_Apache__RequestRec_run_access_checker, file); I'm using Apache 2.0.40, with mod_perl 2.0, Perl 5.8.0 on Red Hat Linux 7.2. Also, I was just reading up on the mod_perl handlers. Is it possible to modify the working of apache, such that, it doesn't close the connection with the client ? and the connection with the client remains a constant one until the client explicitly closes the connection ? Can this be done at a module level ? Or do I need to modify the Apache source to acomplish the same ? If its possible with mod_perl, which PerlHandler(s) need to be used ? HTTP is a stateless protocol and while you have the KeepAlive functionality to serve several requests over the same connection, you cannot rely on that to keep the connection open. Most likely you need to write a protocol handler for that. See: http://perl.apache.org/docs/2.0/user/handlers/protocols.html for examples and explanations. Thanks a whole lot. I've just recently purchased Oreilly's Writing Apache Modules with Perl and C, but realized that it isn't too much of help, coz I'm dealing with Apache 2.0 the book is all about Apache 1.3 theres such a drastic difference between the two mod_perl implementations. Is there any other source of documentation / help I can find ? Yes. There is enough to keep you busy for quite a while: http://perl.apache.org/docs/2.0/user/index.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help getting started ..
Sylbert L wrote: Thanks Stas, the code works just fine now. cool. I've fixed the online doc. This is what i'd read : [Apache 1.3 is hardwired to speak only one protocol, HTTP. Apache 2.0 has moved to more of a server framework architecture making it possible to plugin handlers for protocols other than HTTP. The protocol module design also abstracts the transport layer so protocols such as SSL can be hooked into the server without requiring modifications to the Apache source code. This allows Apache to be extended much further than in the past, making it possible to add support for protocols such as FTP, SMTP, RPC flavors and the like. The main advantage being that protocol plugins can take advantage of Apache's portability, process/thread management, configuration mechanism and plugin API.] So if this is true, then shouldn't it be possible for me to implment a constant connection using Apache 2.0 ? See my previous reply. You need to implement a protocol handler. Here is the URL again: http://perl.apache.org/docs/2.0/user/handlers/protocols.html PS : Any idea when the API docs will be available ? We want to reuse as much of the C headers Apache docs as possible, Lyle is working on writing a tool which will extract them. I'm not sure what's the status of things. Perhaps Lyle can give us an update. Meanwhile, if you aren't sure what APIs to use look in the t/ directory, where there are a few hundreds of tests that exercise most of the existing APIs. Overall 1.3 methods aren't very different in 2.0, there are just a bunch of new methods which are new. Also you can reuse the Apache C documentation as well. See: http://docx.webperf.org and http://lxr.webperf.org/ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::PerlRun weird behavior?
valerian wrote: What mod_perl version are you using? Try to use the latest one. (though PerlRun didn't change for years). I've tested with: mod_perl 1.27 (perl 5.6.1 and 5.8.0) This was the environment: mod_perl 1.21, perl 5.005, apache 1.3.9 (all default packages that came with Debian 2.2r7) I finally had time to setup another machine with Debian 3.0 to test with, and it works like it's supposed to. Very strange... I have no idea what was causing the problem. The new software is: mod_perl 1.26, perl 5.6.1, apache 1.3.26 Most likely there was a bug in some older PerlRun. It's a good idea to run the latest stable sw if possible. Glad to hear that the problem has been resolved. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: flush problem
Udlei Nattis wrote:
hi
i have one problem
look this source:
use strict;
$| = 1;
my ($i,$r);
$r = shift;
$r-content_type('text/html');
while ($i 10) {
$r-printf($i.br\n);
$r-printf(\0);
$i++;
sleep 1;
}
if you try in modperl 1.27 using windows xp and ie6 (others versions is ok)
this code is ok in modperl 1.27 using windows xp and ie6
but if you try modperl 2.0 (last cvs using perl 5.8.0) and httpd-2.0
this code have one problem
code don't send flush, print only when finish
hu $| = 1 in modperl 2.0 dont run :/
Yup, this doesn't work yet. Use $r-rflush() for now.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::PerlRun weird behavior?
Perrin Harkins wrote:
Stas Bekman wrote:
I think I've had enough coffee. PerlRun recompiles the code on each
request, meaning that it re-runs any BEGIN blocks on each request.
Meaning that My::Config will re-import %CF afresh.
That makes sense. I was thinking that keeping track of which BEGIN
blocks had run was somehow separate from the compilation process, but
that seems pretty unlikely now that I think about it.
cool :)
Since use is almost the same as: require+import. require won't be
called because the module will be already in %INC, but import will be
always called.
PerlRun resets %INC after each run, meaning that it should be compiling
the used module again.
It doesn't reset %INC completely, it only resets entries that were
declared with 'package Foo' inside .pl:
for (keys %INC) {
next if $orig_inc{$_};
next if /\.pm$/;
delete $INC{$_};
}
so any .pm modules loaded from the perlrun script stay in %INC.
Moreover, if My::Config was preloaded it'll stay in %INC for sure.
That doesn't explain why he's having trouble though.
If it was a real problem we would have received loads of reports, since
this is such a basic feature. Must be something else that messes up
things for him. He has never followed up with more details, so it's hard
to guess.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
From: Stas Bekman [EMAIL PROTECTED]
What happens if you do:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
Either of these:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
$r-set_handlers('PerlAuthenHandler', \Some::handler);
Yeild:
Can't set_handler with that value...
Which agrees with the Apache.pm docs.
Ah, sorry. I'm living in the future. in mod_perl 2.0 you can pass
\@handlers or \handler for both set_handlers() and push_handlers().
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: SetEnvIf Directive
Pierre Vaudrey wrote: I'm trying to build a web site on the built-in Apache server of a Mac OSX 10.1.5 machine . Extract of httpd.conf is : .. LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so .. AddModule mod_setenvif.c Pierre, this has nothing to do with mod_perl. Please see http://httpd.apache.org/lists.html#http-users __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::PerlRun weird behavior?
Perrin Harkins wrote:
valerian wrote:
So the weird thing is that it runs fine the first time, but when I
reload the page, it doesn't show the variable I imported from
My::Config
Try changing this:
use My::Config;
to this:
require My::Config;
import My::Config;
BEGIN blocks are only run once in PerlRun/Registry, and PerlRun clears
the current namespace after each request, erasing the aliases created by
import.
Of course I can't explain why this worked for Stas. Maybe there is
something about the specific versions of Perl/mod_perl that affects this.
I think I've had enough coffee. PerlRun recompiles the code on each
request, meaning that it re-runs any BEGIN blocks on each request.
Meaning that My::Config will re-import %CF afresh.
It's simply to check, add to your script:
BEGIN { warn BEGIN was called\n; }
you will see the message on every reload.
Since use is almost the same as: require+import. require won't be called
because the module will be already in %INC, but import will be always
called. Again it's simply to check. Add to My::Config:
sub import { warn import was called }
and don't inherit from Exporter. Again you will see import() called on
each request.
In general, you'd be better off just avoiding aliases and
Exporter altogether, since they waste memory and can cause confusion.
Seconded. See
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Using_Global_Variables_and_Sharing_Them_Between_Modules_Packages
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
From: Ryan Parr [EMAIL PROTECTED]
If you have an access handler return OK, then the access handling stops.
Because that handler handled it.
So as far as I know:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return DECLINED;
should work...
Yeah, I tried that. I've also tried AUTH_REQUIRED, FORBIDDEN, and DONE. Since the
authentication phase is after the access phase, my guess has been that the return
from the access phase shouldn't effect the authentication phase. That is, of course,
unless the access phase returns something like SERVER_ERROR. Right?
What happens if you do:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
could be that with push_handlers() you have some other handler that
takes over, before Some::handler has a chance to run.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::PerlRun weird behavior?
valerian wrote:
Hi I'm new at mod_perl, and I decided to start running my scripts with
Apache::PerlRun so I don't have to rewrite them right away (they're too
'dirty' to run under Apache::Registry). Anyway, I figured it was going
to be easy since PerlRun provides an environment similar to CGI, but
something strange is happening. There's a section in the User Guide that
talks about possible problems one can encounter with referenced
variables, so I figured I'd write a very simple test script to see if
that was the case with my code.
So the weird thing is that it runs fine the first time, but when I
reload the page, it doesn't show the variable I imported from
My::Config, and this is what the output looks like this:
html_dir =
count = 1
And this message shows up in the error.log:
[Sat Aug 31 19:59:15 2002] test.pl: Use of uninitialized value at
/home/val/www/cgi-bin/test.pl line 12.
This is such a simple script, but I can't figure out what I'm doing
wrong. What's even more weird is that if I change my httpd.conf to use
Apache::Registry instead of Apache::PerlRun, the script works fine!
(well the value of $count keeps incrementing, but I expected that).
Could someone please tell me what I'm doing wrong? My settings/code are
shown below:
Copy-n-pasted your conf and the code and I cannot reproduce the problem
with Apache::PerlRun.
Do you have this problem when you run the server under 'httpd -X'?
What mod_perl version are you using? Try to use the latest one. (though
PerlRun didn't change for years).
I've tested with: mod_perl 1.27 (perl 5.6.1 and 5.8.0)
- httpd.conf -
PerlWarn On
PerlTaintCheck On
PerlModule CGI
Alias /cgi-perl/ /home/val/www/cgi-bin/
Location /cgi-perl
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
allow from all
/Location
- test.pl -
#!/usr/bin/perl -w
use strict;
use CGI;
use My::Config;
use vars qw($count);
my $q = new CGI;
$count++;
print $q-header(-type='text/html');
print html_dir = $CF{'html_dir'}br;
print count = $countbr;
- My/Config.pm -
package My::Config;
use strict;
use Exporter;
use vars qw(@ISA @EXPORT %CF);
@ISA = ('Exporter');
@EXPORT = qw(%CF);
$CF{'html_dir'} = '/home/val/www/htdocs';
1;
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: modifying @INC at startup and version of perl used
[EMAIL PROTECTED] wrote: [...] So are you forced to use the version of perl that was chosen when mod_perl was installed? Guess so, am trying to do a local non-root install of apache and mod_perl to see if this is so. It helps to RTFM: http://perl.apache.org/docs/1.0/guide/install.html#Should_I_Rebuild_mod_perl_if_I_have_Upgraded_Perl_ http://perl.apache.org/docs/1.0/guide/install.html#Installation_Without_Superuser_Privileges __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: base.pm seems to fail a check
Stefano wrote:
Hello,
I was not able to find anything similar in list archives,
Trying to :
use base Ima::DBI
in mod_perl (also in a Perl/Perl block of config)
a cought this trace:
Uncaught exception from user code:
Can't locate DBI/db.pm in @INC (@INC contains: [...]
This happens because Ima::DBI 'uses' base DBI::db at line 645 of his
source code and DBI::db is not a package available from @INC but
directly from the DBI namespace.
In these cases base.pm (line 42) steps into an unless{} block
to by-pass 'Can't locate ...' exceptions rised from inside base.pm
itself:
eval require $base;
# Only ignore Can't locate errors from our eval require.
# Other fatal errors (syntax etc) must be reported.
-- die if $@ $@ !~ /^Can't locate .*? at \(eval /; #'# --
Working outside mod_perl (i.e. in a command line perl program) no
problem jumps out because the above arrowed 'die' correctly matches
its regexp (the exception message starts at the beginning of the line).
From inside mod_perl we have an unmatch so base croaks with the complete
backtrace and httpd doesn't start (if I pre-use the module) or send
500 - Server Error (in a runtime require).
With the follow substitution it works, but I'm sure there is a better
and more correct way to behave with.
In base.pm :
42: die if $@ $@ !~ /^Can't locate .*? at \(eval /; #'#
42: die if $@ $@ !~ /Can't locate .*? at \(eval /; #'#
Obviously, base.pm should flex it's regex, but this is not an option
with released perls.
I can think of 2 things:
1. override the problematic subroutine in base.pm so it'll do the right
thing.
2. preload the module that you pass to 'use base' before loading the
module that includes 'use base ...'
in any case, please check whether the problem persists in the bleed-perl
(i.e. 5.9.0-dev) and if so, make sure it gets fixed, by sending a
bugreport to p5p.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Filehandles
I think he said mod_perl 2 in his inital post. Which I'm not sure really is all that swift with concurrant requests under threaded mpms (Win32 is limited to threaded mpms) ... least nobody seems 100% happy with the threaded mpm performance of mod_perl 2 yet (Stas? Anybody? How's it looking?) Caution: you are entering unchartered waters. first of all: you must use 5.8.0 with threaded mpms perl 5.8.0 internals are thread-safe, so does mod_perl 2.0-dev. By saying that perl is thread-safe, I mean that operations like push, =, /, map, chimp, etc. are thread-safe. Operations that involve system calls, may or may not be thread-safe. This varies from OS to OS, and even varies for various versions of the same OS. e.g. localtime() is not thread-safe on platforms where asctime(3) is not thread-safe. other problematic ones are readdir(), srand(), ... there is another important issue. what some people are referring to as: thread-locality. Certain functions executed in a single thread affect the whole process e.g. if you chdir() in one thread, all other thread now see the cwd of that thread that chdir'ed. Other problematic functions are umask(), chroot(), %ENV... Getting back to the Justin's question, it's quite possible that thread-safety problems kick in. It could be that flock is not thread-safe. But I think the real problem is with chdir(), because Apache::Registry chdir()s to the dir of the script. Stop using Apache::Registry and start using ModPerl::Registry, which doesn't chdir(). Of course you cannot do any operations with relative path anymore. Arthur Bergman is working on some solutions for chdir(), but nothing was released so far. So you will have to wait or help Arthur to finish his work. So first try using ModPerl:Registry, which I expect will resolve the issue. If that doesn't help, please supply a *short* script that reproduces the problem. Which of course may not exhibit the same behavior on a different platform, but at least we can do some sanity check. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Filehandles
I'm using Perl 5.6 Unless someone with better knowledge pipes up, to the best of my knoweledge there are threading/concurrancy issues with mod_perl 2 and 5.6.1 ... I know that Randy has said in places that eventually the officiall recomdendation for Win32 Apache/mod_perl 2 will be 5.8 because it's theoretically more thread safe. It's not threoretical, it's practical. There are thread-safety problems with perl interpreters in 5.6. It's possible that your code doesn't hit them, so 5.6 may work for you, but why taking the risk, use 5.8.0. expect mod_perl 2.0 *requiring* 5.8.0 for threaded mpms when it gets released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r-print() with slow clients and stop button
[...] I'd like to somehow send data to the client and have execution continue until the end of a time critical section, after which it will wait for acknowledgement of all data that was sent and if that is not received within X seconds, kill the connection and return OK. http://perl.apache.org/docs/1.0/guide/debug.html#Handling_the__User_pressed_Stop_button__case [...] __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: compilation problems in mod_perl
Amir wrote: Hello, I am trying to compile mod_perl in my Redhat Linux 7.2. I run perl 5.8.0, when I do perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 Its looks fine (I get no errors) but then when I try to do make I get the following: - cd src/modules/perl make -f Makefile.modperl make[1]: Entering directory `/usr/src/mod_perl-1.99_04/src/modules/perl' gcc -I/usr/src/mod_perl-1.99_04/src/modules/perl -I/usr/src/mod_perl-1.99_04/xs -I/usr/local/apache2/include -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm -I/usr/local/lib/perl5/5.8.0/i586-linux/CORE -DMOD_PERL -O2 -fpic \ -c mod_perl.c mv mod_perl.o mod_perl.lo mod_perl.c: In function `modperl_register_hooks': mod_perl.c:511: warning: passing arg 3 of `ap_register_output_filter' makes pointer from integer without a cast mod_perl.c:511: too few arguments to function `ap_register_output_filter' mod_perl.c:515: warning: passing arg 3 of `ap_register_input_filter' makes pointer from integer without a cast mod_perl.c:515: too few arguments to function `ap_register_input_filter' mod_perl.c:519: warning: passing arg 3 of `ap_register_output_filter' makes pointer from integer without a cast mod_perl.c:519: too few arguments to function `ap_register_output_filter' mod_perl.c:523: warning: passing arg 3 of `ap_register_input_filter' makes pointer from integer without a cast mod_perl.c:523: too few arguments to function `ap_register_input_filter' make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/usr/src/mod_perl-1.99_04/src/modules/perl' make: *** [modperl_lib] Error 2 - You are trying to use a beta version of mod_perl-2.0. Use mod_perl 1.27 with Apache 1.3.x for now if you want something stable. mod_perl 1.99_04 works with Apache 2.0.39 only. mod_perl 1.99_05 works with Apache 2.0.40. This will solve the problem that you've reported. When reporting problems remember to follow either http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems or http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems both linked from the shortcuts menu on any page at perl.apache.org. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Change in module naming conventions
Nick Tonkin wrote:
- nick
Nick Tonkin {|8^)
On Tue, 27 Aug 2002, Per Einar Ellefsen wrote:
- I originally had Apache::Auth::Authen, ::Authz and ::Access, but Robin
Berjon told me he preferred to have the 4 as top-level namespaces. What do
people think?
I'm in favor of your approach. I have it like that in my
stuff. Auth::Auth, Auth::Authz, and Auth:: Access.
But Authentication, Authorization and Access aren't all Auth. May be
using Apache::AAA:: as in httpd-2.0/modules/aaa/ ?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Segmentation Fault with mod_php and mod_perl
Alex Lee wrote:
This is what I got from core backtrace:
gdb /usr/local/src/apache/current/src/httpd
[...]
Program received signal SIGSEGV, Segmentation fault.
0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
778if (!(r-finfo.st_mode S_IXUSR)) {
please finish reading the section explaining how to get the backtrace.
You've got only the first frame. You need to execute 'bt' or 'where' to
get it all.
Are you going to say this is a PHP bug? :-)
But how come if I only activate PHP module, it works fine.
Something affects a datastructure which PHP uses and segfaults in it.
But get first the whole backtrace.
Alex
From: Stas Bekman [EMAIL PROTECTED]
To: Alex Lee [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Segmentation Fault with mod_php and mod_perl
Date: Tue, 27 Aug 2002 11:54:38 +0800
Alex Lee wrote:
There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27
running with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the
same configuration seems to work fine).
[...]
Segmentation Fault (11)
[...]
running with truss ./httpd -X produce:
Sending the core backtrace should help more that the output of truss.
See
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Clashing Apache::Symbol - Symbol ?
ODELL, TODD E (SWBT) wrote: I just recently got my mod_perl to work. Config is mod_perl-1.27/Apache-1.3.26 on AIX 4.3.3. I wrote a PerlAuthenHandler which uses Expect.pm, requiring the normal Symbol.pm. In my startup.pl script for mod_perl I had this line: use lib qw(/usr/opt/perl5/lib/site_perl/5.6.1/aix/Apache); I get a bareword error when IO:Handle tries to call the gensym(Symbol.pm) BUT if I comment the above line out it seems to get past that. I see that there is an Apache::Symbol which looks quite different than the 'normal' one. My question is by letting the normal Symbol.pm load, so IO:Handle will work, is that going to mess things up since the Apache::Symbol is different? Or will everything be able to know which to use? eh? why in the world you are trying to do that? there is no /usr/opt/perl5/lib/site_perl/5.6.1/aix/Apache, there is /usr/opt/perl5/lib/site_perl/5.6.1/aix. Of course you will have problems when you load the wrong package. It's Apache::Symbol, not Symbol in the dir Apache/. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload -- can't locate main.pm?
Ken Miller wrote: I've been successfully using Apache::Reload for a few weeks now. However, I installed it on my home development system, and I'm getting this error when accessing a module that contains 'use Apache::Reload': [Mon Aug 26 09:59:12 2002] [error] Can't locate main.pm in @INC (@INC contains: ... at /home/miller/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 132. (yes, I install some modules under my own root tree - it keeps the base distribution nice and clean) What's main.pm, and why can't Apache::Reload find it? I've searched the archives, but have had little success in finding anything interesting. Apache1.3.26, mod_perl 1.26. In addition to Darren's reply, this explains what happens: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html#Description says: Note that Apache::Reload operates on the current context of @INC. Which means, when called as a Perl*Handler it will not see @INC paths added or removed by Apache::Registry scripts, as the value of @INC is saved on server startup and restored to that value after each request. In other words, if you want Apache::Reload to work with modules that live in custom @INC paths, you should modify @INC when the server is started. - __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Segmentation Fault with mod_php and mod_perl
Alex Lee wrote: There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27 running with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same configuration seems to work fine). [...] Segmentation Fault (11) [...] running with truss ./httpd -X produce: Sending the core backtrace should help more that the output of truss. See http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: installing mod_perl on binar
Hytham Shehab wrote: hi guys, how can i install mod_perl under a pre-installed Apache 2 binary installation? all what i found through docs is installing via source copies. You don't say what platform you are on. On Unix it's all the same, just skip the build/installation of the Apache stage. On win32 I don't know, probably the same too. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Make test failure when installing mod_perl 2.0 on Solaris 8 withApache 2
Tom Hibbert wrote: Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: [...] bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in Try this patch: Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 20 Aug 2002 15:31:18 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache/2.0.40 (Win32) mod_perl/1.99_05-dev Perl/v5.6.1
The only problem left is perl-status. It still does not work. My relevant entry in the config is: Location /perl-status SetHandler perl-script PerlHandler Apache::Status Order deny,allow Deny from all Allow from 127.0.0.1 The error log says: /Location[Sun Aug 18 21:02:08 2002] [error] failed to resolve handler `Apache::Status' It's not supposed to work, yet. It wasn't ported to 2.0. If you have mod_perl 1.0 installed, the 1.0 version is almost fully working under mod_perl 2.0 (The 'Compiled Registry Scripts' menu entry needs some tweaks). To make it working you need the following: PerlModule Apache2 PerlModule Apache::compat PerlModule Apache::Status Location /perl-status SetHandler perl-script PerlHandler Apache::Status Order deny,allow Deny from all Allow from 127.0.0.1 /Location __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: HTML::Template
Pierre Vaudrey wrote: I'm trying to run the following HTML::Template simple example : [...] Could anybody help me to fix it ? Pierre, you are asking an HTML::Template question at the wrong forum, seems that this is the place where you want to ask this instead: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.5/Template.pm#FREQUENTLY_ASKED_QUESTIONS __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI make apache fail in perl58.dll
pascal barbedor wrote: PERL58! 280681d9() -- error here access violation DBI! 003970b6() PERL58! 2803f289() PERL58! 2805cf4c() PERL58! 2806b821() PERL58! 2808596f() MOD_PERL! 100018b7() LIBHTTPD! 6ff012a6() Hi here is maybe more informative stack trace WARNING: Stack unwind information not available. Following frames may be wrong. perl58!Perl_ptr_table_fetch+0x8 DBI+0x70b6 perl58!Perl_sv_compile_2op+0x76ca perl58!Perl_runops_standard+0xc perl58!perl_clone_using+0x1eac perl58!perl_clone_host+0x6d mod_perl!modperl_interp_new+0x39 libhttpd!ap_run_post_config+0x36 that's a weird trace. it's still incomplete, but getting better. One things missing is 'DBI+0x70b6'. Can you now rebuild DBI? It should pick the debug flags from perl (which you've apparently just rebuilt). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [modperl-2.0] unresolved external on win32 when compiling
pascal barbedor wrote: Hi when compiling modperl 1.99_05 (from today cvs) with MP_DEBUG=1 there is un unresolved external RequestIO.obj : unresolved external symbol _times RequestIO.dll fatal LNK error this is with perl 5.8.0 compiled with DEBUG flag win XP MSVC6 Perhaps someone on win32 can check this out. Randy? PS modperl-1.99_04 downloaded from perl.apache.org shows this error (with same compiling configuration) mod_perl.c(519) : error ap_register_output_filter different types formal and actual parameters 3 mod_perl.c (523): error ap_register_input_filter too few actual parameters that's ok. you aren't supposed to build _04 with apache 2.0.40 or higher. it's time to release _05. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI make apache fail in perl58.dll
pascal barbedor wrote: SharedUserData!SystemCallStub+0x4 ntdll!ZwTerminateProcess+0xc kernel32!_ExitProcess+0x57 kernel32!ExitProcess+0x11 msvcrt!__crtExitProcess+0x2f msvcrt!_cinit+0xe4 msvcrt!exit+0xe WARNING: Stack unwind information not available. Following frames may be wrong. perl58!Perl_Tregnarrate_ptr+0x14809d perl58!Perl_Tregnarrate_ptr+0x57255 perl58!Perl_Tregnarrate_ptr+0x56ef8 perl58!Perl_Tregnarrate_ptr+0x13fc84 perl58!Perl_Tregnarrate_ptr+0x13fcd9 perl58!Perl_Tregnarrate_ptr+0xfeb7a perl58!Perl_Tregnarrate_ptr+0xfe465 DBI!XS_DBI__clone_dbis+0x27b DBI!XS_DBI__clone_dbis+0x100 perl58!Perl_Tregnarrate_ptr+0x96df8 perl58!Perl_Tregnarrate_ptr+0x17de8 perl58!Perl_Tregnarrate_ptr+0x52c21 perl58!Perl_Tregnarrate_ptr+0x5237c I am affraid it's the best I can do, it's very hard to compile debug on win32 I have seemingly compiled perl58 DEBUG (there was a complain about missing vc60.pdb, and I supplied one I found ) I cannot compile debug either modperl1-99_04 either _05 against my debug perl. so I just copied from perl/site/lib everything concerning modperl into the perldebug site/lib tree (don't know if this is liable) I also properly installed DBI-1.30 in the perldebug site/lib tree then I ran apache in windbg and got this stacktrace also here is the last loading modules sequence inside apache ModLoad: 6fbf 6fbf6000 C:\Apache2\modules\mod_userdir.so ModLoad: 2800 281a3000 C:\perld\bin\perl58.dll ModLoad: 1000 1001 C:\Apache2\modules\mod_perl.so ModLoad: 71a9 71a98000 C:\WINDOWS\System32\wshtcpip.dll ModLoad: 0036 00383000 C:\perld\site\lib\auto\DBI\DBI.dll ModLoad: 0039 00399000 C:\perld\site\lib\auto\Apache\RequestRec\RequestRec.dll ModLoad: 003a 003a6000 C:\perld\site\lib\auto\Apache\RequestIO\RequestIO.dll ModLoad: 003b 003b8000 C:\perld\site\lib\auto\ModPerl\Const\Const.dll ModLoad: 003c 003c5000 C:\perld\site\lib\auto\Apache\Const\Const.dll --error at this point since it is past DBI.dll , maybe this is because I copied incompatible modperl to perld site/lib tree. hope this can help I don't think this has anything to do with loading dlls. It definitely happens when DBI gets loaded. May be DBI-1.30 still needs work, as it seems to work on linux, but not on windows. Have you considered asking on the dbi-users list? including posting the traces there? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache2, DBD/Oracle problem
Atsushi Fujita wrote: Hi Stas, Can you please try to convert the script into a mod_perl handler and test again? OK, I just checked it. The result was everything fine using by mod_perl handler! There was no problem in my new code. ...But I want to use ModPerl::Registry, because this is easy to migrate from normal CGI script. Please investigate the reason. I still doubt it's a registry problem. Because you've used different SetHandler's for the registry and the mod_perl handler. I bet that if you set: Location /perl SetHandler modperl ^^^ PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location it'll all work. Read: http://perl.apache.org/docs/2.0/user/config/config.html#mod_perl_2_0_Handlers and that will explain the problem. Please let us know if this was indeed the cause. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Change program name of httpd process
Oleg Shaikhatarov wrote: Stas Bekman wrote: Oleg Shaikhatarov wrote: Hello, all! I need to change proctitle (called $PROGRAM_NAME or $0 in perl) of httpd process from mod_perl. Simple change of $0 variable works well for standalone perl program, but don't work under mod_perl. I'm not sure if it's possible, but if anyone have an idea how to do this please help. please give us some more details. What do you do and what doesn't work. e.g. Apache::Registry sets $0 to the location of the currently processed script. Why cannot you do the same? Thanks for the response. I need to change program name as it seen by ps command. In other words ps ax | grep http gives something like: 21718 ?S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY 21719 ?S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY 21720 ?S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY 23140 pts/4S 0:00 grep http But I need this output to be: 21718 ?S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY 21719 ?S 0:00 my custom title here 21720 ?S 0:00 my another custom title here 23140 pts/4S 0:00 grep http And I need to change this from mod_perl. I understood that. You aren't saying *where* do you need it, that's why I've asked for more details. If you want to do that for mod_perl handlers, mod_perl sets $0 to the httpd path during the perl_startup (see mod_perl.c:713). Therefore you probably want to write a PerlChildInitHandler that overrides $0. If you want the same behavior for Registry scripts, which always set $0 to the location of the currently processed script you have to subclass Apache::RegistryNG and override the method set_script_name() which does exactly that. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache2, DBD/Oracle problem
Atsushi Fujita wrote:
Hi Stas,
I checked using by 'SetHandler modperl', but apache responded no data without
error.
Apache log said HTTP response code was 200, but size was 0.
192.168.1.xxx - - [16/Aug/2002:22:01:51 +0900] GET /cgi-bin/test1.cgi
HTTP/1.1 200 0
What is wrong? I still counldn't understand clearly.
because under 'SetHandler modperl' the script must be written
differently. I guess the easiest is to try the other way around. Take
the mod_perl handler that worked, and change it to be 'SetHandler
perl-script', does it still work?
Thank you.
Atsushi
[/conf/httpd.conf]
IfModule mod_perl.c
PerlRequire /yopt/httpd-2.0.39_prefork_perl5.6.1normal/conf/startup.pl
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler modperl
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
[/conf/startup.pl]
use Apache2 ();
use lib qw(/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin);
# enable if the mod_perl 1.0 compatibility is needed
# use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use APR::Table ();
use ModPerl::Registry ();
use Apache::Const -compile = ':common';
use APR::Const -compile = ':common';
1;
[/cgi-bin/test1.cgi]
#!/yopt/perl5.6.1normal/bin/perl
use strict;
use DBI;
my $dsn = 'dbi:Oracle:';
my $user = 'username/password';
my $password = '';
my $dbh;
my $sth;
my $sql = select SEQUENCE_OWNER, SEQUENCE_NAME, LAST_NUMBER from
ALL_SEQUENCES;
my $rv;
my @row;
#
print Content-type: text/html\n\n;
$ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
$ENV{'ORACLE_SID'} = 'ynt0';
$ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
print ORACLE_HOME=$ENV{'ORACLE_HOME'}br\n;
print ORACLE_SID=$ENV{'ORACLE_SID'}br\n;
print NLS_LANG=$ENV{'NLS_LANG'}br\n;
print DSN=$dsn$ENV{'ORACLE_SID'}br\n;
$dbh = DBI-connect($dsn$ENV{'ORACLE_SID'}, $user, $password)
or die Cannot connect: .$DBI::errstr;
$sth = $dbh-prepare($sql)
or die Cannot prepare: .$dbh-errstr();
$rv = $sth-execute
or die Cannot execute: .$sth-errstr();
print sth=$sth,rv=$rv\n;
while(@row = $sth-fetchrow_array){
print @row\n;
}
$sth-finish();
$dbh-disconnect();
exit(0);
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Atsushi Fujita [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, August 16, 2002 6:12 PM
Subject: Re: apache2, DBD/Oracle problem
Atsushi Fujita wrote:
Hi Stas,
Can you please try to convert the script into a mod_perl handler and
test again?
OK, I just checked it.
The result was everything fine using by mod_perl handler!
There was no problem in my new code.
...But I want to use ModPerl::Registry, because this is easy to migrate
from
normal CGI script.
Please investigate the reason.
I still doubt it's a registry problem. Because you've used different
SetHandler's for the registry and the mod_perl handler.
I bet that if you set:
Location /perl
SetHandler modperl
^^^
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
it'll all work.
Read:
http://perl.apache.org/docs/2.0/user/config/config.html#mod_perl_2_0_Handlers
and that will explain the problem.
Please let us know if this was indeed the cause.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Simple Database connect
David Wheeler wrote: On Friday, August 16, 2002, at 07:52 AM, Pierre Vaudrey wrote: dyld: /usr/sbin/httpd multiple definitions of symbol __dig_vec /usr/libexec/httpd/libphp4.so definition of __dig_vec /Library/Perl/darwin/auto/DBD/mysql/mysql.bundle definition of __dig_vec dyld: /usr/sbin/httpd multiple definitions of symbol __dig_vec /usr/libexec/httpd/libphp4.so definition of __dig_vec /Library/Perl/darwin/auto/DBD/mysql/mysql.bundle definition of __dig_vec It looks as though you have some symbol conflicts between PHP and MySQL. Try turning off libphp.so. If that works, you may need to recompile PHP and/or MySQL. most likely this: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#_exit_signal_Segmentation_fault__11___with_mysql And this: [Fri Aug 16 10:38:41 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName is amended by adding: 127.0.0.1 localhost.localdomain localhost to /etc/hosts __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI make apache fail in perl58.dll
pascal barbedor wrote: same here. segfault in startup.pl. not sure what version it was, but 1.30 installed DBI 1.30. no more segfault. segfault for me on win XP with DBI 1.30 if DBI is used in the startup.pl (apache 2.0.40 modperl 1.99_05 perl 5.8) I reinstalled DBI 1.30 from CPAN just in case, installs and tests ok, but the same error occurs on apache (in perl58.dll.) if module used in startup.pl and no error if use DBI from a registry script (PerlResponseHandler ModPerl::Registry) My working case is on linux, perl 5.8 with ithreads enabled, the rest is the same. Can you retrieve a backtrace from the core file? The version that I was using before 1.30 (I think it was 1.29) was blowing so badly that it was leaving no stack. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: win32 apache2.0.40 mod_perl-2
Paul Simon wrote: Hi all I upgraded from apache2.0.39 to 40 and removed, installed mod_perl-2 via ppm. Now my Apache::Registry directory is not responding. The browser just hangs. Any tips on how I can troubleshoot this? Everything is set up the way I had it working for 2.0.39 and mod_perl-2 Try: http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl install problem
J. W. Ballantine wrote: [...] perl Makefile.PL MP_AP_PREFIX=/a3/APACHE/Apache2 MP_INST_APACHE2=1 MP_USE_STATIC=1 everything makes ok, but when I try to install, it fails with: AKIVA $ make install cd src/modules/perl make -f Makefile.modperl cd src/modules/perl make -f Makefile.modperl install test -f mod_perl.so \ cp mod_perl.so /a3/APACHE/Apache2/modules *** Error code 1 make: Fatal error: Command failed for target `install' Current working directory /a4/WWW/APACHE2/modperl-2.0-CVS-20020816/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target `modperl_lib_install' Other then the need to upgrade perl, why is the install not recognizing that mod_per..a is built and not mod_perl.so. MP_USE_STATIC=1 is not really working yet. It builds the .a target but the build is not yet polished for this install. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl recommended version matrix
Andrew Ho wrote: Hello, Today I went to the mod_perl website with the intention of asking, what version of mod_perl works with Perl 5.8? I found that there wasn't an easy way to find this out. We seem to get a lot of questions on the list about mod_perl with Apache 2 and so forth. Perhaps it would be a good idea to have a recommended version matrix for mod_perl? For example, to indicate that mod_perl 1.27, Apache 1.3.26, and Perl 5.6.1 are a stable combination, whereas if you have Apache 2.0.40, you need mod_perl 1.99 and whichever version of Perl. It's not stated anywhere, because it just works. we are talking about mod_perl 1.0 here. It works with any of the perl versions 5.5-5.8. If you are talking about mod_perl 2.0, here is the info: - prefork mpm requires 5.6.0 or higher (preferrably at least 5.6.1) - threaded mpms require 5.8.0. It should be listed here: http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites I'll update it shortly. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: regional mod_perl mailing lists?
[First mentioned on the dev list, I'm moving it to the users list] I've started International mod_perl mailing lists page http://perl.apache.org/maillist/i18n.html Now it includes only one Japanese list, courtesy Tatsuhiko Miyagawa If you know about any other mod_perl mailing lists please let us know. Thanks. Tatsuhiko Miyagawa wrote: Hi I'm running Japanese mod_perl mailing list. http://bulknews.net/lib/ml/ This list is working on a free mailing list service called freeml in Japan. At Tue, 12 Mar 2002 11:16:16 +0800, Stas Bekman wrote: I was thinking today about the possibility of regional mod_perl mailing lists - kinda like the way local perl mongers have their own lists to coordinate group activities, post local jobs, and just keep in touch with others in their area with similar interests. This is a good idea to especially take some load off the users list. Plus help people with the language barrier. before posting an RFC to modperl@ I thought I'd ask about it here first: whether anyone thought it was a good idea, whether the perl.apache.org domain was a good place to host the lists, creation and management issues, and so on... That's a tough question, I guess Ask would be the best person to answer this question. Alternatively we could check the same thing with perl.org, which already have the infrastructure. Or why not to simply work with perl mongers and create a parallel tree of mod_perl mongers and ride on top of the perl mongers infrastructure? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PerlResponseHandler ?
Paul Simon wrote: Hi All Can somebody answer this for me? Here are two directives for separate directories(1 and 2) to run under ModPerl::Registry (ModPerl::Registry is being called in via a perl startup.pl): Location /mydir1 SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location Location /mydir2 SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location I'm wondering, Is it better to create one directive like Location /perl SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location and put /mydir1 and /mydir2 in the /perl directory? Is it just a matter of managing directories or is there a memory or performance issue? I'd prefer to use the separate directive approach, but I want to make sure it's not causing extra overhead. whichever way you prefer is fine. when Perl sections will be ported things will be even easier. I doubt there is any significant speed difference. If still in doubt -- benchmark. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Possible naming error when extracting mod_perl 2 tarball
Tom Hibbert wrote: Hi, I downloaded the mod-perl 2.0 tarball today from: http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz When I untar'd it: bash-2.03$ tar xf mod_perl-2.0-current.tar It extracted to the following directory: drwxr-x--- 13 software software 512 Jun 21 23:40 mod_perl-1.99_04 I was just wondering if this was correct (i.e mod_perl 2.0 extracting to mod_perl 1.99 directory). After looking at the files it looks like it is mod_perl 2 and therefore just a naming error in the archive - a minor issue, but I thought I would ask. That's correct. It'll become mod_perl-2.0.xx when the first production version is released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache2, DBD/Oracle problem
Atsushi Fujita wrote: Hi Lyle, I does seem to be an ORACLE environment issue. Can you please try to convert the script into a mod_perl handler and test again? I doubt this is registry problem, but probably something that about setting up the env for mod_perl in general. What would help most is to write a test that exposes this problem. I don't have Oracle, so if you could help me reproduce the problem, I'd know what to fix. Thanks! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: SOLVED: How to access base environment from Perl sections
Tom Mornini wrote:
Perhaps it's obvious but after years of mod_perl, I was blocked,
probably because using this basic Perl ability is frowned upon in
mod_perl due to performance issues. Of course, during startup,
performance isn't an issue. :-)
In my case, I wanted to PerlPassEnv all environment variables that began
with EWINGZ_
Perl
for ( grep { /^EWINGZ_/ } `env` ) {
my ($key) = /^([^=]+)/;
push @PerlPassEnv,$key;
}
/Perl
Stas: I asked this question almost exactly a year ago and nobody
answered it. I asked it yesterday, and again nobody answered it. Perhaps
this should be the Perl Sections section of the guide? After all, the
guide already mentions something very similar to this.
Funny, but there are too many things in the guide to remember. The new
search feature exposes them all, just remember to use it.
I was just about to add your tip, when I've found it
http://perl.apache.org/docs/1.0/guide/porting.html#Passing_ENV_variables_to_CGI
which was added about 3 years ago:
http://perl.apache.org/docs/1.0/guide/Changes.html#05_17_1999_ver_1_11
may be we need to add a xref from the Perl sections section?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Another mod_perl-1.99_04 compile failure
J. W. Ballantine wrote: After applying the patch Kyoichi sent, mod_perl.c compiled fine and the make continued until: cd src/modules/perl make -f Makefile.modperl cc -c -I/a4/WWW/APACHE2/mod_perl-1.99_04/src/modules/perl -I/a4/WWW/APACHE2/mod_perl-1.99_04/xs -I/a3/APACHE/Apache2/include -I/usr/local/include -DMOD_PERL -O -DVERSION=\0.01\ -DXS_VERSION=\0.01\ -KPIC -I/usr/add-on/perl-5.6.0/lib/5.6.0/sun4-solaris/COR E Table.c /usr/add-on/perl-5.6.0/lib/5.6.0/sun4-solaris/CORE/perl.h, line 23: warning: macro redefined: VOIDUSED /a4/WWW/APACHE2/mod_perl-1.99_04/xs/APR/Table/APR__Table.h, line 73: undefined struct/union member: a /a4/WWW/APACHE2/mod_perl-1.99_04/xs/APR/Table/APR__Table.h, line 73: non-unique member requires struct/union object: pool /a4/WWW/APACHE2/mod_perl-1.99_04/xs/APR/Table/APR__Table.h, line 73: warning: left operand of . must be struct/union object /a4/WWW/APACHE2/mod_perl-1.99_04/xs/APR/Table/APR__Table.h, line 73: cannot access member of non-struct/union object Apache has changed its API again. The cvs version solves this problem. Remember that mod_perl 1.99_04 works with Apache 2.0.39. If you take a newer Apache 2.0.40 or Apache cvs, you must either wait for 1.99_05 to be released, or use the mod_perl cvs. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl-1.99_04 compile failure
J. W. Ballantine wrote: Thanks, that solved the problem. which has been already solved in cvs. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache2, DBD/Oracle problem
Mike P. Mikhailov wrote:
Hello Fredo Sartori,
Thursday, August 15, 2002, 1:44:34 PM, you wrote:
I mabe wrong, but what about to move code to setup ENV out from BEGIN
block ? I wrote simple test below:
# Test.pm
package Test;
use Apache::Constants qw ( :common );
BEGIN {
$ENV{FOO1} = 'BAR1';
$ENV{FOO2} = 'BAR2';
}
sub handler {
my $r = shift;
$r-print(Content-Type: text/plain\n\n);
print FOO1=$ENV{FOO1}, FOO2=$ENV{FOO2}\n;
return OK;
}
1;
__END__
# httpd.conf
SetEnv FOO1 QQ1
SetEnv FOO2 QQ2
Location /test
SetHandler perl-script
PerlHandler Test
PerlSendHeader On
/Location
One the first request of the fresh apache, I got:
FOO1=BAR1, FOO2=BAR2
On all subsequent requests:
FOO1=QQ1, FOO2=QQ2
I thing this is because mod_perl reset ENV hash on each request, but
I'm not sure. And I'm on Apache/1.3.23 (Unix) mod_perl/1.26. Not on
apache2. Did you confirm such behaviour of MP2 ?
The behaviour didn't change in 2.0.
Does not find any
mention which confirm this in the guide :(
It's because 2.0's documentation has its own guide:
http://perl.apache.org/docs/2.0/
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Compiling problems with Apache 2.040 (Win32)and mod_perl2 lastversion.
Stefan Sabolowitsch wrote: Hi NG. I has here the current Apache 2.040 for Win32. With compile of the last mod_perl2 version, get I the following error message. [...] mod_perl.c(511) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(511) : warning C4024: 'ap_register_output_filter' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 3 mod_perl.c(511) : error C2198: 'ap_register_output_filter' : Nicht genuegend Par ameter uebergeben [...] With Apache 2.039 (Win32) there are no problems. Possibly does someone have an idea? Try building with the cvs mod_perl version: http://perl.apache.org/docs/2.0/user/install/install.html#Installing_from_Source __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: naming convention
Michael Robinton wrote: I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. I guess that this module is not extending mod_perl functionality, but simply optionally uses it and therefore you better off discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without even mentioning mod_perl so not to confuse people. If my guess is wrong (you provided too little info) and it *requires* mod_perl it should probably be named something like Apache::ColorPicker, but again, you've provided too little info to tell. See: http://www.bizsystems.net/downloads/graphics/demo.html FWIW, it doesn't seem to do anything on mozilla-1.0/linux. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: naming convention
Michael Robinton wrote:
Stas wrote:
Michael Robinton wrote:
I have a proposed perl / modperl module that will go to CPAN
Graphics::ColorPicker : A perl module for WYSIWYG web
applications that allow selection of HEX color numbers
I think this is an appropriate name, but have not submitted in
this category before. Please advise.
I guess that this module is not extending mod_perl functionality,
but simply optionally uses it and therefore you better off
discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
even mentioning mod_perl so not to confuse people. If my guess is
wrong (you provided too little info) and it *requires* mod_perl it
should probably be named something like Apache::ColorPicker, but
again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
so my guess was right, take it to one of the lists I've mentioned for
the best effect. Here we discuss modules which extend or exclusively use
mod_perl.
See: http://www.bizsystems.net/downloads/graphics/demo.html
FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
I cannot tell you more, because it doesn't do anything ;). I enter
FA23DB as suggested, click on the button, and get a window whose source is
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01
Transitional//ENhtmlheadtitle/title/headbody/body/html
but we are going OT here, let's take it off the list.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl install on SGI
Tom Keller wrote: Greetings, I am trying to install mod_perl with apache_1.2.26 on and SGI running 6.5.16. apache was installed from the freeware.sgi.com website using their very nice installer. Unfortunately, the clean up after installation seems to remove the Makefile that is used by mod_perl's Makefile. So running install mod_perl from cpan, I get the question Please tell me wher I can find your apache src [ ../apache_x.x/src] I can't seem to give it a path that works. I know the executable is at /usr/freeware/apache, but that gives the message can't open /Makefile No such file. I've also tried using /var/inst/fw_apache which is the downloaded source file. No dice. CPAN asks for your apache '/src' dir, not the location of the binary or the source base dir. e.g. if you've untarred the apache source in /tmp/apache_1.3.26, you should pass /tmp/apache_1.3.26/src when prompted by mod_perl installer. See http://perl.apache.org/docs/1.0/guide/install.html for more info. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Mismatched Prototyped with mod_perl
Yair Lenga wrote:
I've currently in the process of moving from CGI to mod_perl. I noticed several
people that complain about Mismatched prototype warning. while most of the messages
are caused by perl handling of function declaration, I think that some of the
messages can be reduced by fixing 'mod_perl':
The flush_namespace was not checking for empty prototypes (i.e.,function that does
take zero parameters, like most of the constant functions). I.e.
sub PI () { 3.1415 } was treated the same as
sub PI { 3.1415 }
I made a minor modication to the code, and that has eliminated many warnings
(especially from libwww). I hope that someone can review those changes and commit
them to the master source code, for the next mod_perl release).
Thank you Yair, committed.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Handler Concept / Question
Rick Myers wrote: On Aug 12, 2002 at 11:50:56 -0600, Thomas Whitney wrote: I was following this thread with interest because I want to do something like this. I started searching on list archive for the above mentioned syntax, I searched for 'static content', then 'default handler', but with no luck. I do not mind doint the the searching, if you would perhaps suggest a couple other search topics. You were close. It's default-handler. http://httpd.apache.org/docs/handler.html And in mod_perl docs: http://perl.apache.org/docs/1.0/guide/config.html#Overriding_E_lt_LocationE_gt__Setting_in__Sub_Location_ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: please unsubscribe me
[EMAIL PROTECTED] wrote: please unsubscribe me Only you can do that. Look at the email header, it says: list-unsubscribe: mailto:[EMAIL PROTECTED] __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: error_log [info] [debug] lines
Anton Permyakov wrote: Hello, all. My error_log is abounded with following lines. What does it mean, and how it impacts on Apache performance in general? You sometimes get these when clients abort their connections. There is not much you can do about that. It doesn't impact the performance. Thank you. [Sat Aug 10 12:50:03 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed [Sat Aug 10 12:50:03 2002] [debug] Apache.c(364): (104)Connection reset by peer: mod_perl: rwrite returned -1 (fd=3, B_EOUT=8) [Sat Aug 10 12:50:04 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed [Sat Aug 10 12:50:04 2002] [debug] Apache.c(364): (104)Connection reset by peer: mod_perl: rwrite returned -1 (fd=3, B_EOUT=8) [Sat Aug 10 12:50:05 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-server-dir_config-{DocumentRoot} is null on startup
How else can i find the server-document_root ? e.g: Apache-server_root_relative(htdocs); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails
Lupe Christoph wrote:
On Thursday, 2002-08-08 at 15:48:48 -0700, John E. Mendenhall wrote:
On Thu, 8 Aug 2002, Lupe Christoph wrote:
Since mod_perl seems to play tricks with bootstrap, I don't really
know how this comes into play.
I have done all you have asked. All output appears similar. Three files,
including Log.xs. Nine entries in httpd for XS_Apache__Log, as follows:
So, where to from here? Any ideas?
Well, this proves that Apache::Log *is* linked into the httpd binary.
The questions is why bootstrap is called at all. I'm afraid, I have
to hand this over to people who know the internal logic of mod_perl.
bootstrap *should* not be called, I think.
bootstrap() is always needed, because that's the function that
installs XSUBs into the corresponding Perl functions. The only
difference between dynamically and statically linked libraries is the
former is loading the object first and the latter have everything loaded
already. Here is the explanation by Tim Bunce:
http://groups.google.com/groups?q=bootstrap+statically+linked+perlhl=enlr=ie=UTF-8oe=UTF-8selm=Cyy1rA.Lnp%40ig.co.ukrnum=1
So as Tim says a statically linked library should already have its
::bootstrap function (which is boot_Apache__Log in your case).
mod_perl::boot() (lib/mod_perl.pm) is the place where it decides whether
to call DynaLoader's bootstrap() or the existing one:
sub boot {
my($class, $version) = @_;
no strict 'refs';
*{$class.'::dl_load_flags'} = DynaLoader-can('dl_load_flags');
if ($ENV{MOD_PERL}) {
(defined {$class.'::bootstrap'} ?
\{$class.'::bootstrap'} :
\DynaLoader::bootstrap)-
($class, $version);
}
}
In your case defined {$class.'::bootstrap'} should probably return a
ref to Apache::Log::bootstrap() (boot_Apache__Log) and then call it. For
some reason this doesn't happen and the DynaLoader's version is called,
which of course fails to load the object.
What do you get from running:
nm httpd | grep Apache__Log
there should be boot_Apache__Log there.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Verifying Which Handler
Jeff Crist wrote: Can someone send me an example of a test Perl script that will display which Perl handler Apache is using - Apache::Registry or PerlRun. We just migrated our website to a new server that was initially setup to run Appache::Registry but we don't have time to cleanup the code so I change the configuration (at least thought I did) to PerlRun. However we are seeing random behavior when running scripts on our website (the content of the page unexplainably changes sometimes) that seem to indicate variables are not being reset (ie, maybe we are still using the Apache::Registry handler) From the scripts you can use Carp::cluck() or for the fine tuning caller(). You can also do it globally, set in the startup file: $Apache::Registry::Debug = 1; $Apache::PerlRun::Debug = 1; and then the handlers will spit some debug info which should help. Another tipoff was when he had to go change all the exit commands in the Perl scripts to Apache::exit(); You don't need to do that for registry scripts. It's being done for you behind the scenes. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DProf not working
Randy Harmon wrote: I'm having trouble making Apache::DProf work. I've installed the module with CPAN, and I've added PerlModule Apache::DProf at the top of my httpd.conf. I've verified with 'httpd -l' that PerlChildInitHandler is OK - therefore, pushing a child-init handler should be OK, right? I've started the server, ran the web page I want to profile (that uses HTML::Mason), and then stopped the server. ServerRoot/dprof is not created, nor when I create it does it create dprof/$$ files as documented (likewise ServerRoot/logs/dprof/, as described elsewhere in the perldoc - not self-consistent). Also searched the entire system for tmon.out files (not found). Any suggestions? Permission problems? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Some wierd problem with mod_perl and Apache
Ged Haywood wrote: Hi there, On Fri, 2 Aug 2002 [EMAIL PROTECTED] wrote: sometimes.when I enter the values in the form and click on the change password button, the same screen comes back to me without the change actually happening. After doing this couple of times, I would actually succeed. Have you checked out the Guide? http://perl.apache.org/guide/debug.html BTW, while /guide is still working, the real url is now /docs/1.0/guide/, so I'd rather see people use that, because you should remember that we enter the era of co-existence of mod_perl 1.0 and 2.0, so /guide is not the *only* guide anymore. Moreover parts of the /guide that aren't specific to 1.0 have moved into /docs/general/. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Where's Apache::VarTest?
Oden Eriksson wrote: Hi. I'm using this as per documetation: Location /print_env2 SetHandler modperl PerlResponseHandler Apache::VarTest PerlSetVar VarTest VarTestValue /Location And are getting error 500 and this in the log: [Sat Aug 03 15:50:12 2002] [error] failed to resolve handler `Apache::VarTest' SERVER_SOFTWARE = Apache/2.0.40-dev MOD_PERL = mod_perl/1.99_05-dev You have to create that package. This was just an example of the configuration. You realize that we cannot supply a complete handler for each configuration example. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 1.99_05-dev (from CVS) + 1.27?
Oden Eriksson wrote: Hi there. I'm new to this list so excuse me if I brake written or unwritten rules... I'm the apache2 (from CVS) packager for Mandrake Linux. Is there some voodoo magic trick I could do to enable both mod_perl bransches on the same machine? As it is now both apache versions can coexist, but when I try to compile latest mod_perl it complains when it finds 1.27 Any hints would be appreciated. True. MP_INST_APACHE2=1 was supposed to become a default, but it didn't yet :( So I've adjusted the docs too early. I've put it back: http://perl.apache.org/docs/2.0/user/install/install.html#Create_the_build_environment You should be all set now. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: No error log, no database
Joachim Zobel wrote: At 09:03 02.08.2002 +0800, you wrote: Joachim Zobel wrote: Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? You've hit the 2GB limit. Yes, I know. I should have stated my question more clearly. But normally it should not be a critical error if the error log can no longer be written. In our case the database was not accessible (except for one handler that does a very simple SELECT). My question is: How did reaching the error logs 2Gb limit affect the database driver? Could be the DBD driver problem. You should probably ask on the relevant list and if you find an answer please share the reason with us. Seems to be an interesting problem. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl program
masilva3 wrote: Hi list, I converted an cgi for mod_perl and sometimes it execute ok, in the others, it show the code of cgi in browser. Anybody know what occur ? Did you use: Options +ExecCGI PerlSendHeader On __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 1.99_05-dev (from CVS) + 1.27?
Oden Eriksson wrote: On Fridayen den 2 August 2002 13.37, Stas Bekman wrote: Oden Eriksson wrote: Hi there. I'm new to this list so excuse me if I brake written or unwritten rules... I'm the apache2 (from CVS) packager for Mandrake Linux. Is there some voodoo magic trick I could do to enable both mod_perl bransches on the same machine? As it is now both apache versions can coexist, but when I try to compile latest mod_perl it complains when it finds 1.27 Any hints would be appreciated. True. MP_INST_APACHE2=1 was supposed to become a default, but it didn't yet :( So I've adjusted the docs too early. I've put it back: http://perl.apache.org/docs/2.0/user/install/install.html#Create_the_build_ environment You should be all set now. Thanks. It did build without any problems, but there's yet to tell if if conflicts on the file and file location level ;) It definitely doesn't if you use. PerlModule Apache2 as explained here: http://perl.apache.org/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Local file security (in 1.27)
[...] So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. You can't. The only solution is run a dedicated server for each user. Currently the pure Apache solution is to use suexec, which you cannot run under mod_perl. This is all covered at: http://perl.apache.org/docs/general/multiuser/multiuser.html this issue will be addressed in 2.0 with perchild Apache mpm which allows you to run different groups of servers/threads under different uids/gids. If I remember correctly this mpm is highly experimental at this point. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: No error log, no database
Joachim Zobel wrote: Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? You've hit the 2GB limit. First make sure that your OS/fs has a large file support. http://www.suse.de/~aj/linux_lfs.html Then re-build Apache (it should automatically add -D_LARGEFILE_SOURCE flag) and Perl with -Duselargefiles and finally rebuild mod_perl. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName add to /etc/hosts: 127.0.0.1 localhost.localdomain localhost [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So it starts normally. perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have installed perl into /usr/local/bin and /usr/bin comes earlier in the path so it picks 5.6.0. Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries though I can see that you will have dependencies problems. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
Stas Bekman wrote: Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
