Re: 'make test' fails with the server is down, giving up after 121 secs
Just a thought, but are you running the tests as root? If so, try running the tests as a non-root user. Unfortunately manually removing all mod_perl rpms and repeating the install yields the exact same problem. I grepped for some of the strings in the output to see if simply increasing the timeout helps, but could not find where the 120 seconds timeout is set. Any other ideas? I am all out. :( -Original Message- From: Colvin, Joshua Sent: Thursday, October 18, 2007 4:05 PM To: modperl@perl.apache.org Subject: RE: 'make test' fails with the server is down, giving up after 121 secs Thanks Adam, but I've got no firewall and selinux is disabled, so those don't seem to be the problem. I'll see if manually removing the previous mod_perl lets the upgrade (install) work. -Original Message- From: Adam Prime x443 [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 3:57 PM To: modperl@perl.apache.org Subject: RE: 'make test' fails with the server is down, giving up after 121 secs This might not be any help, but the one time that i ran into this it was because for some reason traffic to localhost was being blocked by iptables due to a configuration oversight. You might want to check to make sure that isn't happening to you. -Original Message- From: Colvin, Joshua [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 10:07 AM To: modperl@perl.apache.org Subject: RE: 'make test' fails with the server is down, giving up after 121 secs Thanks for the reply Malcolm. I didn't see anything in error_log that gave me any clues. I've posted the entire contents of error_log in the original posting (unless there's another error_log I should be looking at). We do have ssl configured, but currently disabled: [EMAIL PROTECTED] conf.d]# ls -l /etc/httpd/conf.d/ssl* -rw-r--r-- 1 root root 10919 Dec 15 2005 /etc/httpd/conf.d/ssl.conf -rw-r--r-- 1 root root 10919 Aug 31 2005 /etc/httpd/conf.d/ssl.conf.disabled however the entropy seems okay regardless: [EMAIL PROTECTED] bugzilla-3]# more /proc/sys/kernel/random/entropy_avail 3648 Do you think it's as simple as hacking the test to wait for longer than 120 seconds? -Original Message- From: Malcolm [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 9:54 AM To: modperl@perl.apache.org Subject: Re: 'make test' fails with the server is down, giving up after 121 secs On Thursday 18 October 2007 9:47:31 am Colvin, Joshua wrote: Hello all, I am trying to upgrade bugzilla from 2.22 to 3.0.2 on 32-bit RHEL4, and this means upgrading mod_perl from 1.99_16 to 2.0.03 via CPAN. Unfortunately the 'make test' fails, saying: the server is down, giving up after 121 secs [ error] failed to start server! (please examine t/logs/error_log) Was there nothing useful in the error_log? httpd is up and running when the above is output. It does not fail on any specific test number according to the error_log and I don't see any error msgs in the error_log. I've made sure httpd is stopped before doing the upgrade, otherwise I always get a: Below is the console output for everything I did, minus the lengthy parts that didn't seem relevant. Any ideas? Do you have ssl configured? One thing I've noticed is that if you do, and you're restarting apache a lot (as happens when you're testing) then it's very easy to run out of entropy for the random number generator, at which point apache will hang on start until the system gains enough entropy. On a linux box, check: /proc/sys/kernel/random/_avail You need numbers over 50 for apache/ssl to be happy, in the hundreds is better, single digit means you're stuck. Solutions include less random random sources, entropy generator sources and cat /var/logs/* /dev/null (the quick and dirty method if you just need it occasionally).
Re: Both mod_perl 1 and 2 on same machine
Walt Reed wrote: I have a need to install both apache 1.3.x / mod_perl 1.x and apache 2.2.x / mod_perl 2.x on the same machine. Googling returns some hits from 2004 that mention MP_INST_APACHE2=1, but that option no longer exists in current versions of mod_perl 2. Didn't see anything obvious in the install manual either. Suggestions? I have a couple machines with multiple versions of apache and mod_perl. A front end proxy apache22 installed from ports, and source install of apache13+mod_perl in /usr/local/apache-perl and a source install of apache22+mod_perl2 in /usr/local/apache22-perl. I only have one version of perl and haven't had any problems. -Glenn
bugreport: test suite fails to recognize when the server is running
=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.2.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Dec 29 2006 22:05:29 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/lib/perl5/site_perl/i386-linux /usr/lib/perl5/site_perl /usr/lib/perl5/site_perl . *** Packages of interest status: Apache2: - Apache2::Request : - CGI: 3.15 ExtUtils::MakeMaker: 6.30 LWP: - mod_perl : - mod_perl2 : - 3. This is the core dump trace: (if you get a core dump): No Core Dump This report was generated by t/REPORT on Thu Apr 12 23:03:13 2007 GMT. -8-- End Bug Report --8-- Note: Complete the rest of the details and post this bug report to modperl at perl.apache.org. To subscribe to the list send an empty email to [EMAIL PROTECTED] -- Glenn Pavlovic Motto: I am what I choose to be, for which I make no apologies, no excuses. String Trimmer Support Wheels http://www.weedwheels.com smime.p7s Description: S/MIME Cryptographic Signature
Re: Perl Script using MapToStorageHandler
Sure id love to see that script... to be completely
hones im still kinda new to perl even... Im getting it
slowly... Anyway, im just looking to achieve my goal
and that is to have a working script/perl module that
can switchout config based on incomming URI... a
perfect example would be the one im working on now...
the Subversion/Dav one...
Glenn
--- Torsten Foertsch [EMAIL PROTECTED] wrote:
On Wednesday 01 March 2006 23:20, Glenn Martin
wrote:
Sounds great, but how would i do something simular
to:
$r-add_config([sprintf('LocationMatch
%s/?', $uripath),
'DirectoryIndex .',
'Options +Indexes',
'Dav svn',
sprintf(SVNPath %s,
$localpath),
'/LocationMatch']);
and
$r-add_config([sprintf('Directory %s',
$localpath), 'DirectoryIndex .', 'Options
+Indexes',
'Dav On', '/Directory']);
That leads to an error saying that Directory is
not allowed at that point.
In your case I think you don't need the Directory
around your
configuration, I think. But, let me explain how the
configuration is applied
to a request. After startup when the configuration
has been parsed you have a
server/vhost-specific default configuration. That is
everything outside
Directory, Location and so on. Just before
MapToStorage a copy of this
config is made. Then the core-MapToStorage handler
applies Location,
Directory etc blocks to that copy. At the end of
the request this copy is
thrown away.
The mod_perl MapToStorage handler comes in after the
server-specific config is
loaded but before the core handler. In fact if the
mp-handler returns OK the
core-handler is skipped.
When $r-add_config([EMAIL PROTECTED], $override) is applied
in MapToStorage it is very
similar to
AllowOverride $override
Location /
@lines
/Location
Only this location block is applied *before* any
Directory block.
That means
1) If your mp-handler returns DECLINED, your current
configuration can be
overridden by the core-handler, because it comes
after you.
2) Anything you apply to the config in MapToStorage
applies to a copy. Hence,
nothing is needed to undo the changes.
3) Your config can be applied by
$r-add_config([
'DirectoryIndex .',
'Options Indexes',
'Dav svn',
sprintf(SVNPath %s, $localpath),
], ~0) # ~0 == AllowOverride All
But, a few thing cannot be applied by means of
$r-add_config. For example
AllowOverride needs a Directory block or
ProxyPassReverse does
different things if it appears outside or inside a
Location block. Further,
mod_perl-2.0.2 cannot apply Options if working
under Apache 2.2. For these
situations I have posted a patch a few days ago
(last Friday I think). I hope
it will make it into mod_perl 2.0.3 see
http://www.gossamer-threads.com/lists/modperl/modperl/87401
In fact, I am currently working on a module that can
read the configuration
from a database and apply it on the fly. It already
works pretty good. If you
want I can send you a current copy. I think of
releasing it on CPAN later
this week or early next week.
Torsten
Perl Script using MapToStorageHandler
Ive got a script im wokring on that uses the PerlMapToStorageHandler at that point it adds to the Apache Configuration using the Incomming URI, creating Location/Directory Sections, and an Alias or two... However, i need to be able to remove these changes after the request is completed... How would i remove theses changes and what handler would you suggest for me to tie in to? Thank You Glenn R. Martin
Re: Perl Script using MapToStorageHandler
If i am doing this wrong, how would you suggest doing it? Glenn R. Martin --- Andy Armstrong [EMAIL PROTECTED] wrote: On 1 Mar 2006, at 21:44, Glenn Martin wrote: Ive got a script im wokring on that uses the PerlMapToStorageHandler at that point it adds to the Apache Configuration using the Incomming URI, creating Location/Directory Sections, and an Alias or two... However, i need to be able to remove these changes after the request is completed... How would i remove theses changes and what handler would you suggest for me to tie in to? You're doing it wrong I'm afraid. Why do you want to change the server config during a request? -- Andy Armstrong, hexten.net
Re: Perl Script using MapToStorageHandler
Sounds great, but how would i do something simular to:
$r-add_config([sprintf('LocationMatch
%s/?', $uripath),
'DirectoryIndex .',
'Options +Indexes',
'Dav svn',
sprintf(SVNPath %s,
$localpath),
'/LocationMatch']);
and
$r-add_config([sprintf('Directory %s',
$localpath), 'DirectoryIndex .', 'Options +Indexes',
'Dav On', '/Directory']);
--- Philippe M. Chiasson [EMAIL PROTECTED]
wrote:
Glenn Martin wrote:
Actually if i read the documentation correctly, im
doing it just right. Map to Storage is right
before it
get mapped to a Location/Directory... and thus
this is
where id want to add Directory/Location and Alias
directives based off of the incomming URI... Im
trying
to control DAV input. Take the URI, translate it
to a
Folder, Check the folders contents to see if it
matches a Subversion repository and if it does map
the
Location to SVN Dav and that repository otherwise
Map
the Directory to the URI using an Alias and a
Directory and turn on normal WebDAV... Then return
Decline to Apache then tries to Match the URI to
the
Modified Config. Which will active the correct
module
for the correct folder...
I hope I understood this correctly, so apologies if
I didn't.
However i need this configuration change to be
Temporary... Per request only... I need the Alias'
or
Location/Directory sections to no longer exist..
You can't 'remove' configuration directives you've
injected
in httpd. And those are very *global* and would
affect
much more than the current request.
What handler do i use? and how do i reset the
configuration?
You don't reset the configuration, but you simply
take a different
approach.
Instead of trying to inject httpd configuration,
your MapToStorage handler
needs to emulate Alias/Location directives. For
instance, if you needed
to Alias /foo to /var/www/foo, instead of doing what
I believe you are currently
doing:
$r-add_config([Alias /foo /var/www/foo]);
Simply do what mod_alias would have done...
$r-filename(File::Spec-catfile(/var/www,
$r-uri));
And you get pre-request behaviour just like you
wanted. And it's tons faster too ;-)
Philippe M. Chiasson
m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID :
88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680
1AE5 3631 CB32 A107 88C3A5A5
Re: Perl Script using MapToStorageHandler
Sounds great, but how would i do something simular to:
$r-add_config([sprintf('LocationMatch
%s/?', $uripath),
'DirectoryIndex .',
'Options +Indexes',
'Dav svn',
sprintf(SVNPath %s,
$localpath),
'/LocationMatch']);
and
$r-add_config([sprintf('Directory %s',
$localpath), 'DirectoryIndex .', 'Options +Indexes',
'Dav On', '/Directory']);
--- Philippe M. Chiasson [EMAIL PROTECTED]
wrote:
Glenn Martin wrote:
Actually if i read the documentation correctly, im
doing it just right. Map to Storage is right
before it
get mapped to a Location/Directory... and thus
this is
where id want to add Directory/Location and Alias
directives based off of the incomming URI... Im
trying
to control DAV input. Take the URI, translate it
to a
Folder, Check the folders contents to see if it
matches a Subversion repository and if it does map
the
Location to SVN Dav and that repository otherwise
Map
the Directory to the URI using an Alias and a
Directory and turn on normal WebDAV... Then return
Decline to Apache then tries to Match the URI to
the
Modified Config. Which will active the correct
module
for the correct folder...
I hope I understood this correctly, so apologies if
I didn't.
However i need this configuration change to be
Temporary... Per request only... I need the Alias'
or
Location/Directory sections to no longer exist..
You can't 'remove' configuration directives you've
injected
in httpd. And those are very *global* and would
affect
much more than the current request.
What handler do i use? and how do i reset the
configuration?
You don't reset the configuration, but you simply
take a different
approach.
Instead of trying to inject httpd configuration,
your MapToStorage handler
needs to emulate Alias/Location directives. For
instance, if you needed
to Alias /foo to /var/www/foo, instead of doing what
I believe you are currently
doing:
$r-add_config([Alias /foo /var/www/foo]);
Simply do what mod_alias would have done...
$r-filename(File::Spec-catfile(/var/www,
$r-uri));
And you get pre-request behaviour just like you
wanted. And it's tons faster too ;-)
Philippe M. Chiasson
m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID :
88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680
1AE5 3631 CB32 A107 88C3A5A5
Re: ssl form post variables
JT Smith wrote: Is there any difference between how form post variables are handled in modperl via http vs https? The reason I ask is because since switching from CGI/MP Registry to native MP2 handlers, some of my forms don't seem to work when running under SSL. However, without SSL everything is peachy keen. The forms that don't seem to work are all pretty big and most of them have file chooser form elements. Anything ringing any bells for anyone? JT ~ Plain Black ph: 703-286-2525 ext. 810 fax: 312-264-5382 http://www.plainblack.com I reject your reality, and substitute my own. ~ Adam Savage Not sure if this will apply, but thought I'd mention it. There was/is a bug in Apache 2.0.55/mod_proxy over SSL. When posting forms the data can get truncated if it is over a certain size. I ran into this problem back in December, ended up moving the front end to Apache 2.2. Can't seem to find anything about it now though. -Glenn
Re: Newbie help with Apache2::Request configuration
Joshua H wrote: I copied all the .pm files from the local /tmp install to the apparent correct places in @INC. Now I get: [Fri Dec 30 18:22:51 2005] [error] APR/Request/Param.pm did not return a true value at /usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi/Apache2/Request.pm line 2.\nBEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi/Apache2/Request.pm line 2.\nCompilation failed in require at /usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi/Apache2/Upload.pm line 2.\nBEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi/Apache2/Upload.pm line 2.\nCompilation failed in require at /etc/apache2/mod_perl-startup.pl line 23.\nBEGIN failed--compilation aborted at /etc/apache2/mod_perl-startup.pl line 23.\nCompilation failed in require at (eval 2) line 1.\n Something strange... and probably due to a stupidism on my part. :( Sorry for the trouble. -Joshua Sounds like you didn't use the --enable-perl-glue option when you installed libapreq2. -Glenn
Re: Closing DB handler with PerlCleanupHandler
On Wed, Nov 10, 2004 at 12:51:56PM +0900, Batara Kesuma wrote:
Hi Stas,
1) use Apache::DBI
2) if not, refer to:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlCleanupHandler
http://perl.apache.org/docs/2.0/user/coding/coding.html#Getting_the_C__r__Object
Thank you for the answer. I tried to use Apache::DBI with
dbi_connect_method = 'connect'. But I have a problem here, because I
use 'our' on $dbh so other functions can use it. It looks like:
---
sub show_name {
our $dbh;
my $sth = $dbh-prepare(SELECT name FROM member WHERE id=?);
$sth-execute(1);
...
}
So even if I use dbi_connect_method = 'connect', the connection to the
DB will be alive until the child die. I want to make the connection not
persistent. The only way I know now is to unload Apache::DBI, then call
$dbh-disconnect() at the end of every scripts. Is there any other more
efficient way to do this with little change to the scripts themselves?
use strict;
our($dbh);
sub hander {
local $dbh = DBI-connect(...);
...
}
When your handler exits, the localized global goes out of scope. Voila.
You can also force a variable out of scope with:
undef $dbh;
'my' variables are slightly faster than globals, so you are better
off performance-wise to pass around the $dbh handle than to keep it
in a global, but since the code is already written, 'local'izing is
probably the most convenient thing to do.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to get a core dump
On Fri, Nov 05, 2004 at 01:38:44PM +0100, Marc Gracia wrote:
So, my question is... There is any way to force apache to dump a
coredump file? I suppose I'm forgotting something but I really
desperate...
On Linux, create a directory that is writable by the httpd user
mkdir /var/tmp/apache-cores
chown httpd /var/tmp/apache-cores
chmod 700 /var/tmp/apache-cores
Set the dump directory in httpd.conf:
CoreDumpDirectory /var/tmp/apache-cores
Enable core dumps in your shell and then start Apache
ulimit -c unlimited(for bash; different for csh)
/usr/local/apache/httpd
To test that you can get a dump, start up an httpd process,
send a SIGABRT, SIGBUS, or SIGSEGV to one of the _children_,
and check that it dumped. The error log should indicate
that a possible dump was saved to /var/tmp/apache-cores.
kill -11 apache_child_pid
('kill -l' (that's a lowercase letter L) to get a list
of signals and their numbers for your system)
Of course, this will all be a lot more useful to you if you
build Apache with debugging enabled. When building, set
OPTIM=-g before './configure' in the Apache source dir, e.g.
OPTIM=-g ./configure ...
or before 'perl Makefile.PL' in the mod_perl source dir, e.g.
OPTIM=-g perl Makefile.PL ...
depending on how you build Apache and mod_perl.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Best way to distinguish between mod_perl 1 and 2
On Mon, Sep 20, 2004 at 10:53:09PM +0200, Tom Schindl wrote:
Hi,
!please always reply to the mailing list so the thread doesn't get broken!
well mp uses this value internally and many CPAN-Modules do so either.
Versions
mp1 = VERSION 1.99
mp2 = VERSION = 1.99
The real syntax would be:
-8-
use mod_perl; ## exists in mp1 and mp2
## set the constant to 0 if mp1 and to 1 if mp2
## but also subversions are working like this e.g. = 1.99_12 which
## means the version the version must be at least 1.99_13
use constant MP2 = ($mod_perl::VERSION = 1.99);
BEGIN {
if( MP2 ) {
require Apache::Const;
Apache::Const-import(-compile =
'HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
} else {
require Apache::Constants;
Apache::Constants-import('HTTP_UNAUTHORIZED','HTTP_INTERNAL_SERVER_ERROR','DECLINED','HTTP_FORBIDDEN','OK');
}
}
## proceed with your code
-8-
Tom
John Siracusa wrote:
On Mon, 20 Sep 2004 21:19:58 +0200, Tom Schindl [EMAIL PROTECTED] wrote:
Are you looking for this:
--8--
use constant MP2 = ($mod_perl::VERSION = 1.99_12);
--8--
I don't know. What is that? :) Is that the officially blessed way
to do this, or just another alternative that happens to work? Also,
what's the equivalent for MP1? $mod_perl::VERSION 1.99_12?
-John
I use the following, avoiding the need to pull in mod_perl.pm
unless the MOD_PERL environment variable exists.
use constant MOD_PERL = exists($::ENV{'MOD_PERL'})
? (require('mod_perl.pm'), $mod_perl::VERSION = 1.99)
? $mod_perl::VERSION
: 1
: 0;
and then the Perl optimizer will take care of optimizing
away my simple tests for
(MOD_PERL) == 0 (not mod_perl)
(MOD_PERL) == 1 (mod_perl 1)
(MOD_PERL) 1 (value 1.99 and above for mod_perl 2 and above)
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] code broken by 1.99_15 or _16 or _17-dev
On Thu, Aug 26, 2004 at 08:25:05AM +1000, Carl Brewer wrote:
sub hash_post {
# this has to get called instead of read_post, as read_post()
# gobbles up the POST arguments and they're no longer available...
# and this calls read_post() :)
# returns a hash of all the POST values
my ($r) = shift;
my $post_string = CB::read_post($r);
my %rethash = {};
my @bits = split(//, $post_string);
foreach my $bit (@bits) {
$bit =~ /^(.*)=(.*)$/;
my $key = CGI::Util::unescape($1);
my $value = CGI::Util::unescape($2);
$rethash{$key} = $value;
}
return %rethash;
}
A really quick look and I see that
$bit =~ /^(.*)=(.*)$/;
should be
$bit =~ /^(.*?)=(.*)$/ || next;
or else the greedy match in the key will grab up to an = sign
in the value, if one exists. Also, you do double work on a
sequence without any '=' sign, because $1 and $2 will still be
the same from the previous match if there was one, or else might
be a previous match from elsewhere in the program (!) if there
was not a previous key/value in the $post_string.
The line should really be
$bit =~ /^(.+?)=(.*)$/;
if you want to handle those and additionally wish to disallow
empty keys, either.
If you do want to allow key/value pairs without =, then a
slight variation in code should be used.
However, these probably have nothing to do with the question you
are asking; I'm just pointing out a bug in the code you posted.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
On Wed, Aug 18, 2004 at 12:27:02PM -0700, Stas Bekman wrote: Glenn Strauss wrote: On Wed, Aug 18, 2004 at 10:59:25AM -0700, Stas Bekman wrote: Glenn Strauss wrote: Apache caches the server_rec, so as Stas said, modifying it affects things globally, and across the request. In C, if I wanted to local'ize the server_rec for the request, I would make a copy of the server_rec, store it in r-server, and then modify its contents (top-level only) through r-server. Stas: is there a way to do this in mod_perl? What do you think of local'izing the server_rec when an application attempts to make request-specific changes? There would need to be a clear API for making request-specific or global changes. (Changes through r-server instead of directly through the global server rec, e.g. in the main httpd.conf) Maybe pass $r as an arg to the server_rec method if you want it local'ized? Just musing ... Hmm, how do you see that idea working, Glenn? even if we could localize server_rec, the rest of the Apache will still see the un-localized one, so we don't achieve much. If you wanted to change things just for the mod_perl handlers scope, just stick a new docroot in some singleton and use that in your code. I'm talking about copying the entire server_rec of r-server wholesale and placing a copy in r-server and then modifying the copy. (I'm talking at the C level, here.) Any filters that reference r would see the new copy in r-server. how do you make sure that Apache components and modules don't have their own reference of server stashed somewhere and accessing it not via r-server? All of this is theoretical, mind you. Yes, yes, I understand :) in the particular case of document_root it doesn't live in the server_rec structure. It lives in the core_module's structure: conf = (core_server_config *)ap_get_module_config(r-server-module_config, core_module); return conf-ap_document_root; so localizing server_rec won't help here. Ergh. I hadn't looked where ap_document_root was. Thanks for the correction. The same hack _might_ work; r-server would need to be copied, r-server-module_config would need to be copied, and _then_ the core module's config could be replaced with a local copy for the request. That's not to say it _should_ be done -- just that it might be possible. :) I think this is something that Apache 2.1/2 should address. Having server-wide config localized for requests. it'll benefit things like mod_userdir, us and many other modules which may have the need to modify server-wide values for the duration of the request. Agreed. (Straying a bit off-topic here) How would you approach that? Always deep-copying the entire server_rec and conn_rec for each request seems to me to be very expensive, and would either require too much internal knowledge of each module's config, or would require that all modules be rewritten to provide a hook for localizing their private configs. Neither seems likely to happen. Besides, that sounds like the solution to the wrong problem. There should be a better way to get information like document_root or userdir information without reaching into private module configs. If we're talking filesystem mappings then there ought to be a way for all modules that deal with filesystem mapping to share and exchange information _and_ make sure that all other filesystem mapping modules have access to and _use_ these changes. The same goes for user lookups. There should be never be a time that multiple modules during the _same_ request should have to make multiple getpwnam() or LDAP or other lookups on the same userid. They should be able to share that information. If you have any suggestions how to do this under the hood in Apache, I'll make an attempt to code it. Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
On Wed, Aug 18, 2004 at 12:59:51PM -0700, Ken Simpson wrote: the APR::Socket object is an opaque one, so it can't interoperate with any other perl modules. Have you looked if there is some C api to get the native socket object? There could be one (as they have for file objects), I didn't check. I looked through apr_network_io.h, which seemed like the logical place, and couldn't find an API that returns the native socket object. But I'm pretty unfamiliar with the Apache code base, so someone else would probably have better luck. This is what we'd need bound to the Perl API: apr_os_sock_t fd; apr_os_sock_get((apr_os_sock_t *) fd, (apr_socket_t *) client_socket); On Unix-type platforms, apr_os_sock_t is an int -- the file descriptor, which you can use with select() or IO::Select() or anything you like in Perl to poll the descriptor: $rin = ''; vec($rin, $fd) = 1; ## $fd directly instead of fileno(STDIN) or fileno($FH) ... $nfound = select($rout=$rin, undef, undef, $timeout); (On other platforms, like Windows, I don't know what apr_os_sock_t is; check the headers files. :) To get the client socket for a connection, you can obtain the (apr_socket_t *) with the incantation: apr_socket_t *client_socket = ap_get_module_config(r-connection-conn_config, core_module); and then use apr_os_sock_get() to get the fd. Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
On Wed, Aug 18, 2004 at 02:09:53PM -0700, Stas Bekman wrote: Glenn Strauss wrote: On Wed, Aug 18, 2004 at 12:59:51PM -0700, Ken Simpson wrote: the APR::Socket object is an opaque one, so it can't interoperate with any other perl modules. Have you looked if there is some C api to get the native socket object? There could be one (as they have for file objects), I didn't check. I looked through apr_network_io.h, which seemed like the logical place, and couldn't find an API that returns the native socket object. But I'm pretty unfamiliar with the Apache code base, so someone else would probably have better luck. This is what we'd need bound to the Perl API: apr_os_sock_t fd; apr_os_sock_get((apr_os_sock_t *) fd, (apr_socket_t *) client_socket); On Unix-type platforms, apr_os_sock_t is an int -- the file descriptor, which you can use with select() or IO::Select() or anything you like in Perl to poll the descriptor: and what do you do with socket fd to get it to work with IO::Select? Perl's equivalent of fdopen(): open($FH, =$fd) and then use $FH $rin = ''; vec($rin, $fd) = 1; ## $fd directly instead of fileno(STDIN) or fileno($FH) ... $nfound = select($rout=$rin, undef, undef, $timeout); (On other platforms, like Windows, I don't know what apr_os_sock_t is; check the headers files. :) I'd rather not expose OS specific bits if they won't work with all perl modules. APR provides the API that should (hopefully) work on all platforms, so why not use that? I'm not a Windows programmer, but in the case of sockets, it looks like it might be an int (file descriptor) on Windows, too. We're talking Berkeley sockets on both platforms, right? Whatever socket() returns. While, you're right that this is better hidden by APR, don't let cross-platform concerns entirely prevent you from getting the job done. :) Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
On Wed, Aug 18, 2004 at 09:27:57PM -0700, Stas Bekman wrote: Glenn Strauss wrote: The Socket.Handle property is what I think is needed so that APR::OS::sock_get() can be made to work on Windows, too. mpxs_APR__OS_sock_get() will need to special-case Windows platforms and pull the Handle property. I hope that works. Any Windows programmers out there? and I suppose IntPtr is an integer pointer? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemintptrclasstopic.asp but it can't be really casted with (int) as it can be longer than sizeof(int). Theoretically, yes. But we're talking about file descriptors in this case, and that's a lot of open files. Does any operating system out there support 2 GB open file descriptors? Casting to int shouldn't be a problem in current practice, though I'm not a Windows developer, so take that with some sea salt (large grains; great for Margaritas). and if it was the case, why didn't apr provid such a call? Any APR developers listening? APR hasn't reached version 1.0 yet (though it is frozen for its upcoming release); it has come a long way and is constantly improving. So do you think it's easier to just get this sock_get thing crossplatform and then just use perl modules to manipulate the socket object? Or is it better to expose apr_poll(set)?_.* interface? I prefer the later, as we won't need to deal with crossplatform issues, leaving those to the letter P in APR. Sure, give me ever-evolving (for the better!) APIs that hide low level primitives, but please also always give me access to the low level primitives so that I can get the job done when the higher level APIs do not meet my needs/map to my paradigm. TIMTOWTDI. :) Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
On Tue, Aug 17, 2004 at 04:45:20PM -0700, Stas Bekman wrote: Right. The examples you've found are from mod_perl 1, Apache2 has this in its docs: /** * Retrieve the document root for this server * @param r The current request * @warning Don't use this! If your request went through a Userdir, or * something like that, it'll screw you. But it's back-compatible... * @return The document root * @deffunc const char *ap_document_root(request_rec *r) */ AP_DECLARE(const char *) ap_document_root(request_rec *r); we haven't had a chance yet to work on figuring out how to solve it for mp2. Let me do some research and I'll be back to you shortly. In Apache2, mod_userdir sets a note named mod_userdir_user in the r-notes table, so there is a way to detect if you are in a Userdir request (if using mod_userdir). However, that note only tells you the target user, not the path. The path is typically $HOME/public_html of the user, though that is configurable with the UserDir directive, so YMMV. Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
On Mon, Aug 02, 2004 at 11:55:56AM -0700, Stas Bekman wrote:
[...]
Actually I the problem I saw was exactly what Boris was talking about:
The C-L header wasn't there. The test simply exercises 4 different
combinations of sending and not sending C-L header and content.
my point was that as long as apache does whatever it does
consistently between GET and HEAD it's not a bug. but maybe I'm just not
seeing it, so if you guys grok all of that and still see an issue, let's
flesh it out.
I think it's there. The test that shows that is:
{
# if the response handler sends no data, and sets C-L header,
# the client doesn't get C-L header
my $uri = $location?set_content_length;
my $res = $method-($uri);
ok t_cmp $res-code, 200, $method $uri code;
ok t_cmp $res-header('Content-Length'), undef, $method $uri
C-L header;
ok t_cmp $res-content, , $method $uri content;
}
As I didn't know what's the right thing that should happen, I didn't
make it a failure. But it probabaly shouldn't be undef in the C-L check.
But the fact that sending a bogus char and a different C-L header works
with HEAD (gets the C-L header through), whereas not sending any output
breaks, seems like a bug to me. As mentioned earlier I think the bug is
in the headers_out filter, which received EOS (since on HEAD apache
scratches the response body) and no body. So it takes the liberty to
nuke the C-L header, which I'm not sure is a good thing. When we send
some body, headers_out sends the headers before seeing EOS and therefore
it can't tell whether the body is coming or not, so it leaves the C-L
header alone. Which is at least inconsistent.
I mentioned to Geoff off-list about possibly using a flush bucket,
since I don't have a test setup ready (just replaced my dead
laptop hard drive)
I wrote:
I used to make good use of $r-send_http_header() in my MP1 handlers.
This method isn't available in MP2 (why?), though I could picture it
replaced by sending a flush bucket down the filter chain.
On Tue, Aug 03, 2004 at 10:04:38AM -0400, Geoffrey Young wrote:
apache now sends the headers for you via the header filter. if you were
allowed to send your own headers you might send them before a filter ran
that would alter the headers. for instance, mod_include removes the ETag
header.
Would a flush bucket be a great way to say send headers now?
So if you're not going to send the actual content down the filter chain
on a HEAD request, would sending a flush bucket make things happy?
IIF this works, can I make a request the $r-send_http_header() be
implemented in Apache2 to do just that? (create and pass a flush bucket)
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or incomplete.
On Wed, Jun 16, 2004 at 05:19:57PM -0700, Steven Scotten wrote:
Hello, and thanks in advance for your patience as I ask how to do
something rudimentary, but I seem to be rather dense and a week up to
my eyeballs in documentation has left me no closer than when I began.
No apology necessary. It's quite clear that you've made an effort,
and that effort is greatly appreciated.
Most of what I've read suggests that what I've been doing with CGI.pm
should be replaced by Apache::Request. In fact, my module that uses
CGI.pm throws errors when included in startup.pl:
Can't locate object method new via package CGI (perhaps you
forgot to load CGI?)
use CGI();
CGI-compile();
For more information, 'perldoc CGI' and scroll down to where the
-compile switch is explained.
That should get rid of that error. However, as you already know,
Apache::Request is preferred over CGI.pm in mod_perl for both
performance (Apache::Request is part of the Apache API and
written in C) and resource usage (CGI.pm takes a lot more
memory).
Now, please realize that there are _numerous_ ways to have modperl
run your module. ModPerl::Registry is one of them. Writing an
actual handler, in the vernacular of the Apache API, is another,
and those are not the only ways.
Also, modperl is not limited to producing content. It can do all
sorts of other neat configuration, authentication, and more cool
stuff in Apache. But that's a bedtime story for another day.
So I've set to trying to replace CGI.pm entirely in one particular
module. It looks as though Apache::Request would have been my path in
mod_perl 1.x and I've been looking at
http://perl.apache.org/docs/2.0/user/porting/compat.html (among other
places) for what to do.
Under $r-request it says Use Apache-request.
$r is generally where the request object is stored.
(Whenever you see $r in the documentation, it refers to the current
request object.)
To use Apache::Request instead of CGI.pm, replace
use CGI;
$q = new CGI;
with:
use Apache::Request ();
my $q = Apache::Request-new($r);
and see
http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_use_Apache_Perl_Modules
Now, you don't _have_ to replace CGI.pm.
Apache::Request is just another way to do things.
If writing a handler, which is yet another way to run code in modperl,
the request object will be passed to you as a param.
sub handler {
my $r = shift;
# my main routine code
example_subroutine($r,$_and,$other,$params);
return Apache::Constants::OK;
}
sub example_subroutine {
my($r,$_and,$other,$params) = @_;
# other code
}
As shown above, for subroutines, pass $r as a parameter to
pass the request object between your routines.
If you fall into a situation where it is gross or obtuse to
pass $r as a parameter down through some chains, then in the
deeply nested subroutine, you can actually get $r by doing
sub deeply_nested_routine {
$r = Apache-request;
}
Or, you can do something like:
use vars qw($r);
sub handler {
## always local()ize global variables in modperl! (well, almost always)
local $r = shift;
# ...
return Apache::Constants::OK;
}
sub deeply_nested_routine {
# $r is a global variable that has been localized
# We already have access to use it in this routine.
my $uri = $r-uri;
}
TIMTOWTDI.
Once you have $r, you have easy access to a whole lot of information
and request parameters. 'perldoc Apache' or perldoc 'ModPerl' (I think)
for more information.
Hope I haven't confused you more by giving you so many options.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: reverse IP lookup for check all doimains on the server
On Tue, Jun 15, 2004 at 12:36:35PM +0200, Maxipoint Rep Office wrote: but how http://whois.webhosting.info has some script for that?? I wish see all domains pointed to ANY IP like by http://whois.webhosting.info/anyIPnumber try any server IP like: http://whois.webhosting.info/207.44.194.79 http://whois.webhosting.info/64.5.48.155 Read and understand http://www.webhosting.info/about/profile/ The answers have been there since your first post. Now can we please kill this off-topic thread? Thanks. Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache custom directives problem
On Mon, May 10, 2004 at 02:55:34PM -0700, Stas Bekman wrote:
Anthony Hinsinger wrote:
This is my xs file. it's 100% generated by Apache::Extutils.
static mod_perl_perl_dir_config *newPerlConfig(pool *p)
{
mod_perl_perl_dir_config *cld =
(mod_perl_perl_dir_config *)
palloc(p, sizeof (mod_perl_perl_dir_config));
cld-obj = Nullsv;
so unless something else modifies that member, data-obj should be NULL
(Nullsv is (SV*)NULL). It has been ages since I've messed up with that if
at all. Perhaps someone who has built directives extensions can help you
here. Or compare this autogenerated XS with some other module that creates
similar extensions. I think there are a few of them on CPAN. Geoffrey's book
http://www.modperlcookbook.org/ shouldn't have some tar balls with working
examples. Try to build them first.
If nothing else works, try to step through with gdb/ddd breaking at
newPerlConfig and following from there.
How do you compile the XS module?
Are you using the same flags that were used to compile perl and
mod_perl and Apache? Flags related to pointer sizes and large file
support (e.g. 32-bit or 64-bit off_t) must match between them all.
See the following
http://marc.theaimsgroup.com/?l=apache-modperlm=108210589813501w=2
Check the address of data-obj at different points in the call stack.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
On Thu, May 06, 2004 at 10:55:14AM -0600, Brian Hirt wrote:
On May 6, 2004, at 10:27 AM, Perrin Harkins wrote:
On Wed, 2004-05-05 at 22:11, Brian Hirt wrote:
I've been running across a problem lately where a child process
terminates because of an out of memory error. It prints Out of
Memory
once, the the process sucks up all available cpu print Callback
called
exit. to the log file until it hit's it's 2GB max size.
I'm just guessing here, but this is probably because apache is trying
to
spawn new processes, and they keep dying because there's no memory.
Thanks for the response, interesting insight into the history of $^M.
When I've seen this happen, it's the same PID spewing the messages,
there are no forkings going on. The system isn't actually out of
memory, and there is plenty of it available for the parent httpd
process to fork.The child process has an rlimit set which is why
it's getting an out of memory error. I initially set the rlimit,
because at one point in the past the ImageMagick module would every now
and then go crazy and consume all available memory which would bring
down everything.
Yes, thanks as well. I didn't know how ineffective that was, and am
glad I wasn't setting aside too much memory for it.
Brian, if you can trigger the OOM and Callback called exit loop,
would you try my example mod_perl_startup.pl and use this at the end:
## Importing CGI::Carp sets $main::SIG{__DIE__} = \CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = sub { undef $M; CGI::Carp::confess; };
The 'undef $M' will mark the memory as unused (as long as nothing
else has a reference to it), and if Perl garbage collection kicks
in before the looping problem, then you might have some memory to
work with. I don't know the threshold offhand that Perl uses to
trigger freeing the memory back to the system when using the
system malloc, but a couple of MBs would most likely do it.
Of course, this assumes that the loop is occurring somewhere after
die() is called, and after this routine is called. Worth a shot...
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp1] segfault with DSO if compile options wrong
Back in Oct 2003, Joachim Feise started the thread:
http://marc.theaimsgroup.com/?l=apache-modperlm=106583644716604w=2
Subject: [mp1] segfault with Perl 5.8.1 and mod_perl 1.29
I have had similar problems with segfaults upon the first request and
traced it to a structure packing and alignment mismatch, because of
compile-time -Ddefines... mismatch between compiling mod_perl.so and
Apache.
Notice how the address of r-per_dir_config changes between
http_config.c and mod_perl.c, even though the address of the
request_rec r is the same:
Breakpoint 1, run_method (r=0x81f7384, offset=21, run_all=1) at http_config.c:370
370 result = (*mod_handler) (r);
(gdb) print r-per_dir_config
$1 = (void **) 0x81f74d0
(gdb) print r-per_dir_config
$2 = (void *) 0x81f806c
(gdb) stepi
0x08053b09 370 result = (*mod_handler) (r);
(gdb)
0x08053b0c 370 result = (*mod_handler) (r);
(gdb)
0x08053b0f 370 result = (*mod_handler) (r);
(gdb)
perl_header_parser (r=0x81f7384) at mod_perl.c:1013
1013{
(gdb) print r-per_dir_config
$3 = (void **) 0x81f74d8
(gdb) print r-per_dir_config
$4 = (void *) 0x0
The site (http://bittorrent.netspace.org/) is on a dual-proc box
and the system is Fedora Core 1 with the Perl RPMs from Fedora.
The backtrace is the same as Joachim Feise's post linked above.
perl -V output is included at the end of this post.
apache 1.3.29 and mod_perl 1.29
I had been configuring mod_perl with
perl Makefile.PL PREFIX=/pub/p/e/perl \
APACHE_PREFIX=/usr/local/apache-1.3.29 \
APACHE_SRC=../apache_1.3.29/src \
PERL_TRANS=1 PERL_METHOD_HANDLERS=1 PERL_TABLE_API=1 \
PERL_CHILD_INIT=1 PERL_STACKED_HANDLERS=1 PERL_FIXUP=1
DO_HTTPD=1 PREP_HTTPD=1 USE_APACI=1
make
and then performing a separate ./configure in ../apache_1.3.29/
./configure --prefix=/usr/local/apache-1.3.29 \
--enable-shared=max \
--enable-module=headers \
--enable-module=auth_anon \
--enable-module=expires \
--enable-module=rewrite --enable-shared=rewrite \
--enable-module=proxy --enable-shared=proxy \
--activate-module=src/modules/perl/libperl.a \
--enable-module=perl --enable-shared=perl
make
When doing so, I noticed that while mod_perl compiled with
-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING \
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE \
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm \
-I/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE
Apache was not being compile with similar flags.
With the above configuration, Apache would segfault upon receiving
a request.
(I also noticed the mod_perl was being compile with -fPIC, while Apache
modules were being compiled with -fpic. I don't think this makes a
different on i386, and just mention it in passing)
The following, on the other hand DID compile Apache and mod_perl with
appropriately similar flags, and WORKS (no segfault on requests):
perl Makefile.PL PREFIX=/pub/p/e/perl APACHE_PREFIX=/usr/local/apache-1.3.29
APACHE_SRC=../apache_1.3.29/src PERL_TRANS=1 PERL_METHOD_HANDLERS=1 PERL_TABLE_API=1
PERL_CHILD_INIT=1 PERL_STACKED_HANDLERS=1 PERL_FIXUP=1 DO_HTTPD=1 USE_DSO=1
USE_APACI=1
APACI_ARGS='--prefix=/usr/local/apache-1.3.29,--enable-shared=max,--enable-module=headers,--enable-module=auth_anon,--enable-module=expires,--enable-module=rewrite,--enable-shared=rewrite,--enable-module=proxy,--enable-shared=proxy'
and then building mod_perl and Apache together.
I suppose one could compile mod_perl with PREP_HTTPD=1 and configure
Apache separately with
#CFLAGS_SHLIB=-fPIC -DSHARED_MODULE \
EXTRA_CFLAGS=`perl -MExtUtils::Embed -e ccflags | sed 's/-D_GNU_SOURCE //'` \
./configure --prefix=/usr/local/apache-1.3.29 \
--enable-shared=max \
--enable-module=headers \
--enable-module=auth_anon \
--enable-module=expires \
--enable-module=rewrite --enable-shared=rewrite \
--enable-module=proxy --enable-shared=proxy \
--activate-module=src/modules/perl/libperl.a \
--enable-module=perl --enable-shared=perl
but I did not test this directly.
(removing -D_GNU_SOURCE is necessary to avoid getline() prototype
conflicts for the custom getline() function in
apache/src/support/{htdigest.c,htpasswd.c,logresolv.c} that
conflict with the one in /usr/include/stdio.h when -D_GNU_SOURCE
is defined)
Apologies for the long post, but this all took many hours for me
to figure out, and there seems to be some fatal differences
between what happens when compiling mod_perl with PREP_HTTPD=1
or not, and compiling mod_perl and Apache together or separately.
Also, I'm compiling a DSO, but not configuring mod_perl with DYNAMIC=1.
Are there advantages/disadvantages/requirements for using DYNAMIC=1 when
building mod_perl as a DSO? Thanks much.
Cheers,
Glenn
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.4.21-9.elsmp, archname=i386-linux-thread-multi
uname='linux
