Re: Apache::DProf seg faulting
On Wed, 17 Apr 2002, Paul Lindner wrote: I think that this may be a problem with the use of Perl sections. I believe your original post had something like this: Perl use Apache::DProf use Apache::DB Apache::DB-init(); /Perl Nope. That was Perrin Harkins, but I tried it too! Geoffrey and I tested our environments today and the recipe given in the book seems to work just fine: PerlModule Apache::DB PerlModule Apache::DProf With those lines I get a seg-fault on the first hit to the server. Reversing the lines I can get a few hits before seg-faulting. I doubt it's a problem in your example - something inside Devel::DProf is seg-faulting as far as I can tell. I'm planning to build a debugging Perl and see if I can get more information. But while I have your attention, why are you using Apache::DB at all? The Apache::DProf docs just have: PerlModule Apache::DProf -sam
Re: Sharing Variable Across Apache Children
What will happen if the client's DNS caches the domain name to an IP, which is then dead ? If I understand it corrently, the current system can work only if there is something like NAT in front of the machines, which dynaimcally forward each request. Won't it ? Peter Bi - Original Message - From: Medi Montaseri [EMAIL PROTECTED] To: Andrew Ho [EMAIL PROTECTED] Cc: Benjamin Elbirt [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 9:08 PM Subject: Re: Sharing Variable Across Apache Children You had us going for a whileI thought you are talking about some distributed session management (accross different boxes) Another suggestion is to use lbnamed. lbnamed is a DNS server and Load Balancing server that listens to port 53 and resolves IPs, but on the other side of its personality it talks to bunch of agents who are running on workers. You get to set what the parameters or criteria is and assign a cost factor for a worker. lbnamed then distributes the work on the lightest/least cost worker. In this scenario, whence a box is out (or its critical piece like Oracle, or HTTP server) then no further work is routed to it . Also, be aware that using CNAME in DNS does not provide a uniform distribution of load. Imagine a web page having 20 images and another 5 images. You'll not know with good certainty that if your heavy work like database access is really being distributed. With CNAME you do have a chance of developing harmonics. CNAME (aka round robin) is totally unaware of the load on the worker. Maybe that's why your boxes are bulking See http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html Andrew Ho wrote: Hello, BELet me explain in more detail what I'm doing. So if the situation you explain is the only reason you want a variable shared load balanced machines, I'd suggest a totally different way of doing this altogether. Best would be to use an already shared persistent storage mechanism (NFS or Oracle) but it looks like Oracle warnings are precisely what you want distinct alerts on (why are you getting so many Oracle errors anyway? that might be the first thing you want to check). I'm assuming the number of warning e-mails you get is less than 450,000 / 5 == 90,000 each day, so that if each warning e-mail were a web request, a single box could handle them (if more than 1/5 of your requests result in errors, you REALLY want to just fix the problem first). So put up a single webserver box to serve as an error reporter and logger. You could either use distributed logging (like mod_log_spread) or simpler, just set up another webserver that takes requests like /record_error.pl?error_msg=fooremote_addr=bar or whatever. Your error handlers on your five load-balanced boxes send an HTTP request to this error handling box. All error e-mails can originate from this box, and the box can internally keep a lookup table (using any of the fine techniques discussed by the folks here) to avoid sending duplicate errors. In this scenario error handling is offloaded to another box, and as a bonus you can track the aggregate number of errors each day in an automated way and run reports and such (without having to count e-mails in your inbox). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
Re: Apache/Mod_Perl in Production Env-- NOT Recommended in Windows?
At 03:48 18.04.2002, Arul, Rex wrote: Friends, I know Apache/Mod_Perl on OS other than Windows to be the trend du juor. However, I am in jitters seeing this explicit warning given in http://www.perl.com web-portal. NOTE: it is not recommended to use Windows for production Apache/mod_perl servers; Apache/mod_perl 1.x is not able to scale well on this platform; Apache/mod_perl 2.x is addressing the fundamental architectural disagreements that cause this. The article is here:http://www.perl.com/pub/a/2002/03/12/axkit.html?page=2 Has anyone in this list use Apache/Mod_Perl in **WINDOWS OS** under **Production Environment **? Well, the issue on Windows is that the mod_perl server can only serve one request at a time. So clearly, it's a problem. However, some people have reported that it would still give them a great performance increase, by following some special steps. Get a proxy setup like described at various places in the guide http://perl.apache.org/guide/ : the proxy serves most of the requests, and sends some requests off to the backend mod_perl enabled server. Good caching should be a plus: the less requests sent to the mod_perl-enabled server the better. This isn't all too different from standard mod_perl setups, but you have to watch out even more when running on Windows. You might even want to try and setup several backend mod_perl servers and load balance between them, all depending on how much memory you can spare. -- Per Einar Ellefsen [EMAIL PROTECTED]
newbie - installation problems
Hi there! I can't manage very well with Apache and mod_perl. I have made an installation of mod_perl WITHOUT building a new httpd daemon (NO_HTTPD=1), undergoing all the steps until the end (perl MAKEFILE_PL, make, make install). After that, I read on the Stas Bekman's guide at http://perl.apache.org/guide that mod_perl can albe installed as DSO, via apxs. The question is: 1. Is it possible to do a new installation of mod_perl as DSO that 'overrides' (so to say) the (incomplete) preceding one or there is the risk to mess up things worse? 2. If this risk exists, I should procede with the old installation BUT what would I get at the end? Mod_perl statically built inside Apache? 3. Is there a procedure to 'uninstall' the (incomplete) installation made so far? Thanks in advance, Carlo.
Re: Compiling mod_perl 1.99 on Solaris 8
Darragh Sherwin wrote: Hi, I am trying to compile mod_perl 1.99 with apacche 2.0.35, I give up with mod_perl 1.24 after numberous headaches and lots of profanties. It build configured Apache with following options : ./configure --with-mpm=prefork --prefix=/export/home/website/apache --enable-so --with-port=80 --enable-info I then did a make and make install for Apache Then I configured mod_perl with the following options: perl Makefile.PL MP_AP_PREFIX=../httpd-2.0.35 (httpd-2.0.35 is the source of apache) then I edit all the Makefiles for mod_perl, so the compiler use the option -DUSE_ITHREADS, then I did a make and make install, I got out a mod_perl.so file and put this under the Apache $PREFIX/modules and edit my httpd.conf to correspond, when I start apache, I get the following error: Cannot load /export/home/website/apache/modules/mod_perl.so into server: ld.so.1: /export/home/website/apache/bin/httpd: fatal: relocation error: file /export/home/website/apache/modules/mod_perl.so: symbol PL_thr_key: referenced symbol not found Can anybody tell me, if I am configuring something wrong, or building it the wrong way?? I need to get a quick resolution to this problem, so any help is greatly appreciated Why did you have to manually edit the Makefiles? All the Perl flags are automatically used in the build process, so if you have build perl with -Dusethreads, it's all you need to do. Also why do you need to use MP_AP_PREFIX? Use MP_APXS= instead. You don't need Apache sources to build mod_perl as DSO. Please refer to this document: http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/install/install.html And when you report a problem, please do as explained here; http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/help/help.html#Reporting_Problems __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Inline generation of error document?
Hi all, I'm a little confused (honestly). I want to handle parameter errors in a content handler. When there's a parameter missing in the URL, my handler returns HTTP_BAD_REQUEST. Now Apache sees the HTTP_BAD_REQUEST return value from my handler and generates an error (HTML) document. How can I create this document right from within my handler? I could create another handler of course and use the ErrorDocument directive to point to that but I am wondering if I can do it in my handler directly. Somehow I can't find this in the eagle book. Any tips? Bas.
RE: Re: Apache/Mod_Perl in Production Env-- NOT Recommended inWindows?
Thanks Per. But should the stoic silence for this poser of mine, be construed as there are NO takers out there who have their Web Sites in Production, running out of Apache 1.XX and Mod-Perl 1.XX on Windows NT/2000? Primarily we are a Microsoft shop, and I would like to answer this question to my bosses (if possible). Thanks, Rex Per Einar Ellefsen [EMAIL PROTECTED] wrote: This isn't all too different from standard mod_perl setups, but you have to watch out even more when running on Windows. You might even want to try and setup several backend mod_perl servers and load balance between them, all depending on how much memory you can spare. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: Inline generation of error document?
Bas A. Schulte wrote: Hi all, I'm a little confused (honestly). I want to handle parameter errors in a content handler. When there's a parameter missing in the URL, my handler returns HTTP_BAD_REQUEST. Now Apache sees the HTTP_BAD_REQUEST return value from my handler and generates an error (HTML) document. How can I create this document right from within my handler? I could create another handler of course and use the ErrorDocument directive to point to that but I am wondering if I can do it in my handler directly. Somehow I can't find this in the eagle book. look for $r-custom_response HTH --Geiff
RE: Re: Apache/Mod_Perl in Production Env-- NOT Recommended inWindows?
At 16:57 18.04.2002, Arul, Rex wrote: Thanks Per. But should the stoic silence for this poser of mine, be construed as there are NO takers out there who have their Web Sites in Production, running out of Apache 1.XX and Mod-Perl 1.XX on Windows NT/2000? Primarily we are a Microsoft shop, and I would like to answer this question to my bosses (if possible). Well, I wouldn't say it's undoable. You could try it out and see if it works for you. But I wouldn't take my word for it, because it depends on many factors (especially the number of concurrent connections). What I can suggest is that you take a look at PerlEx from ActiveState. For Windows, it might be a better choice, although it costs a little money. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Compiling mod_perl 1.99 on Solaris 8
Hi, Stas Bekman wrote: Darragh Sherwin wrote: Hi, I am trying to compile mod_perl 1.99 with apacche 2.0.35, I give up with mod_perl 1.24 after numberous headaches and lots of profanties. It build configured Apache with following options : ./configure --with-mpm=prefork --prefix=/export/home/website/apache --enable-so --with-port=80 --enable-info I did this with the enviromental varible CFLAGS=-DUSE_ITHREADS I then did a make and make install for Apache Then I configured mod_perl with the following options: perl Makefile.PL MP_AP_PREFIX=../httpd-2.0.35 (httpd-2.0.35 is the source of apache) I used perl Makefile.PL MP_APXS=/export/home/website/apache/bin/apxs MP_CCOPTS=-DUSE_ITHREADS The ITHREADS library is need on Solaris/Sparc to compile then I edit all the Makefiles for mod_perl, so the compiler use the option -DUSE_ITHREADS, then I did a make and make install, I got out a mod_perl.so file and put this under the Apache $PREFIX/modules and edit my httpd.conf to correspond, when I start apache, I get the following error: Cannot load /export/home/website/apache/modules/mod_perl.so into server: ld.so.1: /export/home/website/apache/bin/httpd: fatal: relocation error: file /export/home/website/apache/modules/mod_perl.so: symbol PL_thr_key: referenced symbol not found However, I am still getting the above error, should I just copy the mod_perl.so file from the mod_perl sources directory to the $APACHE/modules?? I am right in doing that?? Can anybody tell me, if I am configuring something wrong, or building it the wrong way?? I need to get a quick resolution to this problem, so any help is greatly appreciated Why did you have to manually edit the Makefiles? All the Perl flags are automatically used in the build process, so if you have build perl with -Dusethreads, it's all you need to do. Also why do you need to use MP_AP_PREFIX? Use MP_APXS= instead. You don't need Apache sources to build mod_perl as DSO. Please refer to this document: http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/install/install.html I read this, but it was of little help And when you report a problem, please do as explained here; http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/help/help.html#Reporting_Problems __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- ___ Darragh Sherwin [EMAIL PROTECTED] To alcohol, the cause of, and solution to, all of life's problems Homer Simpson
Re: Compiling mod_perl 1.99 on Solaris 8
On Thu, 18 Apr 2002, Darragh Sherwin wrote: I did this with the enviromental varible CFLAGS=-DUSE_ITHREADS ... MP_CCOPTS=-DUSE_ITHREADS you can't do that. and that is the source of your problems. if you are going to use a threaded mpm, *perl* needs to be built with ithreads enabled. perl's generated config.h will then have #define USE_ITHREADS which modperl will get compiled with.
Re: Compiling mod_perl 1.99 on Solaris 8
On Thu, 18 Apr 2002, Stas Bekman wrote: Also why do you need to use MP_AP_PREFIX? Use MP_APXS= instead. You don't need Apache sources to build mod_perl as DSO. MP_AP_PREFIX is not the source tree, it is the install tree. all modperl needs is the include/ directory from the install tree, it does not need apxs. MP_AP_PREFIX works everywhere. MP_APXS does not work on windows.
Help with Apache::DBI
I implemented Apache::AuthCookieDBI for the logins to my web site. AuthCookieDBI requires Apache::DBI. This all works great. I have also started using embperl. This seems to work fairly good as well except it inherited the Apache::DBI from my AuthCookieDBI implementation. Now I get 6 database connections per apache process. Does anyone know a simple way for my embperl pages not to use Apache::DBI, or would it be easy for me to make AuthCookieDBI use the regular DBI module? Thanks, Woody
[OT] Encrypting Embedded URLs
Hi, I'm looking for a two-way cipher to obfuscate URL parameters safely and succinctly (not too many extra characters). # For example, something that converts this URL: $url = 'http://www.foo.com?a=1212u=http://www.foo1.com?a=12323'; # to an encoded URL with the parameters obfuscated print Simple::URLEncode($url); # that looks like this: http://www.foo.com?params=aJHKJHKJHKJHHGHFTDTDGDFDFGDGHDHG879879 A built-in checksum would be a bonus ... any ideas? Thanks Nigel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: [OT] Encrypting Embedded URLs
# For example, something that converts this URL: $url = 'http://www.foo.com?a=1212u=http://www.foo1.com?a=12323'; # that looks like this: http://www.foo.com?params=aJHKJHKJHKJHHGHFTDTDGDFDFGDGHDHG879879 Why are you trying to do this? What's the goal here? xoox, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$) [unpack'C*',n2]3%+\34.'%.'^%4+!o.'])
Re: [OT] Encrypting Embedded URLs
Nigel Hamilton writes: http://www.foo.com?params=aJHKJHKJHKJHHGHFTDTDGDFDFGDGHDHG879879 A built-in checksum would be a bonus ... any ideas? You can use any of the Crypt::CBC ciphers. We then use a modified MIME::Base64 encoding which is more compact than encrypt_hex and doesn't require a subsequent escaping for URI specials. See http://petshop.bivio.biz/src?s=Bivio::MIME::Base64 for the simple algorithm (the error checking hack on MIME::Base64::decode may no longer be necessary with newer versions of MIME::Base64). Rob
Re: [OT] Encrypting Embedded URLs
# For example, something that converts this URL: $url = 'http://www.foo.com?a=1212u=http://www.foo1.com?a=12323'; # that looks like this: http://www.foo.com?params=aJHKJHKJHKJHHGHFTDTDGDFDFGDGHDHG879879 Why are you trying to do this? What's the goal here? HI, So it's not easy for someone to read the parameters ... and also because sometimes embedded URL's parameters are not interpreted correctly - for example the a parameter below: $url = 'http://www.foo.com?a=1212u=http://www.foo1.com?a=12323'; Nige -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
[ANN] Multiple user website app framework, Apache::Onanox
Apache::Onanox is a framework for multi-user websites. It supports user customisation and theming. It has a document management facility. It is currently in beta testing. It is my final project for my university degree and I'm looking for feedback to put into my report. If you try it out, I'd appreciate it if you'd let me know what you think. You can get it from CPAN or http://russell.matbouli.org/code/apache-onanox Thanks -- Russell Matbouli | SOY! SOY! SOY! Soy makes you strong! [EMAIL PROTECTED] | Strength crushes enemies! SOY! PGP KeyID: 0x3CA84CF4 | msg26745/pgp0.pgp Description: PGP signature
Re: Solaris 8 lockups
What version apache/mod_perl are you running? Also, were these intel solaris 7 servers or sparc? We've recently started trying to migrate a number of Solaris 7 machines to Solaris 8, and everything seemed fine for a while. We have each box running its own static, dynamic (mod_perl) and ssl servers, and everything runs fine for 3-7 hours after starting the server. Eventually, however, the mod_perl children just stop responding. If you try to telnet into the port, the connection just hangs why trying to connect...we don't get a refused connection, and it doesn't let you connect to the point where you can issue an HTTP request. It just seems to stop responding and get stuck. Has anyone else run into any of these problems? So far we've had nothing like this happen with Solaris 7 and with Linux, but I can't even think where to start looking on Solaris 8. As a side note, this happened both on boxes that had been upgraded from 7 to 8, as well as boxes that had fresh 8 installs.
Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
On Thu, Apr 18, 2002 at 10:19:09AM -0700, Fernando Munoz wrote: Thanks for your input Stas. I followed (step-by-step) the installation suggested in the guide and I ended with the same message after .. # perl Makefile.PL USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_PREFIX=/usr/local/apachessl \ APACHE_SRC=../apache_x.x.x/src \ APACI_ARGS='--enable-module=ssl,--enable-module=rewrite' . . . # make make test make install . . . ./gen_test_char test_char.h ld.so.1: ./gen_test_char: fatal: libssl.so.0.9.6: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target 'test_char.h' Current working directory /Repository/apache_1.3.24/src/main *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' I'm new with Solaris and it's starting to frustrate me. BTW I'm using binutils-2.11.2. Thanks for any help. I had this problem last week. If you *HAVE* libssl.so.0.9.6 on your system (which I assume you do, since you are using --enable-module=ssl), you need to make sure that ldconfig sets up your system's dynamic library paths properly or that your LD_LIBRARY_PATH environment variable has the correct directory in it. Go for the former, I'd say, but in my case, I merely did this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib And everything worked, because libssl had been previously installed with a prefix of /usr/local. -- \_/} Mark P. Fister Java, Java, everywhere, and all\_/} \_/} eBay, Inc. the cups did shrink; Java, Java\_/} \_/} Austin, TX everywhere, nor any drop to drink! \_/}
Re: Solaris 8 lockups
We're running Apache 1.3.12, as for the mod_perl version, it's not reported in the logs when the servers start and there doesn't seem to be any source lying around, so I'm not sure how to determine its version number. If you could point me in the right direction on that, I'd appreciate it. It's running on Sparc hardware. Brian Nilsen [EMAIL PROTECTED] On Thu, 18 Apr 2002, Marc Slagle wrote: What version apache/mod_perl are you running? Also, were these intel solaris 7 servers or sparc? We've recently started trying to migrate a number of Solaris 7 machines to Solaris 8, and everything seemed fine for a while. We have each box running its own static, dynamic (mod_perl) and ssl servers, and everything runs fine for 3-7 hours after starting the server. Eventually, however, the mod_perl children just stop responding. If you try to telnet into the port, the connection just hangs why trying to connect...we don't get a refused connection, and it doesn't let you connect to the point where you can issue an HTTP request. It just seems to stop responding and get stuck. Has anyone else run into any of these problems? So far we've had nothing like this happen with Solaris 7 and with Linux, but I can't even think where to start looking on Solaris 8. As a side note, this happened both on boxes that had been upgraded from 7 to 8, as well as boxes that had fresh 8 installs.
Re: Solaris 8 lockups
Nevermind about mod_perl version number, looks like we're running 1.24 Brian Nilsen [EMAIL PROTECTED] On Thu, 18 Apr 2002, Marc Slagle wrote: What version apache/mod_perl are you running? Also, were these intel solaris 7 servers or sparc? We've recently started trying to migrate a number of Solaris 7 machines to Solaris 8, and everything seemed fine for a while. We have each box running its own static, dynamic (mod_perl) and ssl servers, and everything runs fine for 3-7 hours after starting the server. Eventually, however, the mod_perl children just stop responding. If you try to telnet into the port, the connection just hangs why trying to connect...we don't get a refused connection, and it doesn't let you connect to the point where you can issue an HTTP request. It just seems to stop responding and get stuck. Has anyone else run into any of these problems? So far we've had nothing like this happen with Solaris 7 and with Linux, but I can't even think where to start looking on Solaris 8. As a side note, this happened both on boxes that had been upgraded from 7 to 8, as well as boxes that had fresh 8 installs.
Solaris 8 lockups
We've recently started trying to migrate a number of Solaris 7 machines to Solaris 8, and everything seemed fine for a while. We have each box running its own static, dynamic (mod_perl) and ssl servers, and everything runs fine for 3-7 hours after starting the server. Eventually, however, the mod_perl children just stop responding. If you try to telnet into the port, the connection just hangs why trying to connect...we don't get a refused connection, and it doesn't let you connect to the point where you can issue an HTTP request. It just seems to stop responding and get stuck. Has anyone else run into any of these problems? So far we've had nothing like this happen with Solaris 7 and with Linux, but I can't even think where to start looking on Solaris 8. As a side note, this happened both on boxes that had been upgraded from 7 to 8, as well as boxes that had fresh 8 installs. Brian Nilsen [EMAIL PROTECTED]
Re: [OT] Encrypting Embedded URLs
Hi ( 02.04.18 17:32 -0500 ) Nigel Hamilton: I'm looking for a two-way cipher to obfuscate URL parameters safely and succinctly (not too many extra characters). If you just want to obfuscate, you can do a rot13, with special substitutions for non alpha charachters. Or any other 'roll your own' solution [XOR against 'snakeoil' then URL encode what needs it]. Something else requires that you think about key management [or public key cryptography], to say nothing of threat models. -- \js transition turn-key applications
RE: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks -Original Message- From: Mark P. Fister [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 10:39 AM To: Fernando Munoz Cc: 'Stas Bekman'; '[EMAIL PROTECTED]' Subject: Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp ! On Thu, Apr 18, 2002 at 10:19:09AM -0700, Fernando Munoz wrote: Thanks for your input Stas. I followed (step-by-step) the installation suggested in the guide and I ended with the same message after .. # perl Makefile.PL USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_PREFIX=/usr/local/apachessl \ APACHE_SRC=../apache_x.x.x/src \ APACI_ARGS='--enable-module=ssl,--enable-module=rewrite' . . . # make make test make install . . . ./gen_test_char test_char.h ld.so.1: ./gen_test_char: fatal: libssl.so.0.9.6: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target 'test_char.h' Current working directory /Repository/apache_1.3.24/src/main *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' I'm new with Solaris and it's starting to frustrate me. BTW I'm using binutils-2.11.2. Thanks for any help. I had this problem last week. If you *HAVE* libssl.so.0.9.6 on your system (which I assume you do, since you are using --enable-module=ssl), you need to make sure that ldconfig sets up your system's dynamic library paths properly or that your LD_LIBRARY_PATH environment variable has the correct directory in it. Go for the former, I'd say, but in my case, I merely did this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib And everything worked, because libssl had been previously installed with a prefix of /usr/local. -- \_/} Mark P. Fister Java, Java, everywhere, and all\_/} \_/} eBay, Inc. the cups did shrink; Java, Java\_/} \_/} Austin, TX everywhere, nor any drop to drink! \_/}
Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Fernando Munoz wrote: Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks seems to me that you've run apache's ./configure again after you have configured mod_perl, which wiped off the modperl config. See if you didn't mess up with the order of things. You should have a Makefile and a bunch of modperl files in src/modules/perl after you run 'perl Makefile ...' __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [OT] Encrypting Embedded URLs
Hello, JSIf you just want to obfuscate, you can do a rot13, with special JSsubstitutions for non alpha charachters. Or any other 'roll your own' JSsolution [XOR against 'snakeoil' then URL encode what needs it]. For simple obfuscation, I would prefer Base64 (using MIME::Base64 in Perl). It's simple, fast, standard, results in string totally composed from a well known character set that needs little further encoding, and well known with implementations in just about any language. You don't need to do anything special for non-alphanumeric characters, either (or indeed, for 8-bit data, which is the whole point of Base64 encoding). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: mod_perl Basic Authentication problem using PerlAuthenHandler
Thank you... cant believe I missed that... was to excited about the ability to do my own auth program I added allow from x.x.x.x and it worked great Thank you. - Original Message - From: Geoffrey Young [EMAIL PROTECTED] To: Jason [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 6:21 PM Subject: Re: mod_perl Basic Authentication problem using PerlAuthenHandler Jason wrote: In httpd.conf i have Location /~jter [snip] Deny from all /Location [snip] It warns to the log file and returns But the problem is, why does my browser come up forbidden I suspect Deny from all is the issue... the PerlAccessHandler will run before the apache default mod_access gets the chance to implement the Deny rule. on a successful login, your PerlAccessHandler will return OK, which is then denied by mod_access, resulting in a FORBIDDEN message. unlike with the PerlAuthenHandler, which immediately terminates on the first OK, the PerlAccessHandler will keep going in search of failure. Has anybody gotten this to sucessfully work? yes :) you may be interested in chapter 13 of the cookbook, which should help clarify things somewhat. --Geoff
Restarting named service
Hi, How can i restart the named service via mod_perl. The script will be activated via a web page. My apache is configured to use "User: apache, Group: apache" Is ther any other way except usine "User root"directive in my httpd.conf file Hamid
Re: Restarting named service
You could use sudo and give the apache user permission to run, as root, whichever command you use to restart the server. Steve On Thu, 18 Apr 2002, Abd El-Hameed Mohammed wrote: Hi, How can i restart the named service via mod_perl. The script will be activated via a web page. My apache is configured to use User: apache, Group: apache Is ther any other way except usine User root directive in my httpd.conf file Hamid -- === Stephen M. Gray www.frontiermedia.net
Re: Restarting named service
or you would be safer running your name server as named as opposed to root. STEVE You could use sudo and give the apache user permission to run, as root, whichever command you use to restart the server. Steve On Thu, 18 Apr 2002, Abd El-Hameed Mohammed wrote: Hi, How can i restart the named service via mod_perl. The script will be activated via a web page. My apache is configured to use User: apache, Group: apache Is ther any other way except usine User root directive in my httpd.conf file Hamid -- === Stephen M. Gray www.frontiermedia.net
Re: [OT] Encrypting Embedded URLs
Nigel Hamilton wrote: I'm looking for a two-way cipher to obfuscate URL parameters safely and succinctly (not too many extra characters). Try Crypt::CBC. - Perrin
Re: Restarting named service
On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote: or you would be safer running your name server as named as opposed to root. STEVE It should be run as named, but trying to start and stop it as the named user won't get you very far if you plan on using port 53. :-) === Stephen M. Gray www.frontiermedia.net
Re: Solaris 8 lockups
We had problems with that combination of apache/mod_perl, on solaris 8 as well. We switched to mod_perl 1.25 and that fixed our problems. Since then we have also moved to newer versions of apache. I would build a newer version of apache/mod_perl on one of the systems and then leave the configuration the same. (Assuming you can do that, some work environments are locked down to older versions of software.) It would be interesting to see what truss reported when you hit the server when it was not responding. - Original Message - From: Tom Servo [EMAIL PROTECTED] To: Marc Slagle [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, April 18, 2002 2:14 PM Subject: Re: Solaris 8 lockups Nevermind about mod_perl version number, looks like we're running 1.24 Brian Nilsen [EMAIL PROTECTED] On Thu, 18 Apr 2002, Marc Slagle wrote: What version apache/mod_perl are you running? Also, were these intel solaris 7 servers or sparc? We've recently started trying to migrate a number of Solaris 7 machines to Solaris 8, and everything seemed fine for a while. We have each box running its own static, dynamic (mod_perl) and ssl servers, and everything runs fine for 3-7 hours after starting the server. Eventually, however, the mod_perl children just stop responding. If you try to telnet into the port, the connection just hangs why trying to connect...we don't get a refused connection, and it doesn't let you connect to the point where you can issue an HTTP request. It just seems to stop responding and get stuck. Has anyone else run into any of these problems? So far we've had nothing like this happen with Solaris 7 and with Linux, but I can't even think where to start looking on Solaris 8. As a side note, this happened both on boxes that had been upgraded from 7 to 8, as well as boxes that had fresh 8 installs.
pnotes notes and subprocess_env
Folks,
I don't seem to be able to make pnotes, notes or subprocess_env work. I
am trying to pass a value from a handler to another, and from what I
have read in the Eagle, and cook book, the request ought to be the main
one in order for the pnotes, ... to work. So Here is the snippet of my
code:
.
.
.
$r-pnotes(STICKY = hello world);
$r-custom_response(FORBIDDEN, /secureDB/Login);
return FORBIDDEN;
.
.
.
package secureDB::Login;
sub handler
{
my $r = shift;
$r = ($r-is_main ? $r : $r-main);
my $object = undef;
my $notes = $r-pnotes(STICKY);
warn notes = $notes\n;
#$object-{query}= $r-args ||
$r-content;
#$object-{path} = $r-uri();
#$object-{FILE} = secureLogin.html;
#getUserInfo($object,$uid);
makeTemplate($object,$r);
return OK;
}
1;
Noe I have tried subprocess_env, notes, and pnotes, but none seem to
work. I have to warn you that I can not use Apache::Request-instance()
because of my Apache version.
I appreciate all the help.
Thanks in advance
-r
Re: pnotes notes and subprocess_env
* Rasoul Hajikhani [EMAIL PROTECTED] [2002-04-18 16:29]: I don't seem to be able to make pnotes, notes or subprocess_env work. I am trying to pass a value from a handler to another, and from what I have read in the Eagle, and cook book, the request ought to be the main one in order for the pnotes, ... to work. So Here is the snippet of my code: I've seen situations where $r-main does not actually return the main request instance, and code like this has worked: $r = $r-main until ($r-is_main); No explanation, but I've seen it necessary in a few cases. In the case of main requests, it has no effect, so it's safe to include. (darren) -- Democracy is a form of government where you can say what you think, even if you don't think.
Re: Restarting named service
* Stephen Gray [EMAIL PROTECTED] [2002-04-18 15:34]: On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote: or you would be safer running your name server as named as opposed to root. STEVE It should be run as named, but trying to start and stop it as the named user won't get you very far if you plan on using port 53. :-) Have a (caching?) nameserver on port 53 that forwards everything to localhost:5353, which is running as the web server user and can be restarted randomly. (darren) -- He who has never configured `sendmail.cf' has no courage. He who has configured it more than once has no brain.
Re: [OT] Encrypting Embedded URLs
Hi, I read about this the other day... lemesee where did I read this... Oh yes! In Web Security, Privacy and Commerce by Simson Garfinkel, p. 453-454. The perl code is on those pages. Elizabeth Nigel Hamilton [EMAIL PROTECTED] writes: Hi, I'm looking for a two-way cipher to obfuscate URL parameters safely and succinctly (not too many extra characters). # For example, something that converts this URL: $url = 'http://www.foo.com?a=1212u=http://www.foo1.com?a=12323'; # to an encoded URL with the parameters obfuscated print Simple::URLEncode($url); # that looks like this: http://www.foo.com?params=aJHKJHKJHKJHHGHFTDTDGDFDFGDGHDHG879879 A built-in checksum would be a bonus ... any ideas? Thanks Nigel -- Nigel Hamilton Turbo10 Metasearch Engine email:[EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.comSearch Deeper. Browse Faster.
RE: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp !
Thank you very much Stas and Mark !... Everything went fine and I have a fresh Apache+mod_perl+mod_ssl running is this box. I noticed though that after rebooting I need to push again the path into $LD_LIBRARY_PATH for apache to run ??? any suggestion ?. But again Thanks so much. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 11:23 AM To: Fernando Munoz Cc: 'Mark P. Fister'; '[EMAIL PROTECTED]' Subject: Re: Problem Installing mod_perl + mod_ssl in Solaris 8 - Please H elp ! Fernando Munoz wrote: Well I tried your suggestion and it didn't work at first but, after revising my steps I noticed that $LD_LIBRARY_PATH did not have /usr/local/ssl/lib (where libssl libraries live) so I push that path there and ssl passed. Unfortunately I got a different problem now .. === src/modules/ssl === src/modules/perl make: Fatal error: Don't know how to make target 'all' Current working directory /Repository/apache_1.3.24/src/modules/perl *** Error code 1 make: Fatal error: Command failed for target 'all' Current working directory /Repository/apache_1.3.24/src/modules *** Error code 1 make: Fatal error: Command failed for target 'subdirs' Current working directory /Repository/apache_1.3.24/src *** Error code 1 make: Fatal error: Command failed for target 'build-std' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'build' Current working directory /Repository/apache_1.3.24 *** Error code 1 make: Fatal error: Command failed for target 'apaci_httpd' It seems that I'm closer but not there yet. Thanks seems to me that you've run apache's ./configure again after you have configured mod_perl, which wiped off the modperl config. See if you didn't mess up with the order of things. You should have a Makefile and a bunch of modperl files in src/modules/perl after you run 'perl Makefile ...' __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Redhat 7.2 glibc update causes problems with Apache::Cookie?
I recently applied the glibc updates described at http://www.redhat.com/support/errata/RHBA-2002-056.html to a system running Apache 1.2.22/modperl 1.2.26 on a Perl 5.6.1/Redhat Linux 7.2 system. All seemed well until I updated Apache::Cookie to the latest version and restarted apache. Apache failed to start and I got the following error messages: Starting httpd: [Thu Apr 18 13:42:14 2002] [error] Can't load '/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 2/usr/lib/perl5/site_perl/5.6.1/i386-linux06. at /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/mod_perl.pm line 14 Compilation failed in require at /usr/local/apache/mason/handler.pl line 33. BEGIN failed--compilation aborted at /usr/local/apache/mason/handler.pl line 33. Compilation failed in require at (eval 5) line 1. /usr/local/apache/bin/apachectl start: httpd could not be started I can find Cookie.so at the directory: drwxr-xr-x2 root root 4096 Apr 18 08:25 . drwxr-xr-x 11 root root 4096 Dec 8 15:32 .. -r--r--r--1 root root0 Nov 19 08:57 Cookie.bs -r-xr-xr-x1 root root16669 Apr 18 08:25 Cookie.so I suspect that this is an issue with the glibc update not Apache::Cookie since I'm also having similar problems with Image::Magick and Time::HiRes (modules I haven't updated) while updated modules like Storable still work. Can anyone confirm this problem? Thanks,
Re: Redhat 7.2 glibc update causes problems with Apache::Cookie?
Edward Moon wrote: I recently applied the glibc updates described at http://www.redhat.com/support/errata/RHBA-2002-056.html to a system running Apache 1.2.22/modperl 1.2.26 on a Perl 5.6.1/Redhat Linux 7.2 system. All seemed well until I updated Apache::Cookie to the latest version and restarted apache. Apache failed to start and I got the following error messages: Starting httpd: [Thu Apr 18 13:42:14 2002] [error] Can't load '/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at looks like you have a broken or missing binary package. It says exactly what's your problem - it cannot find the library. Check that you have the right symlinks from libapreq.so.1.0.0 to libapreq.so.1, or whatever it is. Have you tried building from the sources? perl -MCPAN -eshell cpan install Apache::Cookie __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Redhat 7.2 glibc update causes problems with Apache::Cookie?
I did that Stas. I forgot to mention that I updated Apache::Cookie via CPAN. On Fri, 19 Apr 2002, Stas Bekman wrote: [snip] looks like you have a broken or missing binary package. It says exactly what's your problem - it cannot find the library. Check that you have the right symlinks from libapreq.so.1.0.0 to libapreq.so.1, or whatever it is. Have you tried building from the sources? perl -MCPAN -eshell cpan install Apache::Cookie __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem with Perl sections in httpd.conf, mod_perl 1.26
On Thu, Apr 18, 2002 at 11:15:15PM -0500, Salvador Ortiz Garcia babbled thus: Subject: Re: Problem with Perl sections in httpd.conf, mod_perl 1.26 From: Salvador Ortiz Garcia [EMAIL PROTECTED] To: PinkFreud [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Mailer: Ximian Evolution 1.0.3 Date: 18 Apr 2002 23:15:15 -0500 On Mon, 2002-04-15 at 23:17, PinkFreud wrote: I have a rather odd problem, one which I can only assume is a bug somewhere, due to how bizarre it is. I am attmempting to generate virtual host configs via mod_perl, using Perl sections in httpd.conf. Not all hosts will be using a /perl Alias, though, so I'm reading in an external config, which looks like the following: [ Deleted ] Plese try changing your Alias array ref to a simple scalar: ... 'Alias' = '/perl/ /home/vhosts/linuxhelp.mirkwood.net/perl/', ... That should work. Nope. Still can't find it. What gets me is the syntax I use for Alias works just fine when the code is in httpd.conf. It only fails to work when I read it in via a require'd file. This same behavior occurs when I use your syntax in the require'd file as well. /me scratches his head, perplexed. And yes, I think its an old bug in perl_handle_command_av. Salvador Ortiz. -- Mike Edwards Brainbench certified Master Linux Administrator http://www.brainbench.com/transcript.jsp?pid=158188 --- Unsolicited advertisments to this address are not welcome.
Throttling, once again
Hi, Wasn't there just a thread on throttling a few weeks ago? I had a machine hit hard yesterday with a spider that ignored robots.txt. Load average was over 90 on a dual CPU Enterprise 3500 running Solaris 2.6. It's a mod_perl server, but has a few CGI scripts that it handles, and the spider was hitting one of the CGI scripts over and over. They were valid requests, but coming in faster than they were going out. Under normal usage the CGI scripts are only accessed a few times a day, so it's not much of a problem have them served by mod_perl. And under normal peak loads RAM is not a problem. The machine also has bandwidth limitation (packet shaper is used to share the bandwidth). That combined with the spider didn't help things. Luckily there's 4GB so even at a load average of 90 it wasn't really swapping much. (Well not when I caught it, anyway). This spider was using the same IP for all requests. Anyway, I remember Randal's Stonehenge::Throttle discussed not too long ago. That seems to address this kind of problem. Is there anything else to look into? Since the front-end is mod_perl, it mean I can use mod_perl throttling solution, too, which is cool. I realize there's some fundamental hardware issues to solve, but if I can just keep the spiders from flooding the machine then the machine is getting by ok. Also, does anyone have suggestions for testing once throttling is in place? I don't want to start cutting off the good customers, but I do want to get an idea how it acts under load. ab to the rescue, I suppose. Thanks much, -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Throttling, once again
On Friday 19 April 2002 6:55 am, Bill Moseley wrote: Hi, Wasn't there just a thread on throttling a few weeks ago? I had a machine hit hard yesterday with a spider that ignored robots.txt. I thought the standard practice these days was to put some URL at an un-reachable place (by a human), for example using something like a href=.../a. And then ban that via robots.txt. And then automatically update your routing tables for any IP addresses that try and visit that URL. Just a thought, there's probably more to it. Matt.
