Re: Perl Run and Load Average

2003-06-06 Thread Batara Kesuma
Hi Dale,

 Assuming your CGI scripts aren't doing strange things, liking hanging
 around after the session has closed and doing clean-up work, you might
 check your httpd.conf settings on the number of threads and requests per
 threads.  Its possible that your httpd threads are short-lived and
 restarting more often which now requires a lot more work to start since
 Perl is being loaded each time - just an idea.
 
 MaxRequestsPerChild 1000# if this were too low, say 10 or 50,
 you would probably create more load
 
 # If these were out of wack somehow, it could possibly create some
 # unusual
 load conditions
 MaxSpareServers 20
 MinSpareServers 5

I have this setting on my httpd.conf:
IfModule prefork.c
StartServers   8 
MinSpareServers5
MaxSpareServers   20
ServerLimit  300 
MaxClients   300
MaxRequestsPerChild  1000
/IfModule

Any idea on how can I tweak this setting? 


 I would also run top -d 1 while your webserver is running without
 mod_perl to see what scripts are causing the load.  Do you have a
 database running on the same system?  Do you know if it might be doing
 more work?

The database server is on another machine, but I think I should try to
preload DBI module, and see the result.

I just noticed that the load was going down after I restarted httpd. Is
this because of my scripts have bugs? I think I have some DBI connect
without disconnect in my scripts. I will try to fix this and see how is
the result.






Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources

2003-06-06 Thread Haroon Rafique
On Yesterday at 11:17am, SB=Stas Bekman [EMAIL PROTECTED] wrote:

SB Is it possible that you have an old install and it gets loaded
SB instead? Can you try nuking any preinstalled mod_perl libs?
SB 

Hi Stas,

This will be a long email (I think you're probably used to looking at long 
emails already :-). Thanks for your helpful suggestions and 
wonderful support again.

I have made some progress and here are my findings.

Here's what I did. Based upon your suspicion that the tests were failing 
because of some preinstalled mod_perl libs (true: the system had mod_perl 
1.99_08 installed), I did a local perl install:

1. Installed xstow to make life easier when installing/removing files
2. Installed perl in ~/stow/perl-5.8.0
3. Compiled mod_perl against locally installed perl

Experience with 1.99_09:

In the first batch of test, I had one failure for filter/in_bbs_msg.t. 

-- begin -
filter/in_bbs_msg# connecting to localhost.localdomain:8535
server side has failed (response code: 404),
see t/logs/error_log for more details
dubious
Test returned status 29 (wstat 7424, 0x1d00)
*** server localhost.localdomain:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
-- end   -

Running t/TEST -verbose filter/in_bbs_msg.t, I got the following from 
t/logs/error_log

-- begin -
[Thu Jun 05 10:10:40 2003] [error] [client 127.0.0.1] File does not exist: 
/home/haroon/src/build/mod_perl-1.99_09/t/htdocs/input_filter.html
-- end   -


Experience with 1.99_10-dev (up to date with CVS till yesterday):
=

The first batch of tests passes 100%, so the filter/in_bbs_msg.t from 
1.99_09 is fixed. However, ModPerl-Registry tests fail with:

Failed Test  Stat Wstat Total Fail  Failed  List of Failed
---
redirect.t  22 100.00%  1-2
special_blocks.t   122  16.67%  6 10

Running t/TEST -verbose redirect.t special_blocks.t gave me the 
following output:

-- begin -
/servers/httpd-2.0.44-pl/bin/httpd  -d 
/home/haroon/src/build/modperl-2.0/ModPerl-Registry/t -f 
/home/haroon/src/build/modperl-2.0/ModPerl-Registry/t/conf/httpd.conf 
-DAPACHE2 
using Apache/2.0.44 (prefork MPM)

waiting for server to start: .
waiting for server to start: ok (waited 3 secs)
server localhost.localdomain:8529 started
redirect..1..2
# testing : test redirect: existing target
# expected: ok
# received: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
# htmlhead
# title302 Found/title
# /headbody
# h1Found/h1
# pThe document has moved a 
href=http://localhost.localdomain:8529/registry/basic.pl;here/a./p
# /body/html
not ok 1
# Failed test 1 in redirect.t at line 16
# testing : test redirect: non-existing target
# expected: 404
# received: 302
not ok 2
# Failed test 2 in redirect.t at line 27
FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
special_blocks1..12
# testing : ModPerl::PerlRun is running BEGIN blocks on the first req
# expected: begin ok
# received: begin ok
ok 1
# testing : ModPerl::PerlRun is running BEGIN blocks on the second req
# expected: begin ok
# received: begin ok
ok 2
# testing : ModPerl::PerlRun is running END blocks on the first req
# expected: end ok
# received: end ok
ok 3
# testing : ModPerl::PerlRun is running END blocks on the second req
# expected: end ok
# received: end ok
ok 4
# testing : ModPerl::Registry is running BEGIN blocks on the first req
# expected: begin ok
# received: begin ok
ok 5
# testing : ModPerl::Registry is not running BEGIN blocks on the second 
req
# expected: 
# received: undef
not ok 6
# Failed test 6 in special_blocks.t at line 70
# testing : ModPerl::Registry is running END blocks on the first req
# expected: end ok
# received: end ok
ok 7
# testing : ModPerl::Registry is running END blocks on the second req
# expected: end ok
# received: end ok
ok 8
# testing : ModPerl::RegistryBB is running BEGIN blocks on the first req
# expected: begin ok
# received: begin ok
ok 9
# testing : ModPerl::RegistryBB is not running BEGIN blocks on the second 
req
# expected: 
# received: undef
not ok 10
# Failed test 10 in special_blocks.t at line 70 fail #2
# testing : ModPerl::RegistryBB is running END blocks on the first req
# expected: end ok
# received: end ok
ok 11
# testing : ModPerl::RegistryBB is running END blocks on the second req
# expected: end ok
# received: end ok
ok 12
FAILED tests 6, 10
Failed 2/12 tests, 83.33% okay
Failed Test  Stat Wstat Total Fail  Failed  List of Failed
---
redirect.t  22 100.00%  1-2
special_blocks.t  

Re: Perl Run and Load Average

2003-06-06 Thread Perrin Harkins
On Thu, 2003-06-05 at 09:31, Batara Kesuma wrote:
 I just noticed that the load was going down after I restarted httpd. Is
 this because of my scripts have bugs? I think I have some DBI connect
 without disconnect in my scripts. I will try to fix this and see how is
 the result.

Are your scripts using up all the available memory and sending you into
swap?  That will shoot the load up quickly, and go away when you
restart.

As Stas mentioned, you should try to run Registry instead of PerlRun if
you can.

- Perrin


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Perrin Harkins
On Thu, 2003-06-05 at 03:35, Dennis G. Allard wrote:
 (BTW, my more general goal is to have shared memory across multiple
 Apache threads as part of implementing sessions so that I can avoid
 doing a database write at every HTTP request just to save session IDs.)

Hmmm, save session IDs?  Why aren't you just putting those in a cookie
or in the URLs?

If you meant to say session data rather than IDs, there are several good
ways to do this, and IPC::ShareLite isn't one of them.  It's too slow. 
If this is for a single machine, try either IPC::MM or MLDBM::Sync.  If
it's for a cluster, it's pretty hard to beat MySQL.

- Perrin


Truncated POST at 8192 bytes

2003-06-06 Thread Mick Szucs
Hi All,

Looks like mod_perl is discarding everything past the first 8192 bytes
from POST requests.

mod_perl 1.99
Perl 5.8.0
Apache 2.0.40

All latest RPMs for Redhat 9.

There are some very related looking messages in the archives, but they
seem to pertain to earlier version of mod_perl, and I'm unable to come
up a working solution.

I put together a dummy test script: 

--- 
#!/usr/bin/perl 
 
read (STDIN, $in, $ENV{'CONTENT_LENGTH'}); 
print Content Length: $ENV{'CONTENT_LENGTH'}\n\nP\n; 
print Data Input: $in\n\nP\n; 
print Data Length: , length $in; 
---

Read inbound and spit it back out, nice and simple. 
 
When I set Apache directives on the directory where I'm running it to: 
 
SetHandler cgi-script 
 
and submit a request that I've been having trouble with, I get back 
 
Data Length: 197745 
 
when I change the Apache directives on the test directory to: 
 
SetHandler perl-script 
PerlHandler ModPerl::Registry::handler 
PerlOptions +ParseHeaders 
 
I get back 
 
Data Length: 8192 
 
This is consistent regardless of what I POST or where I POST from.

Any assistance would be greatly appreciated - it's been a long road to
come up with even this much information.

Many thanks,
-- 
Mick Szucs [EMAIL PROTECTED]
Onramp Network Services Inc.



problem with pulling variables from mod_ssl

2003-06-06 Thread Ryan Muldoon
I'm trying to write an apache authentication module that uses client
certificates for authentication.  Basically, all I'm trying to do is use
what mod_ssl does for cert verification, and then set REMOTE_USER. I
wrote to the list last week about a segfault, which was resolved thanks
to the help you guys gave me.  Now I am stuck with a problem that is
likely a logic error on my part, but I have a feeling that my problem
stems from a misunderstanding of how apache is supposed to work.  Since
my module is very short, I'll include it in this email, along with the
relevant contents of my error_log, in the hopes that someone might be
able to point me in the right direction.  Thanks!

---my module, AuthNx509.pm
package Apache::AuthNx509;

use strict;
use Apache::Constants qw(:common);
use Text::ParseWords  qw(quotewords);
use Apache::Log ();

sub handler {
my $r = shift;
my $c = $r-connection;
my $log = $r-log;


my $certcomponent = $r-dir_config('CertComponent') ||
'SSL_CLIENT_S_DN_O';
my $certcompvalue = $r-dir_config('CertComponentValue') ||
'University of Wisconsin';
my $usercomponent = $r-dir_config('RemoteUserCertComponent') ||
'SSL_CLIENT_S_DN_CN';
 
my $uri = $r-uri;

return unless $r-is_main();

my $subr = $r-lookup_uri($uri);
my $apachecertcomp = $subr-subprocess_env($certcomponent);
$log-notice(hello: $apachecertcomp);
   if ($apachecertcomp eq $certcompvalue)
{
$log-notice($certcompvalue good);
$c-user = $r-subprocess_env-{$usercomponent};
$log-notice($c-user logged in successfully);
return OK;
}
$log-notice(cert no good: $r-subprocess_env-{$certcomponent});
my $reason = Client Cert not in correct form;
$r-note_basic_auth_failure;
$r-log_reason($reason, $r-filename);
return DECLINED;
}

1;
__END__
--
error log data:
Thu Jun  5 14:57:11 2003] [notice] [client 128.104.16.134] hello:
[Thu Jun  5 14:57:11 2003] [notice] [client 128.104.16.134] cert no
good: Apache=SCALAR(0x8100308)-subprocess_env-{SSL_CLIENT_S_DN_C}
[Thu Jun  5 14:57:11 2003] [error] access to /var/www/html/test failed
for 128.104.16.134, reason: Client Cert not in correct form
[Thu Jun  5 14:57:13 2003] [notice] [client 128.104.16.134] hello:
[Thu Jun  5 14:57:13 2003] [notice] [client 128.104.16.134] cert no
good: Apache=SCALAR(0x8100308)-subprocess_env-{SSL_CLIENT_S_DN_C}
[Thu Jun  5 14:57:13 2003] [error] access to /var/www/html/test failed
for 128.104.16.134, reason: Client Cert not in correct form
[Thu Jun  5 14:57:13 2003] [crit] [client 128.104.16.134] configuration
error:
couldn't check user.  No user file?: /test/


configuration data (in a Directory statement):

SSLVerifyClient  require
SSLVerifyDepth   10
SSLOptions   +StrictRequire
SSLRequire   %{SSL_CIPHER_USEKEYSIZE} = 128

#   Force clients to use HTTPS
RewriteEngineon
RewriteCond  %{HTTPS} !=on
RewriteRule  .* - [F]

AuthName Test
AuthType Basic
PerlAuthenHandler Apache::AuthNx509
PerlSetVar CertComponent SSL_CLIENT_S_DN_C
PerlSetVar CertComponentValue US
PerlSetVar RemoteUserCertComponent SSL_CLIENT_S_DN_CN
require valid-user


Any ideas would be most appreciated.  Thanks again!

--Ryan


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Perrin Harkins
On Thu, 2003-06-05 at 15:55, Dennis G. Allard wrote:
 MySQL ShmySQL.  A database that didn't have transactions until last year
 and still has no stored procedures

Uh, we're talking about session data here, right?  Basically a remotely
accessible hash?  Stored procedures have no place there, and
transactions don't have much of one either, as evidenced by the fact
that many people simply use files for their session storage.

With a simple table (probably just ID, DATA, and TIMESTAMP) and simple
insert/update/select operations, MySQL pretty much blows everything else
away.  That's why I recommend it for this use.  If you already have
another database, that's fine too.  If your OS has good NFS or SMB
available, you can use MLDBM::Sync over that.  You have to be certain
that locking is well-supported on your OS though, and I doubt it will be
faster than MySQL.

 BTW, I wanted to use Apache::Session or CGI::Session but had some
 problems with each, possibly related to my newness with Apache
 2/mod_perl 2/compat/whatever.

I haven't used either on mod_perl 2, but there's no reason why they
shouldn't work.  Neither of them makes any use of mod_perl or the Apache
API.  If you post more information about the problems, we may be able to
fix them.

 So, I've decide to implement my own
 sessions for now, just for the hell of it, while I wait for Apache 2
 dust to settle or land a project where I am forced to decipher the
 possibilities better.

You could also simply use mod_perl 1.  It is still actively maintained
and remains a good choice for new development.

- Perrin


install mod_perl2 under Redhat 8

2003-06-06 Thread Egor Korablev




HiHow 
to install latest mod_perl 2 under redhat 8, i can'tfind mod-perl-1.99_09 
RPM at http://perl.apache.org/download/index.htmlthx


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Dennis G. Allard
Hmmm.  No one has actually answered the question, although I am getting
all kinds of advice...  (-; ...

On Thu, 2003-06-05 at 01:42, Stas Bekman wrote:
 Thomas Klausner wrote:
  Hi!
  
  On Don, Jun 05, 2003 at 12:35:37 -0700, Dennis G. Allard wrote:
  
  
 I am running Red Hat 8.0, Apache/2.0.40.
  
  
  AFAIK, mod_perl 1.x won't run with Apache 2.0, so I'm quite sure you're
  running mod_perl 2 (which comes shipped with Red Hat 8)
 
 But Dennis, you don't want the version that comes with RH8, it's 1 year old! 
 get 1.99_09 from here:
 http://perl.apache.org/download/index.html

Thanks for that information, Stas.

I'll take that to mean 'yes', I do have mod_perl 2.0 (although, per my
previous post of my `strings /usr/lib/httpd/modules/mod_perl.so` output,
my version is (I guess) 1.99_05-dev, which, you have to admit, does not
look like '2.0'.

Please note, though, one of my goals in life is to rely on my software
providers to do the work of providing me with a stable, tested,
updatable OS and associated tools.  If I download 'out of band' updates,
then I can no longer rely on Red Hat's network update tool, for example.

With all due respect for your fine work, which is awesome, there are
application developers such as myself out there who simply don't have
time to track the bleeding edge except when absolutely forced to do so
(which sometimes does happen).
  
My heuristic is that I intentionally stay behind the curve.  I don't use
Oracle 9 yet, for example.

My current need for mod_perl 2.0 is not critical, so I will give it
another year or so before I dig in and make the (substantial) effort of
coverting entirely to it.


 
 to check the version you can do:
 
 /home/stas perl-blead   -Mmod_perl -le 'print mod_perl-VERSION'
 1.2701
 /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION'
 1.9910
 
 As you can see, I have both. 1.9910 is mod_perl-2.0-tobe (but currently only 
 1.9909 is available, 1.9910 is a cvs version).

Bummer, I don't have perl-blead and there are only 17 references to it
in the entire history of Dejanews, none that seem to point to a
download...

[EMAIL PROTECTED] httpd]# perl-blead -MApache2 -Mmod_perl -le 'print
mod_perl-VERSION'
bash: perl-blead: command not found
[EMAIL PROTECTED] httpd]# 
[EMAIL PROTECTED] httpd]# whereis perl-blead
perl-blead:
[EMAIL PROTECTED] httpd]# locate perl-blead


I could take time to find/download perl-blead, but hey, gotta go earn
some money!  (-;  Outta here for now.

 
 
 __
 Stas BekmanJAm_pH -- Just Another mod_perl Hacker
 http://stason.org/ mod_perl Guide --- http://perl.apache.org
 mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
 http://modperlbook.org http://apache.org   http://ticketmaster.com


-- 
Dennis G. Allard   telephone: 1.310.399.4740
Ocean Park Software http://oceanpark.com





Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Thomas Klausner
Hi!

On Thu, Jun 05, 2003 at 01:37:59PM -0700, Dennis G. Allard wrote:
 Please note, though, one of my goals in life is to rely on my software
 providers to do the work of providing me with a stable, tested,
 updatable OS and associated tools.  If I download 'out of band' updates,
 then I can no longer rely on Red Hat's network update tool, for example.
 
 With all due respect for your fine work, which is awesome, there are
 application developers such as myself out there who simply don't have
 time to track the bleeding edge except when absolutely forced to do so
 (which sometimes does happen).

The latest Red Hat comes with Apache 2 (because Apache 2 is quite stable).
Unfortunatly mod_perl 2.0 is /not/ that finished (Sorry Stas..). But because
Red Hat wants to provide mod_perl to its Users, they included the Beta
Version in their distro.

So blame them ...

  /home/stas perl-blead   -Mmod_perl -le 'print mod_perl-VERSION'
  1.2701
  /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION'
  1.9910
 
 Bummer, I don't have perl-blead and there are only 17 references to it
 in the entire history of Dejanews, none that seem to point to a
 download...

You don't need perl-blead (which is probably Stas' install of the latest
unstable Perl version)

This will do the same job:
% perl -Mmod-perl -le 'print mod_perl-VERSION'


-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Dennis G. Allard
On Thu, 2003-06-05 at 13:08, Perrin Harkins wrote:
 On Thu, 2003-06-05 at 15:55, Dennis G. Allard wrote:
  MySQL ShmySQL.  A database that didn't have transactions until last year
  and still has no stored procedures
 
 Uh, we're talking about session data here, right?  Basically ...

My point about MySQL was a general comment for why I did not use it (in
the past), not just about sessions.

Your suggestions for tools to implement sessions are all sound.

Cheers,
Dennis

 -- 
 Dennis G. Allard [EMAIL PROTECTED]
 http://oceanpark.com



Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Dennis G. Allard
On Thu, 2003-06-05 at 13:37, Thomas Klausner wrote:
 Hi!
 
 On Thu, Jun 05, 2003 at 01:37:59PM -0700, Dennis G. Allard wrote:
[In reply to Stas]
  Please note, though, one of my goals in life is to rely on my software
  providers to do the work of providing me with a stable, tested,
  updatable OS and associated tools.  If I download 'out of band' updates,
  then I can no longer rely on Red Hat's network update tool, for example.
  
  With all due respect for your fine work, which is awesome, there are
  application developers such as myself out there who simply don't have
  time to track the bleeding edge except when absolutely forced to do so
  (which sometimes does happen).
 
 The latest Red Hat comes with Apache 2 (because Apache 2 is quite stable).
 Unfortunatly mod_perl 2.0 is /not/ that finished (Sorry Stas..). But because
 Red Hat wants to provide mod_perl to its Users, they included the Beta
 Version in their distro.

And once mod_perl 2.0 become stable, Red Hat will ship it, and those
having my philosophy will begin developing with it!

 
 So blame them ...

No blame needed.  Everyone is doing a good job as fast as they can.


 
   /home/stas perl-blead   -Mmod_perl -le 'print mod_perl-VERSION'
   1.2701
   /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION'
   1.9910
  
  Bummer, I don't have perl-blead and there are only 17 references to it
  in the entire history of Dejanews, none that seem to point to a
  download...
 
 You don't need perl-blead (which is probably Stas' install of the latest
 unstable Perl version)
 
 This will do the same job:
 % perl -Mmod-perl -le 'print mod_perl-VERSION'

Bummmer, that does not work either for me on Red Hat 8.0:

[EMAIL PROTECTED] httpd]# perl -Mmod-perl -le 'print mod_perl-VERSION'
Can't locate mod.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .).
BEGIN failed--compilation aborted.


I'm new to this list.  Thanks for everyone's advice.


-- 
Dennis G. Allard   telephone: 1.310.399.4740
Ocean Park Software http://oceanpark.com





Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Thomas Klausner
Hi!

On Thu, Jun 05, 2003 at 01:56:58PM -0700, Dennis G. Allard wrote:
  You don't need perl-blead (which is probably Stas' install of the latest
  unstable Perl version)
  
  This will do the same job:
  % perl -Mmod-perl -le 'print mod_perl-VERSION'
 
 Bummmer, that does not work either for me on Red Hat 8.0:

Sorry, typo: it should say -Mmod_perl instead of -Mmod-perl, i.e.:

% perl -Mmod_perl -le 'print mod_perl-VERSION'

-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Perrin Harkins
On Thu, 2003-06-05 at 16:37, Dennis G. Allard wrote:
 Hmmm.  No one has actually answered the question, although I am getting
 all kinds of advice...  (-; ...

Thomas Klausner said that mod_perl 2 only runs on apache 2 and mod_perl
1 only runs on apache 1.  He is correct.  Red Hat gave you an early
version of mod_perl 2 because they gave you apache 2.

 I'll take that to mean 'yes', I do have mod_perl 2.0 (although, per my
 previous post of my `strings /usr/lib/httpd/modules/mod_perl.so` output,
 my version is (I guess) 1.99_05-dev, which, you have to admit, does not
 look like '2.0'.

The 2.x branch has not reached an official release yet.  It is still
basically considered beta.  When it is officially released, it will be
2.0.

 Please note, though, one of my goals in life is to rely on my software
 providers to do the work of providing me with a stable, tested,
 updatable OS and associated tools.  If I download 'out of band' updates,
 then I can no longer rely on Red Hat's network update tool, for example.

If you want to use bleeding edge software, you do have to keep up.

 My heuristic is that I intentionally stay behind the curve.

In that case, you should use apache 1 and mod_perl 1. 

 My current need for mod_perl 2.0 is not critical, so I will give it
 another year or so before I dig in and make the (substantial) effort of
 coverting entirely to it.

Most of us find that it's pretty easy to convert to mod_perl 1, provided
you have clean Perl code to begin with.

 Bummer, I don't have perl-blead

Bleedperl (aka perl-blead) is the name for the unreleased development
version of Perl.  You don't need it.

- Perrin


Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Dennis G. Allard
On Thu, 2003-06-05 at 13:53, Thomas Klausner wrote:

 Sorry, typo: it should say -Mmod_perl instead of -Mmod-perl, i.e.:
 
 % perl -Mmod_perl -le 'print mod_perl-VERSION'

THANKS! (I should have caught that one myself, for crying out loud).

For the sake of completeness:

[EMAIL PROTECTED] root]# uname -a
Linux oceanpark.com 2.4.20-18.8 #1 Thu May 29 07:20:39 EDT 2003 i686 athlon i386 
GNU/Linux

[EMAIL PROTECTED] root]# cat /etc/issue
Red Hat Linux release 8.0 (Psyche)
Kernel \r on an \m

[EMAIL PROTECTED] root]# perl -Mmod_perl -le 'print mod_perl-VERSION'
1.9905



Cheers,
Dennis


-- 
Dennis G. Allard   telephone: 1.310.399.4740
Ocean Park Software http://oceanpark.com





Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Ged Haywood
Hi there,

On 5 Jun 2003, Dennis G. Allard wrote:

 Hmmm.  No one has actually answered the question, although I am getting
 all kinds of advice...  (-; ...

It's been good advice.

If the question to which you refer is the one in the subject line,
then one answer is look in the error log.  Apache tells you when it
starts.  It's generally about the first thing it says.  Your error log
is defined in your Apache configuration file (probably httpd.conf) in
a line that starts

ErrorLog

You could also take a look at

http://perl.apache.org/docs/2.0/user/intro/start_fast.html

which has an example of the output in the error log from a server when
it's started.

If your question isn't the one in the subject line, please accept my
apologies - I haven't been following this thread closely.  Feel free
to ask it again if it hasn't yet been answered.

There's more FM to R if you work with Apache/mod_perl 1.x - if you're
going to be doing a lot of work for a commercial application and you
don't want to be involved in the mod_perl 2.x development, and you're
going to want lots more people around to hold your hand, then that's
what I'd recommend.  There are good books too.  Buy them.  Read them.
You're an exceptional individual if you can absorb it all the first
time through, so read them again.

Oh, heck.  More advice.

73,
Ged.




Re: mod_perl2 rpm for Redhat 8

2003-06-06 Thread Stas Bekman
[moving the thread to the appropriate list and adjusting the subject]

Thomas Klausner wrote:
Hi!

On Don, Jun 05, 2003 at 02:53:52 +0400, Egor Korablev wrote:

This list is for discussing mod_perl documentation issus. For general
mod_perl Problem, use the mod_perl users list:
http://perl.apache.org/maillist/modperl.html

How to install latest mod_perl 2 under redhat 8, i can't
find mod-perl-1.99_09 RPM at http://perl.apache.org/download/index.html


mod_perl is only provided as a source tarball. Pre-compiled binaries are
provided by third parties.
Try to google for mod_perl 1.99 rpm

Or download the sources and install them.
Egor, I think you can find the latest rpm in the redhat's rawhide repository, 
similar to the mandrake's cooker.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Perl Run and Load Average

2003-06-06 Thread Stas Bekman
Batara Kesuma wrote:
 I will try to move all standard modules to startup.pl. Do I need to delete
 the standard modules from the scripts after I moved them to startup.pl? I
 mean, after I moved:
 use MyModule;

 to startup.pl, do I need to delete it from the scripts? Or Perl Run will
 automatically figure out that it has already been loaded and simply ignore
 the one in the scripts?

No, no, you shouldn't delete anything at all. Perl uses the %INC hash to track 
what was loaded already. Perhaps it'll benefit you to read a good perl book or 
at least this document:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html

I have this setting on my httpd.conf:
IfModule prefork.c
StartServers   8 
MinSpareServers5
MaxSpareServers   20
ServerLimit  300 
MaxClients   300
MaxRequestsPerChild  1000
/IfModule

Any idea on how can I tweak this setting? 
Please read:
http://perl.apache.org/docs/1.0/guide/performance.html
in particular
http://perl.apache.org/docs/1.0/guide/performance.html#Performance_Tuning_by_Tweaking_Apache_Configuration
Since you are running prefork mpm, most of these mod_perl 1 notes apply to 
your mod_perl 2 setup.

I would also run top -d 1 while your webserver is running without
mod_perl to see what scripts are causing the load.  Do you have a
database running on the same system?  Do you know if it might be doing
more work?


The database server is on another machine, but I think I should try to
preload DBI module, and see the result.
I just noticed that the load was going down after I restarted httpd. Is
this because of my scripts have bugs? I think I have some DBI connect
without disconnect in my scripts. I will try to fix this and see how is
the result.
You can always monitor this using the database tools. Also consider using 
Apache::DBI. it's all the document I've mentioned above.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Truncated POST at 8192 bytes

2003-06-06 Thread Stas Bekman
Mick Szucs wrote:
Hi All,

Looks like mod_perl is discarding everything past the first 8192 bytes
from POST requests.
mod_perl 1.99
Perl 5.8.0
Apache 2.0.40
All latest RPMs for Redhat 9.
The latest version that we carry (1.99_09) has this problem fixed:
http://perl.apache.org/download/index.html
If the problem persists or in any future bug reporting please make sure to
submit a complete bug report as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Thanks.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources

2003-06-06 Thread Stas Bekman
Haroon Rafique wrote:
On Yesterday at 11:17am, SB=Stas Bekman [EMAIL PROTECTED] wrote:

SB Is it possible that you have an old install and it gets loaded
SB instead? Can you try nuking any preinstalled mod_perl libs?
SB 

Hi Stas,

This will be a long email (I think you're probably used to looking at long 
emails already :-). Thanks for your helpful suggestions and 
wonderful support again.
;)

I have made some progress and here are my findings.

Here's what I did. Based upon your suspicion that the tests were failing 
because of some preinstalled mod_perl libs (true: the system had mod_perl 
1.99_08 installed), I did a local perl install:

1. Installed xstow to make life easier when installing/removing files
2. Installed perl in ~/stow/perl-5.8.0
3. Compiled mod_perl against locally installed perl
Great. So that explains why I had a flash of this problem and then couldn't 
reproduce it. Once the current problems are resolved it'd be nice to track 
that problem. I believe that the cause is a wrong @INC. So if you can keep the 
old setup untouched that would be great.

We are now discussing adding a bootstrap checking on all mod_perl libraries. 
We have too many problem reports just because old libraries kick in.

Experience with 1.99_09:

In the first batch of test, I had one failure for filter/in_bbs_msg.t. 

-- begin -
filter/in_bbs_msg# connecting to localhost.localdomain:8535
server side has failed (response code: 404),
see t/logs/error_log for more details
dubious
Test returned status 29 (wstat 7424, 0x1d00)
*** server localhost.localdomain:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
-- end   -
Running t/TEST -verbose filter/in_bbs_msg.t, I got the following from 
t/logs/error_log

-- begin -
[Thu Jun 05 10:10:40 2003] [error] [client 127.0.0.1] File does not exist: 
/home/haroon/src/build/mod_perl-1.99_09/t/htdocs/input_filter.html
-- end   -
Yup, this one is resolved:

cvs log t/filter/in_bbs_msg.t
...

revision 1.4
date: 2003/05/11 22:59:21;  author: stas;  state: Exp;  lines: +2 -9
- get rid of the http://hostname:port in the GET request, as some lwp's
fail  to remove it from the GET line
- replace manually coded exception handling with GET_BODY_ASSERT macro
PR:
Obtained from:
Submitted by:
Reviewed by:
I tend not to clutter the Changes file with test fixes, since they aren't 
relevant to final users.

So the 1.99_09 thread ends here. Will continue the rest in the other thread.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: [mp2] make test fails with 1.99_10-dev sources

2003-06-06 Thread Stas Bekman
Haroon Rafique wrote:

Experience with 1.99_10-dev (up to date with CVS till yesterday):
=
The first batch of tests passes 100%, so the filter/in_bbs_msg.t from 
1.99_09 is fixed. However, ModPerl-Registry tests fail with:

Failed Test  Stat Wstat Total Fail  Failed  List of Failed
---
redirect.t  22 100.00%  1-2
special_blocks.t   122  16.67%  6 10
Both failed due to the missing LWP. I was able to reproduce the exact problem 
by removing LWP/UserAgent.pm. I have now fixed both in cvs. Please 'cvs up' 
and test again. Thanks.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com



Re: How tell what version of mod_perl is installed?

2003-06-06 Thread Dennis G. Allard
On Thu, 2003-06-05 at 14:13, Ged Haywood wrote:
 ...
 If the question to which you refer is the one in the subject line,
 then one answer is look in the error log.  Apache tells you when it
 starts.  It's generally about the first thing it says.  Your error log
 is defined in your Apache configuration file (probably httpd.conf) in
 a line that starts
 
 ErrorLog

I know about that file.

However, in my case (~stock Red Hat 8.0 Apache 2.0.40), my error log
(/var/log/httpd/error_log) shows:

[Thu Jun 05 02:54:44 2003] [notice] Apache/2.0.40 (Red Hat
Linux) configured -- resuming normal operations

I spent some time scrounging the Apache Web site and can't find any
documentation on how to show what DSOs (Dynamic Shared Objects, aka
Apache modules) are loaded.  Google groups shows some other people
having this question.

For Apache 1.0, one can inspect the httpd.conf for LoadModule
directives.  For Apache 2.0 in Red Hat, one can do that but, also, for
modules that are packaged as separate RPMs, one must examine
/etc/httpd/conf.d/*.  Such techniques do not constitute a documented API
for finding that information, but are better than nothing.  See:

  http://oceanpark.com/notes/howto_redhat8-apache2-mod_perl.html


You can find out what modules are statically linked with your Apache
image by doing, for example:

[EMAIL PROTECTED] httpd]# httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

apachetcl -l will also do that.

But I don't have mod_perl statically linked.  It is loaded by my
/etc/httpd/conf.d/perl.conf file.  


 You could also take a look at
 
 http://perl.apache.org/docs/2.0/user/intro/start_fast.html
 
 which has an example of the output in the error log from a server when
 it's started.

But no documentation as to why or how that line is generated nor what it
means.


 
 If your question isn't the one in the subject line, please accept my
 apologies - I haven't been following this thread closely.  Feel free
 to ask it again if it hasn't yet been answered.

It was in some earlier responses:

[EMAIL PROTECTED] root]# perl -Mmod_perl -le 'print mod_perl-VERSION'
1.9905


 There's more FM to R if you work with Apache/mod_perl 1.x - if you're
 going to be doing a lot of work for a commercial application and you
 don't want to be involved in the mod_perl 2.x development, and you're
 going to want lots more people around to hold your hand, then that's
 what I'd recommend.  There are good books too.  Buy them.  Read them.
 You're an exceptional individual if you can absorb it all the first
 time through, so read them again.

One of the best books I've ever read in my tenure doing software
development is the excellent one by Lincoln Stein and Doug MacEachern,
Writing Apache Modules with Perl and C.  First thing I read back in 1999
when I started using mod_perl.  I eagerly await an update that covers
Apache 2.0 and mod_perl 2.0.

 
 Oh, heck.  More advice.
 73,
 Ged.


All well founded advice is appreciated.



Cheers,
Dennis


-- 
Dennis G. Allard   telephone: 1.310.399.4740
Ocean Park Software http://oceanpark.com





Re: [mp2] How do I find Documentation on . . .

2003-06-06 Thread Jack Nerad
Stas Bekman wrote:

[snip]

Fantastic. We really need volunteers to help with the docs (at least 
manpages).

The infrastructure is all there. We use pod and everything gets glued 
together by DocSet. You can find more info here:
http://perl.apache.org/download/docs.html
Okay.

there are a few bits of the Apache::RequestRec manpage
http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html
This doc is converted from pod.
Okay.  You Perl guys with your text processing.  What will you think of 
next ;)

So get yourself familiar with the infrastructure, but don't do 
anything just yet. We have planned a bulked import of documentation 
bits from the Apache C header files, but it's incomplete. Seeing that 
it's not getting anywhere and hearing no news from Gerald Richter, I 
think I'll just go ahead and import whatever we have. And then 
everybody can chime in and help polish the docs.

Sounds like a plan? 
Aye, Aye.  I have some rudimentary docs with the methods listed, and a 
brief discussion of what they do (the ones I could figure out), but I'll 
move them to pod and await new content from the import you talk about.

--
Jack Nerad


RE: DirectoryIndex doesn't see SetHandler path

2003-06-06 Thread Marc M. Adkins
 I hope that this is the issue. Marc has failed to say that he is using
 mp2/apache2, so I won't be surprised if this is yet another
 problem introduced
 by apache-2.0 (incompatible mod_dir behavior wrt apache-1.3). see
 my recent
 bug reports to the httpd-dev list.

Yah, yah, sorry, Apache 2.0.46 on W2K, ActiveState build 804 (Perl 5.8),
mod_perl/1.99_10-dev.  Postcards from the bleeding edge.

Wish I'd given more attention to your postings on httpd-dev.  I was thinking
this might be a bug and it might not...I'm not always sure what is
_supposed_ to happen.

mma



Trouble with Apache::Request

2003-06-06 Thread K Old
Hello everyone,

I'm having trouble getting Apache::Request installed on my Mandrake 9.0
system.  Let me first say that I'm not using the Apache that came with
Mandrake 9.0.  I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1
sources and compiled and installed them.  Everything works fine with
Apache, mod_perl and PHP, except when I need to use Apache::Request
(trying to use Alzabo browser interface).  BTW, the version of Perl is
5.8.0.

When trying to build Apache::Request, here's what I get when I do the
make test.  I can force the install, but the same error comes up when I
try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo
calls it.

I've scoured mailing list, Google groups and books and can't find any
help.

Any chance I should build perl without the threads?  I've heard that can
be the cause of a lot of problems.

make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c'
make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c'
make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request'
make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request'
make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie'
make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie'
t/httpd -f `pwd`/t/httpd.conf
Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf:
Can't load
'/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module 
Apache::Request: libapreq.so.1: cannot open shared object file: No such file or 
directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
 at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm
line 14
Compilation failed in require at (eval 16) line 3.

Any help is greatly appreciated!

-- 
K Old [EMAIL PROTECTED]



RE: Trouble with Apache::Request

2003-06-06 Thread K Old
Kitch,

No, I didn't build a threaded Perl, it seems to be the popular thing
among any linux distro these days to build it with threads.  

I'll build a version without threads just to see if it works, as I'm out
of things to try.

Thanks,
Kevin

On Fri, 2003-06-06 at 12:39, Kitch, David wrote:
 Did you do a threaded build of Perl 5.8.0?
 You might try a non-threaded Perl build.
 
 Regards,
 Kitch
 [EMAIL PROTECTED]
 
 -Original Message-
 From: K Old [mailto:[EMAIL PROTECTED] 
 Sent: Friday, June 06, 2003 11:27 AM
 To: ModPerl List
 Subject: Trouble with Apache::Request
 
 
 Hello everyone,
 
 I'm having trouble getting Apache::Request installed on my Mandrake 9.0
 system.  Let me first say that I'm not using the Apache that came with
 Mandrake 9.0.  I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1
 sources and compiled and installed them.  Everything works fine with
 Apache, mod_perl and PHP, except when I need to use Apache::Request
 (trying to use Alzabo browser interface).  BTW, the version of Perl is
 5.8.0.
 
 When trying to build Apache::Request, here's what I get when I do the
 make test.  I can force the install, but the same error comes up when I
 try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo
 calls it.
 
 I've scoured mailing list, Google groups and books and can't find any
 help.
 
 Any chance I should build perl without the threads?  I've heard that can
 be the cause of a lot of problems.
 
 make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c'
 make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c'
 make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request'
 make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request'
 make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie'
 make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie'
 t/httpd -f `pwd`/t/httpd.conf
 Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf:
 Can't load
 '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so
 ' for module Apache::Request: libapreq.so.1: cannot open shared object
 file: No such file or directory at
 /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.  at
 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm
 line 14
 Compilation failed in require at (eval 16) line 3.
 
 Any help is greatly appreciated!



RE: Trouble with Apache::Request

2003-06-06 Thread Ged Haywood
Hi there,

On 6 Jun 2003, K Old wrote:

 No, I didn't build a threaded Perl, it seems to be the popular thing
 among any linux distro these days to build it with threads.  
 
 I'll build a version without threads just to see if it works

Want to run that by me again??

  I'm having trouble getting Apache::Request installed on my Mandrake 9.0
[snip]
  make test.  I can force the install, but the same error comes up when I
  try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo
  calls it.

Is it *exactly* the same error?

  Any chance I should build perl without the threads?  I've heard that can
  be the cause of a lot of problems.

Just Perl 5.8.0 can cause problems... do you have any others kicking around?
I'm thinking of 5.7.2 for example (ducks in case Stas throws something :)
which has done me good service.  Wouldn't recommend 5.6.anything.

[snip]
  t/httpd -f `pwd`/t/httpd.conf
  Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf:
  Can't load 
  '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \
for module Apache::Request: libapreq.so.1: cannot open shared object file:  \
No such file or directory
[snip]

Is there in fact no such file or directory?

I don't like that it's even looking in there...  Are you building it all
as root?  Bad idea generally, although -MCPAN does rather encourage it.

73,
Ged.



Re: Trouble with Apache::Request

2003-06-06 Thread Randy Kobes
On Fri, 6 Jun 2003, K Old wrote:

 Hello everyone,

 I'm having trouble getting Apache::Request installed on my
 Mandrake 9.0 system.  Let me first say that I'm not using the
 Apache that came with Mandrake 9.0.  I downloaded Apache
 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and
 installed them.  Everything works fine with Apache, mod_perl
 and PHP, except when I need to use Apache::Request (trying to
 use Alzabo browser interface).  BTW, the version of Perl is
 5.8.0.

 When trying to build Apache::Request, here's what I get when I
 do the make test.  I can force the install, but the same error
 comes up when I try to load Apache::Request as a PerlModule in
 httpd.conf or when Alzabo calls it.

 I've scoured mailing list, Google groups and books and can't find any
 help.

 Any chance I should build perl without the threads?  I've heard that can
 be the cause of a lot of problems.
[ .. ]
 t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of
 /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load
 '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so'
 for module Apache::Request: libapreq.so.1: cannot open shared
 object file: No such file or directory at
 /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line
 229.
  at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm
 line 14
 Compilation failed in require at (eval 16) line 3.

 Any help is greatly appreciated!

If there's more than one Apache on your system, it may be that
libapreq found the wrong one. Does it help any if you specify
explicitly the desired Apache at the 'perl Makefile.PL' stage, as
discussed in the install file of the distribution?

-- 
best regards,
randy kobes


pl extension

2003-06-06 Thread pwallett
Hi 

I'm running redhat 9 and trying to execute a perl script through a web
browser 

http://host/file.pl 

and the file displays as text, how do i get my apache to recognize this
extension? 

thanks 

Paul


[OT] Re: pl extension

2003-06-06 Thread Thomas Klausner
Hi!

On Thu, Jun 05, 2003 at 11:00:37AM +0200, [EMAIL PROTECTED] wrote:

 I'm running redhat 9 and trying to execute a perl script through a web
 browser 
 
 http://host/file.pl 
 
 and the file displays as text, how do i get my apache to recognize this
 extension? 

This doesn't seems like a mod_perl question to me. Try a general CGI list:
http://lists.perl.org/showlist.cgi?name=cgi-list

Or read the Apache Docs, especially the section on ScriptAlias:
http://httpd.apache.org/docs-2.0/mod/mod_alias.html#scriptalias


-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}


[mp2] Newbie: How to get CGI params using mp2?

2003-06-06 Thread Jack Nerad
How the heck do you get the parameters from a request?  I don't see any 
methods that look right.  I'd expect them to be on Apache::RequestRec, 
but I can't see anything that is close to matching my idea of what it 
should be named.  Help?

--
Jack Nerad


RE: Trouble with Apache::Request

2003-06-06 Thread K Old
Hi Ged,

On Fri, 2003-06-06 at 13:55, Ged Haywood wrote:
 Hi there,
 
 On 6 Jun 2003, K Old wrote:
 
  No, I didn't build a threaded Perl, it seems to be the popular thing
  among any linux distro these days to build it with threads.  
  
  I'll build a version without threads just to see if it works
 
 Want to run that by me again??
 

Mandrake 9.0 (and several other linux distros) come out of the box with
Perl 5.8.0 built with threads.  I'm guessing that having Perl compiled
with threads might be what's causing the problem in getting
Apache::Request installed.


   I'm having trouble getting Apache::Request installed on my Mandrake 9.0
 [snip]
   make test.  I can force the install, but the same error comes up when I
   try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo
   calls it.
 
 Is it *exactly* the same error?

Well, here are the errors I'm getting:

When I *force* and install of Apache::Request and a script calls
Apache::Request, this is in the error_log:
[Fri Jun  6 17:27:31 2003] [error] Can't locate object method new via
package Apache::Request at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm
line 22.

This is from doing a make test when trying to install Apache::Request
manually:

Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf:
Can't load
'/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module 
Apache::Request: libapreq.so.1: cannot open shared object file: No such file or 
directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
 at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm
line 14
Compilation failed in require at (eval 16) line 3.




Still with the forced install of Apache::Request, if I try to call it
from httpd.conf via PerlModule Apache::Request, I get this error.

Syntax error on line 590 of /usr/local/apache/conf/httpd.conf:
Can't load
'/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so'
 for module Apache::Request: libapreq.so.1: cannot open shared object file: No such 
file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 
229.
 at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm
line 14
Compilation failed in require at (eval 4) line 3.

 
   Any chance I should build perl without the threads?  I've heard that can
   be the cause of a lot of problems.
 
 Just Perl 5.8.0 can cause problems... do you have any others kicking around?
 I'm thinking of 5.7.2 for example (ducks in case Stas throws something :)
 which has done me good service.  Wouldn't recommend 5.6.anything.

I'm starting to agree.  Just this afternoon I build Apache::Request
without any problems on an RH 7.3 box with Perl 5.6.1 compiled without
threads.  Anyone else have Apache::Request running under Perl 5.8.0 with
threads enabled?


 
 [snip]
   t/httpd -f `pwd`/t/httpd.conf
   Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf:
   Can't load 
   '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \
 for module Apache::Request: libapreq.so.1: cannot open shared object file:  \
 No such file or directory
 [snip]
 
 Is there in fact no such file or directory?
 

The file Requests.so does exist and it is in the location being
referenced.  The permissions are 755.

 I don't like that it's even looking in there...  Are you building it all
 as root?  Bad idea generally, although -MCPAN does rather encourage it.

Yeah, I hear ya on the CPAN thingI am building it as root, but have
tried it as a regular user and get the same errors

Any ideas?

Thanks for your help,
Kevin
-- 
K Old [EMAIL PROTECTED]



Re: [mp2] make test fails with 1.99_10-dev sources on redhat

2003-06-06 Thread Haroon Rafique
On Today at 11:32am, SB=Stas Bekman [EMAIL PROTECTED] wrote:

SB 
SB Both failed due to the missing LWP. I was able to reproduce the exact
SB problem by removing LWP/UserAgent.pm. I have now fixed both in cvs.
SB Please 'cvs up' and test again. Thanks.
SB 

after cvs up, make test skipped a bunch of tests in both the first batch
and the 2nd batch (since libwww-perl was not installed). 100% successful.

After that, I installed:
libwww-perl-5.69
CGI.pm-2.93
HTML-Parser-3.28
URI-1.23
to satisfy all dependencies for installing libwww-perl

The tests, that were skipped last time around, ran successfully this time. 
100%.

Now onto investigating my originally reported problem as to why the older,
system-wide installation is interfering with the make test. Any
suggestions on how to get started on that?

Thanks,
--
Haroon Rafique
[EMAIL PROTECTED]



Re: [mp2] make test fails with 1.99_10-dev sources on redhat

2003-06-06 Thread Stas Bekman
Haroon Rafique wrote:
On Today at 11:32am, SB=Stas Bekman [EMAIL PROTECTED] wrote:

SB 
SB Both failed due to the missing LWP. I was able to reproduce the exact
SB problem by removing LWP/UserAgent.pm. I have now fixed both in cvs.
SB Please 'cvs up' and test again. Thanks.
SB 

after cvs up, make test skipped a bunch of tests in both the first batch
and the 2nd batch (since libwww-perl was not installed). 100% successful.
After that, I installed:
libwww-perl-5.69
CGI.pm-2.93
HTML-Parser-3.28
URI-1.23
to satisfy all dependencies for installing libwww-perl
The tests, that were skipped last time around, ran successfully this time. 
100%.
Fantastic, thanks!

Now onto investigating my originally reported problem as to why the older,
system-wide installation is interfering with the make test. Any
suggestions on how to get started on that?
I think the issue is very simple: @INC had system libraries dirs before the 
freshly build ones, so dumping @INC contents prior to libs loading should aid 
the debug. But please use the latest cvs, since I've messed with @INC a bit 
recently.

In parallel, we are planning to verify .so objects that they were created by 
the same mod_perl.so to avoid completely this kind of problems. Well it won't 
prevent the pickup of wrong libraries, it'll just scream aloud when this will 
happen. So your debug is still very important.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: DirectoryIndex doesn't see SetHandler path

2003-06-06 Thread Stas Bekman
Marc M. Adkins wrote:
I hope that this is the issue. Marc has failed to say that he is using
mp2/apache2, so I won't be surprised if this is yet another
problem introduced
by apache-2.0 (incompatible mod_dir behavior wrt apache-1.3). see
my recent
bug reports to the httpd-dev list.


Yah, yah, sorry, Apache 2.0.46 on W2K, ActiveState build 804 (Perl 5.8),
mod_perl/1.99_10-dev.  Postcards from the bleeding edge.
Wish I'd given more attention to your postings on httpd-dev.  I was thinking
this might be a bug and it might not...I'm not always sure what is
_supposed_ to happen.
You don't have to keep up with all those bloody^H^H^H^Heeding lists. The issue 
with Apache 2.0 is that it has totally changed the way it handles existing 
directories which also happen to be assigned to be handled by handlers. One 
thing I didn't try is replacing Location  containers with Directory .

I haven't really delved into the specific issue you have asked about, so I 
might be talking about a totally irrelevant to your problem thing, that's why 
I haven't responded in first place, but just wanted to tell that 2.0 behavior 
might be different.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Trouble with Apache::Request

2003-06-06 Thread Stas Bekman
[ CC'ing the apreq-dev list. In the future please post apreq build problems 
questions to the apreq-dev list: http://httpd.apache.org/apreq/ ]

K Old, please try the httpd-apreq cvs version:

I just did:

% cd httpd-apreq
% perl-5.8.0-ithread Makefile.PL -httpd /home/httpd/httpd_perl/bin/httpd  
make test
...
All tests successful.

This version will be soon released on CPAN, it wasn't released yet due to some 
polishing of Apache::Test that is now used by Apache::Request for its test suite.

Here is how to get the cvs version:

% cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
  CVS password: anonymous
% cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co httpd-apreq
% cd httpd-apreq
% cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co \
  -d Apache-Test httpd-test/perl-framework/Apache-Test
notice that in the example above, you need to adjust a path to your httpd and 
of course the path to perl, perl-5.8.0-ithread in my case is a symlink to 
perl-5.8.0 built with threads.

If your problem still persists please post the output of your 'perl -V' that 
you have used to build Apache::Request

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Apache modules and mod_perl threads in same process?

2003-06-06 Thread Marc M. Adkins
For Apache 2.0.46 / mod_perl 1.99.10-dev:

If I have an Apache module configured in httpd.conf, will the module code be
executing in the same process as the mod_perl code?  If there are multiple
Apache processes (on W2K I always see 2) will the module code exist in all
processes?

mma



Re: Apache modules and mod_perl threads in same process?

2003-06-06 Thread Stas Bekman
Marc M. Adkins wrote:
For Apache 2.0.46 / mod_perl 1.99.10-dev:

If I have an Apache module configured in httpd.conf, will the module code be
executing in the same process as the mod_perl code?  If there are multiple
Apache processes (on W2K I always see 2) will the module code exist in all
processes?
I'm assuming that you are talking about threaded mpms (winnt in your case?)

Then the answer is yes.

Whenever the perchild mpm will be completed, it'll be possible to do grouping. 
However I'm not sure how applicable that would be to winFU platforms.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com