tests failing when installing libapreq under Leopard

[Brian]

Hi All. I've googled tons and searched the list and can't seem to find an
answer to my problem.
I am trying to install libapreq 1.33 on OS X Leopard. I have successfully
compiled and installed Apache 1.3 with mod_perl 1.3 statically linked. That
seems to work fine. I can start apache and the log file shows mod_perl to be
installed and everything seems ok at that point.

Next I tried to install Apache::Request by
downloading libapreq-1.33.tar.gz from CPAN but 'make test' is resulting in
errors. 100% of the tests are failing. I should note that I did execute
"export ARCHFLAGS=-arch x86_64" prior to building all packages as suggested
in the past. Here is what i believe to be the relevant error message from
the test script:

[Wed Oct 22 12:08:51 2008] [notice] Apache/1.3.41 (Darwin) mod_perl/1.30
configured -- resuming normal operations
[Wed Oct 22 12:08:51 2008] [info] Server built: Oct 22 2008 11:19:51
[Wed Oct 22 12:08:51 2008] [notice] Accept mutex: flock (Default: flock)
[Wed Oct 22 12:08:53 2008] [error] Can't load
'/usr/local/src/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.bundle'
for module Apache::Cookie:
dlopen(/usr/local/src/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.bundle,
1): Symbol not found: _ap_null_cleanup\n  Referenced from:
/usr/local/src/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.bundle\n
 Expected in: dynamic lookup\n at
/Library/Perl/5.8.8/darwin-thread-multi-2level/mod_perl.pm line
14\nCompilation failed in require at
/usr/local/src/libapreq-1.33/t/response/TestApReq/big_input.pm line
9.\nBEGIN failed--compilation aborted at
/usr/local/src/libapreq-1.33/t/response/TestApReq/big_input.pm line
9.\nCompilation failed in require at (eval 10) line 3.\n

Unfortunately this error message is a little outside of my understanding.

Here is a copy/paste of my console during the whole installation process:


bartobrians-macbook-pro:src brian$ cd libapreq-1.33
bartobrians-macbook-pro:libapreq-1.33 brian$ perl Makefile.PL -apxs
/usr/local/httpd/sbin/apxs -httpd /usr/local/httpd/sbin/httpd
[   info] generating script t/TEST
Checking if your kit is complete...
Looks good
Writing Makefile for libapreq
mkdir ../blib
mkdir ../blib/arch
mkdir ../blib/arch/auto
mkdir ../blib/arch/auto/libapreq
Writing Makefile for Apache::Request
Writing Makefile for Apache::Cookie
Writing Makefile for libapreq
bartobrians-macbook-pro:libapreq-1.33 brian$ make
cp lib/Apache/libapreq.pm blib/lib/Apache/libapreq.pm
cp libapreq.pod blib/lib/libapreq.pod
cc -c  -I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/modules/perl
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/regex
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/os/unix
-arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -Wdeclaration-after-statement -I/usr/local/include -O3
  -DVERSION=\"\" -DXS_VERSION=\"\"
 "-I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE"
apache_request.c
cc -c  -I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/modules/perl
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/regex
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/os/unix
-arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -Wdeclaration-after-statement -I/usr/local/include -O3
  -DVERSION=\"\" -DXS_VERSION=\"\"
 "-I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE"
apache_cookie.c
cc -c  -I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/modules/perl
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/include
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/regex
-I/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Apache/include/os/unix
-arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -Wdeclaration-after-statement -I/usr/local/include -O3
  -DVERSION=\"\" -DXS_VERSION=\"\"
 "-I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE"
apache_multipart_buffer.c
rm -rf ../blib/arch/auto/libapreq/libapreq.a
/usr/bin/ar cr ../blib/arch/auto/libapreq/libapreq.a apache_request.o
apache_cookie.o apache_multipart_buffer.o && /usr/bin/ar ts
../blib/arch/auto/libapreq/libapreq.a
__.SYMDEF SORTED
apache_request.o
apache_cookie.o
apache_multipart_buffer.o
chmod 755 ../blib/arch/auto/libapreq/libapreq.a
cp apache_multipart_buffer.h
../blib/arch/auto/libapreq/include/apache_

Re: combining multiple filtered files into a single response

[Brian]

On 11/18/10 6:53 PM, André Warnier wrote:

I'd also like to avoid the last resort which would be to run a long process to
process each file, save them to a temporary directory, and then re-read them

>

Why is that "the last resort" ?
It seems to me to be the logical way of achieving what you want.
Anyway, when the user is posting the three files (as 3 "file" boxes in a form),
this is sent by the browser as one long stream


Sorry, maybe I wasn't clear: the client isn't sending the files, they are being 
read on the server locally and served to the client in a single output stream. 
The client is simply providing the FILENAMES in the request; the server has to 
do all the work, and already has all the data.


My point there was to say that if the client says "send file1+file2+file3" then 
I want the server to be able to start outputting the data for file1 immediately 
before file2 has even been read from disk.  But in addition it needs to pass 
through an output filter, and each will pass through that same filter, but the 
filter needs to know when it hits an EOF (as opposed to an EOS).


I thought a simple solution would be that in a sub-request, the filter only 
processes one file so it's one stream, but then I have to combine sub-requests 
at the top level and I don't know how to do that.  But ideally I want something 
like this:


 for my $file (@requested_files) {
my $header = generate_header($file);
my $footer = generate_footer($file);
$r->write($header);
my $subr = $r->lookup_uri("/fetch?name=$file", $myfilter);
$r->write(...output of $subr...?);
$r->write($footer);
 }

It's a little more complicated than that, but hopefully you get the idea...


Brian

Re: combining multiple filtered files into a single response

[Brian]

On 11/19/10 11:58 AM, Ryan Gies wrote:

One is to iterate over the filenames with subrequests (if this is even
possible/supported), so that each can be passed internally to a single request

Although you could get them to work, I don't think sub-requests are your answer.
They run through all of the handler phases and are expected to return full HTTP
responses.


I think that's right. I gave up on that idea after an exchange with André.


If that doesn't work then I can imagine iterating over the files with calls to
"sendfile()" and using a modified filter to guess at file boundaries.

Because your out-of-band signal may be split across buckets, the output-filter
approach is probably not your answer either. Once again it can be done, however
introduces [seemingly] unneeded complexity. I would say the same for tracking
boundaries according to their offset.


Well there are lots of cases where you have to worry about data being split 
across buckets (or even brigades) in an output filter, but there are known 
solutions for this by maintaining context.  The reason I don't trust custom 
in-band signals is because the filter is handling binary data so I can't predict 
what will pass through reliably.  Tracking by offset is more promising, even 
though like you say there's complexity and openings for error.



Unless there is some constraint, the most straight-forward approach may be to
implement your routine to modify the file contents as they are read from disk:


Yeah, André came up with the same idea, but I'm hoping to avoid that for the 
same reason that I gave up on the idea of subrequests: efficiency (and re-use). 
I already have a filter that does what I want and operates on bucket brigades; 
it's designed for binary files and in most cases only needs to read the first 
few kilobytes of multi-megabyte files before deciding that it can pass on the 
rest untouched.  For efficiency it's much better to skip the calls to read() and 
have the data read only only when it's written to the client, rather than 
multiple times and into memory by the response handler.


So the only way I think to maintain this efficiency for multiple files in a 
single stream would be to have their filehandles going in succession into bucket 
brigades and having the filter track the boundaries by offsets.  I know I can't 
rely on brigade boundaries or flush buckets because single files can be spread 
over multiple brigades, and I'm not confident that I can control where flush 
buckets appear unless I insert a filter directly before to strip them out except 
at the boundaries (does anyone know whether flush buckets are predictable?). 
It's a bit messy and I'm still hoping someone here may offer a cleaner 
mechanism, but if not then I'll try that.


Thanks,

Brian

Re: introducing new code with no perceived user delays?

[Brian Hirt]

The way i do this is having a lightweight apache proxy on port 80.   My 
mod perl application listens on a different port and receives requests 
from the proxy.  When i need to roll out new code, i start up a 2nd mod 
perl application on a 3rd port, update the rules for the proxy to go to 
the new code and reload the rules.  Once everything is running on the 
new mod perl, i shut down the original mod perl application.  There is 
about 0.5 seconds of lag while the proxy reloads the rules. Rolling 
out a new release in the fashion is a simple process that can be coded 
into a very simple shell script and executed with a single command.

There are also other reasons to have a proxy -> mod perl set up which i 
wont go into right now.

--brian

On Dec 17, 2003, at 5:08 PM, justin wrote:

One registry module checks for a new file before a request starts.
Another Registry class does no checking at all. Apache::Reload checks a
file on disk before the request, or ALL module timestamps. None of 
these
solutions are satisfactory. If code is rolled out, 10+ modperl 
processes
all reloading it at the same time will halt forward motion for 30
seconds or more (depends on code size, init time, and so on).

Is it possible to design something that checks in the EXIT phase, and
not every request, just randomly, say, every N times, so all servers
don't freeze up .. if they find a named 're-cycle' file is newer than
their own life-span, then they child_exit ? Ideally, they eval or 
syntax
check the new module(s), before deciding to child_exit.

If they find they do not eval without error, they erase the re-cycle
command file and try not to exit until an admin realizes their mistake
;)
would such a module be a logical plug-in replacement for the Registry
handler, a sub-class, or something else? I'd like to write it, but am
interested to know if I'm barking up the wrong tree.
thanks -Justin

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

directive says no perl handler specified

[Brian Bober]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25175

Running Redhat 9, Apache 2.0.40

This directive is within a virtual host section. I also installed
bundle::openinteract


use lib qw( /var/www/html/thenetdragon/www );


OpenInteract needs this to function properly.

(/etc/httpd/conf.d)> service httpd restart
Stopping httpd:[FAILED]
Starting httpd: Syntax error on line 1087 of /etc/httpd/conf/httpd.conf:
no  handler specified


I tried installing Bundle::Apache through Cpan to solve the problem, but it
wouldn't finish installing... I got errors.



__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: directive says no perl handler specified

[Brian Bober]

Thanks for the help.

I painstakingly built new RPMs and got Apache to 2.0.48-1 and fixed all
dependencies and updated mod perl to 1.99_11, and SO FAR everything with the
 directive seems to be fine. I might have made a bit of a mess of my RPM
dependencies and I can only pray no problems happen in the future. :-)

--- Stas Bekman <[EMAIL PROTECTED]> wrote:
> Brian Bober wrote:
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25175
> > 
> > Running Redhat 9, Apache 2.0.40
> 
> See http://perl.apache.org/bugs/
> 
> > This directive is within a virtual host section. I also installed
> > bundle::openinteract
> > 
> > 
> > use lib qw( /var/www/html/thenetdragon/www );
> > 
> > 
> > OpenInteract needs this to function properly.
> > 
> > (/etc/httpd/conf.d)> service httpd restart
> > Stopping httpd:[FAILED]
> > Starting httpd: Syntax error on line 1087 of /etc/httpd/conf/httpd.conf:
> > no  handler specified
> > 
> > 
> > I tried installing Bundle::Apache through Cpan to solve the problem, but it
> > wouldn't finish installing... I got errors.
> 
> You need to install the latest modperl, 1.99_11 (1.99_12 will be released on 
> Monday).
> 
> 
> 
> __
> 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
> 



--- Chris Winters <[EMAIL PROTECTED]> wrote:
> >> This directive is within a virtual host section. I also installed
> >> bundle::openinteract
> >> 
> >> use lib qw( /var/www/html/thenetdragon/www );
> >> 
> >> OpenInteract needs this to function properly.
> >> (/etc/httpd/conf.d)> service httpd restart
> 
> FWIW, OpenInteract doesn't work with Apache2/mod_perl2, and AFAIK it 
> probably won't. OpenInteract2 (now in beta) will work with mod_perl 
> versions 1, 2 and other environments as well.
> 
> Chris
> 
> --
> Chris Winters
> Creating enterprise-capable snack systems since 1988
> 
> 
> -- 
> Reporting bugs: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> 


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

AuthCookieDBI configuration woes

[Brian Clarkson]

I've done a search through the archives, and the only related question I
could find didn't include any conf. information.
'
I thought I had my httpd.conf configured correctly for
Apache::AuthCookieDBI.  the same ( well, close to the same ) setup
worked for Apache::AuthCookie 
the error message:

[Thu Mar 11 09:52:39 2004] [crit] [client 24.153.205.228] configuration
error:  couldn't check user.  No user file?: /LOGIN
i've tried the following configuration in the main httpd.conf *and* in
the  section.  from reading the archives, the config will
only work in the main server section, even though with my current setup,
I'd *really* prefer it to work in the  section.
the relevant config:

PerlSetVar JBGDBI_SecretKeyFile /home/httpd/secure.jbgoodwin.com/keyfile

PerlModule Apache::AuthCookieDBI
PerlSetVar JBGPath /
PerlSetVar JBGLoginScript /login.pl
### database infos
PerlSetVar JBGDBI_DSN "DBI:mysql:database=**"
PerlSetVar JBGDBI_User "**"
PerlSetVar JBGDBI_Password ""
PerlSetVar JBGDBI_UsersTable "agent"
PerlSetVar JBGDBI_UserField "username"
PerlSetVar JBGDBI_PasswordField "password"

 
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options +ExecCGI
  allow from all
  PerlSendHeader On
 

# These documents require user to be logged in.

AuthType Apache::AuthCookieDBI
AuthName JBG
PerlAuthenHandler Apache::AuthCookieDBI->authenticate
PerlAuthzHandler Apache::AuthCookieDBI->authorize
require valid-user

# 

##this is the action of the login.pl script above.

AuthType Apache::AuthCookieDBI
AuthName JBG
SetHandler perl-script
PerlHandler Apache::AuthCookieDBI->login

-- i've checked that keyfile is 400 ( root read only, per the docs )
-- login.pl has executable permissions ( 755 )
i've tried looking for the error message in the actual code of
Apache::AuthCookieDBI, but i can't find it anywhere.  what am i doing wrong?
brian



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::AuthCookie LOGIN action, where / is protected

[Brian Clarkson]

Nick Phillips wrote:

On 13/03/2004, at 11:08 AM, Elizabeth Cortell wrote:

I have a question for experienced Apache::AuthCookie users.  The 
module's test suite protects directories below the docroot and sets 
the action of the login form to /LOGIN, an unprotected location.  This 
setup  does not work for me as I need to protect the entire docroot. 
Since LOGIN itself is protected, the login method is never called and 
I never progress past the login screen.

Could someone suggest a configuration that would permit LOGIN to 
invoke Apache::AuthCookie->login correctly but still protect the 
entire docroot?


Are you currently using  or  tags to configure 
protection for the main body
of your content?
I'm having the same problem.

I'm using this as the  and  directives as follows:


  AuthType TestCookie::AuthCookieHandler
  AuthName TestCookie
  PerlAuthenHandler TestCookie::AuthCookieHandler->authenticate
  PerlAuthzHandler TestCookie::AuthCookieHandler->authorize
  Require user programer
  Options +ExecCGI
  allow from all


  AuthType  TestCookie::AuthCookieHandler
  AuthName TestCookie
  SetHandler perl-script
  PerlHandler TestCookie::AuthCookieHandler->login

and all of this is within a  container.

( I never saw a response to the list, and I'm abandoning my use of 
Apache::AuthCookieDBI because I can't get it configured correctly.  I 
did post to the list for assistance, but no responses ... )

--brian

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::AuthCookie LOGIN action, where / is protected

[Brian Clarkson]

Rafael Caceres wrote:


You need to make some changes to your conf:


Use , otherwise you are only protecting the "/" URL.

that does seem to fix the issue there.

#
  AuthType TestCookie::AuthCookieHandler
  AuthName TestCookie
  PerlAuthenHandler TestCookie::AuthCookieHandler->authenticate
  PerlAuthzHandler TestCookie::AuthCookieHandler->authorize
  Require user programer
  Options +ExecCGI
  allow from all
#


( I never saw a response to the list, and I'm abandoning my use of 
Apache::AuthCookieDBI because I can't get it configured correctly.  I 
did post to the list for assistance, but no responses ... )
That would be too bad, it's a very nice solution.
if you have any advice to offer on that one.  i can resend the message 
to you (or the list) because quite frankly i'd rather use the *right* 
solution than use Apache::AuthCookie with grafted-in database calls

--brian



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: AuthCookieDBI configuration woes

[Brian Clarkson]

Perrin Harkins wrote:

On Thu, 2004-03-11 at 11:17, Brian Clarkson wrote:


I've never used any of the AuthCookie modules, but this error is coming
from apache:
http://httpd.apache.org/docs/misc/FAQ.html#authauthoritative
It sounds like AuthCookieDBI is returning DECLINED (or rather AuthCookie
is) when your auth fails.  To find out why, you might want to try
running that login URL with the debugger enabled, or turning on the
AuthCookieDebug flag.
i do have the AuthCookieDebug flag on; it's set to 3.

i have a feeling that some other BasicAuth is conflicting.  i (perhaps 
mistakenly) thought that i could mix BasicAuth and Apache::AuthCookie* 
auth schemes for different directory setups.  (at least, this is during 
testing, before I completely drop the BasicAuth in favor of the Apache 
solution ).



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::AuthCookieDBI and SecretKeyFile

[Brian Clarkson]

The WhateverDBI_SecretKeyFile seems to be everyone's problem with this 
module.  I've searched around, read most people's fixes, but none of 
them work for me.  Here's my error_log snippet:

[Tue Mar 23 12:04:58 2004] [error] access to /LOGIN failed, reason: 
Apache::AuthCookieDBI: didn't have the secret key for auth realm JBG
[Tue Mar 23 12:04:58 2004] [error] access to /logintest failed, reason: 
Apache::AuthCookieDBI: didn't the secret key from for auth realm JBG

The host in question is a VirtualHost.  My first configuration attempt, 
which matches one of the more common solutions ( putting the PerlSetVar 
directive before the module load ) doesn't do the trick:



ServerName host.domain.com

[DocRoot and Logging Directives]

## these directives are for Apache::AuthCookieDBI
## and MUST COME FIRST
PerlSetVar JBGDBI_SecretKeyFile /home/httpd/secure.jbgoodwin.com/keyfile

PerlModule Apache::AuthCookieDBI
PerlSetVar JBGPath /
PerlSetVar JBGLoginScript /login.pl
[ other PerlSetVar directives ]

## the two location directives:

## These documents require user to be logged in.

 AuthType Apache::AuthCookieDBI
 AuthName JBG
 PerlAuthenHandler Apache::AuthCookieDBI->authenticate
 PerlAuthzHandler Apache::AuthCookieDBI->authorize
 require valid-user

# 

##this is the action of the login.pl script above.

 AuthType Apache::AuthCookieDBI
 AuthName JBG
 SetHandler perl-script
 PerlHandler Apache::AuthCookieDBI->login


The handler gets called.  I've double-checked everything, and now the 
SecretKeyFile is being wonky.  I've read through the code, read through 
the docs, googled for an answer, even tried setting the SecretKey 
directive in the main server config (not in the VH config).

Permissions look OK:

[hostname ] $ ls -al keyfile
-rw---1 nobody   nobody 52 Mar  1 11:22 keyfile
I have to be missing something obvious?

The earlier problem I was having, if anyone was interested, got solved. 
 The problem was mod_auth looking first, the Apache::AuthCookie trying 
to kick in  ...

--brian

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::AuthCookieDBI and SecretKeyFile

[Brian Clarkson]

William McKee wrote:

Hi Brian,

I've had my share of problems with this module as well. I've found the
following two solutions which I submitted to CPAN RT[1]:
1) place the PerlSetVar at the very top of your httpd.conf
In the Global ENV section?  Doesn't fix the issue.
2) instead of using PerlModule, use the following:


use Apache::AuthCookieDBI;

Tried that too, and I'm still getting the same errors.

I've even tossed this line into the BEGIN block 

Apache::log_error( "DEBUG:  >$auth_name< in file >$keyfile<" );

and i get no output, either on server restart or on script invocation. 
(i'd expect it at server startup ).



BTW, I've submitted several other reports to CPAN which the author has
so far ignored. The most troubling one is "Incorrect processing of
authen_cred()"[2]. I've submitted a patch which you may want to apply.
Let me know if you'd like a copy.
I might need to take a look at that patch.  The error that shows up is 
from sub authen_ses_key 

i can tell because it's a horribly constructed sentence.  :-P ( didn't 
the secret key  )

--b--




Good luck,
William
[1] http://rt.cpan.org/NoAuth/Bug.html?id=4847
[2] http://rt.cpan.org/NoAuth/Bug.html?id=3673


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::AuthCookieDBI and SecretKeyFile

[Brian Clarkson]

Nick Phillips wrote:
On 24/03/2004, at 6:24 AM, Brian Clarkson wrote:


The host in question is a VirtualHost.  My first configuration 
attempt, which matches one of the more common solutions ( putting the 
PerlSetVar directive before the module load ) doesn't do the trick:


You *must* put *all* the PerlSetVar configuration for AuthCookie* in the 
*main* apache
configuration, not in a virtual host section or similar.

This is because it is read in a BEGIN block, and there is no current 
request and hence no
appropriate virtual host at that stage.

It's in the docs, IIRC.
nope, at least not in the perldoc for the version i'm using.  ( 1.19 ).

so there's no way to use this module with VirtualHosts?  guess i'm outta 
luck ... because this is a hosting environment with ~50 or do VHs and no 
'main' server.



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::AuthCookieDBI and SecretKeyFile

[Brian Clarkson]

Actually, with a little bit of help and a little config tweaking I got 
this working.

1.  created separate include files for the Perl directives and the 
Location/ Directory directives.  one is in the main server config ( Perl 
directives) and the other is part of the VH config.

2.  realized that part of the problem with the testing setup was that 
/LOGIN was also considered protected  because of the PerSetDirectory 
being set to / ... changing that to /logintest fixed it, and I can now 
log into the sample part of the site.

I'll need to make a few changes from another thread to finish the 
install of this, namely aliasing the /LOGIN Location to something 
'outside' of the docroot ( per a thread on Apache::AuthCookie ).

thanks for the help

--b--

Nick Phillips wrote:

On 24/03/2004, at 6:24 AM, Brian Clarkson wrote:

The WhateverDBI_SecretKeyFile seems to be everyone's problem with this 
module.  I've searched around, read most people's fixes, but none of 
them work for me.  Here's my error_log snippet:

[Tue Mar 23 12:04:58 2004] [error] access to /LOGIN failed, reason: 
Apache::AuthCookieDBI: didn't have the secret key for auth realm JBG
[Tue Mar 23 12:04:58 2004] [error] access to /logintest failed, 
reason: Apache::AuthCookieDBI: didn't the secret key from for auth 
realm JBG

The host in question is a VirtualHost.  My first configuration 
attempt, which matches one of the more common solutions ( putting the 
PerlSetVar directive before the module load ) doesn't do the trick:


You *must* put *all* the PerlSetVar configuration for AuthCookie* in the 
*main* apache
configuration, not in a virtual host section or similar.

This is because it is read in a BEGIN block, and there is no current 
request and hence no
appropriate virtual host at that stage.

It's in the docs, IIRC.



Cheers,

Nick



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::Cookie not finding cookies ...

[Brian Clarkson]

I'm hoping that I'm doing something wrong ...

I have Apache::AuthCookieDBI working for login and session expiration ( 
I set it to 5 minutes so that I could basically watch the session ticket 
expire ), but manual logout isn't working ...

I've tried the logout.pl that comes in the Apache::AuthCookie dist, but 
that didn't work.

I've rolled this:

my %cookies = Apache::Cookie->fetch($r);
foreach my $name ( values %cookies ) {
  $name->expires("-1d");
  $name->bake();
}
$r->content_type("text/html");
$r->status(200);
$r->send_http_header;
my $tmpl = HTML::Template->new( path => TMPL_PATH,
filename => TMPL_FILE
   );
print $tmpl->output();
but no luck, because there's nothing in %cookies.  ( I verified that by 
assigning a new var to Dumper \%cookies and passing that to 
HTML::Template and got nothing. )

Any advice?  I'd like manual logout to work as well ...

--brian

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Cookie not finding cookies ...

[Brian Clarkson]

Nick Phillips wrote:
On 30/03/2004, at 5:21 AM, Brian Clarkson wrote:

I'm hoping that I'm doing something wrong ...


I've tried the logout.pl that comes in the Apache::AuthCookie dist, 
but that didn't work.


My code has an object that has an Apache::Request object stuffed into 
it, and:
I don't have an object ... I'm firing off logout.pl ( ok, logout.cgi ) 
as a script.  it's in a mod_perl configured directory ...


   SetHandler perl-script
   PerlHandler Apache::Registry
   Options +ExecCGI
   allow from all
   PerlSendHeader On

I tried your code, tried the cookies, but I don't have anything in 
$authType or in the %cookies hash i tried earlier.

my $r = Apache->request;
my $authType = $r->auth_type();
and $authType is empty



i just want to get this to work so i can move on ...

--b--

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: "*:80 has no VirtualHosts" but only via perl!

[Brian Reichert]

On Sat, Apr 24, 2004 at 11:47:15PM -0500, Will Trillich wrote:
> with httpd.conf directives, these virtualhosts work just fine.
> but trying to use perl to make them more universally
> configurable, we get the "no virtualhosts error":
> 
> %VirtualHost = (
>   '*:80' => [
> {

Maybe perl's treating this an RE?

(Just arm-waving; I's still pre-coffee...)

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Problem with perl system() function

[Brian Reichert]

On Wed, Apr 28, 2004 at 03:55:23PM -0400, Alejandro Galue wrote:
> 
> I tried this (inside the handler):
> 
> ...
> my $cmd = '/opt/reports/bin/getdata';
> system($cmd, @params);
> if ( open(DATA, '/opt/reports/var/data.txt') ) {
> local $_;
> while () { $r->print($_) }
> close DATA;
> } else {
> $r->print("Can?t read data");
> }
> ...
> 
> The program getdata put output in /opt/reports/var/data.txt

It may just be an example, but this handler doesn't create a unique
file; it may get stomped my multiple invokations.

Why not

  open(DATA, join(' ', $cmd, @params, '|') || croak "$cmd failed: $? $!\n";

if you're trying to avoid generating a text file.

I wrote the System2 module to get STDERR and STDOUT returned in
scalars (and avoid the Bourne shell); see if that'd be useful for
you...

  my ($out, $err) = system2(@args);

Are you checking on the exit status of your command?

  my ($exit_value, $signal_num, $dumped_core) = &System2::exit_status($?)?

Good luck...

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Callback called exit.

[Brian Hirt]

I've been running across a problem lately where a child process  
terminates because of an out of memory error.   It prints Out of Memory  
once, the the process sucks up all available cpu print "Callback called  
exit." to the log file until it hit's it's 2GB max size.

I have some Apache::Resource limits set, and they probably need to be  
raised, but the way the error is handled is not very graceful.  I'd  
expect the child to just terminate after reporting the first error  
message.   I'm not sure if this is a perl problem or a mod_perl  
problem.   I'd still like to figure out how to prevent the repeating  
message from happening.

Anyway, I've been pulling my hair out trying to prevent this, and I've  
finally figured out how to trap this.   I have some suggestions for the  
documentation, because the following url could use some help:

http://perl.apache.org/docs/1.0/guide/ 
troubleshooting.html#Callback_called_exit

=> "Note that Perl 5.005 and later have PERL_EMERGENCY_SBRK turned on  
by default."

This is only true if perl was built to use it's own malloc.   However,  
"usemymalloc=y" is not the default for many systems because they assume  
the OS version is probably a better implementation (which could be  
true).  However, when perl's internal malloc is used, none of the  
suggestions for solving the out of memory problem or repeated Callback  
called exit messages work.

=> "See Perl's INSTALL document for this item:"
This might have been true at one point.   Newer versions of perl 5.6  
and 5.8 have no reference to this option in the INSTALL document

=>  "=item -DPERL_EMERGENCY_SBRK . "
a better quotation would be from perlvar.pod which states the crux of  
the matter: " . Suppose that your Perl were compiled with  
-DPERL_EMERGENCY_SBRK and used Perl's malloc ..."


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Callback called exit.

[Brian Hirt]

I too followed the advice too, but it did nothing but lead my down the  
wrong path. The advice should be updated.

My point is that $^M does absolutely nothing unless you use perl's  
malloc, which isn't true for most common perl installations these days.  
 compiling with PERL_EMERGENCY_SBRK doesn't help either because it's  
the default if you usemymalloc, and useless if you don't   You MUST  
compile perl with "-Dusemymalloc=y".   A simple grep in the perl hints  
directory shows that many popular systems such as linux, freebsd and  
openbsd default to the system malloc which disables the functionality  
of $^M.

I'd simply like to see the documentation updated, and I'm happy to do  
it.   I know it would have saved me hours and hours of headaches.   The  
documentation as it stands now is misleading.

of course if you use perl's malloc, the advice helps.
I'd still like to know why mod_perl can get into an infinite loop  
writtitng "Callback called exit".In perl.c, when that happens  
my_exit_jump(); is called which should presumably exit the process, but  
somehow that doesn't happen and some sort of infinite loop occurs  
outside of my code that fills the log of with gigibytes of 'Callback  
called exit' messages.

regards,
brian
On May 5, 2004, at 11:00 PM, Glenn wrote:
On Wed, May 05, 2004 at 08:11:56PM -0600, Brian Hirt wrote:
I've been running across a problem lately where a child process
terminates because of an out of memory error.   It prints Out of  
Memory
once, the the process sucks up all available cpu print "Callback  
called
exit." to the log file until it hit's it's 2GB max size.

I have some Apache::Resource limits set, and they probably need to be
raised, but the way the error is handled is not very graceful.  I'd
expect the child to just terminate after reporting the first error
message.   I'm not sure if this is a perl problem or a mod_perl
problem.   I'd still like to figure out how to prevent the repeating
message from happening.
Anyway, I've been pulling my hair out trying to prevent this, and I've
finally figured out how to trap this.   I have some suggestions for  
the
documentation, because the following url could use some help:

http://perl.apache.org/docs/1.0/guide/ 
troubleshooting.html#Callback_called_exit
I've followed that advice and explicitly allocated memory into $^M.
I have the following in my mod_perl_startup.pl, which I run from
httpd.conf with PerlRequire /path/to/mod_perl_startup.pl
If 64K is not enough for you, try increasing the allocation.
Cheers,
Glenn
use strict;
## --
## --
## This section is similar in scope to Apache::Debug.
## Delivers a stack backtrace to the error log when perl code dies.
## Allocate 64K as an emergency memory pool for use in out of memory  
situation
$^M = 0x00 x 65536;

## Little trick to initialize this routine here so that in the case of  
OOM,
## compiling this routine doesn't eat memory from the emergency memory  
pool $^M
use CGI::Carp ();
eval { CGI::Carp::confess('init') };

## Importing CGI::Carp sets $main::SIG{__DIE__} = \&CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = \&CGI::Carp::confess;
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Callback called exit.

[Brian Hirt]

On May 6, 2004, at 10:27 AM, Perrin Harkins wrote:
On Wed, 2004-05-05 at 22:11, Brian Hirt wrote:
I've been running across a problem lately where a child process
terminates because of an out of memory error.   It prints Out of 
Memory
once, the the process sucks up all available cpu print "Callback 
called
exit." to the log file until it hit's it's 2GB max size.
I'm just guessing here, but this is probably because apache is trying 
to
spawn new processes, and they keep dying because there's no memory.

Thanks for the response, interesting insight into the history of $^M.
 When I've seen this happen, it's the same PID spewing the messages, 
there are no forkings going on.   The system isn't actually out of 
memory, and there is plenty of it available for the parent httpd 
process to fork.The child process has an rlimit set which is why 
it's getting an out of memory error.  I initially set the rlimit, 
because at one point in the past the ImageMagick module would every now 
and then go crazy and consume all available memory which would bring 
down everything.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Callback called exit.

[Brian Hirt]

I've typed up my suggestions to the troubleshooting doc, and 
incorporated glen's suggestions too.   Stas wants me to post to the 
list to see if there are any comments / corrections.

I wasn't sure if I should put a comment in about __DIE__ handlers and 
their use with evals, it seemed like that might be too general perl.

Index: src/docs/1.0/guide/troubleshooting.pod
===
RCS file: 
/home/cvspublic/modperl-docs/src/docs/1.0/guide/troubleshooting.pod,v
retrieving revision 1.28
diff -u -r1.28 troubleshooting.pod
--- src/docs/1.0/guide/troubleshooting.pod  5 May 2004 03:29:38 
-   1.28
+++ src/docs/1.0/guide/troubleshooting.pod  6 May 2004 22:40:07 
-
@@ -589,27 +589,45 @@

 If something goes really wrong with your code, Perl may die with an
 "Out of memory!" message and/or "Callback called exit".  Common causes 
of this
-are never-ending loops, deep recursion, or calling an
-undefined subroutine.  Here's one way to catch the problem: See Perl's
-INSTALL document for this item:
+are never-ending loops, deep recursion, or calling an undefined 
subroutine.

-  =item -DPERL_EMERGENCY_SBRK
+If you are using  perl 5.005 or later, and perl is compiled to use 
it's own
+malloc rutines, you can trap out of memory errors by setting aside an 
extra
+memory pool in the special variable $^M.  By default perl uses the 
operating
+system malloc for many popular systems, so unless you build perl with
+'usemymalloc=y' you probably wont be able to use $^M.  To check if 
your mod_perl
+was compiled to use perl's internal malloc(), stick the following code 
in a
+handler and see if usemymalloc is set to 'y'
+
+   use Config;
+
+   print Config::myconfig();
+
+Here is an explanation of $^M from perlvar(i):
+
+   $^M By default, running out of memory is an untrap-
+  pable, fatal error.  However, if suitably built,
+  Perl can use the contents of $^M as an emergency
+  memory pool after die()ing.  Suppose that your
+  Perl were compiled with -DPERL_EMERGENCY_SBRK and
+  used Perl's malloc.  Then
+
+  $^M = 'a' x (1 << 16);
+
+  would allocate a 64K buffer for use in an emer-
+  gency.  See the INSTALL file in the Perl distribu-
+  tion for information on how to enable this option.
+  To discourage casual use of this advanced feature,
+  there is no English long name for this variable.

-  If PERL_EMERGENCY_SBRK is defined, running out of memory need not be 
a
-  fatal error: a memory pool can allocated by assigning to the special
-  variable $^M.  See perlvar(1) for more details.
-
-If you compile with that option and add 'C
+If your perl installation supports $^M and you add 'C
 =E 4;>' to your Perl script, it will allocate the C<$^M> emergency
 pool and the C<$SIG{__DIE__}> handler will call C,
 giving you a stack trace which should reveal where the problem is.
 See the C module for ways to control httpd
 processes.

-Note that Perl 5.005 and later have C turned on
-by default.
-
-The other trick is to have a startup script initialize
+Another trick is to have a startup script initialize
 C, like so:
   use Carp ();
@@ -617,6 +635,24 @@
 this way, when the real problem happens, C doesn't eat
 memory in the emergency pool (C<$^M>).
+
+Some other mod_perl users have reported that this works well for them:
+
+## Allocate 64K as an emergency memory pool for use in out of 
memory situation
+$^M = 0x00 x 65536;
+
+## Little trick to initialize this routine here so that in the 
case of OOM,
+## compiling this routine doesn't eat memory from the emergency 
memory pool $^M
+use CGI::Carp ();
+eval { CGI::Carp::confess('init') };
+
+## Importing CGI::Carp sets $main::SIG{__DIE__} = \&CGI::Carp::die;
+## Override that to additionally give a stack backtrace
+$main::SIG{__DIE__} = \&CGI::Carp::confess;
+
+Discussion of $^M has come up on PerlMonks, and there is speculation 
that $^M is a
+forgotten feature that's not well supported.  See
+http://perlmonks.org/index.pl?node_id=287850 for more information.

 =head2 server reached MaxClients setting, consider raising the 
MaxClients setting


regards,
Brian
On May 6, 2004, at 1:19 PM, Stas Bekman wrote:
Brian Hirt wrote:
I too followed the advice too, but it did nothing but lead my down 
the  wrong path. The advice should be updated.
My point is that $^M does absolutely nothing unless you use perl's  
malloc, which isn't true for most common perl installations these 
days.   compiling with PERL_EMERGENCY_SBRK doesn't help either 
because it's  the default if you usemymalloc, and useless if you 
don't   You MUST  compile perl with "-Dusemymalloc=y".   A simple 
g

Re: mod_perl not able to run some pl files.

[Brian Reichert]

On Thu, May 27, 2004 at 07:45:49PM +0530, Bheema Rao Merugu, BSC, Ambattur, Chennai 
wrote:
> Hi,
>  
>  
> I am getting the below error message in the error_log file. but I had
> the CGI.pm in the path /usr/local/apache/lib/perl5/5.8.3 

When you say you 'had' CGI.pm in that path, do you mean that you
used that perl installation to make/install the module?

Or did you merely copy it in?  If the latter, make sure that you
have permissions on the file set properly.

> Thanks,
> Bheema

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perl not able to run some pl files.

[Brian Reichert]

On Fri, May 28, 2004 at 02:37:39PM +0530, Bheema Rao Merugu, BSC, Ambattur, Chennai 
wrote:
> Hi Tom,
> 
> Thank you for your help.
> 
> I am not using the perl that came with the system. I compiled the source
> code from scratch and using that.

Ok, I think what people meant to suggest was this:

  /usr/local/apache/bin/perl -MCGI -e 'print "CGI.pm version $CGI::VERSION\n";'

That will tell you if _that_ installation of perl knows about a CGI module.

If it's not there, then you'll need to really install CGI.pm there:

  # /usr/local/apache/bin/perl Makefile.PL
  # make && make test && make install

If is _does_ see a CGI module installed, but your mod_perl doesn't,
then we need to do more research.

For example, is there a file called CGI.pm somewhere under that
perl tree?

  find /usr/local/apache/lib -name CGI.pm -ls

What are the permissions on it?  If you installed as root, but had
a restrictive umask, it may not be world-readable, which would
thwart the apache process from reading it.

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perl not able to run some pl files.

[Brian Reichert]

On Mon, May 31, 2004 at 01:19:22PM +0530, Bheema Rao Merugu, BSC, Ambattur, Chennai 
wrote:
> Hi,
> 
>I have noticed one thing while running the perl files.
> 
>in my httpd.conf the user and group names are 
>User nobody
>Group nobody   
>if I change Group name as system
>User nobody
>Group system
>perl files are running fine without any error its giving the problem
> when i am running with group as 'nobody'

Something I had suggested earlier:

> For example, is there a file called CGI.pm somewhere under that
> perl tree?
> 
>   find /usr/local/apache/lib -name CGI.pm -ls
> 
> What are the permissions on it?  If you installed as root, but had
> a restrictive umask, it may not be world-readable, which would
> thwart the apache process from reading it.

I'm guessing that it's group readable.  But we'll never know, if
you don't answer the questions I asked. :/

> Thanks,
> Bheema.

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perl not able to run some pl files.

[Brian Reichert]

On Tue, Jun 01, 2004 at 10:24:33AM +0530, Bheema Rao Merugu, BSC, Ambattur, Chennai 
wrote:
> Hi,
> 
>   I am sorry please find the out put that you are asking for.
> 
>   #  find /usr/local/apache/lib -name CGI.pm -ls
>   372763  228 -rwxrwxrwx  1 root system 230097 May 27 16:50
> /usr/local/apache/lib/perl5/5.8.3/CGI.pm

Egads: a root-owned file that world-writable?!  That's _very_ uncool.

If, by merely changing the group the web server runs as suddenly
make things work, it still leads me to think that the permissions
are off in your Perl tree.

Perl does not install modules world-writable; I think that someone
changed permissions on this file, after the fact. :/

If any component in the path /usr/local/apache/lib/perl5/5.8.3/CGI.pm
is not world-readable, or, in the case of a directory, world-executable,
then user/group nobody/nobody won't be able to read the file.

But this file should certainly not be world-writable.

> Thanks,
> Bheema.

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: reverse IP lookup for check all doimains on the server

[Brian Reichert]

On Thu, Jun 10, 2004 at 09:36:21AM +0200, Maxipoint Rep Office wrote:
> 
> Have someone any idea what I must to do?
> 
> if I add some IP of server that I can see all domains on the same IP on the
> server.

What problem are you trying to solve?

> http://whois.webhosting.info/216.127.92.54
> 
> Mario

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: reverse IP lookup for check all doimains on the server

[Brian Reichert]

On Thu, Jun 10, 2004 at 11:51:02PM +0200, Maxipoint Rep Office wrote:
> how create it at all? :-) about that I can not find any documentation

Create what?  A reverse lookup database?

Or CGI tools to display such a database?

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: reverse IP lookup for check all doimains on the server

[Brian Reichert]

On Fri, Jun 11, 2004 at 12:09:06AM +0200, Maxipoint Rep Office wrote:
> 
> 
> On Thu, Jun 10, 2004 at 11:51:02PM +0200, Maxipoint Rep Office wrote:
> > how create it at all? :-) about that I can not find any documentation
> 
> Create what?  A reverse lookup database?
> 
> Or CGI tools to display such a database?
> 
> 
> RE: CGI tool that display all domains connected on some server IP...

If you mean all domains on the IP(s) of _your_ server, then you
could write code that interprets your Apache config files.  I think
this would be a good starting point:

<http://perl.apache.org/docs/1.0/api/Apache.html#Server_Configuration_Information>

If you want magically divine all domains connected to an arbitrary
IP out there on the internet, then you're asking about a reverse
lookup database...

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: reverse IP lookup for check all doimains on the server

[Brian Reichert]

On Tue, Jun 15, 2004 at 07:01:29PM +0200, Maxipoint Rep Office wrote:
> Why this is off-topic? Why I can not with Perl parse into their
> script/database?
> I must not have their technology, if this is so complicated..

As per your subject line: if you want to provide a list of domains
by IP host on _your_ server, you can do so with the documented API;
I provided a URL to earlier in this thread.

_That_ problem is arguably on-topic, because you can easily use
mod_perl to solve it.

A generic question about writing a perl program to interface with
a database of domains/IPs is not on-topic.

A generic question about how to generate that database (if you're
looking for a DB of domains/IPs _not_ hosted on your server) is not
on-topic.

Good luck...

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

libapreq2 versus everything else

[Dan Brian]

Hi -
Is there a document (or person) with recommendations of using the 
libapreq (2) Perl modules versus the 
Apache::RequestRec/Apache::RequestIO approach described in all the 
perl.apache.org docs? Is libapreq a separate effort from mod_perl 2 and 
its Apache::* space? It's fairly confusing at this point whether there 
exist two different ways to use the Apache2 API, or whether one exists 
waiting for libapreq to catch up, how the apparently conflicting 
namespaces are managed, and so on. The organizations I work with who 
use mod_perl do so strictly with the libapreq interfaces 
(Apache::Cookie etc.), and I'm trying to get a handle on the direction 
of these efforts for migration preparations.

Could someone give me a pointer on where to focus?
Thanks/regards,
Dan Brian
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 versus everything else

[Dan Brian]

From the mod_perl 1.0 land:
http://perl.apache.org/docs/1.0/guide/ 
performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param
And there was a report recently on the apreq-dev list, which shows an  
even better performance of apreq under Apache2.
Thanks Stas.
I understand the benefits of a C binding to the Apache API over, say,  
CGI.pm processing using the environment vars (which is why all my  
projects use libapreq 1). But since both mod_perl2's Apache::RequestRec  
and libapreq's Apache::Request implement XS glue to the Apache API (as  
far as I can tell), I meant to ask about that relationship. Is  
Apache::RequestRec under 2 analogous to Apache::args under 1?

To make the question shorter, is apreq expected to be the preferred  
interface for mod_perl 2, as it was for mod_perl 1? (I'd hate for  
anyone to cross the Spirits of Tim Toady. Just wondering about the  
sentiment of the list.)

Thanks,
Dan Brian
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 versus everything else

[Dan Brian]

While the whole issue has always been somewhat confusing, there's no 
more overlap in MP2. Apache::Request inherits from Apache::RequestRec 
just like it did from its MP1 equivalent Apache.pm before, and adds 
parsing and handling of request parameters incl. multipart/form-data 
and uploads, as well as cookies. MP2 itself doesn't do that anymore, 
Apache::RequestRec::args only gets/sets the whole query string.

I think adding Apache::Request to the mod_perl distribution might save 
a few souls from going PHP. Having all these fancy APIs but not basic 
stuff like parameter accessors probably scares some newcomers away. 
But since this was mostly true for MP1 already, I guess this must have 
been rejected long ago.
Perfect. Thanks Markus.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: debugging run away httpd process

[Brian Reichert]

On Thu, Oct 14, 2004 at 12:07:17PM +0800, victor wrote:
> 2) Why strace doesn't return anything?  or is strace the appropiate tool 
> to use at all?  is there any mod_perl module/option I should turn 
> on/off/tweak to help me find out what the process is doing?

How are you invoking strace?

> 3) What can I do to find more on those socket listed in 
> /proc//fs are for?  what are they pointing to?

What does 'lsof' show you?  I'm more used to that tool that any
vendor-specific one...

> Any advice would be much much appreciated.
> 
> Tor.
> 
> 
> -- 
>Victor
>   Development Engineer
>   Outblaze Ltd
> -->

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: debugging run away httpd process

[Brian Reichert]

On Fri, Oct 15, 2004 at 10:46:01AM +0800, victor wrote:
> >How are you invoking strace?
> > 
> >
>  As root I ran /usr/bin/strace -p 

There are other useful arguments to strace; see the manpage for '-f
-F -v', and so forth.

>  We have sorted out the problem on this part it turns out to be a 
> special case which casued one of the regex run into infinite loop, so no 
> system call hads been made at all.
> 
>  I just wonder is there any other tool out that beside strace I can use 
> in such situtation?

You can use gdb and friends to attach to a process, but that's more
useful if you've got debugging complied into your code.

>  I am sorry I did not save a copy of the lsof output.  but is there any 
> specific detail you are looking for/I should pay extra attention?

I tend to _not_ use /proc, and was hoping you would have the
opportunity to point lsof at the descriptors in question; this is
just in case there was a latency-induced flaw in terms of what
details /proc was exposing.

That may not be a factor at all, of course, given what you found
the problem to be...

> 
> Tor.
> 

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::DBI, Postgresql, and transactions

[Brian Dimeler]

Hi,
 I've been converting some old CGI scripts for use with mod_perl and 
Apache::DBI. These scripts access a Postgres database through DBI. I 
didn't have any trouble until I began writing a new script which in the 
development phase has generated a few bad SQL commands (my fault, not 
the problem). This has had the unexpected side effect of preventing 
*any* older script running in the same process from executing SQL! The 
error messages for these (perfectly fine) scripts is "current 
transaction is aborted, commands ignored until end of transaction 
block," which I'm guessing means that Postgres is assuming I'm in the 
same transaction as generated the original error, even though it's a 
completely unrelated script.

So I looked into it and found that Apache::DBI is supposed to have a 
'cleanup handler' that automatically does a rollback after a script has 
been run. Shouldn't this take care of the "ignoring until end of block" 
thing? I'm fairly new to the 'transactions' concept but I'm guessing 
that a ROLLBACK or a COMMIT is the same thing as "ending the transaction 
block", right?

So anyway, I recompiled mod_perl to ensure these kinds of handlers were 
enabled, restarted the server with $Apache::DBI::DEBUG set to 2, and 
sure enough, I started getting debug messages about rollbacks after each 
script finished executing. Problem is.. they stopped, after awhile. 
Mysteriously, about an hour after restarting, the cleanup handlers 
either aren't running or aren't printing debug info anymore, and the 
'transaction aborted' errors are back. Does anyone know what could cause 
this, or how I could better diagnose my system?

 I'm running Postgres 7.4, Perl 5.8.1, mod_perl 1.29 and Apache 1.3 on 
Mac OS X Panther; mod_perl is using PerlRun and Apache::StatINC.

Brian

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::DBI, Postgresql, and transactions

[Brian Dimeler]

Thanks for the suggestion, but it's the same connection with the same 
params every time. The connection code is actually in a Class::DBI 
module, which gets use()'d by all of my scripts. This module isn't in my 
startup script, so that each process keeps its own copy. So there are 
multiple handles, but they should all be identical and used by different 
interpreters.

Upon further investigation I've found that the rollback is only 
executing once for each server process, and never again after that. 
That's true even *without* the bad SQL and transaction aborted erors. 
I'm assuming that isn't the intended behavior...

Also, I read on some newsgroup that cleanups don't run if there's been a 
500 error or the user hit the 'stop' button. If true, why not? Isn't 
following an error the best possible time to execute cleanup code? Is 
there a way, either with the mod_perl API or some standard perl trick, 
to force the server to run additional code after such an error?


Joe Thomas wrote:
Do you ever connect to a different database from your mod_perl scripts 
-- or to the same database with different options?  Or even use a 
different form for the database hostname (hostname only vs. 
fully-qualified domain name)?

If you do, please try this patch (inline and attached) against the 
current Apache::DBI.  I believe it fixes a bug in rolling back 
transactions when more than one database handle is used.

Joe
--- DBI.pm.orig Tue Feb 17 16:18:50 2004
+++ DBI.pm  Tue Aug 31 14:48:58 2004
@@ -21,7 +21,6 @@
my %Rollback; # keeps track of pushed PerlCleanupHandler which can 
do a rollback after the request has finished
my %PingTimeOut;  # stores the timeout values per data_source, a 
negative value de-activates ping, default = 0
my %LastPingTime; # keeps track of last ping per data_source
-my $Idx;  # key of %Connected and %Rollback.

# supposed to be called in a startup script.
@@ -67,7 +66,7 @@
my $dsn= "dbi:$drh->{Name}:$args[0]";
my $prefix = "$$ Apache::DBI";
-$Idx = join $;, $args[0], $args[1], $args[2];
+my $Idx = join $;, $args[0], $args[1], $args[2];  # key of 
%Connected and %Rollback.

# the hash-reference differs between calls even in the same
# process, so de-reference the hash-reference
@@ -96,7 +95,7 @@
# TODO - Fix mod_perl 2.0 here
if(!$Rollback{$Idx} and $needCleanup and 
Apache->can('push_handlers')) {
print STDERR "$prefix push PerlCleanupHandler \n" if 
$Apache::DBI::DEBUG > 1;
-Apache->push_handlers("PerlCleanupHandler", \&cleanup);
+Apache->push_handlers("PerlCleanupHandler", sub { cleanup($Idx) 
});
# make sure, that the rollback is called only once for every
# request, even if the script calls connect more than once
$Rollback{$Idx} = 1;
@@ -155,6 +154,7 @@
# Note: the PerlCleanupHandler runs after the response has been sent to 
the client

sub cleanup {
+my $Idx = shift;
my $prefix = "$$ Apache::DBI";
print STDERR "$prefix PerlCleanupHandler \n" if $Apache::DBI::DEBUG 
 > 1;
my $dbh = $Connected{$Idx};


--- DBI.pm.orig Tue Feb 17 16:18:50 2004
+++ DBI.pm  Tue Aug 31 14:48:58 2004
@@ -21,7 +21,6 @@
 my %Rollback; # keeps track of pushed PerlCleanupHandler which can do a rollback after the request has finished
 my %PingTimeOut;  # stores the timeout values per data_source, a negative value de-activates ping, default = 0
 my %LastPingTime; # keeps track of last ping per data_source
-my $Idx;  # key of %Connected and %Rollback.
 
 
 # supposed to be called in a startup script.
@@ -67,7 +66,7 @@
 my $dsn= "dbi:$drh->{Name}:$args[0]";
 my $prefix = "$$ Apache::DBI";
 
-$Idx = join $;, $args[0], $args[1], $args[2];
+my $Idx = join $;, $args[0], $args[1], $args[2];  # key of %Connected and %Rollback.
 
 # the hash-reference differs between calls even in the same
 # process, so de-reference the hash-reference 
@@ -96,7 +95,7 @@
 # TODO - Fix mod_perl 2.0 here
 if(!$Rollback{$Idx} and $needCleanup and Apache->can('push_handlers')) {
 print STDERR "$prefix push PerlCleanupHandler \n" if $Apache::DBI::DEBUG > 1;
-Apache->push_handlers("PerlCleanupHandler", \&cleanup);
+Apache->push_handlers("PerlCleanupHandler", sub { cleanup($Idx) });
 # make sure, that the rollback is called only once for every 
 # request, even if the script calls connect more than once
 $Rollback{$Idx} = 1;
@@ -155,6 +154,7 @@
 # Note: the PerlCleanupHandler runs after the response has been sent to the client
 
 sub cleanup {
+my $Idx = shift;
 my $prefix = "$$ Apache::DBI";
 print STDERR "$prefix PerlCleanupHandler \n" if $Apache::DBI::DEBUG > 1;
 my $dbh = $Connected{$Idx};



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Lis

Re: Apache::DBI, Postgresql, and transactions

[Brian Dimeler]

Thanks! It seems to be working correctly after implementing your changes.
Brian
Perrin Harkins wrote:
I plan to submit a patch for Ima::DBI to fix this, but in the meantime I
am handling it by overriding db_Main and doing the connections myself. 
Here's the code I use:

my $db_options = {
RaiseError => 1,
AutoCommit => 0,
FetchHashKeyName   => 'NAME_lc',
ShowErrorStatement => 1,
ChopBlanks => 1,
RootClass  => 'DBIx::ContextualFetch'
};
# override default to avoid using Ima::DBI closure
sub db_Main {
my $dbh;
if ( $ENV{'MOD_PERL'} and !$Apache::ServerStarting ) {
$dbh = Apache->request()->pnotes('dbh');
}
if ( !$dbh ) {
# $config is my config object.  replace with your own
settings...
$dbh = DBI->connect_cached(
$config->get('DbDSN'),  $config->get('DbUser'),
$config->get('DbPass'), $db_options
);
if ( $ENV{'MOD_PERL'} and !$Apache::ServerStarting ) {
Apache->request()->pnotes( 'dbh', $dbh );
}
}
return $dbh;
}
sub dbi_commit {
my $self = shift;
$self->db_Main()->commit();
}
sub dbi_rollback {
my $self = shift;
$self->db_Main()->rollback();
}
Note that it was necessary to override dbi_commit and dbi_rollback as
well because now Ima::DBI doesn't know about this handle.  I also
stashed the handle in pnotes() for some extra speed because Class::DBI
requests it so frequently.  Stashing in pnotes() is safe because it gets
cleared out at the end of each request even if your code dies.  Make
sure you keep the other db options intact or various things in
Class::DBI will break.
- Perrin


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: user login ( authentication )

[Brian Reichert]

On Mon, Nov 01, 2004 at 09:40:16AM -0800, [EMAIL PROTECTED] wrote:
> hello
> could some kind soul please advice as how to implement rock solid
> authentication with modperl
> I have a db app running mod_perl/perl/apache/mysql and need user
> authentication, should I use the database's authentication or should I
> write my own ?which is better?

I've used Apache::Authticket for managing authentication.

You don't use the database's authentication, per se; the proscribed
mechanism is to create a separate MySQL table for uid/password for
web-based authentication.

> ...any advice(help) much appreciated

Any luck googling?  This has been done so many times...

> /G
> --
> www.gh-webinteractive.com

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: user login ( authentication )

[Brian Reichert]

On Mon, Nov 01, 2004 at 12:45:11PM -0600, David Nicol wrote:
> "proscribed?" are you sure?
> 
> m-w.com says that word means
> 2 : to condemn or forbid as harmful or unlawful : PROHIBIT

Whoopsie, typo. :)  I meant 'prescribe'. :)  Thanks for the correction...

> > You don't use the database's authentication, per se; the proscribed
> > mechanism is to create a separate MySQL table for uid/password for
> > web-based authentication.
> 
> 
> -- 
> David L Nicol
> transportation infrastructure technology contracting since 2002

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: New to ModPerl 2

[Dan Brian]

Note, though, that libapreq2 will require some changes in your code,  
but probably less than not using libapreq. Be sure to read the  
documentation, especially the notes about converting from v1, for  
Apache::Request and Apache::Cookie at:
I'll add to your list (of potential confusion) that $r->args may not  
produce the expected results, and not just because of the change away  
from array context described at:

   


Although Apache::Request inherits methods from Apache::RequestRec,  
args() is one place where there is function overlap:  
Apache::Request->args() returns an Apache::Request::Table object, while  
Apache::RequestRec->args() returns the unparsed query string.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perlservice? what the heck?

[Dan Brian]

Having spent time building lots of webapps with flash, and knowing 
many people who still do so and come from art school backgrounds, 
their system seems simple enough and tailored exactly for someone who 
doesn't know programming.
You need to know programming to use it. Perl, specifically.
It seems to be an easily configurable and targeted (not limited) 
system for completing an often needed task.
So are existing standards like XML-RPC, with accompanying 
implementations. And there are a handful of Flash libs for it, as well 
as lots of tutorials for Flash developers not familiar with RPC.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perlservice? Heck Yeah!

[Dan Brian]

I think it's great that you are proud of your work. Criticism will make  
your work better.

Calling this "cross-language remoting" is kind of a misnomer, because  
standards like SOAP/XML-RPC are what allow RPC to occur cross-language.  
Yours is a Perl server solution (by definition), and not based on any  
RPC standard I recognize, which means developers must use your client  
APIs. It therefore misses a great deal of the purpose of systems like  
SOAP/XML-RPC: any-language server, any-language client.

With mod_perlservice, you can host RPC webservices AND webpages all on  
one
server! Wow.
That's pretty ignorant of mod_* generally. I can host RPC services and  
pages now all under one Apache, and under one mod_perl, using code with  
established user bases. So actually, to serve dynamic pages under the  
same Apache as one hosting mod_perlservice, we'd need to load a second  
embedded interpreter via mod_perl, whereas we use one to do the same  
now. So your point is ... backwards.

You have written a mod that embeds the Perl interpreter (as does  
mod_perl), embeds the Apache API (as does mod_perl), but has as its  
only application writing RPC interfaces with your proprietary protocol,  
rather than the much broader/robust feature set offered by mod_perl.  
It's really about the equivalent to embedding the Perl interpreter into  
a compiled binary to parse some proprietary file format, rather than  
publish Perl modules to accomplish the same (or use an existing  
standard file format to begin with).

Also mod_perlservice's configuration system allows you to host MANY RPC
applications on a single Apache server. Try hosting 25 different remote
apps using XML-RPC; there is no native functionality that enables  
XML-RPC
to accomplish such feats.
There's a limit to the number of apps you can host with XML-RPC? How do  
you figure?

Furthermore, mod_perlservice offers a clean programming interface, much
cleaner, less complicated, more scalable, and better organized than any
system out there. Just try it.
Your article claims similar benefits of ease, but doesn't explain what  
these benefits are. In the case of Flash '04, it has native support for  
both SOAP and XML-RPC (a benefit), making the default choices  
compatible with large collections of ready-to-use web services (another  
benefit). Writing a SOAP service with SOAP::Lite, for example, can be  
just as terse as your examples (a benefit), and be instantly compatible  
with the existing SOAP clients (benefit). Say, ActionScript's  
out-of-the-box support:

NetServices.setDefaultGatewayUrl("http://hostname.com/gateway";);
gateway = NetServices.createGatewayConnection();
service =  
gateway.getService("http://www.xmethods.net/sd/2001/ 
BabelFishService.wsdl", this);
service.BabelFish({translationmode:language, sourcedata:text});
function BabelFish_Result (result) {
translated = result;
}

What benefits does mod_perlservice offer over what we have today?
Well, why not just use mod_perl?
Well that's a silly question.
That you find this a silly question makes me wonder whether you  
understand mod_perl.

mod_perlservice is an RPC system, not a CGI
system. You will NOT use mod_perlservice to serve up dynamic web pages  
-
that's mod_perl's job.
mod_perl is for writing RPC, too. As well as anything else you can  
serve over HTTP et al (and almost any other protocol for v2). If your  
complaint about existing RPC was simplicity, why did you write  
something that duplicates mod_perl, limiting its application, rather  
than just write Perl modules that run under mod_perl to implement your  
own protocol (as have XML-RPC and SOAP Perl modules)? Why write another  
embedded interpreter?

No, mod_perlservice will be used to create
applications that need to call remote subs and object-methods. mod_perl
CGI doesn't provide support for marshaling and unmarshaling aggregates;
try passing an array of hashes of arrays of integers efficiently using
CGI, it's improbable. mod_perlservice is for distributed applications  
that
need to pass and retrieve complex data structures, it is not for simple
forms and content-based html apps.
Despite the fact that I don't know what "mod_perl CGI" is supposed to  
describe, everything you describe is already done (and in many heavy  
production environments) with mod_perl + SOAP/XML-RPC Perl modules.  
Again, I don't think you have a grasp what mod_perl is or does.

So, I've been a bit of a Frankenstein, sewing mod_perlservice together
from the best elements of all the systems out there. Now we have a
scalable, secure, practical, clean, fast, and robust webservices  
system.
Be happy.
Great. But we have that already in mod_perl + RPC modules.
On the other hand I understand the emotion. You may have felt  
threatened
by a new embedded perl system on Apache. I hope I have allayed your  
fears
since mod_perlservice doesn't threaten your work, but instead  
complements
it.
N

Re: mod_perl marketing

[Dan Brian]

The lack of awareness extends to Apache generally, and not just 
mod_perl. Saying that "mod_perl isn't just CGI; it allows Perl coding 
to the Apache API" is not really informative, because people don't know 
what the Apache API is. (The author that initiated this thread replied 
to me privately that his mod_ "doesn't embed the Apache API, is that 
possible?", so it appears to be possible to write a mod_ without even 
knowing ... ?)

Only 2 years ago I was pitching a "Perl application development" title 
to an O'Reilly editor (who shall remain nameless) who asked me why I 
thought mod_perl was a "big deal" (since my outline had a heavy 
emphasis on it). After explaining what I thought about it, I got a 
curious look, followed by the comment, "yeah, we don't think that is 
really going places." And to this day, many Perl people still don't 
understand how you could build large applications using mod_perl, as 
opposed to CGI + templates and PHP (or other HTML markups). Threads 
like (http://use.perl.org/~jjohn/journal/20761) still make the mistake 
of comparing mod_perl to PHP. mod_perl invites developers to invent new 
CMSs, new ways to authenticate, to manage sites, to log data, new ways 
to handle content. PHP is for writing web sites. I personally didn't 
know whether mod_perl's audience is that much larger than its current 
user base; this thread proves it is.

I have used mod_perl 1 since soon after it became available, building 
several CMSs, custom markup languages (as have we all), and so on. 
Verio's entire line (almost) of web hosting customer interfaces is 
built on mod_perl and XSLT. This isn't emerging technology anymore! I 
took the dive to mp2 a few months ago, and am astounded by both the 
Apache 2 API and its Perl translation. You have all completely outdone 
yourselves, and mp is a bigger deal than ever.

I would suggest that future mp2 articles (on perl.com and elsewhere) 
take some time to explain the Apache API and why it is by far the best 
choice for Perl server development, before diving into the particulars 
of accomplishing something with it. Perhaps a "mod_perl for Beginners: 
All Your Servers ..." article could be useful, or adapting Randal's 
intro talk, or something like that.

In the end though, there's a lot of documentation. The eagle book is 
great, and the cookbook was mentioned too. Until people read, there's 
not much we can do about it.

- Dan
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perl marketing

[Dan Brian]

So far only a few people actually did something (publishing articles, 
helping to update and improve the website), the rest are just talking.
Many are also spending a lot of time influencing their own spheres 
(businesses, peers) to learn and actually adopt the technology. I think 
that's some of the most valuable advocacy.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

CGI::Carp and PerlRun

[Brian Dimeler]

Hi,
 I've noticed that on some of my simpler CGI scripts, in which I use 
CGI::Carp's 'die' replacement to print an error message to the browser, 
PerlRun will give an internal server error instead, but still log the 
error message. These scripts worked fine under mod_cgi. CGI::Carp's 
documentation claims to have long ago been patched to work with 
mod_perl, but for some reason this isn't working for me. Even a very 
simple example:

#!/usr/bin/perl -w
use CGI::Carp 'fatalsToBrowser';
die 'CGI::Carp test';
will log this in error_log:
[Thu Dec  9 10:54:27 2004] [error] PerlRun: `CGI::Carp test at 
/System/Library/Perl/5.8.1/CGI/Carp.pm line 312.

yet generate a 500 error for the browser (access_log):
[09/Dec/2004:10:54:27 -0500] "GET /cgi-bin/carptest.pl HTTP/1.1" 500 605
Does anyone know why this would happen under PerlRun, which is 
*supposed* to be able to run CGI scripts without modification, and if 
there's a workaround?

Thanks,
Brian
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[libapreq] could not create/open temp file

[Brian Hirt]

all of a sudden i'm getting '[libapreq] could not create/open temp file'.   Searching on google, i came across a patch stan posted  to give a more meaningful error message, but somehow it never made it into the CVS tree.  (i've got libapreq1.2 installed)

here was the old patch.   anyway, it would be nice if this was incorporated into the real source code, it would have made finding the problem much easier/quicker.

Index: c/apache_request.c
===
RCS file: /home/cvs/httpd-apreq/c/apache_request.c,v
retrieving revision 1.20
diff -u -r1.20 apache_request.c
--- c/apache_request.c  18 Feb 2002 16:48:27 -  1.20
+++ c/apache_request.c  8 Jun 2002 04:41:08 -
@@ -359,7 +359,9 @@
}

if ( tries == 0  || (fp = ap_pfdopen(r->pool, fd, "w+" "b") ) == 
NULL ) {
- 
ap_log_rerror(REQ_ERROR, "[libapreq] could not create/open temp file");
+ 
ap_log_rerror(REQ_ERROR,
+  "[libapreq] could not create/open temp file: %s",
+  strerror(errno));
if ( fd >= 0 ) { remove(name); free(name); }
return NULL;
}

Index: c/apache_request.h
===
RCS file: /home/cvs/httpd-apreq/c/apache_request.h,v
retrieving revision 1.8
diff -u -r1.8 apache_request.h
--- c/apache_request.h  26 Jun 2001 10:58:29 -  1.8
+++ c/apache_request.h  8 Jun 2002 04:41:08 -
@@ -9,6 +9,7 @@
#include "http_main.h"
#include "http_protocol.h"
#include "util_script.h"
+#include 

#ifdef  SFIO
#include "sfio.h" 

Re: PATCH porting.pod "First Mystery"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> - move the perl4 lib solution to the perl_reference.pod

Will do when I get round to that bit.  I still think a mention of it
is needed in porting.pod to warn people away from it.  If you disagree
simply delete the offending paragraph.

> - suggest turning a lexical variable declared with my() into a global
> variable declared with our() to avoid the closure, with the following
> "but"s:
> 
>o if with my() it wasn't crucial to initialize the variables
> (since my() initialized them to 'undef'), now all variables declared with
> our() must be explicitly initialized.

> [Brian: notice that I prefer *not* to suggest using local() to init
> vars, and rather have users do that explicitly, which is a good
> practice]

Well I disagree with you about it being good a practice.  I personally
consider it good practice to work in a way that minimises the number
of things you have to do explicitly (with the exception of
declarations).  I can't see why you think relying on the fact that
local() will initialize variables to undef is any worse than relying
on the fact that my() will.

But this is your document so I shall go along with your preferences.

I've tried to keep it brief by moving some of the points (in
particular 'use vars') into comments inside the code examples where
they can be expressed more concisely.

--- porting.pod.origFri Oct 10 18:58:48 2003
+++ porting.pod Fri Oct 10 18:42:27 2003
@@ -88,7 +88,7 @@
   
   print "Content-type: text/plain\r\n\r\n";
   
-  my $counter = 0;
+  my $counter = 0; # Explicit initialization technically redundant
   
   for (1..5) {
 increment_counter();
@@ -195,8 +195,8 @@
 
 print "Content-type: text/plain\r\n\r\n";
 
-my $counter = 0;
-
+my $counter = 0; # Explicit initialization technically redundant
+
 for (1..5) {
   increment_counter();
 }
@@ -228,51 +228,66 @@
 
 It's important to understand that the I effect
 happens only with code that C wraps with a
-declaration of the C subroutine. If you put your code into a
-library or module, which the main script require()'s or use()'s, this
-effect doesn't occur.
-
-For example if we move the code from the script into the subroutine
-I, place the subroutines into the I file, save it in
-the same directory as the script itself and require() it, there will
-be no problem at all. (Don't forget the C<1;> at the end of the
-library or the require() might fail.)
-
-  mylib.pl:
-  -
-  my $counter;
-  sub run{
-print "Content-type: text/plain\r\n\r\n";
-$counter = 0;
-for (1..5) {
-  increment_counter();
-}
+declaration of the C subroutine.  If you put all your code
+into modules, which the main script Cs, this effect doesn't
+occur.
+
+Do not use Perl4-style libraries.  Subroutines in such libraries will
+only be available to the first script in any given interpreter thread
+to C a library of any given name.  This can lead to
+confusing sporadic failures.
+
+The easiest and the fastest way to solve the nested subroutines
+problem is to switch from lexical scope to package scope for all
+variables for which you get the warning.  The C subroutines
+are never called re-entrantly and each resides in a package to itself.
+Most of the usual disadvantates of package scoped variables are,
+therefore, not a concern.  Note, however, that whereas explicit
+initialization is often redundant for lexical variables it is usually
+not redundant for these package variables as they are reused in
+subsequent executions of the handler.
+
+  counter.pl:
+  --
+  #!/usr/bin/perl -w
+  use strict;
+  
+  print "Content-type: text/plain\r\n\r\n";
+  
+  # In Perl <5.6 our() did not exist, so:
+  #   use vars qw($counter);
+  our $counter = 0; # Explicit initialization now necessary
+
+  for (1..5) {
+increment_counter();
   }
+  
   sub increment_counter{
 $counter++;
 print "Counter is equal to $counter !\r\n";
   }
-  1;
-
-  counter.pl:
-  --
-  use strict;
-  require "./mylib.pl";
-  run();
 
-This solution provides the easiest and the fastest way to solve the
-nested subroutines problem, since all you have to do is to move the
-code into a separate file, by first wrapping the initial code into
-some function that you later will call from the script and keeping the
-lexically scoped variables that could cause the problem out of this
-function.
-
-But as a general rule of thumb, unless the script is very short, I
-tend to write all the code in external libraries, and to have only a
-few lines in the main script.  Generally the main script simply calls
-the main function of my library.  Usually I call it C or
-C.  I don't worry about nested subroutine effects anymore
-(unless I create them myself :).
+If the shared 

Re: PATCH porting.pod "First Mystery"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Brian McCauley wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> >
> >>- move the perl4 lib solution to the perl_reference.pod
> > Will do when I get round to that bit.  I still think a mention of it
> > is needed in porting.pod to warn people away from it.  If you disagree
> > simply delete the offending paragraph.
> 
> I'm not disagreeing with you on this. But I will wait for your second
> patch and commit both at once otherwise one of the solutions gets
> temporary lost...

Yep, OK.

> > [...] this is your document so I shall go along with your preferences.
> 
> It's not really mine, I just happen to maintain it. From the previous
> discussion it seems that those who cared agreed that it's better to
> explicitly declare vars.

I assume that was a typo :-)  s/declare/initialize/.

> Granted 'local our' works, but for (most?)  users this point will be
> lost, as they will just copy-n-paste examples without understanding
> why is it so.

Hey, I've conceded.  You can stop trying to beat me into submission now.

> Power users can figure it out on their own, and I wasn't against
> mentioning it at the end after explaining the longer (more
> explicit?) solution. I think that makes it a happy compromise, no?

I believe that is the compromise embodied in my previous attempt.

> > I've tried to keep it brief by moving some of the points (in
> > particular 'use vars') into comments inside the code examples where
> > they can be expressed more concisely.
> 
> Frankly, I can't understand why do you try to undermine the importance
> of always initializing variables.

I don't.  On the contrary I explain the importance in the narrative
and also re-enforce the importance in comments in the example code.  I
have, at your suggestion, pushed into an afterthought any mention of
the fact that if you need to use local() anyhow you can get away
without explicit initialization of package variables.

Since it appears you _are_ against mentioning it even at the end I'll
remove it completely from porting.pod.  I don't care, I'm not on a
crusade here.

> Unless you are an advanced user and know what you are doing, it's a
> goodness to always initialize variables before you use them.

Of course I agree that initializing variables before you use them is
good.  It's just that I think that implicit initialization using my()
or (if you can't use my(), local()) is better than explicit
initialization using undef().  IMNSHO, whenever one sees an explicit
``$var = undef'' or ``undef($var)'' an alarm bell should ring and ones
first thought should be "is there a missing/misplaced my()/local()?".

BUT

I can't see why we are still arguing about this.  I've worded the
document _as_if_ I agreed with you that explicit initialization was a
"good thing" per se.  The fact that we disagree is, therefore, surely,
irrelevant.

> > +The easiest and the fastest way to solve the nested subroutines
> > +problem is to switch from lexical scope to package scope for all
> > +variables for which you get the warning.  The C subroutines
> 
> Would it be better to say:
> 
> The easiest and the fastest way to solve the nested subroutines
> problem is to switch every lexically scoped variable you get the
> warning for to a global package variable.

Yes, that does read more easily.  But the dangling "for" now grates.
Particularly the juxtaposition "for to".  So I'd keep the "for which"
even if some people consider such strict English grammar to be
affected.

I would drop the word "global" since global has many different
meanings.  By one definition of "global", the orginal file-scoped
lexical variable was global.  By another definition of "global",
package variables (other than ones like %INC) are not global.

The use of the phrase "global variable" in Perl documentation as a
synonym for "package variable" is AFAIK deprocated.

Some people use the phase "global package variable" (or "global global
variable" (sic)) to refer to a variable like %INC.

I've even seen examples where people use the phrase "global variable"
to mean "package variable in package main".

> or something like that? 

OK:

  The easiest and the fastest way to solve the nested subroutines
  problem is to switch every lexically scoped variable for which you
  get the warning to a package variable.

> package scope is lexical scope too.

Er, now I'm really confused.  The our() function declares a lexically
scoped alias for a package variable - but this is getting far too subtle.
 
> > +are neve

Re: PATCH porting.pod "First Mystery"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> >... I'd keep the "for which"
> > even if some people consider such strict English grammar to be
> > affected.
> 
> I guess it reads better if using commas:
> 
> The easiest and the fastest way to solve the nested subroutines
> problem is to switch every lexically scoped variable, you get the
> warning for, to a global package variable.

OK, I still find the strict English grammar easier to read in this
instance, but I'll go with your form. 

> > I would drop the word "global" since global has many different
> > meanings. 
> 
> Well, the problem I have with this approach is the following: I think
> of lexical variables as non-accessible from outside the scope thy
> exist in. This is incorrect for variables declared with 'our' and 'use
> vars', since those variables are accessible outside the file/package
> they were defined in. Which makes them non-lexical. No?

I'm sorry I have no idea where that came form.  I said: Let's not use
the term 'global' to describe a Perl package because it has many
meanings to different people.  You come back with a discussion of the
meaning of lexical scope.

> >>package scope is lexical scope too.
> >
> > Er, now I'm really confused.
> 
> See my comment above.

That would be the comment above where you said "package scope is a
non-lexical scope" (i.e. the exact opposite)?

Anyhow - none of that matters now.
 
> BTW, let's finish off that porting mystery issue when you get a
> chance... it's been dragging for too long ;) partially because of me ;)

I think porting.pod is done.  Now I have to attack perl_reference.pod,
and I assume from what you said before you don't want to release the
one without the other.

--- porting.pod.origFri Oct 10 18:58:48 2003
+++ porting.pod Fri Oct 24 13:46:50 2003
@@ -88,7 +88,7 @@
   
   print "Content-type: text/plain\r\n\r\n";
   
-  my $counter = 0;
+  my $counter = 0; # Explicit initialization technically redundant
   
   for (1..5) {
 increment_counter();
@@ -195,8 +195,8 @@
 
 print "Content-type: text/plain\r\n\r\n";
 
-my $counter = 0;
-
+my $counter = 0; # Explicit initialization technically redundant
+
 for (1..5) {
   increment_counter();
 }
@@ -228,51 +228,65 @@
 
 It's important to understand that the I effect
 happens only with code that C wraps with a
-declaration of the C subroutine. If you put your code into a
-library or module, which the main script require()'s or use()'s, this
-effect doesn't occur.
-
-For example if we move the code from the script into the subroutine
-I, place the subroutines into the I file, save it in
-the same directory as the script itself and require() it, there will
-be no problem at all. (Don't forget the C<1;> at the end of the
-library or the require() might fail.)
-
-  mylib.pl:
-  -
-  my $counter;
-  sub run{
-print "Content-type: text/plain\r\n\r\n";
-$counter = 0;
-for (1..5) {
-  increment_counter();
-}
+declaration of the C subroutine.  If you put all your code
+into modules, which the main script Cs, this effect doesn't
+occur.
+
+Do not use Perl4-style libraries.  Subroutines in such libraries will
+only be available to the first script in any given interpreter thread
+to C a library of any given name.  This can lead to
+confusing sporadic failures.
+
+The easiest and the fastest way to solve the nested subroutines
+problem is to switch every lexically scoped variable, you get the
+warning for, to a package variable. The C subroutines are
+never called re-entrantly and each resides in a package to itself.
+Most of the usual disadvantates of package scoped variables are,
+therefore, not a concern.  Note, however, that whereas explicit
+initialization is not always necessary for lexical variables it is
+usually necessary for these package variables as they persist in
+subsequent executions of the handler and unlike lexical variables,
+don't get automatically destroyed at the end of each handler.
+
+
+  counter.pl:
+  --
+  #!/usr/bin/perl -w
+  use strict;
+  
+  print "Content-type: text/plain\r\n\r\n";
+  
+  # In Perl <5.6 our() did not exist, so:
+  #   use vars qw($counter);
+  our $counter = 0; # Explicit initialization now necessary
+
+  for (1..5) {
+increment_counter();
   }
+  
   sub increment_counter{
 $counter++;
 print "Counter is equal to $counter !\r\n";
   }
-  1;
-
-  counter.pl:
-  --
-  use strict;
-  require "./mylib.pl";
-  run();
 
-This solution provides the easiest and the fastest way to solve the
-nested subroutines problem, since all you have to do is to move the
-code into a separate file, by first wrapping the initial code into
-some function that you later will call from the script and keeping the
-lexically scoped variables that could cause the problem out of this
-function.
-
-But as a general rule of thumb, unless the script is very short, I
-tend to write all the code in external li

PATCH perl_reference.pod "Remedies for Inner Subroutines"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Brian McCauley wrote:
> 
> > I think porting.pod is done.
> 
> Indeed.
> 
> > Now I have to attack perl_reference.pod,
> > and I assume from what you said before you don't want to release the
> > one without the other.
> 
> Yes. Let's commit them together.

Here's a _very_ rough first cut at perl_reference.pod.  I haven't even
proof-read it yet so it's probably got spelling a and grammar errors
but I just want to be sure I'm going in the right direction.

--- perl_reference.pod.orig Thu Aug 14 18:11:11 2003
+++ perl_reference.pod  Fri Oct 31 19:46:56 2003
@@ -863,16 +863,17 @@
 problem, Perl will always alert you.
 
 Given that you have a script that has this problem, what are the ways
-to solve it? There are many of them and we will discuss some of them
-here.
+to solve it? There have been many of them suggested in the past and we
+will discuss some of them here.
 
 We will use the following code to show the different solutions.
 
   multirun.pl
   ---
-  #!/usr/bin/perl -w
+  #!/usr/bin/perl
   
   use strict;
+  use warnings;
   
   for (1..3){
 print "run: [time $_]\n";
@@ -925,20 +926,26 @@
   Counter is equal to 5 !
   Counter is equal to 6 !
 
-Obviously, the C<$counter> variable is not reinitialized on each
-execution of run(). It retains its value from the previous execution,
-and sub increment_counter() increments that.
-
-One of the workarounds is to use globally declared variables, with the
-C pragma.
+Apparently, the C<$counter> variable is not reinitialized on each
+execution of run(), it retains its value from the previous execution,
+and increment_counter() increments that.  Actually that's not quite
+what happens.  On each execution of run() a new C<$counter> variable
+is initialized to zero but increment_counter is remains bound to the
+C<$counter> variable from the first call to run().
+
+The simplest of the workarounds is to use package-scoped variables,
+declared using C or, on older versions of Perl, the C
+pragma.  Note that whereas using C declaration also implicitly
+initializes variables to undefined the C declaration does not,
+and so you may need to add explicit initialisation.
 
   multirun1.pl
-  ---
-  #!/usr/bin/perl -w
+  
+  #!/usr/bin/perl
   
   use strict;
-  use vars qw($counter);
-  
+  use warnings;  
+
   for (1..3){
 print "run: [time $_]\n";
 run();
@@ -946,7 +953,7 @@
   
   sub run {
   
-$counter = 0;
+our $counter = 0;
   
 increment_counter();
 increment_counter();
@@ -977,11 +984,34 @@
 problem, since there is no C (lexically defined) variable used
 in the nested subroutine.
 
-Another approach is to use fully qualified variables. This is better,
-since less memory will be used, but it adds a typing overhead:
+In the above example we know C<$counter> is just a simple small
+scalar.  In the general case variables could reference external
+resource handles or large data structures.  In that situation the fact
+that the variable would not be released immediately when run()
+completes could be a problem.  To avoid this you should put C
+in front of all you C declarations for all variables other than
+simple scalars.  This has the effect of restoring the variable to its
+previous value (usually undefined) upon exit from the current scope.
+As a side-effect C also initializes the variables to C.
+So, you recall that thing I said about needing to remeber to add
+explicit initialization when you replace C by C, well you can
+forget it again if you replace C with C.
+
+Be warned that C will not release circular data structures and
+if the original CGI script relied on process termination to clean up
+after it then it will leak memory as a registry script.
+
+A varient of the package variable approach is to use explicit package
+qualified variables.  This has the advantage on old versions of Perl
+that there is no need to load the C module, but it adds a
+significant typing overhead.  This approach is not suitable for
+registry scripts because they would all be stomping on the C
+namespace rather than each staying within the namespace allocated to
+them.  And, besides, the overhead of loading the C module would
+only have to be paid one per Perl interpreter.
 
   multirun2.pl
-  ---
+  
   #!/usr/bin/perl -w
   
   use strict;
@@ -993,14 +1023,14 @@
   
   sub run {
   
-$main::counter = 0;
+$::counter = 0;
   
 increment_counter();
 increment_counter();
   
 sub increment_counter{
-  $main::counter++;
-  print "Counter is equal to $main::counter !\n";
+  $::counter++;
+  print "Counter is equal to $::counter !\n";
 }
   
   } # end of sub run
@@ -1019,10 +1049,11 @@
 and then submit it for your script to process.
 
   multirun3.pl
-  ---
-  #!/u

Re: PATCH perl_reference.pod "Remedies for Inner Subroutines"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Brian McCauley wrote:
> 
> > Here's a _very_ rough first cut at perl_reference.pod.  I haven't even
> > proof-read it yet so it's probably got spelling a and grammar errors
> > but I just want to be sure I'm going in the right direction.
> 
> Thanks Brian. A few comments:
> 
> [...]
> > -  #!/usr/bin/perl -w
> > +  #!/usr/bin/perl
> >   use strict;
> > +  use warnings;
> 
> But that won't work with perl < 5.6.

This is example code being used to illustrate a point.  It is more
appropriate therefore (IMHO) that it reflect best current practice
than that it maintain backward compatability.  Anyone still using Perl
< 5.6 must be used to seeing "use warnings" all over the place and
know that they need to remove it on their system.  Unless, of course,
they are living in total isolation - in which case they'll never see
this document so the point is moot anyhow.
 
> [...]
> > +The simplest of the workarounds is to use package-scoped variables,
> > +declared using C or, on older versions of Perl, the C
> > +pragma.  Note that whereas using C declaration also implicitly
> > +initializes variables to undefined the C declaration does not,
> > +and so you may need to add explicit initialisation.
> > multirun1.pl
> > -  ---
> > -  #!/usr/bin/perl -w
> > +  
> > +  #!/usr/bin/perl
> >   use strict;
> > -  use vars qw($counter);
> > -
> > +  use warnings;  +
> >for (1..3){
> >  print "run: [time $_]\n";
> >  run();
> > @@ -946,7 +953,7 @@
> >   sub run {
> >-$counter = 0;
> > +our $counter = 0;
> 
> I think it would be more clear if all are declared at the top of the
> file,

Declaring variables at the top of the file is, IMNSHO, a bad
programming habit that should be discouraged.  Variables' declaration
and initialisation should be kept together wherever possible.  It
seems more natural.  It aids readibility.  It aids maintainability.  I
have collegues who program in the "declarations go at the top" style.
Their programs almost invariably declare variables that are never then
used.

> just where the 'use vars' declaration was.

Remember that you are looking at the diff file so it seems to you that
I've moved the declaration.  The end-user reader of perl_reference.pod
is not looking at the diff file.  They are comparing multirun.pl and
multirun1.pl.  So from their point of view, by simply replacing "my"
with "our" I'm keeping the declaration in the same place.  If we were
to move the declaration away from the initialisation then I think we'd
have to explain why we did it.  And since I think it's a bad idea I
couldn't do that.

> [...]
> >multirun2.pl
> > -  ---
> > +  
> >#!/usr/bin/perl -w
> >   use strict;
> > @@ -993,14 +1023,14 @@
> >   sub run {
> >-$main::counter = 0;
> > +$::counter = 0;
> 
> what's the gain in doing this? The two are identical and for
> unexperienced perl users $::counter will look totally alien.

That, of course, would depend on the nature of their (in)experience to
date :-).  If they have always seen explicit access to variables in the
root namepace written as $::counter then it is the use of the alias
$main::counter that will look totally alien.

However, given that I go on to refer to root namespace as 'main::'
later on, I suppose it makes sense to be consistant and revert to
using the alias throughout.

> The rest looks good, sans spelling ;)

I'll try to fix that now.

Combined patch follows.

--- perl_reference.pod.orig Thu Aug 14 18:11:11 2003
+++ perl_reference.pod  Fri Nov 14 17:39:20 2003
@@ -863,16 +863,17 @@
 problem, Perl will always alert you.
 
 Given that you have a script that has this problem, what are the ways
-to solve it? There are many of them and we will discuss some of them
-here.
+to solve it? There have been many suggested in the past, and we
+discuss some of them here.
 
 We will use the following code to show the different solutions.
 
   multirun.pl
   ---
-  #!/usr/bin/perl -w
+  #!/usr/bin/perl
   
   use strict;
+  use warnings;
   
   for (1..3){
 print "run: [time $_]\n";
@@ -925,20 +926,27 @@
   Counter is equal to 5 !
   Counter is equal to 6 !
 
-Obviously, the C<$counter> variable is not reinitialized on each
-execution of run(). It retains its value from the previous execution,
-and sub increment_counter() increments that.
-
-One of the workarounds is to use globally declared variables, with the
-C pragma.
+Apparently, the C<$counter> variable is n

Re: PATCH perl_reference.pod "Remedies for Inner Subroutines"

[Brian McCauley]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Brian McCauley wrote:
> >
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> >>
> >>I think it would be more clear if all are declared at the top of the
> >>file,
> >
> > Declaring variables at the top of the file is, IMNSHO, a bad
> > programming habit that should be discouraged.
> 
> Sorry I've missed the word "globals" while typing [...]
> 
> You are talking about the locality rule, which I perfectly agree with
> when it comes to scoped variables.
> 
> However when it comes to globals I tend to disagree with you.

[ snip - Stas correctly anticipates all my arguments in the debate ]

> Agreed.

I used to think I was the only person I knew who could loose a debate
without letting the other guy get a word in. :-)

> Both are now committed and will appear online within the next 6 hours.

Phew!

> Thanks a lot, Brian. Please keep those patches coming (and I promise
> to be build less walls next time).

Will do - but right now I have other fish to fry.

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

should we be using tempnam() ?

[Brian Hirt]

i think that libapreq shouldn't be using tempnam()It frustraiting 
that you can't force tempnam to use a given directory via some sort of 
api.   this makes the TEMP_DIR argument to Apache::Request behave 
inconsistently depending on what environment variables may or may not 
be set.   If you tell an object to put temp files in a certain place, 
you expect it to behave that way.  Also, with the way the current 
ApacheRequest_tmpfile() code is written it's hard to figure out what 
went wrong, because you can't really print the returned name from 
tempnam() making it even harder to track down the fact that tempnam() 
returned a file name in a different one than you asked Apache::Request 
to put it.

tempnam isn't posix, and even the manpage on most linux systems say:

BUGS:
   The precise meaning of ‘appropriate’ is undefined;  it  is  
unspecified
   how  accessibility  of a directory is determined.  Never use 
this func-
   tion. Use mkstemp(3) instead.

I propose that we follow this good advice and use mkstemp instead.   
The change is fairly easy to do, and will certainly avoid headaches 
that i'm sure many of us have run into.

I see that somewhere between apreq1.1 and 1.3 the man page was updated 
to mention this, so i know i'm not the only one who's been bitten by 
this.

any objections if i send in a patch?

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Why MP2

[Dan Brian]

In preparation for the upcoming release of mod_perl2, I'd like to 
prepare a list of reasons why a person/company would look at using 
mod_perl2, specifically, why upgrade from mod_perl1, and converting 
from other technologies.  So with that, what reasons do you have for 
wanting MP2? What prevented you from upgrading before?
What key features are most interesting for you?
How will this help your company?
I guess the silence indicates that mp2 just works for those who moved 
to it and they have unsubscribed from the list since they had no 
questions to ask. :)
libapreq2 is a big reason, in case it hasn't been mentioned.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Slashdot | Help Test mod_perl 2 Release Candidates

[Dan Brian]

Stas> My submission to /.org made it to the Apache section:
Stas>  

Stas> It's about asking to help testing the mp2-RCs.

Oh good.  Another place to post my "use Apache2 considered harmful"
rant...  

Thanks for pointing it out.
Oh good. Another place to read Randal's "use Apache2 considered  
harmful" rant... Thanks for pointing it out.

Is this considered a dead topic, or is there some consideration being  
given to the points he raises?

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

[Dan Brian]

Stas> 99.9% of users do *not* need to use this workaround. So that
Stas> issue is moot if you ask me.
Randal> You keep saying this like you believe it.  In fact, the number 
keeps
Randal> getting closer to 100% each time.

Randal> This is pure, fabricated *fiction*.
For me, this ends up being the sane way to do it, for the same reason I 
install Apache2 into a separate tree. MP2 isn't simply a collection of 
modules. It's an embedded interpreter with pieces that enter the Apache 
tree. I realize this isn't the big issue, but comparisons to other Perl 
"generations" don't quite match for this reason.

Randal> Four out of my five biggest customers *will* need to have both
Randal> modperl1 and modperl2 in the same Perl installation tree on 
their
Randal> development machines, because they'll need to start looking at 
how to
Randal> port their work over, and they won't want to duplicate-install 
all the
Randal> other modules they use into two different Perl installations 
on one
Randal> box.
I may be the exception, but I've done a lot of porting already and 
would never go about it the way you describe. An mp2 install 
(regardless of the solutions at hand) virtually demands a clean Perl 
install (usually on a clean box as well), and duplicate installs of 
dependency modules is typical on any migration project I do in the 
interest of having a sane development environment and duplicate-ability 
(not unlike the separate apache2 tree itself). I then introduce the 
code to be ported into the new environment in much the way that the mp2 
docs describe. Whether users *will* port this way is debatable. But if 
forced, I'd say they're being forced into the preferable scenario 
anyhow.

I agree with Adam's points on the API, but think Stas is correct that 
most users will not have both "generations" installed in the same tree. 
The fact that mp2 is such a radical departure from mp1 is to me an 
argument for porting into a "clean" tree, in much the same way that the 
API incompatibilities are others' argument for a change of namespace. 
:-)

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[Fwd: Re: OT: Free Software as a "Security Hole"]

[brian wheeler]

I forgot to CC the list!

 Forwarded Message 
> From: brian wheeler <[EMAIL PROTECTED]>
> To: Goehring, Chuck, RCI - San Diego
> <[EMAIL PROTECTED]>
> Subject: Re: OT: Free Software as a "Security Hole"
> Date: Wed, 12 Jan 2005 12:28:34 -0500
> On Wed, 2005-01-12 at 09:21 -0800, Goehring, Chuck, RCI - San Diego
> wrote:
> > I post here for lack of a better place.  Sorry in advance to anyone
> > offended.
> > 
> >  
> > 
> > I was speaking to an acquaintance that has a security background and
> > she told me her company prohibits the use of "Free" software because
> > there is no guarantee that there are no "backdoors" in it.
> > 
> >  
> 
> Define 'free'!  If you're talking closed-source free, then yeah, there's
> a distinct possibility that there's backdoors in it.  Heck, even non-
> free closed-source applications have been known to have backdoors in
> them.
> 
> If by 'free' you mean open-source free, then you can guarantee(*) that
> there aren't any backdoors by looking at the source itself.  Even if you
> don't check yourself, you can be relatively sure that there isn't
> because it would come up rather quickly if someone did take a peek at
> the source.
> 
> Brian
> 
> (*) Guaranteed with the exception of the method described in
> "Reflections on Trusting Trust" by Ken Thompson.
> 
> 
> 
> 
-- 
brian wheeler <[EMAIL PROTECTED]>

Mac::Glue and mod_perl

[Brian Dimeler]

Sorry for cross-posting this, but i think it applies to both groups.
I'm trying to write a mod_perl script (for PerlRun) that will present an 
online interface to my Mac OS X Address Book. Using the standard method 
of connecting to the glue (new Mac::Glue 'Address Book') doesn't work; 
the webserver complains about not being able to connect to a window 
server. So, I'm using Remote Apple Events instead (yes, I remembered to 
turn them on in System Preferences):

my $book = new Mac::Glue 'Address Book',
eppc => 'Address Book',
'mac8.local' # hosts both the webserver + addressbook
undef, undef, # uid & pid omitted
'Mac8', 'mypass' # Mac8 is the Admin user & owner of addressbook
This line apparently causes the server child process to exit:
[Fri Jan 14 11:02:40 2005] [notice] child pid 6070 exit signal Bus error 
(10)

However, it works if I run it in a Terminal window (the remainder of the 
script successfully prints out a list of address groups). It even works 
when run in a Terminal window in a different, non-admin user account, as 
long as I include the admin username and pass, as above.

So, does anyone know why it's causing a "bus error" when I try to run it 
in the webserver? Is there a workaround?

Brian

Re: Mac::Glue and mod_perl

[Brian Dimeler]

Well, if you mean restarting the whole computer, no; but I had shut down 
and restarted the webserver a few times, and always gotten the same results.

Martin Moss wrote:
please forgive the really daft question, but have done
a complete server shutdown and restart?
I've come across bus errors before where a complete
server restart made the problem go away and never come
back...
Marty

Re: [OSCon 2005] rfc Open Source Dynamic Data Compression

[Dan Brian]

Any additional suggestions?
I'd cite the fact that places like Google use compression for almost 
all serving. A lot of people don't know that compression is wide-spread 
among the big sites.

Re: [OSCon 2005] rfc Open Source Dynamic Data Compression

[Dan Brian]

I'd cite the fact that places like Google use compression for almost
all serving. A lot of people don't know that compression is 
wide-spread
among the big sites.

Yes Dan, you are right regarding the Google, however to date Google and
Yahoo are rather exceptions than the rule for the content delivery over
the web. It is estimated recently that only some 6% of the top 1000
businesses are compressing their web data when possible. The most 
common
misunderstanding among the IT managers is that it is impossible (or 
very
difficult at least) to compress the dynamically generated content. They
used to choose the dynamic content as an alternative to the compressed
one. I want them to know that they can happily benefit from both of
these goodies, using OS and/or commercial software (and support) when
necessary/appropriate.
But you need to "hook" them. The fact that Google uses compression 
automatically dispels the reasons people might not find your session 
interesting: "compression is not generally compatible with most web 
browsers", "nobody is using compression", etc. My suggestion is that 
you use the fact that some of the top sites do use it successfully to 
create interest. I'd put that right in your session description. To 
emphasize what Stas said, you need to advertise what you are doing. 
That includes hooking their interest with the information that says, 
"the best know something that the rest of you don't", rather than "only 
6% of you are using compression", to which anybody can draw their own 
incorrect conclusions. :-)

Re: //scriptname gets script source on https server on Win32

[Brian Reichert]

On Mon, Feb 07, 2005 at 05:12:18PM +0100, Josef Ender wrote:
> Hello
> 
> I accidentally entered a wrong URL in my browser and instead of the 
> script output I got the script SOURCE back!
> 
> The URL is https://my.servername.local//p_reh/myscriptname.pl
> 
> My mistake was the double / after the server name. Single / works as 
> expected. I can also enter three or more / after the server name and get 
> the script source back.
> 
> This happens on both my development server and the productive server.
> 
> May this be a configuration issue?
> 
> Many thanks for any hints.

I think the issue is your Location block:

> 

no longer matches your typo'ed URL:

> The URL is https://my.servername.local//p_reh/myscriptname.pl

Here, the location is '//p_reh'.  Your handler won't be called.

Consider LocationMatch, or using mod_rewrite to correct requested URLs.

> Josef
> -- 
> Josef Ender, Bitspot AG
> http://www.bitspot.com

-- 
Brian Reichert  <[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large

Re: [OSCon 2005] RFC

[Dan Brian]

If your goal is to convince people to switch to mod_perl, I don't think
this will work very well.  People choose platforms for practical
reasons, the most common being that they already have employees who 
know
that platform.  Relative ease of parsing a form has little to do with
it, especially since that sort of thing is easy on basically every
platform now.
Additionally, comparing mod_perl to PHP/JSP is apples to oranges. If 
anything, people need to understand that mod_perl != CGI != markup 
languages. The more you compare them, the more you get of "mod_perl is 
losing to PHP!", which doesn't make sense, and works against mp. I'd 
like to see less of this and more education about mp and the Apache 
API.

Re: Controlling licensed software? [veering OT]

[Dan Brian]

Thanks for everybody's answers, but as stated in my previous e-mail 
where its
hosted is not negotiable.
Who is it "not negotiable" for?
If the client is the one demanding this, that should be a huge warning 
flag for you.
I realize you already said that this wasn't negotiable, but the reason 
people keep asking is because if "controlling" that software is the top 
priority, a hosted solution is the only thing that will really allow 
it.

Note that there are other reasons to opt for hosting. The primary one 
is cost. Assuming that a motivating factor for protecting your software 
is to prevent lost revenue (which is usually the case), packaged 
software entails much more overhead by way of support and service, the 
need for user documentation, and the difficulty of providing updates 
and troubleshooting problems that arise. Not to mention the need to 
build and maintain a key distribution system to monitor for unlicensed 
copies (if you're doing site licensing). These costs usually far 
outweigh the potential loss of revenue that results from hacking, 
especially on custom contract apps, since not many people will even 
know about the app. (Is it a contract job? Because if so you'll often 
be able to charge for time spent in support. That's probably not the 
case if you chose to distribute the app encrypted; the burden will more 
often be on you to fix problems.)

I realize that's all irrelevant if this is truly not negotiable, and 
that you weren't asking for this kind of input. Just sharing some 
lessons learned from trying to do what you're doing. It's a PITA that 
you'd better have the time to build and support. Pardon the unsolicited 
input. :-)

- Dan

Re: very basic question

[Brian Reichert]

On Thu, Mar 10, 2005 at 02:43:44PM -0600, Jain, Abhay K, ALABS wrote:
> I must apologize if it is not directly relevant to mod-perl.
> I have tried to search google and other places but no luck.
> As I had mentioned I have apache built with mod-perl 2.
> Some old cgi scripts were written in ksh and use of set -x
> produced complete output in browser window under Netscape.
> While Apache seem to ignore stderr. Is there any way
> I can get that output sent to the browser under Apache. Thanks.

If your question can be restated thusly:

How can I cause my ksh scripts to send stderr to stdout?

You can fake it thusly; add this early on in your script:

  exec 2>&1

-- 
Brian Reichert  <[EMAIL PROTECTED]>
55 Crystal Ave. #286Daytime number: (603) 434-6842
Derry NH 03038-1725 USA BSD admin/developer at large

Re: ModPerl performance on BSDs

[Dan Brian]

I've been running mp2 in production on FreeBSD 4.9 without issue for 
about 6 months.

On Mar 14, 2005, at 7:28 AM, William McKee wrote:
On Thu, Mar 10, 2005 at 04:15:38PM -0500, Jonathan Vanasco wrote:
I've been looking mostly at NetBSD, FreeBSD and OpenBSD -- has anyone
had remarkable success or misfortune with modperl2 under these
environments in regards to speed or running?
Hi Jonathan,
I've been running mp1 under FreeBSD 4.9 for several years without
incident (was using Apachetoolkit to compile from scratch). Recently
I've been working on getting mp2 installed under FreeBSD 5.3. Outside 
of
some issues with the tests running inside of a jailed process[1], I've
seen no problems.

I haven't gone into production with mp2 nor have I done any benchmark
comparisons. However, I have noticed that my web pages can sometimes
load faster off the live server that sits halfway across the US vs. my
local Linux server (it's a bit of an unfair comparison as the hardware
on the production server is far more powerful).
HTH,
William
[1] Stas, I'm still working on tracking down the issues. Just been
sidetracked by my work lately.
--
Knowmad Services Inc.
http://www.knowmad.com

Re: Which OS would you choose given a free choice

[Dan Brian]

I'm getting a new server and was planning on going with Fedora Core 3
and plesk. But it was just suggested that I maybe consider FreeBSD and
DA. Never even heard of DA (about to look it up) but being a Mac user
I must know a little about FreeBSD.
So if you had a free choice of OS and control panel what would you go
with and why.
FreeBSD hands down. Stability, security, and speed. The new Linux 
kernel is supposed to be faster by some tricks or some such, but I 
have not had good luck with stability and Linux especially under heavy 
load.  I prefer the FreeBSD philosophy as well.  Linux is, by its very 
nature, chaos incarnate.
FreeBSD is fast, clean, and well-supported. Best server OS I've used.

Re: ticketing solutions

[Dan Brian]

Thanks all; I'll look at the solutions mentioned!
On Apr 22, 2005, at 6:35 PM, Michael Schout wrote:
Dan Brian wrote:
My point was that I don't need a CPAN module to verify hashes. 
Features
could include a mechanism for rotating a key on the servers being
accessed, IP verification ... and other features I can't think of. :-)
Apache::AuthTicket does ip verification.
Not sure what you mean by "key rotation", but AuthTicket allows you to
change the "secret" key in the database periodically.  These are used 
to
verify that the ticket has not been tampered with.  You can have
multiple "secret" keys active at the same time, allowing tickets just
issued on the previous key to expire before you remove it from the 
database.

So, for example, you can issue new "secret" keys every 2 hours, and
delete all secret keys more than 6 hours old at the same time.
AuthTicket will always issue new tickets using the most recent secret 
key.

Not sure if this is the type of thing you are referring to, or if you
are looking for something else :).
Regards,
Michael Schout

ticketing solutions

[Dan Brian]

What are people using to do authentication ticketing from mp? Nothing 
jumps out of CPAN at me, mostly because what I've seen just makes md5's 
out of username/password/expiration. Any recommendations?

Ideally, I'm looking for a solution that might be usable both inside 
and outside mp, over multiple servers. Something like what the Writing 
Apache Modules book describes. Is anybody using that solution? Is it 
decent?

Thanks,
Dan

Re: ticketing solutions

[Dan Brian]

What are people using to do authentication ticketing from mp? Nothing
jumps out of CPAN at me, mostly because what I've seen just makes 
md5's
out of username/password/expiration. Any recommendations?
What were you expecting it to do beyond making a hash for verification?
My point was that I don't need a CPAN module to verify hashes. Features 
could include a mechanism for rotating a key on the servers being 
accessed, IP verification ... and other features I can't think of. :-) 
I didn't see anything on CPAN that does stuff like that, and wondered 
if anybody had had experience with something "standard", or if this was 
typically home-grown, as in my case.

- Dan

Apache2::Reqest

[Dan Brian]

I'm sure this has been discussed in recent days, but I couldn't find 
the thread.

Has anyone succeeded in getting the CVS version of libapreq 
(Apache2::Request) to work with the newer-namespace mp2? I can't get 
the CVS version to compile, but wondered if there was a working 
snapshot anyone was aware of (since libapreq2-2.04-dev is still the 
latest on apache.org), or if my case was isolated. I'll spend more time 
on it if there are people running Apache2::Request without any 
problems.

Thanks,
Dan

Re: Apache2::Reqest

[Dan Brian]

This is for [EMAIL PROTECTED] Also, search those archives... 
they hold more answers :)
It's not usually easy to get help compiling a nightly dev shapshot on 
any list (thus, the "dev snapshot" part). I figured that since the 
newer mp2 leaves this group the CVS ... doh, I mean, SVN :P, version as 
the only option for Request.pm, that I could ask here without a 
redirect. :-)

Try the tarball at http://people.apache.org/~joes  (2.05-dev) a 
developer preview release.
Thanks, will do.

Re: Apache2::Reqest

[Dan Brian]

Yeah, that's what I'm working from. I'll keep at it, thanks Adam.
On Apr 25, 2005, at 2:53 PM, Adam Prime x443 wrote:
On sunday I successfully built the most recent snapshot from SVN.
you can get them here:  http://svn.apache.org/snapshots/apreq/
I didn't exactly test it extensively though, but it built and 
installed fine, and the few things i was using A:R for didn't blow up.

Adam
-Original Message-
From: Dan Brian [mailto:[EMAIL PROTECTED]
Sent: Monday, April 25, 2005 4:49 PM
To: mod_perl Mailing List
Subject: Apache2::Reqest
I'm sure this has been discussed in recent days, but I couldn't find
the thread.
Has anyone succeeded in getting the CVS version of libapreq
(Apache2::Request) to work with the newer-namespace mp2? I can't get
the CVS version to compile, but wondered if there was a working
snapshot anyone was aware of (since libapreq2-2.04-dev is still the
latest on apache.org), or if my case was isolated. I'll spend more time
on it if there are people running Apache2::Request without any
problems.
Thanks,
Dan

[mp1] binmode(STDOUT, ':utf8') fails silently

[Brian Dimeler]

Hi, I'm trying to set binmode(STDOUT, ':utf8') from within a PerlRun script (mod_perl 1.29, apache 
1.3.29, perl 5.8.6), and it's failing (returning undef) without setting $!, as the docs claim it 
should.

I really shouldn't even have to do this at all, since I'm already setting
Content-type: text/html; charset=UTF-8
as the header,

at the start of the document AND, just to be thorough,

in the  section of all my generated HTML. When I invoke my script at the command line, the 
output shows up in the terminal with the proper unicode characters. Málaga is Málaga. But the same 
script, when run by mod_perl, sends "Málaga" to the browser instead. Why is this, and why is it 
that the only obvious workaround, binmode(), has decided to quietly quit? (and yes, I'm setting 
binmode() before using print() for for the first time).

Let me know if that's not enough information. Unfortunately I cannot post the entire script in a 
public forum.

Re: [mp1] binmode(STDOUT, ':utf8') fails silently

[Brian Dimeler]

Ha, nevermind, I figured it out. Turns out that when a param was sent to the script indicating a 
cookie should be changed, it was using CGI's header() function to generate the header rather than my 
header text. Adding -charset => 'UTF-8' to header() did the trick, naturally.

Still curious about binmode(), though; is there some mod_perl-specific reason 
that it would fail?
Brian Dimeler wrote:
Hi, I'm trying to set binmode(STDOUT, ':utf8') from within a PerlRun 
script (mod_perl 1.29, apache 1.3.29, perl 5.8.6), and it's failing 
(returning undef) without setting $!, as the docs claim it should.

I really shouldn't even have to do this at all, since I'm already setting
Content-type: text/html; charset=UTF-8
as the header,

at the start of the document AND, just to be thorough,

in the  section of all my generated HTML. When I invoke my script 
at the command line, the output shows up in the terminal with the proper 
unicode characters. Málaga is Málaga. But the same script, when run by 
mod_perl, sends "Málaga" to the browser instead. Why is this, and why 
is it that the only obvious workaround, binmode(), has decided to 
quietly quit? (and yes, I'm setting binmode() before using print() for 
for the first time).

Let me know if that's not enough information. Unfortunately I cannot 
post the entire script in a public forum.

[mp2] PerlSetEnv Issue

[Brian Becker]

Title: [mp2] PerlSetEnv Issue






Quick background - this is mod perl 2 version 2.0.0 on Apache 2 prefork on Solaris 10


Issue - when I access a file in folder "a" the variable FOO gets set using PerlSetEnv (see code below).  When I access a file (script file) in a different folder (lets say b) I can still see FOO defined in the environment on some requests (assuming this request is the same process that handled the a folder request - if I refresh enough times FOO will bet set on all requests).  The trick is the file accessed in folder a is just plain html.  To make it more interesting if I do access a script in folder a then the FOO variable is not set when access folder b. I would assume that the variable FOO should only be set in the environment when I am in folder a.

What am I missing?


Relavent files:


Portion of ssl.conf


Include conf/jsite/A_SECURE.conf


All of A_SECURE.conf




  PerlSetEnv FOO "BAR"

  AuthName "A"

  AuthType A::Authenticate2

  PerlAuthenHandler A::Authenticate2->verifyUser

  require valid-user




All of Authenticte2


package A::Authenticate2;

use strict;

sub verifyUser($$)

{

  use Apache2::Const qw{OK};

  return OK;

}

1;


Startup.pl


$ENV{MOD_PERL} or die "not running under mod_perl!";

use base qw(ModPerl::Registry);

use A::Authenticate2;

1; #return true value


Brian Becker

seg faults on RHEL 3

[Brian Duggan]

Hi Modperlers,

I saw some recent posts with problems like this, but I didn't see
a solution.

I'm migrating a large mod_perl application from a machine with redhat
7.3, apache-1.3.27, mod_perl-1.27, and perl 5.6.1 to a machine with
Redhat Enterprise Linux AS 3, mod_perl-1.29, apache-1.33, and perl 5.8.0.

Things run well on the former setup, but I'm seeing seg faults on
the latter.

I've built apache and mod_perl as follows :

$ tar xzvf apache_1.3.33.tar.gz
$ tar xzvf mod_perl-1.29.tar.gz
$ cd mod_perl-1.29 
$ perl Makefile.PL APACHE_SRC=../apache_1.3.33/src \
DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 \
PERL_DEBUG=1 APACI_ARGS='--without-execstrip'
$ make
$ cd ../apache_1.3.33
$ export CC='gcc -g'
$ ./configure --without-execstrip \
--prefix=/usr/local/apache \
--activate-module=src/modules/perl/libperl.a \
--enable-module=so
$ make
$ cd ../mod_perl-1.29
$ make test
$ sudo make install
$ cd ../apache-1.3.33
$ sudo make install

I then start the server via

$ cd /usr/local/apache/bin
$ ./httpd -X

and send a sequence of requests to the application, after which I get

Segmentation fault (core dumped)

gdb shows me :

$ gdb ./httpd core.18078
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
[..]

1720for (i = 0, j = 0; s[i] != '\0'; i++)
(gdb) where
#0  0x080d0a62 in ap_escape_html (p=0x8b01b54, s=0x0) at util.c:1720
#1  0x080c9ef7 in ap_send_error_response (r=0x8b01b7c, recursive_error=0) 
at http_protocol.c:2915
#2  0x080cbf65 in ap_die (type=302, r=0x8b01b7c) at http_request.c:1138
#3  0x080cc555 in process_request_internal (r=0x8b01b7c) at 
http_request.c:1299
#4  0x080cc59a in ap_process_request (r=0x8b01b7c) at http_request.c:1314
#5  0x080c36fd in child_main (child_num_arg=0) at http_main.c:4786
#6  0x080c389d in make_child (s=0x8106f14, slot=0, now=1119435820) at 
http_main.c:4901
#7  0x080c3a03 in startup_children (number_to_start=8) at http_main.c:4983
#8  0x080c40ba in standalone_main (argc=2, argv=0xbfff9f84) at 
http_main.c:5315
#9  0x080c48d8 in main (argc=2, argv=0xbfff9f84) at http_main.c:5657

Any suggestions for fixes or how I might diagnose this further
would be appreciated.

Brian

Re: seg faults on RHEL 3

[Brian Duggan]

On Wednesday, June 22, Joel Bernstein wrote: 
> Try seeing if you can remove unicode from the equation. RH Perl often
> has odd utf-8 settings. Build a non-utf8 perl and link mod_perl with
> that?
> 
> Also, it may be as simple as removing .utf8 from $LANG. A lot of RH
> boxes I've seen set LANG=en_GB.UTF8 - get rid of the .UTF8 and stuff
> works...

Great, thanks.

I got the latest RHEL 3 perl source rpm (perl-5.8.0-89.10), set LC_ALL=C,
LANG=en_US, rebuilt perl, then rebuilt apache/mod_perl as before, and
no more seg faults.  Yay.

-Brian

RE: [mp2] PerlSetEnv Issue

[Brian Becker]

I'm sorry to say this did not fix the problem - bit I have managed to
hack up some of the code to get it to unset the environment.  I really
didn't know what I was doing so there is probably a better way (and I
don't really know the internals of mod_perl so I may have screwed other
things up)...but here is my attempt at an explanation.

Your change was made to modperl_env_request_populate which is called
from the response handler (modperl_response_handler and
modperl_response_handler_cgi) which I assume would be to process dynamic
pages.  Since this request is on a standard html page
modperl_env_request_populate was not getting called.  

Instead it was using modperl_env_configure_request_dir (this was the one
setting my particular variable, however it is possible that
modperl_env_configure_request_srv could have same issue).  I applied
your same modperl_config_req_cleanup_register to those two functions and
that still did not solve the problem (left these changes in the
functions but may not be needed?).  

So I tried working backwords figuring out where the environemnt gets
unset (modperl_env_request_unpopulate) and the call to that in
modperl_config.c is wrapped in if(MpReqSETUP_ENV) which never gets set
when just calling env_conf...dir and env_conf...srv.  

My solution was to change the if logic to include MpReqPERL_SET_ENV_DIR
and MpReqPERL_SET_ENV_SRV when calling modperl_env_request_unpopulate.  

Final snag was that inside modperl_env_request_unpopulate there is
another check to MpReqSETUP_ENV - so before I called
modperl_env_request_unpopulate I set MpReqSETUP_ENV_On.

Brian

-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 21, 2005 8:38 AM
To: Brian Becker
Cc: modperl@perl.apache.org
Subject: Re: [mp2] PerlSetEnv Issue

ugh, another message lost to the email-eating tree...

reposting.


> What am I missing?

that there was a bug?  :)

ok, here's what I think is going on.  we only register the %ENV cleanup
function when a Perl*Handler runs for a given request but in your case
that
doesn't happen by design, so %ENV is set up but never cleaned up and
%ENV
propagates forever.

I think this patch ought to do the trick.  the only problem is that I
can't
seem to reproduce your bug in our test environment, probably because
there
is _always_ some mod_perl handler running in the base config, even if I
create a separate virtual host.  nevertheless, give it a whirl and
report
back if it seems to fix your issue.

oh, and sorry for the slow turnaround and overall silence :)

--Geoff

Re: [mp2] Small "bug" / feature request / documentation in make test needed

[Brian Huxtable]

Kevin A. McGrail wrote:


still waiting for server to warm up:

.
the server is down, giving up after 121 secs
[  error] failed to start server! (please examine t/logs/error_log)
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++

 

Try running 'make test' immediately after you get this hang.  I had a 
similar issue with apache 2.0.54/mod_perl 2.0.0 (RC5/RC6/Release) on 
CentOS 4 with no other Apache installed/running.  I wasn't able to 
figure out why the first test run hangs (everything looks like it should 
be working).  The second test run has no problems.


Brian

Re: trying to build a statically-linked apache2/mod_perl2

[Brian Huxtable]

Danny Thomas wrote:


I'm not sure whether it is a real bug, not properly documented or whether
I'm just being particularly thick, but I can't seem to build a statically-
linked apache2/mod_perl2

 


Danny,

FWIW, I used the following options to build static mod_perl/Apache2 on 
CentOS 4 (httpd 2.0.54/mp 2.0.0):


> perl Makefile.PL MP_USE_STATIC=1 MP_COMPAT_1X=1 MP_GENERATE_XS=1 \
 MP_AP_PREFIX=/usr1/products/apache2/httpd-2.0.54 \
 MP_AP_CONFIGURE="--prefix=/opt/apache2 --with-mpm=prefork \
 --enable-ssl --enable-unique-id"
> make
> make test
> make test (yes, twice)
> make install

It builds and installs fine.  Then I add /opt/apache2/bin to my path to 
install libapreq (I think it needs apxs):


> perl -MCPAN -e shell
> install Apache2::Request

The CPAN install warns about a few of the later tests but I haven't 
noticed any problems with the few functions I use.


Brian

Re: trying to build a statically-linked apache2/mod_perl2

[Brian Huxtable]

Danny Thomas wrote:


I would be grateful if people could try the documented approach but
 1) as non-root (which is always good when building software because
it makes it unlikely stuff gets accidentally installed in wrong location)
 2) with a fairly clean file-system. I did a rm -rf of the http
and mod_perl directories between each attempt. Also had an
empty install directory, again in case previous attempts left
something around confounding the situation.
I did not go to the extreme of cleaning out and re-installing

between each ATTEMPT
 3) trying to install in a specified location, eg with --prefix

Brian Huxtable's posting suggests the documented method worked for him
though he did not indicate that had been done with a clean file-system.
I did try adding the "MP_COMPAT_1X=1 MP_GENERATE_XS=1" he used, but
it still did not work for me.
 


Danny,

The first installation I did using this method was a new install of 
CentOS 4 (without Apache2/mod_perl RPMs installed).  It was fairly 
clean.  I upgraded CGI and Compress::Zlib modules per the instructions.  
The 2.0RC5 build had no other Apache install to contend with.


My method was very similar to your second attempt with the following 
exceptions:


- my tar doesn't have a --bunzip2 option (used -j)
- I downloaded mod_perl from 
/http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz/ and didn't use 
the CPAN method

- I had a few more options (as you've seen)
- I installed as root

There was an issue with an installation directory in the Makefile (there 
was a patch posted on this list earlier that cleaned it up) and I had to 
run 'make test' twice; but for the most part it worked well.


I built 2.0RC6 and 2.0.0 over the installed Apache2/static mod_perl with 
similar results as above.  I dump the httpd-2.0.54 and mod_perl-2.0.x 
directories before each build and untar again.


After your second post on this subject I went back to my sources and 
tried to make/make test as a less privileged user and that seemed to 
work well (only needed one run of 'make test'!).


About the only thing I can think to try is to grab the mod_perl source 
from the URL above instead of using the CPAN module.  I'm not familiar 
with FreeBSD and the jail setups so I don't know if there is anything 
that needs to be done to support that.


Brian

Re: mod_perl variables

[Dan Brian]

On Aug 10, 2005, at 11:07 AM, Boysenberry Payne wrote:


This message contains information that is confidential
and proprietary to Humaniteque and / or its affiliates.
It is intended only for the recipient named and for
the express purpose(s) described therein.
Any other use is prohibited.


Please ditch the signature, Boysenberry. Thank you.

Re: [Fwd: ApacheCon US 2005 CFP slightly extended]

[Dan Brian]

By the way, Stas deserves some severe kudos for these materials. They  
were the best tutorial materials at OSCON, reading like a well- 
written book. You could stand up and read the whole thing without any  
preparation.


But, don't do that. :-)

Thanks Stas!

- Dan

mod_perl 1.29: send_fh(): result status?

[Brian Gorby]

I'm programming a web application that limits the number of downloads 
for clients on certain files:


...
unless ( $r->header_only ) {
  $r->send_fd($fh);
  $self->record_download($user_id, $file_id);
}
close($fh);

I'd like to be able to have some sort of confirmation that the file was 
sent / received in entirety before recording the download; if the 
download times out for whatever reason for the client, the download will 
not be recorded.


Is this something that's possible in general? with mod_perl?

-Brian

Re: mod_perl 1.29: send_fh(): result status?

[Brian Gorby]

Brian Gorby wrote:

Is this something that's possible in general? with mod_perl?


Found it. Apache::Connection->aborted() is just what I needed.

-Brian

Re: Apache2::Cookie blank value bug?

[Dan Brian]

On Aug 24, 2005, at 3:40 PM, Ted wrote:


Blank value in cookie causes server to die with a Segmentation Fault.


For me, too.

Apache::Constants qw(HTTP_OK)

[Brian Duggan]

Hi modperl,

The SYNOPSIS for Apache::TestRequest says :

use Apache::Test qw(ok have_lwp);
use Apache::TestRequest qw(GET POST);
use Apache::Constants qw(HTTP_OK);

plan tests => 1, have_lwp;

my $res = GET '/test.html';
ok $res->code == HTTP_OK, "Request is ok";

But, this seems not to work for me since HTTP_OK doesn't 
get properly exported by Apache::Constants unless I'm running 
from within a response handler.

$ perl -MApache::Constants=HTTP_OK -e 'print HTTP_OK'
Undefined subroutine &Apache::Constants::HTTP_OK called at -e line 1.

What am I missing?

-Brian

Re: mod_perl, mysql, and set names

[Brian Phillips]

You could also just make sure something like the following is in a my.cnf file (on my system it's /var/lib/mysql/my.cnf):
[perl]
default-character-set=utf8

And then when you connect, you'll need to specify two options to DBI to make DBD::mysql read from the option file:
DBI->connect( 'dbi:mysql:localhost;mysql_read_default_group=perl;mysql_read_default_file=/var/lib/mysql/my.cnf');

In playing with it a bit, only the first option (the default_group) is
necessary but I'm not sure if that's intentional behavior (it's not
documented as such).

Having this information embedded in your dsn or connection options will
allow you to use Apache::DBI (since presumably it uses the same options
you passed in when you originally connected).

BrianOn 11/4/05, Philip M. Gollucci <[EMAIL PROTECTED]> wrote:
> But I can't help feeling I'm redesigning the wheel here - would I have the same> problem if I used Apache::DBI? Are there other easier ways to handle this?IIRC, Apache::DBI just makes the connection persistant.  It could still
time out and disconnect if a handle in the handle cache isn't used.  AKAthe MySQL Morning bug.It would likely make it more infrequent though.I never remember which, but DBD and/or DBI document turning on the
auto_reconnect attribute.--END What doesn't kill us can only make us stronger. Nothing is impossible.
Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198Consultant / http://p6m7g8.net/Resume/Senior Developer / Liquidity Services, Inc.
   http://www.liquidityservicesinc.comhttp://www.liquidation.comhttp://www.uksurplus.com
http://www.govliquidation.comhttp://www.gowholesale.com

@CustomLog and @LogFormat directives

[Brian Phillips]

I've been attempting to turn my httpd.conf file into a perl
module.  Overall, it seems pretty straightforward but I've had
trouble with the CustomLog and LogFormat directives.  I can get
them to work as scalars but not as arrays.  For instance, the
following works (it took me awhile to get anything to work):

$LogFormat = '"%h %l %u %t \\"%r\\" %>s %b \\"%{Referer}i\\" \\"%{User-Agent}i\\"" combined';

$CustomLog = 'logs/access_log combined';


But when I attempt to specify multiple values for either of those
directives, I either get a Apache error on startup or nothing gets
written to the logs.

Even simply just changing the LogFormat to an array and keeping the rest of the data the same doesn't work:

@LogFormat = ('"%h %l %u %t \\"%r\\" %>s %b \\"%{Referer}i\\" \\"%{User-Agent}i\\"" combined');

$CustomLog = 'logs/access_log combined';

In this instance, the word "combined" gets written to the access log
which seems to indicate the @LogFormat isn't getting parsed
correctly.  I've tried changing the element to an array ref but
that doesn't help either:


@LogFormat = (['"%h %l %u %t \\"%r\\" %>s %b \\"%{Referer}i\\" \\"%{User-Agent}i\\""', 'combined']);


$CustomLog = 'logs/access_log combined';



Playing with the quoting hasn't seemed to get me anywhere either (the
following results in ": LogFormat takes 1-2 arguments, a
log format string (see docs) and an optional format name."):



@LogFormat = (['%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"', 'combined']);



$CustomLog = 'logs/access_log combined';




Even using Apache->httpd_conf with the exact line from our regular httpd.conf hasn't worked:

    Apache->httpd_conf(q{
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

    });
    our $CustomLog = 'logs/access_log combined';


I'd like to be able to do something like this:

    @LogFormat = (
    '"%h %l %u %t \\"%r\\" %>s %b \\"%{Referer}i\\" \\"%{User-Agent}i\\"" combined'],

    '"%h %l %u %t \\"%r\\" %>s %b" common',
    '"%{Referer}i -> %U" referer',
    '%{User-agent}i agent',
    );

    @CustomLog = (
    ['logs/access_log', 'common'],
    ['logs/referer_log', 'referer'],
    ['logs/agent_log', 'agent'],
    );



Does anyone have a working example of how to use multiple values for these specific directives?

Thanks in advance,
Brian

Re: @CustomLog and @LogFormat directives

[Brian Phillips]

Unfortunately I'm not using Apache2... :-( 



Any ideas for Apache 1.3?On 10 Nov 2005 11:37:50 -0800, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>> "Brian" == Brian Phillips <
[EMAIL PROTECTED]> writes:Brian> Even using Apache->httpd_conf with the exact line from our regularBrian> httpd.conf hasn't worked:Brian> Apache-> httpd_conf(q{
Brian>  LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""Brian> combinedBrian>  });Brian>  our $CustomLog = 'logs/access_log combined';
Brian> Brian> Does anyone have a working example of how to use multiple values for theseBrian> specific directives?This is probably an example of the bug I reported earlier, and to which a
fix has been posted, but not tested.  However, my workaround looks like this:  use Apache2::PerlSections;BEGIN {  *Apache2::PerlSections::dump_special = sub {my($self, @data) = @_;
$self->add_config($_) for @data;  }}  And that works for me to enable PerlSections to actually *work*.Apparently, there are no tests for that. :(--Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> 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!

[mp1] Apache::PerlRun errs on backtick operator

[Brian Dimeler]

I'm moving my all of my PerlRun scripts to a new webserver, and have discovered that a few modules 
which invoke system commands via the backtick `` operator are failing to compile when they reach 
those commands. This doesn't happen when I run the scripts from the command line; only when run as 
mod_perl scripts.


I've tried numerous commands with a test perl script and they all get the same error: "No such file 
or directory." Thing is, these are simple commands, like `date`, `pwd` and `ls`, sans arguments, so 
what on earth could that error mean?

Re: child process exited with status 3221225477 -- Restarting

[Brian Reichert]

On Thu, Feb 02, 2006 at 03:18:41PM +0100, Henrik Schak Hansen wrote:
> 
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
> 
> Every now and then (random) mod_perl/apache restarts for no apparent
> reason, with 
> "child process exited with status 3221225477 -- Restarting."

See perlvar(1) for a discussion on how to unpeel that into separate parts;
see $?.

Dunno what that might mean under Windows, though...

-- 
Brian Reichert  <[EMAIL PROTECTED]>
55 Crystal Ave. #286Daytime number: (603) 434-6842
Derry NH 03038-1725 USA BSD admin/developer at large

Re: [OT] modperl vs. Ruby

[Danny Brian]

On Feb 24, 2006, at 4:00 PM, Alan Bailward wrote:

It probably really comes down to personal preference and  
familiarity FWIW.


And marketing.

[mp1] CGI upload_hook with PerlRun

[Brian Dimeler]

Hi,

 I have a file-uploading script from a server running perl scripts as plain old CGI, and I'm trying 
to port it to an Apache 1.3 server using PerlRun. Everything works except CGI's upload hook. On the 
vanilla CGI server, the upload hook routine is called repeatedly during the upload process, but 
under mod_perl, nothing happens until the file is finished uploading, at which point the upload hook 
appears to be called a zillion times in the space of a second or two (based on the logs).


Could anyone shed some light on why this behavior is different under mod_perl, and if there's a way 
around it? CGI.pm's docs mention an "Apache UPLOAD_HOOK" feature, but I don't know how I would go 
about incorporating that in a PerlRun script as it uses Apache::Request objects..


For reference, I'm running:
 Mac OS X Server 10.4.5 with original built-in versions of perl (5.8.6), Apache (1.3.29), mod_perl 
and CGI.pm (3.05)


Snip from the script in question:

use CGI;
my $uploaddir = '/path/to/uploads/';
my $data = {};
my $query = new CGI sub {
my ($file, $b, $bytes, $d) = @_;
open my $fh, ">$uploaddir$file.uploadCount";
$$d{$file} = $bytes;
print $fh $bytes;
close $fh
print STDERR localtime() . ": upload hook called - $file, $bytes\n"
}, $data;
unlink "$uploaddir$_.uploadCount" for keys %$data;
# all file copying, form processing and output goes below here

segv issue

[Danny Brian]

I'm wondering if anyone can shed light on the circumstances of a segv  
with httpd2.2.2/mod_perl2.0.2. The module being loaded in  
Sleepycat::DbXml (part of the Sleepycat BDB XML distribution). The  
segfault occurs upon Apache startup with either:


  a) The module is loaded as use Sleepycat::DbXml;
  b) The module is loaded with "use" from any other imported Perl  
module


The segfault does *not* occur when:

  a) The module is loaded with PerlModule Sleepycat::DbXml
  b) The module is loaded with "require" from any other imported  
Perl module


I have tested the problem with a barebones build of httpd on FreeBSD  
5 and 6. I do not believe any different library versions are shared  
between this module and Apache or other loaded Apache modules; symbol  
conflicts were my first thought.


Thanks for any ideas,
Danny

Re: segv issue

[Danny Brian]

I have tested the problem with a barebones build of httpd on  
FreeBSD 5 and 6. I do not believe any different library versions  
are shared between this module and Apache or other loaded Apache  
modules; symbol conflicts were my first thought.


No idea why... but I've definitely encountered that exact situation  
before with a few different modules on osx/freebsd.   I just never  
had time to explore.


It's definitely a symptom of the bootstrapping of XS. But it doesn't  
happen under MP1, just MP2.

Re: segv issue

[Dan Brian]

I have tested the problem with a barebones build of httpd on  
FreeBSD 5 and 6. I do not believe any different library versions  
are shared between this module and Apache or other loaded Apache  
modules; symbol conflicts were my first thought.


No idea why... but I've definitely encountered that exact  
situation before with a few different modules on osx/freebsd.   I  
just never had time to explore.


It's definitely a symptom of the bootstrapping of XS. But it  
doesn't happen under MP1, just MP2.


I retract this. It happens on both mp1 and mp2.

Re: I swear, [idiots unsubscribe help request]

[Danny Brian]

P.P.S
  You might try being nicer to volunteers you are trying to help  
you and not call them idiots.


I suspect the subject was meant to be read, "idiot's unsubscribe help  
request", and not, "help me unsubscribe, idiots!"


- Danny