vanilla install failure 1.3.12/1.22/5.6.0
After much fast progress buiding a new machine, I'm stuck.
This is a vanilla RH6.2 box with almost nothing on it.. no
residue from RPM perl or httpd (deselected at machine blast time).
I've built perl 5.6.0 (all tested out ok), also built apache 1.3.12
both with and without Ben-SSL (all tested out ok).
The most basic Modperl 1.22 install attempt fails though: just with
a simple perl Makefile.PL and let it build vanilla httpd next door.
It builds a binary, and make test starts it, chucks a few requests
and it core dumps. The trace is below, followed at the end by
the perl -V output.
The segfault comes in the third test .. "GET LoadClass.pm", just
after it looks around for some .htaccess files
There isnt any sign in the errorlog.
help!?
thanks
-Justin
accept(16, {sin_family=AF_INET, sin_port=htons(1512),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 3
fcntl(18, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x80a05b4, [], SA_INTERRUPT|0x400}, 8) = 0
getsockname(3, {sin_family=AF_INET, sin_port=htons(8529),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
setsockopt(3, IPPROTO_TCP1, [1], 4) = 0
brk(0x8728000) = 0x8728000
alarm(300) = 0
read(3, "GET /test.html HTTP/1.0\r\nHost: l"..., 4096) = 79
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 956256085
alarm(300) = 300
alarm(0)= 300
stat("/work/mod_perl-1.22/t/docs/test.html", {st_mode=S_IFREG|0644, st_size=566, ...})
= 0
open("/work/mod_perl-1.22/t/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/work/mod_perl-1.22/t/docs/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/work/mod_perl-1.22/t/docs/test.html", O_RDONLY) = 4
old_mmap(NULL, 566, PROT_READ, MAP_PRIVATE, 4, 0) = 0x401de000
alarm(300) = 0
alarm(0)= 300
alarm(300) = 0
alarm(300) = 300
alarm(0)= 300
close(4)= 0
select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout)
write(3, "HTTP/1.1 200 OK\r\nDate: Thu, 20 A"..., 838) = 838
time(NULL) = 956256085
write(17, "127.0.0.1 - - [20/Apr/2000:14:41"..., 77) = 77
alarm(30) = 0
shutdown(3, 1 /* send */) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {2, 0})
read(3, "", 512)= 0
close(3)= 0
alarm(0)= 30
rt_sigaction(SIGUSR1, {0x80a05b4, [], SA_INTERRUPT|0x400}, {SIG_IGN}, 8) = 0
alarm(0)= 0
munmap(0x401de000, 566) = 0
fcntl(18, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
accept(16, {sin_family=AF_INET, sin_port=htons(1513),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 3
fcntl(18, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x80a05b4, [], SA_INTERRUPT|0x400}, 8) = 0
getsockname(3, {sin_family=AF_INET, sin_port=htons(8529),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
setsockopt(3, IPPROTO_TCP1, [1], 4) = 0
alarm(300) = 0
read(3, "GET /test.html HTTP/1.0\r\nHost: l"..., 4096) = 79
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 956256085
alarm(300) = 300
alarm(0)= 300
stat("/work/mod_perl-1.22/t/docs/test.html", {st_mode=S_IFREG|0644, st_size=566, ...})
= 0
open("/work/mod_perl-1.22/t/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/work/mod_perl-1.22/t/docs/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/work/mod_perl-1.22/t/docs/test.html", O_RDONLY) = 4
old_mmap(NULL, 566, PROT_READ, MAP_PRIVATE, 4, 0) = 0x401de000
alarm(300) = 0
alarm(0)= 300
alarm(300) = 0
alarm(300) = 300
alarm(0)= 300
close(4)= 0
select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout)
write(3, "HTTP/1.1 200 OK\r\nDate: Thu, 20 A"..., 838) = 838
time(NULL) = 956256085
write(17, "127.0.0.1 - - [20/Apr/2000:14:41"..., 77) = 77
alarm(30) = 0
shutdown(3, 1 /* send */) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {2, 0})
read(3, "", 512)= 0
close(3)= 0
alarm(0)= 30
rt_sigaction(SIGUSR1, {0x80a05b4, [], SA_INTERRUPT|0x400}, {SIG_IGN}, 8) = 0
alarm(0)= 0
munmap(0x401de000, 566) =
End failed -- Cleanup aborted and other errors
Hi, We are in the process of moving our site www.adalbadal.com from the web hosting company in India to iserver -- they do have mod_perl!!! Well during this process, some of our scripts are giving us: END failed--cleanup aborted at /dev/null line 6. Callback called exit at /dev/null line 6. and an occassional Out of memory! This server has Apache 1.3.11 Mod_perl 1.21 Do any of you have any ideas since these scripts work correctly on 3 other servers which have mod_perl? Thanks Gagan ** Web App Development Needs? *** Contact OSATech today! http://www.OSATech.com *** - Original Message - From: "Gunther Birznieks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 22, 2000 9:57 PM Subject: Re: Implementing security in CGI > At 09:42 AM 4/22/00 -0500, Michael Schout wrote: > >On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote: > > > The secure session has the following properties: > > > > > > *) The user is able to initiate a secure session by providing proper > > > credentials (i.e., a username and password pair) via a login process. > > > > > > *) The user is able to terminate the secure session via a logout > > > process. > > > > > > *) Secure sessions must be able to time out automatically. > > > > > > *) Secure sessions must *never* transmit sensitive data (such as the > > > password) over insecure channels. > > > >my Apache::TicketAccess module does all of this, but it uses Cookies for the > >transport mechanism. So if using cookies are okay, them Apache::TicketAccess > >may be a solution for some folks. > > You might want to consider adding a subclass that will hook into a handler > that will interpret a mangled URL with the session id if the cookie does > not exist in order to give people a choice. Then, have an API in the class > that can create the mangled URL on an as-needed basis for the web > application author to hook into. > > This is similar to how sessions in Java Servlets work. Cookies used by > defaults, but routines exist to help mangle the URLs for those that do not > wish to use them. > > Later, > Gunther > > __ > Gunther Birznieks ([EMAIL PROTECTED]) > Extropia - The Web Technology Company > http://www.extropia.com/ >
Re: Implementing security in CGI
At 09:42 AM 4/22/00 -0500, Michael Schout wrote: >On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote: > > The secure session has the following properties: > > > > *) The user is able to initiate a secure session by providing proper > > credentials (i.e., a username and password pair) via a login process. > > > > *) The user is able to terminate the secure session via a logout > > process. > > > > *) Secure sessions must be able to time out automatically. > > > > *) Secure sessions must *never* transmit sensitive data (such as the > > password) over insecure channels. > >my Apache::TicketAccess module does all of this, but it uses Cookies for the >transport mechanism. So if using cookies are okay, them Apache::TicketAccess >may be a solution for some folks. You might want to consider adding a subclass that will hook into a handler that will interpret a mangled URL with the session id if the cookie does not exist in order to give people a choice. Then, have an API in the class that can create the mangled URL on an as-needed basis for the web application author to hook into. This is similar to how sessions in Java Servlets work. Cookies used by defaults, but routines exist to help mangle the URLs for those that do not wish to use them. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Trying to setup embedded Perl
It seems as if this site is already running Apache/mod_perl (according to
Netcraft) so as long as you can get hold of the particular module
responsible for this then you should have no problems.
--
Edward Thomas | [EMAIL PROTECTED]
Cynosure Design | www.cyno.co.uk
- Original Message -
From: "Dennis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 22, 2000 5:13 PM
Subject: Trying to setup embedded Perl
Hey
can you throw some helpful hints on the problem I'm having ?
I'm trying to move a working site from singleslibrary.com to my server.
Unfortunately the guy who wrote the site for us is not available anymore ..
and nobody seems to know what to do, including me.
What I'm trying to do is setup the following:
I have HTML code, the one like in P.S.
and it seems to have Perl embedded in between <: > and
brackets
can Apache handle that ? do I need some other program ? Just wondering if
I can use apache to do that
P.S.
I took the following HTML/Perl parts from
http://singleslibrary.com/dynahtml/singles/sample.html
Do you have children?<:&field('chihome')>
EOF
<:&htmlselect( 'chil', CHIHOME, NULL )>
Do you drink?<:&field('drink')>
Do you smoke?<:&field('smoke')>
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: > > > > Does apache 2.0 let you run a prefork model under NT? > > > NT has it's own MPM which is threaded > > prefork ... Multi Process Model with Preforking (Apache 1.3) > dexter Multi Process Model with Threading via Pthreads > Constant number of processes, variable number of threads > mpmt_pthread .. Multi Process Model with Threading via Pthreads > Variable number of processes, constant number of > threads/child (= Apache/pthread) > spmt_os2 .. Single Process Model with Threading on OS/2 > winnt . Single Process Model with Threading on Windows NT > > I believe the first 3 run only under Unix. So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? Les Mikesell [EMAIL PROTECTED]
Re: httpd could not be started
It's a much simpler problem than I let on to before... (thanks matt@telepath) The error log shows what went wrong, but I am at a bit of a loss on how to correct it. [info] mod_unique_id: using ip addr my.valid.ip.address getpeername: Socket operation on non-socket getsockname: Socket operation on non-socket Error getting local address hostname returns the correct answer. I put "my.ip.x.x localhost" into /etc/hosts inetd is running, but all /etc/inetd.conf programs are commented out. I'm getting my IP from DHCP, but it is constant until midnight.
segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
I get a segfault on the first page access to Apache (it's just a request for / on the server). Backtrace: #0 0x402307db in perl_header_parser (r=0x8154e84) at mod_perl.c:1002 #1 0x8052715 in run_method (r=0x8154e84, offset=58, run_all=1) at http_config.c:360 #2 0x8052802 in ap_header_parse (r=0x8154e84) at http_config.c:397 #3 0x80613d5 in process_request_internal (r=0x8154e84) at http_request.c:1149 #4 0x80616ed in ap_process_request (r=0x8154e84) at http_request.c:1231 #5 0x805b099 in child_main (child_num_arg=0) at http_main.c:4177 #6 0x805b20c in make_child (s=0x809a114, slot=0, now=956437231) at http_main.c:4281 #7 0x805b333 in startup_children (number_to_start=5) at http_main.c:4363 #8 0x805b7dc in standalone_main (argc=2, argv=0xbd44) at http_main.c:4651 #9 0x805be9a in main (argc=2, argv=0xbd44) at http_main.c:4978 That line of mod_perl.c is "dPPDIR;" However, r->per_dir_config is NULL, so the get_module_config() call there ends up dereferencing a NULL pointer to generate the SEGV. Any hints on what I'm doing wrong, or how to fix this? Michael (please cc me on any responses; I've just now subscribed to the list)
Re: Implementing security in CGI
hi, most likely you will want to shut down cookies and use another method as per advisories that currently there is a problem with javascript and cookies when both enabled. b.t.w. exploder has simular problems so since javascript is nice to have cookies are a problem these days. besides most clueful users these days have cookies turned off.. Regards, [EMAIL PROTECTED]
Re: ANNOUNCE: Apache-TicketAccess 0.10
On Thu, Apr 20, 2000 at 02:16:09PM -0700, Doug MacEachern wrote: > On Tue, 18 Apr 2000, Michael J Schout wrote: > > > Apache-TicketAccess-0.10.tar.gz > > cool, but, there's already a module named Apache::TicketAccess, listed in > the apache-modlist.html: > > TicketAccess bdpOTicket based access/authentication MPB Does this entry in the apache-modlist exist anywhere? I looked for it on CPAN, but I cant even find MPB's directory on CPAN. If the module is no longer in existance, then maybe my module can replace it? I dont know what else I would name it. It is extremely similar to the TicketAccess system in the eagle book, with a lot of extra features added in. Mike
Re: Implementing security in CGI
On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote: > The secure session has the following properties: > > *) The user is able to initiate a secure session by providing proper > credentials (i.e., a username and password pair) via a login process. > > *) The user is able to terminate the secure session via a logout > process. > > *) Secure sessions must be able to time out automatically. > > *) Secure sessions must *never* transmit sensitive data (such as the > password) over insecure channels. my Apache::TicketAccess module does all of this, but it uses Cookies for the transport mechanism. So if using cookies are okay, them Apache::TicketAccess may be a solution for some folks. Mike
Trying to setup embedded Perl
Hey
can you throw some helpful hints on the problem I'm
having ?
I'm trying to move a working site from
singleslibrary.com to my server. Unfortunately the guy who wrote the site
for us is not available anymore .. and nobody seems to know what to do,
including me.
What I'm trying to do is setup the following: I
have HTML code, the one like in P.S.
and it seems to have Perl embedded in between
<: > and
brackets
can Apache handle that ? do I need some other
program ? Just wondering if I can use apache to do that
P.S.
I took the following HTML/Perl parts from http://singleslibrary.com/dynahtml/singles/sample.html
Do
you have children?<:&field('chihome')>EOF<:&htmlselect(
'chil', CHIHOME, NULL )>Do you
drink?<:&field('drink')>
Do
you smoke?<:&field('smoke')>
Re: httpd could not be started
Addenda: apachectl configtest shows everything is ok
httpd could not be started
I am trying to build httpd using DSO and mod_perl, mod_ssl and mod_php (but that one hasn't come up yet) I'm on an unpatched RedHat 6.1 with a newly built 5.6.0 perl (egcs 2.91.66) with mod_perl from CVS and mod_ssl-2.6.3-1.3.12 for apache_1.3.12 I didn't get ANY errors doing the configuration and makes! apachectl start results in "httpd could not ne started" This is my build procedure SSL stage all done according to mod_ssl-2.6.3-1.3.12/INSTALL :standard rsaref-2.0 worked perfectly :open_ssl-2.6.3-1.3.12 sh config -L`pwd`/../rsaref-2.0/local -fPIC worked fine :optional mm-1.0.12 installed :./configure --with-apache=/usr/local/apache MODPERL stage: : perl Makefile.PL EVERYTHING=1 PERL_TRACE=1 \ APACHE_SRC=../apache_1.3.12/src PREP_HTTPD=1 DO_HTTPD=1\ SSL_BASE=../mod_ssl-2.6.3-1.3.12 USE_DSO=1 : make : make install APACHE stage: : SSL_BASE=../mod_ssl-2.6.3-1.3.12 CC=/usr/bin/gcc \ RSA_BASE=../rsaref-2.0/local EAPI_MM=../mm-1.0.12 \ ./configure --prefix=/usr/local/apache \ --enable-module=most --enable-shared=all \ --enable-module=ssl --enable-shared=ssl \ --disable-rule=SSL_COMPAT --enable-rule=SSL_SDBM --enable-rule=SHARED_CORE : make : make certificate TYPE=custom : make install During this whole thing I didn't get a single error :) :httpd -l http_core.c mod_so.c Did I miss something with APXS? Thanks everyone. Peace.
Re: Implementing security in CGI
On Fri, 21 Apr 2000, Gunther Birznieks wrote: > At 01:44 PM 4/20/00 -0500, Matt Carothers wrote: > > >Another big win is that the secure token can persist across multiple > >servers. > > What would prevent the token from being across multiple servers otherwise? It's beneficial when compared to a non-token system like apache's basic auth, where your browser won't (or shouldn't anyway) send your credentials to multiple hosts, and you end up having to enter your password over and over. Regarding cookies vs. url mangling, you could use urls as easily as cookies. Just unpack your encrypted data into hex and shove it right into the url. It would make for some pretty long urls, but I've seen worse on search engines. :) > The nice thing about your encryption is that it makes the cookie into a > kind of pseudo client certificate -- providing information. But at the same > time, I would be concerned that that sort of Encryption overhead (on top of > SSL) seems like it would add load to the server. > > How does it work for you in real world use? It works great for my purposes, but my servers are very lightly loaded. > I suppose it poses an > interesting tradeoff... with that method you don't have to maintain real > session persistence since you have it in your decrypted data? So then you > can avoid an extra IO going to a database or flatfile to retrieve the > session info. > > Am I getting this correct? Exactly. It's a cpu vs. i/o tradeoff. It takes more processor power to decrypt/encrypt a cookie on each hit, but you only have to query the database once for each session. - Matt
[rfc/revised] Do Not Run Everything on One mod_perl Server
Here is a complete rewrite which comprises your responds on my initial post. Joshua, notice that this setup with smaller memory requirements and lots of shared memory gives even better results as it comes to the goal of having more servers using the same memory. In my hypotetical example below I've rised the number of servers from 40 to 90! I hope I didn't make any math mistakes, otherwise Ken will not accept me to his class (Hi, Ken :) A few more rewrites and I will use integrals to calculate mod_perl configuration ;) Enjoy! =head1 Do Not Run Everything on One mod_perl Server Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no code sharing). Typical numbers can be four megabytes of unshared and four megabytes of shared memory for each code set, plus three megabytes of shared basic mod_perl stuff. Which makes each process 17Mb in size when the two code sets are loaded. (3Mb (server) + 4Mb (shared 1st code set ) + 4Mb (unshared 1st code set ) + 4Mb (shared 2nd code set ) + 4Mb (unshared 2nd code set ). Where eleven megabytes are shared and eight megabytes not. We assume that four megabytes is the size of each code set unshared memory. This is pretty typical size of unshared memory, especially when connecting to databases, as the database connections cannot be shared, and especially DB's like Oracle take lots of RAM per connection. Let's assume that we have 260 megabytes of RAM dedicated for the webserver. According to the equation developed in the section: "L": Total_RAM - Max_Process_Size MaxClients = --- Max_Process_Size - Shared_RAM_per_Child MaxClients = (260 - 17)/(17-11) = 40 We see that we can run 40 processes, using the given memory and the two code sets in the same server. Now consider this practical decision. Since we have recognized that the code sets are very distinct in nature and there is no significant memory sharing in place, the wise thing to do is to split the two code sets between two mod_perl servers (a single mod_perl server actually is a set of the parent process and a number of the child processes). So instead of running everything on one server, now we move the second code set onto another mod_perl server. At this point we are talking about a single machine. Let's look at the figures again. After the split we will have 20 servers of eleven megabytes (4Mb unshared + 7mb shared) and another 20 servers of eleven megabytes. How much memory do we need now? From the above equation we derive: Total_RAM = MaxClients * (Max_Process_Size - Shared_RAM_per_Child) + Max_Process_Size And using the numbers: Total_RAM = 2 * (20 * (11-7) + 11) = 182 A total of 182 megabytes of memory required. But, hey, we have 260Mb of memory. We've got 78Mb of memory freed up. If we recalculate again the C we will see that we can run almost 60 servers: MaxClients = (260 - 11*2)/(11-8) = 60 So we can run about 20 more servers using the same memory size. 30 servers for each code set. We have enlarged the servers pool by a half without changing machine's hardware. Moreover this new setup allows us to fine tune the two code sets, since in reality the smaller in size code base might have a higher hit rate, so we can benefit even more. Let's assume that based on the usage statistics we know that the first code set is deployed in 70% of requests and the other 30% are used by the second set. Now we assume that the first code set requires only 5Mbytes of RAM (3Mb shared plus 2Mb unshared) over the basic mod_perl server size, and the second set needs 11Mbytes (7Mb shared and 4Mb unshared). Lets compare this new requirement with our original 50%/50% setup. So now the first mod_perl server running the first code set will have all its processes of 8Mb (3Mb (server shared) + 3Mb (code shared) + 2Mb (code unshared), and the second 14Mb (3+7+4). Given that we have a 70:30 hits relation and that we have 260Mbytes of available memory, we have to solve these two equations: X/Y = 7/3 X*(8-6) + 8 + Y*(14-10) + 14 = 260 where X is the total number of the processes the first code set can use and Y the second. The first equation reflect the 70:30 hits relation, and the second uses the equation for the total memory requirements for the given number of servers and the shared and unshared memory sizes. When we solve these equations, we get that X equals 63 and Y equals 27. So we have a total of 90 servers -- we have twice and a half more servers running compared to the original setup using the same memory size The hits rate optimized solution and the fact that the code sets can be different in their memory requirements, allowed us to run 30 more servers in total and gave us 33 more servers (63 versus 30) for the most wanted code base, relative to the simple 50:50 split as in the first example. Of course if you can identify more t
[ANNOUNCE] Apache::XMLStylesheet
I've completed my mapper. Rather than try and stuff modules into the type="..." attribute I decided it was best to just leave that as a content-type, and allow you to add mappings to you .htaccess or wherever you want them... I've also updated Apache::XPath::NotXSLT to use this module, and for some glorious reason I'm now getting 80 requests/sec. Very nice. It's all available on http://xml.sergeant.ord/download/ - I'll upload to CPAN after I hear back from people, or some other time if no interest is generated ;-) (PS: Appologies if anyone was trying to access xml.sergeant.org this afternoon - there seems to be a bug in mod_perl that I was grappling with to get this to work). Here's the README. Let me know if there are any questions. NAME Apache::XMLStylesheet - Execute module based on SYNOPSIS # in .htaccess PerlHandler +Apache::XMLStylesheet PerlSetVar StylesheetMap "text/xsl => XML::XSLT::transformfiles, \ application/x-mystyle => My::Style" PerlSetVar PreferredStyle "default style" DESCRIPTION This module automatically detects XML stylesheet types and associates modules/functions with those stylesheets according to the StylesheetMap variable. See http://www.w3.org/TR/xml- stylesheet for details on the xml-stylesheet processing instruction that this module uses. This module also checks for you whether the xml file and stylesheet files exist, so you don't need to check that in your template/stylesheet implementation if you don't want to. If an error occurs at any point it is logged in the error log, and DECLINED is returned, so that other Apache modules might have a chance to process the file. In the mapping you can either present a function (fully qualified with package), or a package. Different parameters are passed depending on whether you specify a function or a package: 'type' => Package::function The function receives the xml filename as the first parameter, and the stylesheet filename as the second parameter. The return value of the method is not considered, and Apache always returns OK. 'type' => Package The Package's handler() function is called, with the Apache::Request object as the first parameter, the xml filename as the second parameter and the stylesheet filename as the third parameter. Apache returns whatever the return value of the handler() function is. The PreferredStyle option will make use of the "alternate" attribute of the xml-stylesheet processing instruction. PerlFixupHandler If you install Apache::XMLStylesheet as a PerlFixupHandler, rather than an ordinary PerlHandler, the actual type handler gets called by pushing the handler onto the stack as a PerlHandler. The benefits of this are that it gives you better information from the Apache::Request object given as the first parameter. The downside is that it's significantly slower than installing as an ordinary PerlHandler (80 requests/sec vs 20 for a PerlFixupHandler). If anyone can tell me why its so much slower I'd love to know. Apache::MimeXML Originally this module required that Apache::MimeXML v0.03 or higher be installed, because this module sets the Apache notes table entry: is_xml => 1 However it appears that you can't operate PerlTypeHandlers _and_ PerlHandlers at the same time with mod_perl. I've logged a bug, and hopefully it will get fixed. In the meantime only files ending in .xml will be processed by this module, which isn't great. AUTHOR Matt Sergeant, [EMAIL PROTECTED] LICENSE This module is distributed under the same terms as Perl itself. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, Apr 22, 2000 at 11:59:58AM +0200, Eric Cholet wrote: > > though. Can anybody in the know, shed some light on this, just trying to > > save some work down the road as I'd like to upgrade to the perl 5.6 stuff > > now and use it with my existing mod_perl (I already use the CVS version > > and I know thats required for perl 5.6) but I really don't want to have > > recompile perl (and modules, etc) again later if I can build it the way > > it will need to be now and continue using mod_perl 1.x and then just upgrade > > to mod_perl 2.x down the road. > > mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns > on threading and multiplicity. The biggest hurdle I've faced until now is > that DBI won't build with this threaded perl. Hopefully DBI will be updated > since the latest version is from july 99. > This is for using Apache 2.0's pthread MPM, of course you can build perl > 5.6 non threaded and use apache 2.0's prefork model but then it's not > as exciting :-) Thinking about it now after your message and it makes sense. I've actually been a bit lazy and still have one of the older CVS versions (pre alpha) of Apache 2.0, guess I don't know about the alphas but I was playing with both the threaded, dexter MPM's. Since dexter is kind of a hybrid but uses threads I assume it'll also need a threaded perl then. At one time I did build a threaded perl but ran into problems here and there with various modules, etc. Don't recall having any problems with DBI but then again it wasn't perl 5.6 either, that is kind of a show stopper though :-( All in all I guess I found out the answer, might just as well go for it and build 5.6 threaded, grab the lastest Apache 2.x alpha and take what comes. Its my play box anyways so I guess I can live with some things being broken :-) -- Didn't I see your picture on a milk carton ? Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: PerlHandler stopped working???
On Sat, 22 Apr 2000, Matt Sergeant wrote: > The only thing I can think of, is that Apache::MimeXML is somehow stopping > the PerlHandler phase from being executed. Can it do that (but still allow > the PerlFixupHandler phase to execute)??? OK, it was Apache::MimeXML... Which is very odd indeed. A bug in mod_perl by the looks of things. All I'm returning from Apache::MimeXML, btw, is OK or DECLINED. It was returning OK when PerlHandler stopped working. For now I'll disable it, and set Mime types manually for .xml files - but something is seriously not right there. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: mod_perl 2.x/perl 5.6.x ?
> > This is for using Apache 2.0's pthread MPM, of course you can build perl > > 5.6 non threaded and use apache 2.0's prefork model but then it's not > > as exciting :-) > > Does apache 2.0 let you run a prefork model under NT? NT has it's own MPM which is threaded prefork ... Multi Process Model with Preforking (Apache 1.3) dexter Multi Process Model with Threading via Pthreads Constant number of processes, variable number of threads mpmt_pthread .. Multi Process Model with Threading via Pthreads Variable number of processes, constant number of threads/child (= Apache/pthread) spmt_os2 .. Single Process Model with Threading on OS/2 winnt . Single Process Model with Threading on Windows NT I believe the first 3 run only under Unix. -- Eric
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: > > This is for using Apache 2.0's pthread MPM, of course you can build perl > 5.6 non threaded and use apache 2.0's prefork model but then it's not > as exciting :-) Does apache 2.0 let you run a prefork model under NT? Les Mikesell [EMAIL PROTECTED]
Re: [OT] Proxy Nice Failure
According to Jim Winstead: > On Apr 21, Michael hall wrote: > > I'm on the new-httpd list (as a lurker, not a developer :-). Any ideas, > > patches, help porting, etc. would be more than welcome on the list. > > Mod-Proxy is actually kind of in limbo, there are some in favor of > > dropping it and others who want it. I guess the code is difficult and > > not easy to maintain and thats why some would just as soon see it go > > unless someone steps up to maintain (redesign) it. There are some > > working on it and apparently it will survive in some form or another. > > Now would be a perfect time for anybody to get involved in it. > > mod_backhand may also be the solution people are after. > > http://www.backhand.org/ Is anyone using this in production? It has the disadvantage of requiring itself to be compiled into both the front and back ends. I have some backend data being generated by custom programs running on NT boxes and would like to have a fail-over mechanism. We may end up running Windows load balancing on them, but that means paying for Advanced Server (about $3k extra) on each of them when a smart proxy would work just as well. I also didn't see how to access it through mod_rewrite which is how I control most of my proxy access. This might be possible by letting backhand handle certain directories and RewriteRules to map to those directories - I just didn't get that far yet. > (Sorry for the off-topic-ness.) > > I'm also coming around to the idea that caching proxies have some > very interesting applications in a web-publishing framework outside > of caching whole pages. All sorts of areas to exploit mod_perl in > that sort of framework. This can help with the load on a backend, but after watching squid logs for a while I decided that a lot of extra traffic is passed through when users hit the 'refresh' button which will send the 'Pragma: no-cache' header with the request. For things like images you may be better off using RewriteRules on the front end to short-circuit the request, and other popular pages that should update only at certain intervals can be done with cron jobs and delivered from the front end as well. So, from a mod_perl perspective I don't care much about the caching side but really need the relationship between mod_rewrite and mod_proxy. I haven't found equivalent built-in functionality in any other server. Les Mikesell [EMAIL PROTECTED]
PerlHandler stopped working???
I'm so confused... I can't get my PerlHandler to work. It works sort of fine as a PerlFixupHandler - only if I return "OK" from that it then appends the entire file again to the end :( This is mod_perl 1.22, and it's a .htaccess file I'm trying to define it in. Here's the file: __BEGIN__ DirectoryIndex index.xml index.html # I added this but it made no difference Options +ExecCGI # this is required to set the MIME type. PerlTypeHandler +Apache::MimeXML SetHandler perl-script # offending line!!! PerlFixupHandler Apache::XMLStylesheet PerlSetVar StylesheetMap "notxslt => Apache::XPath::NotXSLT" __END__ When I change the "offending line" to: PerlHandler Apache::XMLStylesheet I just get the default handler - i.e. it gives me the raw index.xml file, rather than processing it. I have no idea what's going on here... Also, I can't seem to push_handlers(PerlHandler => ...) either - that just runs the default handler as well. What's strange about this, is on the same server I have a couple of modules working just fine as a PerlHandler, and even in a .htaccess file. The only thing I can think of, is that Apache::MimeXML is somehow stopping the PerlHandler phase from being executed. Can it do that (but still allow the PerlFixupHandler phase to execute)??? -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: mod_perl-1.99_01-dev [ - possibly OT ]
- Original Message -
From: "Gerald Richter" <[EMAIL PROTECTED]>
To: "Greg Cope" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: 22 April 2000 13:36
Subject: RE: mod_perl-1.99_01-dev
> >
> > Does this mean that we {will|may} be able to use the interpreter pool
to
> > set up X Perl interpreters (say 20 to service dynamic handlers) with Z
> > apache (say 60 to handle static + dynamic content - assuming the dynamic
> > content is passed to the Perl interpreters) children, and hence have
> > significant memory savings as we can avoid (in some cases) the
> > light / heavy
> > httpd model ?
> >
>
> If you use only threads (instead of processes) to handle request by
Apache,
> the answer is yes :-)
Going a little off topic here ...
I though the new apache model was a hybrid were there were preforked
children that then used threads - have I missed the plot here ?
Or is it either a preforked child model or a threaded model ?
Greg
>
> 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 925151
> WWW:http://www.ecos.de Fax: +49 6133 925152
> -
>
>
Re: do "file" -- does NOTHING
On Fri, 21 Apr 2000, w trillich wrote:
> the entire listing for startup.pl is:
>
> package Apache::ReadConfig;
>
> Apache->httpd_conf("Clavis");
> Apache->httpd_conf("");
> Apache->httpd_conf(" 1/2%3'*");
> Apache->httpd_conf("isn't this wonderful?");
You need to use() the Apache module in order to access its methods. Add
this to the top of your startup.pl:
BEGIN
{
use Apache();
}
- Matt
RE: mod_perl-1.99_01-dev
>
> Does this mean that we {will|may} be able to use the interpreter pool to
> set up X Perl interpreters (say 20 to service dynamic handlers) with Z
> apache (say 60 to handle static + dynamic content - assuming the dynamic
> content is passed to the Perl interpreters) children, and hence have
> significant memory savings as we can avoid (in some cases) the
> light / heavy
> httpd model ?
>
If you use only threads (instead of processes) to handle request by Apache,
the answer is yes :-)
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 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
RE: mod_perl 2.x/perl 5.6.x ?
> I'm more of a perl end user and plead ignorance in actually understanding > what goes on behind the scenes. In the process of considering upgrading to > perl 5.6 and according to a recent message I see its going to be required > for mod_perl 2.x anyways so I guess its a good time to start migrating in that > direction. I was curious as to if there are requirements as to how perl > should be built for this. I scanned through the archives as I seemed to > remember some threads about this awhile ago, especially regarding threads > and multiplicity, from what I can see it looks like -DMULTIPLICITY is > going to be required ?, don't know about -DTHREADS, doesn't look like it > though. Can anybody in the know, shed some light on this, just trying to > save some work down the road as I'd like to upgrade to the perl 5.6 stuff > now and use it with my existing mod_perl (I already use the CVS version > and I know thats required for perl 5.6) but I really don't want to have > recompile perl (and modules, etc) again later if I can build it the way > it will need to be now and continue using mod_perl 1.x and then just upgrade > to mod_perl 2.x down the road. mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns on threading and multiplicity. The biggest hurdle I've faced until now is that DBI won't build with this threaded perl. Hopefully DBI will be updated since the latest version is from july 99. This is for using Apache 2.0's pthread MPM, of course you can build perl 5.6 non threaded and use apache 2.0's prefork model but then it's not as exciting :-) -- Eric
Re: mod_perl-1.99_01-dev
- Original Message -
From: "Doug MacEachern" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 21 April 2000 06:51
Subject: mod_perl-1.99_01-dev
> eric and stas already let the cat out of the bag, but i was planning to
> give a summary of what's in progress for mod_perl-2.0 anyhow :)
> i've included a summary of the pieces i'm currently working on, there's a
> great deal left to do, but it's looking good and moving along fast.
> i'll be putting these design notes into cvs soon, along with a
> bigger-picture plan, which should make it easy to see where folks can help
> out if you're interested...
This is excellent news - I was going to ask what the status of
mod_perl.pre-2.X !
> interpreter pool
>
>
> this logic is only enabled if Perl is built with -Dusethreads
> otherwise, mod_perl will behave just as 1.xx, using a single
> interpreter, which is only useful if you're using the prefork mpm.
This may be a question born of ignorance / inexperience but here goes:
Does this mean that we {will|may} be able to use the interpreter pool to
set up X Perl interpreters (say 20 to service dynamic handlers) with Z
apache (say 60 to handle static + dynamic content - assuming the dynamic
content is passed to the Perl interpreters) children, and hence have
significant memory savings as we can avoid (in some cases) the light / heavy
httpd model ?
Or have I missed the plot vis-a-vi apache 2.0 and threads ?
>
> i'm also interested in shane's "garbage collector", which could also
> run in it's own thread, examining the padlists of idle interpreters
> and deciding to release and/or report large strings, array/hash sizes,
> etc., that Perl is keeping around as an optimization.
Adding in the garbage collector would also be a massive bonus if people do
allot of sorting / data manipulation / sort term caching in RAM (Perl).
Again thanks for the good news.
Greg Cope
Re: Problem with CGI::Carp under mod_perl
At 02:02 PM 4/18/00 +0100, Steve Hay wrote: >I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl >scripts. Sorry for the late reply. I was actually trying to figure out why you were experiencing this problem. I rarely use Perl 5.005 specific features, and so I actually received reasonable results where you were not. It turns out that CGI::Carp does a specific check for Perl 5.005 and above and uses a different mechanism that asks whether it is in an eval block. Unfortunately the $^S variable gives information that is not precisely the same as the error string parsing (for "eval") technique in it's effectiveness under mod_perl. Of course, do take what I say with a grain of salt. I am NOT the author of CGI::Carp. But I do like using it because it is more convenient than using an outer eval block in every CGI script. I have emailed the author of CGI::Carp with this issue today and hopefully should receive confirmation or negation of this theory within the next few days unless others on here can confirm or deny the rumors. >Below are three short scripts and their output under Apache/CGI and >Apache/modperl. All three of them produce (more or >less) useful output under Apache/CGI, but only the last one does under >Apache/modperl. > >The first one calls die() itself. Under Apache/CGI the die() message >appears in the web browser (albeit preceded by a >spurious Content-Type line), but under Apache/modperl the message goes >to the error.log and a bizarre message appears in >the web browser consisting of some output from the script, followed by a >"200 OK" HTTP header, followed by a message >suggesting that all was not OK after all (all the same as if CGI::Carp >was not being used). > >The second one has a syntax error. Under Apache/CGI a message about a >compilation error appears in the web browser (but not >the detail of the syntax error itself, which disappears completely - not >even going to error.log!); under Apache/modperl an >"Internal Server Error" message appears in the web browser (again just >like CGI::Carp was not being used) and (curiously) >the detail of the syntax error does now at least appear in error.log! > >The third one attempts a division by zero and correctly says so in the >web browser under both Apache/CGI and >Apache/modperl. > >Can anybody explain what's going on here??? Yes. Albeit a little late. Sorry about that. >The first script is closest to the problem I've really got. I'm using >DBI/DBD::mysql and I want SQL syntax errors (which I >keep making) to appear in the web browser instead of having to keep >opening the error.log. Running under Apache/CGI I get >useful messages like: > >Software error: >DBD::mysql::st execute failed: You have an error in your SQL syntax near >'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 >at d:/inetpub/cgi-bin/mysql.pl line 300. > >but under Apache/modperl I just get useless garbage like the >error_die.pl below produces. > >I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. > > >error_die.pl > > > use CGI::Carp qw(fatalsToBrowser); > $| = 1; > print "Content-Type: text/html\n\n"; > print "I'm about to die() ...\n"; > die "I'm dead.\n"; > >Apache/CGI: > >I'm about to die() ... Content-type: text/html >Software error: >I'm dead. >For help, please send mail to the webmaster ([EMAIL PROTECTED]), >giving this error message and the time and date of >the error. > >Apache/modperl: > >I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 >GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 >Connection: close Content-Type: text/html >OK >The server encountered an internal error or misconfiguration and was >unable to complete your request. >Please contact the server administrator, [EMAIL PROTECTED] and >inform them of the time the error occurred, and >anything you might have done that may have caused the error. >More information about this error may be available in the server error >log. This should work as you expected. The reason why it did not is because of the Perl 5.005 check. Go into your CGI::Carp.pm file and look for the ineval() method. Manually edit it to remove the 5.005 check and just compile an ineval() routine that is dependent on longmess() instead of $^S. >error_syntax.pl >--- > > use CGI::Carp qw(fatalsToBrowser); > $| = 1; > print "Content-Type: text/html\n\n"; > print "Syntax error at the end of this line ...\n" > print "blah blah blah.\n"; > >Apache/CGI: > >Software error: >Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to >compilation errors. >For help, please send mail to the webmaster ([EMAIL PROTECTED]), >giving this error message and the time and date of >the error. > >Apache/modperl: > >Internal Server Error >The server encountered an internal error or misconfiguration and was >unable to complete your request. >Please contact the server administrator, [EMAIL PROTECTED] and >inform them of th
Re: Problem with CGI::Carp under mod_perl
At 12:46 PM 4/18/00 +0100, Matt Sergeant wrote: >On Tue, 18 Apr 2000, Steve Hay wrote: > > > I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl > scripts. > >Then don't use CGI::Carp. The whole qw(fatalsToBrowser) thing is broken, >IMHO, anyway. See http://modperl.sergeant.org/guide/exceptions.html for >a better way to handle exceptions. I looked at this today. I believe the problem started with Perl version 5.005 where Lincoln Stein started using $^S to detect if CGI::Carp is in an eval block. If you comment out that code and use the longmess() code inside of ineval() that is active for Perl versions below 5.005, fatalsToBrowser seems to work OK. I have emailed Lincoln Stein to confirm whether this makes sense. Although I only tested it in a few limited cases, so I don't know if 5.005 introduced new types of evaling that never existed in 5.004 where fatalsToBrowser worked fine. Only compile time errors are not caught. But that is as I stated in a previous message, because when you compile code in an eval, it is not a fatal error... it is a warning. I don't know if your guide is necessarily a "better" way to deal with errors than CGI::Carp when CGI::Carp actually works. ;) Although, I would concede it is a better way of dealing with exceptions. Important point that I would like to interject: Exceptions != Errors. die() by it's nature is not OO. It is a typical crash and dump because I got a fatal error type of situation. It is certainly idomatic to use die in a procedural way even in OO programs and exception handling is not always easier to read or understand even amongst experienced programmers of Perl (or even Java). Although Perl and Java are two different languages and arguably like comparing apples to oranges... I think it can be successfully argued that Java has had a lot more people looking at OO programming theory (and practice) because they were forced to by the language. So sometimes pulling out a Java article discussing a particular topic can help. In this case, Bill Venners (known for his articles on practical OO design) has the following article: http://www.javaworld.com/javaworld/jw-07-1998/jw-07-exceptions_p.html In it, Bill Venners discusses the difference between checked and unchecked exceptions. In essence, the theory is posed that errors are unchecked exceptions (this is the only error mechanism in Java). Typically what happens is that even in Java, most programmers do not bother with unchecked exceptions and allow them to bubble up the stack until the Java program dies. This is similar to what you expect in Perl for a truly fatal error. For generically checking fatal errors, I would at least posit that (when it works) CGI::Carp provides a useful tool so that you don't have to wrap the entire program in one huge eval block where uncaught errors would finally drop into the eval. The need to display fatal errors generically to a browser is not the same as constructive exception checking that programmers would do when looking for particular error conditions. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Problem with CGI::Carp under mod_perl
At 06:38 PM 4/19/00 -0700, Perrin Harkins wrote:
> > > CGI::Carp can't catch compile errors.
> >
> > Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
> > control the output message): "In order to correctly intercept compile-time
> > errors, you should call set_message() from within a BEGIN{} block. ", which
> > suggests it does catch compile errors? I've tried both with "BEGIN
> > {set_message('...')}" and without a set_message() at all, but to no avail.
>
>My mistake. CGI::Carp doesn't catch compile errors inside an eval block,
>which is where you are when compiling under Apache::Registry. You could
>work around this by commenting out the first line of the die() subroutine
>where it checks to see if it's in an eval, but that's pretty lame and
>makes CGI::Carp incompatible with use of eval blocks. I don't use
>Apache::Registry or CGI::Carp, so I'm not very motivated to find a better
>fix. You could contact the author.
Actually I do not believe that this will help anyway. The reason being that
when you compile code in an eval, it is not a die error in the first place.
It ends up being a warning (so you need to trap the WARN signal).
To do this, Apache::Registry itself would need to be the one catching the
compilation error in a WARN signal and then outputting something to the
browser.
I don't know of a real way around this. However, I did spend some time
investigating these issues today and will post some of my results to
previous messages.
__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
