Re: OT: ApacheCon/Europe
Gunther Birznieks wrote: > > Just wondering who all from mod_perl is going to ApacheCon/Europe next week > and are there any plans to get together like there was at PerlCon. I'm going to be there. Some kind of get together would be cool. I'd like to hear about what other people are working on. - Perrin
Apache::AuthCookie now on SourceForge
Hi all, I have just created a SourceForge project for AuthCookie. If you are interested, you can access the project at http://sourceforge.net/projects/ap-authcookie/ . All previous releases are there, and I have imported the CVS tree too. Moving the project to SourceForge gives several benefits. First, interested developers can access the distribution via anonymous CVS. Second, the bug tracking tools & task list seem like they'll help organize my development and help let other people know the current statuses of project details. And third, it opens the possibility of having other developers work on the project. For some time now, I haven't had enough time to synthesize all the various requests/contributions/questions people have contacted me about. I've been considering finding a new person to be the shepherd of AuthCookie, but for the time being I think I'll hold off on that and remain in charge. I would like to make the development a bit more open though, because lately I've been a bit of a communication black-hole and the project has stagnated because of it. If you have any interest in being a developer or otherwise influencing the direction of the module, please contact me. I'm not sure whether I'm ready to coördinate the activity of lots of people, but I suspect perhaps only 1 or 2 people will be interested anyway. Although SourceForge provides discussion tools, I would like the mod_perl list to remain the main point of contact for AuthCookie support & discussion. It's possible that in the future we'll want to make a development list or something, but for now let's hold off. Pretty soon I will probably move Apache::Filter development to SourceForge too. Thanks for the time. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
OT: ApacheCon/Europe
Just wondering who all from mod_perl is going to ApacheCon/Europe next week and are there any plans to get together like there was at PerlCon. I missed PerlCon unfortunately. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: Remembering Authentication
On Tue, 17 Oct 2000, John Saylor wrote:
> From: "Ian Frawley" <[EMAIL PROTECTED]>
> > Is it not just possible through a perl module as I am not very clued
> > up on digital certificates.
> Well, you have to have some credentials- and if it's not a cookie [bad
> idea anyway], and if it's not a username/password- what would it be?
Form based authentication. Rather than the HTTP Basic box that the browser
provides.
> You could have IP address based authentication, but this is probably
> more prone to misconfiguration and forgery than digital certificates.
Yes. You forgot proxying and cacheing.
What you also appear to have forgotten is that mod_perl provides you with
a fantastic handle - PerlTransHandler - where you can really have some fun
with the Translation.
| # some test code
| sub handler
| {
| my $r=shift;
| my $uri=$r->uri();
| if(extract_crypto(\$uri))
| {
| # push the credentials into the notes table, or the
| # %ENV or similar at this point.
| $r->uri($uri);
| }
| return DECLINED;
This can still be cryptographically secure - requires the transmission of
username/password pair once - which can be done over https if required.
Thereafter you can do what you like to identify a session
> How important is access control to your application? In other words,
> where is the line on how much effort you [and your users] are going to
> put into security at the expense of convenience?
I think that the usage of digicerts is not wide enough yet that the use of
them is probably an inconvenience. Plus it doesn't work if someone
physically steals the computer. :)
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
standards n.: The principles upon which we reject other people's code.
Re: XML help (offtopic)?
On Wed, 18 Oct 2000, Adi wrote: > Have you looked at SOAP::Lite and the rest of the SOAP:: hierarchy on CPAN? > They may not be of direct help if you've already got a home-grown XML transport > protocol, but it might give you some good ideas. And, it may save you lots of > time in the long run if you can convert your home-grown XML system to use the > SOAP standard. > > BTW, has anyone played with these SOAP modules much? Specifically, are they > well-written / optimized for mod_perl? I've played a little bit with SOAP::Lite. Its a great concept, and just seemed to work, except in certain cases, for example you can't pass a DBI handle over SOAP, obviously, and the same goes for globs and filehandles. But other than that its almost transparent! -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: XML help (offtopic)?
Have you looked at SOAP::Lite and the rest of the SOAP:: hierarchy on CPAN? They may not be of direct help if you've already got a home-grown XML transport protocol, but it might give you some good ideas. And, it may save you lots of time in the long run if you can convert your home-grown XML system to use the SOAP standard. BTW, has anyone played with these SOAP modules much? Specifically, are they well-written / optimized for mod_perl? -Adi Geoffrey Gallaway wrote: > > I know this isnt the right place to ask this question but if someone could > at least fill me in and point me in the right direction I'd be gratefull. > > I'm trying to find a way to do XML over HTTP. I have a project at work > that I'm doing where we have a XML based system. The system would connect > to port 80 and do XML over HTTP. I'm not exactly sure what this entails > but I'm guessing using the HTTP protocall to send XML. So, you get the > HTTP methods (GET, POST, HEAD, etc) and headers (Date, Server, > Content-Type, etc) but with XML data instead of HTML. Now, I understand I > could easily use apache to send XML data (GET) but I'm not to sure how I > should handle receiving XML (POST). I definetly want to do the XML parsing > and such with perl (I've been playing with XML::Parser, very cool). What > am I missing? > > Thanks, sorry for being offtopic and for the bad explanation... > Geoff > > -- > Geoffrey Gallaway || This may seem a bit weird, but that's okay, because it > [EMAIL PROTECTED] || is weird. > D e v o r z h u n ||-- Tom Christiansen
Mod_perl, DBI, and Postgres install procedures...
Does anyone have a set of procedures to install Mod_perl, Apache, Postgres, DBI, DBI.pm, and anything else needed to make Modperl talk to a postgres database. I'm new to Linux and Mod_perl, and I've followed all the setup procedures I can find to do this, but I still cannot get a database connection. I think I'm just missing a step somewhere, and if I can get the procedures on how to do this from start to finish from one source, I think I'll be allright. I've been piecing together all the information I've found on the Internet, but I'm not having any luck. Currently I'm receiving the error Can't locate object method "connect" via package "DBI" at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm in my error_log whenever I start up the apache server. I've tried installing using RPM's and using the source files, but I always end up with a similar error. Thanks in advance
Re: possible bug in mod_perl 1.24_01
I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
possible bug in mod_perl 1.24_01
I have had an application working under apache 1.3.12/mod_perl 1.24 for several months now with no problems. I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then try to start apache, it goes into an infinite loop proocessing sections. The stack trace from gdb looks like this: #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 1736vfprintf.c: No such file or directory. (gdb) bt #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 #1 0x40105966 in _IO_vfprintf (s=0x401aea20, format=0x8119d18 "loading perl module '%s'...", ap=0xbf801910) at vfprintf.c:1029 #2 0x4010e027 in fprintf (stream=0x401aea20, format=0x8119d18 "loading perl module '%s'...") at fprintf.c:32 #3 0x806d0c0 in perl_require_module () #4 0x806b40c in perl_section () #5 0x806b231 in perl_section_self_boot () #6 0x8068d8e in perl_cmd_require () #7 0x8081f29 in invoke_cmd () #8 0x80822ac in ap_handle_command () #9 0x806acb7 in perl_handle_command () #10 0x806b826 in perl_section () #11 0x806b231 in perl_section_self_boot () #12 0x8068d8e in perl_cmd_require () #13 0x8081f29 in invoke_cmd () #14 0x80822ac in ap_handle_command () #15 0x806acb7 in perl_handle_command () #16 0x806b826 in perl_section () #17 0x806b231 in perl_section_self_boot () #18 0x8068d8e in perl_cmd_require () #19 0x8081f29 in invoke_cmd () #20 0x80822ac in ap_handle_command () #5889 0x806acb7 in perl_handle_command () #5890 0x806b826 in perl_section () #5891 0x806b231 in perl_section_self_boot () #5892 0x8068c6c in perl_cmd_module () #5893 0x8081f29 in invoke_cmd () #5894 0x80822ac in ap_handle_command () #5895 0x80822f8 in ap_srm_command_loop () #5896 0x80827ed in ap_process_resource_config () #5897 0x8085f28 in include_config () #5898 0x808206c in invoke_cmd () #5899 0x80822ac in ap_handle_command () #5900 0x806acb7 in perl_handle_command () #5901 0x806b043 in perl_handle_command_av () #5902 0x806b9d8 in perl_section () #5903 0x808206c in invoke_cmd () #5904 0x80822ac in ap_handle_command () #5905 0x80822f8 in ap_srm_command_loop () #5906 0x80827ed in ap_process_resource_config () #5907 0x8082e74 in ap_read_config () #5908 0x808a745 in main () #5909 0x400d89cb in __libc_start_main (main=0x808a560 , argc=4, argv=0xb914, init=0x8062524 <_init>, fini=0x811741c <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:92 And when I run with "MOD_PERL_TRACE=all" I get a whole bunch of output. It starts out like this: perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok SVt_PV: $Group = `mschout' handle_command (Group mschout): OK SVt_PV: $ServerAdmin = `[EMAIL PROTECTED]' handle_command (ServerAdmin [EMAIL PROTECTED]): OK perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: SVt_PV: $ServerRoot = `/nis.home/mschout/httpd' handle_command (ServerRoot /nis.home/mschout/httpd): OK SVt_PV: $User = `mschout' handle_command (User mschout): OK perl_section: loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok PORTS CONFIGURATION HTTP : 8531 HTTPS: 4531 `@Listen' directive is TAKE1, (2 elements) default: iterating over @Listen handle_command (Listen 8531): OK handle_command (Listen "4531"): OK perl_section: perl_section: SSLVerifyDepth 10 (OK) Limit=no SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key (OK) Limit=no SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt (OK) Limit=no SSLVerifyClient none (OK) Limit=no SSLEngine on (OK) Limit=no handle_command (SetEnvIf "User-Agent" ".*MSIE.*" "nokeepalive" "ssl-unclean-shutdown"): OK perl_section: perl_section: perl_section: perl_section: SVt_PV: $Port = `8531' handle_command (Port 8531): OK perl_section: perl_section: loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok SVt_PV: $DAVLockDB = `/var/tmp/DAVLock.mschout' handle_command (DAVLockDB /var/tmp/DAVLock.mschout): OK `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: SVt_PV: $DAVMinTimeout = `600' handle_command (DAVMinTimeout 600): OK loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: perl_section: perl_section: perl_section: AllowOverride None (OK) Limit=no DAV On (OK) Limit=no Options Indexes (OK) Limit=no perl_section: perl_section: perl_section: `
Installation problems!!!
I installed mod_perl 1.24 successfully ( the web server used is apache 1.3.9 and perl 5.004-4 ). No errors during configure, make , make test or make install. I added the loadmodule and addmodule lines to httpd.conf. But when I started the apache I get the following error message: "Starting httpd: httpd Syntax error on line 132 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libperl.so into server: /etc/httpd/modules/libperl.so: undefined symbol: ap_ctx_get" Can anyone help me? Thanks... -- Edmar Edilton da Silva Bacharel em Ciência da Computação - UFV Mestrando em Ciência da Computação - UNICAMP
Re: END block aborted during httpd shutdown
META Hi Ged, why are you answering me directly and not through the list? /META G.W. Haywood wrote: > > On Wed, 18 Oct 2000, Ernest Lergon wrote: > > > but how does it fit in the idea of shared modules in mod_perl? > > Shared memory, not shared events. > I have to think about this. > > > So I have to go more in detail: It's not just closing files... > > Write your own Aapche module, and use that to tidy up before Apache > shuts down? It's always a little bit uncertain to rely on Perl END > blocks if you want to be sure that stuff gets written to the disc. > Hmmm - so all that POD is only funny stuff? The Perl-authors are just kidding about END blocks? Ernest -- Yours sincerely Mit freundlichen Grüßen Ernest Lergon VIRTUALITAS Artists online, Fine Arts online, Poets online http://www.virtualitas.com/
Re: END block aborted during httpd shutdown
G.W. Haywood wrote: > > On Wed, 18 Oct 2000, Ernest Lergon wrote: > > > 1) Our apache is running 20 childs. A perl module is loaded via > > startup.pl. On shutdown of apache the END block of this module is called > > 20 times and not only 1 time as I expected. Why? > > Because each child is its own program and each executes the block. > You could put a global flag in there if you're adamant that it mustn't > do things more than once. > This workaround came to my mind too, but how does it fit in the idea of shared modules in mod_perl? > > > 2) I want to use the END block of this preloaded module to execute some > > cleanup - checking and writing back to disk data possibly changed during > > module livetime: a lengthy operation. > > You shouldn't need to do tha, the OS should take care of it if you > just close the files. Use Symbol; > So I have to go more in detail: It's not just closing files. On startup of apache (and loading of the module) the files will be read in and the module creates an internal net of objects (sort of cache). The files will be locked on disk so that a call to the module via unwanted mod_cgi will fail. Those objects might be changed by several requests to this module. On shutdown (NOT after each request!) all objects are checked and changed objects are written back to the files on disk. I expected, that this will be done once in the END block and that apache will wait. The root of the net of objects is a Class::Singleton object. Ernest
Re: Apache 1.3.14 and Mod_Perl
On Wed, 18 Oct 2000, Roger Espel Llima wrote: > It looks to me like perl.apache.org is explicitly blocking wget > requests. If I do the request manually with netcat, sending the same > headers wget sends, it fails: Why is wget considered so evil? -- "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd edition, June '72
AuthCookie consulting Basic for AuthZ?
Hello! I' m using AuthCookie for authentication, but I would like to use all the normal authorization possibilities in .htaccess files (especially 'require group', and ). Do I have to implement all the handling of .htaccess directives in my AuthCookie-derived module? Is it possible to ask the Apache's Basic auth to do the authorization? A subrequest with some special headers maybe? Am I totally lost with this one? In my case the cookie does not contain the password neiher there is any flat user file (nor group file). So maybe some kludge must be done to give the Basic auth headers all the information needed (for example base64 coded username:password)? Any help greatly appreciated!!! -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
Re: Apache 1.3.14 and Mod_Perl
<[EMAIL PROTECTED]> wrote: > Why can't I download it with wget? > > [root@wakko /root]# wget http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz > --15:56:47-- http://perl.apache.org:80/dist/mod_perl-1.24_01.tar.gz >=> `mod_perl-1.24_01.tar.gz' > Connecting to perl.apache.org:80... connected! > HTTP request sent, awaiting response... 403 Forbidden > 15:56:47 ERROR 403: Forbidden. It looks to me like perl.apache.org is explicitly blocking wget requests. If I do the request manually with netcat, sending the same headers wget sends, it fails: GET /index.html HTTP/1.0 User-Agent: Wget/1.5.3 Host: perl.apache.org:80 Accept: */* returns HTTP/1.1 403 Forbidden Date: Wed, 18 Oct 2000 13:49:26 GMT Server: Apache/1.3.15-dev (Unix) tomcat/1.0 Connection: close Content-Type: text/html; charset=iso-8859-1 while, if I just change the string Wget to Blah, then it works. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: Segmentation faults
We always had that, but I guess I solved it, it was the MaxRequestsPerChild directive on apache's httpd.conf , I set it to 10 and the problem was gone, may be it was because the childs grown up too much, up to 26M, now the max grow up size is 7M. Thanks anyway. -- Daniel Alejandro Grunblatt Jefe de Operaciones. Portal InfoNegocio. Tel: 4332-3332. Dir: Tucuman 1 piso 5. CP: C1049AAA. -BEGIN PGP PUBLIC KEY BLOCK- Version: PGP 6.5.1i mQGiBDnbPQ4RBADACXb8fSQa+RsVutdoGBV4ki/t26jD20k8e1D4rIvtHAxU8wbf ubnTMJ28rqp005l6I0InB8CrHrfgkzxtyD6xpxV1hYpdJRGGl3bwbawuYxT/Kl+1 3ss2nv4NoFE08vB73i6fsYjIhafYDeq3QYWZA3UKXdt1rr/iCEpo7aTzhQCg/6Q6 ZWWyACsnCP3z0RdSmXBBMQED/iCPPM4eNlyUjt+ijH4LVgMsTzUqNIOnb/mDrtHl wMYIoJqMvQ44wnxYxfQbMPkvETLM0/cVUA9CNf3KDNBBQ/lqbJxR7d5DdYrErGn+ AMtJv7pC732HswY956FpNK3wKB1NSODo8EDTIhyU/r1CZNKR0d5rkO+SxRT8Q82c f7DeBACUnDoLvNlBzr9swGwecFn5c7F0URe2GinNFzj81UMqJqoMxsVya7yXqnkX HRt5no0TxonxJ5wKc+HKIr0zdrrUqcweiQ74OHcpoKzZbxqiUgaoJSOtwYXrrxgR Yn1owLfhXdghKdC/s8h80i3FnnTchV2JkdgAzq+xRyCs594x8LQsRGFuaWVsIEdy dW5ibGF0dCA8ZGFuaWVsQGluZm9uZWdvY2lvLmNvbS5hcj6JAE4EEBECAA4FAjnb PQ4ECwMBAgIZAQAKCRAL0qbR8Z7fBC9cAKCkdh7FcxtxvY/8kbzueUwqfyBwCACg 0gWk6TXj54Ea9mfSTVpPpnfXUni5Aw0EOds9FBAMAMwdd1ckOErixPDojhNnl06S E2H22+slDhf99pj3yHx5sHIdOHX79sFzxIMRJitDYMPj6NYK/aEoJguuqa6zZQ+i AFMBoHzWq6MSHvoPKs4fdIRPyvMX86RA6dfSd7ZCLQI2wSbLaF6dfJgJCo1+Le3k XXn11JJPmxiO/CqnS3wy9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadW oxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeS Wc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0 iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF04 0zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQ ClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6UwybwACAgwAoz4dpF6Z37WFrTmZ nbcN+w2QY95NLKfcdf8LM1Hu1M8/uq4EdDGH8az+ka4MCzmdQPLYovQPvufMVAIX DCPKlECqCnFlm1nhpP2NkYOEpa/NR3M5VmjRGCiCs3pM5G4JzXhCScnY3xlJVHI4 tqpM4tQQR02TD8mAuBhh124nL8ypSYvykEdKEIAkanHC8NIhYgkGRWKkxfHbsyAX ju2CSRRY+5i9Ls5pEFS0BN8sRsgSNd7j+AHY94MpuRAAC41A4f0yFH7ztG7HleaG 1dHZjyQ+BSPM/VTsq+fNMPbKHGsF/z/OUPSKrYZEn4YcwOMZMQMDbtQh6GX58F8g gFm1BmHiFfIMB43peub7cXpWu5lsGduqSCvgGTdnD2/NGCyyk1GMiuGRBO9/Wais XHM3xJoAwOOr6SjVRIzYwYMdYWm7rg16f58103otzggvmfUYuM9cmfAUhrtUnk11 G/Mq/VK090dSfZ4od8jNOEMwEV7oQ9PF8Ny3DJbpYfEibNbiiQBGBBgRAgAGBQI5 2z0UAAoJEAvSptHxnt8EqmwAni/oHx6nZID6YdtdyqS6EFHGWJsLAKCWmahsk54o yyro5vzlLTF1/1l8SpkBogQ57JCTEQQA/cj1wYtSRJygT80flezalvDa7oDYs6qD uFS1YvsBUY8WFex7ouE5oxdZZiII4eeNJ72KTNG224r9qRYio9yPrWq52aWSHVn6 eVmR9pexHsVkV6OeNDpYITcQyprwm3+G13llgOPRQzSbSJeC4sYWUX93M5NpVkvJ ka37ifkxTlMAoP+BL4DqnqbNSDq0pr9AE7LjmndXA/kBCGo3kOb8djrJWqR6LBHV G5SBGeXs2e7/2waLNB5E1RwF45Yo/Qpdlgg6uDOh1VL5gzAYMC0Gre8lAR6xSfJb tb5qK+OTrvt1shRkIdxew/e9/EtJGg2Iw4hDoT+tanDDZ2y632PCXdxgyyXo7Lgu OmF3folE7AEVwhphBd1gzAQAzijs8sNmidi2rTTNEab6+wv6zPRvOhrRTtHk4ddu 76I+z4KxtbyHJPLTuaYoa17Jd4v/zCS88REL6iu4Ye0IFTojCVc+ejaWQzvEcP2o qVCLLDrqbnNG5K/+/TneWDZtw7obhxf1iZni3QsM+xKWnTCJCqQdvCfPKi9L0IET /3y0LERhbmllbCBHcnVuYmxhdHQgPGRhbmllbEBpbmZvbmVnb2Npby5jb20uYXI+ iQBOBBARAgAOBQI57JCTBAsDAQICGQEACgkQDOGuSFVStWt1UQCguH9OZA+U4PQZ TOMEx7jqCDR4GbwAn18Hk/4FiXY4NpzyNPMasfSOW5YbuQMNBDnskJgQDADMHXdX JDhK4sTw6I4TZ5dOkhNh9tvrJQ4X/faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jW Cv2hKCYLrqmus2UPogBTAaB81qujEh76DyrOH3SET8rzF/OkQOnX0ne2Qi0CNsEm y2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cIfwgXcqK61qlC8wXo+VMR OU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf 3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2g pXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPA Q/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQD GcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVelMMm8AAgIM ALR39Mee1pKzArzhNM/GZ3205LFPb1HRHEhs4A0SGsa4KeFsoy0RWue+Vd1hSuBe JJN7C3YSXn+FUakXQLbsI1G2SLc9RANl/znW1QOBS0ulwaspt/QtAEDfMTvVD8SA xcqZWr6jThwLLnyEJkzCE8qRzZaOllAsdArqEBljTxpLUHMf65bGpz83BxChSax/ /KvJ8jIPSuqxGpeHJPK3Hit5+EYwhBXtmTD+1rBoVRDCQPXBOKNWSpVmyEjfC0v9 BYcIWsmpix3wIHm+DNJxVR/7tK1qlKN5CueTA5RhDe3nUZHjQV7Xh14TUADOxE1t gHI/m1FB+TSvm0n0VAwAzMPIttFVUpyk6SxR+AXs1KX0WdsSSWM/J6BPwQqcntH2 vZ9LKTQ1JhZDlA7vM6zu5lrZY+wujLpj69bTz26qKiDPT8QaZSLn/bYnF/tZruFU w/RMgFcTq+XpmNObij1ulgdBzzVdrgfj2VBlJ/AyxklnrfyAyeyfY2UWBRG9YY9s S4kARgQYEQIABgUCOeyQmQAKCRAM4a5IVVK1a7PbAJ48LMu4RElR3Te1ROIYcBHa bjRxaQCeM5P96uhA8DDnMrLGKXHVg7GdusI= =4f4N -END PGP PUBLIC KEY BLOCK- On Sun, 15 Oct 2000, Gerald Richter wrote: > To your httpd.conf add a > > PerlModule HTML::Embperl > > > > > > > Options ExecCGI > > AllowOverride None > > SetHandler perl-script > > PerlHandler HTML::Embperl > > > > this should normaly solve this problem. If not let me know and we try to > track it down further > > Gerald > > > - > Gerald Richterecos electronic communication services gmbh > Internetconnect * Webserver/-design/-datenbanken * Consulting > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > E
Re: security suggestion
Would it make sense to allow anonymous subroutines as handlers only if ExecCGI is turned on for a given directory? (Likewise, allow handlers only in modules residing in system directories unless ExecCGI is turned on?) -- Richard Goerwitz[EMAIL PROTECTED]
Re: END block aborted during httpd shutdown
Dear list members, dear Doug, it seems to me, that my initial mail of this thread was to long to read and to be answered - especially because the questions are in the last paragraph far down below and need scrolling of the message text ;-)) Ok, I'll try to split it up in bite-sized pieces: 1) Our apache is running 20 childs. A perl module is loaded via startup.pl. On shutdown of apache the END block of this module is called 20 times and not only 1 time as I expected. Why? 2) I want to use the END block of this preloaded module to execute some cleanup - checking and writing back to disk data possibly changed during module livetime: a lengthy operation. But this is aborted on apache shutdown after 5 seconds with SIGKILL. Do I need special configuration for compiling apache/perl/mod_perl, in httd.conf or startup.pl to tell apache to wait for the completion of the END block(s)? Extended information can be found in my message at the beginning of this thread. Thank you in advance for your help. Ernest -- Yours sincerely Mit freundlichen Grüßen Ernest Lergon VIRTUALITAS Artists online, Fine Arts online, Poets online http://www.virtualitas.com/
Re: Mod Perl Startup Question
Randy, Thanks ... & I'll try that. - Vaughn - Original Message - From: Randy Kobes <[EMAIL PROTECTED]> To: vaughn_staples <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 18, 2000 9:14 AM Subject: Re: Mod Perl Startup Question On Wed, 18 Oct 2000, vaughn_staples wrote: > I'm having trouble getting Apache & Modperl to run on an NT machine. > When I attempt to launch Apache using a console window, I receive the > following message: > >"Syntax error on line 205 of c:/apache/conf/httpd.conf: >Cannot load c:/apache/modules/ApacheModulePerl into server: >(126) The specified module could not be found: > >Note the errors or messages above, and press key to exit." > > I've verified that the file "ApacheModulePerl.dll" is in the right > location, and > that the LoadModule command in the httpd.conf file is set ok. > > Here's what I have done thus far: > > o Since I lack a C compiler, I'm currently running ActiveState perl > 5.00503. > > o Installed Apache (apache_1_3_14_win32.exe) as "c:/Apache" > > o Downloaded (mod_perl-1.16) and copied the following files: > FROM: mod_perl_1.16/apache/modules/ApacheModulePerl.dll > TO: c:/Apache/modules/ApacheModulePerl.dll > > I've also copied the "perl/site/lib" tree to my "c:/perl" > directory. > > o Added the following entry to the httpd.conf file (at line 205) as > noted >in the error message: > LoadModule perl_module modules/ApacheModulePerl > > > I'm new to Apache & Modperl, and all help is appreciated. > > Thanks in advance, > > - Vaughn Hi, I doubt that this mix of mod_perl/perl/apache versions could work - typically you must use mod_perl compiled against the sources for the apache and perl binaries you're using. Plus, mod_perl hasn't been gotten to work with ActivePerls based on perl-5.005_03. The easiest thing to do is to upgrade your ActivePerl to build 618 (based on perl-5.6.0) and then use the ppm utility to install mod_perl (for apache_1.3.14): ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd This will also grab ApacheModulePerl.dll for you. best regards, randy kobes
Re: Mod Perl Startup Question
On Wed, 18 Oct 2000, vaughn_staples wrote: > I'm having trouble getting Apache & Modperl to run on an NT machine. > When I attempt to launch Apache using a console window, I receive the > following message: > >"Syntax error on line 205 of c:/apache/conf/httpd.conf: >Cannot load c:/apache/modules/ApacheModulePerl into server: >(126) The specified module could not be found: > >Note the errors or messages above, and press key to exit." > > I've verified that the file "ApacheModulePerl.dll" is in the right > location, and > that the LoadModule command in the httpd.conf file is set ok. > > Here's what I have done thus far: > > o Since I lack a C compiler, I'm currently running ActiveState perl > 5.00503. > > o Installed Apache (apache_1_3_14_win32.exe) as "c:/Apache" > > o Downloaded (mod_perl-1.16) and copied the following files: > FROM: mod_perl_1.16/apache/modules/ApacheModulePerl.dll > TO: c:/Apache/modules/ApacheModulePerl.dll > > I've also copied the "perl/site/lib" tree to my "c:/perl" > directory. > > o Added the following entry to the httpd.conf file (at line 205) as > noted >in the error message: > LoadModule perl_module modules/ApacheModulePerl > > > I'm new to Apache & Modperl, and all help is appreciated. > > Thanks in advance, > > - Vaughn Hi, I doubt that this mix of mod_perl/perl/apache versions could work - typically you must use mod_perl compiled against the sources for the apache and perl binaries you're using. Plus, mod_perl hasn't been gotten to work with ActivePerls based on perl-5.005_03. The easiest thing to do is to upgrade your ActivePerl to build 618 (based on perl-5.6.0) and then use the ppm utility to install mod_perl (for apache_1.3.14): ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd This will also grab ApacheModulePerl.dll for you. best regards, randy kobes
RE: DBI / Postgres Intermittent Problem
Hi, Thanks for those who responded to my request. In response to something someone suggested - when i tried using Apache::DBI - there was no difference whether or not I was using it. I set up a new Apache/mod_perl installation to see if the problem stayed. My old set up was mod_perl 1.21 + Apache 1.3.9 + SSL + HTML::Embperl + perl 5.00503 New set up : mod_perl 1.24 + Apache 1.3.12 + HTML::Embperl + perl 5.6 DBI on both was most recent version After much hassle I got it all working... and - wait for it. I didn't get the intermittent problem I've been getting! I hammered it - I ran ab -n 100 -c 100 and it flew through without a single Internal Server Error. I sat hitting reload on Netscape to try and catch it out - but it was solid. I was running the old Apache SSL installation at the same time on the same machine - both were running of the same .epl scripts and db. so I added the 's' after http and tried hammering again. But dammit... the problems had disappeared from here too. unfortunately I couldn't run ab as it doesn't seem to support https. Looking back, I had solid reason to believe this intermittent thing was occurring with MySQL at my old place because of various signs. But it's possible with the problem i've had with postgres, it was occurring because it was reloading the wrong page from the cache. I've no idea why that would happen - but there's been no problem from either webserver since I set my cache to 0bytes mem/disk. So until the problem rears its head again... I'll be keeping quiet. Rajit
Re: Handler is preventing redirects on missing trailing / ?
> "darren" == darren chamberlain <[EMAIL PROTECTED]> writes:
darren> Clayton Mitchell ([EMAIL PROTECTED]) said something to this effect:
>> I then noticed that URI's of directories lacking a trailing '/' were not
>> being redirected in the browser and so relative links started to break.
darren> In your handler subroutine, do something like:
darren> return DECLINED if ($r->content_type =~ /directory$/i);
darren> or
darren> return DECLINED if (-d $r->filename);
darren> HTML::Mason has this problem; Locations handled by Mason are all given to
darren> the default handler subroutine, which needs to decline directory requests.
I stole the code for Stonehenge::Pictures partially from some stuff
I saw in the Eagle book, but here's my current meme on that:
use Apache::Constants qw(:common DIR_MAGIC_TYPE);
...
sub handler {
$R = shift;
$URI = $R->uri;
...
if ($R->content_type eq DIR_MAGIC_TYPE) {
return handle_directory();
} else {
return handle_file();
}
...
sub handle_directory {
## if non-slash URL, send external redirect via mod_dir:
return DECLINED unless $URI =~ /\/$/;
...
So, I first see if content_type is DIR_MAGIC_TYPE, and then
if it doesn't also end in a slash, I decline, and the nice mod_dir
does all the external redirecting stuff.
(Stonehenge::Pictures is at
.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Mod Perl Startup Question
I'm having trouble getting Apache & Modperl to run on an NT machine. When I attempt to launch Apache using a console window, I receive the following message: "Syntax error on line 205 of c:/apache/conf/httpd.conf: Cannot load c:/apache/modules/ApacheModulePerl into server: (126) The specified module could not be found: Note the errors or messages above, and press key to exit." I've verified that the file "ApacheModulePerl.dll" is in the right location, and that the LoadModule command in the httpd.conf file is set ok. Here's what I have done thus far: o Since I lack a C compiler, I'm currently running ActiveState perl 5.00503. o Installed Apache (apache_1_3_14_win32.exe) as "c:/Apache" o Downloaded (mod_perl-1.16) and copied the following files: FROM: mod_perl_1.16/apache/modules/ApacheModulePerl.dll TO: c:/Apache/modules/ApacheModulePerl.dll I've also copied the "perl/site/lib" tree to my "c:/perl" directory. o Added the following entry to the httpd.conf file (at line 205) as noted in the error message: LoadModule perl_module modules/ApacheModulePerl I'm new to Apache & Modperl, and all help is appreciated. Thanks in advance, - Vaughn
RE: PerlAuthenHandler and DBI:
> -Original Message-
> From: Daniel Hutchison [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 17, 2000 3:49 PM
> To: [EMAIL PROTECTED]
> Subject: PerlAuthenHandler and DBI:
>
>
> While the behaviour seems correct from the browser, I am
> getting errors in
> the error_log that may be indicative of some kind of problem:
> Here is the relevant snippet of my httpd.conf:
>
>
> # Added for Oracle to work. Dan H. 5-oct-2000
> #
>
> SetEnv ORACLE_HOME /home/oracle/product/8.1.6
> SetEnv LD_LIBRARY_PATH /home/oracle/product/8.1.6/lib
>
[snip]
> Now, when I browse to the survey directory and enter my username and
> password this line appears in the errors_log:
>
> [datestamp] null: ORACLE_HOME environment variable not set!
SetEnv only takes affect at fixup, making ORACLE_HOME not set during
authentication.
use PerlSetEnv, which sets ORACLE_HOME sooner, in time for authentication.
for what it's worth, IIRC, it is best to make sure ORACLE_HOME is set when
DBD::Oracle is compiled, so if you have a startup.pl script that pre-loads
your modules, it might help to have
BEGIN {
$ENV{'ORACLE_HOME'} = "/home/oracle/product/8.1.6";
}
in there too...
HTH
--Geoff
>
> I've never had this error before, and most of my scripts do
> access oracle,
> always working fine.
> Only in this case has it ever appeared.
>
> Any help would be appreciated, or a pointer to some thorough
> documentation.
> thanks!
> Dan
>
>
Re: Handler is preventing redirects on missing trailing / ?
Clayton Mitchell ([EMAIL PROTECTED]) said something to this effect:
> I then noticed that URI's of directories lacking a trailing '/' were not
> being redirected in the browser and so relative links started to break.
In your handler subroutine, do something like:
return DECLINED if ($r->content_type =~ /directory$/i);
or
return DECLINED if (-d $r->filename);
HTML::Mason has this problem; Locations handled by Mason are all given to
the default handler subroutine, which needs to decline directory requests.
(darren)
> As a w/o I installed a TransHandler listed below to modify the URI. It
> seems like I am re-inventing the wheel here and so I assume I did something
> wrong to get to this point?
> Thanks for any advice.
>
>
> package Tofu::Tofugruff;
>
> #use Apache::Constants qw(:common);
> use Apache::Constants qw(:response);
>
> use strict;
>
>
> sub handler {
> my $r = shift;
> my $f = $r->document_root.$r->uri;
> my $uri = $r->uri;
> if ( -d $f && $f !~/.*\/$/ ) {
># A directory that doesn't end in a '/'
>$uri.='/'; # fix it
>$r->err_header_out("Pragma", "no-cache");
>$r->header_out("Location" => $uri );
>$r->status(REDIRECT);
>return DECLINED;
> }
> return DECLINED;
> }
>
> 1;
> __END__
>
--
I tended to place my wife under a pedestal.
-- Woody Allen
Re: [ RFC ] New Module Apache::SessionManager
Hi Greg, the name sounds good to me. I would be happy if you send me a copy, so I can take a (because of my limited time) short look how it may fit with Embperl's session management Thanks Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - - Original Message - From: "Greg Cope" <[EMAIL PROTECTED]> To: "Gunther Birznieks" <[EMAIL PROTECTED]> Cc: "Modperl list" <[EMAIL PROTECTED]> Sent: Wednesday, October 18, 2000 10:55 AM Subject: Re: [ RFC ] New Module Apache::SessionManager > Gunther Birznieks wrote: > > > > I like the name as it works well with our naming (SessionManager, Session > > hierarchy) so I can probably write a wrapper that assumes your > > SessionManager is embedded in Apache and it's not confusing for our users > > who want to configure our apps to use your session manager. > > Thanks Gunther > > If anyone wants a copy in the mean time drop me a line. > > Greg > > > > > > > Thanks, > > Gunther > > > >
Re: [OT]logging Apache processes w/rotatelogs
"Alexander Farber (EED)" <[EMAIL PROTECTED]> writes: > David Hodgkinson wrote: > > There are plenty of counter examples floating around. Mostly involving > > moving log files away then doing a graceful restart. > > Maybe this is useful: > http://www.modperl.com/perl_conference/cool_tricks/handout.html Certianly more useful than my response...thanks. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: [ RFC ] New Module Apache::SessionManager
Gunther Birznieks wrote: > > I like the name as it works well with our naming (SessionManager, Session > hierarchy) so I can probably write a wrapper that assumes your > SessionManager is embedded in Apache and it's not confusing for our users > who want to configure our apps to use your session manager. Thanks Gunther If anyone wants a copy in the mean time drop me a line. Greg > > Thanks, > Gunther >
ANNOUNCE: HTML-Embperl 1.3b6 (pre 1.3)
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-1.3b6.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GR/GRICHTER/HTML-Embperl-1.3b6.tar.gz
size: 300443 bytes
md5: a57165c6a75b3c8d33ca8b2833c671fc
Embperl is a module for embedding Perl code in HTML pages. See
http://perl.apache.org/embperl/ (english) or http://www.ecos.de/embperl/
(german) for more informations.
This is hopefully the last release before the final 1.3 release. I have
added
some more session stuff and enhanced EmbperlObject. Please give it a try
and report me any problems.
Enjoy
Gerald
Changes since 1.3b5:
- Embperl now runs on ActiveState Perl. (At least in offline mode,
mod_perl mode seems to still have some problems). With a lot of help
from Randy Korbes.
- Changed EmbperlObject search order:
* If EMBPERL_OBJECT_STOPDIR is set, this directory is taken as
the last directory in the normal search path, instead of the
directory where the base template (EMBPERL_OBJECT_BASE) is found.
* EMBPERL_OBJECT_ADDPATH is _always_ added to the search path
* Now Embperl also searches the path for files like
../foo.html, or bar/foo.html, which includes a relative path.
- ../* is now a shortcut for the requested file, but in the
parent directory (or upper depending on the search path)
- Added access to Embperl session handling for modules and
calling scripts (see SetupSession and GetSession)
- Embperl is now able to output binary data if EMBPERL_ESCMODE
and/or $escmode is zero. This also include that no CRLF is
added at the end of the file, if escmode is zero.
- Added method for deleting session data and cookie
- Added method for triggering resend of session cookie.
- Added Test for pnotes ('EMBPERL_ERRORS')
- Added hash %CLEANUPFILE. All variables defined into the files given
in this hash, are also cleanup at the end of the request.
Patch from Todd Eigenschink.
- Changed the way the C Requestobject is attached to the Perlobject,
so it should now also work on 64Bit Processor like Alpha.
Spotted by Andre Landwehr.
- Fixed a problem with importing files that contains foreach and
do until loops, which may caused a syntax error or endless
loop. Spotted by Steffen Geschke.
- embpcgi* and embpexec* are now geratated out of *.templ instead
of editied in place to avoid problems with cvs conflicts
and lower/uppercase on Win32. Suggest by Jens-Uwe Mager.
- make test works with Apache that has mod_jserv compiled in
- Embperl now cache same files with relative path, which are located
in different directories correctly.
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
