Re: maybe off topic? Mod write config issue
George Valpak wrote: Sorry if this is offtopic here - I looked on http://httpd.apache.org/lists.html and didn't see any better lists for this question...if there is one, let me know and Iwill post it there George, why not to try a specially designated httpd-users support list: http://httpd.apache.org/lists.html#http-users Also see: http://httpd.apache.org/docs/mod/mod_rewrite.html http://httpd.apache.org/docs/misc/rewriteguide.html I want to redirect http://www.i18n.com/showcase/foo to http://showcase.i18n.com/foo I am running a dual apache config (mp1, current release for mp and apache) so Ialready have some rewrite rules: ServerName www.i18n.com RewriteEngine On RewriteLogLevel 0 RewriteRule ^/(.*.shtml)$ http://localhost:8000/$1 [proxy] RewriteRule ^/(.*.pl)$ http://localhost:8000/$1 [proxy] RewriteRule ^/(.*.inc)$ http://localhost:8000/$1 [proxy,last] NoCache * ProxyPassReverse / http://www.i18n.com/ snip This all works fine. The virtual host showcase.i18n.com is defined in the same httpd.conf file and it works. Now I want to add the new rewrite rule: RewriteLogLevel 3 RewriteLog "/usr/local/httpd_docs/logs/vslash_rewrite.log" RewriteRule ^/showcase/(.*)$ http://showcase.i18n.com/$1 [proxy,last] this is added to the top of the list of rules. some weird things happen: 1 - nothing get written to the log file, even at level 9. It is owned by root (created by touch). Is that ok? 2 - the rewrite doesn't happen and I get a 404 error; "The requested URL /showcase was not found on this server. Apache/1.3.27 Server at www.i18n.com Port 80" in my browser (Opera 6.05). Any ideas? It is live if you want to see it.. thanks, GV -- __ 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: An URL is not Invoking the Anticipated Perl Module [mp2]
Steve, please don't throw more than one question into the same email. It makes it really hard to followup. Please post each question separately. Steve D wrote: For the purpose of clarifying the issue, are you saying there is contention between the two handlers which are declared within the httpd.conf, as it has been setup in this case? That is, since a handler has been declared within by the directory section [/var/www/perl] and another for the location [/CurrDate], the two handlers are contenting against the one other? Therefore, in this case, although has been defined, the default handler is overriding the CurrDate name space[!?] Would someone please clarify. Eh? Did you: s/per-script/perl-script/ and tried again? From studying this further, I noticed I forgot to prefix the /CurrDate> section with a PerlModule directive. Consequently, the following line has been added to the perl.conf file. PerModule: MyApache::CurrDate However, now, with this addition, when starting the Apache the following exception is genereated: httpd failed. The error was: Starting httpd: [Fri Jan 10 12:11:15 2003] [error] Can't locate MyApache/CurrDate.pm in @INC (@INC contains: /var/www/perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at (eval 4) line 3. You'll notice from this message, the path does include '/var/www/perl' and the perl module which is being called is within the '/var/www/perl/MyApache/' directory. (For good measure it was also placed within '/var/www/perl' without a resolution to the run time exception.) There was a bug in older mod_perl versions, and you'd get the "Can't locate module" error when in fact, the module has failed to compile. Please try again with the cvs version. Incidentally, the format of the configuration file which is being used in this case has been adapted from the article "Introducting mod_perl Handlers". I've also been using "Getting Your Feet Wet with mod_perl". These resources can be respectfully found at http://perl.apache.org/docs/2.0/user/handlers/intro.html#What_are_Handlers_ and http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Handler_Modules I found these to be very helpful for a newcomer. Great. This later article was especially beneficial for it connected several fregmented thoughts together [at least in my own learning curve] into good concise working document. In my case, I found it helpful to get a perl script working [as a first measure] and then proceed to the use of a response handler. However, I did run across a problem with how the perl script name space was defined. The first example [in the article "Getting Your Feet Wet"] would not work when I used the syntax "PerlResponseHandler Modperl::Registry" nor "PerlResponseHandler Modperl::Registry::handler". Consequently, I changed the format to "PerlHandler ModPerl::Registry::handler" and then my test script was able to run. It should work with 'PerlResponseHandler Modperl::Registry'. What was the error message (please start a new thread on this one, don't continue here) Consequently, at this stage, a few questions remain. 1) Since, at least in this situation, I had to adapt the handler from being PerlResponseHandler to PerlHandler in order to get the perl scripting to work, does that also mean the same adaptation will be necessary in order to yield a result from a reponse handler for the CurrDate.pm module? 2) Once again, how do I instruct Apache to properly locate the CurrDate.pm file? [Stas, you may have already given me the answer to this latter question but more clarity is still needed.] 3) When I include the provision of the line "PerModule: MyApache::CurrDate" within the perl.conf file, Apache throws an exception and failed to start. s/PerModule:/PerlModule/ I don't know where did you take PerModule: from. __ 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: Shared memory 'copy-on-write' issue
Perrin Harkins wrote: Anton Permyakov wrote: reading http://perl.apache.org/docs/1.0/api/Apache/SizeLimit.html#Shared_Memory_Opti ons i am seeing that link about memory sharing by copy-on-write points to http://perl.apache.org/docs/1.0/guide/index.html and 'META: change link when site is live' stands after it. Site is alive, how knows where should this link point to? It does go the guide correctly, but a more specific link would be this: http://perl.apache.org/docs/1.0/guide/performance.html#Sharing_Memory I've fixed the link to point to the above URL. Thanks for pointing this out. __ 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: Problem combining mod_proxy, mod_rewrite & mod_perl
Jan P. Monsch wrote: G'day! I would like to combine mod_proxy, mod_rewrite and mod_perl on an Apache 2.0.43 for Windows with mod_perl 2.0. The Perl Version I use is ActiveState 5.6.1. Just by loading the module the server behaves differently. Instead seeing the the reverse proxied site I get following error in the browser: - Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/directx1/. Reason: Max-Forwards has reached zero - proxy loop? - It seems as if the rewrite rules are applied in a recursive loop. The rewrite.log does support this. Any ideas why this is happening and how can I get the config running again. [...] From your explanations and debug traces it looks like a bug in mod_proxy/mod_rewrite. You probably will get the same story with mod_cgi. If so, you need to report this bug to the httpd-dev 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: An URL is not Invoking the Anticipated Perl Module
Steve D wrote: The problem: Apache is generating File does not exist within its error.log and the message Object not found (The requested URL was not found. Error number 404.) while attempting to call a perl module from a brower. [...] SetHandler per-script PerlResponseHandler MyApache::CurrDate s/per-script/perl-script/ SetHandler can't verify at parsing time whether a handler really exists, it's really a string. So in your case the default handler was handling that Location. See: http://httpd.apache.org/docs-2.0/mod/core.html#sethandler If you still have questions regarding this (my guess is that it should work just fine) please ask. re: PerlResponseHandler vs PerlHandler, I've updated the docs to always use PerlResponseHandler. PerlHandler is just a backcompat thing to easy httpd.conf porting, so it works. p.s. please remember to mention in the subject [mp2] or at least in the body of the message, when talking about mod_perl 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: Passing CGI environment to subprograms
I don't see any reason why your `` invoked process doesn't see the CGI
env vars. For example:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
print qx{printenv |grep REMOTE_ADDR};
prints:
REMOTE_ADDR=127.0.0.1
So as you can see, it works. The problem is probably in your external
program, since the env vars are all there.
Or may be you are using PerlSetEnv Off?
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetupEnv
I've now located and tried the subprocess_env() in conjunction w/
spawn_proc_prog(). I just do a foreach on the ENV hash and stuff
the values
into subprocess_env(). That works (I have a test perl subprogram
that just
dumps the ENV), but now I am not able to get the output of the program.
I
pasted in the read_data() func from the example and I have a single
scalar
accepting the return value from spawn_proc_prog() per the example
and that
is supposed to give me the output filehandle.
Can you post a simple test program that reproduces the problem?
Also it'd be really useful if somebody could add a test suite for
Apache::Subprocess for (mod_perl 1.0). You can look at the
t/apr/subprocess test in mod_perl 2.0 to a basic example. It's a good
way to learn how to use Apache::Test, which is covered here:
http://perl.apache.org/docs/general/testing/testing.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: mod_perl pre-install questions
Richard wrote: I had a brand new server setup yesterday, which has SuExec installed. I read somewhere, I don't remember where, that mod_perl won't work with SuExec. Is that true? Or did I just think I read that somewhere? It's true. It's all explained here: http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to_run_mod_perl_enabled_Apache_as_suExec_ I see mod_perl in my RPM package installer, with the options of ignore dependancies and force install, what do you recommend? I'd recommend to install it manually, YMMV. This has been discussed many times here, check the archives if you are curious why. What do I need to do to install it? Should I use the RPM installer? Do I need to disable SuExec? If not, how will the user and group settings in httpd.conf work with mod_perl installed? Thank you for any advice you may have You will find all the information that you need here: http://perl.apache.org/docs/1.0/guide/ Please take some time to read things under this URL. __ 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: development techniques
Jim Martinez wrote: [...] At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp use instead of (or to complement) the web browser portion. Will the use of lwp instead of a browser improve my coding ability (either in terms of speed or just improving my perl coding)? Seems like I'd have to spend too much time with the lwp script (tell it to first request the page then choose option A and B then hit the "submit" button ... ) There are many benefits to using command line tools (which can be anything, but LWP::UserAgent and other packages in libwww-perl are a gift from god). Here are some of them off the top of my head: 1. You get the results as they come in (browsers tend to cash things). 2. You can program things: - make a sequence of request/response cycles based on a response - you can choose to display only certain bits of the response: e.g., show me only headers, only the body, only the size of the body, only certain keywords, etc. 3. You can easily reproduce sequences or specific inputs, especially when there is a sequence of request/response pairs to get to some state. 4. you can involve someone else in debugging the problem, without needing to come down (fly?) to his cubicle to explain how a certain anomaly is reached. So you can educate your users to create test scripts that reproduce the problem. 5. We (mod_perl programmers) very often use the single server mode (httpd -X) to test things. If you have a page with embedded images, it's going to take a while before you get the output, because you have only one server (this is documented in the guide). 6. Filling in forms. - You can prefill forms programmatically (saving you a lot of time and protecting from mistyping things) - You can provide inputs which with normal manual typing won't be possible (so you can test your program's behavior when a 10MB core file is submitted as a fname form's field). ... I guess there are many more things that could be added here, you get the idea. Apache::Test is one of the new tools that work with both versions of Apache (and mod_perl and other mod_*). If you are a 3rd party mod_perl module developer (CPAN or in-house) you definitely should use it to test your module. See: http://perl.apache.org/docs/general/testing/testing.html The only major drawback to command line tools I can see is when you need to observe the html as is (e.g. you can't use some logic/parser to verify correctness), here the browser is definitely more useful. So knowing when to use what technique is important. Both have an application. (I've also noticed that lwp-get sometimes have a significant delay because it tries to resolve IPs, even though the request is made to localhost. So many times I end up using just 'lynx --source') Is there some way to improve this cycle : edit code -> refresh browser -> possibly look at the error log -> edit code -> ... Or maybe you use another approach that's better? Inject mod_perl into your brain ;0) Seriously, I don't think that the core of this cycle can be any different, other than the 'refresh browser' part. Talking about the 'refresh browser' part. In one of the companies I've worked for, there was this girl who did some perl coding and who was very inefficient, because she didn't know she could do a refresh. Many times she needed to debug a form to which you get after a sequence of several forms, all requiring a lot of things to type in. So every time she would change a bit of code (1 sec), she would go to the first form and start filling in a form, then submit, get to the next form, fill it in, submit, and so on, till she gets to the stage she is debugging, see that her fix didn't work and start all again from scratch. On the way she would enter different data by mistake which would lead her to the wrong stage and she would need to start from scratch again. I'm sure that you all have seen someone in your office do that. Do them and your company a favor, explain to them that you can do a refresh to resubmit just the last stage. Or even better, show them the light by pointing them to libwww-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: OSCON ideas - MVC talk
Stas Bekman wrote: Since the submission deadline is one week that certainly would not happen. For some reason I thought the deadline was Jan 15th, I see that it's Feb 15th. Submit your proposals here: http://conferences.oreillynet.com/cs/os2003/create/e_sess __ 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: OSCON ideas - MVC talk
Nathan Torkington wrote: (yes, yes, we all want to see the "How mod_perl 2.0 was finished" but I'm not sure that's on the cards :-) Since the submission deadline is one week that certainly would not happen. Though an improved "mod_perl 2.0 by Example" tutorial is definitely a must for those who want to get familiar with most of the 2.0 new features. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] input filter
Steve wrote:
I'm having some trouble configuring an input filter.. I'm using Apache
2.0.43, mod_perl 1.99_08-dev and perl 5.8.0.
In httpd.conf, I just did this inside a
PerlInputFilterHandler myApache::Filters::filter_in
My code looks something like this:
package myApache::Filters;
#here I loaded different modules etc..
sub filter_in : FilterConnectionHandler{
my ($filter, $bb, $mode, $block, $readbytes) = @_
my $rv =$filter->next->get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv = APR::SUCCESS;
print STDERR "INPUT FILTER\n";
my $c = $filter->c
return Apache::OK;
}
Are you sure that this is the code that you run? How about adding a
semicolon after $filter->c
In your original post you've asked whether it's OK that the debug
warning is printed twice. Yes, that's OK. A filter is called one or more
times depending on how other filters output their data. You should get
the filter called once per bucket brigade.
This is pretty much just taken from the mod_perl filter documenation, so I'm
pretty sure the code is OK.
My problem is this:
From the time I hit refresh in my browser to the time the content
appears takes a very long time. The request completes eventually, it
just takes forever. As soon as I take the filter handler out of
httpd.conf it works perfectly
Is this a configuration issue? Anyone have any ideas as to why this
happens?
While it responds slowly, do you see the debug printouts coming out
slowly as well? Try to use the MyApache::FilterSnoop filter
http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter
and see where things are delayed.
Also try using a command line useragent: lynx --source, lwp-request,
etc. So you will see the output as it comes out.
______
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.c Not Compatible with Apache
Dale Lancaster wrote: Trying to narrow down a problem I am having with mod_perl::PerlRun on a stock RedHat 8.0 system, I have the following that simply doesn't work reliably under Apache 2.0.40 and mod_perl-1.99_05-3. The script runs fine for the first few refreshes and then I get the ominous error message: Error message: Not a CODE reference at /home/usa/cgi-bin/env.cgi line 7. Thanks for the report, Dale. Please try again with the current cvs, I've just committed a bug fix and a test that was reproducing it based on your report. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] Input Filter virus scan (more info)
Issac Goldstand wrote: [snip] . Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. If you need to store something in between the filter calls (filter may get the data in chunks, every time it's called it may only gets a chunk of data), the context is the way to store such data (e.g. partial bucket brigades, counters, etc.). Just give me some time and I'll commit the implementation and the updated doc with examples. I'm experiencing some problems with not seeing EOS, which prevents me from completing it. Stay tuned. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache instll ok, but....
Matt Lopresti wrote:
I am worried about the ENV{MOD_PERL} var not being set. What would cause
that not to get set? Is it a perms issue? In the conf file the User is
nobody and the Group is nobody. I am doing the entire make as root.
If you are seeing the mod_perl token in the server response headers or
the server startup:
http://perl.apache.org/docs/1.0/guide/install.html#Checking_the_error_log
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_telnet
but not in the script:
http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script
that means only one thing: You're calling the script under mod_cgi and
not mod_perl. Re-check again that you make the request to a location
configured to be run under Apache::Registry and also that you
don't override the mod_perl settings with ScriptAlias setting later in
httpd.conf.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache instll ok, but....
Matt Lopresti wrote: I am using RedHat 7.2, apache 1.3.27, mod_perl 1.27. Everything istalls correctly and make test is all a go. I then start the server, run a print env script and I dont get a MOD_PERL env and the gatway interface is CGI/1.1, I am however getting the server software env with mod_perl/1.27. I also added the the script in httpd.conf and took out the she bang line to perform another test, no go, internal server error. I do this process as root. What's the relevant section of your httpd.conf, where a is configured to run under mod_perl handler? You probably run scripts under mod_cgi. Did you look at: http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server http://perl.apache.org/docs/1.0/guide/getwet.html#A_Simple_Apache_Perl_Content_Handler Here is how I built mod_perl and apache: % tar xzvf apache_1.3.27.tar.gz % tar xzvf mod_perl-1.27.tar.gz % cd mod_perl-1.27 % perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 (I have also used the USE_DSO=1) % make && make test && make install % cd ../apache_1.3.27 % make installd I'm not sure what "installd" is, but the rest looks good. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] Input Filter virus scan (more info)
Chris Hoffmann wrote: [...] My need is to scan incoming data. If anyone has used "mod_vscan" on incoming data or know if the "All-in-One Filter" example located at; http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter can do this please contact me. I'm not familiar with mod_vscan and you don't specify how the scan filter works, but I see no reason why it shouldn't work, as long as all you need is an access to the request's headers. Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. Also all-in-one filter is an example of how to snoop on the data going through the filter, since you don't need the output filter, you can use a simpler only-input connection filter: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Output_Filters One more thing that needs to be figured out is how to make the filter abort the normal request processing if the virus is discovered and return a 40x response. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl.c Not Compatible with Apache
I've updated the README file to specify the minimum and maximum Apache versions required, the next mod_perl version's release will include it. As for your troubles, as Randy has suggested you probably have a bunch of various installs laying around and you've it all messed up. You don't need to install apr separately from Apache, just grab the latest cvs version of Apache and mod_perl, build them and you will be all set. See: http://perl.apache.org/docs/2.0/user/install/install.html#Getting_Bleeding_Edge_CVS_Sources http://perl.apache.org/docs/2.0/user/install/install.html#Configuring_and_Installing_Prerequisites http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_the_mod_perl_Source ... It should just work. To make sure that you aren't messing up with other installation on your system, go and clean those up first. __ 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: Need help with perl and ezmlm-web
Margo Poolak wrote: Hello! I have several problems that i dont know how to fix! 1) Im trying to make work the ezmlm-web but it gives me an error: [...] 2) Oki trying to install ezmlm: /home/listmg/pakid/Ezmlm-0.03 perl Makefile.PL make && make test make install Gives me an error: Can't use an undefined value as a HASH reference at /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 457 Look's like a problem with perl...stupid as im trying to install perl again(because i don't know what else could be done!) These two has nothing to do with mod_perl, please take them to one of the lists at http://lists.perl.org 3) Trying to install perl: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2/ make[1]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/docs/api/mod_perl-2.0' make[1]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs' make[2]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR' make[3]: Entering directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR/APR' gcc -c -I/home/listmg/pakid/mod_perl-1.99_07/src/modules/perl -I/home/listmg/pakid/mod_perl-1.99_07/xs -I/usr/local/apache2//include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm -DMOD_PERL -O2 -march=i386 -mcpu=i686 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fpic "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" APR.c Running Mkbootstrap for APR () chmod 644 APR.bs rm -f ../../../blib/arch/auto/APR/APR.so LD_RUN_PATH="/usr/lib" gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/auto/APR/APR.so -L/usr/local/apache2//lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/auto/APR/APR.so] Error 1 make[3]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR/APR' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/listmg/pakid/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 Now i don't know what those errors are? You need to use the latest cvs version or wait for the new version to be released, which should happen RSN. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution __ 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: perl's system() w/ apache under win2k
Terra Info wrote: [...] > application. If you would like to take output from that application then > you should write to STDOUT all text you want the perl application to see > as a return value from your system() call or `` (backticks) call. you probably meant qx(), as system doesn't return the sub-process' STDOUT, but only the exec status. __ 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: Question on possible effects of mod_perl on mod_cgi
OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them all? __ 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: perl's system() w/ apache under win2k
Terra Info wrote: I will write up a more publically palatable version of the below and post it for someone more intimately associated with the docs and development to merge into the tree. Great, thank you! Keep in mind that this is an issue not just for MP but also any CGI script or frankly any service that allows execution of external binaries that try to initialize and display GUI components. Although I have not tested it, I would imagine that this would be an issue on a Unix/linix variant as well as the design of the OS is similar to WinNT and up. Or the other way around if you want to follow the timeline correctly ;-}. I believe that Unix users are aware of this issue from the very first steps of using the system and therefore we hardly ever see this kind of questions on this list. Apparently permissions on winNT is something unexpected and new for those who are used to older win32 systems. Moreover, error_log usually tells what the exact problem is when the code is written properly to report errors (e.g., checking the return status of system()). My guess is that this should work on winNT too. If there are similar issues with MacOS X or other platforms, please send the info in, so we will add it to the docs. Though my guess is that MacOS X is based on FreeBSD and therefore all the normal Unix perms concepts apply as is. Correct me if I'm wrong. __ 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: Question on possible effects of mod_perl on mod_cgi
Terra Info wrote:
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess.
No prob. the comment was addressed to all subscribers.
Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
I meant the Apache::PerlRun from mod_perl 1.0. Obviously I wasn't trying
to suggest for you to run it as a pure handler ;)
Notice that ModPerl::PerlRun and others aren't exactly the same as their
1.0 counterparts. Due to the threading issues, currently 2.0's registry
aren't chdir()'ing to the scripts directory. That may change in the
future. But this may be unrelated to your problem.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
No.
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi?
The two has nothing to do with each other.
I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
I still don't understand you. When do you see the problem? When you run
the script under mod_cgi or mod_perl? I don't understand why do you keep
referring to mod_cgi.
And we are talking about Apache/mod_perl 2.0 here, right?
__
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: sed error in perl Makefile.pl
[...] When I run perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 \ APACHE_PREFIX=/home/user/httpd/apache I see this (note the sed error) (cd ../apache_1.3.27 && CC="gcc" CFLAGS=" -D_REENTRANT -DTHREADS_HAVE_PIDS -fno- strict-aliasing -I/usr/local/include" ./configure --activate-module=src/modules/ perl/libperl.a --disable-rule=EXPAT --prefix=/home/user/httpd/apache) CC="gcc" CFLAGS=" -D_REENTRANT -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include" ./configure --activate-module=src/modules/perl/libperl.a --disable-rule=EXPAT --prefix=/home/user/httpd/apache Configuring for Apache, Version 1.3.27 + using installation path layout: Apache , (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile sed: -e expression #44, char 46: Unknown option to 's' Creating Configuration.apaci in src First, you need to figure out where this error is coming from, sed isn't very helpful here. Since we are talking about ./configure errors, you need to modify apache-1.3/configure to start with: #!/bin/sh -x (notice the -x) now log the build process into a file a look what happens between two strings: Creating Makefile and Creating Configuration.apaci in src From what I see the error is in apache domain, but since I don't have this problem I could be wrong. ______ 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: perl's system() w/ apache under win2k
Terra Info wrote: Two things: 1) this is not the list for this question. 2) a probable answer anyhow-> If that's a real pitfall and it's doomed to be a recurrent question, can we please document this under win32/? Also, Randy, it seems that there is whole lot of win32 issues which apply to all mod_perl versions (per our faq discussion), so rather than duplicating them in docs/1.0/os/win32 and docs/2.0/os/win32, we should probably have an area for general win32 issues, e.g. docs/general/os/win32 and point to it from both 1.0 and 2.0. The issue is not file permissions (per se) or anything like that. It is the way WinNT and up is built. What you were doing in Win 98 worked because apps all ran in the same user space. Despite logging into a 98 machine you were really executing all programs as the default user and inside that users memory space. That happened to be, for the most part, shared by almost everything else running on the system. Hence when you ran a gui app from within apache the system would display the gui part of it on the screen. Instead of going into how WinNT and up is designed (go over to mikeysoft's site and you may see something there or maybe a MCSE book on Win2K will have the design philosophy in it) let's just skip to the possible fix. Check to see if the user you run apache under is allowed to "interact with the desktop". It should be in the services CPL applet under the entry for that service. Check that and restart the service. This may allow your app to run but I doubt it. Also, keep in mind this is not secure at all and your best bet is to see if the app you are running has a /quiet switch or something that will keep it from trying to paint any dialog boxes. If you wrote that app then you should put a hook into it that will allow that option (obviously adding the code to bypass init'n the gui code) and then execute it with that option. Tom Philip Fibiger wrote: Hello all, I've got a pretty simple perl script that used to run on a windows 98 machine running apache just fine. It would use system() to launch a windows app that has a graphical display to sync a ms-sql database to a mysql one. Anyway, it's been replaced by a new machine running win2k, and I'm having some problems. When I attempt to use system() to execute the program under win2k, the program appears to start (it shows up in the task list) but it never gets past that point. The same thing happens with any program that has a gui. I checked permissions, and I can log in w/ the same account apache uses, and I can execute the program just fine. Is there some permissions issue, or some alternate way of launching the program via perl that i'm not seeing? Thanks! Philip -- __ 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: Question on possible effects of mod_perl on mod_cgi
[When starting a new thread, please remember to create a new mail, rather than doing a reply to one of the threads. If you don't do that, your mail software attaches reference ids to the original thread and your post gets folded into the thread you've replied to. people may delete the whole thread without seeing your post if they weren't interested in this thread. it also has an ill effect on mail archives.] Terra Info wrote: I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. You mean, it has never worked under mod_perl 1.0? Can you test it with mod_perl 1.0? I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. You can turn the debugging on and see whether it gets cached. in ModPerl::RegistryCooker set: use constant DEBUG => 4; restart the server and watch error_log, compare the output of Registry with PerlRun. __ 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 make failed: cannot find -lapr
Randy Kobes wrote: On Tue, 31 Dec 2002, Steve Davis wrote: Your help will be very much appreciated to resolve the following issue. When attempting to make mod_perl.so, the make script 'almost' makes a touchdown but fails before getting to the finishing line. Now it is time get some help from a coach. Hopefully, with a little help, a touchdown will soon follow. Below, I present was appears to be the problem, but someone else will have to direct me to the next set of steps. [ .. ] This problem 'may' have to do with an issue of a change of naming conventions which were adapted by the apr apache group. Confer with Stas Bekman's post on Nov 26, 2002 with a title of "Problems compiling mod_perl 1.99_07 in RH 8.0". He provides a cvs patch; but, unfortunately, I'm not familiar with using that-as least-as of yet. (Look's like I might have learn this package real soon.) Are they any intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is correct, then currently, and according to the on-line instructions, the present tar.gz edition is not compatible to the latest edition of apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears as if, only the cvs repository maybe a valid for compiling. If my analysis is correct, and a new edition of the respective non-cvs files be acquired somehow. It might be easier to obtain the whole mod_perl 2.0 sources via cvs, rather than patching - this is described at http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution You likely have a cvs client already, so it's a matter of changing to an appropriate directory and doing % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co modperl-2.0 Or you can use the cvs snapshots tarballs, linked from the same URL Randy provided. 1.99_08 should be released RSN. I will make sure that it will state in the README file which Apache version it will work with. ______ 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: Modules Executed Twice
Hann, Brian wrote: Is anyone getting duplicates (i.e. 2 of the same email) of this thread? It just started happening today. I can't tell, since I never receive dups because of the procmail rule: :0 Wh: msgid.lock | formail -D 8192 saved/msgid.cache hint, hint ;) __ 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: Modules Executed Twice
David Wheeler wrote:
On Monday, December 30, 2002, at 02:45 PM, Stas Bekman wrote:
David Wheeler wrote:
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
It was supposed to be fixed in 1.25_01:
=item 1.25_01 - July 6, 2001
...
fix double-loading bug of Perl{Require,Module}s at startup time
Hrm, interesting. I wonder what the problem is?
Indeed, that's the workaround that was added originaly to cure the
above problem. Perhaps you can play with httpd_conf and see why it
doesn't work for you. I know that several people have reported that
they still had this problem since 1.26 was released.
I have a better workaround, now. I found that I could make the problem
go away by reversing the order in which the modules are loaded in
httpd.conf:
PerlModule TestSeen
PerlModule DoubleTest
Not exactly sure why that makes a difference, though.
Because $seen wasn't reset yet on reload.
Is httpd_conf() documented somewhere? I can't see what's supposed to be
passed to it.
It's an internal thing. You can add debug prints and Carp::cluck, to see
who calls it with what args. Hopefully someone will be able to track the
problem down and finally cure it for good.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Modules Executed Twice
David Wheeler wrote:
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
It was supposed to be fixed in 1.25_01:
=item 1.25_01 - July 6, 2001
...
fix double-loading bug of Perl{Require,Module}s at startup time
Here is the diff:
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- Apache/Apache.pm29 Jan 2001 16:07:08 - 1.62
+++ Apache/Apache.pm26 Apr 2001 05:30:45 - 1.63
@@ -30,7 +30,10 @@
sub httpd_conf {
shift;
-push @Apache::ReadConfig::PerlConfig,
+no strict 'refs';
+#use a symbolic reference so %Apache::ReadConfig::
+#is empty at compile time
+push @{"Apache::ReadConfig::PerlConfig"},
map "$_\n", @_;
}
[...]
sub test_seen {
return if $Apache::Server::Starting;
$seen++;
warn "Seen: $seen\n"
}
Indeed, that's the workaround that was added originaly to cure the above
problem. Perhaps you can play with httpd_conf and see why it doesn't
work for you. I know that several people have reported that they still
had this problem since 1.26 was 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: [mp2] APR::Socket::recv set read timeout ?
Michael wrote: ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? You have the APR::Socket object, so it should be possible. Though I see that apr_poll_ API is not glued. !MODULE=APR::Poll apr_poll_socket_add apr_poll_socket_clear apr_poll_data_get apr_poll_revents_get apr_poll_socket_mask apr_poll apr_poll_socket_remove apr_poll_data_set apr_poll_setup The ! mark in xs/maps/apr_functions.map disables the glueing of this API subset at the build time. sorry but I would like to ask how do I glue that? I tried the util/xs_check.pl in the modperl2 src dir, and it reports.. unable to glue 27 mapped functions: [...] it requires more than that, since the C types used by apr_pool functions aren't all having Perl typemap entries. Before we implement these let's ask Doug why he chose to skip APR::Poll in first place. Finally, as I've mention before, I would like to put this non http thing together with other http things on the same port 80. Is this possible? say, when this handler sees GET|POST|HEAD it forgets the request and let the Apache HTTP module process it in the normal way? This is a job of the PerlPreConnectionHandler, which is currently not implemented. Its purpose is to look at the first request of the new connection and dynamically assign a protocol handler for the current connection. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] APR::Socket::recv set read timeout ?
Michael wrote: Hi all. As suggested by Geoff and Stas, I am trying out modperl2.. Now I have some questions: i) with Apache::CommandServer (can be found at http://perl.apache.org/docs/2.0/user/overview/overview.html#toc_Protocol_Modules_with_mod_perl_2_0), I setup everything according to the guide..but > telnet localhost 8084 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Login: foo Password: foo ^] I must hit return once before the 'Login' prompt appears, and after a few tests I found that $socket->send() do not send the buffer to the client right away. Is this related to some configurable directives in httpd.conf or I did something wrong.. or just a feature? I'm trying to bring the overview and design notes docs up-to-date, Doug wrote them long time ago and things have changed a bit since then. The almost up-to-date version of the overview is here: http://perl.apache.org/docs/2.0/user/intro/overview.html How did you get to the old URL? Via google? For the latest docs on protocols see: http://perl.apache.org/docs/2.0/user/handlers/protocols.html If based on this doc you can bring the example from the overview up-to-date and send a patch here, I'll move it into the protocols doc, where it belongs. ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? You have the APR::Socket object, so it should be possible. Though I see that apr_poll_ API is not glued. !MODULE=APR::Poll apr_poll_socket_add apr_poll_socket_clear apr_poll_data_get apr_poll_revents_get apr_poll_socket_mask apr_poll apr_poll_socket_remove apr_poll_data_set apr_poll_setup The ! mark in xs/maps/apr_functions.map disables the glueing of this API subset at the build time. __ 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 2 and problems w/ ErrorDocument Directive
Terra Info wrote: Sounds good. Thanks for the help. I will patch my copy. Or just grab the latest cvs. Will all MP1 functionality be migrating over to MP2? Pretty much yes. In particular the PerlHandler Apache::Status functionality. Doug mentioned that most of its functionality works as-is. It needs some patching to work with the new registry. __ 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: Relative path problem
Andrzej Jan Taramina wrote: Stas: Are you talking about registry scripts or handlers? Because the former do change into the script's dir. CGI script using ModPerl::Registry and mp2. And that doesn't seem to workat least not using the HTML::Template module, which under mp2 does not find the requested template, which is located in the same directory as the script. It only finds it if I specify a fully qualified file/path. Any ideas why? That's why I repeatedly ask to mention the mod_perl version when reporting problems and not leave us guessing. Indeed, currently ModPerl::Registry and friends (mod_perl 2.0) don't chdir() to the script's dir, because under threads chdir() affects all threads. The original poster was talking about mod_perl 1.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: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: Thanks for the information. I did try removing Apache:DBI, but it still fails. OK Building everything from source will be time consuming. If I do that, I will probably just drop back to Apache 1.3 since I know it works. It's not time consuming at all, just follow the copy-n-paste recipe from the install page for 2.0. It'll help a lot if you try that first and verify that the bug hasn't been fixed already. __ 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: Relative path problem
Andrzej Jan Taramina wrote: Steve: In my index.pl, I call another perl file using a reletive path, like ../lib/work.pm. But I found this file cannot be found. Could someone tell me what is going on or give me some directions? Since your script is compiled under mod_perl ahead of time, and things like working directory are shared amongst all processes, you cannot assume that the relative path will be rooted from the script location directory under mp. You need to use fully qualified pathnames (config parameters that are passed into your script or read in are a good way to work around this issue). I heard rumours that MP2 might have a better solution by the time it goes final next year, but that was just a rumour at this stage. Maybe Stas can illuminate the matter more. The best solution is to use a project specific namespace, rather than ../../whatever.pm. It's all explained at: http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl and the sections that follow. __ 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 1.27] Problem regarding Perl*Handler and the HTTPrequestline
in Apache/mod_perl 2.0, you can write an input filter that _does_ allow you do parse the Request Line yourself. then again, you can write a protocol handler for any protocol you can dream up, so there's no reason to mess with HTTP :) Actually in 2.0 you can even implement this in a HeaderParser handler. Here is such an example: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler Here is an example of the input filter that modifies the request headers (as suggested by Geoff): http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters __ 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: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: I have searched the archives and various websites to find my problem and its associated resolution to no avail. I upgraded my working Apache 1.3 and mod_perl 1.x website using the PerlRun option of modperl to the RedHat 8.0 standard release with Apache/mod_perl 2.0 combo -- bad move it appears. ModPerl::Registry and friends are in beta now. I've ported the 1.0's version and made it a bit more modular via ModPerl::RegistryCooker. It's quite possible that I broke some of the functionalities while porting as you saw in the recent bug fix. The problem is that I couldn't verify whether the porting was 1:1 because there was no exhaustive test suite. For 2.0 we are hoping to have one. First, disable Apache::DBI. Does the problem persist? Second, please download the latest cvs versions of apache and mod_perl and try again. Does the problem persist? If it does, please send a short script that reproduces the problem, and hopefully a self-contained one, so it's not relying on mysql. In short, think of it this way: To solve the problem, I need to reproduce it first. So help me to accomplish that first. __ 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 2 and problems w/ ErrorDocument Directive
Terra Info wrote: PS: I forgot to let you know if it works on MP1. I do not have that installed on any machines so if someone out there on the list could check that out and post back I would appreciate it. Everything you need is below. Here is the fix, I've messed up this part while porting. I'll commit that fix soonish + a new test. Index: lib/ModPerl/RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.23 diff -u -r1.23 RegistryCooker.pm --- lib/ModPerl/RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23 +++ lib/ModPerl/RegistryCooker.pm 24 Dec 2002 01:44:52 - @@ -157,7 +157,8 @@ # handlers shouldn't set $r->status but return it my $old_status = $self->[REQ]->status; my $rc = $self->run; -my $new_status = $self->[REQ]->status($old_status); +my $new_status = $self->[STATUS]; +$self->[REQ]->status($old_status); return ($rc != Apache::OK) ? $rc : $new_status; } __ 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: Installed OK, but fails immediately on tests
Nigel Gilbert wrote:
I have run 'perl Makefile.PL' and 'make' without error, following the
mod_perl installation instructions, but when I run make test, the
server is shown as 'failing to start' and the test sequence aborts.
Further investigation shows that httpd has started successfully and the
problem is in t/TEST, which tries to do a 'simple_fetch' of
"/test.html" to demonstrate that the server is working, but this fails.
I think the reason that it fails is that any attempt to GET a page
using the server on port 8529 returns a 403 Forbidden code. A
colleague wondered whether this port had to be included in
/etc/services, but I can see no mention of this in the documentation.
Some context:
The server is running SunOS dusty 5.7 Generic sun4u sparc SUNW,Ultra-4
The server is also running a production version of Apache on port 80
(without mod_perl)
Perl is v5.8.0 built for sun4-solaris
I am attempting to install mod_perl-1.27
Here is the end of the transcript and what appears in the error_log
/opt/apache_1.3.20/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t &
httpd listening on port 8529
will write error_log to: t/logs/error_log
letting apache warm up...\c
done
/usr/bin/perl t/TEST 0
still waiting for server to warm up...not ok
server failed to start! (please examine t/logs/error_log) at t/TEST
line 95.
make: *** [run_tests] Error 29
{dusty:41} cat t/logs/error_log
[notice] Destruction->DESTROY called for $global_object
Subroutine fileparse_set_fstype redefined at
/usr/local/lib/perl5/5.8.0/File/Bas
ename.pm line 154.
Subroutine fileparse redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm li
ne 168.
Subroutine basename redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm lin
e 235.
Subroutine dirname redefined at
/usr/local/lib/perl5/5.8.0/File/Basename.pm line
248.
Constant subroutine CGI::XHTML_DTD redefined at
/usr/local/lib/perl5/5.8.0/const
ant.pm line 108.
[Mon Dec 23 21:44:18 2002] [warn] [notice] child_init for process
15493, report
any problems to [no address given]
{dusty:42}
what's wrong?
The error_log is not very helpfull here, may be it's just slow to start?
mod_perl 1.0's test suite waits too little before it gives up.
So try:
make start_httpd
t/TEST
make stop_httpd
you can manually test whether the server is running by fetching
localhost:8529, after 'make start_httpd'. If you are already doing that,
and as you say you get 403, check the perms.
And no, you don't need 8529 to be in /etc/services
Also, any reason for using 1.3.20 and not the latest version of Apache 1.3?
__
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: Database Pooling
Jean-Michel Hiver wrote: [...] * I _think_ that mod_perl 2 on Apache 2 might solve your problem since it's threaded (list, am I right here? I'm still working on mp1 for the most part) Eventually, yes. __ 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: [mp1] strange build problem with request_rec structure breaksAPI
[...]
I've tracked the difference down as to where it is in the structure: all
elements before and including "finfo" (type: struct stat) are in sync,
and all elements after and including "parsed_uri" (type: uri_components)
are 8 bytes off (extra 8 bytes in apache-mod_perl).
Either "finfo" is eight bytes longer in apache-mod_perl, or
apache-mod_perl has slipped some other element between "finfo" and
"parsed_uri".
Somehow apache-mod_perl and apache-vanilla have a different ideas of the
request_rec structure. Because I compile mod_ssl using apxs from
apache-vanilla it works with apace-vanilla but not apache-mod_perl.
it's the struct stat that's different, not the request_rec. And no,
mod_perl doesn't mangle the Apache datastructures.
Check this out:
/* sizeof.c */
#include
#include
int main()
{
printf("size of struct stat is: %d\n", sizeof(struct stat));
return 0;
}
# sizeof.pl
use Inline C;
foo();
__END__
__C__
int foo()
{
printf("size of struct stat is: %d\n", sizeof(struct stat));
return 0;
}
% gcc -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 88
% /home/stas/perl/5.6.0/bin/perl ./sizeof.pl
size of struct stat is: 96
tested with other perls on the same machine and the result is the same
(beware to delete _Inline before each try, since it won't recompile the
code if you use a different perl version, but the C code haven't changed)
So as you can see there is indeed 8 bytes difference. This is because
some of the members of the struct stat aren't of the same size when
compiled with perl and C. You may want to dig deeper and figure out the
one that's different. But first compare perl -V of the older perl build
under which things worked and the output of the newly built perl. I
suspect that the latter has the USE_LARGE_FILES enabled, whereas the
older doesn't. On my machine /usr/include/bits/stat.h uses a different
struct stat when large files are enabled.
Ah, indeed that seems to be the issue:
gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o sizeof sizeof.c ; ./sizeof
size of struct stat is: 96
here you go -D_FILE_OFFSET_BITS=64 is the one that causes the prob.
__
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: Install Problem: make test: modules/src.t
Mark Hawkes wrote: When I 'make test' I'm getting failures relating to modules/src.t [...] $ make test TEST_VERBOSE=1 <--snip--> dir=../src ok 2 main= not ok 3 module_magic_number = 0 not ok 4 httpd_version = not ok 5 -I../src -I../src/modules/perl ok 6 FAILED tests 3-5 Failed 3/6 tests, 50.00% okay <--snip--> Failed Test Status Wstat Total Fail Failed List of failed --- modules/src.t 63 50.00% 3-5 6 tests skipped. httpd terminated Failed 1/34 test scripts, 97.06% okay. 3/398 subtests failed, 99.25% okay. make: *** [run_tests] Error 29 what t/logs/error_log has to say about that? BTW, you can run just one test: % make start_httpd % t/TEST -v modules/src.t % make stop_httpd Please remember to follow the guidelines at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems to get the issues resolved much faster. -- __ 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 2 and problems w/ ErrorDocument Directive
Terra Info wrote: I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400&useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request" which makes no sense since the only log entry is "File does not exist: /var/www/terradev/docs/bad-link". When you use the 500.pl example below you get "Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request." despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. Looks like ModPerl::Registry is not handling correctly the return status , hence you get the run of the default handler as well. I'll look into it. But first, does it work properly with mod_perl 1.0? Finally please attach the script that fails, preferrably removing all but the very minimal code that allows to reproduce the problem. Thanks. And if you can a test to modperl-2.0/ModPerl-Registry/t that reproduces the problem, that would be even better. If you don't know Apache::Test, you can learn more about it at: http://perl.apache.org/docs/general/testing/testing.html and looking at the existing tests. To run the registry tests you need to cd to the ModPerl-Registry dir first and run 'make test'. If it seems like too much work, I'll take care of adding the test. But it'd be cool if people who encounter problems were able to submit tests with their reports. 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: install apache:asp in windows
Karthik wrote: Sir, I want to run sum asp programs using apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) What is it not clear? Could you please be more specific? What document are you talking about? Have you read: http://perl.apache.org/docs/1.0/os/win32/install.html If not, please do it first. 2. Is there any change in config file. RTFM: http://perl.apache.org/docs/1.0/os/win32/config.html 3. then how to run an asp file. RTFM again at: http://www.apache-asp.org/ Hope that now you have enough information to figure it out on your own. Please do ask further *specific* questions, if you have any, but after you have read the documents listed in this email. 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: modperl 2.0 problems with Apache::Cookie and related modules.
b. ash wrote: Hi, I am trying to configure a working apache2/modperl2 setup, unfortunately I can not seemt to get a critical module Apache::Cookie to install, I keep getting this error. Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 27. BEGIN failed--compilation aborted at Makefile.PL line 27. any ideas what might be going on here. A backcompat version of Apache::MyConfig is now available via Apache::compat in the mod_perl cvs. Though it won't solve the Apache::Cookie lib as reported by others. __ 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 troubles with RedHat 8.0 and Perl 5.8.0
iansmith wrote: On Thu, 19 Dec 2002, Stas Bekman wrote: Before you rebuild it, if you can get the segfault backtrace, that would be great. If you don't know how, check: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems Tried to do a "make test" in the mod_perl directory and got... Syntax error on line 3 of 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 Usually that happens when mod_perl hasn't been compiled yet. Are you sure you have followed the right order of build as explained at the install page? I did a manual run with gdb and got this when it crashed... Starting program: /var/www-1/source/apache_1.3.27/src/httpd -X [New Thread 8192 (LWP 5250)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 5250)] #0 0x400c8dfd in perl_header_parser () from /var/www-1/libexec/libperl.so #1 0x0806acdd in run_method () #2 0x0806add7 in ap_header_parse () #3 0x0807f198 in process_request_internal () #4 0x0807f552 in ap_process_request () #5 0x08076816 in child_main () #6 0x080769b6 in make_child () #7 0x08076b1d in startup_children () #8 0x0807714a in standalone_main () #9 0x08077968 in main () #10 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Any ideas? Thanks. Any chance you can recompile mod_perl with DEBUG enabled and get the trace again, so that we can see the arguments to the faulty call? -- __ 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 fails tests
[EMAIL PROTECTED] wrote: Yes, I was able to find CGI.pm. Do you know how I can fix my "problem" and get mod_perl installed and configured. I want to see the output of: find /usr/lib/perl5 -name "CGI.pm" Does it match one of the paths in @INC, as reported by the error message? Thanks- Rodney On Wed, 18 Dec 2002 16:13:19 +0800 Stas Bekman <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Actually, this is the correct httpd.conf which is autogenerated for the tests only Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 You mean, you have 5.8.0 but no CGI.pm? It should be there, because it's the part of the core. can you please do: find /usr/lib/perl5 -name "CGI.pm" Do you get it? __ 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: When perl is not quite fast enough
[apache.org keeps on timing out :( reposting 3rd time :(] Jeff AA wrote: >>-Original Message- >>From: Stas Bekman [mailto:[EMAIL PROTECTED]] >>Sent: 16 December 2002 13:22 >>To: [EMAIL PROTECTED] >>Subject: When perl is not quite fast enough >> >> >>While reading Mark Fowler excelent Perl Advent Calendar >>(http://www.perladvent.org/2002/) 6th entry: >>http://www.perladvent.org/2002/6th/, in the references >>section I've noticed a >>link to Nicolas Clark's notes from his YAPC::EU::2002 >>presentation, on how to >>make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ > > > Dear ModPerl Lister, > > I have two questions: > > 1) In this list, I have seen folks asking general Perlish questions >told to take their discussions elsewhere, along with the useless >recommendation that they browse lists.perl.org - I have done this >several times and joined a few of the lists, but only ever found >lists that were rather beginner. I have also lurked in some of the >groups.yahoo.com pearly lists without finding the right level. > >- can folks name any specific useful intermediate/advanced > Perl lists? i.e. Perl 4+ years in a commercial env I think the comp.lang.perl.moderated newsgroup (and if not accepted by the first, comp.lang.perl.misc) used to be the best resource to discuss general perl things. It's been a while since I've last used it, so I'm not sure if it's still a good resource. If others can confirm that it's still useful, I'll add that resource to: http://perl.apache.org/docs/offsite/other.html#Perl If you know of other good resources for general perl discussions which aren't already listed at lists.perl.org please let us know and we will update that section. It's probably a good idea to link from http://perl.apache.org/help/index.html to http://perl.apache.org/docs/offsite/other.html to help direct those seeking help on other topics in the vicinity of mod_perl. > 2) I have one common approach to speed improvement that is not >mentioned at all, to do with symbol table manipulation for >functions, that I would like to polish via a list discussion > >- is this list appropriate for a thread discussing Perlish >performance in general? I would guess that symbol table fiddles >might be risky in a mod_perlish env. It sounds good to me if it helps other mod_perl users to improve their code's performance. __ 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 troubles with RedHat 8.0 and Perl 5.8.0
iansmith wrote: I have compiled apache_1.3.27 with mod_perl-1.27 and got no errors. I have mod_perl as a shared module. I can run Apache without mod_perl fine, but when I activate the mod_perl module, it gives me this in error_log for every connection and fails to deliver any pages at all. [notice] child pid 27049 exit signal Segmentation fault (11) My perl is: This is perl, v5.8.0 built for i386-linux-thread-multi I looked over the mod_perl documentation, but can't seem to find anything that says what works and what does not. Do I need to compile a non-threaded version of Perl? Certainly Aaron's solution should work, but it'd be nice to figure out the cause of segfaults, because a threaded 5.8 perl works just fine with mod_perl for me (Mandrake 9.0). Though I built it by myself, I should try using the Perl supplied by Mandrake. Before you rebuild it, if you can get the segfault backtrace, that would be great. If you don't know how, check: 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: Release date for mod_perl 2.0
Ask Bjoern Hansen wrote: On 17 Dec 2002, Devin Heitmueller wrote: [...] I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. It will get stable faster if you choose to use it. :-) True, other than porting the remaining APIs, we need your bug reports so those ported can be fixed. Other than that perfork mpm is probably in a pretty good shape. Doug says that a few Covalent's clients use it in production for quite a while. Check whether you have all the APIs that you need available, and if so give it a stress test. You can use Apache::compat for those APIs that for some reason aren't there yet. See: http://perl.apache.org/docs/2.0/user/compat/compat.html p.s. when you test, please use the cvs mod_perl version. We plan to make a new beta release soon, since many things were fixed/added since the last release. ______ 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 fails tests
[EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Actually, this is the correct httpd.conf which is autogenerated for the tests only Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 You mean, you have 5.8.0 but no CGI.pm? It should be there, because it's the part of the core. can you please do: find /usr/lib/perl5 -name "CGI.pm" Do you get it? __ 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
What's On-topic and what's Off-topic on this list
I've the feeling that many subscribers are quite confused about the on-topic/off-topic "policy" on this list. In general, we try to keep threads mod_perl-centric. Because when the list starts to be dumping grounds for other "related" things, with a side effect of surging the list's traffic, those who were interested in pure mod_perl discussions, simply leave. And among those who leave we lose current or potential contributors. It's extremely hard to tell what's on-topic and what's not, because mod_perl programmers touch an enourmous amount of areas at their work. And sometimes this list is the only place where you can get an advice on certain topics, which happen to be related to mod_perl. But... my rule of thumb of deciding what's off-topic is very simple: think whether there is another good place to discuss a question in hand. May be an example will help to explain that approach. If somebody asks a beginners question on perl; usually how to write their code better, or why some code doesn't work, you have to agree that there are plenty other forums where this can be discussed (e.g. perlmonks.org). Now, when somebody asks about a proper way to generate unique hardly guessable session keys, that's a grey zone; on one side this is not a mod_perl specific question, on the other side it is, because under mod_perl you can take a benefit of process persistance and the way your keys are generated are a bit different. If you ask about performance improvement, this is kind of questions that are always welcome here, because I doubt there is any other forum where there are as many experts in performance as in the mod_perl community. But again, this is a grey zone. Obviously when something doesn't work under mod_perl, but works under mod_cgi, this is a very ontopic question. So, the next time you are about to ask a question which is not clearly on topic, first think whether you can get your answers elsewhere. If you don't where to ask, and you have browsed the help docs, ask about the right resource (just like Jeff did). If you have failed to find an answer elsewhere, after truly looking for it, I guess it's fine to ask here as a last resort, explaining your situation. But some people dare to post a statement: "I know that you can answer my question, so I'm asking it here". That's ugly. I feel that we need to add some sort of explanation of the on/off-topic posts issue to http://perl.apache.org/maillist/email-etiquette.html. Perhaps somebody who's writing is better than mine can contribute that. I feel that I brag too much around and people lose the point. So if somebody can write a clear, concise version of my bragging, or even better your own thoughts, please do that. Finally, it's everybody's list. If you don't like the way things are, change them. But please don't complain if you do nothing to help others (that's unrelated to your post, Jeff :). __ 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: windows and apache/mod_perl?
Paul Simon wrote: I started out with apache1.x. It didn't make sense using it, since apache2 was built to work with window's native environment, according to my understanding of the documentation. Plus, I read that apache1.x doesn't serve concurrent requests on windows. Doesn't that defeat a large part of what a web server (and mod_perl) is supposed to do? It does. But perl interpreters weren't thread-safe, so serialization is the only way to make it work at all. It is sort of a known fact that mod_perl 1.0 on win32 is not very useful in production. See: http://perl.apache.org/docs/1.0/guide/getwet.html#Installing_mod_perl_for_Windows http://perl.apache.org/docs/1.0/os/win32/multithread.html#Does_it_really_matter_ __ 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
We need help from mod_perl users with technical expertise in non-mainstreamOSs
Here at the list we have a rather sucky trend in the last year or so. Those folks who report problems that they have on platforms that aren't *BSD, Linux and Win32 mostly get unasnwered. Doug, who seems to know about everything, used to respond to those souls, but nowadays he's too busy with real work. We have plenty of folks who are kind enough to help others with Linux, BSD flavors and Win32. So we are all dandy on these platforms. So, my big request is to all the folks on the other platforms, whose users don't get their problems resolved here. If somebody posts a problem that happens on the platform that you use, please try to help that person, even if you don't consider yourself an expert. Many times a participation in the person's quest helps him to find the way on its own. What bugs most people is the silence. Also if you know somebody who may know the answer but not on the list, please take the initiative and try to kindly ask that person to help. And who knows may be he will enjoy to help and do that in the future as well. Please, stop lurking in the shades, but try to help when you see that nobody else does. Especially if you were helped here before. Remember that you have to give back, if everybody becomes a leech there will be no "blood" left. Also remember that helping others is addictive, you just need to start doing that. Also remember that we all do mistakes. And we aren't experts in all fields. So if your answer is incorrect, it's not a big problem, since surprisingly, someone, who ignores the original question in first place, immediately posts to correct you. Don't feel bad about that, since you've just learned something. On the opposite feel good about your follow-up, because you tried to help. So, if my rant wakes anybody out there on SunOS, can you please try to figure out what the problem is with Kenny Smith's report: http://mathforum.org/epigone/modperl/sleikrigroo There are many earlier questions that went unanswered, just go to http://mathforum.org/epigone/modperl and see which posts have no followup, and try to help. It's better late, then never. __ 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: Perl Cookbook modperl chapter
Gunther Birznieks wrote: Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. You are correct. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Ah, sorry, wrong copy-n-paste. i wanted to say connection. Thanks for correcting me! Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 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: Perl Cookbook modperl chapter
Hill, Ronald wrote: -Original Message- Grant McLean wrote: Nathan Torkington wrote: Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl Database persistence is an important topic but it's hard to say whether one directive ... PerlModule Apache::DBI ... constitutes a 'recipe' I agree that database persistence is an important topic and should be included in the perl Cookbook. However, Apache::DBI is not always the answer. Example: I currently have a need to use database persistence for an Ingres Database. So I installed the DBD::Ingres Module and attempted to use Apache::DBI. Needless to asy it did not work :-( After much searching/posting I got my answer. Henrik Tougaard wrote: (from comp.databases.ingres) I wouldn't bet on Apache::DBi working with DBD::Ingres! Reason: cached statementhandles are not implemented (currently) in DBD::Ingres and Apache::DBI uses them. (It's on my todo list, but not scheduled right now - i seem to have run out of tuits). I assume that the only way of getting permanent connections is to have another process hold them for you - but the hassle of accessing the connections would be so great, that it might be just as easy to avoid CGI entirely and go straight for mod_perl. OK, so now what? This type of situation could be discussed then talk about the Apache::DBI module. It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. ______ 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
When perl is not quite fast enough
While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ It's a very good read, and very relevant to us mod_perl users, who always want to have their code run faster. I especially liked it since it's very concise and gives you ideas of areas to explore. Certain things Nicolas talks about are already covered in detail in the mod_perl documentation. BTW, most other things mentioned in his notes are in the performance section of our upcoming mod_perl book (ora promises to get the book on the shelves in feb-mar next year). Me thinking to ask Nicolas to contribute these notes to our tutorial section (http://perl.apache.org/docs/tutorials/) and if possible to add some more meat to the original notes. If you remember our evil plan was to host at perl.apache.org interesting tutorials, relevant to mod_perl developers, but which are of interest to non-mod_perl developers too, thus bringing them to our site and hopefully getting them interested in mod_perl. Nicolas's doc, looks like a good bite ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Byterange requests
Nathan Byrd wrote: Hi all, I'm currently attempting to upgrade Apache::PAR to work with mod_perl 2, and one of the issues I am running into is with byterange requests: With mod_perl 1.x, it was possible (using Apache::File) to use byteranges with requests using $r->each_byterange and $r->set_byterange (a good example is in the mod_perl Developer's Cookbook, section 6.7, Byteserving and Range Requests.) It appears that with Apache2/mod_perl2 ap_each_byterange and ap_set_byterange are no longer available, replaced instead by a protocol filter in Apache. The only documentation for Apache I could find regarding this is at http://httpd.apache.org/docs-2.0/developer/filters.html - in that document, it explains that "Byterange: We have coded it to be inserted for all requests, and it is removed if not used." Does anyone know if the above statement includes mod_perl requests, or is there another workaround to send byterange responses with mod_perl modules? I suppose it could be implemented in the module itself (or as a patch to mod_perl, maybe in Apache::Response), but I don't want to attempt that if the byterange filter could be run anyway for a request. I've read the ap_byterange_filter() code (modules/http/http_protocol.c) and it has all the bytecode functionality in that function, plus a helper ap_set_byterange, which is private to that filter, so it can't be used by mod_perl. If I understand correctly the benefits of slicing the response in the response handler is good if it somehow saves memory/CPU cycles. Otherwise byterange_filter will do that work for you. It looks like implementing this functionality as a third party module is a good idea. Mostly likely you can simply rip off the code from ap_byterange_filter, making it more modular and then adding the XS to have the perl api. Or you can write the whole thing in perl. I think all the ingredients are readily available. __ 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::compat and german special chars
[perl.apache.org keeps on timing out once in a while :( reposting]
Tom Schindl wrote:
> Problems with Apache::compat
>
> CGI-PARAM-STRING: header=%DC%DC%DC%DC&body=%D6%D6%D6%D6&type=save_thread
>
> cut--
> [Sun Dec 08 21:39:09 2002] [error] [client 127.0.0.1] Character in "c"
> format wrapped at
>
/usr/bestsolution/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/Apache/compat.pm
line 217.
> , referer: http://localhost/discussion-board
> cut--
>
> When I copy the lines of interest into a small perl program and execute
> it, everything works perfectly. What's going wrong there?
>
> cut--
> map { s/%([0-9a-fA-F]{2})/pack("c",hex($1))/ge; $_; } split /[=&;]/,
> $string, -1
> cut--
Doug has fixed this already in the cvs version of mod_perl. Ditto for the
s/+/ / transform:
revision 1.71
date: 2002/11/23 22:35:06; author: dougm; state: Exp; lines: +2 -0
PR:
Obtained from:
Submitted by: Walery Studennikov <[EMAIL PROTECTED]>
Reviewed by: dougm
tr/+/ /; in parse_args compat method
revision 1.70
date: 2002/10/21 20:21:34; author: dougm; state: Exp; lines: +1 -1
PR:
Obtained from:
Submitted by: Walery Studennikov <[EMAIL PROTECTED]>
Reviewed by:dougm
fix parse_args compat method to support non-ascii characters
The problem was that the buggy code was doing pack("c", $num) which
expects a
number in range -128..127, whereas a fixed version does pack("C", $num),
which works with 0..255.
_
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: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
So, I have updated my src of apache, arp and mod_perl2 from cvs. Still the exact same result. I've messed up while adjusting for the new libapr's naming. it's fixed now in cvs. Though you shouldn't have had a problem in first place. it'd have just skipped linking to the apr libs and shouldn't have caused a problem. In any case. Please update your cvs version and try again. If you fail, please check that you build against the new versions that you have installed. that's make sure that you've deleted all the old installs, if they are no longer needed. If you still fail, post a complete report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_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: [mp2] make install quirk
Randy Kobes wrote:
On Sat, 14 Dec 2002, Stas Bekman wrote:
[looks my original reply didn't make it through, trying again]
Beau E. Cox wrote:
> Hi -
>
> I am posting this message informally - this is not
> critical (maybe not worth looking at); during
> the mp2 make install, mod_perl.so is copied to the
> apache2 tree (on my system) like this:
>
> cp mod_perl.so /usr/local/apache2/modules
>
> Now, if you haven't configured any apache2 modules
> (as I haven't for my test server), the subdirectory
> modules doesn't exist, so mod_perl.so is put into
> the apache2 tree as _file_ 'modules' under
> /usr/local/apache2. That's why I couldn't find it!
[...]
This is a known problem. I came up with this patch:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=103847596809386&w=2
But I'm afraid it's not portable and hence I couldn't commit it. Here is the
relevant snippet of the patch:
install:
+ test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
Any portability gurus know how to make this Makefile's line (the one with +)
portable? I think 'mkdir' is portable. What about 'test -d'?
On Win32, at least, 'test' isn't available. What about something
like the following:
perl -e "exit ! -d \"$(MODPERL_AP_LIBEXECDIR)\"" || mkdir $(...)
(the \" may be needed if the directory contains spaces, as Win32
might). And if one is worried about the system mkdir
availability, one can use
perl -MExtUtils::Command -e mkpath directory
randy++!
Please check that this work for you and I'll commit it (verified on linux).
You need to run a full build to check, unless you patch the Makefile manually.
I also see that my copy-n-paste has translated \t into spaces, so replace
those with tabs (between the + and $)
I've replaced \"\" with qq{} because shells and quotes, even escaped ones are
a big trouble. At least your suggestion didn't work for me. qq{} works just fine.
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.108
diff -u -r1.108 Build.pm
--- lib/Apache/Build.pm 28 Nov 2002 16:31:36 - 1.108
+++ lib/Apache/Build.pm 14 Dec 2002 08:43:32 -
@@ -1057,6 +1057,9 @@
lib: $(MODPERL_LIB)
install:
+ $(MODPERL_PERLPATH) -e "exit ! -d qq{$(MODPERL_AP_LIBEXECDIR)}" || \
+ $(MODPERL_PERLPATH) -MExtUtils::Command \
+ -e mkpath $(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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make install quirk
[looks my original reply didn't make it through, trying again] Beau E. Cox wrote: > Hi - > > I am posting this message informally - this is not > critical (maybe not worth looking at); during > the mp2 make install, mod_perl.so is copied to the > apache2 tree (on my system) like this: > > cp mod_perl.so /usr/local/apache2/modules > > Now, if you haven't configured any apache2 modules > (as I haven't for my test server), the subdirectory > modules doesn't exist, so mod_perl.so is put into > the apache2 tree as _file_ 'modules' under > /usr/local/apache2. That's why I couldn't find it! [...] This is a known problem. I came up with this patch: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=103847596809386&w=2 But I'm afraid it's not portable and hence I couldn't commit it. Here is the relevant snippet of the patch: install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) Any portability gurus know how to make this Makefile's line (the one with +) portable? I think 'mkdir' is portable. What about 'test -d'? __ 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: Stupid newbie question: where is "."?
Stephen Walton wrote: Please state [mp2] or something in the subject or at least in the message so we don't have to guess what version you are talking about. So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have "." set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that "." is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Yes, ModPerl::Registry does *not* chdir to the script's dir in 2.0. Here is why: http://perl.apache.org/docs/2.0/user/coding/coding.html#Threads_Coding_Issues_under_mod_perl Various workarounds were discussed, but none were implemented so far. By the time mod_perl 2.0 is released we should sort it out. For now use mod_perl 1.0 if that's an issue to you. Of course you are more than welcome to sort this problem out and submit a patch for 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: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
D. Fairbanks wrote: [...] LD_RUN_PATH="/usr/lib" gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an "Apache Head" check my installs, configs, versions, lib's & processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly. __ 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: Perl Cookbook modperl chapter
Paul Lindner wrote: Hi, I only speak for myself, but I am happy to see mod_perl covered in the Perl Cookbook. Why you ask? I see the inclusion of mod_perl helping increase the size of the mod_perl "pie". A rising tide lifts all boats. I second that. And just like Paul, I only speak for myself. We need more coverage/crossreference for mod_perl in places where people don't know/use mod_perl yet. If Nat's chapter gives plenty of crossreferences to the eagle book, cookbook and our new book, it's a goodness. I'd like to think of Nat's chapter as a teaser, to get the reader all excited about mod_perl. So you should a simple auth recipe and say, to learn about more complex implementation, see Chapter XXX Book YYY. Now if that reader is not really interested in getting to know mod_perl, chances are that he would never have bought Book YYY. But if Nat's chapter raised enough curiosity for that person to go and buy Book YYY, that's a goodness! Also please don't forget that the majority of mod_perl users use or at least start with *only* Apache::Registry and Apache::PerlRun, so just covering these two meaning to bring many more converts to mod_perl, by just letting them know that it takes a few minutes to make your perl/cgi scripts fly. Do they need more than that? Time will show. To me what's important is to have as many people as possible *know* about mod_perl and its strengths (and weaknesses I guess ;). Because if people don't know about mod_perl they obviously won't buy mod_perl books. The real problem with mod_perl books not selling as well as they could is the availability of the online documentation, which certainly doesn't cover the cool things in the cookbook and the eagle books, but is good enough for many purposes. So I was thinking to help the sales of our book when it hits the shelves in March 2003, we should pull the documentation site down for a few months and redirect everybody to http://modperlbook.org/ ;) (...for those who miss the smiley, I'm joking of course) __ 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: Can't find Apache::ModuleConfig
Tom Schindl wrote:
Maybe one could mark the things not implemented yet with a big comment
and remove things which will never implemented.
I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... .
I'm planning to revamp these old docs all at once.
Sounds good. Do you know how long this will take?
Hopefully, soonish.
May I ask more question?
1)
How can I read params sent via GET or POST?
In mod_perl-1.2x this was done via $r->param("bla"). Apache::RequestRec
does not provide such an method.
For now use CGI.pm, till Apache::Request gets ported to 2.0.
Apache::compat also provides methods to retrieve the params couldn't I
use them?
Sure you can. That's why there were added.
Although they're a little bit buggy (see my posting from
yesterday "Problems with Apache::compat and german special chars" ).
Yes, thanks. I didn't have a chance to look at it yet.
__
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: Can't find Apache::ModuleConfig
Tom Schindl wrote:
Thanks Stas.
The documentation on perl.apache.org pointed me in a wrong direction
(e.g. Apache::DBIPool
(http://perl.apache.org/docs/2.0/user/overview/overview.html#Apache__DBIPool))
--cut-
use strict;
use Apache::TIPool ();
use Apache::ModuleConfig ();
use DBI ();
--cut-
Maybe one could mark the things not implemented yet with a big comment
and remove things which will never implemented.
I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... .
I'm planning to revamp these old docs all at once.
May I ask more question?
1)
How can I read params sent via GET or POST?
In mod_perl-1.2x this was done via $r->param("bla"). Apache::RequestRec
does not provide such an method.
For now use CGI.pm, till Apache::Request gets ported to 2.0.
2)
Will Apache::TIPool ever implemented?
Not in the way it's described in the overview, but yes should be
implemented at some 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: [mp2]Kow do I find dovumention on...
There are many methods in 2.0, most directly glued from apache and apr methods. We want to re-use their docs as is, where possible. Meaning that we need a tool to extract these. Lyle and Gerald are working on this tool, please help them to get it out asap. See the threads on the docs-dev list: http://mathforum.org/epigone/modperl-docs-dev/fyhahmen http://mathforum.org/epigone/modperl-docs-dev/sayyarsnin Currently, your best friend to finding out what 2.0 is capable of doing is to grep/browse test handlers in t/, since most of the API is covered and exercised by these tests. __ 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: 0x444ba45b in prof_mark () from /usr/lib/perl5/5.6.1/i686-linux/auto/Devel/DProf/DProf.so
Ged Haywood wrote: Hi Stas, On Sun, 8 Dec 2002, Stas Bekman wrote: Ged Haywood wrote: [...] Try upgrading to Perl 5.7.2 at least. It worked for me. There are those who would recommend 5.8.0 minimum, but I'm not one. (Yet:). Eh? 5.8.0 is almost the same as 5.7.2, with mucho bugs fixed. I don't understand why do you suggest to install an unstable developers version, when there is a stable and better version out there. Simply that I've never upgraded to 5.8.0 myself and I've seen a few people with some troubles when they did. I've had no trouble at all with 5.7.2. If there are any troubles, they should be reported to p5p. Personally I didn't have any. Mandrake 8.0 uses 5.8.0 for its all tools and it works, so does the new RH. You may remember I had segfault problems with dprof and 5.7.1 which went away when I upgraded to 5.7.2 (it was you who suggested it:). At that time there was no 5.8.0 available. I see no reason why we should mislead readers, saying do not upgrade to 5.8.0, but to 5.7.2 instead. __ 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: All tests fail with Apache/2.0.43 (Unix) mod_perl/1.99_07-dev
Richard Curtis wrote: OK, after following the instructions requested by Stas Bekman, it still doesnt work... Below is a list of everything I have type. I dont claim to be a major expert or anything, so I have included all the commands in full to help catch if I missed something :) [...] I still can't reproduce this. Though your error_log shows a different problem. after adding "PerlOptions +Autoload" to make the httpd.conf read as follows : PerlOptions +Autoload LoadModule perl_module "/home/richard/modperl-2.0/src/modules/perl/mod_perl.so" PerlOptions should come *after* you load LoadModule [...] __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Warnings not showing in Apache log?
Andrzej Jan Taramina wrote: Later on you have reported that some problems went away. Does it include this one? I'm now seeing warningsbut they are flagged as [error] instead of [warning] in the Apache log. Any idea why? Does this happen when you run 'make test' as well? e.g. when you run: t/TEST -v api/aplog (see the corresponding t/response/TestAPI/aplog.pm) And when running under mp2, the lines in the log are not written using cr/lf on my windoze server like they should be. only lf (\n)? Unfortunately, I live in the country and my access is dial through Bell Sympatico...which is Bell Nexxia. Seems that your mail server bounces anything coming in from my ISP. Probably they are on the RBL. Not much I can do about that though, hence this response was posted to the list ;-( Hehe, your server bounces my emails as well ;) But that's a good thing for once, as this thread shouldn't leave 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: 0x444ba45b in prof_mark () from /usr/lib/perl5/5.6.1/i686-linux/auto/Devel/DProf/DProf.so
Ged Haywood wrote: [...] Try upgrading to Perl 5.7.2 at least. It worked for me. There are those who would recommend 5.8.0 minimum, but I'm not one. (Yet:). Eh? 5.8.0 is almost the same as 5.7.2, with mucho bugs fixed. I don't understand why do you suggest to install an unstable developers version, when there is a stable and better version out there. Whether you are running 5.7.2 or 5.8.0, do not compile with ithreads support, unless you need it, as it makes the interpreter slower. __ 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: Can't find Apache::ModuleConfig
Tom Schindl wrote: Hi, I've installed perl-5.8.0, Apache2.0.43 and mod_perl-1.99_07. Now I want to use Apache::ModuleConfig but I can't find it anywhere. I've installed everything like it was shown on perl.apache.org. What have I done wrong? Any ideas? When looking at my old perl-5.6.1 installation with apache-1.3.x and mod_perl-1.2x, I found the module. Where has it gone now, do I have to use another module instead? mod_perl 2.0 has a much improved configuration customization framework. You implement everything in perl now. There is no more Apache::ModuleConfig, but there is Apache::Module. Since the change is very significant, I don't think we will be able to provide a back compatibility layer for this one. I'm working on the documentation for the custom configuration, but I still didn't finish in as I encountered bugs, which aren't resolved yet. So, either wait a bit, till I finish the doc. Or if you are in hurry, look at t/response/TestDirective/perlloadmodule* for examples. __ 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 + mod_perl2 + dbd::oracle
Fabian Kreitner wrote:
[...]
$ENV{'ORACLE_HOME'} is set correctly right before the connection attempt
(it missing would result in an additional warning in the trace). Also,
the same script run from bash does successfully connect (same users, all
envs set in script).
read the info at the link I've posted in the prev reply. it doesn't work
this way anymore. explanations are there.
I did an additional installation with apache-1.3.27 & mod_perl-1 and in
this combination the test script does work =/
--
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2]: Problem running scripts with Apache::compat and PerlRun.
Bill Drury wrote: -8<-- Start Bug Report 8<-- 1. Problem Description: I've been getting a consistent error attempting to run scripts with PerlRun and the Apache::compat layer. It may just be a configuration error, but I'd appreciate anything you could tell me. Use ModPerl::PerlRun instead of Apache::PerlRun. The former is a special version written for 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: mod_perl + mod_rewrite
P. Zadikian wrote: Hello, Is there some way to set mod_rewrite rules in a section in the apache configuration? Just like any other httpd configuration, as explained here: http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl and in much more detail in the eagle and the cookbook. You can even write your own PerlTransHandler which will do the rewrite... __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] default values for PerlInterp directives?
Andrzej Jan Taramina wrote:
Does anyone know what the default values are (that is, if you don't specify
them) for the PerlInterpX directives? I can't find this info anywhere in the
docs...
PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests
PerlInterpScope
Thanks!
from scr/modules/perl/modperl_config.c:
void *modperl_config_srv_create(apr_pool_t *p, server_rec *s)
{
[...]
scfg->interp_scope = MP_INTERP_SCOPE_REQUEST;
/* XXX: determine reasonable defaults */
scfg->interp_pool_cfg->start = 3;
scfg->interp_pool_cfg->max_spare = 3;
scfg->interp_pool_cfg->min_spare = 3;
scfg->interp_pool_cfg->max = 5;
scfg->interp_pool_cfg->max_requests = 2000;
[...]
they aren't documented because it wasn't decide what the default should
be. But you are right, I'll document the current defaults and we will
adjust the documentation if there are any changes.
__
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 in Linux Mandrake
Carlos Kassab wrote: Hi: I installed Apache in Linux Mandrake, Mod perl seems to be installed according the rpm. Now i installed the ASP module but i get the message that the Module Apache:: ASP does not exist. Somebody would knows how to solve this? Thank you in advance for your help Do yourself a favor and build everything by yourself. When you do that, you don't need to guess why this or that doesn't seem to be what it's likely to be. ... If you persist and want to use a prepackaged things, that's cool too, but... you have to be more helpful if you want help: What Apache version do you have installed? What mod_perl version you *seem* to have installed? Can you use mod_perl as it's installed? What perl version do you have installed? When you've installed Apache::ASP (I assume via CPAN.pm) which Perl installation did it go to? Was mod_perl compiled with the same Perl, you've installed Apache::ASP with? There are so many different versions and flavors of everything. If you don't tell us *all* the details, we can't guess what you have. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2]Cookies?
Beau E. Cox wrote: Hi Randy - Sorry, I should have been more explicit. I am trying to use Apache::Cookie. AFAIK, Apache::Cookie won't work under mp2, because Apache::Request wasn't ported yet. Trying using CGI::Cookie for now, as it has the same API and implemented in pure perl. Notice that this is not an issue of Apache::compat, because Apache::Cookie is implemented in XS. What's with the Apache/test.pm (small 't')? I added use Apache2; (to add apache2 stuff to the @INC) - same results with or without it. Searched for Apache/_small t _est.pm - not found. That's an older testing package coming from mp1. It won't work with mp2. __ 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: Online Tonight
David Wheeler wrote: On Thursday, December 5, 2002, at 12:46 AM, Stas Bekman wrote: Care to share with us how was the show? And how much mod_perl talk was in it? I certainly mentioned how important Perl, mod_perl, Apache, Mason, and PostgreSQL are to the success of the project. The show went pretty well (and a few people who listened agree), but I think I got only around 10-12 minutes time talking in the whole hour! Such is the nature of commercial radio, I guess. They plan to have me on again, though -- perhaps live from the floor of Macworld Expo; we'll see. I'll certainly keep pumping the above-mentioned software, though -- it's all crucial! Great! Unfortunately I wasn't able to listen to the broadcast due to some sw issues, the browser just hanged there... If the show was of interest to other mod_perl users, is there an mp3 that we can link to from perl.apache.org? The show is online here: http://www.onlinetonight.net/archives/001100.html I was on in the second hour (photo to appear later today), and you can listen to it via a WMA file. They were kind enough to give me MP3s of the hour, and once I get them edited, I'll post them somewhere. Probably on bricolage.cc. I think it might be of interest to others, although I suspect that the edited version might be of most interest, once I can provide it. When you get the mp3, please send us a link, so we can link to it from perl.apache.org! 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: apache2 + mod_perl2 + dbd::oracle
Marcin Kasperski wrote: Fabian Kreitner <[EMAIL PROTECTED]> writes: Hello all, I have problems connecting to an oracle db using mod_perl but cant figure out where the problem is. The script works fine from the bash but not through perl::registry. The script only sets the environment variables and then tries a connect. (...) !! ERROR: 12154 'Error while trying to retrieve text for error ORA-12154 (DBD ERROR: OCIServerAttach)' Either you removed message files from your Oracle installation (not very likely) or you failed to set ORACLE_HOME so that OCI libraries below DBD::Oracle notice this variable. Double check the way you set your environment. And if that's the case, watch the new culprit under 2.0: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Entries_Set_by_Perl_Code __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] doing PerlSetVar from a startup handler
Beau E. Cox wrote:
Hi -
I'm trying to get mason running under mod_perl 2,
but this is a mod_perl question. I need to have the
following set:
PerlSetVar MasonArgsMethod CGI
When I configure mason in httpd.conf w/o a startup handler,
everything is fine.
What do you mean by the "startup handler"? a startup file?
With a handler, even with the PerlSetVar before the
'require' for the handler in the conf file, CGI is NOT
set.
I'm not familiar with mason, so please provide a short example that
reproduces the problem (w/o mason if possible).
Question: how can I PerlSetVar from the perl code in the
handler? I see:
push @{ $Location{"/"}->{PerlSetVar} }, [ foo => 'bar' ];
in the mp1 docs - looks good - but where do I get the %Location
hash? Can't seem to find that.
In 1.0 outside you would go as:
package Apache::ReadConfig;
push @{ $Location{"/"}->{PerlSetVar} }, [ foo => 'bar' ];
but 2.0's support Perl sections support is incomplete as far as I know.
Doug implemented the base and Philippe was working on the rest, but he
is on vacation now, so expect him to complete it once he comes back (in
January I believe)
__
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: Online Tonight
David Wheeler wrote: All, I will be the featured guest for an hour on the nationally syndicated talk radio show "Online Tonight" this evening at 8 pm PST (11 pm EST). Host David Lawrence and I be discussing Bricolage, its history, and content management in general. This is my first time on the radio, so it should be interesting. The show is a light, humor-oriented tech talk show, and is, along with Online Today, "the most listened to high-tech-oriented talk show on the air today," according to CNET Radio. The show's web site: http://www.online-tonight.com/ To listen in via streaming media: http://www.cnet.com/broadband/0-7227152.html Hi David, Care to share with us how was the show? And how much mod_perl talk was in it? Unfortunately I wasn't able to listen to the broadcast due to some sw issues, the browser just hanged there... If the show was of interest to other mod_perl users, is there an mp3 that we can link to from 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: [mp2] LogHandler configuration problems
Beau E. Cox wrote: Hi Stas - ...look at the error log... For the first test, which my logger reported: ::1 [Wed Dec 4 19:58:13 2002] "/" 404 266 ::1 [Wed Dec 4 19:58:24 2002] "/index.html" 403 280 ::1 [Wed Dec 4 19:58:45 2002] "/perl/rocks.html" 200 29 The error log reported: [Wed Dec 04 19:58:13 2002] [error] [client ::1] Attempt to serve directory: /srv/www/htdocs/ [Wed Dec 04 19:58:24 2002] [error] file permissions deny server execution/srv/www/htdocs/index.html I don't see that these error_log entries "...revealed the problem right away, from the first test..." To me, newbie that I am, they give abount the same information that my logger gave... bummer ;) I was sure that registry will complain in the logs, but forgot that Apache got on its way. So you were right and I wrong ;) Glad that you've figured it out. OK, I'll relax. The secret is to read and test more before crying wolf you'd be surprised how many times i've cried wolf myself... even did that, this morning ;) __ 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::Hook
Yuriy Syrota wrote: Hello, folks. Could anybody explain me how can I specify apache hooks in the module? In the other words, I want to do exactly what described here: http://perl.apache.org/~dougm/modperl_2.0.html#new%20hook%20scheme Although it's unclear for me what I should use() to use Apache::Hook. It's not (fully) implemented yet. Patches are welcome. That doc is a bit dated and certaint things have changed. Please refer to the mostly up to date docs at perl.apache.org. There are two docs that are outdated a bit there and require cleanup: http://perl.apache.org/docs/2.0/user/overview/overview.html http://perl.apache.org/docs/2.0/user/design/design.html so I suggest to not look at them at this time, as the material in them is mostly covered in the rest of the 2.0 docs. That reminds me that I need to add the 'what's new chapter from my tutorial. will do that shortly. p.s. Yuriy, I'm working on the custom conf directives doc now and hopefully should be done soon, so you can get going with the axkit porting. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] LogHandler configuration problems
Beau E. Cox wrote: Well Stas, you asked for it... :) [...] #---mod_perl 2.0 rocks test- Alias /perl/ /srv/www/conf/perl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI #---MyApache-FileLogger- SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlLogHandler MyApache::FileLogger Options +ExecCGI As you have figured out by trial and error, if you wanted the logger to work for everything you just needed to add: > > PerlLogHandler MyApache::FileLogger > what you originally did, is assigned ModPerl::Registry to serve everything on the server, but fed it with html and images, forgetting that it requires a Perl diet. Since you've repeated many times that you are a newbie, I'll forgive you ;) But if you weren't a newbie and you didn't remember to check the error_log file, I'd say: "shame on you" :) As the latter would have revealed the problem right away, from the first test. Notice that my example configuration is correct since it demonstrates the use of a logger for a particular sub-section of the site that *happens* to be served by the ModPerl::Registry handler. Perhaps that example needs some extra notes to avoid this kind of confusion in the future. I'll add a note. __ 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: DSO/Tru64 (was Re: References for modperl usage in financialinstitutions?)
Marcin Kasperski wrote: PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this list. I am using Tru64 - and if you have any suggestions of what to try, I will do it... I wish it was that simple :( You really have to know the peculiarities of the system to know why the behavior is different. -- __ 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: References for modperl usage in financial institutions?
Marcin Kasperski wrote: Yes, please post your success stories here (...) I am more than happy being now able to add the new nice reference. Please, patch my English where necessary... Thanks a lot, Marcin. I've added your story (it'll appear online within 6 hours). Chip, I've added www.redhat.com as well! Thank you too! PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this 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: [mp2] Documentation/LogHandler question
Beau E. Cox wrote: Hi - In: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler, the PerlLogHandler documentation, the configuration file sample setup is given as: SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlLogHandler MyApache::LogPerUser Options +ExecCGI Now I wrote a simple log handler and had no end of problems (will detail upon request) with this configuration. Please do so. Since I want to intercept _every_ access to my server, I ended up with: PerlLogHandler MyApache::Logger and then shortened it to: PerlLogHandler MyApache::Logger where MyApache::Logger is the name of my logging perl script. I works perfectly. Do you really need all the other 'stuff'? Since this is a log handler why would you need the ResponseHandler, etc.? Of course you don't need it. I've added it so the example will be complete (i.e. you need some kind of response handler, or I guess you could rely on the default handler) As you have gathered, this is my very first mod_perl handler :) You probably want to get hold of the eagle and the R&W mod_perl books. Though covering mod_perl 1.0, most of the information you learn applies to 2.0 as well. Think of 2.0 as 1.0 on mushrooms. For the books info see: http://perl.apache.org/docs/offsite/books.html#Learn_mod_perl PS: Hey Mr. 100%, mod_perl 2.0 rocks! ;) p.s. Geoff, we need a short acronym for your book so it's easy to refer to it, (a new eagle), I've called it R&W (Red&White), if you have a better idea, please suggest. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] How do I port modules using Apache::SIG?
The changes are documented here: http://perl.apache.org/docs/2.0/user/compat/compat.html I haven't put it into the developer's guide, but the user's guide. Because the user's guide is for all people who write mod_perl code. The developer's guide is for those who tinker with the core. I'll put an xref to the above doc to avoid this problem in the fuure. While adding the xrefs I've realized that what I've said is not strictly correct, as http://perl.apache.org/docs/2.0/devel/porting/porting.html includes useful notes for code writers as well. In any case I've added xrefs to each other, so there shouldn't be a problem to find all the relevant info now. The online docs will be updated by the cron within 6 hours. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] How do I port modules using Apache::SIG?
Clare, Bruce W wrote:
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl
2.0 running on Windows 2000, but the application was written for Apache/mp
1.x, so it uses Apache::SIG (and possibly other) modules that are no longer
in mod_perl.
The mod_perl developer documentation for porting from 1.x to 2.x doesn't
really cover the missing modules, other than to say you can use
Apache::compat to allow use of deprecated methods. This doesn't do the job
here, which makes sense because the SIG module isn't even installed on my
system. Is there any resource that discusses the changes between mod_perl
1.x and 2.x in more detail than the current developer document? The key
point here is what has been deprecated/removed/rearchitected in mod_perl
2.x? and how do I replace it?
The changes are documented here:
http://perl.apache.org/docs/2.0/user/compat/compat.html
I haven't put it into the developer's guide, but the user's guide.
Because the user's guide is for all people who write mod_perl code. The
developer's guide is for those who tinker with the core. I'll put an
xref to the above doc to avoid this problem in the fuure.
Apache::compat is certainly incomplete, as you have just figured out,
and that doc is synced with Apache::compat. But we are getting there.
Please keep reporting those missing things.
I'm not sure if mod_perl 2.0 will ever need this module (especially with
perl 5.8.0 which has safe signals). So here is a stub that let's your
1.0 code run as is. It'll be in CVS soonish.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.71
diff -u -r1.71 compat.pm
--- lib/Apache/compat.pm23 Nov 2002 22:35:06 - 1.71
+++ lib/Apache/compat.pm4 Dec 2002 02:23:01 -
@@ -509,5 +509,14 @@
APR::Table::make($r->pool, $nelts);
}
+package Apache::SIG;
+
+use Apache::Const -compile => 'DECLINED';
+
+sub handler {
+# don't set the SIGPIPE
+return Apache::DECLINED;
+}
+
1;
__END__
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [MP2] Handler feauters in a filter?
Issac Goldstand wrote:
Implemented it in C:
if (f->r->status==HTTP_NOT_FOUND) // If this is so, we need to revamp the
request_rec
{
f->r->status=HTTP_OK; // Spoof HTTP_OK
f->r->status_line="200 OK";
APR_BRIGADE_INSERT_TAIL(ctx->bb,apr_bucket_eos_create(f->c->bucket_alloc));
// Add an EOS to the new bb
ap_pass_brigade(f->next,ctx->bb); // and pass the new bb to the next
filter
return APR_SUCCESS;
}
Not sure how to translate that to mod_perl's API (the first half is easy and
understandable in C, I think, though...)
It works exactly the same, just add $ before 'f' :) Though you don't say
where in the filter chain do you insert it and how do you configure it
(i.e. what filter type).
This was *my* solution - I'm not sure if it's the "best way to do it"...
I'm sure that as I delve deeper into Apache 2, I'll find better solutions...
Hence my suggestion to ask at the httpd-dev 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: [mp2] the make test problem saga continues...
C. same Apache/Const.pm not found:
Can't locate Apache/Const.pm in @INC (@INC contains:
[...]
D. same tests failed:
apache/subprocessFAILED tests 1-4
Failed 4/4 tests, 0.00% okay
OK, here is the patch that will 100% :) fix these two problems (apply
manually or just use the cvs version):
Index: Apache-Test/lib/Apache/TestConfigPerl.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigPerl.pm,v
retrieving revision 1.53
diff -u -r1.53 TestConfigPerl.pm
--- Apache-Test/lib/Apache/TestConfigPerl.pm1 Jul 2002 07:57:15
- 1.53
+++ Apache-Test/lib/Apache/TestConfigPerl.pm3 Dec 2002 15:27:17 -
@@ -282,6 +282,13 @@
sub configure_pm_tests {
my $self = shift;
+# since server wasn't started yet, the modules in blib under
+# Apache2 can't be seen. So we must load Apache2.pm, without which
+# run_apache_test_config might fail to require modules
+if ($mod_perl::VERSION > 1.99) {
+require Apache2;
+}
+
for my $subdir (qw(Response Protocol Hooks Filter)) {
my $dir = catfile $self->{vars}->{t_dir}, lc $subdir;
next unless -d $dir;
--
I hope that now you get a clean make test.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0]make test problems
My ignorance is showing (20 yrs+ with M$ systems, only 1 1/2 yrs with Linux) but I did notice that mod_perl untared to beau:mysql? Where did that come from? umask? man umask only gives me (2) - programmers reference. Is there some setup parameter I should set? I've read my SuSE admin guide and can't find anything revelent. Please point me somewhere... :) No need for excuses :) as you saw in my followup it wasn't a umask issue. (Though 'perldoc -f umask' has a good explanation of umask.) Of course, I'm doing everthing logged in as root (it's my network after all, and if you can't be King of your own network...) I've never seen tar carry owner:group + perms thru an untar...they usually come out the other end root:root. Been there, done that. But now I work under my own user and rarely need to run 'su'. But that discussion belongs to a different list... We are probably going to change Apache::Test to not let you run the test suite as root (the real problem is that Apache 2.0 will refuse to start if httpd.conf file says: "User root"), instead of trying to guess your 'other' username. As you can see this help causes more troubles than it helps. It's some of your magic, isn't it Stas? If it has anything to do with magic always remember to s/Stas/Doug/gi __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [MP2] Handler feauters in a filter?
Issac Goldstand wrote: I'm writing a filter in which two lines of data are to be appended to the content going back. However, I'd like to test for a 404, and if found set the response to 200. Can this be done from the output filters? Or am I going to have to do something more complex with a handler? Haven't tried this yet, but you can either write a connection filter which rewrites the headers if they were sent already, or insert your filter just before the one that generates the headers. Since you want to add something to the end, the former case is probably the best. I suggest that you ask for the best way at the httpd-dev list, as it's a pretty generic httpd topic and that list has real filter experts. Then once you figure out from them what's the best way to go (and share with us :) implementing it in perl is a piece of cake. The big problem is mod_proxy (or any other module, for that matter) - it's not as simple as checking the file on disk - the content could be coming from a proxy or from another content-handler. Any ideas? Issac -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0]make test problems
Also, can you please try to do the testing with the cvs version of mod_perl 2.0? Since chances are that some things were fixed since last release (and possibly new bugs added :) See: http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution (though use only the mod_perl cvs, not the httpd) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0]make test problems
There are two problems: C. Apache/Const not found: Can't locate Apache/Const.pm in @INC (@INC contains: Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/lib /usr/local/addons/mod_perl-1.99_07/blib/lib /usr/local/addons/mod_perl-1.99_07/blib/arch /usr/local/addons/mod_perl-1.99_07/t/../Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/t/../lib /usr/local/addons/mod_perl-1.99_07/t/../../lib /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at /usr/local/addons/mod_perl-1.99_07/t/response/TestApache/subprocess.pm line 12. BEGIN failed--compilation aborted at /usr/local/addons/mod_perl-1.99_07/t/response/TestApache/subprocess.pm line 12. Here is where Const.pm (actually several vertsions of them) is in the mod_perl tree (looks like the @INC should have a --/Apache2/Apache-- in it) (all below are from /usr/local/addons/mod_perl-1.99_07/): blib/lib/Apache2/APR: -r--r--r--1 root root 160 Apr 11 2001 Const.pm blib/lib/Apache2/Apache: -r--r--r--1 root root 324 Aug 28 16:28 Const.pm blib/lib/Apache2/ModPerl: -r--r--r--1 root root 743 Sep 5 07:07 Const.pm xs/APR/Const: -rw-r--r--1 beau mysql 160 Apr 11 2001 Const.pm xs/Apache/Const: -rw-r--r--1 beau mysql 324 Aug 28 16:28 Const.pm xs/ModPerl/Const: -rw-r--r--1 beau mysql 743 Sep 5 07:07 Const.pm It wants /usr/local/addons/mod_perl-1.99_07/blib/lib/Apache2/Apache/Const.pm but for some reason blib/lib/Apache2 is not in the path. modperl_extra.pl loads Apache2, so @INC should be adjusted. What happens if you run this test standalone, like so: t/TEST apache/subprocess even better in a verbose mode: t/TEST -v apache/subprocess (watch the error_log) The second problem manifestates in the error_log file: [Mon Dec 02 05:08:38 2002] [error] [client 127.0.0.1] mkdir /usr/local/addons/mod_perl-1.99_07/t/htdocs/perlio: Permission denied at /usr/local/addons/mod_perl-1.99_07/Apache-Test/lib/Apache/TestUtil.pm line 128 it tries to create a new dir 'perlio' in the dir 'htdocs' and fails. Apparently your umask is set to some value that when untarring the package the writable bits weren't set. What does the following show? cd /usr/local/addons/mod_perl-1.99_07/ ls -dl t/htdocs You are not the first to report this problem. I suppose we should add some code to check that t/htdocs is writable. BTW, when you have tests failing, run them separately and then you will immediately what errors are relevant for this test. You can even tell it to run/skip specific subtests... MaxClients (in t/conf/httpd.conf): ... StartServers 1 MaxClients 1 MinSpareThreads 1 ... Tried setting it to 150 before make test, but he sets it back to 1! if you read the head of that file, it's autogenerated and all your changes will be overwritten. If you really want to change it (and most likely you don't, since some test rely on the fact that there is only one process/thread that responds, read the Apache::Test guide here: http://perl.apache.org/docs/general/testing/testing.html#Starting_Multiple_Servers G. I hope you folks don't think I'm just dumping this on you; I have tried everthing I could think of before reporting; I'm really trying to RTFM and learn while I'm doing... You are doing the right thing. Your last report was very comprehensive, now we need to figure out why your system behaves differently than mine :) And you are doing a great service of shaking all those problems out for the many users to come. (hint, hint... :) ______ 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: Horrible handler memory leak
Hann, Brian wrote: > I'm having a problem with a fairly simple handler eating up resources > and I'm wondering if there's any easy way to track it down. > > The handler fetches data from an Oracle database and displays it > using Template-Toolkit. Nothing fancy, just some display logic, etc. > > > The thing is, when I try to show all 8000 records the process spirals > upwards towards 500M and it has to be killed. With smaller amounts > of records (~100-1000), the process STILL grows by several megs. > There really isn't that much data going through other than the sheer > amount of records so I'm wondering what's eating the resources. When storing lots of small records in Perl the overhead of the data management is very big. You can check the real memory usage with B::Size (which can be conveniently invoked via Apache::Status). See http://perl.apache.org/ for some examples. Consider using some other way to represent data in your perl code (e.g. dbm files). Also see the list archives for similar discussions. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0]make test problems
That's much better! -8<-- Start Bug Report 8<-- 1. Problem Description: MP make test fails (no error log generated) A. Apache/Const.pm not found - snip of console output: [START] *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST Can't locate Apache/Const.pm in @INC (@INC contains: Apache-Test/lib [...etc...] You've snipped it in the bad place. What's the reported @INC? But first try with the last suggestion in this reply. I looked on CPAN but Apache::Constants seems to be part of MP1. B. 'test mode' apache doesn't start (it starts OK using apachectl start): Syntax error on line 27 of /usr/local/addons/mod_perl-1.99_07/t/conf/httpd.conf: Invalid command 'TransferLog', perhaps mis-spelled or defined by a module not included inthe server configuration !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 line 27 ot the test httpd.conf file: 26: LogLeveldebug 27: TransferLog /usr/local/addons/mod_perl-1.99_07/t/logs/access_log 28: 29: ServerAdmin nobody@localhost You miss mod_log_config.c, see the next answer C. NOTE! I have gone backwards! My previous incarnations of mod_perl install have gotten further than this. My change - configured Apache with 'all' modules: ./configure --enable-layout=SuSE --enable-mods-shared=all --with-mpm=worker please try first with just: ./configure --with-mpm=worker as suggested by the docs. __ 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: Install problem...
Beau E. Cox wrote: Hi - I am trying to upgrade my test server (SuSE 8.1) to Apache/ mod_perl 2. I installed and tested Apache 2 - all OK. Beau, when reporting problems, please follow the guidelines linked from the perl.apache.org's shortcuts menu: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I have perl 5.8.0 (pre-build by SuSE); It passed the tests in the mpd_perl 2 prequsites section. I get this problem on make test (both with Apache mpm configured as prefork AND worker): apache/subprocess1..4 # testing : passing ARGV # expected: [ # 'foo', # 'bar' # ] # received: [] not ok 1 # testing : passing env via subprocess_env # expected: 'my cool proc' # received: '' not ok 2 # testing : testing subproc's stdin -> stdout + list context # expected: 'my cool proc # ' # received: '' not ok 3 # testing : testing subproc's stdin -> stderr + list context # expected: 'my stderr # ' # received: '' not ok 4 FAILED tests 1-4 Failed 4/4 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/subprocess.t44 100.00% 1-4 I haven't got a clue. This is my sixth reRTFM/reinstall/retest. Could someone give me a push as to what to try next? I forgot to add to the guidelines to check t/logs/error_log, will add it now. So what does your error_log say? Most likely some perms problems with t/htdocs/util, right? __ 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
