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
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
[ANNOUNCE] OpenInteract 1.99_00, first 2.0 beta
I am happy to announce the first beta of OpenInteract 2.0, 1.99_00. This is a major rewrite of the OpenInteract web application framework with substantial feature enhancements. A few highlights: * Runs under more environments than Apache/mod_perl 1.x since the request and response responsibilities are divided up * No separate repository of packages, each website stands on its own * Task-oriented management framework to make creating websites, creating and installing packages, installing SQL and other jobs much easier. * An app server no longer demands your full URL-space so you can deploy it under a location (e.g., http://www.mysite.com/OI2/) and have all actions respond and rewrite URLs properly. * Lots of changes to make package development easier. While it should be a fairly solid release this is still a beta. It's only been tested on a couple of databases, only on Linux and on 5.8.0. It should still work on the same systems as OI 1.x but there's always that X factor... OpenInteract 1.99_00 has been released to both CPAN and the Sourceforge area [1]. You can browse the full (and growing) set of documentation online [2] and follow the status at the OpenInteract wiki site [3]. I'd love to talk with people at YAPC::NA about OI2 and would be happy to initiate a BOF if there's enough interest. Thanks! Chris [1] http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.99_00.tar.gz?download [2] http://openinteract.sourceforge.net/docs/oi2/ [3] http://openinteract.sourceforge.net/cgi-bin/twiki/view/OI/ -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
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
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
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: 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) /
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: 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-
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-
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
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) /
Re: [PATCH] Apache::DBI - AutoCommit => 1 and begin_work
Patrick Mulvany wrote:
Hi,
Came accross an issue when trying to reduce creation of handles on a site.
Currently Apache::DBI makes the assumption that it AutoCommit => 1 then the handle does not need cleaning up. This is not neccessariliy true as begin_work switches of the AutoCommit for one transaction.
To be safe the handle should always be cleaned up otherwise next time it is requested it may be mid transaction.
Not sure who has access to the CVS tree but here is a patch for that case.
Tested against MP1.
Looks like you have posted a reversed patch. change the order of the files
when you create the diff.
Also CC Ask so he won't miss it.
--- DBI/DBI.pm 2003-06-10 12:20:06.0 +
+++ DBI/DBI.pm 2003-06-10 12:02:07.0 +
@@ -87,9 +87,10 @@
}
# this PerlCleanupHandler is supposed to initiate a rollback after the script has finished if AutoCommit is off.
-my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
+# however cleanup can only be determined at end of handle life as begin_work may have been called to temporarily turn off AutoCommit.
+#
# TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and Apache->can('push_handlers')) {
+if(!$Rollback{$Idx} and Apache->can('push_handlers')) {
print STDERR "$prefix push PerlCleanupHandler \n" if $Apache::DBI::DEBUG > 1;
Apache->push_handlers("PerlCleanupHandler", \&cleanup);
# make sure, that the rollback is called only once for every
--
__
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
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: is anybody using mp2 in production?
Thanks for all the long and short success stories. It's good to see that mod_perl 2.0 is alive and kicking ;) We have a special location for success stories on perl.apache.org: http://perl.apache.org/outstanding/sites.html http://perl.apache.org/outstanding/success_stories/index.html If you want your story to be added there please post it here supplying this information: URL: Title: Contact Person: Traffic: (hits/day/month/whatever) Success Story: __ 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: Compling mod_perl as a static module....(shared=max)
Forrest Aldrich wrote: 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. The workaround is to list the wanted modules explicitly rather than using 'max'? Patches for mod_perl's build to do the right thing are very welcome. __ 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?
I'm using mp2 with Template::Toolkit for a number of production sites on NetBSD. Apart from it whinging at test time, it seems just fine :) Carl
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: 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
Test please ignore
Mail server crashed... Testing...
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: 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: Simple DAV Server?
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... :( ) See this URL for more info: http://www.webdav.org/mod_dav/install.html#complex speeves cws
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: 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=en&lr=&ie=UTF-8&threadm=b7fpt9%24q9a%241%40agate.berkeley.edu&prev=/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....
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: 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....
Ged, This seems to have done the trick, in-so-far-as the configure process... it now reports: + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.27_01-dev + id: Perl/v5.8.0 (freebsd) [/usr/local/bin/perl] + adjusting Apache build environment + enabling Perl support for SSI (mod_include) However, I wonder if this will affect anything else, especially other things that require DSO support. ? What does --enable-shared=max imply to Apache... Thanks, Forrest At 02:55 PM 6/10/2003, Ged Haywood wrote: Hi there, On Tue, 10 Jun 2003, Forrest Aldrich wrote: > 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. Try taking out --enable-shared=max 73, Ged.
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: Site running mod_perl
Hi Ged, > Are you able to give us any numbers for the improvements, even > if they are approximate? When we were using plain CGI: Page view: 3.5 million / mo Load average: 0.6 - 1.2 mod_perl PerlRun: Page view: 4 million / mo Load average: 0.2 - 0.5 I couldn't find the benchmark result on requests/sec, but I remember it was around 4 times faster when running mod_perl PerlRun.
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
Re: Compling mod_perl as a static module....
Hi there, On Tue, 10 Jun 2003, Forrest Aldrich wrote: > 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. Try taking out --enable-shared=max 73, Ged.
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". Did anyone 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. Since the messages in error.log are 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 Canada mailto: [EMAIL PROTECTED]http://www.dymaxion.ca
Re: Site running mod_perl
Hello there, On Wed, 11 Jun 2003, Batara Kesuma wrote: > Find Job! http://www.find-job.net is the biggest computer and internet > related employment site in Japan. > [snip] > The speed improvement is significant, and the CPUs load > average are lower than when we were running plain CGI. Thank you! Are you able to give us any numbers for the improvements, even if they are approximate? 73, Ged.
[PATCH] Apache::DBI - AutoCommit => 1 and begin_work
Hi,
Came accross an issue when trying to reduce creation of handles on a site.
Currently Apache::DBI makes the assumption that it AutoCommit => 1 then the handle
does not need cleaning up. This is not neccessariliy true as begin_work switches of
the AutoCommit for one transaction.
To be safe the handle should always be cleaned up otherwise next time it is requested
it may be mid transaction.
Not sure who has access to the CVS tree but here is a patch for that case.
Tested against MP1.
Hope it helps
Paddy
--- DBI/DBI.pm 2003-06-10 12:20:06.0 +
+++ DBI/DBI.pm 2003-06-10 12:02:07.0 +
@@ -87,9 +87,10 @@
}
# this PerlCleanupHandler is supposed to initiate a rollback after the script has
finished if AutoCommit is off.
-my $needCleanup = ($Idx =~ /AutoCommit[^\d]+0/) ? 1 : 0;
+# however cleanup can only be determined at end of handle life as begin_work may
have been called to temporarily turn off AutoCommit.
+#
# TODO - Fix mod_perl 2.0 here
-if(!$Rollback{$Idx} and $needCleanup and Apache->can('push_handlers')) {
+if(!$Rollback{$Idx} and Apache->can('push_handlers')) {
print STDERR "$prefix push PerlCleanupHandler \n" if $Apache::DBI::DEBUG > 1;
Apache->push_handlers("PerlCleanupHandler", \&cleanup);
# make sure, that the rollback is called only once for every
pgp0.pgp
Description: PGP signature
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
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
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: 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
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Today at 9:46am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote:
SB>
SB> Actually it was Sunday (future!) and it's winter (past?) here in
SB> Melbourne ;)
I figured we were a few continents away.
SB>
SB> Then, if it's indeed your globally installed Apache::Filter and not
SB> the local one, dump @INC (in the same place) to see whether the global
SB> path comes before the local one.
SB>
Apache::Filter is indeed the globally installed one as evidenced by:
Apache::Filter
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/Apache/Filter.pm
at /home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm
line 15.
Here's what @INC looks like:
/home/haroon/src/build/modperl-2.0/Apache-Test/lib
/home/haroon/src/build/modperl-2.0/lib
/home/haroon/src/build/modperl-2.0/t/response
/home/haroon/src/build/modperl-2.0/t/protocol
/home/haroon/src/build/modperl-2.0/t/preconnection
/home/haroon/src/build/modperl-2.0/t/hooks
/home/haroon/src/build/modperl-2.0/t/filter
/home/haroon/src/build/modperl-2.0/t
/home/haroon/src/build/modperl-2.0/t/htdocs/testdirective/perlmodule-vh
/home/haroon/src/build/modperl-2.0/t/htdocs/testdirective/main
/home/haroon/src/build/modperl-2.0/t/
/home/haroon/src/build/modperl-2.0/t/lib/perl
/home/haroon/src/build/modperl-2.0/blib/lib
/home/haroon/src/build/modperl-2.0/blib/arch
Apache-Test/lib
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl at
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm
line 16.
I used the following diff to gather this diagnostic output:
===
--- t/filter/TestFilter/in_init_basic.pm9 May 2003 03:33:37 -
1.2
+++ t/filter/TestFilter/in_init_basic.pm10 Jun 2003 14:46:33 -
@@ -11,6 +11,11 @@
use base qw(Apache::Filter);
+BEGIN {
+warn "Apache::Filter $INC{'Apache/Filter.pm'}";
+warn join "\n", @INC;
+}
+
use Apache::Const -compile => qw(OK M_POST);
use constant READ_SIZE => 1024;
What's next to try?
--
Haroon Rafique
<[EMAIL PROTECTED]>
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Tue, 2003-06-10 at 05:08, Mithun Bhattacharya wrote: > What exactly is broken in RedHat 8.0/9.0 - RedHat's build of perl, > perl's support for unicode or perl's support for locales ? Short answer: the Perl build is fine if you change the locale to what it was in previous version of Red Hat (en_US.ISO8859-1) or simply remove the UTF8 part. My understanding is that setting locale to UTF8 makes it try to open everything as a UTF8 document, but not everything is one. It causes problems for Java and Konsole too apparently. It could simply be that Perl's handlling of UTF8 is broken, but I didn't want UTF8 in the first place so putting LANG back to what it was before seems like a reasonable fix to me. More here: http://twiki.org/cgi-bin/view/Codev/UsingPerl58OnRedHat8 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 - Perrin
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: [mp2] win2000 + Apache::DBI + Oracle
--- Stas Bekman <[EMAIL PROTECTED]> 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.
I'm using DBD::ODBC to connect. I should have
mentioned that in the original post!
My main concern was that my application was moving
very slowly when it had to call Oracle. But thanks to
you guys I realized that the Apache::DBI call needs to
be called before DBI!! RTFM. Now my app is suddenly a
lot faster!!
Here's what's in my startup.pl file:
use Apache2 ();
use Apache::DBI ();
Apache::DBI->connect_on_init($dsn, $user, $pass,
\%h);
use ModPerl::Util ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';
use APR::Table ();
use Apache::compat ();
use ModPerl::Registry ();
use CGI ();
use CGI::Carp ();
use CGI::Application ();
use HTML::Template ();
$Apache::DBI::DEBUG = 2;
1;
Here's my httpd.conf with mod_perl LoadModule:
LoadFile "C:/Perl/bin/perl58.dll"
LoadModule perl_module modules/mod_perl.so
PerlOptions +Parent
PerlInterpMaxRequests 1
PerlInterpStart 1
PerlInterpMax 1
PerlRequire "C:/Apache2pl/conf/startup.pl"
Here's the error log immediatly after startup and
calling one web page ($dbh->trace(1) and
$Apache::DBI::DEBUG):
[Tue Jun 10 08:24:21 2003] [notice] Parent: Created
child process 2060
[Tue Jun 10 08:24:23 2003] [notice] Child 2060: Child
process is running
2060 Apache::DBI PerlChildInitHandler
2060 Apache::DBI need ping: yes
2060 Apache::DBI new connect to
'st1 st1 st1 AutoCommit=1 PrintError=1 RaiseError=1'
[Tue Jun 10 08:24:24 2003] [notice] Child 2060:
Acquired the start mutex.
[Tue Jun 10 08:24:24 2003] [notice] Child 2060:
Starting 100 worker threads.
2060 Apache::DBI need ping: yes
2060 Apache::DBI new connect to
'st1 st1 st1 AutoCommit=1 PrintError=1 RaiseError=1'
DBI 1.35-ithread dispatch trace level set to 1
-> DBI->Apache::DBI::connect(DBI:ODBC:st1, st1,
)
<- FETCH('Name')= 'ODBC' ('Name' from cache) at
DBI.pm line 67
2060 Apache::DBI need ping: no
2060 Apache::DBI already connected to
'st1 st1 st1 AutoCommit=1 PrintError=1 RaiseError=1'
<- STORE('RaiseError' 1)= 1 at DBI.pm line 615
<- STORE('PrintError' 1)= 1 at DBI.pm line 615
<- STORE('AutoCommit' 1)= 1 at DBI.pm line 615
<- connect= Apache::DBI::db=HASH(0x110779c)
<- STORE('dbi_connect_closure' CODE(0x10e3380))= 1
at DBI.pm line 632
<- STORE('LongReadLen' 22000)= 1 at CCCS.pm line
403
<- prepare('SELECT DISTINCT CONTENT_ID,
STANDARD_ID, STANDARD FROM tblCCCS WHERE CONTENT_ID =
? ORDER BY STANDARD_ID')= DBI::st=HASH(0x10e3278) at
CCCS.pm line 99
<- execute('3')= -1 at CCCS.pm line 100
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- fetch= [ '3' '1' '(Reading) All students will
understand and apply the knowledge of sounds, letters,
and words in written English to become independent and
fluent readers, and will read a variety of materials
and texts with fluency and comprehension.' ] row1 at
DBI.pm line 1682
1 <- fetchrow_hashref= HASH(0x1107910)3keys row1 at
DBI.pm line 1682
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- FETCH('NAME')= [ 'CONTENT_ID' 'STANDARD_ID'
'STANDARD' ] at DBI.pm line 1682
2 <- fetch= undef row5 at DBI.pm line 1682
1 <- fetchrow_hashref= undef row5 at DBI.pm line
1682
-> DBI->Apache::DBI::connect(DBI:ODBC:st1, st1,
)
<- FETCH('Name')= 'ODBC' ('Name' from cache) at
DBI.pm line 67
2060 Apache::DBI need ping: no
2060 Apache::DBI already connected to
'st1 st1 st1 AutoCommit=1 PrintError=1 RaiseError=1'
<- STORE('RaiseError' 1)= 1 at DBI.pm line 615
<-
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
What exactly is broken in RedHat 8.0/9.0 - RedHat's build of perl, perl's support for unicode or perl's support for locales ? I dont think the LANG variable is wrong as such is it ? I have to currently upgrade a couple of production servers running mod_perl and I am finding it difficult to decide between choosing a old/possible becoming unsupported but functional RedHat 7.3 and RedHat 9.0 with a possibly broken perl or some issues with perl 5.8 which I am not able to comprehend. Mithun --- Perrin Harkins <[EMAIL PROTECTED]> wrote: > Just a thought: did you fix the locale on that machine? Most of CPAN > won't compile on Red Hat 8 and 9 because of the broken UTF8 locale > setting they have. If you haven't already, edit /etc/sysconfig/i18n > and > change LANG="en_US.UTF-8" to LANG="en_US.ISO8859-1". That fixed many > mysterious things for me. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
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=en&lr=&ie=UTF-8&threadm=b7fpt9%24q9a%241%40agate.berkeley.edu&prev=/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: 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: 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.
