Re: Installation/test problems - mod_perl-1.27
Hi there, On Tue, 26 Aug 2003, Patrick West wrote: I've installed apache_1.3.27 and mod_perl-1.27. When I go to run the tests in mod_perl-1.27/t (just running the first one), first it complains that it couldn't start the server. But the server is actually running. Are you sure you have the right server running? Did you check that there were no httpd processes running before you started the test? You might want to check which ports 80, 8080, 8259... are being used as this might lead you to the answer. Have you checked the error_log files for the server(s)? Pay particular attention to dates and times, both when you give the commands to start servers, run tests etc. and also when you look in the log files. This may help you to understand what happened and when. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
[EMAIL PROTECTED] wrote: Hello! Your letter successfully arrived to my mailbox and I'll read it in the nearest future. -- ! . Like we don't have enough spam and virus emails already. If you ask a question in a public forum and expect an answer, please at least consider to turn off any autoresponders that you may 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
Hello there, On Mon, 25 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz and unarchive it to /usr/src/httpd_perl for back-end server then when I make perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' [snip] modules/psections...ok modules/request.Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. [snip] Can you tell us a bit more about your system? The documentation gives you information about what information you need to give... What compiler was used to build your Perl, and was it the same compiler that you used to build mod_perl and Apache? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
Hi there On Tue, 26 Aug 2003, Patrick West wrote: Apparently $net::httpserver is set incorrectly, [snip] So ... where is $net::httpserver being set? t/net/config.pl 73, Ged. PS: Please keep it on the list... :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
why you should reply to the list
Perrin Harkins wrote: On Tue, 2003-08-26 at 18:41, Bruce Tennant wrote: Can we fix the list so that when a person replies, it defaults to the list address and not the posters? Read the following thread: http://marc.theaimsgroup.com/?l=apache-modperlm=99790842623617w=2 Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. Normally when people followup to my reply in private, I don't know what to do about it. I simply bounce it back to the list if it's obvious that the poster just didn't know better. However in some cases an off-list email means that the poster did *not* want it to be seen in public, so I end up asking the person whether she ment to send it to the list in first place, but hit 'Reply' instead of 'Reply-All'. So we have another 2 emails going back in forth. So instead of generating 1 email we end up with 4 in the best case. Now multiply by the number of misdirected emails. Moreover when people correct their mistake they usually end up forwarding the email, they sent to off-list, losing all reference email ids, which breaks the thread in the archives. Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problem with mod_perl 2.0 + apache 2.0 and proxyreq
John Chiu wrote: Thanks in advance. I've tried all the archives and google'd but I have not found anything that would help. I'm running RH 8.0, httpd-2.0.40-11.5 and mod_perl-1.99_05-3 from the RedHat distribution. I'm trying to create a small proxy module that will check a non-proxy request and depending on stuff dynamically transform it into a proxy request using mod_proxy. 1.99_05 is a way too old. Lots of bugs were fixed since that release. Upgrade to at least 1.99_09 or better the current cvs. 1.99_10 will be released as soon as perl-5.8.1 is released. I'm following the example in Chapter 7 (page 370) of the Writing Apache Modules with Perl and C. I know that the book is based on the older apache 1.3 server and associated mod_perl. However, I have not found anything in my readings to indicate that this would not work any more. my $r =3D shift; [... code snipped ...] BTW, you mailer has mangled the source code, s/=/=3D/ Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request. The apache error log indicates (with some debugging) that it is looping on the GET of goodbye.html. Additional debuging indicates that $r-proxyreq is always 0, so it's looping. My questions are: 1.Did sometime change in apache 2 or mod_perl 2 so that you cannot set proxyreq anymore: ie. $r-proxyreq(1). 2.How do you set proxyreq if $r-proxyreq(1) is not the correct method? 3.Is the logic wrong in this proxy example? How can we possible know what the problem is if you don't show the relevant configuration section? Most likely you have a broken configuration and should advise first the mod_proxy documentation. http://httpd.apache.org/docs-2.0/mod/mod_proxy.html To make sure that the problem is not in mod_perl, I've added a new modules/proxy test to the mp2 test suite, based on that example from the eagle book. Try it and if you succeed to break it, then we will fix it. You will need to retrieve the cvs version in order to get it. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution (note: I have just committed the test, so if you use the snapshot, which is updated every 6 hours, it may not be there, so use the normal cvs checkout) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Drox wrote: Hi I am having troubles trying to install the Apache module Apache::Filter I need this module installed, so I can use Apache::SSI with Apache::ASP I already have mod_perl installed. It seems to be installed ok. But when I try to install or test Apache::Filter, I get the following: Can't locate object method boot via package mod_perl at C:/Perl/site/lib/Apache/Constants.pm line 8 Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, or I need to bundle this functionality directly into Apache::ASP. I would prefer the former, but could do the latter ( its been requested before anyway ). Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Stas Bekman wrote: Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. I actually couldn't care less what the reply-to header for the list is, since I will just reply all as I always have. I posted the reference to the earlier thread because anyone who wants to bring it up should at least be aware of what was said in previous discussions. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good morning, On 26/8/03 at 8:26 PM +0200, Thomas Klausner [EMAIL PROTECTED] wrote: Hi! On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote: I need to protect resources in both the static (proxy) front-end and the mod_perl back-end. I have been using standard http authentication which works pretty well except for not allowing a proper logout function and some caching issues which result in occasional false FORBIDDEN responses. Since a proper logout has become an important requirement, I am looking for other solutions. Did you take a look at Apache::AuthCookie? http://search.cpan.org/author/MSCHOUT/Apache-AuthCookie-3.04/ Yes, I've looked at Auth::Cookie, and if I needed a mod_perl only solution, it would be perfect. Since I need the user credentials in the mod_perl app, I'm not happy to leave all authentication to the front-end proxy server unless it sets the user credentials (or some other values) before passing along the request. As AuthCookie is a mod_perl handler, you would have to put the Authentification into the backend. Depending on how you generate the session key (i.e. the value of the Auth Cookie), you should be able to use the cookie in the frontend using one of the modules you mentioned (although I don't know any of them..) Which sort of brings me back full circle. I'm happy to write the backend (modperl) support myself for whatever the frontend module requires. But the module that I would choose (mod_auth_mda) doesn't have perl examples for creating the MD5 cookie, and I'm only borderline confident that I can take their java examples along with the documentation to figure out perl routines for the cookie creation. I'm still hoping someone has already solved this issue of shared authentication scheme between static frontend and modperl backend servers. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: MP_AP_PREFIX = /home/craig/temp/mod_perl-1.99_09/ hi craig. before we continue, please try the latest cvs (without the patch I sent) and see if your stuff segfaults there. if not, at least we know we've isolated the segfault and just have bad logic to fix :) if you need help with cvs, see http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_the_mod_perl_Source --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
On Tue, 26 Aug 2003, Stas Bekman wrote: Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. [snip] Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. Unfortunately I think we've all seen enough unsubscribe me emails to know that people don't read the info that is *already* being added to the outgoing mail... Stas, you probably get it worst just because of the volume of mail you send to the list (which we're all grateful for!). Maybe when you do your mod_perl list reading you should just configure your outgoing email with: Reply-to: [EMAIL PROTECTED] Kind of a pain for you though... Larry Leszczynski [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Larry Leszczynski wrote: On Tue, 26 Aug 2003, Stas Bekman wrote: Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. [snip] Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. Unfortunately I think we've all seen enough unsubscribe me emails to know that people don't read the info that is *already* being added to the outgoing mail... One can argue that it's not obvious that one has to look at the headers to find out the unsubscribe information. Most modern mail-clients hide the headers by default. You need to know that you want to look at them. I think the new signature that Ask has added last week doesn't leave place for such valid excuses ;) Stas, you probably get it worst just because of the volume of mail you send to the list (which we're all grateful for!). Maybe when you do your mod_perl list reading you should just configure your outgoing email with: Reply-to: [EMAIL PROTECTED] Kind of a pain for you though... Hmm, that's an idea. Won't the list software strip this header? I shell try it now. If it works I should just figure out how to add an outgoing mozilla-mail filter to push this header, if the email is sent to the modperl list. Thanks for the idea, Larry! __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
On 8/26/03 8:48 PM, Stas Bekman [EMAIL PROTECTED] a écrit : Larry Leszczynski wrote: On Tue, 26 Aug 2003, Stas Bekman wrote: Please advise on another way to tell people to respond to the list and not in private. I used to receive much less off-list replies earlier. [snip] Purhaps adding a list signature: Always post followups back to the list! will help, but who reads that. Unfortunately I think we've all seen enough unsubscribe me emails to know that people don't read the info that is *already* being added to the outgoing mail... One can argue that it's not obvious that one has to look at the headers to find out the unsubscribe information. Most modern mail-clients hide the headers by default. You need to know that you want to look at them. I think the new signature that Ask has added last week doesn't leave place for such valid excuses ;) Stas, you probably get it worst just because of the volume of mail you send to the list (which we're all grateful for!). Maybe when you do your mod_perl list reading you should just configure your outgoing email with: Reply-to: [EMAIL PROTECTED] Kind of a pain for you though... Hmm, that's an idea. Won't the list software strip this header? I shell try it now. If it works I should just figure out how to add an outgoing mozilla-mail filter to push this header, if the email is sent to the modperl list. I thought this was a strange behavior for the list messages when I realized that I had replied, accidentally, to Stas personally and not the list. I subscribe to six lists, and mod_perl is the *only* one where my email reader automatically replies to the sender and not the list. All the other lists automatically put the list email address in the Reply-to: of the distributed posts, thus making replying to the list the default. Couldn't that be changed for modperl? Douglas -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Douglas Theobald wrote: I thought this was a strange behavior for the list messages when I realized that I had replied, accidentally, to Stas personally and not the list. I subscribe to six lists, and mod_perl is the *only* one where my email reader automatically replies to the sender and not the list. All the other lists automatically put the list email address in the Reply-to: of the distributed posts, thus making replying to the list the default. Couldn't that be changed for modperl? Perrin has already replied to this, as we have discussed this many times in the last 7 years: http://marc.theaimsgroup.com/?l=apache-modperlm=99790842623617w=2 While there is no consensus on this dispute please remember to use the 'Reply-All' function/button when replying to the list. It'll work for other lists which use the 'Reply-To' header as well. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. If there's really nothing out there to add a hash to the URI, I could probably be convinced to package up the code I have, simple as it may be. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org Knowledge is power. Power corrupts. Study hard. Be Evil. - Thyra -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
On 8/26/03 10:00 PM, Stas Bekman [EMAIL PROTECTED] a écrit : Douglas Theobald wrote: I thought this was a strange behavior for the list messages when I realized that I had replied, accidentally, to Stas personally and not the list. I subscribe to six lists, and mod_perl is the *only* one where my email reader automatically replies to the sender and not the list. All the other lists automatically put the list email address in the Reply-to: of the distributed posts, thus making replying to the list the default. Couldn't that be changed for modperl? Perrin has already replied to this, as we have discussed this many times in the last 7 years: http://marc.theaimsgroup.com/?l=apache-modperlm=99790842623617w=2 Sorry, I had no idea this was such a fun topic ... While there is no consensus on this dispute please remember to use the 'Reply-All' function/button when replying to the list. It'll work for other lists which use the 'Reply-To' header as well. Except 'Reply-All' duplicates emails unnecessarily, so currently I have different methods depending upon which list I'm replying to. C'est la vie. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Douglas == Douglas Theobald [EMAIL PROTECTED] writes: Douglas All the other lists automatically put the list email address Douglas in the Reply-to: of the distributed posts, thus making Douglas replying to the list the default. Couldn't that be changed Douglas for modperl? Eeek. Please make the bad man stop, mommy! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Quoting Michael [EMAIL PROTECTED]: On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Cheers, Cees -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: why you should reply to the list
Ok compare: == w/Reply-To "munged" 1) Left click on from line, copy 2) hit reply, replace list email w/sender email 3) type away == w/out reply to, reply to whole list 1) hit reply, DOH! reply all 2) cut out senders email address or he gets duplicate mails (YES I DONT WANT TO READ IT TWICE!) 3) type away Seems the "common" case is easier in the "munged" way, and MUCH harder in the normal way. It's a mail list, mail lists aren't normal email, reply-to munging is not as bad as that article made it out to be. I'll shut-up now since I started this thread (and have been reading duplicate if you didn't notice). "Randal L. Schwartz" [EMAIL PROTECTED] wrote: "Douglas" == Douglas Theobald <[EMAIL PROTECTED]>writes:Douglas All the other lists automatically put the list email addressDouglas in the Reply-to: of the distributed posts, thus makingDouglas replying to the list the default. Couldn't that be changedDouglas for modperl?"Eeek. Please make the bad man stop, mommy!"-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095<[EMAIL PROTECTED]>Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!-- Reporting bugs: http://perl.apache.org/bugs/Mail list info: http://perl.apache.org/maillist/modperl.htmlwww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 2:49 PM +1000, Cees Hek [EMAIL PROTECTED] wrote: Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Thanks for the clarification. And the requirement for something that works in both modperl and non-modperl servers is also part of the subject line. But I'll try to make the problem/requirements more clear in future emails. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 12:05 AM -0400, Michael [EMAIL PROTECTED] wrote: The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. Except that I'm looking for a solution which will also work in the static (proxy) front-end. I'm currently using Apache::DBI for the backend and it works well. I also want a solution which doesn't rely on browser based http authentication since logging out is a requirement. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. Any other suggestions? Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Carpout in mod_perl
Solaris 2.5.1
perl 5.6.0
Apache/1.3.27 (Unix) mod_perl/1.27
CGI 2.76
CGI::Carp 1.20
Hi,
I have problems with redirecting STDERR in mod_perl. Have a look at the
following example:
==
#/usr/bin/perl -w
use CGI qw(header param url_param url);
use CGI::Carp qw(fatalsToBrowser croak carp carpout);
my ($pwd, $errorlog, $fh);
BEGIN {
$pwd = qx|/bin/pwd|;
chop $pwd;
$errorlog = $pwd/myerror.log;
$fh = new FileHandle $errorlog;
carpout($fh);
}
# functions printing to STDERR
...
==
If I use CGI instead of mod_perl, it is OK. I have all my STDERR messages at
myerror.log. But when I put my script in mod_perl environment then I have some
of the messages in myerror.log and some in standard Apache error_log file. If
I run my script a few times, I can see that the message appears randomly either
in myerror.log or in error_log file.
I am not able to determine when messages are going to myerror.log and when they
are going to error_log. Is it a feature of mod_perl?
Thank you in advance for your help.
Best regards,
Wojciech Pietron
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
File Upload mod_perl to mod_perl2
Could anyone advise which file upload method to use that is be written in mod_perl that will be migrated to mod_perl2 at a later time? And, generally, which particular package from mod_perl (1) should be avoided. Any insight will be helpful. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: installing Apache::Test via CPAN impossible as root
Am Tue, 26 Aug 2003 16:07:21 + schrieb Stas Bekman:
As you posted in the followup, this is a problem with all Apache:: modules.
The problem originates within Apache, not us.
Didn't know that apache rejects to run as root. Strange (but safe) behaviour.
Ideas how to solve this are *very* welcome.
The best idea I have is to serve the htdocs directory from outside the
~root hierarchy. Apache is initially started as root and thus has no
difficulties to get the configuration stuff needed to start up.
A quick (non MSWormOS compatible) fix would be to patch
lib/Apache/TestConfig.pm as follows:
---CUT
--- TestConfig.pm 2003-06-07 01:43:28.0 +0200
+++ TestConfig.pm.docroot_patched 2003-08-27 12:13:26.0 +0200
@@ -214,7 +214,7 @@
$vars-{t_dir}||= catfile $vars-{top_dir}, 't';
$vars-{serverroot} ||= $vars-{t_dir};
-$vars-{documentroot} ||= catfile $vars-{serverroot}, 'htdocs';
+$vars-{documentroot} ||= /tmp/Apache-Test.$$/htdocs;
$vars-{perlpod} ||= $self-find_in_inc('pods') ||
$self-find_in_inc('pod');
$vars-{perl} ||= $^X;
---CUT
Moving the entire t/ directory to temp is IMHO not necessary, but depending on
the test needs it may also be required to copy a cgi-bin directory to /tmp as
well.
For a better solution of course it would also be reasonable to query the ENV
settings that even exist on MSWorm (IIRC) and even better check that directory's
permissions and fallback again to /tmp, if nothing else is found. But this is maybe
something that File::Spec, which nathan mentioned, already does.
IMHO again the build dir in general should default to /tmp/cpan_$USER (or
/var/tmp/cpan_$USER if you prefer), so it would be a good thing to change the default
setting of CPAN's initial configuration for future CPAN releases.
In some ways CPAN packages are very similar to SRPMS and I think CPAN could learn
a lot from RPM here.
happy hacking
udo
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and staticfrontend
Hi there, On Wed, 27 Aug 2003, Charlie Garrison wrote: Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. It's not so hard. There's a skeleton module in the Apache sources for you to start with, take a look at it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp1.0] Installation problem
Hello again! I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz and unarchived them to /usr/src/httpd_perl for back-end server then when I make perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' and make make test tests failed: done /usr/bin/perl t/TEST 0 modules/actions.ok modules/cgi.ok modules/constants...ok modules/cookie..ok modules/fileok modules/httpdconf...ok modules/include.ok modules/log.ok modules/module..skipped test on this platform modules/perlrun.ok modules/psections...ok modules/request.Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. Use of uninitialized value in numeric eq (==) at modules/request.t line 149. Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. Use of uninitialized value in numeric eq (==) at modules/request.t line 149. Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. Use of uninitialized value in numeric eq (==) at modules/request.t line 149. Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. Use of uninitialized value in numeric eq (==) at modules/request.t line 149. modules/request.NOK 10FAILED tests 1-10 Failed 10/10 tests, 0.00% okay modules/src.ok modules/ssi.skipped test on this platform modules/stage...skipped test on this platform modules/status..fetch /perl/perl-status failed! modules/status..dubious Test returned status 111 (wstat 28416, 0x6f00) DIED. FAILED tests 1-10 Failed 10/10 tests, 0.00% okay modules/symbol..FAILED before any test output arrived modules/uri.FAILED before any test output arrived modules/utilFAILED before any test output arrived internal/apiFAILED before any test output arrived internal/auth...ok 2/2FAILED test 1 Failed 1/2 tests, 50.00% okay internal/croak..NOK 12FAILED tests 1, 3-4, 6-7, 9-10, 12 Failed 8/12 tests, 33.33% okay internal/dirmagic...FAILED before any test output arrived internal/error..ok internal/headersArgument isn't numeric in numeric eq (==) at internal/headers.t line 29. Argument isn't numeric in numeric eq (==) at internal/headers.t line 29. Argument isn't numeric in numeric eq (==) at internal/headers.t line 29. Argument isn't numeric in numeric eq (==) at internal/headers.t line 29. Use of uninitialized value in string eq at internal/headers.t line 42. Use of uninitialized value in string eq at internal/headers.t line 48. Use of uninitialized value in string eq at internal/headers.t line 54. internal/headersNOK 13FAILED tests 1-11, 13 Failed 12/13 tests, 7.69% okay internal/hooks..500 (Internal Server Error) Can't connect to localhost:8529 (Timeout) Client-Date: Mon, 25 Aug 2003 05:12:29 GMT internal/hooks..dubious Test returned status 111 (wstat 28416, 0x6f00) internal/http-get...Internal Server Error internal/http-get...dubious Test returned status 111 (wstat 28416, 0x6f00) DIED. FAILED tests 1-16 Failed 16/16 tests, 0.00% okay internal/http-post..Internal Server Error internal/http-post..dubious Test returned status 111 (wstat 28416, 0x6f00) DIED. FAILED tests 1-7 Failed 7/7 tests, 0.00% okay internal/proxy..ok internal/redirect...NOK 6FAILED tests 1-4, 6 Failed 5/6 tests, 16.67% okay internal/rwrite.NOK 2FAILED tests 1-2 Failed 2/2 tests, 0.00% okay internal/stackedcan't open http://localhost:8529//perl/stacked internal/stackeddubious Test returned status 111 (wstat 28416, 0x6f00) internal/table..FAILED before any test output arrived internal/taint..Internal Server Error internal/taint..dubious Test returned status 111 (wstat 28416, 0x6f00) DIED. FAILED tests 1-3 Failed 3/3 tests, 0.00% okay Failed Test Status Wstat Total Fail Failed List of failed --- internal/api.t ?? ?? % ?? internal/auth.t 21 50.00% 1 internal/croak. 128 66.67% 1, 3-4, 6-7, 9-10, 12 internal/dirmag ?? ?? % ?? internal/header 13 12 92.31% 1-11, 13 internal/hooks. 111 28416?? ?? % ?? internal/http-g 111 2841616 16 100.00% 1-16 internal/http-p 111 28416 77 100.00% 1-7 internal/redire 65 83.33% 1-4, 6 internal/rwrite 22 100.00% 1-2 internal/stacke 111 28416?? ?? % ?? internal/table.
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 14:49:05, Cees Hek said... It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. Whoops, you're right, I did just skim it. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org If Bill Gates had a nickel for every time Windows crashed... ..oh wait, he does. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 15:45:11, Charlie Garrison said... I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Are you looking for something that's just a drop-in solution, transparent to the backend completely, not part of the backend software? I'd think in that case, you'd want something like PerlAuthenHandler and PerlAuthzHandler, let them manage the logins and just pass the client down to the backend software. I could still be way off here though. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1.0] Installation problem
Hi there, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz [snip] tests failed: [snip] Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.16-22smp, archname=i386-linux Upgrade Perl (and your operating system?:). that might help, and version 5.6.0 of Perl is a disaster just waiting to happen anyway. You should be OK with 5.6.1 but I would think 5.8.1 might be better. [snip] Compiler: cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 (ASPLinux 7.0 2.96-79) Please post the output of gcc -v on your system. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: AuthenNTLM
Brett Hales wrote: I am having problems with Apache-AuthenNTLM-0.23. In apache's error.log I am getting the following errors reported. AuthenNTLM: timed out while waiting for lock (key = 23754) This also seems to cause the web server to go _very_ slow. I have looked through the AuthenNTLM.pm and found the section where this is evaluated. There is a comment above it. # smb aborts any connection that where no user is looged on as soon as somebody # tries to open another one. So we have to make sure two request, do not start # two auth cycles at the same time. To avoid a hang of the whole server we wrap it with # a small timeout Maybe this is actually happening and I am getting two auth cycles. Does anybody have an idea why this is happening? Thanks, It's possible, but seems unlikely. Is this happening constantly? Also, try messing with the PerlSetVar ntlmsemkey and PerlSetVar ntlmsemtimout values. ntlmsemkey turns serialization on/off, and ntlmsemtimout sets the timeout for the Apache server to wait for the semaphore, (which serializes the requests to the SMB server). speeves cws -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI not really loading
I've got a case where my DBI connections appear to be timing out and not reconnecting. Google just points to the old timeout problem that should be solved. I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages (from it) in the error log. Apache::Status lists Apache DBI, but lists no database connections. Advice most welcome Perl version v5.6.1 for Apache/1.3.27 (Unix) AuthPG/1.2 mod_perl/1.27 Database is Postgres (I can dig up version, but it's recent but not most recent) I have no startup.pl (just trying to get it to work at this point) Scripts are in /login, and call DBI-connect() and disconnect(). They work, until the connection drops. (Normally, it doesn't time out, but the connection will eventually drop when the network fritzes, figure once or twice a week.) Then I get DBD::Pg::st execute failed: no connection to the server at (my module) in the error log. It looks as if Apache::DBI isn't pinging it, but my efforts to look into have just left me confused...Apache::DBI is loaded, according to Apache::Status, But why won't it log any material? httpd.conf looks like: (test server obviously) MinSpareServers 1 MaxSpareServers 1 StartServers 1 IfModule mod_perl.c PerlTaintCheck On PerlWarn On PerlModule Apache::Status PerlSetVar StatusOptionsAll On PerlSetVar StatusTerse On PerlSetVar StatusTerseSize On PerlSetVar StatusTerseSizeMainSummary On PerlModule B::TerseSize PerlModule Apache::DBI PerlModule Apache::StatINC PerlSetVar StatINC_Debug 1 Location /perl-status SetHandler perl-script PerlHandler Apache::Status /Location Location /login PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI /Location /IfModule -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Re[2]: [mp1.0] Installation problem
Hello again, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: GH Please post the output of GH gcc -v Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) Make sure to use that compiler to build Perl, mod_perl and Apache. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re[2]: [mp1.0] Installation problem
Hello Ged, Wednesday, August 27, 2003, 6:11:13 PM, you wrote: GH Hi there, GH On Wed, 27 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz [snip] tests failed: [snip] Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.16-22smp, archname=i386-linux GH Upgrade Perl (and your operating system?:). that might help, and GH version 5.6.0 of Perl is a disaster just waiting to happen anyway. GH You should be OK with 5.6.1 but I would think 5.8.1 might be better. [snip] Compiler: cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 (ASPLinux 7.0 2.96-79) GH Please post the output of GH gcc -v Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) GH on your system. GH 73, GH Ged. -- Alan Rafagudinov E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED] Homepage: http://www.rafagudinov.com Phone: +7(926)22-5 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp1] consistent segfaults with HTML::Mason
Greetings, I'm not sure if this should be sent here, or to the HTML::Mason list, but as its a segfault, I've sent it here first. I've just upgraded my apache/mod_perl installation, and have run into a few problems. Firstly, all of mod_perl's tests pass (although a few are skipped), and mod_perl itself seems to work (Apache::MP3 was the module I used for testing, which seems to work). However, any attempt to use HTML::Mason::ApacheHandler causes a segmentation fault. I've looked though the various mod_perl and Mason FAQs/documentation, and couldn't find anything regarding this. I'd be most appreciative if anyone could point me in the right direction. My system details are as below - I've included everything that seems to be relevant from the list on http://perl.apache.org/bugs/. I'm running FreeBSD 4.8-RELEASE, Perl 5.8.0, Apache 1.3.28 and mod_perl 1.28. mod_perl was compiled as a static module, using the following command line in the mod_perl source directory: perl Makefile.PL APACHE_SRC=../apache_1.3.28/src APACHE_PREFIX=/usr/local/apache13 DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 The following mod_perl tests were skipped (the rest all completed sucessfully): modules/cookieskipped all skipped: no reason given modules/moduleskipped all skipped: no reason given modules/request...skipped all skipped: no reason given modules/stage.skipped all skipped: no reason given My perl details are as follows: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=freebsd, osvers=4.8-release, archname=i386-freebsd uname='freebsd holly.mutatorr.net 4.8-release freebsd 4.8-release #0: sat may 17 18:53:46 bst 2003 [EMAIL PROTECTED]:usrsrcsyscompileholly i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.0/m ach -Dprivlib=/usr/local/lib/perl5/5.8.0 -Dman3dir=/usr/local/lib/perl5/5.8. 0/man/man3 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.0/mach -Dsitelib=/u sr/local/lib/perl5/site_perl/5.8.0 -Dscriptdir=/usr/local/bin -Ui_malloc -Ui _iconv -Uinstallusrbinperl -Dcc=cc -Dccflags=-DAPPLLIB_EXP=/usr/local/lib/p erl5/5.8.0/BSDPAN -Ui_gdbm -Dusemymalloc=n -Dusethreads=n' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.0/BSDPAN -DHAS_FPSETMASK -DHAS_FL OATINGPOINT_H -fno-strict-aliasing -I/usr/local/include', optimize='-O -pipe ', cppflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.0/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 20020320 [FreeBSD]', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lm -lc -lcrypt -lutil perllibs=-lm -lc -lcrypt -lutil libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under freebsd Compiled at May 26 2003 00:36:13 @INC: /usr/local/lib/perl5/site_perl/5.8.0/mach /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.0/BSDPAN /usr/local/lib/perl5/5.8.0/mach /usr/local/lib/perl5/5.8.0 The GDB backtrace output (from debugging httpd -X) is as follows: (gdb) bt #0 0x808d079 in XS_Apache_dir_config () #1 0x810a7f7 in Perl_pp_entersub () #2 0x8104b24 in Perl_runops_standard () #3 0x80c39fe in Perl_call_sv () #4 0x80c3b42 in Perl_eval_sv () #5 0x80846ce in perl_require_module () #6 0x807f1ac in perl_call_handler () #7 0x807ecb4 in perl_run_stacked_handlers () #8 0x807d7a3 in perl_handler () #9 0x809bb8d in ap_invoke_handler () #10 0x80b185c in ap_some_auth_required () #11 0x80b1cec in ap_internal_redirect () #12 0x8076052 in ap_get_server_built () #13 0x809bb8d in ap_invoke_handler () #14 0x80b185c in ap_some_auth_required () #15 0x80b18c6 in ap_process_request () #16 0x80a817f in ap_child_terminate () #17 0x80a8341 in ap_child_terminate () #18 0x80a84ba in ap_child_terminate () #19 0x80a8b5c in ap_child_terminate () #20 0x80a93bc in main () #21 0x8064a22 in _start () The relavent sections of my httpd.conf are as follows: VirtualHost * DocumentRoot
Re: Use of uninitialized valued in concatenation....
On Fri, 2003-08-22 at 17:23, B. Fongo wrote: I have a file (output_tab.pm) that I use to generate tables dynamically. Even though it serves its purpose, it goes on generating this error: Script_name.pl: Use of uninitialized value in concatenation (.) or string at output_tab.pm line 42. This is a standard perl error message. It is not related to mod_perl. You can look in the perldiag man page for a more complete explanation. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[Job] Staff Programmer Needed
I'm looking for a mod_perl savvy programmer to join an eCommerce development team. Skills include: Perl 5.6.1, mod_perl 1.0, Oracle, DBI, Linux, SQL, and experience in a test driven development. I'm also looking for a build engineer with experience with RPM, autoconf, and make. Solaris and Linux platforms. The company is based in Oregon and the work environment is excellent. Send me your resume at [EMAIL PROTECTED] and I'll send you further details. Thx, John -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: [...] The GDB backtrace output (from debugging httpd -X) is as follows: (gdb) bt #0 0x808d079 in XS_Apache_dir_config () #1 0x810a7f7 in Perl_pp_entersub () #2 0x8104b24 in Perl_runops_standard () #3 0x80c39fe in Perl_call_sv () #4 0x80c3b42 in Perl_eval_sv () #5 0x80846ce in perl_require_module () #6 0x807f1ac in perl_call_handler () #7 0x807ecb4 in perl_run_stacked_handlers () #8 0x807d7a3 in perl_handler () #9 0x809bb8d in ap_invoke_handler () #10 0x80b185c in ap_some_auth_required () #11 0x80b1cec in ap_internal_redirect () #12 0x8076052 in ap_get_server_built () #13 0x809bb8d in ap_invoke_handler () #14 0x80b185c in ap_some_auth_required () #15 0x80b18c6 in ap_process_request () #16 0x80a817f in ap_child_terminate () #17 0x80a8341 in ap_child_terminate () #18 0x80a84ba in ap_child_terminate () #19 0x80a8b5c in ap_child_terminate () #20 0x80a93bc in main () #21 0x8064a22 in _start () Wearing my bug-tender cap, but not taking the ownership of this bug, I should say that your backtrace could be much more useful if you have had rebuilt apache/perl/mod_perl with debugging symbols enabled. When you do that the trace will show the arguments to the functions. http://perl.apache.org/bugs/ provides the details on how to do that. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1.0] Installation problem
Ged Haywood wrote: Hello again, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: GH Please post the output of GH gcc -v Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) Make sure to use that compiler to build Perl, mod_perl and Apache. Since he built from source as: perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' it's quite sure that he has used the same compiler. However Alan, have you seen that all emails to this list end with this two lines? Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html If you have followed http://perl.apache.org/bugs/, you'd have supplied a proper bug report and Ged won't have to guess-work what compiler you have used. Make sure to always report bugs properly in the future. Alan, as Ged suggested, upgrade your perl to 5.6.1 or 5.8.0 (5.8.1 was not released yet) and try again (you will need to rebuild mod_perl once you did that). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File Upload mod_perl to mod_perl2
Issac Goldstand wrote: You might want to look at Apache::Request for mod_perl. It's currently almost ready for mod_perl2... or meanwhile use CGI.pm 2.93 or higher. - Original Message - From: rkl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 9:51 AM Subject: File Upload mod_perl to mod_perl2 Could anyone advise which file upload method to use that is be written in mod_perl that will be migrated to mod_perl2 at a later time? And, generally, which particular package from mod_perl (1) should be avoided. Any insight will be helpful. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: installing Apache::Test via CPAN impossible as root
Udo Rader wrote:
Am Tue, 26 Aug 2003 16:07:21 + schrieb Stas Bekman:
As you posted in the followup, this is a problem with all Apache:: modules.
The problem originates within Apache, not us.
Didn't know that apache rejects to run as root. Strange (but safe) behaviour.
It starts as root alright, but won't spawn workers as root.
Ideas how to solve this are *very* welcome.
The best idea I have is to serve the htdocs directory from outside the
~root hierarchy. Apache is initially started as root and thus has no
difficulties to get the configuration stuff needed to start up.
A quick (non MSWormOS compatible) fix would be to patch
lib/Apache/TestConfig.pm as follows:
---CUT
--- TestConfig.pm 2003-06-07 01:43:28.0 +0200
+++ TestConfig.pm.docroot_patched 2003-08-27 12:13:26.0 +0200
@@ -214,7 +214,7 @@
$vars-{t_dir}||= catfile $vars-{top_dir}, 't';
$vars-{serverroot} ||= $vars-{t_dir};
-$vars-{documentroot} ||= catfile $vars-{serverroot}, 'htdocs';
+$vars-{documentroot} ||= /tmp/Apache-Test.$$/htdocs;
$vars-{perlpod} ||= $self-find_in_inc('pods') ||
$self-find_in_inc('pod');
$vars-{perl} ||= $^X;
---CUT
this is only needed for root-run tests, which most of us don't do.
Moving the entire t/ directory to temp is IMHO not necessary, but depending on
the test needs it may also be required to copy a cgi-bin directory to /tmp as
well.
Other dirs top-level t/ dirs may need to be copied as well, e.g. t/logs if
they have some custom logs written from the handlers. Ideally it should be
configurable by the developer that uses Apache::Test.
But I agree that it's certainly a good idea to copy only the minimal amount of
files.
For a better solution of course it would also be reasonable to query the ENV
settings that even exist on MSWorm (IIRC) and even better check that directory's
permissions and fallback again to /tmp, if nothing else is found. But this is maybe
something that File::Spec, which nathan mentioned, already does.
Yup, this is going to be the hardest part. We need a good portable test.
Currently I do this check. I have no idea how portable it is. Please tell me
if there is some problem with it.
You can find it in Apache-Test/lib/Apache/TestRun.pm of the current
modperl-2.0 cvs:
sub check_perms {
my ($self, $user, $uid, $gid) = @_;
# test that the base dir is rwx by the selected non-root user
my $vars = $self-{test_config}-{vars};
my $dir = $vars-{t_dir};
my $perl = $vars-{perl};
my $check = qq[sudo -u '#$uid' $perl -e ] .
qq['print -r $dir -w _ -x _ ? OK : NOK'];
warning $check\n;
my $res = qx[$check] || '';
warning result: $res;
unless ($res eq 'OK') {
#$self-restore_t_perms;
error(EOI) die \n;
You are running the test suite under user 'root'.
Apache cannot spawn child processes as 'root', therefore
we attempt to run the test suite with user '$user' ($uid:$gid).
The problem is that the path:
$dir
must be 'rwx' by user '$user', so Apache can read and write under that
path.
There several ways to resolve this issue. For example move
'$dir' to '/tmp/' and repeat the 'make test' phase.
You can test whether the location is good by running the following test:
% $check
EOI
}
}
IMHO again the build dir in general should default to /tmp/cpan_$USER (or
/var/tmp/cpan_$USER if you prefer), so it would be a good thing to change the default
setting of CPAN's initial configuration for future CPAN releases.
In some ways CPAN packages are very similar to SRPMS and I think CPAN could learn
a lot from RPM here.
Well, that is the wrong forum to discuss the CPAN issues, at least because
those who control CPAN.pm aren't listening ;)
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Loading perl modules from same directory
All, I'm having problems loading .PM modules (apache2, mod_perl2) that are in the root directory and am not quite sure where to begin (Been here http://perl.apache.org/docs/general/perl_reference/perl_reference.html#The__INC_hash but no success). I am converting code from an IIS/Perl CGI implementation and the following worked before without any problems. In the WWWROOT, I had mylib.pm (example) and in a perl script I simply said: use mylib; In mod_perl 2.0, using COMPAT etc, I get: ModPerl::Registry: Can't locate mylib.pm in @INC (@INC cont ains: C:/Perl/site/lib/Apache2 C:/Perl/lib C:/Perl/site/lib . C:/apache2/ C:/apache2/lib/perl) at C:/apache2/htdocs/ptest.pl line 2. BEGIN failed--compilation aborted at C:/apache2/htdocs/ptest.pl line 2. My question is, why isn't Apache2/Mod_perl finding the library to load, if the PM file is in the same directory as the perl-script? Is this a sandbox security feature? I know its a bad idea, but its legacy code and is peppered everywhere. JS -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Loading perl modules from same directory
On Wed, 2003-08-27 at 14:48, js wrote: My question is, why isn't Apache2/Mod_perl finding the library to load, if the PM file is in the same directory as the perl-script? This is a mod_perl 2 issue, which is documented here: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends There is a workaround for it on that page as well. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
perl.apache.org problem
It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. Cheers, Cees Hek -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: perl.apache.org problem
Cees Hek wrote: It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. There is no problem, Cees. This is done by the Apache Software Foundation. mod_perl is an ASF project if you didn't know. Have you read what it says on http://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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stas Bekman [EMAIL PROTECTED] wrote:
Wearing my bug-tender cap, but not taking the ownership of this bug, I
should
say that your backtrace could be much more useful if you have had rebuilt
apache/perl/mod_perl with debugging symbols enabled. When you do that the
trace will show the arguments to the functions.
http://perl.apache.org/bugs/
provides the details on how to do that.
Hrm. I thought I had. Let me try it again.
Aha. It would seem that make install strips symbols or something...
Program received signal SIGSEGV, Segmentation fault.
0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
3114TABLE_GET_SET(cs-vars, FALSE);
(gdb) bt
#0 0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
#1 0x810c3b3 in Perl_pp_entersub ()
#2 0x81066e0 in Perl_runops_standard ()
#3 0x80c55ba in S_call_body ()
#4 0x80c56fe in Perl_eval_sv ()
#5 0x80860ea in perl_require_module (name=0x8324f7c
HTML::Mason::ApacheHandler, s=0x827019c) at perl_util.c:550
#6 0x807ffdc in perl_call_handler (sv=0x81ce9ec, r=0x8323d34, args=0x0) at
mod_perl.c:1590
#7 0x807f9d1 in perl_run_stacked_handlers (hook=0x815f619 PerlHandler,
r=0x8323d34, handlers=0x81cea4c) at mod_perl.c:1374
#8 0x807dd37 in perl_handler (r=0x8323d34) at mod_perl.c:897
#9 0x809d811 in ap_invoke_handler (r=0x8323d34) at http_config.c:518
#10 0x80b3470 in process_request_internal (r=0x8323d34) at
http_request.c:1324
#11 0x80b3900 in ap_internal_redirect (new_uri=0x8323d0c /index.mhtml,
r=0x8323034) at http_request.c:1461
#12 0x8076042 in handle_dir (r=0x8323034) at mod_dir.c:174
#13 0x809d811 in ap_invoke_handler (r=0x8323034) at http_config.c:518
#14 0x80b3470 in process_request_internal (r=0x8323034) at
http_request.c:1324
#15 0x80b34da in ap_process_request (r=0x8323034) at http_request.c:1340
#16 0x80a9dcb in child_main (child_num_arg=0) at http_main.c:4653
#17 0x80a9f8d in make_child (s=0x819c034, slot=0, now=1062020715) at
http_main.c:4768
#18 0x80aa106 in startup_children (number_to_start=2) at http_main.c:4850
#19 0x80aa7a4 in standalone_main (argc=4, argv=0xbfbffa78) at
http_main.c:5169
#20 0x80ab004 in main (argc=4, argv=0xbfbffa78) at http_main.c:5511
#21 0x8064a6a in _start ()
(gdb) list
3109s = r r-server ? r-server : perl_get_startup_server();
3110if (s s-module_config) {
3111SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
3112cs = (perl_server_config
*)get_module_config(s-module_config,
3113
perl_module);
3114TABLE_GET_SET(cs-vars, FALSE);
3115}
3116else XSRETURN_UNDEF;
3117}
3118
(gdb) print cs
$4 = (perl_server_config *) 0x0
(gdb) print s
$6 = (server_rec *) 0x0
I'm no expert at debugging C, but I dont think that the above looks too
healthy
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Carpout in mod_perl
Wojciech Pietron wrote:
...
use CGI qw(header param url_param url);
use CGI::Carp qw(fatalsToBrowser croak carp carpout);
my ($pwd, $errorlog, $fh);
BEGIN {
$pwd = qx|/bin/pwd|;
chop $pwd;
$errorlog = $pwd/myerror.log;
$fh = new FileHandle $errorlog;
carpout($fh);
}
# functions printing to STDERR
...
==
If I use CGI instead of mod_perl, it is OK. I have all my STDERR messages at
myerror.log. But when I put my script in mod_perl environment then I have some
of the messages in myerror.log and some in standard Apache error_log file. If
I run my script a few times, I can see that the message appears randomly either
in myerror.log or in error_log file.
I am not able to determine when messages are going to myerror.log and when they
are going to error_log. Is it a feature of mod_perl?
In mod_perl, you should be aware that BEGIN {} blocks only get executed the
first time a script is compiled, so is not a reliable place to execute code
that you want executed once per script. If you reall want the code execute
each request, put it into a subroutine, and call that routine each time.
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checker http://www.nodeworks.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Josh Chamas wrote: Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, IMHO, Apache::Filter does doesn't need to be ported to mp2. You have a native API for filtering. Geoff has posted a an alpha-port of Apache::SSI to the list some time ago. or I need to bundle this functionality directly into Apache::ASP. I would prefer the former, but could do the latter ( its been requested before anyway ). Most likely you need to do the filtering in Apache::ASP by yourself, see the URL to the filters guide I have posted in another followup. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Stas Bekman wrote: Josh Chamas wrote: Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, IMHO, Apache::Filter does doesn't need to be ported to mp2. You have a native API for filtering. Geoff has posted a an alpha-port of Apache::SSI to the list some time ago. yes. Apache::SSI seems to be getting a bit of attention lately, so I'll probably pick up working on that again now :) --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote:
Stas Bekman wrote:
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report
as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r-main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being
operated on is explicity flushed. this is bad within a (streaming)
filter where you are expected to call $f-print yourself, as the data is
sent without your permission (you may be operating on it or not want to
send it at all). it also seemed to cause infinite loop in my tests
because the filter was seeing the same data over and over again.
I can't really understand the reason behind the code anyway, since I
can't see anywhere in core where such logic is applied before
ap_run_sub_request - everyone seems to call without regard to where in
the data stream they happen to be, so I don't get why mod_perl should be
any different. indeed commenting it out fixes the problem for me.
however, removing that logic causes api/lookup_uri2.t to fail, but I
suspect this is an issue with puts() rather than the subrequest
mechanism - changing puts() to print() makes everything work just fine.
does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
rputs() never flushes data,
print() flushes if $| == 1;
Please don't remove rputs, it's there for a reason.
If you fix lookup_uri2's handler to be:
sub handler {
my $r = shift;
subrequest($r, 'myplan');
local $| = 0;
$r-print(ok 2\n);
subrequest($r, 'ok3');
Apache::OK;
}
You get:
ok 1
ok 3
ok 2
Confused test output: test 3 answered after test 3
ok
which is wrong.
So there is no problem with the r-main logic in mpxs_ap_run_sub_req, it's
there for exactly this reason.
I wonder why $| is on? must have forgotten to localize $| setting somewhere.
anyway, attached is a patch against current cvs - fixes and a few
filtering subrequest tests. note that the patch does not mention the
removal of xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer
needed, so I guess you should remove that file by hand before compiling.
craig - note that this patch affects the autogenerated code, so in order
to get it to work you'll need to apply it, then run make realclean, perl
Makefile.PL, etc.
and you forgot to add to the patch a new file
#t/htdocs/filter/subrequest.txt
core subrequest
regarding new tests, do you mind calling them:
out_str_subreq_core
out_str_subreq_perl
since 'sub' is too confusing, or even better:
out_str_subreq_default
out_str_subreq_modperl
since these correspond to the SetHandler settings.
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
however, removing that logic causes api/lookup_uri2.t to fail, but I suspect this is an issue with puts() rather than the subrequest mechanism - changing puts() to print() makes everything work just fine. does puts() write directly to the wire, bypassing filters? Sorry, but that's cheating ;) rputs() never flushes data, print() flushes if $| == 1; ah, ok, that's the difference. So there is no problem with the r-main logic in mpxs_ap_run_sub_req, it's there for exactly this reason. no, there is definitely something wrong. someplace :) if I'm in a filter and call sub-run (which is what mod_include essentially does), mod_perl is silently passing along the data I'm in the middle of filtering. so, if the filter sees datatagdata and wants to substitute something for tag via a subrequest, it won't work - mpxs_ap_run_sub_req is flushing tag along before the filter gets the chance to decide about the data. as I said, nowhere in any of the module shipped with core do I find logic like this - mod_include and mod_cgi both seem to call ap_run_sub_req without flushing the main data stream (though mod_include does split the stream and send the data _prior to the tag_ off). I don't see why mod_perl needs to behave differently in this respect, but if flushing is required for other reasons I can't see, making it a tacit part of $sub-run seems the wrong solution since it goes against the intent of output filters. and you forgot to add to the patch a new file #t/htdocs/filter/subrequest.txt core subrequest yes, sorry. or even better: out_str_subreq_default out_str_subreq_modperl since these correspond to the SetHandler settings. will do. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote: the problem is with the r-main logic in mpxs_ap_run_sub_req. with that logic, what ends up happening is that the data currently being operated on is explicity flushed. this is bad within a (streaming) filter where you are expected to call $f-print yourself, as the data is sent without your permission (you may be operating on it or not want to send it at all). it also seemed to cause infinite loop in my tests because the filter was seeing the same data over and over again. That's is the problem with streaming filters. Nothing indicates to mod_perl whether the currently executed filter is a streaming filter or not, in fact I think you can mix and match both methods in the same filter. So $f-print is not expected, really. What you are right about is that mpxs_ap_run_sub_req should flush only if run from the non-filter handler, and do nothing if run from the filter handler. I have somewhere a prototype for the new API which tells what phase we are in, but it's possible that there is a more efficient way to tell the difference. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Geoffrey Young wrote: [...] as I said, nowhere in any of the module shipped with core do I find logic like this - mod_include and mod_cgi both seem to call ap_run_sub_req without flushing the main data stream (though mod_include does split the stream and send the data _prior to the tag_ off). I don't see why mod_perl needs to behave differently in this respect, but if flushing is required for other reasons I can't see, making it a tacit part of $sub-run seems the wrong solution since it goes against the intent of output filters. but that's how it works in mp1, no? Are you required to flush any data before issuing a subrequest? If I remember correctly you aren't. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
