RE: [ANNOUNCE] The New "mod_perl" logo - results now in...
:: I actually like the logo without the underscore. I don't :: think an underscore is very collaborative with art. The "_" :: has always been irritating me a little. I don't see any reason why the underscore can't be incorporated "discreetly". I had an idea that we could have the "dp" together (like in the new logo) with a small underscore directly beneath them. :: I know that there is history and nostalgia involved here but :: dropping an underscore at least in the logo is a nice :: evolution IMHO. The whole "mod_" just happens to be the :: original Apache naming convention for modules, I believe, :: and let's not forget that the Apache folks never thought :: they would get the kind of success they have. Given the :: choice, I don't think they would have stuck with this kind :: of naming convention. This doesn't matter. The simple fact is, the name is mod_perl. It's established, known and the author has stated quite clearly that it will not change. :: The underscore really belongs to the "C/C++" language and :: isn't really so much of a standard in Perl. True, "Perl", :: "Apache" and "mod_perl" are all children of "C/C++" but they :: should have some independence - they are in their :: adolescence now (if not even adults). If the underscore "belongs" anywhere, then it also belongs in Perl. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ <-- Temporarily off-line http://wypug.digital-word.com/
RE: [ANNOUNCE] The New "mod_perl" logo - results now in...
:: I agree here. But then, TMTOWTDI is a big part of Perl :: culture. I suggest a democratic solution: present the logo :: and the favorite logo-based button as "the" logo and button. :: Then, also present a page which has some alternate buttons :: on it, including the two winners of the present contest. :: Make the page with the official logo and button easy to find :: so users will see it first. But an important part of any "product" is its brand. I personally believe that the logo/button/banner should be uniform throughout, with one font and one colour scheme. One area where we do have creative license is with banners - providing that the recognised mod_perl logo still features within. :: Since there was a landslide winner I would say there is :: probably no need for alternate logos although it may be :: interesting for historical reasons (the Google logo archives :: do it the right way, in my opinion: :: http://www.google.com/stickers.html). The logos at http://beverley2.digital-word.com/mod_perl/ will remain online "forever" for historical/nostalgic purposes. :: DR>I really like the :: new logo, and in fact I voted for it. However, I :: DR>just realized that the logo uses "modperl", whereas :: mod_perl's name :: DR>is "mod_perl", with the underscore. Does anyone else see :: this as a :: DR>problem? :: :: BM>It's a graphic design so I don't see that it needs to follow the :: BM>Apache module naming convention exactly... It's a design -- it :: BM>doesn't have to be accurate to the name. :: :: I agree with both these statements. I think the issue isn't :: that the design must follow the name, but that users often :: get confused between the two, and if the design doesn't :: follow the name, that confusion will certainly be :: exacerbated. Of course, this is probably not a big problem :: as long as the conventional term is used in the :: documentation and website and as long as "modperl" on Google :: leads to the mod_perl site. I think the logo should feature an underscore, however it's used. We are promoting a brand, a product... its name needs to be consistent wherever it's used - how else will we get pointy-haired bosses to recognise it? :: I might also point out that any mod_perl hostnames come out :: as modperl (since underscores are not allowed in hostnames) :: and that modperl is often used as a directory name even :: though underscores ARE allowed in filenames. I don't think that's relevant at all. People name their files and directories in whatever way suits them. And hostnames, well that's just a convention we can do nothing about and, thus, a non-issue. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ <-- Temporarily off-line http://wypug.digital-word.com/
RE: [ANNOUNCE] The New "mod_perl" logo - results now in...
:: A thought - what about putting the suggestion of an :: underscore by putting bars underneath the d and p of :: "modperl"? Just a suggestion to Michael as presumably he is :: revisting the design for the buttons. I had a similar idea - a single bar under the "dp" yet keeping the "dp" together. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ <-- Temporarily off-line http://wypug.digital-word.com/
Re: loss of shared memory in parent httpd (2)
Eric Frazier wrote: > Hi, > > This may be totaly ignorate crap, but I noticed this when I was reading the > ps man page on BSD 4.5 about sys/proc.h flags > > This one I noticed.. > > P_SYSTEM 0x00200System proc: no sigs, stats or swapping > > > Could this mean what I think it means? That a process with this flag set, > won't be swaped out?? I've spent some time with our friend google and here is what I came up with (it's hard to search for things which can be called in many different ways): I've searched for P_SYSTEM and it seems that it's a *BSD thing and also when you set it you don't get sigs delivered. e.g. see the discussion here: http://mail-index.netbsd.org/tech-kern/1998/09/08/0004.html There is also: madvise(2) - give advice about use of memory Has anybody tried to use it? Can this help? There is some discussion here: http://lists.insecure.org/linux-kernel/2001/Oct/0877.html Here is another observation and explanation of the swapping/mem unsharing phenomena on linux. http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.3/0324.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.3/0307.html Finally, apparently it's relatively easy to patch the linux kernel to enabling mlock for non-root processes: http://www.uwsg.iu.edu/hypermail/linux/kernel/9608.2/0280.html > At 03:55 PM 3/12/02 +0100, Elizabeth Mattijsen wrote: > >>Oops. Premature sending... >> >>I have two ideas that might help: >>- reduce number of global variables used, less memory pollution by lexicals >>- make sure that you have the most up-to-date (kernel) version of your >>OS. Newer Linux kernels seem to be a lot savvy at handling shared memory >>than older kernels. >> >>Again, I wish you strength in fixing this problem... >> >> >>Elizabeth Mattijsen >> >> > > http://www.kwinternet.com/eric > (250) 655 - 9513 (PST Time Zone) > > > -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [ANNOUNCE] PHP::Session
Now PHP::Session 0.05 with save/destory implementation is going on its way to CPAN. 0.05 Mon Mar 18 16:36:27 JST 2002 * added Boolean type (ext/var.h in PHP source code) 0.04 Fri Mar 15 16:14:32 JST 2002 * added destroy() 0.03 Fri Mar 15 16:01:35 JST 2002 * added session ID validation * implemented save() At Thu, 14 Mar 2002 17:40:28 +0900, Tatsuhiko Miyagawa wrote: > > Announcing new module: PHP::Session. > > This module enables you to read / write (write is not yet implemented > though) PHP4-builtin session files from Perl. Then you can share > session data between PHP and Perl, without changing PHP code, which > may be a hard work for us Perl hackers. > > This is something you'll never want to do, but imagine the cases where > you should co-work with PHP coders, or take over another company's PHP > code. -- Tatsuhiko Miyagawa
RE: :Parallel error
What does: perl -MCPAN -e shell > install LWP::Parallel do for you? I don't use the specific module in question, but by using CPAN for installing it usually tells you what dependancies there might be. Given that this module is in CPAN :) Regards // Nicolai -Original Message- From: Parag R Naik [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 8:35 PM To: [EMAIL PROTECTED] Subject: LWP::Parallel error I get the following error . can any body help .i install ParallelUserAgent-2.51.tar.gz does it require some additional modules . Can't locate object method "new" via package "LWP::Parallel::Protocol::http::Socket" Regards Parag R Naik Phone : 5093100(off) Tough times dont last for a long tough people always do. To send secure email get my certificate from :http://parag.freeshell.org/parag2.p7b
Re: Trouble w/ LWP during mod_perl install
Hi Stas, I am currently running w/ openssl-0.9.6b. ALso, I tried your suggestion: perl -MCPAN -eshell cpan> install URI HTML::HeadParser LWP make test still could not find LWP... But thanks anyways. John Kolvereid --- Stas Bekman <[EMAIL PROTECTED]> wrote: > John Kolvereid wrote: > > Hi Ade, > >I am sending the errs as an attachment. > Thanks. > > It helps to actually *look* at the build log: > > > Will configure via APACI > ... > > o ssl_module uses ConfigStart/End > > + SSL interface: mod_ssl/2.8.5 > > + SSL interface build type: DSO > > + SSL interface compatibility: enabled > > + SSL interface experimental code: disabled > > + SSL interface conservative code: disabled > > + SSL interface vendor extensions: disabled > > + SSL interface plugin: Built-in SDBM > > + SSL library path: /usr/local/ssl > > + SSL library version: SSLeay 0.9.0b > 29-Jun-1998 > > Error: OpenSSL VERSIONS BELOW 0.9.3 ARE NO LONGER > SUPPORTED. > > Hint: Use OpenSSL version 0.9.3 or higher! > > hint, hint: install openssl 0.9.3 or higher! > > > Checking for LWP::UserAgent..failed > > Can't locate URI.pm in @INC (@INC contains: ./lib > /usr/lib/perl5/5.00503/i386-linux > /usr/lib/perl5/5.00503 > /usr/lib/perl5/site_perl/5.005/i386-linux > /usr/lib/perl5/site_perl/5.005 .) at (eval 2) line > 3. > > BEGIN failed--compilation aborted at > /usr/lib/perl5/site_perl/5.005/LWP/UserAgent.pm line > 108. > > > > The libwww-perl library is needed to run the test > suite. > > Installation of this library is recommended, but > not required. > > > > Checking for HTML::HeadParserfailed > > Can't locate HTML/HeadParser.pm in @INC (@INC > contains: ./lib /usr/lib/perl5/5.00503/i386-linux > /usr/lib/perl5/5.00503 > /usr/lib/perl5/site_perl/5.005/i386-linux > /usr/lib/perl5/site_perl/5.005 .) at Makefile.PL > line 1154. > > > > The HTML-Parser package is needed (by libwww-perl) > to run the test suite. > > install URI and HTML::HeadParser packages. > > Most likely you've installed an RPM or a similar > package of libwww-perl > without installing its prerequisites. > > Do: > > perl -MCPAN -eshell > cpan> install URI HTML::HeadParser LWP > > need to specify explicitly since LWP is already > installed. > > and 'make test' should work. > > > > _ > Stas Bekman JAm_pH -- Just > Another mod_perl Hacker > http://stason.org/ mod_perl Guide > http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://ticketmaster.com > http://apacheweek.com > http://singlesheaven.com http://perl.apache.org > http://perlmonth.com/ > __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
Re: Trouble w/ LWP during mod_perl install
John Kolvereid wrote: > Hi Stas, >I am currently running w/ openssl-0.9.6b. ALso, I > tried your suggestion: > > perl -MCPAN -eshell > cpan> install URI HTML::HeadParser LWP > > make test still could not find LWP... Nope, according to your original report (the relevant part of it is attached below) it did find LWP, but it couldn't load its LWP::UserAgent because it couldn't locate URI and HTML::HeadParser. Now can you check that they are installed in the same location as LWP? What do you get from running these? find /usr/lib/perl5 | grep URI.pm find /usr/lib/perl5 | grep UserAgent.pm find /usr/lib/perl5 | grep HeadParser.pm assuming that all your perl libs are installed under /usr/lib/perl5 as in your report can you run %perl -MURI -e1? >>>Checking for LWP::UserAgent..failed >>>Can't locate URI.pm in @INC (@INC contains: ./lib >>> >>/usr/lib/perl5/5.00503/i386-linux >>/usr/lib/perl5/5.00503 >>/usr/lib/perl5/site_perl/5.005/i386-linux >>/usr/lib/perl5/site_perl/5.005 .) at (eval 2) line >>3. >> >>>BEGIN failed--compilation aborted at >>> >>/usr/lib/perl5/site_perl/5.005/LWP/UserAgent.pm line >>108. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Trouble w/ LWP during mod_perl install
Hi John, On Sun, 17 Mar 2002, John Kolvereid wrote: > Thanks for sticking in there w/ me. :) > There are a great many options and the number > of combinations is awesome. True, but there's no point worrying about the number of combinations, you need to worry about setting things up the way you want them. > Only 1 is correct, It's not really like that. (You just have to decide how you want things to be set up...:) > I ran the build again for the mod_perl and apache using > APACHE_PREFIX and APACHE_SRC and SSL_BASE. When finished I tried > the apachectl startssl and got the same LoadModule error as before. I really think you should forget ssl for the moment until you get a grip on compiling and configuring Apache and mod_perl. And PLEASE don't run apachectl until you know what it's going to do. You can start Apache without using a script. > I tried the httpd -l and mod_so.c WAS present. To be certain I did > a 'which httpd'. It was using the one in /usr/sbin but that's not > new, it is dated Oct 19 2000. That's not the one you're running. 'which' tells you what will be used if you call the binary directly without giving the full path to the binary, but if you try to run it with 'apachectl' then you could be using a different one. Why not just delete it, or rename it if you want to keep it? Keep a notebook to record the changes you make so that you don't forget what you've changed. In my last message I asked you to run the binary by calling it with the full path name. Don't rely on the path in your environment by running a binary without the full path name at this stage, you'll only confuse yourself even more. > Moreover, the httpd.conf in the conf directory is dated Mar 4. When you do 'make install' the scripts won't overwrite your existing configuration. If you delete, rename or move the conf directory and then re-install you'll get a new httpd.conf. > There is one dated Mar 17 (today) named httpd.conf.default but it > does not include any reference to mod_perl. If you compile mod_perl in statically it doesn't have to have a loadmodule directive for mod_perl - in fact it shouldn't have one. You need a completely new httpd.conf which is installed at the time you build Apache and mod_perl. But do please read it when you've finally made it, because there are as you have said lots of things you need to think about. > What should I try next. All the things I've said in my last three messages. They *will* work if you clean everything up like I said, RedHat 6.2 really has no problems with Apache and mod_perl. 73, Ged.
RE: Trouble w/ LWP during mod_perl install
John: Try the following: $ perl Makefile.PL \ USE_APXS=1 \ EVERYTHING=1 \ WITH_APXS=/usr/local/apache/bin/apxs $ make $ make test $ make install This will build mod_perl as a DSO outside of the Apache source tree using the Apache APXS option - . Let us know. RB -Original Message- From: John Kolvereid [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 8:03 PM To: OCNS Consulting; Ade Olonoh Cc: mod_perl Mailing List Subject: RE: Trouble w/ LWP during mod_perl install Hi RB, Here is the configuration I tried: perl Makefile.PL \ APACHE_PREFIX=/usr/local/apache \ APACHE_SRC=/home/ssl/apache_1.3.22 \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 Both w/ and w/o the APACHE_PRFIX and APACHE_SRC lines. The errors are attached. Please advise. Thanks. --- OCNS Consulting <[EMAIL PROTECTED]> wrote: > John, > > Consider building mod_perl as a DSO outside of > Apache. Look for the > section title "Build mod_perl as DSO outside Apache > source tree via > APXS" in the file INSTALL.apaci. > > This should work for you. Let us know. > > RB > > -Original Message- > From: John Kolvereid [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 17, 2002 6:09 PM > To: Ade Olonoh > Cc: mod_perl Mailing List > Subject: Re: Trouble w/ LWP during mod_perl install > > > Hi Ade, > I followed your suggestion and went to > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > Most of their steps I had followed before. Now I > tried to config mod_perl w/ the following config > file > as they had suggested: > perl Makefile.PL \ > APACHE_PREFIX=/usr/local/apache \ > APACHE_SRC=/home/ssl/apache_1.3.22 \ > SSL_BASE=/usr/local/ssl \ > APACI_ARGS='--enable-module=ssl, \ > --enable-shared=ssl, \ > --enable-module=proxy, \ > --enable-shared=proxy, \ > --prefix=/usr/local/apache, \ > --enable-module=rewrite' \ > DO_HTTPD=1 \ > USE_APACI=1 \ > EVERYTHING=1 > > when I try to do a 'make' I get errors such as > *** No rule to make target 'all'. Stop > I can get it to make and make install if I leave out > the APACI_ARGS, but then it doesn't know how to > create > Apache w/ ssl. > Yes I do have an existing Apache which I created > w/ > mod_ssl. It has been working fine. My goal is to > add > mod_perl. Any suggestions. Please advise. > > Thanks. >John Kolvereid > > --- Ade Olonoh <[EMAIL PROTECTED]> wrote: > > > Then I try running > > > /usr/local/apache/bin/apachectl startssl > > > > > > Unfortunately I get the msg: > > > Syntax error on line 206 of > > > /usr/local/apache/conf/httpd.conf: > > > Invalid command 'LoadModule', perhaps > > mis-spelled or > > > defined by a module not included in the server > > > > > > configuration > > > could not locate Module SSL (line 206 > > httpd.conf) > > > > Are you installing on top of an existing Apache > > directory? In other > > words, was /usr/local/apache/conf/httpd.conf > created > > by the install, or > > did it already exist before you built Apache? It > > looks like the conf > > file might expect Apache to have been built with > DSO > > support but it > > wasn't in actuality. > > > > In case you haven't seen this already, you might > > take a look at this > > guide to installing Apache with mod_perl and > > mod_ssl: > > > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > > > The options it suggests should work for you here. > > > > > > --Ade. > > > __ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
SVG version of logo
Animated version of the new mod_perl logo: http://take23.org/modperl.svg If you want a button, download it and change the width/height attributes to 100 x 22 (or smaller/larger as appropriate). -- <:->Get a smart net
RE: [ANNOUNCE] The New "mod_perl" logo - results now in...
Could you make it flaming? ;) > -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 17, 2002 12:31 PM > To: Jonathan M. Hollin > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [ANNOUNCE] The New "mod_perl" logo - results now in... > > > OK, here's my attempt at SVGing the logo. Works in Adobe's SVG viewer > (Linux and Windows). I'll work on animating it next (making > the cog spin). > > -- > > <:->Get a smart net >
RE: Trouble w/ LWP during mod_perl install
John: Consider installing the latest version of Apache 1.3.23. RB -Original Message- From: OCNS Consulting [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 8:53 AM To: John Kolvereid; Ade Olonoh Cc: mod_perl Mailing List Subject: RE: Trouble w/ LWP during mod_perl install John: Try the following: $ perl Makefile.PL \ USE_APXS=1 \ EVERYTHING=1 \ WITH_APXS=/usr/local/apache/bin/apxs $ make $ make test $ make install This will build mod_perl as a DSO outside of the Apache source tree using the Apache APXS option - . Let us know. RB -Original Message- From: John Kolvereid [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 8:03 PM To: OCNS Consulting; Ade Olonoh Cc: mod_perl Mailing List Subject: RE: Trouble w/ LWP during mod_perl install Hi RB, Here is the configuration I tried: perl Makefile.PL \ APACHE_PREFIX=/usr/local/apache \ APACHE_SRC=/home/ssl/apache_1.3.22 \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 Both w/ and w/o the APACHE_PRFIX and APACHE_SRC lines. The errors are attached. Please advise. Thanks. --- OCNS Consulting <[EMAIL PROTECTED]> wrote: > John, > > Consider building mod_perl as a DSO outside of > Apache. Look for the > section title "Build mod_perl as DSO outside Apache > source tree via > APXS" in the file INSTALL.apaci. > > This should work for you. Let us know. > > RB > > -Original Message- > From: John Kolvereid [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 17, 2002 6:09 PM > To: Ade Olonoh > Cc: mod_perl Mailing List > Subject: Re: Trouble w/ LWP during mod_perl install > > > Hi Ade, > I followed your suggestion and went to > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > Most of their steps I had followed before. Now I > tried to config mod_perl w/ the following config > file > as they had suggested: > perl Makefile.PL \ > APACHE_PREFIX=/usr/local/apache \ > APACHE_SRC=/home/ssl/apache_1.3.22 \ > SSL_BASE=/usr/local/ssl \ > APACI_ARGS='--enable-module=ssl, \ > --enable-shared=ssl, \ > --enable-module=proxy, \ > --enable-shared=proxy, \ > --prefix=/usr/local/apache, \ > --enable-module=rewrite' \ > DO_HTTPD=1 \ > USE_APACI=1 \ > EVERYTHING=1 > > when I try to do a 'make' I get errors such as > *** No rule to make target 'all'. Stop > I can get it to make and make install if I leave out > the APACI_ARGS, but then it doesn't know how to > create > Apache w/ ssl. > Yes I do have an existing Apache which I created > w/ > mod_ssl. It has been working fine. My goal is to > add > mod_perl. Any suggestions. Please advise. > > Thanks. >John Kolvereid > > --- Ade Olonoh <[EMAIL PROTECTED]> wrote: > > > Then I try running > > > /usr/local/apache/bin/apachectl startssl > > > > > > Unfortunately I get the msg: > > > Syntax error on line 206 of > > > /usr/local/apache/conf/httpd.conf: > > > Invalid command 'LoadModule', perhaps > > mis-spelled or > > > defined by a module not included in the server > > > > > > configuration > > > could not locate Module SSL (line 206 > > httpd.conf) > > > > Are you installing on top of an existing Apache > > directory? In other > > words, was /usr/local/apache/conf/httpd.conf > created > > by the install, or > > did it already exist before you built Apache? It > > looks like the conf > > file might expect Apache to have been built with > DSO > > support but it > > wasn't in actuality. > > > > In case you haven't seen this already, you might > > take a look at this > > guide to installing Apache with mod_perl and > > mod_ssl: > > > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > > > The options it suggests should work for you here. > > > > > > --Ade. > > > __ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
Latest version of mod_perl
Where's the latest snapshot of mod_perl? RB OCNS, Inc. [EMAIL PROTECTED]
RE: Latest version of mod_perl
Where's the homepage of perl.apache.org? It should say something about cvs.apache.org/snapshots/modperl ... Sorry for the sarcasm... but please... what effort did you do to find it yourself? Best regards Nicolai Schlenzig nicolai.schlenzig(at)got2get.net --- This mail does not reflect my company's oppinion on the subject in question but is my personal response and cannot be held against my company in any way. > -Original Message- > From: OCNS Consulting [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 3:13 PM > To: [EMAIL PROTECTED] > Subject: Latest version of mod_perl > > > Where's the latest snapshot of mod_perl? > > RB > OCNS, Inc. > [EMAIL PROTECTED] >
checking a site for ssl cert?
hello, kind of a long shot but does anyone know if its possible to check a site for ssl certificate information from a mod perl handler or perl script? thanks k
Perl 5.7.3 breaks mod_perl tied handles [PATCH]
I have been testing my mod_perl-1.26 applications under perl 5.7.3.
I have discovered that the tying of STDIN and STDOUT does not work.
This is caused by a change in the internals of the implementation
of tied handles in Perl. The following extract from the source
of Perl (pp_sys.c ll 764 ff) describes the change
methname = "TIEHANDLE";
how = PERL_MAGIC_tiedscalar;
/* For tied filehandles, we apply tiedscalar magic to the IO
slot of the GP rather than the GV itself. AMS 20010812 */
if (!GvIOp(varsv))
GvIOp(varsv) = newIO();
varsv = (SV *)GvIOp(varsv);
break;
I have got myself going by patching mod_perl as below. This
patch makes mod_perl work with 5.7.3, but, of course, stops it
working with 5.6.x. It is beyond my knowledge to make this patch
version dependent, as it needs to be.
*** /tmp/sccs.I.aOiqMon Mar 18 14:41:11 2002
--- perlio.cMon Mar 18 12:18:22 2002
***
*** 54,61
#define TIEHANDLE(name,obj) \
{ \
dHANDLE(name); \
! sv_unmagic((SV*)handle, 'q'); \
! sv_magic((SV*)handle, obj, 'q', Nullch, 0); \
}
#if 0
--- 54,61
#define TIEHANDLE(name,obj) \
{ \
dHANDLE(name); \
! sv_unmagic((SV*)GvIOp((SV*)handle), 'q'); \
! sv_magic((SV*)GvIOp((SV*)handle), obj, 'q', Nullch, 0); \
}
#if 0
--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED]Tel: +44 1223 334506, Fax: +44 1223 334679
Re: checking a site for ssl cert?
Kirk Rogers wrote: >hello, >kind of a long shot but does anyone know if its possible to check a site for >ssl certificate information from a mod perl handler or perl script? > >thanks >k > it's all exported into %ENV if you do: SSLOptions + StdEnvVars Issac
RE: checking a site for ssl cert?
What about a standalone CGI script? Is there some module or package I need acquire or is it also exported into %ENV? Thanks, K >-Original Message- >From: Issac Goldstand [mailto:[EMAIL PROTECTED]] >Sent: Monday, March 18, 2002 7:16 AM >To: [EMAIL PROTECTED] >Cc: modperl >Subject: Re: checking a site for ssl cert? > > >Kirk Rogers wrote: > >>hello, >>kind of a long shot but does anyone know if its possible to check >a site for >>ssl certificate information from a mod perl handler or perl script? >> >>thanks >>k >> >it's all exported into %ENV if you do: > >SSLOptions + StdEnvVars > > Issac > > >
2 httpd processes looping in SQL statement
Hi Team, new subscriber here hoping someone can help me out. I'm getting a weird behavior with Apache: after running for a while, always two httpd processes have to be restarted because they use up around 8% of CPU each. Does this ring a bell to anyone? The following are a truss output and gcore stack of one of the faulty process. The truss output shows a continuous looping: a read, 9 calls to sigaction and a write. The gcore stack shows the process deep in libperl.so. Any feedback would be appreciated - thank you - Andre. 4812/1: psargs: /usr/up/mms/tools/apache/bin/httpd 4812/1: read(5, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 524 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: write(5, "\0\01F02\0\0\0\0\0\0\0\0".., 24) = 24 4812/1: read(5, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 488 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 4812/1: new: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: old: hand = 0xFE8C7CB4 mask = 0xFFBFFEFF 0x1FFF 0 0 flags = 0x000C 4812/1: sigaction(SIGPIPE, 0xFFBEF3E8, 0xFFBEF4E8) = 0 ... current LWP ($lwp) is l@1 =>[1] __sigaction(0x0, 0xd652048, 0xffbef440, 0x4, 0x0, 0x1), at 0xff2168f4 [2] _setsighandler(0xfe8e529c, 0xd0, 0xffbef344, 0xfe8de000, 0xd, 0xffbef460), a t 0xfe8c8dfc [3] _sigaction(0xd, 0xffbef460, 0xffbef440, 0xd98958, 0xd, 0xfee7b52c), at 0xfe8 c8968 [4] Perl_rsignal(0xd, 0xfee82608, 0x80, 0x, 0x74, 0x74), at 0xfee7b5 2c [5] Perl_magic_setsig(0x47e19c, 0xfef18400, 0xfef17c00, 0x34, 0x435d18, 0xd), at 0xfee7ee90 [6] Perl_mg_set(0x47e19c, 0x210, 0x0, 0xdd210c, 0x7, 0x80803), at 0xfee7d03c [7] Perl_pp_sassign(0x47e19c, 0xfef18534, 0xfef18400, 0xfef18400, 0x4f6810, 0x4f 680c), at 0xfee8843c [8] Perl_runops_standard(0xfef18534, 0x0, 0xfef18400, 0x1, 0x0, 0xffbef74d), at 0xfee87dec [9] Perl_call_sv(0xfef18400, 0xfef18000, 0xfef18400, 0xfef18800, 0xfef18400, 0xf ef18000), at 0xfee35a20 [10] perl_call_handler(0x6d916c, 0xaac, 0x800, 0xb24, 0xc00, 0xca8), at 0xfee1a3 08 [11] perl_handler(0xfef1260c, 0xfef18808, 0xfef0b194, 0x0, 0x74, 0x74), at 0xfee 194c4 [12] ap_invoke_handler(0x6b7c20, 0x148394, 0x0, 0x0, 0x18, 0x18), at 0x5ac14 [13] process_request_internal(0x6b7c20, 0xfec3114c, 0xff31ae30, 0xffbef970, 0x4, 0x1), at 0x748bc [14] ap_process_request(0x6b7c20, 0x4, 0x6b7c20, 0xffbef9fc, 0xffbefa0c, 0x1b), at 0x74948 [15] child_main(0x1b, 0x680d0, 0x0, 0x0, 0x21860, 0x69e94), at 0x69c30 [16] make_child(0x17d670, 0x1b, 0x3c57292f, 0xff239164, 0xff239164, 0xffbefb10), at 0x69f2c [17] perform_idle_server_maintenance(0x, 0x134a, 0xe, 0x17d670, 0x146784 , 0x13883c), at 0x6a3e0 [18] standalone_main(0x1, 0xffbefd14, 0x165e24,
Re: [OT] checking a site for ssl cert?
IT's a feature of mod_ssl, not of mod_perl, so the answer is no, it does not need another module to be accessed by standalone perl. Issac Kirk Rogers wrote: >What about a standalone CGI script? Is there some module or package I need >acquire or is it also exported into %ENV? > >Thanks, >K > > >>-Original Message- >>From: Issac Goldstand [mailto:[EMAIL PROTECTED]] >>Sent: Monday, March 18, 2002 7:16 AM >>To: [EMAIL PROTECTED] >>Cc: modperl >>Subject: Re: checking a site for ssl cert? >> >> >>Kirk Rogers wrote: >> >>>hello, >>>kind of a long shot but does anyone know if its possible to check >>> >>a site for >> >>>ssl certificate information from a mod perl handler or perl script? >>> >>>thanks >>>k >>> >>it's all exported into %ENV if you do: >> >>SSLOptions + StdEnvVars >> >> Issac >>
Re: 2 httpd processes looping in SQL statement
Andre Terroux wrote: > Hi Team, new subscriber here hoping someone can help me out. I'm getting a > weird behavior with Apache: after running for a while, always two httpd > processes have to be restarted because they use up around 8% of CPU each. This is probably caused by a bug in your perl code. You should try to figure out what sort of request triggers it. Maybe you can add some logging to your application or use the MOD_PERL_TRACE feature to figure it out. - Perrin
Re: Perl 5.7.3 breaks mod_perl tied handles [PATCH]
Charles Jardine wrote:
> I have been testing my mod_perl-1.26 applications under perl 5.7.3.
>
> I have discovered that the tying of STDIN and STDOUT does not work.
Great work, Charles!
the output of 'diff -u' is a preffered format for patches :)
[snip]
> This
> patch makes mod_perl work with 5.7.3, but, of course, stops it
> working with 5.6.x. It is beyond my knowledge to make this patch
> version dependent, as it needs to be.
here is the one that works for all 5.x versions. Tested with 5.7.3 and
5.6.1.
Index: src/modules/perl/perlio.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perlio.c,v
retrieving revision 1.7
diff -u -r1.7 perlio.c
--- src/modules/perl/perlio.c 13 Jun 2001 21:27:51 - 1.7
+++ src/modules/perl/perlio.c 18 Mar 2002 15:48:39 -
@@ -51,12 +51,25 @@
#define dHANDLE(name) GV *handle = gv_fetchpv(name, TRUE, SVt_PVIO)
+#if (PERL_REVISION == 5 && PERL_VERSION < 7)
+
#define TIEHANDLE(name,obj) \
{ \
dHANDLE(name); \
sv_unmagic((SV*)handle, 'q'); \
sv_magic((SV*)handle, obj, 'q', Nullch, 0); \
}
+
+#else
+
+#define TIEHANDLE(name,obj) \
+{ \
+ dHANDLE(name); \
+ sv_unmagic((SV*)GvIOp((SV*)handle), 'q'); \
+ sv_magic((SV*)GvIOp((SV*)handle), obj, 'q', Nullch, 0); \
+}
+
+#endif
#if 0
#define TIED tied_handle
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Cookbook Chapter 4 online!
just in case anyone is interested, WebReference.com is hosting Chapter 4 from the mod_perl Developer's Cookbook starting today: http://www.webreference.com/programming/perl/cookbook/ this is in addition to chapters 1, 7, and 16 which are already available at our website (http://www.modperlcookbook.org). happy reading! --Geoff
Re: here is a good modperl question on perlmonk
On Tue, Mar 05, 2002 at 02:54:47PM -0800, Paul Lindner wrote: > On Tue, Mar 05, 2002 at 04:53:56PM -0600, Dave Rolsky wrote: > > On Tue, 5 Mar 2002, Medi Montaseri wrote: > > > > > My suggestion would be to install a Linux on your developer's PC and > > > keep with the distributed model. Now everyone can use a common web tree > > > and at integeration, bring all of them to a staging box, QC it and ship > > > it to production. > > > > Giving everyone their own Apache daemon, which uses their checked out tree > > of code, on a central dev server is really not a problem either. > > One other tip... write a small script (or modify apachectl) to start > apache with a port number matched to your unix UID. This keeps > developers from using clashing port numbers. > > httpd -c "Port $UID" -c "Listen $UID" > > etc.. (returning from spring break...) Just keep in mind that this won't work (afaik) on systems that need more than 16 bits for the uids. (Here at TAMU we are going that direction -- unified UIDs across all our unix boxes -- 80,000 people > 16 bits -- developers are part of those 80,000.) What I did was very similar except I created a `testserver' script that checks out the CVS tree, sets up the configs, and starts the server. After starting it, it lets the person know which port they can use -- I hard code that into the script for now (small group of developers -- < 10). The UID thing can also run into problems if the UID is below 1024 (several of ours are). But for small groups of users with all uids between 1024 and 65535, using the uid as the port can work most of the time (6000 won't work if X Windows is being used, for example). --jim
mod_perl does not see multipart POSTs
All, I am still trying to figure out why my setup of mod_perl does not have multipart POSTs. I rebooted my machine, and found that, whereas I reported before mod_perl would try to reload the page (which it should not but send out a text/plain attachment for download), it appears the script (running as a perl handler) does not see any of the multipart POST. Vanilla posts are not a problem, though. Even if the information being sent via multipart is _not_ a file to upload to the server, the information is lost in transit. Here is what is odd. The same scripts/modules unmodified and running as perl_cgi are okay. Multipart forms allow me to upload files, et cetera. In short, I am confident the problem is not with my programming. I am using the code snippet, POST2GET, to capture the one-time read of POST and storing as if it was retrieved via GET. Any ideas how to debug this? I REALLY REALLY would love some feedback. I would love to think that all my effort to stay away from M$ ASP are worth it -- esp. when I stand up to defend Perl, Apache, and mod_perl in an environment that is decidely M$-bent. Thanks! Ward
RE: Trouble w/ LWP during mod_perl install
Hey, That may have worked. No descernable errors. What's the best way to test it. Meanwhile I will be looking in 'Apache Modules w/ Perl & C'. Please advise. Thanks. John Kolvereid --- OCNS Consulting <[EMAIL PROTECTED]> wrote: > John: > > Consider installing the latest version of Apache > 1.3.23. > > RB > > -Original Message- > From: OCNS Consulting [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 8:53 AM > To: John Kolvereid; Ade Olonoh > Cc: mod_perl Mailing List > Subject: RE: Trouble w/ LWP during mod_perl install > > > John: > > Try the following: > > $ perl Makefile.PL \ > USE_APXS=1 \ > EVERYTHING=1 \ > WITH_APXS=/usr/local/apache/bin/apxs > > $ make > $ make test > $ make install > > This will build mod_perl as a DSO outside of the > Apache source > tree using the Apache APXS option - eXtenSion (APXS) > support tool>. > > Let us know. > > RB > > -Original Message- > From: John Kolvereid [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 17, 2002 8:03 PM > To: OCNS Consulting; Ade Olonoh > Cc: mod_perl Mailing List > Subject: RE: Trouble w/ LWP during mod_perl install > > > Hi RB, > Here is the configuration I tried: > perl Makefile.PL \ > APACHE_PREFIX=/usr/local/apache \ > APACHE_SRC=/home/ssl/apache_1.3.22 \ > USE_APXS=1 \ > WITH_APXS=/usr/local/apache/bin/apxs \ > DO_HTTPD=1 \ > USE_APACI=1 \ > EVERYTHING=1 > Both w/ and w/o the APACHE_PRFIX and APACHE_SRC > lines. > The errors are attached. Please advise. Thanks. > --- OCNS Consulting <[EMAIL PROTECTED]> wrote: > > John, > > > > Consider building mod_perl as a DSO outside of > > Apache. Look for the > > section title "Build mod_perl as DSO outside > Apache > > source tree via > > APXS" in the file INSTALL.apaci. > > > > This should work for you. Let us know. > > > > RB > > > > -Original Message- > > From: John Kolvereid [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, March 17, 2002 6:09 PM > > To: Ade Olonoh > > Cc: mod_perl Mailing List > > Subject: Re: Trouble w/ LWP during mod_perl > install > > > > > > Hi Ade, > > I followed your suggestion and went to > > > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > > > Most of their steps I had followed before. Now > I > > tried to config mod_perl w/ the following config > > file > > as they had suggested: > > perl Makefile.PL \ > > APACHE_PREFIX=/usr/local/apache \ > > APACHE_SRC=/home/ssl/apache_1.3.22 \ > > SSL_BASE=/usr/local/ssl \ > > APACI_ARGS='--enable-module=ssl, \ > > --enable-shared=ssl, \ > > --enable-module=proxy, \ > > --enable-shared=proxy, \ > > --prefix=/usr/local/apache, \ > > --enable-module=rewrite' \ > > DO_HTTPD=1 \ > > USE_APACI=1 \ > > EVERYTHING=1 > > > > when I try to do a 'make' I get errors such as > > *** No rule to make target 'all'. Stop > > I can get it to make and make install if I leave > out > > the APACI_ARGS, but then it doesn't know how to > > create > > Apache w/ ssl. > > Yes I do have an existing Apache which I created > > w/ > > mod_ssl. It has been working fine. My goal is to > > add > > mod_perl. Any suggestions. Please advise. > > > > Thanks. > >John Kolvereid > > > > --- Ade Olonoh <[EMAIL PROTECTED]> wrote: > > > > Then I try running > > > > /usr/local/apache/bin/apachectl startssl > > > > > > > > Unfortunately I get the msg: > > > > Syntax error on line 206 of > > > > /usr/local/apache/conf/httpd.conf: > > > > Invalid command 'LoadModule', perhaps > > > mis-spelled or > > > > defined by a module not included in the > server > > > > > > > > > configuration > > > > could not locate Module SSL (line 206 > > > httpd.conf) > > > > > > Are you installing on top of an existing Apache > > > directory? In other > > > words, was /usr/local/apache/conf/httpd.conf > > created > > > by the install, or > > > did it already exist before you built Apache? > It > > > looks like the conf > > > file might expect Apache to have been built with > > DSO > > > support but it > > > wasn't in actuality. > > > > > > In case you haven't seen this already, you might > > > take a look at this > > > guide to installing Apache with mod_perl and > > > mod_ssl: > > > > > > http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_ > > > > > > The options it suggests should work for you > here. > > > > > > > > > --Ade. > > > > > > __ > > Do You Yahoo!? > > Yahoo! Sports - live college hoops coverage > > http://sports.yahoo.com/ > > > > > __ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com
Re: Trouble w/ LWP during mod_perl install
John Kolvereid wrote: > Hi Stas, John, please keep the thread at the list, unless you are asked to take it offlist. > Results: > URI.pm location > /usr/lib/perl5/site_perl/5.005/i386-linus/Apache > UserAgent > /usr/lib/perl5/site_perl/5.005/LWP > HeadParser > unavailable install HTML::HeadParser first. than install LWP from sources, and make sure that it passes all the LWP tests. only then, if you still have a problem with 'make test' it's a modperl problem, before that it's OT. > When I run >%perl -MURI -e1 > I get >No such job %perl :) I use % as a prompt example, of course no need to copy-n-paste % :) Hope you get it right now. Using CPAN.pm is the easiest way to go about Perl modules installation. perl -MCPAN -eshell (this time I'm not including the % prompt :) > What should I do next. Please advise. Thanks. > --- Stas Bekman <[EMAIL PROTECTED]> wrote: > >>John Kolvereid wrote: >> >>>Hi Stas, >>> I am currently running w/ openssl-0.9.6b. >>> >>ALso, I >> >>>tried your suggestion: >>> >>> perl -MCPAN -eshell >>> cpan> install URI HTML::HeadParser LWP >>> >>>make test still could not find LWP... >>> >>Nope, according to your original report (the >>relevant part of it is >>attached below) it did find LWP, but it couldn't >>load its LWP::UserAgent >>because it couldn't locate URI and HTML::HeadParser. >> >>Now can you check that they are installed in the >>same location as LWP? >>What do you get from running these? >> >>find /usr/lib/perl5 | grep URI.pm >>find /usr/lib/perl5 | grep UserAgent.pm >>find /usr/lib/perl5 | grep HeadParser.pm >> >>assuming that all your perl libs are installed under >>/usr/lib/perl5 as >>in your report >> >>can you run >> >>%perl -MURI -e1? >> >> >> >Checking for LWP::UserAgent..failed >Can't locate URI.pm in @INC (@INC contains: ./lib > > /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at (eval 2) line 3. >BEGIN failed--compilation aborted at > > /usr/lib/perl5/site_perl/5.005/LWP/UserAgent.pm >>line >> 108. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl does not see multipart POSTs
I'm not sure I understand what you're asking... Apache, on it's own, does not support any internal parsing of POST data, multipart or otherwise, so why should mod_perl? For this, we have the Apache::Request library in mod_perl (Which is the mod_perl interface to the libapreq library for Apache's C API). libapreq supports multipart/form-data, even without a file upload... Issac Vuillemot, Ward W wrote: >All, > >I am still trying to figure out why my setup of mod_perl does not have >multipart POSTs. I rebooted my machine, and found that, whereas I reported >before mod_perl would try to reload the page (which it should not but send >out a text/plain attachment for download), it appears the script (running as >a perl handler) does not see any of the multipart POST. Vanilla posts are >not a problem, though. Even if the information being sent via multipart is >_not_ a file to upload to the server, the information is lost in transit. > >Here is what is odd. > >The same scripts/modules unmodified and running as perl_cgi are okay. >Multipart forms allow me to upload files, et cetera. In short, I am >confident the problem is not with my programming. > >I am using the code snippet, POST2GET, to capture the one-time read of POST >and storing as if it was retrieved via GET. > >Any ideas how to debug this? > >I REALLY REALLY would love some feedback. I would love to think that all my >effort to stay away from M$ ASP are worth it -- esp. when I stand up to >defend Perl, Apache, and mod_perl in an environment that is decidely >M$-bent. > >Thanks! >Ward >
RE: mod_perl does not see multipart POSTs
Just to re-iterate a previous post. Here is what I have done thusfar.
My httpd.conf file:
#
# **
# ** MOD PERL CHANGES **
# **
# limit POSTS so that they get processed properly
PerlInitHandler POST2GET
# force reloading of modules on restart
PerlFreshRestart on
# Perl module primitive mother load on start/restart
#PerlRequire lib/perl/startup.pl
# FLOE application (mod_perl)
PerlModule Apache::DBI
PerlModule floeApp
SetHandler perl-script
PerlHandler floeApp
PerlSendHeader On
And the relevant two snippets of code from the script are:
## process incoming
# if submitted
my %hash = undef;
my $initialList = $q->param('initialList') || '';
my $upload = $q->upload || undef;
my $fh = $upload->fh if defined($upload);
if (defined($upload) && $upload) {
$initialList = '';
while (<$fh>) {
$initialList .= $_;
}
}
## some processing is done to the POST'ed data
## and eventually. . .
## send file to client
print "Content-type: text/plain\n";
print "Content-Disposition: attachment;
filename=list.txt\n\n";
foreach my $value (sort keys %$hash) {
chomp($value);
next unless ($value);
print "$hash->{$value}$CRLF$value$CRLF";
}
exit;
$q is the Apache::Request object. When running in CGI mode it is simply
pointing toward the CGI.pm object.
I did not mean to presume Apache was doing anything to anything.
Apache::Request does not seem to appear to support/handle multipart in my
present config. I do not know why. All I have changed in my code is to use
Apache::Request instead of CGI. Otherwise, the scripts are untouched.
Same machine, same httpd.conf other the mod_perl changes, same scripts. . .
.then why cannot I not see anything being passed via multipart/form-data
encoding?
: -Original Message-
: From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
: Sent: Monday, March 18, 2002 9:37 AM
: To: Vuillemot, Ward W
: Cc: [EMAIL PROTECTED]
: Subject: Re: mod_perl does not see multipart POSTs
:
:
: I'm not sure I understand what you're asking... Apache,
: on it's own,
: does not support any internal parsing of POST data, multipart or
: otherwise, so why should mod_perl? For this, we have the
: Apache::Request library in mod_perl (Which is the
: mod_perl interface to
: the libapreq library for Apache's C API). libapreq supports
: multipart/form-data, even without a file upload...
:
: Issac
:
: Vuillemot, Ward W wrote:
:
: >All,
: >
: >I am still trying to figure out why my setup of mod_perl
: does not have
: >multipart POSTs. I rebooted my machine, and found that,
: whereas I reported
: >before mod_perl would try to reload the page (which it
: should not but send
: >out a text/plain attachment for download), it appears
: the script (running as
: >a perl handler) does not see any of the multipart POST.
: Vanilla posts are
: >not a problem, though. Even if the information being
: sent via multipart is
: >_not_ a file to upload to the server, the information is
: lost in transit.
: >
: >Here is what is odd.
: >
: >The same scripts/modules unmodified and running as
: perl_cgi are okay.
: >Multipart forms allow me to upload files, et cetera. In
: short, I am
: >confident the problem is not with my programming.
: >
: >I am using the code snippet, POST2GET, to capture the
: one-time read of POST
: >and storing as if it was retrieved via GET.
: >
: >Any ideas how to debug this?
: >
: >I REALLY REALLY would love some feedback. I would love
: to think that all my
: >effort to stay away from M$ ASP are worth it -- esp.
: when I stand up to
: >defend Perl, Apache, and mod_perl in an environment that
: is decidely
: >M$-bent.
: >
: >Thanks!
: >Ward
: >
:
:
:
Asia To USA Shipping Rates
We have a full collection of wholesale freight rate calculators at http://www.apx-air-cargo.com Our new calculator is here and it will calculate rates from Asia to over 30 US cities including customs clearance and delivery. CLICK HERE http://www.freight-calculator.com/ocean-asia/oceanasia.asp Hope to see your business grow! Regards, Virginie ML DeJaham Bordelais APX (Air Parcel Express, Inc.) Customer Service and Sales http://www.shipping-worldwide.com http://www.freight-calculator.com
Permission conflict between mod_cgi and mod_perl
Hi, We have a product that at the moment uses a combination of CGI and mod_perl. While in the future it will be totally ported to mod_perl, until we figure out exactly how we'd like to overcome the 'expat' issues we're stuck with a mixed-mode enviroment. Here however is the current problem. The cgi script under a specific set of circumstances (signing up a new account) copies a directory using a fork to the system's cp command and they're created as user: apache group: apache. I'm not by nature a linux mod_perl programmer and thus I'm not totally up on the nuances of what I'm doing here. I needed a quick solution to copying a template directory to a user directory when a new user account was created, and since it happened only once during the user's process I figured a fork to cp was worth the performance hit for the simplicity it provided. Single line of code vs some directory recurison scheme. The problem is when I later try access the files or directories under either mod_perl or the cgi process the server returns an error unless I set the chmod to 777 on the files. This is obviously not good. I have done some looking into using $> before I write the file but I hadn't found anything about using this under mod_perl ... let alone mod_cgi ... except that generally it's a bad idea to setuid to root. um yeah ... I wasn't gonna do that ... I just didn't want to give the world 777 access to files that run under apache:apache. I also didn't want to follow bad with worse implimenetation wise. Is there a simple secure method for copying a directory from a template directory to a user directory and then giving access to the (new) user directory? Any other considerations here? Thanks -Chris ::who will be happy if someone even says "Go Read the Nautilis book ... it covers Recursion in depth"::
Re: Permission conflict between mod_cgi and mod_perl
On Mon, 18 Mar 2002 14:17:35 EST [EMAIL PROTECTED] wrote: > We have a product that at the moment uses a combination of CGI and mod_perl. > While in the future it will be totally ported to mod_perl, until we figure > out exactly how we'd like to overcome the 'expat' issues we're stuck with a > mixed-mode enviroment. > > Here however is the current problem. The cgi script under a specific set of > circumstances (signing up a new account) copies a directory using a fork to > the system's cp command and they're created as user: apache group: apache. > > I'm not by nature a linux mod_perl programmer and thus I'm not totally up on > the nuances of what I'm doing here. I needed a quick solution to copying a > template directory to a user directory when a new user account was created, > and since it happened only once during the user's process I figured a fork to > cp was worth the performance hit for the simplicity it provided. Single line > of code vs some directory recurison scheme. > > The problem is when I later try access the files or directories under either > mod_perl or the cgi process the server returns an error unless I set the > chmod to 777 on the files. This is obviously not good. > > I have done some looking into using $> before I write the file but I hadn't > found anything about using this under mod_perl ... let alone mod_cgi ... > except that generally it's a bad idea to setuid to root. um yeah ... I wasn't > gonna do that ... I just didn't want to give the world 777 access to files > that run under apache:apache. I also didn't want to follow bad with worse > implimenetation wise. > > Is there a simple secure method for copying a directory from a template > directory to a user directory and then giving access to the (new) user > directory? You may want to look into useradd and /etc/skel on a Linux system. It has everything you are trying to accomplish handled automatically by using the standard Linux user creation techniques. No need to re-implement the wheel. :) - Frank Wiles <[EMAIL PROTECTED]> http://frank.wiles.org -
Asia To USA Shipping Rates
We have a full collection of wholesale freight rate calculators at http://www.apx-air-cargo.com Our new calculator is here and it will calculate rates from Asia to over 30 US cities including customs clearance and delivery. CLICK HERE http://www.freight-calculator.com/ocean-asia/oceanasia.asp Hope to see your business grow! Regards, Virginie ML DeJaham Bordelais APX (Air Parcel Express, Inc.) Customer Service and Sales http://www.shipping-worldwide.com http://www.freight-calculator.com
Re: Asia To USA Shipping Rates
[EMAIL PROTECTED] wrote: > > We have a full collection of wholesale freight rate calculators at > Aaaahhh!! Ask, anybody, make it stop!!! --Geoff
Re: [ANNOUNCE] PHP::Session
On Mon, Mar 18, 2002 at 07:27:40PM +0900, Tatsuhiko Miyagawa wrote: > Now PHP::Session 0.05 with save/destory implementation is going on its > way to CPAN. > > 0.05 Mon Mar 18 16:36:27 JST 2002 > * added Boolean type (ext/var.h in PHP source code) > > 0.04 Fri Mar 15 16:14:32 JST 2002 > * added destroy() > > 0.03 Fri Mar 15 16:01:35 JST 2002 > * added session ID validation > * implemented save() Will there be a way to specify each of the actions as PHP allows? For example, in a project I have, we use PHP4 sessions, but they are stored in a MySQL table so they can be shared across web machines without worrying about NFS problems. Basically, it would be nice to have PHP::Sessions provide the serialization mechanism for use by Apache::Session without it worrying about how to store the information. --jim
Re: Permission conflict between mod_cgi and mod_perl
In a message dated 18-Mar-02 7:36:55 PM GMT Standard Time, [EMAIL PROTECTED] writes: You may want to look into useradd and /etc/skel on a Linux system. It has everything you are trying to accomplish handled automatically by using the standard Linux user creation techniques. No need to re-implement the wheel. :) That's just it ... we didn't want to have to create whole new user accounts for everybody. Just a small directory of files for a demo of our web-app. I'd be happy if all the apps weren't apache:apache ... but I was thinking there had to be a better solution than `chown nobody:nobody $directory -R` (just an example !!) I will take a look though at /etc/skel ... I hadn't heard of it. -Chris
Re: Permission conflict between mod_cgi and mod_perl
At 3:42 PM -0500 3/18/02, [EMAIL PROTECTED] wrote: >In a message dated 18-Mar-02 7:36:55 PM GMT Standard Time, >[EMAIL PROTECTED] writes: > >>You may want to look into useradd and /etc/skel on a Linux system. It >> has everything you are trying to accomplish handled automatically >> by using the standard Linux user creation techniques. No need to >> re-implement the wheel. :) >> > > >That's just it ... we didn't want to have to create whole new user >accounts for everybody. Just a small directory of files for a demo >of our web-app. > >I'd be happy if all the apps weren't apache:apache ... but I was >thinking there had to be a better solution than `chown nobody:nobody >$directory -R` (just an example !!) To change default file permissions of newly created files perldoc -f umask To change ownership of a file without a fork* perldoc -f chown To change permissions of a file without a fork* perldoc -f chmod To create directories without a fork* perldoc -f mkdir * on most *nix based systems Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: [ANNOUNCE] PHP::Session
At Mon, 18 Mar 2002 14:06:56 -0600, Jim Smith wrote: > Will there be a way to specify each of the actions as PHP allows? > For example, in a project I have, we use PHP4 sessions, but they are > stored in a MySQL table so they can be shared across web machines > without worrying about NFS problems. You're very happy :) Then you don't have to play with this module of nightmare. > Basically, it would be nice to have PHP::Sessions provide the > serialization mechanism for use by Apache::Session without it > worrying about how to store the information. Yes, what I'm planning now is Apache::Sesion::PHP, which gives your a way to handle PHP4 session files transparently via Apache::Session interface. -- Tatsuhiko Miyagawa
Re: [ANNOUNCE] PHP::Session
At Tue, 19 Mar 2002 06:03:56 +0900, Tatsuhiko Miyagawa wrote: > > Basically, it would be nice to have PHP::Sessions provide the > > serialization mechanism for use by Apache::Session without it > > worrying about how to store the information. > > Yes, what I'm planning now is Apache::Sesion::PHP, which gives your a > way to handle PHP4 session files transparently via Apache::Session > interface. Current implementation of PHP::Session is already modularized enough for you to use serialization part as a standalone code. See PHP::Session::Serializer::PHP for it. (Though its synopsis says "DONT USE THIS MODULE DIRECTLY" :)) -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
[DIGEST] mod_perl digest 2002/03/04
-- mod_perl digest March 4, 2002 - March 17, 2002 -- Recent happenings in the mod_perl world... Hope everyone had a fun and safe spring break (for those that had a spring break). Features o mod_perl status o module announcements o application announcements o available mod_perlers o mailing list highlights o links mod_perl status o mod_perl - stable: 1.26 (released July 11, 2001) [1] - development: 1.26_01-dev [2] o Apache - stable: 1.3.23 (released January 24, 2002) [3] - development: 1.3.24-dev [4] o mod_perl 2.0 - in development (cvs only) [?] o Apache 2.0 - beta: 2.0.32 (released February 14, 2002) [5] o Perl - stable: 5.6.1 (released April 9, 2001) [6] - development: 5.7.3 [7] module announcements o Apache::GTopLimit 1.01 - Limit Apache httpd processes [8] o Apache::FillInForm 0.01 - mod_perl interface to HTML::FillInForm [9] o Apache::VMonitor 0.7 - Visual System and Apache Server Monitor [10] o Embperl 2.0b6 - system for building dynamic websites with Perl [11] o PHP::Session 0.05 - read and write PHP4 session files [12] application announcements o Bricolage 1.2.3 - full-featured, open-source, enterprise-class content management system [13] available mod_perlers o Paris, France (contracts, telecommute, or full-time; may be willing to move) [14] mailing list highlights o mod_perl training companies [15] o developer mod_perl environment [16] o site host providers that support mod_perl [17] o mod_perl list moved to perl.apache.org [18] o new mod_perl logo chosen [19] links o The Apache/Perl Integration Project [20] o mod_perl documentation [21] o mod_perl modules on CPAN [22] o mod_perl homepage [23] o mod_perl news and advocacy [24] o mod_perl list archives - modperl@ [25] [26] - dev@ [27] [28] - advocacy@ [29] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.apache.org/dist/httpd/ [6] http://www.cpan.org/src/stable.tar.gz [7] http://www.cpan.org/src/devel.tar.gz [8] http://mathforum.org/epigone/modperl/plalphoitwul [9] http://mathforum.org/epigone/modperl/stoipulrald [10] http://mathforum.org/epigone/modperl/strandplanggrur [11] http://mathforum.org/epigone/modperl/maublirgeh [12] http://mathforum.org/epigone/modperl/verdtwunglah [13] http://mathforum.org/epigone/modperl/rerbrifel [14] http://mathforum.org/epigone/modperl/crastringpox [15] http://mathforum.org/epigone/modperl/clingpholrom [16] http://mathforum.org/epigone/modperl/perlfrahswer [17] http://mathforum.org/epigone/modperl/chingpeiphay [18] http://mathforum.org/epigone/modperl/quingrimpwheu [19] http://mathforum.org/epigone/modperl/swoydendkau [20] http://perl.apache.org [21] http://perl.apache.org/#docs [22] http://www.cpan.org/modules/by-module/Apache/ [23] http://www.modperl.com [24] http://www.take23.org [25] http://mathforum.org/epigone/modperl/ [26] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2 [27] http://marc.theaimsgroup.com/?l=apache-modperl-dev&r=1&w=2 [28] http://www.mail-archive.com/dev%40perl.apache.org/ [29] http://www.mail-archive.com/advocacy@perl.apache.org/
Re: Permission conflict between mod_cgi and mod_perl
To change set the default /etc/skel files and to use useradd on linux, you need to run as root ... but the cgi code normally runs with the userid of the web server (nobody or www) and thus cannot successfully invoke the useradd command. To successfully invoke the useradd command, you could do one of the following: 1. use suid perl and set the owner as root ... but i do not know if you can run a suid perl program under modperl. (anyone? will this work?) 2. run the web server as root ... DO NOT DO THIS! ... it will cause security problems. 3. use apache suexec and set root as the owner of your cgi program, but modperl and suexec do not work together. :( your best bet for what you want to do is to use suid perl ... but it would sure be nice if suexec and modperl worked together ... especially since most cgi programs need to save data for the userid of the cgi program ... especially when virtual hosts are supported ... and shopping cart cgi programs need to save all kinds of tracking data. in any of the above alternatives, be nice to your sys admin, since root access is needed. jim Frank Wiles wrote: > > On Mon, 18 Mar 2002 14:17:35 EST [EMAIL PROTECTED] wrote: > > > We have a product that at the moment uses a combination of CGI and mod_perl. > > While in the future it will be totally ported to mod_perl, until we figure > > out exactly how we'd like to overcome the 'expat' issues we're stuck with a > > mixed-mode enviroment. > > > > Here however is the current problem. The cgi script under a specific set of > > circumstances (signing up a new account) copies a directory using a fork to > > the system's cp command and they're created as user: apache group: apache. > > > > I'm not by nature a linux mod_perl programmer and thus I'm not totally up on > > the nuances of what I'm doing here. I needed a quick solution to copying a > > template directory to a user directory when a new user account was created, > > and since it happened only once during the user's process I figured a fork to > > cp was worth the performance hit for the simplicity it provided. Single line > > of code vs some directory recurison scheme. > > > > The problem is when I later try access the files or directories under either > > mod_perl or the cgi process the server returns an error unless I set the > > chmod to 777 on the files. This is obviously not good. > > > > I have done some looking into using $> before I write the file but I hadn't > > found anything about using this under mod_perl ... let alone mod_cgi ... > > except that generally it's a bad idea to setuid to root. um yeah ... I wasn't > > gonna do that ... I just didn't want to give the world 777 access to files > > that run under apache:apache. I also didn't want to follow bad with worse > > implimenetation wise. > > > > Is there a simple secure method for copying a directory from a template > > directory to a user directory and then giving access to the (new) user > > directory? > >You may want to look into useradd and /etc/skel on a Linux system. It >has everything you are trying to accomplish handled automatically >by using the standard Linux user creation techniques. No need to >re-implement the wheel. :) > > - >Frank Wiles <[EMAIL PROTECTED]> >http://frank.wiles.org > -
Re: [ANNOUNCE] PHP::Session
On Tue, Mar 19, 2002 at 06:03:56AM +0900, Tatsuhiko Miyagawa wrote: > At Mon, 18 Mar 2002 14:06:56 -0600, > Jim Smith wrote: > > > Will there be a way to specify each of the actions as PHP allows? > > For example, in a project I have, we use PHP4 sessions, but they are > > stored in a MySQL table so they can be shared across web machines > > without worrying about NFS problems. > > You're very happy :) > Then you don't have to play with this module of nightmare. I tried to write such a module last year. PHP sessions are a bit of a nightmare to parse efficiently, afaik. I'm glad someone's gone to the trouble to try and make a usable and distributable module. --jim
Re: [ANNOUNCE] PHP::Session
At Mon, 18 Mar 2002 15:46:20 -0600, Jim Smith wrote: > > > Will there be a way to specify each of the actions as PHP allows? > > > For example, in a project I have, we use PHP4 sessions, but they are > > > stored in a MySQL table so they can be shared across web machines > > > without worrying about NFS problems. > > > > You're very happy :) > > Then you don't have to play with this module of nightmare. > > I tried to write such a module last year. PHP sessions are a bit of > a nightmare to parse efficiently, afaik. I'm glad someone's gone to > the trouble to try and make a usable and distributable module. Exactly, it *is* a nightmare. See my dirty duplicated source code! I guess the format is designed to be easily parsed by C, but very difficult by Perl :) -- Tatsuhiko Miyagawa
