Embeded perl question
I am having trouble returing a variable from a sub?...below is my effort to do this...is there some fundamental place where i am going wrong and can you help me?!...thanks [$ sub get_date $] [- $var = shift; $path = ("/home/genoccaj/public_html/lookup/"); use File::stat; $inode = stat($path.$var) or die "Couldn't stat file : $!"; $mtime = $inode->mtime; $size = $inode->size; use Time::localtime; $tm = localtime($mtime); $year = $tm->year+1900; $month = $tm->mon; $mday = $tm->mday; @months = ("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"); $mth = $months[$month]; $date = ($mday."-".$mth."-".$year); return[$date]; -] [+ $date +] [+ $var +] [$ endsub $] [- use DirHandle; $path = ("/home/genoccaj/public_html/lookup/"); %files = (); %filedates = (); opendir(TXT, $path); while (defined($file = readdir TXT )) { if ($file =~ /states/ && $file !~ /zip/ ) { $filedates{states} = get_date($file) } if ($file =~ /nacs/ && $file !~ /zip/ ) { $filedates{nacs} = get_date($file) } } closedir(TXT); -] [+ $filedates{states} +] [+ $filedates{nacs} +]
Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote: >ken, i have a feature request too :) i would like to be able to test if >mod_include is linked static with httpd, otherwise Makefile.PL will >disable PERL_SSI. a hash of parsed `httpd -l`, something like: > >my $static_modules = Apache::test->http_static_modules; > >if ($static_modules->{mod_include}) { >... >} Okey dokey Doug, here's a patch. I cleaned up _read_existing_conf() too because it was pretty hard to understand. === RCS file: /home/cvspublic/modperl/lib/Apache/test.pm,v retrieving revision 1.19 diff -u -r1.19 test.pm --- test.pm 2000/10/02 21:06:19 1.19 +++ test.pm 2000/10/10 06:47:00 @@ -138,13 +138,12 @@ } sub _read_existing_conf { -# Returns some config text -shift; -my ($server_conf) = @_; +# Returns some "(Add|Load)Module" config lines, generated from the +# existing config file and a few must-have modules. +my ($self, $server_conf) = @_; - open SERVER_CONF, $server_conf or die "Couldn't open $server_conf: $!"; -my @lines = grep {!m/^\s*#/} ; +my @lines = grep {!m/^\s*\#/} ; close SERVER_CONF; my @modules = grep /^\s*(Add|Load)Module/, @lines; @@ -154,41 +153,47 @@ foreach (@modules) { s!(\s)([^/\s]\S+/)!$1$server_root/$2!; } - -# Directories where apache DSOs live. -my (@module_dirs) = map {m,(/\S*/),} @modules; - -# Have to make sure that dir, autoindex and perl are loaded. -my @required = qw(dir autoindex perl); -my @l = `t/httpd -l`; -my @compiled_in = map /^\s*(\S+)/, @l[1..@l-2]; +my $static_mods = $self->static_modules('t/httpd'); my @load; -foreach my $module (@required) { - if (!grep /$module/i, @compiled_in, @modules) { +# Have to make sure that dir, autoindex and perl are loaded. +foreach my $module (qw(dir autoindex perl)) { + unless ($static_mods->{"mod_$module"} or grep /$module/i, @modules) { + warn "Will attempt to load mod_$module dynamically.\n"; push @load, $module; } } +# Directories where apache DSOs live. +my @module_dirs = map {m,(/\S*/),} @modules; + # Finally compute the directives to load modules that need to be loaded. MODULE: foreach my $module (@load) { foreach my $module_dir (@module_dirs) { - if (-e "$module_dir/mod_$module.so") { - push @modules, "LoadModule ${module}_module $module_dir/mod_$module.so\n"; next MODULE; - } elsif (-e "$module_dir/lib$module.so") { - push @modules, "LoadModule ${module}_module $module_dir/lib$module.so\n"; next MODULE; - } elsif (-e "$module_dir/ApacheModule\u$module.dll") { - push @modules, "LoadModule ${module}_module $module_dir/ApacheModule\u$module.dll\n"; next MODULE; + foreach my $filename ("mod_$module.so", "lib$module.so", +"ApacheModule\u$module.dll") { + if (-e "$module_dir/$filename") { + push @modules, "LoadModule ${module}_module +$module_dir/$filename\n"; next MODULE; + } } } + warn "Warning: couldn't find anything to load for 'mod_$module'.\n"; } - -print "found the following modules: \n@modules"; + +print "Adding the following dynamic config lines: \n@modules"; return join '', @modules; } +sub static_modules { +# Returns a hashref whose keys are each of the modules compiled +# statically into the given httpd binary. +my ($self, $httpd) = @_; + +my @l = `$httpd -l`; +return {map {lc($_) => 1} map /(\S+)\.c/, @l}; +} + # Find an executable in the PATH. sub which { foreach (map { "$_/$_[0]" } split /:/, $ENV{PATH}) { @@ -628,6 +633,14 @@ response. In a list context, fetch() returns the content and the HTTP::Response object itself. This can be handy if you need to check the response headers, or the HTTP return code, or whatever. + +=head2 static_modules + + Example: $mods = Apache::test->static_modules('/path/to/httpd'); + +This method returns a hashref whose keys are all the modules +statically compiled into the given httpd binary. The corresponding +values are all 1. =head1 EXAMPLES === ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: PerlWarn On being ignored on win32
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote: > Hi, > I have problems having mod_perl show his warnings: setting PerlWarn to On, > nothing appears into the ErrorLog. > I tried to change che LogLevel down to "debug": other messages do appear, > but not the perl warnings. > > I'm using Perl 5.6.0, mod_perl 1.24, apache 1.3.12 as localhost. The same > script issues warnings, as expected, using linux as web-server. > > This is the area in my httpd.conf file: > --- > LoadModule perl_module modules/ApacheModulePerl.dll > PerlWarn On > ScriptAlias /perl/test/ q:/web/perl/test/ > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options +ExecCGI > > --- > > What am I missing ? > Any help would be appreciated, thanks. > Franco > Hi, Can you supply a stripped down version of a script which illustrates this? On my Win32, PerlWarn works with a simple script: #!/Perl/bin/perl.exe print "Content-type: text/html\n\n"; my $x; print "$x"; This is with the current cvs mod_perl version, though. Are you also running perl-5.6.0/mod_perl-1.24/apache_1.3.12 on your linux machine? best regards, randy kobes
Re: Bug in mod_perl
[EMAIL PROTECTED] (Greg Williams) wrote: >>I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive >>no output after the \0. Is this a mod_perl or Apache bug? Or is it a >>client bug (using Netscape 4.75) or is it the expected behavior. > >It would be expected, I'd assume. perl5-porters discussed this back >in January when phrack ran an article claiming it was a 'bug' with >security implications. To summarize, this isn't really bug, but >merely what you'd expect when the PV gets passed to a C function >which expects a NULL terminated string. > >http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html I think I disagree with not calling this a bug. The entire p5p discussion was about the fact that *system calls* will see \0 as the end-of-string character, which in some cases is kind of a bad thing. However, Dave's code is just trying to send some *data* to the browser. It appears that $r->print (or somewhere down in the Apache code) can't handle embedded nulls, which I think should be either documented or fixed. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Third post. PLease help. PerlHandler configuration question.
On Mon, 9 Oct 2000, Todd Chapman wrote: > That only solves half the problem. Since it is a virtual directory, how > will Apache::Registry know where 'cgifile' really exists so it can run it? Either put it under your docroot or use the standard Alias stuff: Alias /perl/ /home/httpd/perl/ See http://thingy.kcilink.com/modperlguide/config/Alias_Configurations.html for more. - Perrin
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
On Mon, Oct 09, 2000 at 05:03:44PM -0700, Joshua Chamas wrote: > When I execute $Request->Form->('test')->Item() > on a real life code sample, even after building in > support for $Request->Form('test')->Item(), I get > this error: > > Not a CODE reference at (eval 14) line 10. > > I have seen this error before with this syntax... > is this really supposed to work? I thought it > was not supposed to be supported by perl. I saw > that it passed compilation, but perl saves some things > for runtime checking. It works in VBScript because > that language has the notion of a default method for > an object class to cover these instances. Those syntaxes are saying two separate things. $Request->Form('test')->Item() calls the method `Form' on the object `$Request' with argument `test', and calls the method `Item' with no arguments on the result. $Request->Form->('test')->Item() calls the method `Form' on the object `$Request' with no arguments, and calls the return value as a subroutine with argument `test'. Thus, if `Form' doesn't return a coderef, it will crash and burn. -dlc
Re: Third post. PLease help. PerlHandler configuration question.
Thanks. It seems like I would want to write a PerlTransHandler. However I don't want to change the filename until after the authorization phase. Can I change the uri to filename mapping at the end of the authorization phase but before the content handler phase? Thanks. -Todd On Mon, 9 Oct 2000, Tom Brown wrote: > > > > I am servicing requests from a virtual document tree. Most of the time I > > want the request to be serviced by a PerlHandler module I wrote. However, > > if the requested filename is 'cgifile' I would rather have > > Apache::Registry handle the request, but since this is a virtual document > > tree the CGI program 'cgifile' is located in a real directory somewhere > > else. > > > > 1. How would I configure this behavior? > > mod_rewrite, or write your own URL -> file mapping utility that ties into > an early request phase > > > > > 2. Would I have to locate 'cgifile' in the document tree or could it be > > located anywhere accessible by the httpd process? > > anywhere... > > > > > Thanks! > > > > -Todd > > > > > > > > -- > [EMAIL PROTECTED] | Drive thy business, or it will drive thee. > http://BareMetal.com/ | - Benjamin Franklin > web hosting since '95 | >
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
So what you are saying is that either this: > my $uid = $Request->QueryString('foo')->Item(); or this > $Request->QueryString->Item('foo')->Item() works natively in PerlScript. I see, so with the CollectionItem Apache::ASP config, I will enable the latter to work too. The other way around from what you are telling me is in IIS/PerlScript > use Win32::OLE qw(in valof with OVERLOAD); which makes things like $Request->QueryString('foo') work compatible with Apache::ASP. This is right because when I implemented the Apache::ASP functionality I was working to be compatible with above setting. I believe that you also need to use the above to get $Session->{item} functionality which is also native to Apache::ASP. So either way you are going to have a special config for this. I don't mind putting it in, but it can't be both ways at the same time unfortunately. I'll send you a copy which does this separately. -- Joshua
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
On Oct 09, [EMAIL PROTECTED] contorted a few electrons to say... Joshua> $Request->QueryString->('foo')->Item() isn't valid perl syntax, Joshua> is it? Are you going for $Request->QueryString('foo')->Item() Joshua> support here? yes $Request->QueryString('foo')->Item() seems to be the way AP618 wants you to convert the WIN32::OLE object to a perl string as in: my $uid = $Request->QueryString('foo')->Item(); without the item it fails horribly in PerlScript. Joshua> Joshua> There is already a Collection class that is used to emulate Joshua> this kind of behavior, which can possibly be extended to Joshua> meet this need. One of the behaviors that this interface Joshua> supports is: Joshua> Joshua> $Request->QueryString->Item('foo') which wouldn't work unfortunately for winblows without $Request->QueryString->Item('foo')->Item() Joshua> Joshua> Do you really need the above interface? If so, I'll need Joshua> to create a config setting I imagine as there will be Joshua> a significant performance impact do doing something Joshua> like you suggest. really? that's a bummer. the only other option is to throw use Win32::OLE qw(in valof with OVERLOAD); in the ASP pages when they are running under ActivePerl. which kind of sucks too. (the above is found in the ActivePerl docs for WIN32::OLE). jr -- Joel W. Reed412-257-3881 --All the simple programs have been written. PGP signature
Re: having several mod_perl virtualhosts on the same machine
Make sure the MaxClients & MaxRequestsPerChild is set low enough so that your machine doesn't start swapping excessively. Try a benchmark against your system with "ab -c 100 -n 1 modperl-URL" and see what happens. If your MaxClients is 100 and MaxRequests 100, this will be a decent test against your system. Fire up top and watch the fun! Note to get a real life load test, you will need to test against a mix of URLs, not just one, but you'll get the idea if you hit a RAM heavy URL, like one database driven. --Joshua > Frédéric Schwien wrote: > > Hi, > > i'am encouring problems with a machine that is hosting several completly independant >modperl featured host. > It is crashing without any apparent reason (nothing in the logs), and it seems to be >a lack of memory (1 GB !). The only visual aspect is that it > becomes impossible to login in via ssh after it has crashed. The reboot is necessary >!!! > > My configuration is > Linux 2.2.14, > 1GB Memory, > apache 1.3.12 > modperl 1.24 > Perl 5.6 > > There is no significant traffic over run due to the new sites added using modperl. > At the begining, it was running 3 virtualhosts, everything was working fine for >months ! > As soon as I added 3 new virtualhosts, it starting crashing 2 or 3 times a week. I >removed some of them that were not vital, and then it is crashing > once a week . > > The httpd process is only 12 Mb big, I do not think it is too heavy , is it ? > > Is anybody having any advice ? I'm running out of ideas ... > > > THanks a lot > > > Fred >
Re: Third post. PLease help. PerlHandler configuration question.
That only solves half the problem. Since it is a virtual directory, how will Apache::Registry know where 'cgifile' really exists so it can run it? For example: http://www.mydoamin.com/dirA/dirB/cgifile dirA and dirB don't really exist. If 'cgifile' is stored somewhere else how will Apache::Registry know where to find it? Thanks. -Todd On Mon, 9 Oct 2000, Richard Dice wrote: > Todd: > > This seems fairly straightforward. Have you not just tried: > > >SetHandler perl-script >PerlHandler Apache::Registry > > > ? > > Just because it's in a virtual directory, it's a virtual URI/URL, etc., > doesn't mean that Location isn't the correct directive. "Location" > means a match on the URI requested by the web client. I just put > a pattern match in there saying "if the requested URI ends with 'cgifile', > then handle with Apache::Registry". > > This isn't a perfect location matching pattern, as this will work also on >http://www.yourdomain.com/thisisnotacgifile > but I can leave it to you to spruce it up. Maybe try > > ? > > (I know that would work with Perl, but the Apache pattern matching > engine might not work exactly the same in this circumstance.) > > If I misunderstood your problem, I'm sorry for not having read closer, > confused you, etc. :-) > > Cheers, > Richard > > Todd Chapman wrote: > > > > I need to get this problem solved for a project I am working on. Any help > > is appreciated. > > > > Thanks. > > > > -Todd > > > > -- Forwarded message -- > > > > I am servicing requests from a virtual document tree. Most of the time I > > want the request to be serviced by a PerlHandler module I wrote. However, > > if the requested filename is 'cgifile' I would rather have > > Apache::Registry handle the request, but since this is a virtual document > > tree the CGI program 'cgifile' is located in a real directory somewhere > > else. > > > > 1. How would I configure this behavior? > > > > 2. Would I have to locate 'cgifile' in the document tree or could it be > > located anywhere accessible by the httpd process? > > > > Thanks! > > > > -Todd > > -- > > Richard Dice * Personal 514 816 9568 * Fax 514 816 9569 > ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED] > Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ > "squeeze the world 'til it's small enough to join us heel to toe" > - jesus jones >
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
Greg Williams wrote: > > At 14:23 -0700 2000/10/09, Joshua Chamas wrote: > >$Request->QueryString->('foo')->Item() isn't valid perl syntax, > >is it? > > >perl -c > $Request->QueryString->('foo')->Item() > __END__ > - syntax OK When I execute $Request->Form->('test')->Item() on a real life code sample, even after building in support for $Request->Form('test')->Item(), I get this error: Not a CODE reference at (eval 14) line 10. I have seen this error before with this syntax... is this really supposed to work? I thought it was not supposed to be supported by perl. I saw that it passed compilation, but perl saves some things for runtime checking. It works in VBScript because that language has the notion of a default method for an object class to cover these instances. Note, with my current patch to the system, $Request->Form('something') no longer works when the config PerlSetVar CollectionItem 1 is set. The syntax that gets supported is $Request->Form('something')->Item() instead. I was able to hack it so that $Request->Form->Item('something') works either way. When CollectionItem is set, reading Form like above returns a bless ref to a hash like { Item => 'value' } so that $Request->Form('something')->Item() could also be written as $Request->Form('something')->{Item} The config is used to maintain backwards compatibility with regular faster $Request->Form('something') usage. $Request->{Form}{something} will continue to work in either case as well for the fastest access albeit without any error checking that Form is a valid Collection for Request. --Joshua
Re: Bug in mod_perl
>I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive >no output after the \0. Is this a mod_perl or Apache bug? Or is it a >client bug (using Netscape 4.75) or is it the expected behavior. It would be expected, I'd assume. perl5-porters discussed this back in January when phrack ran an article claiming it was a 'bug' with security implications. To summarize, this isn't really bug, but merely what you'd expect when the PV gets passed to a C function which expects a NULL terminated string. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html .g -- - Crack RC5-64 with Bovine: http://www.distributed.net/rc5/ - #!/bin/perl -sp0777i
Re: Bug in mod_perl
Interesting, the Mason bug report I just filed is obviously mis-filed. Apache::Registry scripts suffer the same behaviour. On Mon, 9 Oct 2000, Dave Rolsky wrote: > Try the following handler: > > package Foo; > > use Apache::Request; > > sub handler > { > my $r = shift; > > my (@vars) = ( 'abc', "abc\0def", "def" ); > > $r->send_http_header; > $r->print("$_\n") foreach @vars; > } > > > 1; > > > I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive > no output after the \0. Is this a mod_perl or Apache bug? Or is it a > client bug (using Netscape 4.75) or is it the expected behavior. > > -dave > > /*== > www.urth.org > We await the New Sun > ==*/ > -- [EMAIL PROTECTED] | Drive thy business, or it will drive thee. http://BareMetal.com/ | - Benjamin Franklin web hosting since '95 |
Third post. PLease help. PerlHandler configuration question.
I need to get this problem solved for a project I am working on. Any help is appreciated. Thanks. -Todd -- Forwarded message -- I am servicing requests from a virtual document tree. Most of the time I want the request to be serviced by a PerlHandler module I wrote. However, if the requested filename is 'cgifile' I would rather have Apache::Registry handle the request, but since this is a virtual document tree the CGI program 'cgifile' is located in a real directory somewhere else. 1. How would I configure this behavior? 2. Would I have to locate 'cgifile' in the document tree or could it be located anywhere accessible by the httpd process? Thanks! -Todd
Bug in mod_perl
Try the following handler: package Foo; use Apache::Request; sub handler { my $r = shift; my (@vars) = ( 'abc', "abc\0def", "def" ); $r->send_http_header; $r->print("$_\n") foreach @vars; } 1; I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive no output after the \0. Is this a mod_perl or Apache bug? Or is it a client bug (using Netscape 4.75) or is it the expected behavior. -dave /*== www.urth.org We await the New Sun ==*/
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault no clue. I emailed your comment to a friend at work and see what he can make of it. He's the fellow that found the cause of the segfault in the first place. Shane -Original Message-From: Herrington, Jack [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:59 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault This allows for XML parsing with no change to the Perl code. I'm just not sure what I am losing in Apache (which is where I make the change). What does losing EXPAT do to Apache? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 4:02 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Hmmm well I *have* to have Xml parsing. Not sure if what you are suggesting totally turns it off or just does something else? -Original Message-From: Herrington, Jack [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:49 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault I did a little more digging around and found that you could also avoid the problem by turning off EXPAT in apache with: Rule EXPAT=no Which fix is more preferable? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan) sub parse { my $self = shift; my $arg = shift; croak "Parse already in progress (Expat)" if $self->{_State_}; $self->{_State_} = 1; my $parser = $self->{Parser}; my $ioref; my $result = 0; if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { eval { $ioref = *{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref = *{$arg}{IO}; ### Problem code ##}; undef $@; } Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared. -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse segmentation fault This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault This allows for XML parsing with no change to the Perl code. I'm just not sure what I am losing in Apache (which is where I make the change). What does losing EXPAT do to Apache? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 4:02 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Hmmm well I *have* to have Xml parsing. Not sure if what you are suggesting totally turns it off or just does something else? -Original Message-From: Herrington, Jack [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:49 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault I did a little more digging around and found that you could also avoid the problem by turning off EXPAT in apache with: Rule EXPAT=no Which fix is more preferable? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan) sub parse { my $self = shift; my $arg = shift; croak "Parse already in progress (Expat)" if $self->{_State_}; $self->{_State_} = 1; my $parser = $self->{Parser}; my $ioref; my $result = 0; if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { eval { $ioref = *{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref = *{$arg}{IO}; ### Problem code ##}; undef $@; } Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared. -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse segmentation fault This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault Hmmm well I *have* to have Xml parsing. Not sure if what you are suggesting totally turns it off or just does something else? -Original Message-From: Herrington, Jack [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:49 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault I did a little more digging around and found that you could also avoid the problem by turning off EXPAT in apache with: Rule EXPAT=no Which fix is more preferable? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan) sub parse { my $self = shift; my $arg = shift; croak "Parse already in progress (Expat)" if $self->{_State_}; $self->{_State_} = 1; my $parser = $self->{Parser}; my $ioref; my $result = 0; if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { eval { $ioref = *{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref = *{$arg}{IO}; ### Problem code ##}; undef $@; } Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared. -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse segmentation fault This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault I did a little more digging around and found that you could also avoid the problem by turning off EXPAT in apache with: Rule EXPAT=no Which fix is more preferable? -Original Message-From: Shane Adams [mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43 PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE: :Parse segmentation fault Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan) sub parse { my $self = shift; my $arg = shift; croak "Parse already in progress (Expat)" if $self->{_State_}; $self->{_State_} = 1; my $parser = $self->{Parser}; my $ioref; my $result = 0; if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { eval { $ioref = *{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref = *{$arg}{IO}; ### Problem code ##}; undef $@; } Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared. -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse segmentation fault This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan) sub parse { my $self = shift; my $arg = shift; croak "Parse already in progress (Expat)" if $self->{_State_}; $self->{_State_} = 1; my $parser = $self->{Parser}; my $ioref; my $result = 0; if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { eval { $ioref = *{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref = *{$arg}{IO}; ### Problem code ##}; undef $@; } Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared. -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse segmentation fault This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
Re: Bug#74416: apache-perl: Apache::MyConfig should provide path to `apxs' (/usr/bin/apxs) in %Setup
[Please keep the CC: to bugs.debian.org] On Mon, Oct 09, 2000 at 10:59:29PM +0200, [EMAIL PROTECTED] wrote: > Package: apache-perl > Version: 1.3.9-13.1-1.21.2309-1 > Severity: normal > > I've tried to create a package `libapache-request-perl' > (Module Apache::Request). (Such a package doesn't yet exist > neither in potato nor in woody.) > > I have currently installed apache-perl and apache-dev (beside others). > When I try to build the package, gcc can't find `httpd.h' (and other > header files). Makefile.PL asks the path to include files from Apache::MyConfig. > But without `APXS' set this module can't provide all needed directories. The problem is that apache-perl is the statically linked binary, and thus does not use apxs in its own build process. modperl folks: should APXS get set anyway? Is Apache::Request wrong? > A few months ago I could successfully build libapache-request-perl since > then I had installed `apache' (together with `libapache-mod-perl') instead > of `apache-perl'. Apache::MyConfig from `libapache-mod-perl' provides > the path to `apxs'. > > Following the contents from the two versions of Apache/MyConfig.pm: > > libapache-mod-perl 1.24-1 > = > > # > # Configuartion for mod_perl and Apache::... > # > package Apache::MyConfig ; > > %Setup = ( >'Apache_Src' => '', >'SSL_BASE' => '', >'APXS' => '/usr/bin/apxs', > ); > > 1; > > __END__ > > > apache-perl 1.3.9-13.1-1.21.2309-1 > = > > # > # Configuartion for mod_perl and Apache::... > # > package Apache::MyConfig ; > > %Setup = ( >'Apache_Src' => >'/usr/src/aperl/apache-perl-1.3.9-13.1-1.21.2309/apache-1.3.9/build-tree/apache_1.3.9/src', >'SSL_BASE' => '', >'APXS' => '', > ); > > 1; > > __END__ > > As you can see the value for `APXS' is empty in apache-perl's version. > > In case the lack of /usr/bin/apxs is intentional, I will make my package > Build-Depend on `apache' and `libapache-mod-perl'. Shouldn't be necessary... it should probably have just Build-Depends: libapache-mod-perl - note that apache-perl already provides both apache and libapache-mod-perl. Also don't forget apache-dev. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
XML::Parse segmentation fault
This code works as a perl script executed off the command line: use XML::Parser; my $parser = new XML::Parser(); $parser->parse( "" ); This code fails with a segmentation fault when called from mod_perl: package CBL::mod_perl::test1; use strict; use XML::Parser; sub handler { my $r = shift; my $parser = new XML::Parser(); $parser->parse( "" ); $r->content_type( 'text/html' ); $r->send_http_header; $r->print( "" ); $r->print( "Testing" ); $r->print( "" ); return OK; } 1; Is there some inherint problem with XML::Parser and mod_perl? Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
At 14:23 -0700 2000/10/09, Joshua Chamas wrote: >$Request->QueryString->('foo')->Item() isn't valid perl syntax, >is it? >perl -c $Request->QueryString->('foo')->Item() __END__ - syntax OK ;-) .g -- Greg Williams, Cnation, (310) 228-6924 "Wow, no intel, no microsoft, sounds like a computer that might... dare I say it... work!" -LHB
having several mod_perl virtualhosts on the same machine
Hi, i'am encouring problems with a machine that is hosting several completly independant modperl featured host. It is crashing without any apparent reason (nothing in the logs), and it seems to be a lack of memory (1 GB !). The only visual aspect is that it becomes impossible to login in via ssh after it has crashed. The reboot is necessary !!! My configuration is Linux 2.2.14, 1GB Memory, apache 1.3.12 modperl 1.24 Perl 5.6 There is no significant traffic over run due to the new sites added using modperl. At the begining, it was running 3 virtualhosts, everything was working fine for months ! As soon as I added 3 new virtualhosts, it starting crashing 2 or 3 times a week. I removed some of them that were not vital, and then it is crashing once a week . The httpd process is only 12 Mb big, I do not think it is too heavy , is it ? Is anybody having any advice ? I'm running out of ideas ... THanks a lot Fred
Re: Apache::ASP - RH install tip
I'll add this fix to the error messaging for Apache::ASP. Thanks for figuring out an alternative solution. -- Joshua Tyler Vallillee wrote: > > A tip that may fix somebody else's problems. My system is RH 6.2 and I > installed Apache and mod_perl from RPM's (please no flames :) > > Upon installing Apache::ASP I got the dreaded SCALAR error in my error log > when testing the site/eg directory: > - > no valid request object (Apache=SCALAR(0x831a48c)) passed to ASP handler; > if you are getting > this error message, you likely have a broken DSO version of mod_perl > which often occurs when using RedHat RPMs. The fix here is to compile > statically the apache + mod_perl build. Please check FAQ or mod_perl > archives for more information. > > > Looking at the default httpd.conf entries, the /perl directory handler is > missing a VERY important line: PerlSendHeader On > > When I added this line, the examples worked perfectly! > > Here is my mod_perl Location entry from httpd.conf: > Alias /perl/ /home/httpd/perl/ > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options +ExecCGI > > > I am not sure how the FAQ gets updated, but this may be a worthwhile > update. > > Tyler > > --
Re: [Apache::ASP] $Request->QueryString->('foo')->Item() support
$Request->QueryString->('foo')->Item() isn't valid perl syntax, is it? Are you going for $Request->QueryString('foo')->Item() support here? There is already a Collection class that is used to emulate this kind of behavior, which can possibly be extended to meet this need. One of the behaviors that this interface supports is: $Request->QueryString->Item('foo') Do you really need the above interface? If so, I'll need to create a config setting I imagine as there will be a significant performance impact do doing something like you suggest. --Joshua "joel w. reed" wrote: > > I'm trying to write an ASP app that runs under PerlScript and Apache::ASP. > > i've found that with ActivePerl 618 -- $Request->QueryString->('foo') > return a reference to a Win32::OLE hash. > > to get a string from the hash you must write -- > $Request->QueryString->('foo')->Item() > or you must use one of the hacks in the OLE.pm docs that come with ActivePerl. > > $Request->QueryString->('foo')->Item() however doesn't work > under Apache::ASP. so i'm wondering if something like the patch > below would improve compatibility without hurting performance > too much. > > comments? suggestions? i know the patch below would need work > to support the "array of values" ASP thing... > > --- /usr/lib/perl5/site_perl/5.6.0/Apache/ASP.pmTue Aug 1 19:42:18 2000 > +++ /home/jreed/tmp/ASP.pm Mon Oct 9 16:30:21 2000 > @@ -2640,6 +2640,25 @@ sub ScriptOnFlush { > > 1; > > +package Apache::ASP::QsObj; > + > +sub new { > +my $class = shift; > +my $self = {}; > +$self->{str} = shift; > + > +bless $self, $class; > +return $self; > + }; > + > +sub Item() > + { > +my $self = shift; > +return $self->{str}; > + } > + > +1; > + > # Request Object > package Apache::ASP::Request; > > @@ -2794,7 +2813,11 @@ sub Form > sub FileUpload >{ shift->{FileUpload}->Item(@_) } > sub QueryString > - { shift->{QueryString}->Item(@_) } > + { > +my $self = shift; > +my $key = shift; > +return new Apache::ASP::QsObj($self->{QueryString}->Item($key)); > + } > sub ServerVariables >{ shift->{ServerVariables}->Item(@_) } > > > -- > > Joel W. Reed412-257-3881 > --All the simple programs have been written. > > >-- >Part 1.2Type: application/pgp-signature
[Apache::ASP] $Request->QueryString->('foo')->Item() support
I'm trying to write an ASP app that runs under PerlScript and Apache::ASP. i've found that with ActivePerl 618 -- $Request->QueryString->('foo') return a reference to a Win32::OLE hash. to get a string from the hash you must write -- $Request->QueryString->('foo')->Item() or you must use one of the hacks in the OLE.pm docs that come with ActivePerl. $Request->QueryString->('foo')->Item() however doesn't work under Apache::ASP. so i'm wondering if something like the patch below would improve compatibility without hurting performance too much. comments? suggestions? i know the patch below would need work to support the "array of values" ASP thing... --- /usr/lib/perl5/site_perl/5.6.0/Apache/ASP.pmTue Aug 1 19:42:18 2000 +++ /home/jreed/tmp/ASP.pm Mon Oct 9 16:30:21 2000 @@ -2640,6 +2640,25 @@ sub ScriptOnFlush { 1; +package Apache::ASP::QsObj; + +sub new { +my $class = shift; +my $self = {}; +$self->{str} = shift; + +bless $self, $class; +return $self; + }; + +sub Item() + { +my $self = shift; +return $self->{str}; + } + +1; + # Request Object package Apache::ASP::Request; @@ -2794,7 +2813,11 @@ sub Form sub FileUpload { shift->{FileUpload}->Item(@_) } sub QueryString - { shift->{QueryString}->Item(@_) } + { +my $self = shift; +my $key = shift; +return new Apache::ASP::QsObj($self->{QueryString}->Item($key)); + } sub ServerVariables { shift->{ServerVariables}->Item(@_) } -- Joel W. Reed412-257-3881 --All the simple programs have been written. PGP signature
Apache::ASP - RH install tip
A tip that may fix somebody else's problems. My system is RH 6.2 and I installed Apache and mod_perl from RPM's (please no flames :) Upon installing Apache::ASP I got the dreaded SCALAR error in my error log when testing the site/eg directory: - no valid request object (Apache=SCALAR(0x831a48c)) passed to ASP handler; if you are getting this error message, you likely have a broken DSO version of mod_perl which often occurs when using RedHat RPMs. The fix here is to compile statically the apache + mod_perl build. Please check FAQ or mod_perl archives for more information. Looking at the default httpd.conf entries, the /perl directory handler is missing a VERY important line: PerlSendHeader On When I added this line, the examples worked perfectly! Here is my mod_perl Location entry from httpd.conf: Alias /perl/ /home/httpd/perl/ SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI I am not sure how the FAQ gets updated, but this may be a worthwhile update. Tyler
Re: test fails with "[warn] [notice] child_init for process..."
I had similar symptoms this summer while trying to build a mod_perl-enabled apache 1.3.12 on an HP-UX 10.20 box (this was with perl 5.6.0 and mod_perl probably 1.2.4). I don't think anything useful showed up in error_log, but I serendipitously found later that the test httpd *worked* when I ran the test as a non-root user. This leads me to believe that the problem results because of some environment settings, but I am not sure. Also, while this test failed when run as root, I do believe the httpd executable itself (which was subject to tests by a non-root user) worked. So I was content enough to install it. shimon. On Thu, Oct 05, 2000 at 05:39:20PM -0400, Phil Freed wrote: > I've seen this problem reported a half-dozen or so times on this list, but > I cannot seem to find a resolution. I've been trying to install mod_perl , > but "make test" fails consistently. > > I'm using perl v5.6.0 , Solaris 5.7 , apache_1.3.12. > > There are two general classes of failures that I've seen. If I run > perl Makefile.PL \ >EVERYTHING=1 \ >DO_HTTPD=1 \ >USE_APACI=1 \ >APACHE_SRC=/devel/src/apache_1.3.12/src > > I get the following from "make test": > > /devel/src/keep/apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d > `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...done > /usr/local/bin/perl t/TEST 1 > still waiting for server to warm up... not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line 95. > make: *** [run_tests] Error 9 > > > # cat t/logs/error* > [notice] Destruction->DESTROY called for $global_object > [Thu Oct 5 17:14:39 2000] [warn] [notice] child_init for process 21363, > report any problems to [no address given] > > A 'ps' shows that process 21363 is running, but (no surprise here) it won't > respond to a telnet to port 8259. > > === > > If I add PREP_HTTPD=1 to the initial make line, I get > > /devel/src/keep/apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d > `pwd`/t & > httpd listening on port 8529 > /bin/sh: /devel/src/keep/apache_1.3.12/src/httpd: not found > will write error_log to: t/logs/error_log > letting apache warm up...done > /usr/local/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line 95. > make: *** [run_tests] Error 146 > > > This time there is no httpd process, and nothing in the logfile. > > === > > I assume these two errors are unrelated. I'd like to use the latter, and > manually configure my apache server -- but I'll take whatever I can > get. What am I missing? >
[mod_rewrite] Remember to set your logLevel down!
hi, I've got a 2 tier apache setup running a lightweight apache with mod_rewrite proxying *.pl requests to the heavyweight apache. I'm posting this to share a bit of practical info on how to build such a setup on a per-file basis, as the Guide only deals with per domain/directory rewriting/proxying. The aim is to proxy requests to a mod_perl enabled apache running on a high port, based on file extension, and enabling a transparent transition from a monolothic one-apache setup to a 2 tier setup. As a matter of fact, I keep a single apache on my dev box, and I'm upgrading the production server to handle static + CGI + server-parsed content with apache.plain, and proxy Registry and Embperl to apache.perl (running on port 1800). Additionally, requests for any PHP content will be proxied to apache.php at port 1801. To achieve this, I used to have in httpd.conf RewriteEngine ON RewriteLogLevel 3 RewriteLog /projects/webserver/logs/rewrite_log RewriteCond %{REQUEST_FILENAME} \.(pl|ehtml)$ RewriteRule ^/(.*) http://%{HTTP_HOST}:1800/$1 [P] The issue is that PLAIN requests, that do not get proxied are getting a performance hit because each hit executes 2 regexes on the URL: the RewriteRule and the RewriteCond. At the beggining, I was horrified at the performance, because I had logging on. See: Without Rewriting: 510 requests per second With LogLevel 0: 418 req/s With LogLevel 1: 365 req/s With LogLevel 3: 300 req/s Calling test.pl at port 1800: 85 req/s Calling test.pl through proxy: 70 req/s One of the interesting things I found is that the statically compiled apache.perl serves static content a little slower than the mod_so (ENABLE_SHARED=MAX) apache.plain: 510 req/s against 470 req/s. My guess is that the extra handlers that mod_perl registers slow down things a bit more than the usage of mod_so (which the docs estimate to be 5%). martin
PerlWarn On being ignored on win32
Hi, I have problems having mod_perl show his warnings: setting PerlWarn to On, nothing appears into the ErrorLog. I tried to change che LogLevel down to "debug": other messages do appear, but not the perl warnings. I'm using Perl 5.6.0, mod_perl 1.24, apache 1.3.12 as localhost. The same script issues warnings, as expected, using linux as web-server. This is the area in my httpd.conf file: --- LoadModule perl_module modules/ApacheModulePerl.dll PerlWarn On ScriptAlias /perl/test/ q:/web/perl/test/ SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI --- What am I missing ? Any help would be appreciated, thanks. Franco
How i will set The Environment ??
Hi Group Sorry to bother u again. But due to my poor knowledge i am looking for the help . I am having Web Server on solaris 2.7 SPARC , running Apache 1.3.11 + PERL + SSL + Etc. .. i am trying to install Apache::AuthCookie . when i do perl Makefile.PL it give some information on console like __ $ perl Makefile.PL For testing purposes, please give the full path to an httpd with mod_perl and at least the following hooks enabled: PERL_AUTHEN, PERL_AUTHZ, PERL_STACKED_HANDLERS, PERL_METHOD_HANDLERS. The path defaults to $ENV{APACHE}, if present. __ I know the the path to my httpd but what other things mean ?? after perl Makefile.PL if i run test i receive Error messges like All test is failed... I do not have any idea on that I need yours Advice. Thanks Sambit Nanda Unix Admin ///|||---|||\\\ \\\---|||---/// __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
RE: How tp Prevent This
That'll be fixed in the next version of AuthenCache. Hopefully, due out sometime this week now that I am unemployed. On 09-Oct-2000 Sambit Nanda wrote: > Hi Friends > I Applied AuthenCache to My Apache 1.3.11 + SSL + > PERL + Etc, web Server My server is also having > AuthenSmb with it. What i found When any user sign in > the user name and password goes to log file. So in my > log file some line gets appended whenever any user > sign in. like this > > [Sun Oct 8 11:46:29 2000] [warn] > AuthenCache::manage_cache: username=snanda > [Sun Oct 8 11:46:29 2000] [warn] > AuthenCache::manage_cache: added snanda:examplesam > 31 to the cache > > So this things happen for every user, what i do not > want. > > So Each there any way to stop this thing. Or The > user name or the Password should not come/write to > Log Files > > > Any Help Any Idea. ??? > > Thanks > > Sambit Nanda > Unix Admin > > ///|||---|||\\\ > \\\---|||---/// > > > > > __ > Do You Yahoo!? > Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! > http://photos.yahoo.com/ -- Jason Bodnar [EMAIL PROTECTED]
PerlHandler configuration question.
I am servicing requests from a virtual document tree. Most of the time I want the request to be serviced by a PerlHandler module I wrote. However, if the requested filename is 'cgifile' I would rather have Apache::Registry handle the request, but since this is a virtual document tree the CGI program 'cgifile' is located in a real directory somewhere else. 1. How would I configure this behavior? 2. Would I have to locate 'cgifile' in the document tree or could it be located anywhere accessible by the httpd process? Thanks! -Todd
Re: mod_perl and ActiveState perl (v5.6.0 618)
On Mon, 9 Oct 2000, oliver wrote: > On Fri, 6 Oct 2000 15:48:20 -0500 (CDT), Randy Kobes wrote: > >It would be good to try to track this down ... > > > >- if you use a non-mod_perl apache config file, but simply > >add in a line to load ApacheModulePerl.dll, does the problem > >occur? > > Using the a stripped down httpd.conf, with just the line: > > LoadModule perl_module modules/ApacheModulePerl > > added, causes Apache to raise an application error after doing: > > net start apache > net stop apache > > (i.e. starting and stopping apache as a service) [ ... ] It seems, then, and also from someone else on clp.modules, that this is a problem with using apache/mod_perl as a service - it seems OK starting and stopping apache from the command line (with apache -k start/shutdown). The problem also seems to persist with the development apache_1.3.13-dev, which has some changes regarding services. I'm not sure what to suggest for the moment, other than using apache from a command window, if possible. best regards, randy kobes
How tp Prevent This
Hi Friends I Applied AuthenCache to My Apache 1.3.11 + SSL + PERL + Etc, web Server My server is also having AuthenSmb with it. What i found When any user sign in the user name and password goes to log file. So in my log file some line gets appended whenever any user sign in. like this [Sun Oct 8 11:46:29 2000] [warn] AuthenCache::manage_cache: username=snanda [Sun Oct 8 11:46:29 2000] [warn] AuthenCache::manage_cache: added snanda:examplesam 31 to the cache So this things happen for every user, what i do not want. So Each there any way to stop this thing. Or The user name or the Password should not come/write to Log Files Any Help Any Idea. ??? Thanks Sambit Nanda Unix Admin ///|||---|||\\\ \\\---|||---/// __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
[mod_perl for ISPs] The User-mode Linux Kernel
In the light of the guide's section "mod_perl for ISPs" http://perl.apache.org/guide/multiuser.html There is a new project called: The User-mode Linux Kernel http://user-mode-linux.sourceforge.net/ User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup. User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software. So if you want to completely protect one user from another and yourself from your users this might be yet another alternative to other proposed solutions at: http://perl.apache.org/guide/multiuser.html This reminds me IBM's mainframe virtual machines, but now you don't need to own a mainframe to be able to do have the same. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: mod_perl and ActiveState perl (v5.6.0 618)
On Fri, 6 Oct 2000 15:48:20 -0500 (CDT), Randy Kobes wrote: >It would be good to try to track this down ... > >- if you use a non-mod_perl apache config file, but simply >add in a line to load ApacheModulePerl.dll, does the problem >occur? Using the a stripped down httpd.conf, with just the line: LoadModule perl_module modules/ApacheModulePerl added, causes Apache to raise an application error after doing: net start apache net stop apache (i.e. starting and stopping apache as a service) >Does it occur if you simply stop and start apache, >or is it only after certain requests are made? Can you >narrow down the type of requests that cause the problem? >- are you preloading any perl modules? > >If so, >can you narrow it down as to which one(s) cause the error? >Or perhaps, if it's only after certain requests are made, >which scripts or modules seem to cause the error? Is there >anything useful in the apache error log? No requests need to be made to replicate the error, it just needs to be started and stopped; nothing is logged. >- are you using an apache binary *without* EAPI support >(used, eg, by mod_ssl)? The mod_perl ppm was compiled >without EAPI support. AFAIK, no. I'm trying it with two versions of Apache; one I compiled using the 1.3.12 source (using default settings), and the precompiled Win32 release >- did you clean out all files and libraries from a possible >earlier installation before installing these? Especially >ApacheModulePerl.dll. Yup - building from scratch makes no difference (neither does reinstalling everything...) >If you want to compile your own, grab the latest cvs >mod_perl sources (links are at http://perl.apache.org/). >These sources have the patches you mentioned above >already applied, and with them all mod_perl tests >should pass. Done - it looks like it's got the patch, but the problem's still there when the Apache service is stopped... In all cases, it looks like the mod_perl tests complete successfully.