Re: [mp2] win2000 + Apache::DBI + Oracle
On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? - Perrin
Re: [mp2] win2000 + Apache::DBI + Oracle
Perrin Harkins wrote: On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? I think you are right. I was thinking about pooling across threads. If somebody can give it a try and report back (use debug mode to see what happens) that would be the simplest check. connect_on_init() should probably be not used. __ 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: Compling mod_perl as a static module....
The configure process goes through and shows that it's selected a DSO compilation, and that's not what I want so I just stopped it. The configure process complains about PERL_SSI and says it cannot include that with a DSO, etc. But again, I'm not trying to compile a DSO. I wonder if some other flag might set the make process to assume DSO builds? Forrest At 07:51 PM 6/9/2003, Ged Haywood wrote: Hello again, On Mon, 9 Jun 2003, Forrest Aldrich wrote: Referring back to my original post, it with the options I specified, the compile process still insists on compiling mod_perl as a DSO. Even if I explicitly set USE_DSO=0 -- I wonder if one of the other flags (like EVERYTHING=1) is triggering the DSO compile. No, I often compile statically with EVERYTHING=1. I don't think we're dealing with a full deck here. Are you quite sure that you're looking at the right executable after you build it? Check the timestamp. Try running it by giving the full pathname and the -l switch for example /home/forrest/src/apache_1.3.27/src/httpd -l or change to the directory that the exewcutable is in and say ./httpd -l (you can do both without being root) and see if the output includes a line mod_perl.c which tells you that mod_perl is compiled in (i.e. compiled statically). 73, Ged.
Re: Perl Run and Load Average
Hi all, Thank you for all your suggestions. Now the load average on my server is back to normal again :) It is around 0.2 - 0.5 now with the same pageviews. Ok not just normal, actually the load average is even lower than when I was using CGI (which was around 0.6 - 1.2). The changes I made: reduced MaxClients value from 300 to 150 in httpd.conf, preloaded CGI module by putting it inside startup.pl, unloaded some DSO modules that I didn't use. This article really helps me a lot: http://perl.apache.org/docs/1.0/guide/performance.html --bk
Re: is anybody using mp2 in production?
... ... I'd be interested in what you thought of the switch after going live, we were never sure (but getting there now) if we should have started with MP2 or not, never got a chance to see MP1 in action. We have found MP1 to be stable. (We had a lot of issues with PerlFreshRestart I had to patch MP1 to get around this issue. Otherwise there were no problems) I'm not very sure about MP2. We want to play around with MP2 on development as much as possible before going live. I'm also worried about the differing opinion on perl-ithreads (especially after reading http://groups.google.com/groups?dq=hl=enlr=ie=UTF-8threadm=b7fpt9%24q9a%241%40agate.berkeley.eduprev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.perl.moderated%26start%3D25) We plan to get mp2 working on development test the performance. Once we find it's stable on dev., it's time to go live. Sreeji __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
Re: [mp2] win2000 + Apache::DBI + Oracle
On Tue, Jun 10, 2003 at 04:27:17PM +1000, Stas Bekman wrote: Perrin Harkins wrote: On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU = winnt MPM = no forking, only threads = Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? I think you are right. I was thinking about pooling across threads. If somebody can give it a try and report back (use debug mode to see what happens) that would be the simplest check. connect_on_init() should probably be not used. connect_on_init() pushs to a list of connection strings to start on child creation. childinit should be called as a PerlChildInitHandler (not sure when MP2 handles these) but is this called per thread? Note to me: Fix issue of cleanup not correctly rolling back when an AutoCommit in on but begin_work has been called. Could be causing side effects in following reuse of handle. Similar issues may exist with overriding other default parameters from within a handle. my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0; looks like being the offending line. I will extend my handle limiting patch to cover this and resubmit to here. Hope it helps Paddy pgp0.pgp Description: PGP signature
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Today at 12:38am, PH=Perrin Harkins [EMAIL PROTECTED] wrote: PH On Mon, 2003-06-09 at 09:55, Haroon Rafique wrote: PH Now onto serious stuff. /usr/bin/perl here is the system-wide perl PH install that came bundled with Redhat. PH PH Just a thought: did you fix the locale on that machine? Most of CPAN PH won't compile on Red Hat 8 and 9 because of the broken UTF8 locale PH setting they have. If you haven't already, edit /etc/sysconfig/i18n PH and change LANG=en_US.UTF-8 to LANG=en_US.ISO8859-1. That fixed PH many mysterious things for me. PH PH - Perrin Hi Perrin, I don't think locale is the issue here. I say that because by installing a new perl in my home directory (I don't have root access to this machine, just developer access), I'm able to install 1.99_10-dev and pass 100% of the tests. I think the issue is that I asked the admin to install 1.99_08 a couple of months ago. Now 1.99_10-dev won't pass make test properly, as we suspect, it is finding the older 1.99_08 mod_perl. Just for completeness, I checked for the LANG variable, env | grep LANG LANG=en_US so more than likely that is not the issue. Stas suggested some steps to take in his latest reply. I will post my findings as a reply to his email. -- Haroon Rafique [EMAIL PROTECTED]
Re: modules that work with both modperl1 and 2
Stas Bekman wrote:
speeves wrote:
Stas Bekman wrote:
[...]
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
This source code was the saving grace for me. If we could add the link
to:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
into the documentation, that would be great.
hat did it!!! Thank you so much for your patience and help with all
that I am working on here. After I test these changes on modperl 1
tomorrow, I should be able to upload it to CPAN, and it will be ready
for prime-time... (fingers crossed ;) )
Based on your porting experience if you have additions/corrections to
these two documents:
http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/2.0/user/porting/compat.html
please submit those here.
BTW, I have updated the info on the constants:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
__
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
Also, it would probably be nice to have a link from:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version
to
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
that would help the porter to understand the overall picture of what
needs to be done to allow the single code-base to work with both
mod_perls...
Finally, I found that the PAUSE server did not recognize the $VERSION
number, (returned as undef), until I placed it above the BEGIN {} block
as following:
package Apache::AuthNetLDAP;
use strict;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK);
use Net::LDAP;
use mod_perl;
require Exporter;
@ISA = qw(Exporter AutoLoader);
# Items to export into callers namespace by default. Note: do not export
# names by default without a very good reason. Use EXPORT_OK instead.
# Do not simply export all your public functions/methods/constants.
@EXPORT = qw(
);
$VERSION = '0.21';
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 = ($mod_perl::VERSION = 1.99);
# test for the version of mod_perl, and use the appropriate libraries
BEGIN {
if (MP2) {
require Apache::Const;
require Apache::Access;
require Apache::Connection;
require Apache::Log;
require Apache::RequestRec;
require Apache::RequestUtil;
Apache::Const-import(-compile = 'HTTP_UNAUTHORIZED','OK');
} else {
require Apache::Constants;
Apache::Constants-import('HTTP_UNAUTHORIZED','OK');
}
}
# Preloaded methods go here.
#handles Apache requests
sub handler {
...
}
Thanks again for all of your help! If you know of any modules that need
porting in a like manner, feel free to contact me and I would be happy
to help out.
speeves
cws
Site running mod_perl
Hi, Find Job! http://www.find-job.net is the biggest computer and internet related employment site in Japan. And I just want to let you know that our site now is running on mod_perl completely. We have around 75000 registered users and 1 registered companies. Our pageview is around 4 million per month. Our whole system was running under plain CGI written in Perl, until recently we changed it to mod_perl with HTML::Template templating system. The speed improvement is significant, and the CPUs load average are lower than when we were running plain CGI. --Batara Kesuma
error running mysql test
Dear all I had installed mysql. Things comes right till i tried to execute perl run-all-tests i got the following error /usr/local/bin/perl: relocation error: /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so: undefined symbol: mysql_init Any ideas? hamid
Re: error running mysql test
On Tue, 10 Jun 2003, Abd El-Hameed Mohammed wrote: Date: Tue, 10 Jun 2003 19:36:30 +0300 From: Abd El-Hameed Mohammed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: error running mysql test Dear all I had installed mysql. Things comes right till i tried to execute perl run-all-tests i got the following error /usr/local/bin/perl: relocation error: /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so: undefined symbol: mysql_init Any ideas? hamid Um...how is this related to mod_perl? Probably you should send your question to a MySQL list? ky
perlwarn break our CGIs
Title: Message Hi, all, We are at a stage of converting CGI to run under mod_perl. In order to help debugging our CGI code under mod_perl, we turned PerlWarn On. Unfortunately, after turning on PerlWarn, our CGIs that already run well under mod_perl get broken with the message "page cannot be displayed" on browser. The error.log does not show the corresponding error for the request, but list tons of warnings such as "Use of uninitialized value in split at /perl_root/lib/Cwd.pm line 103 during global destruction". Didanyone encounter the similar symptom? I thought global destruction only happens when the server is shutdown or a child server dies, but these messages came out upon the very first request since the server restarts, and makes no sense too me. After I turn off PerlWarn, our CGIs that were broken start to work again. Sincethe messages in error.logare only warning message, how come the page is broken. Does PerlWarn outputs anything to places other than error.log? Welcome any help. June Young June Young, Software Development bus: (902)422-1973 x144Dymaxion Research Ltd., 5515 Cogswell St., fax: (902)421-1267Halifax, Nova Scotia, B3J 1R2 Canadamailto: [EMAIL PROTECTED]http://www.dymaxion.ca
Installing Apache::AuthCookie
Hi, I'm running into a problem during the make test while installing the current version of Apache::AuthCookie. I'm not sure where to go. I looked at tests 10 and 15: Test 10 is supposed to fail: and it did Test 15 is supposed to be FORBIDDEN Should I go ahead and do make install? Jay I installed apache, mod_ssl... via apt-get install Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_perl/1.26 conf meir:/usr/local/cpan/build/Apache-AuthCookie-3.04# make test TEST_VERBOSE=1 t/httpd -f `pwd`/t/httpd.conf PERL_DL_NONLAZY=1 PORT=8228 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/per /5.6.1 -I/usr/share/perl/5.6.1 -e 'use Test::Harness qw(runtests $verbose); $v rbose=1; runtests @ARGV;' t/*.t t/real1..17 ok 1 ok 2 ok 3 ok 4 code: 302 ok 5 ok 6 ok 7 ok 8 ok 9 code: 401 not ok 10 Result: Connection: close Date: Tue, 10 Jun 2003 19:16:26 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_ erl/1.26 Content-Type: text/html; charset=iso-8859-1 Client-Date: Tue, 10 Jun 2003 19:16:26 GMT Client-Peer: 127.0.0.1:8228 Client-Response-Num: 1 Client-Transfer-Encoding: chunked Client-Warning: Missing Authenticate header Title: 401 Authorization Required X-Pad: avoid browser bug Expected: Location: /docs/protected/get_me.html Set-Cookie: Sample::AuthCookieHandler_WhatEver=programmer:Heroo; path=/ Code: 302 ok 11 ok 12 ok 13 Location: /docs/authany/get_me.html Set-Cookie: Sample::AuthCookieHandler_WhatEver=some-user:mypassword; path=/ Code: 302 ok 14 code: 200 not ok 15 Result: Connection: close Date: Tue, 10 Jun 2003 19:16:26 GMT Accept-Ranges: bytes ETag: 1a4039-a8-3ce29115 Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_ erl/1.26 Content-Length: 168 Content-Type: text/html Last-Modified: Wed, 15 May 2002 16:47:17 GMT Client-Date: Tue, 10 Jun 2003 19:16:26 GMT Client-Peer: 127.0.0.1:8228 Client-Response-Num: 1 Title: Congratulations Expected: ok 16 ok 17 FAILED tests 10, 15 Failed 2/17 tests, 88.24% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/real.t 172 11.76% 10 15 Failed 1/1 test scripts, 0.00% okay. 2/17 subtests failed, 88.24% okay. make: *** [run_tests] Error 11
EXPAT?
I did a test compile of mod_perl as a DSO, and ran into a problem with
another module I use (mod_dav). It requires EXPAT to be defined in the
ap_auto_config.h file. However, I found this in the mod_perl Makefile.PL:
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
if(is_ssl() !~ /stronghold/i) {
$cmd .= --disable-rule=EXPAT;
}
So, I'm not certain about how to rectify this with mod_dav.
Re: Compling mod_perl as a static module....(shared=max)
This is what I found: --enable-shared=max tells the script to include mod_so (needed for dynamic modules, or DSOs) and compile all the standard modules as dynamic modules So I will need to find some way around this for the other things I rely upon. but it seems that mod_perl's configuration should behave accordingly if you tell it NOT to use DSO. Forrest
Re: Compling mod_perl as a static module....
At 02:55 PM 6/10/2003, Ged Haywood wrote: [ ... ] Try taking out --enable-shared=max [ ... ] This caused the compilation process to bomb: ./libhttpd.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/local/lib/perl5/5.8.0/mach/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `SaveError': DynaLoader.o(.text+0x60): undefined reference to `Perl_vmess' DynaLoader.o(.text+0x8b): undefined reference to `Perl_sv_2pv_flags' /usr/local/lib/perl5/5.8.0/mach/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_load_file': DynaLoader.o(.text+0x128): undefined reference to `Perl_sv_2pv_nolen' /usr/local/lib/perl5/5.8.0/mach/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_find_symbol': DynaLoader.o(.text+0x38d): undefined reference to `Perl_sv_2pv_nolen' /usr/local/lib/perl5/5.8.0/mach/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_install_xsub': DynaLoader.o(.text+0x4b8): undefined reference to `Perl_sv_2pv_nolen' DynaLoader.o(.text+0x521): undefined reference to `Perl_sv_2pv_nolen' /usr/local/lib/perl5/5.8.0/mach/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `boot_DynaLoader': DynaLoader.o(.text+0x68d): undefined reference to `Perl_sv_2pv_flags' DynaLoader.o(.text+0x6d2): undefined reference to `Perl_get_sv' DynaLoader.o(.text+0x70e): undefined reference to `Perl_get_sv' DynaLoader.o(.text+0x747): undefined reference to `Perl_sv_2pv_flags' ./libhttpd.so: undefined reference to `Perl_require_pv' ./libhttpd.so: undefined reference to `Perl_get_cv' ./libhttpd.so: undefined reference to `Perl_get_av' ./libhttpd.so: undefined reference to `Perl_call_pv' ./libhttpd.so: undefined reference to `Perl_sv_pvn_force_flags' ./libhttpd.so: undefined reference to `Perl_safesysfree' ./libhttpd.so: undefined reference to `Perl_sv_catpvn_flags' ./libhttpd.so: undefined reference to `Perl_eval_sv' ./libhttpd.so: undefined reference to `Perl_sv_catsv_flags' ./libhttpd.so: undefined reference to `Perl_sv_setsv_flags' ./libhttpd.so: undefined reference to `Perl_get_hv' ./libhttpd.so: undefined reference to `Perl_eval_pv' ./libhttpd.so: undefined reference to `Perl_call_sv' ./libhttpd.so: undefined reference to `Perl_call_method' ./libhttpd.so: undefined reference to `Perl_PerlIO_close' ./libhttpd.so: undefined reference to `PerlIO_findFILE' ./libhttpd.so: undefined reference to `Perl_save_destructor_x' ./libhttpd.so: undefined reference to `PerlIO_open' ./libhttpd.so: undefined reference to `Perl_safesysmalloc' gmake[3]: *** [libhttpd.ep] Error 1 gmake[3]: Leaving directory `/usr/local/src/apache/apache_1.3.27/src' gmake[2]: *** [build-std] Error 2 gmake[2]: Leaving directory `/usr/local/src/apache/apache_1.3.27' gmake[1]: *** [build] Error 2 gmake[1]: Leaving directory `/usr/local/src/apache/apache_1.3.27' gmake: *** [apaci_httpd] Error 2
Re: is anybody using mp2 in production?
Hi, sorry my english i development one big ecommerce system in mp2 and i very happy is fast and stable Sreeji K Das wrote: ... ... I'd be interested in what you thought of the switch after going live, we were never sure (but getting there now) if we should have started with MP2 or not, never got a chance to see MP1 in action. We have found MP1 to be stable. (We had a lot of issues with PerlFreshRestart I had to patch MP1 to get around this issue. Otherwise there were no problems) I'm not very sure about MP2. We want to play around with MP2 on development as much as possible before going live. I'm also worried about the differing opinion on perl-ithreads (especially after reading http://groups.google.com/groups?dq=hl=enlr=ie=UTF-8threadm=b7fpt9%24q9a%241%40agate.berkeley.eduprev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.perl.moderated%26start%3D25) We plan to get mp2 working on development test the performance. Once we find it's stable on dev., it's time to go live. Sreeji __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
Re: Compling mod_perl as a static module....
Okay, here's what I've done which seems to have worked with a statically-linked mod_perl. o untar all distributions into a working directory o ./configure apache with all the usual options I use (i have a script that has this): ./configure --with-perl=/usr/local/bin/perl --enable-module=rewrite --enable-module=include --enable-module=info --enable-module=usertrack --server-gid=nogroup --suexec-docroot=/usr/local/apache/htdocs --enable-module=most --enable-module=auth_db --enable-module=mmap_static --enable-shared=max --enable-module=ssl --enable-rule=SHARED_CORE --add-module=src/modules/dosevasive/mod_dosevasive.c --activate-module=src/modules/perl/libperl.a o enter mod_ssl configure with apache o enter mod_ssl directory and configure with these makepl options: APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.27/src DO_HTTPD=0 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 o return to apache directory, re-run my configure script to activate the modules, build, and install. Doing an httpd -l shows this now: # /usr/apache/bin/httpd -l Compiled-in modules: http_core.c mod_so.c mod_dosevasive.c mod_perl.c suexec: disabled; invalid wrapper /usr/apache/bin/suexec (weird, I did a fresh install) So I'll be damned if building mod_perl is such a pain in the arse. I hope Apache2 and MP2 will have an easier approach (I'm waiting on Apache2 for it to stabilize). Ged, thoughts on this one? I of course still need to test mod_perl with something - will try my go at installing RT or something simple (open to suggestions). Forrest
Re: Compling mod_perl as a static module....
Hi Forrest, On Tue, 10 Jun 2003, Forrest Aldrich wrote: seems to have worked [snip] # /usr/apache/bin/httpd -l Compiled-in modules: http_core.c mod_so.c mod_dosevasive.c mod_perl.c [snip] :) building mod_perl is such a pain [snip] thoughts on this one? It isn't usually such a pain. Without getting an account on the box or looking at the entire build process it's difficult to see why you've had such trouble. You do seem to be putting a lot of stuff in there, and I wonder if it wouldn't have been simpler to start with a very cut-down configuration. Well, no matter, you have a statically linked mod_perl now. Can I suggest that you create another account on the box and rebuild httpd from scratch in exactly the same way to make sure you have all the information you need to repeat it? I of course still need to test mod_perl with something - Did you not run 'make test' ? will try my go at installing RT or something simple (open to suggestions). Lynx? Telnet? What are you going to use mod_perl for? 73, Ged.
Re: Compling mod_perl as a static module....
Hi there, On Tue, 10 Jun 2003, Forrest Aldrich wrote: I wonder if this will affect anything else, especially other things that require DSO support. ? Have you got the Eagle Book? You need --enable-module=so in your configure arguments to put mod_so into Apache, mod_so allows Apache to load shared objects. What does --enable-shared=max imply to Apache... make as much as possible as shared objects, the idea being to make the resulting binary smaller. It won't save any memory if you run it with tons of modules loaded, so it's probably more trouble than it's worth. Which is my opinion of DSO generally. I always build static if I can. On your EXPAT question, I'm not sure what you found is relevant. You might want to check the List archives for discussions about EXPAT, not so long ago it seemed to come up quite a lot. 73, Ged.
Re: modules that work with both modperl1 and 2
Shannon Eric Peevey wrote:
Stas Bekman wrote:
This source code was the saving grace for me. If we could add the link
to:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
into the documentation, that would be great.
No need to, I've already merged it into the docs:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
Also, it would probably be nice to have a link from:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version
to
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
that would help the porter to understand the overall picture of what
needs to be done to allow the single code-base to work with both
mod_perls...
done, thanks for the suggestion.
Finally, I found that the PAUSE server did not recognize the $VERSION
number, (returned as undef), until I placed it above the BEGIN {} block
as following:
Yes, not before the BEGIN block, but before any other occurence of the string
VERSION. Some claim that this is a bug, others that it's a feature. Depends on
who you ask.
BTW, to verify your module that its version is parsable correctly by PAUSE,
you don't need to submit it to pause, but use:
perl -MExtUtils::MakeMaker -le 'print MM-parse_version(shift)' 'file'
as explained at:
http://pause.perl.org/pause/query?ACTION=pause_04about#conventions
I've added a note about this to the porting docs.
package Apache::AuthNetLDAP;
[...]
$VERSION = '0.21';
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 = ($mod_perl::VERSION = 1.99);
[...]
Thanks again for all of your help! If you know of any modules that need
porting in a like manner, feel free to contact me and I would be happy
to help out.
I think there are quite a few modules that need porting. Just go to CPAN pick
one and go with it. Probably first contact the author so you don't step on
their toes.
I'm planning on adding more docs as I doing porting myself, and if others find
new tricks and useful additions to the existing docs don't hesitate to post
them here, just like Shannon did. Which is *very* helpful! Thank you Shannon!
I'm also thinking about creating several modules to ease the porting, I'll
post more on this when I'll get around writing some first prototypes.
__
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] win2000 + Apache::DBI + Oracle
Patrick Mulvany wrote: On Tue, Jun 10, 2003 at 04:27:17PM +1000, Stas Bekman wrote: connect_on_init() should probably be not used. connect_on_init() pushs to a list of connection strings to start on child creation. childinit should be called as a PerlChildInitHandler (not sure when MP2 handles these) but is this called per thread? No, PerlChildInitHandler is called when a process starts up. Apache provides no hooks for threads startup. http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlChildInitHandler __ 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: EXPAT?
Forrest Aldrich wrote:
I did a test compile of mod_perl as a DSO, and ran into a problem with
another module I use (mod_dav). It requires EXPAT to be defined in the
ap_auto_config.h file. However, I found this in the mod_perl Makefile.PL:
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
if(is_ssl() !~ /stronghold/i) {
$cmd .= --disable-rule=EXPAT;
}
So, I'm not certain about how to rectify this with mod_dav.
That comment is not very clear. Should it be disabled only for SSL servers,
but not stronghold? That change was made at:
revision 1.157
date: 2000/04/21 05:56:19; author: dougm; state: Exp; lines: +2 -1
--disable-rule=EXPAT is passed to Apache's configure to avoid
XML::Parser conflicts
PR:
Obtained from:
Submitted by:
Reviewed by:
I suggest that you search the mailing list archives for --disable-rule=EXPAT
around this date, find the discussion leading to this change and this will
clarify thinigs.
If this change was made only for ssl servers, this might work:
ndex: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.213
diff -u -r1.213 Makefile.PL
--- Makefile.PL 5 Jun 2003 07:38:46 - 1.213
+++ Makefile.PL 11 Jun 2003 01:22:24 -
@@ -1033,7 +1033,8 @@
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
-if(is_ssl() !~ /stronghold/i) {
+my $is_ssl = is_ssl();
+if($is_ssl $is_ssl !~ /stronghold/i) {
$cmd .= --disable-rule=EXPAT;
}
But I'm not sure if that's the case.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: is anybody using mp2 in production?
Sreeji K Das wrote: That's cool is yet another example of the power of mod_perl. And you're right about the documentation. I was blown away by the amount of docs. available at perl.apache.org; thanks to all the hard work of Stas Beckman !! ;) We had been using mod_perl had been having a very stable site for quite a long time. Now we're planning to shift to mod_perl-2. I could get everything compiled, but mp2 bombed while parsing our config. files. I've reported this bug (search for PerlSection + recurse/recursive) and hopefully some1 is working on it ;-) Anyway, I plan to spend my weekends reading mod_perl code and see if I can fix this issue. Once Philippe releases mod_perl 1.28 he will get back to work on this issue. We had some discussion on this issue on the dev list. And Philippe has proposed several solutions to this problem. So 1.99_10 should have this fixed. __ 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: Authentication design
Jonathan Gardner wrote: It sounds like you are mixing HTTP-level authentication with application-level authentication. Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r-user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are login-only, and those are protected by an authz handler that makes sure $r-user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
Simple DAV Server?
I'm quite suprised at the limited amount of custom DAV server uses. I mean, here's a protocol for editing content over HTTP, which to me screams as an ideal solution for, say, editing full HTML content within a DB/CMS. I mean, I've been working as Technical Support at a uni for Web Services, and there seems to be these two sides; on one side are the advocates of a file-based system, using any range of HTML editing tools to edit your content (and preferrably some server-side templating for maintaining common look and feel). On the other side is a content management system, which is heavily template structured, with content being chunks of text (or HTML) edited using web forms, or custom editors (eg; in Java). One way of obtaining the advantages of both of these techniques would be to use a DB-driven CMS, but edit the content chunks using a DAV editor. I'd like to write a simple DAV interface to a DB myself, but I'm looking for existing perl modules to make things easier, but I haven't found a heck of a lot along these lines. Most Perl Dav things seem to be more client focussed. Of those that are for server stuff, they seem either overly complicated (eg; Apache::DAV), or fairly immature, and still emphasising filesys structures (eg; HTTP::DAVServer). I suppose what I'm after is an implementation which is easily adaptable to editing data within a DB. I'm considering implementing enough of the HTTP methods to be functional myself, but would rather not bite off more than I have time to chew if there's a nicer solution. Any suggestions? -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Administrator - [EMAIL PROTECTED] : | IT Services- Murdoch University | | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
undefined symbol: PL_stack_base
Hi, I can't seem to find what's going wrong, I'm trying to run mod_perl on Gentoo, but I get this: # /etc/init.d/apache start * Starting apache... Syntax error on line 58 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libperl.so into server: /etc/apache/extramodules/libperl.so: undefined symbol: PL_stack_base [ !! ] I looked extensively through Google and mailing list archives, and can't seem to find what the problem is. Please note that I have some extensive experience with Apache+mod_perl, but I can't seem to pinpoint what's going wrong. Any idea where to look? I have recompiled everything (perl, libperl, Apache, mod_perl, several perl modules) but it did'nt solve the problem. Any idea how I can find out what fucks up? If I can't I'll try compiling by hand but I wanted to avoid this. I have: gcc 3.3 glibc 2.3.2-r1 apache-1.3.27-r4
Re: Authentication design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 03 June 2003 18:59, Michael L. Artz wrote: I am trying to design/implement a fairly simple authentication scheme using cookies and such, but wanted to air my design questions before I run into too many issues. It sounds like you are mixing HTTP-level authentication with application-level authentication. While HTTP authentication is pretty cool, unfortunately it is user-unfriendly. You won't find hardly any big sites that use it for this reason. Instead, they use application-level authentication. This is like Slashdot's login box, where everything is handled with cookies and HTML forms. The idea here is that there is a hash attached to each user who browses the website. You store variables and information in that hash. When they come back, you restore the hash they used last time. There are several ways to do this. The best practice is to give the user a cookie that is a number -- usually an MD5 of something like time, PID of the server process, and other random bits of data. The idea is you want a unique, unguessable session id. Then, on your end, you create a table in a database or something like a database. You stoe the session id linked to the session data. But how to store a hash in a database? You serialize it with Data::Dumper. The algorithm on each page is pretty simple. If the user is browsing a page where you might want to use session data, just check for the session id cookie value. If it is not there, you have a choice: do you set a cookie for all users when they fail to show a session id cookie, or do you set it only under special circumstances (like when logging in)? Either way, you'll want to check to see if the cookie was properly set, and at least warn the user that cookies need to be enabled. The way I like to do this is to set the cookie, then redirect them to a cookie check page. The cookie check page will see if the cookie was set. If not, it prints out a warning and explains your privacy policy. The idea is to convince the user to change his browser setting to accept your cookies. If the cookie was successfully set, you redirect back to where you came from. Once you get the session id, you grab the session data, unserialize it, and begin using it. When you are done, remember to serialize the data, and store it in the database. With a little thought, you can probably tweak the system so that it does exactly what you need. Don't be afraid of exploring MySQL or PostgreSQL for storing the session data. If you are only going to store session IDs, I would suggest you explore MySQL. If you may get serious about the database, and one day, design a huge database, you are better off starting off with PostgreSQL. Enjoy! - -- Jonathan Gardner [EMAIL PROTECTED] (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+5eKLWgwF3QvpWNwRAoWdAKCc1HFa+jxbuiO5+lySY7ViKK7cBQCaA2m5 f7F/121dBpe7ULqyBszvxCI= =T9Cv -END PGP SIGNATURE-
Re: font width to pixel width in perl - but also offtopic in javascript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 04 June 2003 06:46, Martin Moss wrote: Hi All, I'm sure this can't be an issue that hasn't been tackled, but I couldn't find anything in the archives so:- I'm trying to find a way in which I can calculate the pixel width of a string in a given font. I'm doing this to feed a javascript file, so I am also looking at doing this in javascript also. I would go back and re-read the specifications for HTML and CSS, and think about the design philosophy one more time. Do you really want to control the user's experience to that degree? What happens when they want to make the fonts bigger or smaller? What if they assign a stylesheet that puts all fonts in an unexpected font face, where the measurements just don't mean the same thing? What if they are viewing a translated page via babelfish? What if they are blind and are hearing an aural rendering of your page, or feeling a braille printed version? How will your page appear to Googlebot and other bots? In short, you have little to no control over what *exactly* the user sees, and this is for a good reason. You create content, and perhaps suggest a way it should be rendered via CSS. They decide how it should actually appear, and they may or may not honor your idea of what it should look like. Trying to violate this will only lead to difficulty. - -- Jonathan Gardner [EMAIL PROTECTED] (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+5eTXWgwF3QvpWNwRAqpnAKDl0dV4Xozh2UaXBYZNcy3vS8l9IQCg3LbV bVhvH3QxFVNil/vnuo7sNo8= =OPFi -END PGP SIGNATURE-
Site running mod_perl
Hi, Find Job! http://www.find-job.net is the biggest computer and internet related employment site in Japan. And I just want to let you know that our site now is running on mod_perl completely. We have around 75000 registered users and 1 registered companies. Our pageview is around 4 million per month. Our whole system was running under plain CGI written in Perl, until recently we changed it to mod_perl with HTML::Template templating system. The speed improvement is significant, and the CPUs load average are lower than when we were running plain CGI. --Batara Kesuma
Re: Simple DAV Server?
On Wednesday 11 June 2003 05:13, you wrote: Trevor Phillips wrote: I'm quite suprised at the limited amount of custom DAV server uses. I mean, here's a protocol for editing content over HTTP, which to me screams as an ideal solution for, say, editing full HTML content within a DB/CMS. I think the problem with webDAV, as a protocol through which to manipulate web pages, lies in the fact that it is difficult to manipulate dynamic content without sending the rendered content to the client, instead of the true source. (Phew!! That was long winded... :P ) The only way that I have found to do it, is to either break the web server, (ie publish to a web server that doesn't have the dynamic language engine installed), or... (I don't know of another solution that works... :( ) I'm aware of the issue, but don't see it as a show-stopper. You could use an alternate URL to direct DAV handling to a different handler. ie; To view: /path/to/content/ To edit: /dav/path/to/content/ ... where the module associated with /dav/ knows how to retrieve the raw content (be it files, or a map to DB-stored content) of the normal path. When viewing the content, you could provide links to the edit version of the URL. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Administrator - [EMAIL PROTECTED] : | IT Services- Murdoch University | | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: Authentication design
On Tue, 2003-06-10 at 21:47, Michael L. Artz wrote: I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? It is a good way to do it. The confusing bit is your use of $r-user, which is generally part of HTTP basic auth. Cookie-based auth schemes generally just use an ID in the cookie to tie into server-side data. I'm not certain it won't work to use $r-user, but I don't see the point when you already have a unique identifier in the cookie. - Perrin
Re: undefined symbol: PL_stack_base
Nicolas MONNET wrote: Hi, I can't seem to find what's going wrong, I'm trying to run mod_perl on Gentoo, but I get this: # /etc/init.d/apache start * Starting apache... Syntax error on line 58 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libperl.so into server: /etc/apache/extramodules/libperl.so: undefined symbol: PL_stack_base [ !! ] Are you sure that you compiled with the same perl that gets loaded? ldd /etc/apache/extramodules/libperl.so will show you which libperl.so (this time perl's) it's linked against. Then you check that libperl.so to see if it has the symbol defined: nm /path/to/CORE/libperl.so | grep PL_stack_base My guess is that you may have more than one perls on your machine and mod_perl picks the wrong library at the startup. I looked extensively through Google and mailing list archives, and can't seem to find what the problem is. Please note that I have some extensive experience with Apache+mod_perl, but I can't seem to pinpoint what's going wrong. Any idea where to look? I have recompiled everything (perl, libperl, Apache, mod_perl, several perl modules) but it did'nt solve the problem. Any idea how I can find out what fucks up? If I can't I'll try compiling by hand but I wanted to avoid this. I have: gcc 3.3 glibc 2.3.2-r1 apache-1.3.27-r4 -- __ 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: Authentication design
Perrin Harkins wrote: I'm not certain it won't work to use $r-user, but I don't see the point when you already have a unique identifier in the cookie. Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. -Mike
Problem with mod_ssl and mod_perl on Windows
Hi, I was trying to setup Apache (with mod_perl and mod_ssl) on Windows ME, and I had a weird problem. Before the problem, let me talk about more about some details. I have installed Apache from http://perl.apache.org/dist/win32-bin/. I installed the perl 5.6 version, which is perl-win32-bin.exe. THis file contains Perl 5.6 and Apache 1.3.27. It also contains mod_perl and mod_ssl. After installation I did not use the perl that the package came with. I used my ActivePerl (which is 5.6), because I already installed lots of packages there and there is no difference anyway. In my previous installation of Perl (activeperl) I had mod_perl installed, however that mod_perl was not for eapi, so I removed it and installed the one for eapi from the canadian web site. I installed mod_perl-eapi.ppd. http://theoryx5.uwinnipeg.ca/ppmpackages/ So anyway, I had mod_perl setup for perl and apache. I configured my apache so that it listens both on 443 for secure connections and 80 too. Now, let me talk about how I use mod_perl for my site. I use AuthCookieURL for authentication and authorization. What I do is essentially, get the user's name and password in a page and then authorize the user for the other pages. This works fine, until I used mod_ssl for secure connections. When I tested the apache, it works just fine for port 80. However, it doesn't work very well, on port 443. The second request to the https port crashes Apache. Now as far I as I understood the second request crashes the child process. I am not sure about the internals of Apache. What happens is that, the first request is always fine, only the second request crashes the server. The child process dies, Apache parent process creates the child process again and then everything works fine again until the next 2 requests, except of course I have to press Ok to shutdown the Apache's error box. That is the error does prevent me using Apache for secure connections. Anyway, I spent quite some time on it, and I tracked down the problem to the following. There are two problems, and let me describe how I solved the first one and how I couldn't solve the second one. The first one was that, when the user first requests a page, he/she has to login. In this phase, the AuthCookieURL module shows the custom login page. This happens by a redirection, using custom_message or something like that. I forgot its name now. Anyway, this method as you know receives a return value (in this case it is FORBIDDEN) and a messsage or a relative url. Normally it is a relative url, like /public/login.pl. This is the default way I use this module, and it normally works fine. However, in https requests the second request causes Apache crash, unless I change this method so that it actually returns the output as string. That is instead of a redirection to login.pl, I send the login page in the second argument using the custom_error method. If I make this change, Apache doesn't crash anymore. Ok, now the next step is fixing the authorization phase. Assuming that the user already supplied the correct user/password, he/she can enter to the site. However once he/she enters, the user can not make two subsequent requests without crashing the Apache. I tracked down this problem to the return value of the authorize method of AuthCookieURL. If this method returns OK, which means that the user can enter, it crashes, if the method returns DECLINED, it doesn't crash, but it certainly doesn't show anything either, cause it says Forbidden , you don't have access message. I couldn't fix this problem. It just seems that there is no way around this. What I found in the ssl.log is that, basically OpenSSL crashes with I/O errors. It says like expected to read 5 bytes The error somehow indicate to me that, maybe I added the modules in the wrong way. I have changed them, but again, it didn't work. That is I added mod_perl last, mod_ssl last and so on, but the net result was the same. Overall, the problem seem to be somewhat related with the phases. If anybody can help me to fix the problem, I would be thankful. Thanks __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Re: Authentication design
On Tue, 2003-06-10 at 23:43, Michael L. Artz wrote: Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: - Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID. The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. - Perrin
