Re: [mp2] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Stas Bekman
Perrin Harkins wrote:
On Tue, 2003-06-10 at 01:45, Stas Bekman wrote:

mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless 
there. not only useless, but also wasteful, since it's going to do work that 
has no added value.


But how is this any different from separate processes really?  Each
thread is a separate interpreter with separate globals and this separate
Apache::DBI persistent handles.  If things are not threadsafe it
crashes, but if they are it should work just like it does for 
multi-process apache, shouldn't it?
I think you are right. I was thinking about pooling across threads. If 
somebody can give it a try and report back (use debug mode to see what 
happens) that would be the simplest check.

connect_on_init() should probably be not used.



__
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] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Perrin Harkins
On Tue, 2003-06-10 at 01:45, Stas Bekman wrote:
> mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless 
> there. not only useless, but also wasteful, since it's going to do work that 
> has no added value.

But how is this any different from separate processes really?  Each
thread is a separate interpreter with separate globals and this separate
Apache::DBI persistent handles.  If things are not threadsafe it
crashes, but if they are it should work just like it does for 
multi-process apache, shouldn't it?

- Perrin



Re: [mp2] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Stas Bekman
Perrin Harkins wrote:
On Mon, 2003-06-09 at 21:02, Stas Bekman wrote:

Paul Simon wrote:

So, according to the docs,
http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM,
using Apache::DBI doesn't do anything under
mp2+windows2000 ...
That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on 
winFU, runs one process with many threads. So Apache::DBI is useless there.


Wait a minute, it's only useless if DBI and DBD::Oracle are not thread
safe.  Do we know if that's true?
Yes, but:

mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless 
there. not only useless, but also wasteful, since it's going to do work that 
has no added value.

Of course I tell all that without ever using winFU, but I don't think this is 
a wrong assumption if the server doesn't fork.

Just to be clear, Apache::DBI stores database handles in globals, which
are not shared between threads.  This provides persistence.  DBI::Pool
is a more ambitious idea to allow the handles to be actually shared,
providing "pooling" as well as persistence.
Once DBI::Pool will be available, Apache::DBI may use it internally, or it may 
become obsolete altogether.

But since you are using Oracle, if I remember correctly DBD::Oracle provides 
an internal pooling support. I could be wrong, please check the docs.


It's called ora_dbh_share.  I haven't tried it yet, and probably won't
for a bit since I'm not using Oracle at the moment.




__
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] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 21:02, Stas Bekman wrote:
> Paul Simon wrote:
> > So, according to the docs,
> > http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM,
> > using Apache::DBI doesn't do anything under
> > mp2+windows2000 ...
> 
> That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on 
> winFU, runs one process with many threads. So Apache::DBI is useless there.

Wait a minute, it's only useless if DBI and DBD::Oracle are not thread
safe.  Do we know if that's true?

Just to be clear, Apache::DBI stores database handles in globals, which
are not shared between threads.  This provides persistence.  DBI::Pool
is a more ambitious idea to allow the handles to be actually shared,
providing "pooling" as well as persistence.

> But since you are using Oracle, if I remember correctly DBD::Oracle provides 
> an internal pooling support. I could be wrong, please check the docs.

It's called ora_dbh_share.  I haven't tried it yet, and probably won't
for a bit since I'm not using Oracle at the moment.

- Perrin



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

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 09:55, Haroon Rafique wrote:
> Now onto serious stuff. /usr/bin/perl here is the system-wide perl install
> that came bundled with Redhat.

Just a thought: did you fix the locale on that machine?  Most of CPAN
won't compile on Red Hat 8 and 9 because of the broken UTF8 locale
setting they have.  If you haven't already, edit /etc/sysconfig/i18n and
change LANG="en_US.UTF-8" to LANG="en_US.ISO8859-1".  That fixed many
mysterious things for me.

- Perrin



ANNOUNCE: Embperl 2.0b9

2003-06-09 Thread Gerald Richter
The URL

ftp://ftp.dev.ecos.de/pub/perl/embperl/Embperl-2.0b9.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/G/GR/GRICHTER/Embperl-2.0b9.tar.gz
  size: 654860 bytes
   md5: 3a4836d15100feb2bf9c37e9470a1d1d


While development has continued all the time, there was a long time no
release of Embperl, so it's really overdue.

This version fixes a number of bugs and adds a lot of enhancements. My plan
is to make the next release the final 2.0. So give it a try, so we can catch
as much problems as possible before.

Embperl is a system for building dynamic websites with Perl.
It gives you the power to embed Perl code in your HTML/XML documents
and the ability to build your Web site out of small reusable objects in
an object-oriented style. You can also take advantage of all the
usual Perl modules, (including DBI for database access) use their
functionality and easily include their output in your web pages.

Embperl has several features which are especially useful for creating
Websites, including dynamic tables, form field processing, URL
escaping/unescaping, session handling, caching, xslt transformation
and more.

See http://perl.apache.org/embperl/ (english) or
http://www.ecos.de/embperl/ (german) for more information.


Enjoy

Gerald

Changes since 2.0b8:

   - libxml now searchs through Embperl search path when includeing external
entities,
 so for example  directives searchs files the same way as
Execute
 does under Embperl::Object.
   - fixed typo in JavaScript code for Form::Validate reported by Axel
Beckert
   - fixed typo in Embperl::Mail reported by Axel Beckert.
   - fixed small bugs in Embperl::Form::Validate test code reported by Axel
Beckert.
   - charcters 128-160 are now escaped in URLs to avoid problems with
Mozilla.
   - fixed missing escaping of '/' in Embperl::Form::Validate JS routines.
 Patch from Axel Beckert.
   - fixed spelling: CACKE_KEY -> CACHE_KEY. Reported by Andre Landwehr.
   - URL escaping now fully conforms to RFC 2396. This mainly solves some
problems
 where IE interpreted characters in URLs as UTF8.
   - Embperl::Form::Validate JavaScript code can now handle fieldnames that
 aren't correct JavaScript identifier.
   - Fix SIGSEGV when printing to Embperl::LOG before Embperl log file is
setup.
   - Fix problem when session id is given to Embperl, but session management
 was not setup
   - Added 'same' validation to check if two fileds have the same input
enterd
   - Fixed memory leak. Patch from Joshua Chamas.
   - Use MP_AP_PREFIX as source for APache 2. Patch from Paul Dyer.
   - Fixed a initialisation bug which caused under special conditions a
segfault
 when compiling a select tag.
   - Fixed compiler warnings and errors when compiling with Perl 5.8.0.
   - Replaced PL_sv_undef with ep_sv_undef (which is a copy of PL_sv_undef),
 because storing PL_sv_undef in a Perl 5.8.0 hash is treated as a
placeholder
 and doesn't work as before.
   - Fixed problem with [$ sub $] when running under Perl 5.8.0.
   - Fixed problem when STDOUT is tied, because storage has changed in Perl
5.8.0.
   - Fixed problem when single quote or backslash is inside of option or
input value.
 Bug reported by Saadiq Rodgers-King.
   - Added [$last$], [$next$], [$redo$] and documented [* next *] etc.
   - Readdeded missing MailFormTo and added test for it.
   - Fixed escaping inside of html attributes of Embperl generated tags like
input
 and [$ hidden $]. Reported by Axel Beckert.
   - checked and selected attributes are now correctly set when values
contains
 entities (e.g. <)
   - Fixed segfault when cleanup is called to early. Reported by Neil
Gunton.
   - If no name is given for a key, Form::Validate now tries to lookup the
correct
 text via Embperl's gettext method.
   - Fixed problem with message ids that are Perl keywords. Reported by
Jaak.
   - Added EMBPERL_COOKIE_SECURE option to transfer cookie only over a
secure
 connection.
   - Added EMBPERL_OUTPUT_MODE that allows to change to XML output, which
cause
 generated tags to contains a closing slash, so they are valid
XML/XHTML.
   - Fixed make test to ignore different idention of newer versions of
 libxslt.
   - Added server_addr to the request param object.
   - Keep spaces and newlines in  tag.
   - Embperl::Mail now encodes all header fields that contains characters
between
 128 and 255. Use headerencoding parameter to turn of or tell Embperl
your charset.
   - Fixed mod_perl 2 detection when mod_perl is build with MP_INST_APACHE2.
   - Fixed problem with reseting $escmode, when using print OUT. Reported by
 David Hull.
   - Fixed compiling problem on FreeBSD.
   - Added function XML::Embperl::DOM::iSetText to change name of Tag.
 Requested by Yatin Chawathe.
   - EMBPERL_COOKIE_EXPIRES now again accepts relatives times like +2h.
   - embpexec.pl now correctly takes config values from environment
 for application object.
   - Added -type => Integer, IPAd

testing your CPAN modules with Apache::Test and both mod_perl generations

2003-06-09 Thread Stas Bekman
Just in case you didn't know, you can use Apache::Test for testing your code 
with both mod_perl generations. It certainly helps to automate the testing. 
For example I use the following simple smoker script to run the test suite on 
Apache::Peek with different versions of perl and mod_perl.

Kudos to Barrie Slaymaker for the wonderful IPC::Run.

BTW, Philippe has a more advanced smoker (with much better reporting) but he 
won't let it to see the light before he makes it perfect ;)

For more info on Apache-Test see Geoff's article:
http://www.perl.com/pub/a/2003/05/22/testing.html
and the online manual:
http://perl.apache.org/docs/general/testing/testing.html
--

#!/usr/bin/perl

use strict;
use warnings;
use IPC::Run qw(run timeout);

use constant TIMEOUT => 5*60;
use constant DEBUG   => 0;
$SIG{INT} = sub { report(); exit; };

my %report = (ok => 0, nok => 0, failed => {});
my $test = 0;
while () {
next if /^\s*(#.*|$)/;
chomp;
run_test($_);
}
report();

sub run_test {
my $command = shift;
my @cmds = split /\s*&&\s*/, $command;
$test++;
my $cnt = 0;
my $failed = 0;
for my $cmd (@cmds) {
next unless $cmd =~ /\S/;
$cnt++;
print "[$test.$cnt] $cmd\n";
my @cmd = split /\s+/, $cmd;
my($in, $out, $err);
my $ok = 0;
eval {
$ok = run [EMAIL PROTECTED], \$in, \$out, \$err,
debug => DEBUG, timeout(TIMEOUT);
};
warn "[EMAIL PROTECTED]" if $@;
$ok = 1 if $cmd =~ /make clean/; # ignore 'make clean' errors
unless ($ok) {
print "\n\tFAILURE!\n\n";
print "STDOUT:\n$out\n" if $out;
print "STDERR:\n$err\n" if $err;
push @{ $report{failed}{$command} }, "($cnt) $cmd";
$failed++;
last;
}
if (@cmd == 2 && $cmd[0] eq 'make' && $cmd[1] eq 'test') {
my $result = $out =~ /All tests successful/ ? "OK" : "NOT OK";
print "\n\t$result\n\n";
}
}
$failed ? $report{nok}++ : $report{ok}++;
print "\n", "-" x 40, "\n\n";
}
sub report {
my $format = "%-7s: %3d\n";
printf $format, "Success", $report{ok};
printf $format, "Failure", $report{nok};
print "-" x 16, "\n";
printf $format, "Total", $report{ok}+$report{nok};
my @failed = keys %{ $report{failed} };
if (@failed) {
print join "\n", '',
"Failed commands:", "-" x 16,
map { join("\n\t", $_, @{ $report{failed}{$_}||[] }),"\n"} @failed;
}
}
__DATA__
# need to test all these combinations
### mp2 DSO ###

make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1 Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl 
/home/stas/httpd/prefork/modules/mod_perl-5.6.1.so -port select MOD_PERL=2 && 
make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0 Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.0.so -port select 
MOD_PERL=2 && make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0-ithread Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.0-ithread.so -port 
select MOD_PERL=2 && make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1 Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.1.so -port select 
MOD_PERL=2 && make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1-ithread Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.1-ithread.so -port 
select MOD_PERL=2 && make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-blead Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-blead.so -port select 
MOD_PERL=2 && make && make test

make clean && /usr/bin/env CCFLAGS="-g" perl-blead-ithread Makefile.PL -httpd 
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-blead-ithread.so -port 
select MOD_PERL=2 && make && make test

### worker 2.0 ###

make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1-ithread Makefile.PL -httpd 
/home/stas/httpd/worker/bin/httpd -libmodperl mod_perl-5.8.1-ithread.so -port 
select MOD_PERL=2 && make && make test

### mp1 NON-DSO ###

#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.00503 Makefile.PL -httpd 
/home/httpd/httpd_perl/bin/httpd-5.00503 -port select MOD_PERL=1 && make && 
make test

#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1-ithread Makefile.PL -httpd 
/home/httpd/httpd_perl/bin/httpd-5.6.1-ithread -port select MOD_PERL=1 && make 
&& make test

#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1 Makefile.PL -httpd 
/home/httpd/httpd_perl/bin/httpd-5.6.1 -port select MOD_PERL=1 && make && make 
test

#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0-ithread Makefile.PL -httpd 
/home/httpd/httpd_perl/bin/httpd-5.8.0-ithread -port select MOD_PERL=1 && make 
&& make test

#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0 Makefile.PL -httpd 
/home/httpd/httpd_perl/bin/httpd-5.8

Re: modules that work with both modperl1 and 2

2003-06-09 Thread Stas Bekman
speeves wrote:
Stas Bekman wrote:
[...]
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm 

That did it!!!  Thank you so much for your patience and help with all 
that I am working on here.  After I test these changes on modperl 1 
tomorrow, I should be able to upload it to CPAN, and it will be ready 
for prime-time...  (fingers crossed ;) )
Based on your porting experience if you have additions/corrections to these 
two documents:
http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/2.0/user/porting/compat.html
please submit those here.

BTW, I have updated the info on the constants:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
__
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: modules that work with both modperl1 and 2

2003-06-09 Thread speeves
Stas Bekman wrote:

Shannon Eric Peevey wrote:

Perrin Harkins wrote:

On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:

To answer your original question, Apache::Peek on CPAN now works with 
both mod_perl versions. And while it uses separate implementations for 
each version, the test suite uses the same code to test both.

Yeah, I've been messing with that, but it seems to me that I need 
something similar to a preprocessor directive, where I can load the 
appropriate "use MODULE" lines into the module bases upon which 
version of modperl they have installed.  Is it possible to use the 
BEGIN {} subroutine as this?
  


You don't need a preprocessor.  You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:

if ($mod_perl::VERSION >= 1.99) {
 require Apache2::Module;
 import Apache2::Module;
} else {
 require Apache1::Module;
 import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to.  That
will make it run before the rest of the code in the current package.
- Perrin

Ok, I'm back... :(  Here is the code, modified to use "require":

use mod_perl;

# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
   require Apache::Const;
   import Apache::Access;
   require Apache::Access;
   import Apache::Access;
   require Apache::Connection;
   import Apache::Connection;
   require Apache::Log;
   import Apache::Log;
   require Apache::RequestRec;
   import Apache::RequestRec;
   require Apache::RequestUtil;
   import Apache::RequestUtil;
}


You don't need to import anything, since none of these modules import 
anything. Just require will do.

Here is the code that is coughing up the error:

 102   #Look for user based on UIDAttr
   103
   104my $attrs = ['dn'];
   105   $mesg = $ldap->search(
   106   base => $basedn,
   107   scope => 'sub',
   108   filter => "($uidattr=$user)",
   109   attrs => $attrs
   110  );
   111
   112 if (my $error = $mesg->code())
   113{
   114 $r->note_basic_auth_failure;
   115 MP2 ? $r->log_error("user $user: LDAP Connection 
Failed: $error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
   116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;


this should be:

return MP2 ? Apache::HTTP_UNAUTHORIZED : 
Apache::Constants::HTTP_UNAUTHORIZED;

and before the handler (at the top of your module) you need to add:

BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm 


   117}
   118
   119unless ($mesg->count())
   120{
   121 $r->note_basic_auth_failure;
   122 MP2 ? $r->log_error("user $user: user entry not found 
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter: 
$uidattr=$user",$r->uri);
   123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;
   124}

And, here is the error that I am getting in the Apache2 logs, (using 
mod_perl 1.99_09)

[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found 
for filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate 
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps 
you forgot to load "Apache::Log"?) at 
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.

As you can see, it is running everything up to the HTTP_UNAUTHORIZED 
constant...

If you have any ideas, I would greatly appreciate it. :)

Thanks,
speeves
cws
PS.  As a matter of fact, I get the same error when using "use" 
instead...  (Possibly a screwed perl or mod_perl installation?  I'm 
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)




Hi!

That did it!!!  Thank you so much for your patience and help with all 
that I am working on here.  After I test these changes on modperl 1 
tomorrow, I should be able to upload it to CPAN, and it will be ready 
for prime-time...  (fingers crossed ;) )

Most humbly yours,
speeves
cws



Simple DAV Server?

2003-06-09 Thread Trevor Phillips
I'm quite suprised at the limited amount of custom DAV server uses. I mean, 
here's a protocol for editing content over HTTP, which to me screams as an 
ideal solution for, say, editing full HTML content within a DB/CMS.

I mean, I've been working as Technical Support at a uni for Web Services, and 
there seems to be these two sides; on one side are the advocates of a 
file-based system, using any range of HTML editing tools to edit your content 
(and preferrably some server-side templating for maintaining common look and 
feel). On the other side is a content management system, which is heavily 
template structured, with content being chunks of text (or HTML) edited using 
web forms, or custom editors (eg; in Java).

One way of obtaining the advantages of both of these techniques would be to 
use a DB-driven CMS, but edit the content chunks using a DAV editor.

I'd like to write a simple DAV interface to a DB myself, but I'm looking for 
existing perl modules to make things easier, but I haven't found a heck of a 
lot along these lines. Most Perl Dav things seem to be more client focussed.

Of those that are for server stuff, they seem either overly complicated (eg; 
Apache::DAV), or fairly immature, and still emphasising filesys structures 
(eg; HTTP::DAVServer).

I suppose what I'm after is an implementation which is easily adaptable to 
editing data within a DB. I'm considering implementing enough of the HTTP 
methods to be functional myself, but would rather not bite off more than I 
have time to chew if there's a nicer solution.

Any suggestions?

-- 
. Trevor Phillips -   http://jurai.murdoch.edu.au/ . 
: Web Technical Administrator -  [EMAIL PROTECTED] : 
| IT Services-  Murdoch University | 
 ><
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
 \  -- (Terry Pratchett, Wyrd Sisters)  /



Re: [mp2] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Stas Bekman
Paul Simon wrote:
So, according to the docs,
http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM,
using Apache::DBI doesn't do anything under
mp2+windows2000 ...
That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on 
winFU, runs one process with many threads. So Apache::DBI is useless there.

What is the status of DBI::Pool?
I've posted a hard-coded mysql prototype to the dbi-dev list a few months ago. 
Tim has added the required DBI support recently, but I haven't had a chance to 
do any work on it since then. If you or anybody else is interested in helping 
to code DBI::Pool let me know.

These modules deal mainly with persistent database
connections. Is that correct?
That's correct.

But since you are using Oracle, if I remember correctly DBD::Oracle provides 
an internal pooling support. I could be wrong, please check the docs.

__
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


[mp2] win2000 + Apache::DBI + Oracle

2003-06-09 Thread Paul Simon
So, according to the docs,
http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM,
using Apache::DBI doesn't do anything under
mp2+windows2000 ... What is the status of DBI::Pool?
These modules deal mainly with persistent database
connections. Is that correct?

Paul 


Re: PerlOptions Clone/Parent in mp2

2003-06-09 Thread Stas Bekman
Marc M. Adkins wrote:
However I think it is possible to make the architecture more
flexible to allow
pools sharing across specific vhosts, or even location containers (if the
scope is set to be only for the handler). e.g. something like:
#base server


# parameters


# parameters


PerlUseTiPool A


PerlUseTiPool A


PerlUseTiPool B


PerlUseTiPool B



Yeah, that would do it.  I don't know how many people will need this,
probably not so many.  And there might be a sufficient work-around in those
rare (?) cases involving multiple Apache instantiations and a proxy server
to tie it all together.  Something like the high-volume configurations I've
seen documented, only with one mod_perl-enhanced server for each TIPool.
The code to implement blocks (e.g. ...) in config files is
pretty gnarly, too.  I know it's already there for , it's one of the
places I looked when I was considering doing one of my own and wanted to see
an example.  The Apache framework is pretty strong for putting in new
directives, but not so much for adding new blocks.
Actually you can't quite do that in a 3rd party module. Currently the pools 
are internal to mod_perl. Making this customizable will require adding hooks 
to the internal tipool mechanism. When I wrote the above pseudo-config I was 
suggesting an internal support for these.

__
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: PerlOptions Clone/Parent in mp2

2003-06-09 Thread Marc M. Adkins
> However I think it is possible to make the architecture more
> flexible to allow
> pools sharing across specific vhosts, or even location containers (if the
> scope is set to be only for the handler). e.g. something like:
>
> #base server
>
> 
> # parameters
> 
> 
> # parameters
> 
>
> 
> PerlUseTiPool A
> 
> 
> PerlUseTiPool A
> 
>
> 
> PerlUseTiPool B
> 
> 
> PerlUseTiPool B
> 

Yeah, that would do it.  I don't know how many people will need this,
probably not so many.  And there might be a sufficient work-around in those
rare (?) cases involving multiple Apache instantiations and a proxy server
to tie it all together.  Something like the high-volume configurations I've
seen documented, only with one mod_perl-enhanced server for each TIPool.

The code to implement blocks (e.g. ...) in config files is
pretty gnarly, too.  I know it's already there for , it's one of the
places I looked when I was considering doing one of my own and wanted to see
an example.  The Apache framework is pretty strong for putting in new
directives, but not so much for adding new blocks.

mma



Re: Compling mod_perl as a static module....

2003-06-09 Thread Ged Haywood
Hello again,

On Mon, 9 Jun 2003, Forrest Aldrich wrote:

> Referring back to my original post, it with the options I specified, the 
> compile process still insists on compiling mod_perl as a DSO.   Even if I 
> explicitly set USE_DSO=0 -- I wonder if one of the other flags (like 
> EVERYTHING=1) is triggering the DSO compile.

No, I often compile statically with EVERYTHING=1.  I don't think we're
dealing with a full deck here.  Are you quite sure that you're looking
at the right executable after you build it?  Check the timestamp.  Try
running it by giving the full pathname and the -l switch for example

/home/forrest/src/apache_1.3.27/src/httpd -l

or change to the directory that the exewcutable is in and say

./httpd -l

(you can do both without being root) and see if the output includes a line

mod_perl.c

which tells you that mod_perl is compiled in (i.e. compiled statically).

73,
Ged.



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

2003-06-09 Thread Stas Bekman
Haroon Rafique wrote:
On Saturday at 9:22am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote:

SB> I think the issue is very simple: @INC had system libraries dirs
SB> before the freshly build ones, so dumping @INC contents prior to libs
SB> loading should aid the debug. But please use the latest cvs, since
SB> I've messed with @INC a bit recently.
SB> 
SB> In parallel, we are planning to verify .so objects that they were
SB> created by the same mod_perl.so to avoid completely this kind of
SB> problems. Well it won't prevent the pickup of wrong libraries, it'll
SB> just scream aloud when this will happen. So your debug is still very
SB> important.
SB> 

Seeing that you were answering emails even on a Saturday, I feel guilty
about taking that out of town trip yesterday. Oh well! I think we should
be able to enjoy the little bit of summer that we get here in Canada to
the fullest.
Actually it was Sunday (future!) and it's winter (past?) here in Melbourne ;)

Now onto serious stuff. /usr/bin/perl here is the system-wide perl install
that came bundled with Redhat.
/usr/bin/perl -MApache2 -Mmod_perl -le 'print mod_perl->VERSION'
1.9908
I posted t/REPORT output in the beginning of the thread and can
repost upon request.
no need to

I did a cvs up, and issued:

* /usr/bin/perl Makefile.PL MP_AP_PREFIX=/servers/httpd-2.0.44-pl 
* make
* make test

and was greeted by the now familiar output (same as originally reported)

/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -clean
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -clean
sh: line 1: ulimit: core file size: cannot modify limit: Operation not 
permitted
APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -verbose=0 
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -verbose=0
sh: line 1: ulimit: core file size: cannot modify limit: Operation not 
permitted
/servers/httpd-2.0.44-pl/bin/httpd  -d 
/home/haroon/src/build/modperl-2.0/t -f 
/home/haroon/src/build/modperl-2.0/t/conf/httpd.conf -DAPACHE2 
-DPERL_USEITHREADS
using Apache/2.0.44 (prefork MPM)

waiting for server to start: ..[Mon Jun 09 09:38:20 2003] [info] 22 
Apache:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] 5 APR:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] base server + 9 vhosts ready to run 
tests
[Mon Jun 09 09:38:20 2003] [error] Invalid CODE attribute: 
TestFilter::in_init_basic at 
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm 
line 30
BEGIN failed--compilation aborted at 
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm 
line 30.
Compilation failed in require at (eval 35) line 3.

[Mon Jun 09 09:38:20 2003] [error] Can't load Perl module 
TestFilter::in_init_basic for server localhost.localdomain:8529, 
exiting...

!!! 
server has died with status 255 (t/logs/error_log wasn't created, start 
the server in the debug mode)
make: *** [run_tests] Error 143
Well, nothing has changed, hasn't it? Now try to figure out which .so gets 
loaded and why it is not the locally built one. The module in question is 
Apache::Filter

For example change TestFilter/in_init_basic.pm to dump the location of the 
Apache::Filter library.

Index: t/filter/TestFilter/in_init_basic.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/in_init_basic.pm,v
retrieving revision 1.2
diff -u -r1.2 in_init_basic.pm
--- t/filter/TestFilter/in_init_basic.pm9 May 2003 03:33:37 -  1.2
+++ t/filter/TestFilter/in_init_basic.pm9 Jun 2003 23:45:58 -
@@ -11,6 +11,8 @@
 use base qw(Apache::Filter);

+BEGIN { warn "Apache::Filter $INC{'Apache/Filter.pm'}" }
+
 use Apache::Const -compile => qw(OK M_POST);
 use constant READ_SIZE  => 1024;

Then, if it's indeed your globally installed Apache::Filter and not the local 
one, dump @INC (in the same place) to see whether the global path comes before 
the local one.

__
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: PerlOptions Clone/Parent in mp2

2003-06-09 Thread Stas Bekman
Marc M. Adkins wrote:
wrt Apache 2.0, mod_perl 2.0...

I'm not using Clone or Parent at the current time, but I was re-reading the
documentation on them for an unrelated reason and started thinking about how
they would work.
Suppose I want to set up five virtual hosts with modules A - E.  Then I want
to set up six virtual hosts with modules F - M.  The first five virtual
hosts can all share a pool of interpreters and the second six virtual hosts
can share a different pool of interpreters.
How might I declare two parent interpreters globally, one with modules A - E
and the other with modules F - M such that I could share a pool of
interpreters derived from the first parent with five virtual hosts and a
pool of interpreters derived the second parent with a different six virtual
hosts?
This is all theoretical, I don't actually need this right now, and probably
won't ever.  Just trying to imagine how these options would be used.
Currently you can't do that. Each vhost can inherit from the base server perl, 
clone it or start a while new pool of interpreters.

However I think it is possible to make the architecture more flexible to allow 
pools sharing across specific vhosts, or even location containers (if the 
scope is set to be only for the handler). e.g. something like:

#base server


# parameters


# parameters


PerlUseTiPool A


PerlUseTiPool A


PerlUseTiPool B


PerlUseTiPool B

Of course we are talking about threaded mpms here.

__
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: modules that work with both modperl1 and 2

2003-06-09 Thread Stas Bekman
Shannon Eric Peevey wrote:
Perrin Harkins wrote:

On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
To answer your original question, Apache::Peek on CPAN now works with both 
mod_perl versions. And while it uses separate implementations for each 
version, the test suite uses the same code to test both.

Yeah, I've been messing with that, but it seems to me that I need 
something similar to a preprocessor directive, where I can load the 
appropriate "use MODULE" lines into the module bases upon which 
version of modperl they have installed.  Is it possible to use the 
BEGIN {} subroutine as this?
  


You don't need a preprocessor.  You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:

if ($mod_perl::VERSION >= 1.99) {
 require Apache2::Module;
 import Apache2::Module;
} else {
 require Apache1::Module;
 import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to.  That
will make it run before the rest of the code in the current package.
- Perrin

Ok, I'm back... :(  Here is the code, modified to use "require":

use mod_perl;

# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
   require Apache::Const;
   import Apache::Access;
   require Apache::Access;
   import Apache::Access;
   require Apache::Connection;
   import Apache::Connection;
   require Apache::Log;
   import Apache::Log;
   require Apache::RequestRec;
   import Apache::RequestRec;
   require Apache::RequestUtil;
   import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import 
anything. Just require will do.

Here is the code that is coughing up the error:

 102   #Look for user based on UIDAttr
   103
   104my $attrs = ['dn'];
   105   $mesg = $ldap->search(
   106   base => $basedn,
   107   scope => 'sub',
   108   filter => "($uidattr=$user)",
   109   attrs => $attrs
   110  );
   111
   112 if (my $error = $mesg->code())
   113{
   114 $r->note_basic_auth_failure;
   115 MP2 ? $r->log_error("user $user: LDAP Connection Failed: 
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
   116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;
this should be:

return MP2 ? Apache::HTTP_UNAUTHORIZED : Apache::Constants::HTTP_UNAUTHORIZED;

and before the handler (at the top of your module) you need to add:

BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
   117}
   118
   119unless ($mesg->count())
   120{
   121 $r->note_basic_auth_failure;
   122 MP2 ? $r->log_error("user $user: user entry not found for 
filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter: 
$uidattr=$user",$r->uri);
   123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;
   124}

And, here is the error that I am getting in the Apache2 logs, (using 
mod_perl 1.99_09)

[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for 
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate 
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you 
forgot to load "Apache::Log"?) at 
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.

As you can see, it is running everything up to the HTTP_UNAUTHORIZED 
constant...

If you have any ideas, I would greatly appreciate it. :)

Thanks,
speeves
cws
PS.  As a matter of fact, I get the same error when using "use" 
instead...  (Possibly a screwed perl or mod_perl installation?  I'm 
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)




--

__
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: modules that work with both modperl1 and 2

2003-06-09 Thread Shannon Eric Peevey
Perrin Harkins wrote:

On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
 

Yeah, I've been messing with that, but it seems to me that I need 
something similar to a preprocessor directive, where I can load the 
appropriate "use MODULE" lines into the module bases upon which version 
of modperl they have installed.  Is it possible to use the BEGIN {} 
subroutine as this?
   

You don't need a preprocessor.  You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:

if ($mod_perl::VERSION >= 1.99) {
 require Apache2::Module;
 import Apache2::Module;
} else {
 require Apache1::Module;
 import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to.  That
will make it run before the rest of the code in the current package.
- Perrin

Ok, I'm back... :(  Here is the code, modified to use "require":

use mod_perl;

# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
   require Apache::Const;
   import Apache::Access;
   require Apache::Access;
   import Apache::Access;
   require Apache::Connection;
   import Apache::Connection;
   require Apache::Log;
   import Apache::Log;
   require Apache::RequestRec;
   import Apache::RequestRec;
   require Apache::RequestUtil;
   import Apache::RequestUtil;
}
Here is the code that is coughing up the error:

 102   #Look for user based on UIDAttr
   103
   104my $attrs = ['dn'];
   105   $mesg = $ldap->search(
   106   base => $basedn,
   107   scope => 'sub',
   108   filter => "($uidattr=$user)",
   109   attrs => $attrs
   110  );
   111
   112 if (my $error = $mesg->code())
   113{
   114 $r->note_basic_auth_failure;
   115 MP2 ? $r->log_error("user $user: LDAP Connection Failed: 
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
   116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;
   117}
   118
   119unless ($mesg->count())
   120{
   121 $r->note_basic_auth_failure;
   122 MP2 ? $r->log_error("user $user: user entry not found 
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter: 
$uidattr=$user",$r->uri);
   123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return 
Apache::Constants->HTTP_UNAUTHORIZED;
   124}

And, here is the error that I am getting in the Apache2 logs, (using 
mod_perl 1.99_09)

[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for 
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate 
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you 
forgot to load "Apache::Log"?) at 
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.

As you can see, it is running everything up to the HTTP_UNAUTHORIZED 
constant...

If you have any ideas, I would greatly appreciate it. :)

Thanks,
speeves
cws
PS.  As a matter of fact, I get the same error when using "use" 
instead...  (Possibly a screwed perl or mod_perl installation?  I'm 
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)





Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
On Mon, 2003-06-09 at 15:24, Perrin Harkins wrote:
> [ Please keep it on the list. ]
> 
Sorry about that!

> On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > > Ryan, can you post a more complete code example?
> > > 
> > > - Perrin
> > Here it is:
> > 
> > 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;
> > return OK unless $r->is_main;
> > 
> > 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 $cn = $r->subprocess_env('MOD_PERL');
> >  #   $log->notice("test: $ENV{'MOD_PERL'}");
> > my $apachecertcomp = $r->subprocess_env{$certcomponent};
> 
> That should be $r->subprocess_env($certcomponent).  It's a method, not a
> hash key.  Also, put the lookup_uri stuff back in, since it seems that
> you need it when trying to get the stuff from mod_ssl.
> 
> - Perrin

I must have been stupid.  Making those two corrections, everything works
(Almost)!  Right now it is failing on my attempts to set the user
variable (I want to be able to set REMOTE_USER to an arbitrary cert
field).  I'll have to dig a bit to figure out how to do that.  Thank you
everyone on the list for helping me out so much today - I really
appreciate it.  Many days of hair-pulling are at an end. ;-)

--Ryan


Re: getting *any* variables out of the server environment

2003-06-09 Thread Perrin Harkins
[ Please keep it on the list. ]

On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > Ryan, can you post a more complete code example?
> > 
> > - Perrin
> Here it is:
> 
> 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;
> return OK unless $r->is_main;
> 
> 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 $cn = $r->subprocess_env('MOD_PERL');
>  #   $log->notice("test: $ENV{'MOD_PERL'}");
> my $apachecertcomp = $r->subprocess_env{$certcomponent};

That should be $r->subprocess_env($certcomponent).  It's a method, not a
hash key.  Also, put the lookup_uri stuff back in, since it seems that
you need it when trying to get the stuff from mod_ssl.

- Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
Actually, upon flushing my browser cache and checking again, I can in
fact read the MOD_PERL environment variable just fine.  But still no
luck on any mod_ssl related variables.

--Ryan


Re: Mod_perl 1.99 spawning processes causing major performanceissue

2003-06-09 Thread Perrin Harkins
Thanks for using REPORT!

On Mon, 2003-06-09 at 16:07, George Bagley wrote:
> On Apache 1.3, when I do a ps -ef, I cannot see the cgi script running.
> I assume this is because Apache is NOT spawning a separate process to
> satisfy the request.
> 
> On Apache2, there are hundreds of the cgi scripts running and
> performance is roughly half what it was on Apache 1.3

Sounds like your scripts are not actually running under mod_perl.  To
test this, you can try printing out the value of $ENV{'MOD_PERL'} in one
of them.  If you're running under mod_perl (via ModPerl::Registry) that
variable will be defined.

> # PerlModule ModPerl::Registry
> 
> AddHandler cgi-script cgi pl
> #   AddHandler perl-script .pl
> #   PerlResponseHandler Apache::Registry
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> AllowOverride None
> Options +ExecCGI -Includes
> #   SetHandler perl-script
> SetHandler cgi-script
> 

That last line is the problem.  The perl-script one should be
uncommented, not the cgi-script one.

- Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Geoffrey Young

Ok, removed.  Thank you very much for the in-depth replies.  It is very
useful.  Unfortunately any variable-reading continues to elude me.  But
I really appreciate all the help!
well, it sounds like you are having a larger problem that just mod_ssl-based 
variables.

since you mention you're interested in learning...  :)

if you really want to track this down you could start from the beginning, 
meaning a bare bones server and a bare bones mod_perl content handler that 
merely iterates over %ENV and $r->subprocess_env() (see the do() method from 
Apache::Table)

this kind of bare bones thing used to be a pain, but with Apache-Test, it 
has gotten _lots_ easier.  you can find Apache-Test on CPAN

http://search.cpan.org/CPAN/authors/id/S/ST/STAS/Apache-Test-1.01.tar.gz

you can look at some of the SSL tests in the Perl-Framework

http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/

to see how they use Apache-Test to test SSL based things.  for instance 
env.t tests basic environment setting for SSL connections - you can use that 
as the starting point for writing tests for your own stuff.

or you can even download the Perl framework from

http://httpd.apache.org/test/

and run the ssl tests to make sure you're server is configured properly.

just some advice, and you certainly don't need to go through all the effort 
of reading, setting up the test environment, etc.  however, once you get 
Apache-Test set up it will make your module development much, much easier, 
and you'll be able to pinpoint exactly where things go wrong much easier.

some basic explanations and pointers to other docs can be found here

http://www.perl.com/pub/a/2003/05/22/testing.html

HTH

--Geoff



Mod_perl 1.99 spawning processes causing major performance issue

2003-06-09 Thread George Bagley

-8<-- Start Bug Report 8<--
1. Problem Description:

 Hi

I have ugraded from apache1.3 to Apache2 and I am having a performance
problem with a cgi script.
Hardware
Dell 2550, Dual Proc, 2GB RAM, RedHat Linux 9.0

On Apache 1.3, when I do a ps -ef, I cannot see the cgi script running.
I assume this is because Apache is NOT spawning a separate process to
satisfy the request.

On Apache2, there are hundreds of the cgi scripts running and
performance is roughly half what it was on Apache 1.3

The cgi script in question makes a connection to a mysql database.  

I have had to increase the max number of connections allowed by mysql to
allow for the large number of spawned perl processes attempting to make
a DB connection.

Is there a configuration option to stop this happening?  

I have the following relating to perl in my httpd.conf

# LoadModule foo_module modules/mod_foo.so
#
LoadModule perl_module modules/mod_perl.so
# PerlRequire "/usr/local/apache2/2.0.45/conf/startup.pl"
PerlModule Apache2

# PerlModule ModPerl::Registry

AddHandler cgi-script cgi pl
#   AddHandler perl-script .pl
#   PerlResponseHandler Apache::Registry
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
AllowOverride None
Options +ExecCGI -Includes
#   SetHandler perl-script
SetHandler cgi-script



2. Used Components and their Configuration:

*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
  MP_AP_PREFIX=> /usr/local/apache
  MP_COMPAT_1X=> 1
  MP_GENERATE_XS  => 1
  MP_INST_APACHE2 => 1
  MP_LIBNAME  => mod_perl
  MP_USE_DSO  => 1
  MP_USE_STATIC   => 1


*** /usr/local/apache/bin/httpd -V
Server version: Apache/2.0.45
Server built:   Apr 30 2003 17:51:58
Server's Module Magic Number: 20020903:0
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/usr/local/apache2/2.0.45"
 -D SUEXEC_BIN="/usr/local/apache2/2.0.45/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"


*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=linux, osvers=2.4.20-8smp, archname=i686-linux
uname='linux redeye-lin-01.pajmc.com 2.4.20-8smp #1 smp thu mar 13
17:45:54 est 2003 i686 i686 i386 gnulinux '
config_args='-d -Dprefix=/usr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O3',
cppflags='-fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)',
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='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.2'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: USE_LARGE_FILES
  Built under linux
  Compiled at Apr 30 2003 17:16:30
  %ENV:
PERL_LWP_USE_HTTP_10="1"
  @INC:
/usr/lib/perl5/5.8.0/i686-linux
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl

3. This is the core dump trace: (if you get a core dump):

 I am not getting an ERROR.  Just a major performance issue.

This report was generated by t/REPORT on Mon Jun  9 20:59:06 2003 GMT.

-8<-- End Bug Report --8<--

Note: Complete the rest of the details and post this bug report to
dev  perl.apache.org. To subscribe to the list send an empty
email to [EMAIL PROTECTED]



Re: getting *any* variables out of the server environment

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 15:35, Geoffrey Young wrote:
> no, I wasn't saying that :)  subprocess_env() from the main request is the 
> right way to go.  I was just trying to let you know that it has nothing to 
> do with %ENV really.

I wouldn't go that far.  %ENV does get populated with that stuff, just
not yet.

> perhaps this is why 
> the eagle book said to get them from a subrequest - presumably the 
> subrequest would have them, since it runs through the fixup phase and SSL 
> stuff is per-connection and not per-request.

Exactly, and as it happens, that chapter is on-line.  The part Ryan was
referring to is here:
http://modperl.com:9000/book/chapters/ch6.html#Using_Digital_Certificates_for_A

Ryan, can you post a more complete code example?

- Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
On Mon, 2003-06-09 at 14:35, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > Geoffrey,
> > 
> > Thanks for the explanation.  Unfortunately, I think I am still a little
> > unclear as to how to proceed.  If I understand you correctly, my first
> > method is completely wrongheaded.  
> 
> :)
> 
> > (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327)  
> 
> don't have my book handy to check that.
> 
> > So it sounds
> > like the second way is the appropriate usage for subprocess_env().  But
> > it seems like you're saying that I shouldn't be using that at all.
> 
> no, I wasn't saying that :)  subprocess_env() from the main request is the 
> right way to go.  I was just trying to let you know that it has nothing to 
> do with %ENV really.
> 
Ok, cool.  Thanks for the clarification ;-)

> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature.  
> 
> ok, those are definitely setup in the subprocess_env table according to the 
> code I just took a look at.  however...
> 
> > According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate.  
> 
> from what I can see, that's not entirely true.  they are set in 
> subprocess_env where they sit and wait, presumably for somebody else to call 
> add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
> 
> the problem you're seeing is that these variables are setup during the fixup 
> phase, so in using a PerlAuthenHandler you're trying to see them too early.
> 
> int ssl_hook_Fixup(request_rec *r)
> {
>  SSLSrvConfigRec *sc = mySrvConfig(r->server);
>  SSLDirConfigRec *dc = myDirConfig(r);
>  table *e = r->subprocess_env;
> ...
>  /*
>   * Annotate the SSI/CGI environment with standard SSL information
>   */
>  /* the always present HTTPS (=HTTP over SSL) flag! */
>  ap_table_set(e, "HTTPS", "on");
>  /* standard SSL environment variables */
>  if (dc->nOptions & SSL_OPT_STDENVVARS) {
>  for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
>  var = (char *)ssl_hook_Fixup_vars[i];
>  val = ssl_var_lookup(r->pool, r->server, r->connection, r, var);
>  if (!strIsEmpty(val))
>  ap_table_set(e, var, val);
>  }
>  }
> 
> in other words, you're SOL from the current request.  perhaps this is why 
> the eagle book said to get them from a subrequest - presumably the 
> subrequest would have them, since it runs through the fixup phase and SSL 
> stuff is per-connection and not per-request.
> 
Yeah, I think that was the motivation.  On the upside of my current
difficulty, I'm getting to learn a lot more about how apache does
things.  

> > Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.  
> > 
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> 
> don't do that.  PerlPassEnv is for passing variables such as those from 
> /etc/profile to the %ENV of the Apache child processes.
> 
Ok, removed.  Thank you very much for the in-depth replies.  It is very
useful.  Unfortunately any variable-reading continues to elude me.  But
I really appreciate all the help!

--Ryan


Re: Mod_perl spawning processes

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 15:34, George Bagley wrote:
> CONFIG  redhat linux 9.0
> apache 2

I'm afraid that's not enough info to guess what you're doing.  Please
read
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems

> I have ugraded from apache1.3 to Apache2 and I am having a performance
> problem with a cgi script.

Do you mean a script running under ModPerl::Registry?  We don't support
actual CGI on this list, just mod_perl.

- Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
>From what I understand, what you outline *should* work.  It just doesn't
for me for some reason.  I really appreciate everyone's help though. 
(And as an aside - I learned how to program in Perl from your books -
many thanks)

--Ryan

On Mon, 2003-06-09 at 14:23, Randal L. Schwartz wrote:
> > "Ryan" == Ryan Muldoon <[EMAIL PROTECTED]> writes:
> 
> Ryan> Geoffrey,
> Ryan> Thanks for the explanation.  Unfortunately, I think I am still a little
> Ryan> unclear as to how to proceed.  If I understand you correctly, my first
> Ryan> method is completely wrongheaded.  (I tried this because it is how the
> Ryan> "Writing Apache Modules with Perl and C" does it. p.327)  So it sounds
> Ryan> like the second way is the appropriate usage for subprocess_env().  But
> Ryan> it seems like you're saying that I shouldn't be using that at all.
> Ryan> Specifically, here is what I'd like to get out of the environment:
> Ryan> SSL_CLIENT_S_DN_CN
> Ryan> SSL_CLIENT_S_DN_O
> Ryan> and things of that nature.  According to mod_ssl's documentation, these
> Ryan> are put in ENV upon processing of a client certificate.  Ideally, I'd
> Ryan> like to make which fields to extract configurable, so I don't want to
> Ryan> hard-code.  
> 
> Well, then, in any handler after the mod_ssl has run, you
> should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
> to get at that info.
> 
> Ryan> Currently, I have
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
> Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
> Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
> Ryan> tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
> Ryan> avail. :(  
> 
> That takes the enviroment variables that apache was started with
> and passes those to mod_perl.  Probably not what you want.
> 
> (I'm doing this from memory, so please correct me if I'm wrong.)


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
I'm trying to do this as a PerlAuthenHandler, so it should be well past
mod_ssl's involvement, but before the fixup stage.  Trying to print out
MOD_PERL either through a subprocess or ENV fails.  So maybe I'm in
bigger trouble than I thought?

--Ryan

On Mon, 2003-06-09 at 14:26, Issac Goldstand wrote:
> Ryan,
>   Ust out of curiosity, at what stage in the request chain are you doing
> this?  If you are doing anything before mod_ssl populates its environment
> variables (which I seem to rembmer being at Fixup, although I may be
> confusing with something else), you wouldn't be able to access them.  You
> *should* still be able to get to other Apache environment variables.
> Try an easy one: test for mod_perl.  If that works, your environment
> variables are OK, and it's likely a mod_ssl problem that you're having.
> 
>   Issac
> 
> - Original Message - 
> From: "Ryan Muldoon" <[EMAIL PROTECTED]>
> To: "Geoffrey Young" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, June 09, 2003 10:13 PM
> Subject: Re: getting *any* variables out of the server environment
> 
> 
> > Geoffrey,
> >
> > Thanks for the explanation.  Unfortunately, I think I am still a little
> > unclear as to how to proceed.  If I understand you correctly, my first
> > method is completely wrongheaded.  (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327)  So it sounds
> > like the second way is the appropriate usage for subprocess_env().  But
> > it seems like you're saying that I shouldn't be using that at all.
> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature.  According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate.  Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> > To make sure it isn't just mod_ssl being lame for some reason, I've
> > tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
> > avail. :(
> >
> > --Ryan
> >
> > On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> > > Ryan Muldoon wrote:
> > > > I'm not able to get *any* variables out from the apache server
> > > > environment.
> > >
> > > ok, first off, this is a two step process for Apache.  the first step is
> > > that modules (like mod_ssl) populate the subprocess_env table with
> various
> > > values.  then, modules like mod_cgi and mod_perl come along and populate
> > > %ENV with the values from subprocess_env as well as various other CGI
> > > specific variables (like DOCUMENT_ROOT or whatever else there is).  the
> > > point is that you're really not after environment variables if you want
> to
> > > test for something like $r->subprocess_env('HTTPS') - that it ends up as
> > > $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> > >
> > > just for your own edification :)
> > >
> > > > As you might be able to imagine, this is extremely
> > > > frustrating, and inhibits my ability to do anything of use with
> > > > mod_perl. My basic technique has been:
> > > > my $uri = $r->uri;
> > > > return unless $r->is_main();
> > > > my $subr = $r->lookup_uri($uri);
> > > > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > >
> > > I don't understand the need for a subrequest to the same URI -
> > > subprocess_env has nothing to do with an actual subprocess.  each
> request
> > > (including subrequests) have their own subprocess_env table attached to
> $r.
> > >   in many cases, modules are coded to behave differently for subrequests
> > > than for the main request, so something you may see in
> $r->subprocess_env()
> > > could not be in $r->lookup_uri($uri)->subprocess_env().
> > >
> > > > But this doesn't work.  I also tried
> > > > my $var = $r->subprocess_env("VARIABLE_NAME");
> > > > And this does not work either.  I really need to be able to use
> > > > environment variables that mod_ssl sets in my authentication handler.
> > >
> > > a few things here too.  for the reasons described above,
> subprocess_env() is
> > > not a substitute for %ENV, so if what you want is a true %ENV value
> (such as
> > > those from PerlPassEnv), you will not be able to get to it via
> > > $r->subprocess_env().
> > >
> > > > Any ideas?  Thanks!
> > >
> > > HTH
> > >
> > > --Geoff
> > >
> > >
> > >
> >
> 


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
I didn't.  But I just set that, and it didn't seem to make a
difference

--Ryan

On Mon, 2003-06-09 at 14:16, Randy Kobes wrote:
> On Mon, 9 Jun 2003, Ryan Muldoon wrote:
> 
> > Geoffrey,
> >
> > Thanks for the explanation.  Unfortunately, I think I am
> > still a little unclear as to how to proceed.  If I understand
> > you correctly, my first method is completely wrongheaded.  (I
> > tried this because it is how the "Writing Apache Modules with
> > Perl and C" does it. p.327)  So it sounds like the second way
> > is the appropriate usage for subprocess_env().  But it seems
> > like you're saying that I shouldn't be using that at all.
> > Specifically, here is what I'd like to get out of the
> > environment: SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O and things of
> > that nature.  According to mod_ssl's documentation, these are
> > put in ENV upon processing of a client certificate.  Ideally,
> > I'd like to make which fields to extract configurable, so I
> > don't want to hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> > To make sure it isn't just mod_ssl being lame for some reason, I've
> > tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
> > avail. :(
> 
> Do you have a
>SSLOptions +StdEnvVars
> directive inside the relevant location of your httpd.conf?


Re: getting *any* variables out of the server environment

2003-06-09 Thread Geoffrey Young


Ryan Muldoon wrote:
Geoffrey,

	Thanks for the explanation.  Unfortunately, I think I am still a little
unclear as to how to proceed.  If I understand you correctly, my first
method is completely wrongheaded.  
:)

(I tried this because it is how the
"Writing Apache Modules with Perl and C" does it. p.327)  
don't have my book handy to check that.

So it sounds
like the second way is the appropriate usage for subprocess_env().  But
it seems like you're saying that I shouldn't be using that at all.
no, I wasn't saying that :)  subprocess_env() from the main request is the 
right way to go.  I was just trying to let you know that it has nothing to 
do with %ENV really.

Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature.  
ok, those are definitely setup in the subprocess_env table according to the 
code I just took a look at.  however...

According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate.  
from what I can see, that's not entirely true.  they are set in 
subprocess_env where they sit and wait, presumably for somebody else to call 
add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).

the problem you're seeing is that these variables are setup during the fixup 
phase, so in using a PerlAuthenHandler you're trying to see them too early.

int ssl_hook_Fixup(request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r->server);
SSLDirConfigRec *dc = myDirConfig(r);
table *e = r->subprocess_env;
...
/*
 * Annotate the SSI/CGI environment with standard SSL information
 */
/* the always present HTTPS (=HTTP over SSL) flag! */
ap_table_set(e, "HTTPS", "on");
/* standard SSL environment variables */
if (dc->nOptions & SSL_OPT_STDENVVARS) {
for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
var = (char *)ssl_hook_Fixup_vars[i];
val = ssl_var_lookup(r->pool, r->server, r->connection, r, var);
if (!strIsEmpty(val))
ap_table_set(e, var, val);
}
}
in other words, you're SOL from the current request.  perhaps this is why 
the eagle book said to get them from a subrequest - presumably the 
subrequest would have them, since it runs through the fixup phase and SSL 
stuff is per-connection and not per-request.

Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.  

Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
don't do that.  PerlPassEnv is for passing variables such as those from 
/etc/profile to the %ENV of the Apache child processes.

--Geoff



Mod_perl spawning processes

2003-06-09 Thread George Bagley
Hi

CONFIG  redhat linux 9.0
  apache 2

I have ugraded from apache1.3 to Apache2 and I am having a performance
problem with a cgi script.

On 1.3, when I do a ps, I cannot see the cgi script running.

On 2, there are hundreds of the cgi scripts running.

The cgi makes a connection to a mysql database.

Is there a configuration option to stop this happening?  



Thanks

George Bagley
Senior Systems Analyst

Red Eye International Ltd
24-28 Nelson's Row
Clapham
London  SW4 7JT

d: 020 7627 9313
t: 020 7627 9300
f: 020 7627 9301
e: [EMAIL PROTECTED] 
n: www.redeye.com

eCRM experts





Re: getting *any* variables out of the server environment

2003-06-09 Thread Randy Kobes
On Mon, 9 Jun 2003, Ryan Muldoon wrote:

> Geoffrey,
>
>   Thanks for the explanation.  Unfortunately, I think I am
> still a little unclear as to how to proceed.  If I understand
> you correctly, my first method is completely wrongheaded.  (I
> tried this because it is how the "Writing Apache Modules with
> Perl and C" does it. p.327)  So it sounds like the second way
> is the appropriate usage for subprocess_env().  But it seems
> like you're saying that I shouldn't be using that at all.
> Specifically, here is what I'd like to get out of the
> environment: SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O and things of
> that nature.  According to mod_ssl's documentation, these are
> put in ENV upon processing of a client certificate.  Ideally,
> I'd like to make which fields to extract configurable, so I
> don't want to hard-code.
>
> Currently, I have
> PerlPassEnv SSL_CLIENT_S_DN_O
> PerlPassEnv SSL_CLIENT_S_DN_CN
> in my httpd.conf, but it doesn't seem to make any kind of difference.
> To make sure it isn't just mod_ssl being lame for some reason, I've
> tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
> avail. :(

Do you have a
   SSLOptions +StdEnvVars
directive inside the relevant location of your httpd.conf?

-- 
best regards,
randy kobes


Re: getting *any* variables out of the server environment

2003-06-09 Thread Issac Goldstand
Ryan,
  Ust out of curiosity, at what stage in the request chain are you doing
this?  If you are doing anything before mod_ssl populates its environment
variables (which I seem to rembmer being at Fixup, although I may be
confusing with something else), you wouldn't be able to access them.  You
*should* still be able to get to other Apache environment variables.
Try an easy one: test for mod_perl.  If that works, your environment
variables are OK, and it's likely a mod_ssl problem that you're having.

  Issac

- Original Message - 
From: "Ryan Muldoon" <[EMAIL PROTECTED]>
To: "Geoffrey Young" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 10:13 PM
Subject: Re: getting *any* variables out of the server environment


> Geoffrey,
>
> Thanks for the explanation.  Unfortunately, I think I am still a little
> unclear as to how to proceed.  If I understand you correctly, my first
> method is completely wrongheaded.  (I tried this because it is how the
> "Writing Apache Modules with Perl and C" does it. p.327)  So it sounds
> like the second way is the appropriate usage for subprocess_env().  But
> it seems like you're saying that I shouldn't be using that at all.
> Specifically, here is what I'd like to get out of the environment:
> SSL_CLIENT_S_DN_CN
> SSL_CLIENT_S_DN_O
> and things of that nature.  According to mod_ssl's documentation, these
> are put in ENV upon processing of a client certificate.  Ideally, I'd
> like to make which fields to extract configurable, so I don't want to
> hard-code.
>
> Currently, I have
> PerlPassEnv SSL_CLIENT_S_DN_O
> PerlPassEnv SSL_CLIENT_S_DN_CN
> in my httpd.conf, but it doesn't seem to make any kind of difference.
> To make sure it isn't just mod_ssl being lame for some reason, I've
> tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
> avail. :(
>
> --Ryan
>
> On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> > Ryan Muldoon wrote:
> > > I'm not able to get *any* variables out from the apache server
> > > environment.
> >
> > ok, first off, this is a two step process for Apache.  the first step is
> > that modules (like mod_ssl) populate the subprocess_env table with
various
> > values.  then, modules like mod_cgi and mod_perl come along and populate
> > %ENV with the values from subprocess_env as well as various other CGI
> > specific variables (like DOCUMENT_ROOT or whatever else there is).  the
> > point is that you're really not after environment variables if you want
to
> > test for something like $r->subprocess_env('HTTPS') - that it ends up as
> > $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> >
> > just for your own edification :)
> >
> > > As you might be able to imagine, this is extremely
> > > frustrating, and inhibits my ability to do anything of use with
> > > mod_perl. My basic technique has been:
> > > my $uri = $r->uri;
> > > return unless $r->is_main();
> > > my $subr = $r->lookup_uri($uri);
> > > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> >
> > I don't understand the need for a subrequest to the same URI -
> > subprocess_env has nothing to do with an actual subprocess.  each
request
> > (including subrequests) have their own subprocess_env table attached to
$r.
> >   in many cases, modules are coded to behave differently for subrequests
> > than for the main request, so something you may see in
$r->subprocess_env()
> > could not be in $r->lookup_uri($uri)->subprocess_env().
> >
> > > But this doesn't work.  I also tried
> > > my $var = $r->subprocess_env("VARIABLE_NAME");
> > > And this does not work either.  I really need to be able to use
> > > environment variables that mod_ssl sets in my authentication handler.
> >
> > a few things here too.  for the reasons described above,
subprocess_env() is
> > not a substitute for %ENV, so if what you want is a true %ENV value
(such as
> > those from PerlPassEnv), you will not be able to get to it via
> > $r->subprocess_env().
> >
> > > Any ideas?  Thanks!
> >
> > HTH
> >
> > --Geoff
> >
> >
> >
>



Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
PerlSetEnv works fine.  I can't, however, put PerlPassEnv inside either
a Location or Directory block, if that makes any difference.  Apache
says it is a configuration error to do so (though PerlSetEnv works
fine).  

I've tried every way that I can think of to do
$r->subprocess_env('VARIABLE'), and it definitely does not work. :(

--Ryan

On Mon, 2003-06-09 at 14:04, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> > I tried that as well (and just re-tried). My understanding is that the
> > %ENV hash only gets updated in the fixup stage, so the mod_ssl
> > environment variables can't be accessed that way.  Thanks for the
> > suggestion though!
> 
> Okay.  And you're certain that a simple $r->subprocess_env('VARIABLE')
> doesn't work?  Have you tried setting a variable yourself as a test with
> PerlSetEnv in httpd.conf?
> 
> - Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Randal L. Schwartz
> "Ryan" == Ryan Muldoon <[EMAIL PROTECTED]> writes:

Ryan> Geoffrey,
Ryan>   Thanks for the explanation.  Unfortunately, I think I am still a little
Ryan> unclear as to how to proceed.  If I understand you correctly, my first
Ryan> method is completely wrongheaded.  (I tried this because it is how the
Ryan> "Writing Apache Modules with Perl and C" does it. p.327)  So it sounds
Ryan> like the second way is the appropriate usage for subprocess_env().  But
Ryan> it seems like you're saying that I shouldn't be using that at all.
Ryan> Specifically, here is what I'd like to get out of the environment:
Ryan> SSL_CLIENT_S_DN_CN
Ryan> SSL_CLIENT_S_DN_O
Ryan> and things of that nature.  According to mod_ssl's documentation, these
Ryan> are put in ENV upon processing of a client certificate.  Ideally, I'd
Ryan> like to make which fields to extract configurable, so I don't want to
Ryan> hard-code.  

Well, then, in any handler after the mod_ssl has run, you
should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
to get at that info.

Ryan> Currently, I have
Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
Ryan> tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
Ryan> avail. :(  

That takes the enviroment variables that apache was started with
and passes those to mod_perl.  Probably not what you want.

(I'm doing this from memory, so please correct me if I'm wrong.)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
Geoffrey,

Thanks for the explanation.  Unfortunately, I think I am still a little
unclear as to how to proceed.  If I understand you correctly, my first
method is completely wrongheaded.  (I tried this because it is how the
"Writing Apache Modules with Perl and C" does it. p.327)  So it sounds
like the second way is the appropriate usage for subprocess_env().  But
it seems like you're saying that I shouldn't be using that at all.
Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature.  According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate.  Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.  

Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables.  But to no
avail. :(  

--Ryan

On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.  
> 
> ok, first off, this is a two step process for Apache.  the first step is 
> that modules (like mod_ssl) populate the subprocess_env table with various 
> values.  then, modules like mod_cgi and mod_perl come along and populate 
> %ENV with the values from subprocess_env as well as various other CGI 
> specific variables (like DOCUMENT_ROOT or whatever else there is).  the 
> point is that you're really not after environment variables if you want to 
> test for something like $r->subprocess_env('HTTPS') - that it ends up as 
> $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> 
> just for your own edification :)
> 
> > As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> 
> I don't understand the need for a subrequest to the same URI - 
> subprocess_env has nothing to do with an actual subprocess.  each request 
> (including subrequests) have their own subprocess_env table attached to $r. 
>   in many cases, modules are coded to behave differently for subrequests 
> than for the main request, so something you may see in $r->subprocess_env() 
> could not be in $r->lookup_uri($uri)->subprocess_env().
> 
> > But this doesn't work.  I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either.  I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler. 
> 
> a few things here too.  for the reasons described above, subprocess_env() is 
> not a substitute for %ENV, so if what you want is a true %ENV value (such as 
> those from PerlPassEnv), you will not be able to get to it via 
> $r->subprocess_env().
> 
> > Any ideas?  Thanks!
> 
> HTH
> 
> --Geoff
> 
> 
> 


Re: getting *any* variables out of the server environment

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> I tried that as well (and just re-tried). My understanding is that the
> %ENV hash only gets updated in the fixup stage, so the mod_ssl
> environment variables can't be accessed that way.  Thanks for the
> suggestion though!

Okay.  And you're certain that a simple $r->subprocess_env('VARIABLE')
doesn't work?  Have you tried setting a variable yourself as a test with
PerlSetEnv in httpd.conf?

- Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Geoffrey Young


Ryan Muldoon wrote:
I'm not able to get *any* variables out from the apache server
environment.  
ok, first off, this is a two step process for Apache.  the first step is 
that modules (like mod_ssl) populate the subprocess_env table with various 
values.  then, modules like mod_cgi and mod_perl come along and populate 
%ENV with the values from subprocess_env as well as various other CGI 
specific variables (like DOCUMENT_ROOT or whatever else there is).  the 
point is that you're really not after environment variables if you want to 
test for something like $r->subprocess_env('HTTPS') - that it ends up as 
$ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.

just for your own edification :)

As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r->is_main();
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
I don't understand the need for a subrequest to the same URI - 
subprocess_env has nothing to do with an actual subprocess.  each request 
(including subrequests) have their own subprocess_env table attached to $r. 
 in many cases, modules are coded to behave differently for subrequests 
than for the main request, so something you may see in $r->subprocess_env() 
could not be in $r->lookup_uri($uri)->subprocess_env().

But this doesn't work.  I also tried
	my $var = $r->subprocess_env("VARIABLE_NAME");
And this does not work either.  I really need to be able to use
environment variables that mod_ssl sets in my authentication handler. 
a few things here too.  for the reasons described above, subprocess_env() is 
not a substitute for %ENV, so if what you want is a true %ENV value (such as 
those from PerlPassEnv), you will not be able to get to it via 
$r->subprocess_env().

Any ideas?  Thanks!
HTH

--Geoff





RE: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
I'm using mod_perl 1.  But I'm setting the handlers in httpd.conf.  I
sent a message to the list on thursday ("problem with pulling variables
from mod_ssl") that more fully describes my situtation.

--Ryan

On Mon, 2003-06-09 at 14:31, Marc M. Adkins wrote:
> IF you're using mp2...in your httpd.conf are you setting up the handlers
> with modperl or perl-script?  The former doesn't provide any environment
> variables:
> 
>   http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
> 
> I don't believe this applies to mp1.
> 
> mma
> 
> > -Original Message-
> > From: Ryan Muldoon [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 09, 2003 11:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: getting *any* variables out of the server environment
> >
> >
> > I'm not able to get *any* variables out from the apache server
> > environment.  As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > But this doesn't work.  I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either.  I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler.
> > Any ideas?  Thanks!
> >
> > --Ryan
> >
> 


RE: getting *any* variables out of the server environment

2003-06-09 Thread Marc M. Adkins
IF you're using mp2...in your httpd.conf are you setting up the handlers
with modperl or perl-script?  The former doesn't provide any environment
variables:

http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_

I don't believe this applies to mp1.

mma

> -Original Message-
> From: Ryan Muldoon [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 09, 2003 11:30 AM
> To: [EMAIL PROTECTED]
> Subject: getting *any* variables out of the server environment
>
>
> I'm not able to get *any* variables out from the apache server
> environment.  As you might be able to imagine, this is extremely
> frustrating, and inhibits my ability to do anything of use with
> mod_perl. My basic technique has been:
>   my $uri = $r->uri;
>   return unless $r->is_main();
>   my $subr = $r->lookup_uri($uri);
>   my $apachecertcomp = $subr->subprocess_env($certcomponent);
> But this doesn't work.  I also tried
>   my $var = $r->subprocess_env("VARIABLE_NAME");
> And this does not work either.  I really need to be able to use
> environment variables that mod_ssl sets in my authentication handler.
> Any ideas?  Thanks!
>
>   --Ryan
>



Re: getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way.  Thanks for the
suggestion though!

--Ryan

On Mon, 2003-06-09 at 13:41, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.
> 
> Did you try the normal $ENV{'VARIABLE'} approach?
> 
> - Perrin


Re: getting *any* variables out of the server environment

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> I'm not able to get *any* variables out from the apache server
> environment.

Did you try the normal $ENV{'VARIABLE'} approach?

- Perrin


getting *any* variables out of the server environment

2003-06-09 Thread Ryan Muldoon
I'm not able to get *any* variables out from the apache server
environment.  As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r->is_main();
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
But this doesn't work.  I also tried
my $var = $r->subprocess_env("VARIABLE_NAME");
And this does not work either.  I really need to be able to use
environment variables that mod_ssl sets in my authentication handler. 
Any ideas?  Thanks!

--Ryan


Re: modules that work with both modperl1 and 2

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
> Yeah, I've been messing with that, but it seems to me that I need 
> something similar to a preprocessor directive, where I can load the 
> appropriate "use MODULE" lines into the module bases upon which version 
> of modperl they have installed.  Is it possible to use the BEGIN {} 
> subroutine as this?

You don't need a preprocessor.  You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.

For example:

if ($mod_perl::VERSION >= 1.99) {
  require Apache2::Module;
  import Apache2::Module;
} else {
  require Apache1::Module;
  import Apache1::Module;
}

You can put that whole construct in a BEGIN block if you want to.  That
will make it run before the rest of the code in the current package.

- Perrin


Re: modules that work with both modperl1 and 2

2003-06-09 Thread Shannon Eric Peevey
Perrin Harkins wrote:

On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
 

PS Am having problems with the compile time loading of modules depending 
on the existence of either modperl1 or 2...  "use" dies and "require" is 
not importing the symbols correctly at runtime...
   

If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:
BEGIN { require Module; import Module LIST; }

If you want to import things correctly when using require, you have to
call import yourself.
- Perrin
 

Yeah, I've been messing with that, but it seems to me that I need 
something similar to a preprocessor directive, where I can load the 
appropriate "use MODULE" lines into the module bases upon which version 
of modperl they have installed.  Is it possible to use the BEGIN {} 
subroutine as this?

speeves
cws



Re: Compling mod_perl as a static module....

2003-06-09 Thread Forrest Aldrich
Ged,

This is what the make output shows... I've read the docs.  Perhaps I need 
to try compiling mod_perl with a different method (I recall a build option 
with apxs, outside of the apache src tree).

o perl_module uses ConfigStart/End
  + mod_perl build type: DSO
  + setting up mod_perl build environment
  + id: mod_perl/1.27
  + id: Perl/v5.8.0 (freebsd) [/usr/local/bin/perl]
Here are the makepl flags I have thus far:

USE_DSO=0
DYNAMIC=0
USE_APACI=1
APACHE_PREFIX=/usr/local/apache
APACHE_SRC=../apache_1.3.27/src
DO_HTTPD=1
EVERYTHING=1
ALL_HOOKS=1
PERL_SSI=1
PERL_SECTIONS=1
APACI_ARGS=--with-perl=/usr/local/bin/perl
APACI_ARGS=--enable-module=rewrite
APACI_ARGS=--enable-module=include
APACI_ARGS=--enable-module=info
APACI_ARGS=--enable-module=usertrack
APACI_ARGS=--server-gid=nogroup
APACI_ARGS=--suexec-docroot=/usr/local/apache/htdocs
APACI_ARGS=--enable-module=most
APACI_ARGS=--enable-module=auth_db
APACI_ARGS=--enable-module=mmap_static
APACI_ARGS=--enable-shared=max
APACI_ARGS=--enable-module=ssl
APACI_ARGS=--enable-rule=SHARED_CORE
APACI_ARGS=--activate-module=src/modules/dosevasive/libdosevasive.a



Re: modules that work with both modperl1 and 2

2003-06-09 Thread Perrin Harkins
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
> PS Am having problems with the compile time loading of modules depending 
> on the existence of either modperl1 or 2...  "use" dies and "require" is 
> not importing the symbols correctly at runtime...

If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:

BEGIN { require Module; import Module LIST; }

If you want to import things correctly when using require, you have to
call import yourself.

- Perrin


modules that work with both modperl1 and 2

2003-06-09 Thread Shannon Eric Peevey
Hi!

Just wondering if anyone knows of a perl module that is coded to work 
with modperl1 and 2?  I am hitting a wall in getting my module to do 
that, and want to cheat a little off of someone who already has... ;)

thanks,
speeves
cws
PS Am having problems with the compile time loading of modules depending 
on the existence of either modperl1 or 2...  "use" dies and "require" is 
not importing the symbols correctly at runtime...  My bad for not 
completely understanding how to use "require".  (Am trying to work this 
out as we speak.)  Thanks again!



Re: PERL/java interface available?

2003-06-09 Thread Mark Hawkes
At 07:34 2003-06-09 -0600, you wrote:
Would anyone happen to know if there is a PERL/java interface where these 
two languages could talk to each other?
Java can call any native function that's packaged in a dso or dll. (But is 
it possible to compile Perl modules to standalone dso?) Did anyone mention 
B::JVM::Jasmin or JPL? See links below...

-Mark

-
Porting Perl to the Java Virtual Machine
http://www.ebb.org/bkuhn/writings/technical/thesis
More about JPL
http://www.oreilly.com/catalog/prkunix/info/more_jpl.html
Java Native Interface Tutorial
http://java.sun.com/docs/books/tutorial/native1.1/


Re: PERL/java interface available?

2003-06-09 Thread wsheldah

I believe there's a Java.pm module on CPAN that will allow a perl program
to instantiate java objects and call methods on them. That may or may not
be enough intercommunication for what you need.

Wes Sheldahl



"Charlie Smith" <[EMAIL PROTECTED]> on 06/09/2003 09:34:04 AM

To:[EMAIL PROTECTED]
cc:
Subject:PERL/java interface available?


Would anyone happen to know if there is a PERL/java interface where these
two languages could talk to each other?

Charlie


--

This message may contain confidential information, and is intended only for
the use of the individual(s) to whom it is addressed.


==









Re: PERL/java interface available?

2003-06-09 Thread Beau E. Cox

- Original Message - 
From: "Charlie Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 3:34 AM
Subject: PERL/java interface available?


Would anyone happen to know if there is a PERL/java interface where these
two languages could talk to each other?

Charlie

Hi Charlie:

Check out the 'Inline' modules on CPAN:

http://search.cpan.org/author/INGY/Inline-0.44/Inline.pod

You also may want to look at SWIG at:

http://www.swig.org/

I have used Inline::C and SWIG for c and c++, but not for
java; but they say they work...

Aloha => Beau;

PS: The 'Inline' modules are neat because your code is just
that - inline; it's easier to see what's going on.




Re: Compling mod_perl as a static module....

2003-06-09 Thread Forrest Aldrich
At 03:26 AM 6/9/2003, Ged Haywood wrote:
Hi there,

On Sun, 8 Jun 2003, Forrest Aldrich wrote:

> I want to try compiling mod_perl statically

What's the question?

73,
Ged.
[ ... ]

Referring back to my original post, it with the options I specified, the 
compile process still insists on compiling mod_perl as a DSO.   Even if I 
explicitly set USE_DSO=0 -- I wonder if one of the other flags (like 
EVERYTHING=1) is triggering the DSO compile.   This seems to be very tricky.

_F




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

2003-06-09 Thread Haroon Rafique
On Saturday at 9:22am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote:

SB> I think the issue is very simple: @INC had system libraries dirs
SB> before the freshly build ones, so dumping @INC contents prior to libs
SB> loading should aid the debug. But please use the latest cvs, since
SB> I've messed with @INC a bit recently.
SB> 
SB> In parallel, we are planning to verify .so objects that they were
SB> created by the same mod_perl.so to avoid completely this kind of
SB> problems. Well it won't prevent the pickup of wrong libraries, it'll
SB> just scream aloud when this will happen. So your debug is still very
SB> important.
SB> 

Seeing that you were answering emails even on a Saturday, I feel guilty
about taking that out of town trip yesterday. Oh well! I think we should
be able to enjoy the little bit of summer that we get here in Canada to
the fullest.

Now onto serious stuff. /usr/bin/perl here is the system-wide perl install
that came bundled with Redhat.

/usr/bin/perl -MApache2 -Mmod_perl -le 'print mod_perl->VERSION'
1.9908

I posted t/REPORT output in the beginning of the thread and can
repost upon request.

I did a cvs up, and issued:

* /usr/bin/perl Makefile.PL MP_AP_PREFIX=/servers/httpd-2.0.44-pl 
* make
* make test

and was greeted by the now familiar output (same as originally reported)

/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -clean
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -clean
sh: line 1: ulimit: core file size: cannot modify limit: Operation not 
permitted
APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -verbose=0 
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -verbose=0
sh: line 1: ulimit: core file size: cannot modify limit: Operation not 
permitted
/servers/httpd-2.0.44-pl/bin/httpd  -d 
/home/haroon/src/build/modperl-2.0/t -f 
/home/haroon/src/build/modperl-2.0/t/conf/httpd.conf -DAPACHE2 
-DPERL_USEITHREADS
using Apache/2.0.44 (prefork MPM)

waiting for server to start: ..[Mon Jun 09 09:38:20 2003] [info] 22 
Apache:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] 5 APR:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] base server + 9 vhosts ready to run 
tests
[Mon Jun 09 09:38:20 2003] [error] Invalid CODE attribute: 
TestFilter::in_init_basic at 
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm 
line 30
BEGIN failed--compilation aborted at 
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm 
line 30.
Compilation failed in require at (eval 35) line 3.

[Mon Jun 09 09:38:20 2003] [error] Can't load Perl module 
TestFilter::in_init_basic for server localhost.localdomain:8529, 
exiting...

!!! 
server has died with status 255 (t/logs/error_log wasn't created, start 
the server in the debug mode)
make: *** [run_tests] Error 143

Thanks,
--
Haroon Rafique
<[EMAIL PROTECTED]>



Re: is anybody using mp2 in production?

2003-06-09 Thread Beau E. Cox

- Original Message - 
From: "Chris Faust" <[EMAIL PROTECTED]>
To: "Sreeji K Das" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 3:20 AM
Subject: Re: is anybody using mp2 in production?


> > (Btw, Chris, are you using the worker mpm ? Is it
> > stable ? We'd like to go the worker mpm way & would
> > like to know if any1 is using it yet in production.)
> >
>
> On our dev server yes, and all seems well - but we haven't rolled it out
in
> production yet. Its one of those things we want to do but keep getting
side
> tracked with something else.
> Sooner then later we will be giving it a shot though.
>
> I'd be interested in what you thought of the switch after going live, we
> were never sure (but getting there now) if we should have started with MP2
> or not, never got a chance to see MP1 in action.
>
> -Chris
>
Hi -

My low-volume personal site has been on Apache2-mp2-mason
since October 2002 - no problems (other than the ones I
caused).

In April I put one of my clients up with the same setup; another
in May. (I pried both away from M$ IIS!) Although both
are small company low-volume sites, they seem to be running
without problems - knock on wood.

All sites mentioned above are running SuSE 8.2 Linux.

Aloha => Beau;

By the way, have you ever tried to explain the idom
"knock on wood" to someone for whom English is not
their first language? I have been trying to explain it to my
wife - from Japan - for ten years now without success :)




PERL/java interface available?

2003-06-09 Thread Charlie Smith
Would anyone happen to know if there is a PERL/java interface where these two 
languages could talk to each other?

Charlie


--
This message may contain confidential information, and is intended only for the use of 
the individual(s) to whom it is addressed.


==



Re: is anybody using mp2 in production?

2003-06-09 Thread Chris Faust
> (Btw, Chris, are you using the worker mpm ? Is it
> stable ? We'd like to go the worker mpm way & would
> like to know if any1 is using it yet in production.)
>

On our dev server yes, and all seems well - but we haven't rolled it out in
production yet. Its one of those things we want to do but keep getting side
tracked with something else.
Sooner then later we will be giving it a shot though.

I'd be interested in what you thought of the switch after going live, we
were never sure (but getting there now) if we should have started with MP2
or not, never got a chance to see MP1 in action.

-Chris





Re: Fw: [OT] [Perl] HTML::Mason help anyone?

2003-06-09 Thread Issac Goldstand
Ged Haywood wrote:
[snip]
>>>I have a simple form
[snip]
>>>The problem is that I only see the values printed when I use the "GET"
>>>option in the form above, when I change "GET" to "POST" nothing gets
>>>printed...
>>POST data can only be read once, if you want to read it again you have
>>to save it somewhere.  It looks to me like before you try to read it,
>>it's being read by something else and therefore lost to you.

>>This question seems to crop up quite a lot (if this is the right answer:)

>Off topic for the perl list but since you all saw the question...
>The problem was related to the form's enctype specifier, I saw an error
message in the apache log
>
>" [libapreq] unknown content-type: `text/plain'"
>
>Now I'm not really sure where the variables disappeared to (an explanation
would be kind) but as soon >as I removed this specifier the data started
showing up right in the handler even when using >"POST"..
>anyone care to explain this please?

Hmm... That looks like the form is not being submitted properly.  When you
submit a form, it can encode it in a number of ways.  The most popular
standard way is to use application/x-www-form-urlencoded (which means that
the POST content is formatted to look like a query string:
param=some+value&otherparam=anotherval) or, if there's an upload,
mutlipart/form-data (which makes the POST data resemble a MIME email with
boundaries).  If you specify another type, then libapreq might chocke on it,
not knowing how to interpret the data it recieves.  Does that help a bit?

  Issac



Re: Fw: [Perl] HTML::Mason help anyone?

2003-06-09 Thread Ged Haywood
Hi there,

On Mon, 9 Jun 2003, Issac Goldstand wrote:

> Forwarded from the Israeli Perl Mongers mailing list:
> 
> - Original Message - 
> From: "Ron" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 09, 2003 1:48 PM
> Subject: [Perl] HTML::Mason help anyone?
> 
> 
> > I have a simple form
[snip]
> > The problem is that I only see the values printed when I use the "GET" 
> > option in the form above, when I change "GET" to "POST" nothing gets 
> > printed... 

POST data can only be read once, if you want to read it again you have
to save it somewhere.  It looks to me like before you try to read it,
it's being read by something else and therefore lost to you.

This question seems to crop up quite a lot (if this is the right answer:)

73,
Ged.



Fw: [Perl] HTML::Mason help anyone?

2003-06-09 Thread Issac Goldstand
Forwarded from the Israeli Perl Mongers mailing list:

- Original Message - 
From: "Ron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 1:48 PM
Subject: [Perl] HTML::Mason help anyone?


> I have a simple form that looks like so:
> 
>  enctype="text/plain">
>
>
> 
> 
> all HTML files are  processed by Mason using the  directive 
> in httpd.conf
> 
> and my simple handler object simply does:
> 
> % foreach (sort %ARGS) {
><% $_ %>
> % }
> 
> The problem is that I only see the values printed when I use the "GET" 
> option in the form above, when I change "GET" to "POST" nothing gets 
> printed... what am I doing wrong? it seams to me that Mason is not 
> seeing any posted data...
> 
> Thanks
> Ron.
> 
> ___
> Perl mailing list
> [EMAIL PROTECTED]
> http://www.perl.org.il/mailman/listinfo/perl
> 


Re: Compling mod_perl as a static module....

2003-06-09 Thread Ged Haywood
Hi there,

On Sun, 8 Jun 2003, Forrest Aldrich wrote:

> I want to try compiling mod_perl statically

What's the question?

73,
Ged.