modperl

Re: mod_perl causing Apache Segmentation fault

2012-02-17T06:29:00.000-08:00

On 17 Feb 2012, at 14:03, Mauritz Hansen wrote:

> #17 0x000000000046432b in invoke_cmd (cmd=0x5b9880,
> parms=0x7fffffffe770, mconfig=0x844728, args=0x89b7d8 "use lib qw(
> /usr/local/apache2/virtualhosts/api.nwwi.nl /httpdocs/lib/ );\n") at
> config.c:757

This appears to be what it's trying to do. Take that directive
out and see what happens?

mod_perl causing Apache Segmentation fault

2012-02-17T06:03:00.000-08:00

NOTE: I posted have posted this question on Stackoverflow and have not yet
received an answer.
*********************************************

My mod_perl appears to cause a segmentation fault in my Apache. 'httpd -X'
simply gives 'Segmentation Fault' and my server does not start.

I am using Apache 2.2.22, mod_perl 2.0.5, CentOS 5.7 x86_64. I built
mod_perl and Apache together from source with the following command:

perl5.12.4 Makefile.PL MP_USE_STATIC=1
MP_AP_PREFIX=/usr/local/src/httpd-2.2.22
MP_AP_CONFIGURE="--with-mpm=prefork --enable-rewrite"

What I have tried so far:

Point httpd.conf to my Catalyst application. Result: Apache dies with
'Segmentation fault'.
Point httpd.conf to a simple application created with catalyst.pl.
Apache dies with 'Segmentation fault'.
Point httpd.conf to a static site. Result: Apache starts fine and
serves the website.

I tried the following:

gdb -c /usr/local/apache2/bin/httpd

Program received signal SIGSEGV, Segmentation fault.

0x00002aaab0db0270 in ?? ()

(gdb) bt

#0 0x00002aaab0db0270 in ?? ()

#1 0x00000000004c9d24 in Perl_newUNOP ()

#2 0x00000000004fb6a6 in Perl_yyparse ()

#3 0x0000000000557c57 in S_doeval ()

#4 0x0000000000559546 in Perl_pp_require ()

#5 0x0000000000528bae in Perl_runops_standard ()

#6 0x00000000004d5d2f in Perl_eval_sv ()

#7 0x0000000000478425 in modperl_require_module ()

#8 0x0000000000472283 in modperl_boot ()

#9 0x00000000005529cc in Perl_leave_scope ()

#10 0x00000000004d87eb in S_parse_body ()

#11 0x00000000004d927c in perl_parse ()

#12 0x0000000000471d2a in modperl_startup ()

#13 0x0000000000471cbc in modperl_startup ()

#14 0x000000000047202e in modperl_init ()

#15 0x000000000047215f in modperl_hook_init ()

#16 0x00000000004737bb in modperl_cmd_perldo ()

#17 0x000000000046432b in invoke_cmd (cmd=0x5b9880,
parms=0x7fffffffe770, mconfig=0x844728, args=0x89b7d8 "use lib qw(
/usr/local/apache2/virtualhosts/api.nwwi.nl /httpdocs/lib/ );\n") at
config.c:757

#18 0x0000000000465865 in ap_walk_config_sub (current=0x89b828,
parms=0x7fffffffe770, section_vector=0x830c18) at config.c:1163

#19 0x0000000000465914 in ap_walk_config (current=0x89b828,
parms=0x7fffffffe770, section_vector=0x830c18) at config.c:1196

#20 0x0000000000466cb9 in ap_process_config_tree (s=0x82de10,
conftree=0x86fcb0, p=0x822138, ptemp=0x82a178) at config.c:1765

#21 0x0000000000449512 in main (argc=2, argv=0x7fffffffe9e8) at
main.c:723

I have no idea how to read and interpret this. Can somebody help and point
me in a direction to further troubleshoot this?

Re: disabling directives in .htaccess files

2012-02-15T17:23:00.000-08:00

On Sat, Feb 11, 2012 at 7:23 PM, Aaron Knister <aaronk@umbc.edu> wrote:
> I need to allow htaccess files for users to be able to customize their
> websites as required (specify authentication/authorization methods, rewrite
> rules, mime types, custom handlers etc.). I wish I could turn them off but I
> fear that it's not feasible for me to do so.

Well, here's my idea. I'd turn off htaccess and provide an alternate
way for people to configure those things. That might just be a file
called user.conf or something that you parse yourself and set conf
directives with. Not exactly simple, but if security is the issue I
usually like a list of things you can do better than a list of things
you can't.

- Perrin

Re: Apache Children Stuck on futex

2012-02-13T08:00:00.001-08:00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Sorry about the grave-dig, but as this is still an issue.)

I'm still coming up to speed on the inner working of mod_perl (I've
never played in it before), but Max asked me to take a look at the futex
problem, so I thought I'd try to pick up where it was left off and
hopefully get this fixed.

My system:
Linux modperl 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
Apache/2.2.20 (build from Ubuntu source packages with debug symbols)
mod_perl 2.0.5 (build from Ubuntu source packages with debug symbols)

Torsten Förtsch wrote:

> Can you install the symbol tables for your modperl and perhaps check the
> values of *tipool in the core? I think it is
>
> tipool->size == tipool->in_use == tipool->cfg->max

3, 0, and 5 respectively for all threads blocked on
modperl_tipool_wait(tipool).

> BTW, there are IMHO many points about the tipool implementation that
can be improved.
> Why do we use these lists? Wouldn't it be better to allocated an array
of tipool->cfg->max
> pointers? Or perhaps an apr_hash_t in pconf?

As I don't understand the inner workings yet, I don't know, and hope
figure out.

Greg
P.S. Since it's been a while, here is the archived thread:
http://www.gossamer-threads.com/lists/modperl/modperl/103558#103558
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk85M4QACgkQF1oFywYE3z7GvACfSZ2uU7Vfnn60rRlEJHBNLkVk
nL8AoO7bz5sEM/B7OSDdZhgxbvi1j7gT
=NCp+
-----END PGP SIGNATURE-----

Re: disabling directives in .htaccess files

2012-02-13T04:58:00.000-08:00

Hi Tuomo,

I don't mean 80,000 virtual hosts. I have over 80k unix accounts for which content is being served via mod_userdir. And I consider each one it's own "site". It's critical to the environment that users be prevented from specifying handlers in htaccess files in part exactly for the reasons you specified. The other issue is the potential for suexec abuse. I only have one perl access handler I need to use and it has no global variables.

Sent from my iPhone

On Feb 13, 2012, at 3:55 AM, Tuomo Salo <Tuomo.Salo@cybercom.com> wrote:

> On Fri, Feb 10, 2012 at 08:50:21AM -0500, Aaron Knister wrote:
>
>> this is a personal web hosting setup for 80,000+ individual sites (think mod_userdir).
>
> I might be missing something, but does this not seem to be inherently
> impossible? 80 kilosites sharing a perl interpreter that persists any
> global variables from one request to another would seem to create any
> number of problems that are near-impossible to debug, the typical ones
> being name space collisions and module version conflicts.
>
> -Tuomo

Re: disabling directives in .htaccess files

2012-02-13T00:55:00.000-08:00

On Fri, Feb 10, 2012 at 08:50:21AM -0500, Aaron Knister wrote:

> this is a personal web hosting setup for 80,000+ individual sites (think mod_userdir).

I might be missing something, but does this not seem to be inherently
impossible? 80 kilosites sharing a perl interpreter that persists any
global variables from one request to another would seem to create any
number of problems that are near-impossible to debug, the typical ones
being name space collisions and module version conflicts.

-Tuomo

Re: disabling directives in .htaccess files

2012-02-11T16:23:00.001-08:00

Hi Perrin,

I need to allow htaccess files for users to be able to customize their websites as required (specify authentication/authorization methods, rewrite rules, mime types, custom handlers etc.). I wish I could turn them off but I fear that it's not feasible for me to do so.

Specifically, the directives I would like to prevent are:

Perl*Handler
Perl*Var
Perl*Env
PerlOptions
PerlModule
PerlRequire
<Perl>

Pretty much any directive defined with the MP_CMD_DIR_* macros.

-Aaron

On Sat, Feb 11, 2012 at 6:29 PM, Perrin Harkins <perrin@elem.com> wrote:

On Fri, Feb 10, 2012 at 6:46 AM, Aaron Knister <aaronk@umbc.edu> wrote:
> I'm using mod_perl in a shared hosting environment for some server-side
> configuration bits. All dynamic content for the users runs through SuEXEC,
> however this obviously doesn't help in the case of mod_perl so I would like
> to prevent users from specifying any handlers or other potentially
> undesirable mod_perl options/directives in their .htaccess files.

Is it necessary to allow htaccess files? If there's something that
you want people to be able to specify, maybe you can use a custom conf
file for it instead of allowing htaccess.

If it is necessary, can you provide an example of an htaccess
directive that you're trying to prevent?

- Perrin

--
Aaron Knister
Systems Administrator
Division of Information Technology
University of Maryland, Baltimore County
aaronk@umbc.edu

Re: disabling directives in .htaccess files

2012-02-11T15:29:00.001-08:00

On Fri, Feb 10, 2012 at 6:46 AM, Aaron Knister <aaronk@umbc.edu> wrote:
> I'm using mod_perl in a shared hosting environment for some server-side
> configuration bits. All dynamic content for the users runs through SuEXEC,
> however this obviously doesn't help in the case of mod_perl so I would like
> to prevent users from specifying any handlers or other potentially
> undesirable mod_perl options/directives in their .htaccess files.

Is it necessary to allow htaccess files? If there's something that
you want people to be able to specify, maybe you can use a custom conf
file for it instead of allowing htaccess.

If it is necessary, can you provide an example of an htaccess
directive that you're trying to prevent?

- Perrin

Re: ModPerl::Util::exit: (120000) exit was called

2012-02-11T10:33:00.001-08:00

*** Disclosure: Haven't encountered this issue but was lacking a Sunday
morning puzzle so take this for what it's worth.

You're right about the exit() documentation.

I tried to recreate your problem and could only come up with a similar
situation if I used exit() inside an eval block like so:

eval{
if ( $failing_condition ) {
exit();
}
};

if ( $@ ) {
carp($@);
}

That gives a similar error message to yours in the error log. That's
because exit() here is inside the eval block and it is trapped and won't
be carried out. Code after the exit() is still executed.

In the above code, you can fix it by adding another exit() like so:

if ( $@ ) {
carp($@);
exit(); # Works as it's outside an eval block
}

This'll work as expected. A more in depth explanation and better code to
check errors is here:

http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_

On 2/11/2012 6:18 AM, James Andrews wrote:
> Afternoon mod_perl'ers,
>
> I am a Perl programmer of 7 years, however this is the first time I have
> come to using mod_perl. In a nutshell I am getting this error:
>
> ModPerl::Util::exit: (120000) exit was called at /path/to/script.cgi
>
> I have a clean install of Ubuntu 10.04, apache2, libapache2-mod-perl2
> and the following in apache2.conf:
>
> <Files ~ "\.(pl|cgi)$">
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> Options +ExecCGI
> PerlSendHeader On
> </Files>
>
> In my scripts I call exit(); everywhere. However according to the
> mod_perl website, this shouldn't be a problem (correct me if I am wrong).
>
> I have done the same setup on 3 different servers using the same OS and
> yield the same error each time!
>
> If anyone has any ideas please let me know. I have searched the internet
> everywhere for solution, however this problem doesn't seem to be of large.
>
> Kind regards,
>
> James Andrews
>
>
>
>

ModPerl::Util::exit: (120000) exit was called

2012-02-11T06:18:00.000-08:00

Afternoon mod_perl'ers,

I am a Perl programmer of 7 years, however this is the first time I have
come to using mod_perl. In a nutshell I am getting this error:

ModPerl::Util::exit: (120000) exit was called at /path/to/script.cgi

I have a clean install of Ubuntu 10.04, apache2, libapache2-mod-perl2 and the following in apache2.conf:

<Files ~ "\.(pl|cgi)$">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlSendHeader On
</Files>

In my scripts I call exit(); everywhere. However according to the mod_perl website, this shouldn't be a problem (correct me if I am wrong).

I have done the same setup on 3 different servers using the same OS and yield the same error each time!

If anyone has any ideas please let me know. I have searched the internet everywhere for solution, however this problem doesn't seem to be of large.

Kind regards,

James Andrews

Re: disabling directives in .htaccess files

2012-02-10T09:16:00.000-08:00

On 10 Feb 2012, at 13:50, Aaron Knister wrote:

> Hi Dave,
>
> Thanks for the feedback. Unfortunately the setup isn't fronted by apache proxies. Having an apache instance per site would, I think, be painful-- this is a personal web hosting setup for 80,000+ individual sites (think mod_userdir).

And al these sites could load their own perl? Painful.

And PLEASE front the sites with a reverse proxy: squid, varnish whatever. If
not, you're opening yourself up to all kinds of badness. Mod_perl is an *app*
server, not a web server.

Please read Stas' chapter on performance tuning!

Chapters 9 and 10:

http://modperlbook.org/html/part2.html

And the others.

Re: disabling directives in .htaccess files

2012-02-10T06:03:00.001-08:00

On Friday, 10 February 2012 06:46:01 Aaron Knister wrote:
> I was thinking of something along these lines:
>
> A per-directory config directive called PerlHtaccessOverrides with possible
> values of Handlers, Others, Env, Options, All and None. These names are
> based what seemed to be perceived significant groupings of the MP_CMD_DIR_*
> cmd's in modperl_cmds.c.

Perhaps something along these lines:

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

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net

Re: disabling directives in .htaccess files

2012-02-10T05:50:00.001-08:00

Hi Dave,

Thanks for the feedback. Unfortunately the setup isn't fronted by apache proxies. Having an apache instance per site would, I think, be painful-- this is a personal web hosting setup for 80,000+ individual sites (think mod_userdir).

Sent from my iPhone

On Feb 10, 2012, at 7:20 AM, Dave Hodgkinson <davehodg@gmail.com> wrote:

>
> On 10 Feb 2012, at 11:46, Aaron Knister wrote:
>
>> Hi,
>>
>> I'm using mod_perl in a shared hosting environment for some server-side configuration bits. All dynamic content for the users runs through SuEXEC, however this obviously doesn't help in the case of mod_perl so I would like to prevent users from specifying any handlers or other potentially undesirable mod_perl options/directives in their .htaccess files.
>
> Are the Apaches fronted by proxies?
>
> In which case, I'd seriously consider everyone having their own Apaches with a limited
> number of processes and an appropriately (automatically generated?) startup.pl for maximum
> shared memory in those processes.
>
> Obviously, that number can be tuned depending on the site, but you'd be surprised at how
> few most sites need if the responses are quick.
>
> See Stas Bekman's immortal tuning work.
>
>

Re: disabling directives in .htaccess files

2012-02-10T04:20:00.000-08:00

On 10 Feb 2012, at 11:46, Aaron Knister wrote:

> Hi,
>
> I'm using mod_perl in a shared hosting environment for some server-side configuration bits. All dynamic content for the users runs through SuEXEC, however this obviously doesn't help in the case of mod_perl so I would like to prevent users from specifying any handlers or other potentially undesirable mod_perl options/directives in their .htaccess files.

Are the Apaches fronted by proxies?

In which case, I'd seriously consider everyone having their own Apaches with a limited
number of processes and an appropriately (automatically generated?) startup.pl for maximum
shared memory in those processes.

Obviously, that number can be tuned depending on the site, but you'd be surprised at how
few most sites need if the responses are quick.

See Stas Bekman's immortal tuning work.

disabling directives in .htaccess files

2012-02-10T03:46:00.001-08:00

Hi,

I'm using mod_perl in a shared hosting environment for some server-side configuration bits. All dynamic content for the users runs through SuEXEC, however this obviously doesn't help in the case of mod_perl so I would like to prevent users from specifying any handlers or other potentially undesirable mod_perl options/directives in their .htaccess files.

I was thinking of something along these lines:

A per-directory config directive called PerlHtaccessOverrides with possible values of Handlers, Others, Env, Options, All and None. These names are based what seemed to be perceived significant groupings of the MP_CMD_DIR_* cmd's in modperl_cmds.c.

Each cmd function would then check its context to see if it's an htaccess file, and would check against the list of allowed htaccess overrides for that location and deny accordingly. I'd also need to modify the Code.pm file that generates most of the handler cmd definitions.

I've something like this working right now, so I know it's possible but it's not quite as I described here so I need to re-write it.

Any feedback would be appreciated-- I don't want to write a patch that's not likely to be accepted upstream :)

Thanks!

-Aaron

--
Aaron Knister
Systems Administrator
Division of Information Technology
University of Maryland, Baltimore County
aaronk@umbc.edu

Re: Interrupting a POST with file upload

2012-02-08T17:56:00.000-08:00

Sorry slight clarification here after rereading httpd source:

If you send anything other than that "Continue: 100" interim
response to the client, httpd will NOT attempt to read the
body, considering it empty. But even if you do send the
"Continue: 100", httpd will NOT block the response from being
sent until the body has been exhausted. Instead it will
send your response as expected, and then finalize the request by
calling ap_discard_request_body(r) which WILL exhaust the
POST data in order to retain protocol compliance. OTOH I
have no idea how browsers deal with the timing issues here,
so buyer beware. My point still stands: interrupt the POST
prior to sending the Continue, not afterwards.

----- Original Message -----
> From: Joe Schaefer <joe_schaefer@yahoo.com>
> To: Vincent Veyron <vv.lists@wanadoo.fr>; mike cardeiro <mcardeiro@yahoo.com>
> Cc: Torsten Förtsch <torsten.foertsch@gmx.net>; "modperl@perl.apache.org" <modperl@perl.apache.org>
> Sent: Wednesday, February 8, 2012 4:35 PM
> Subject: Re: Interrupting a POST with file upload
>
> I don't think people groked my point very well. When you POST
> via HTTP/1.1, httpd will send a "Continue: 100" header before it
> starts doing blocking reads on the client socket (any attempts to
> read from the client will trigger this behavior). If you really
> want to interrupt an upload, the time to do it is *before* httpd
> sends that header. Afterwards httpd commits to reading the entire
> request in *before it lets you send a response* in order to maintain
> protocol compliance.
>
>
> For reasons that escape me it doesn't look like mod_perl exposes
> r->remaining, which is the thing to check when looking at the
> pending number of bytes the client wants to send. If I'm not wrong
> that should be easy enough for us to address. apreq won't read
> anything in in this situation tho, so you're good on that front.
> CGI.pm I'd bet doesn't try to read either if the pending data
> is too big, but I haven't looked at that codebase in a long time.
>
>
> ----- Original Message -----
>> From: Vincent Veyron <vv.lists@wanadoo.fr>
>> To: mike cardeiro <mcardeiro@yahoo.com>
>> Cc: Torsten Förtsch <torsten.foertsch@gmx.net>;
> "modperl@perl.apache.org" <modperl@perl.apache.org>
>> Sent: Wednesday, February 8, 2012 4:24 PM
>> Subject: Re: Interrupting a POST with file upload
>>
>> Le mercredi 08 février 2012 à 05:53 -0800, mike cardeiro a écrit :
>>> This is a fantastic list!
>>
>> Agreed.
>>
>> On the same note : I was recently presenting the legal case management
>> app in my sig to an institutional client in the south of France, and the
>> IT guy said that it had a 'fantastic architecture' (I assume he was
>> talking about mod_perl).
>>
>> --
>> Vincent Veyron
>> http://marica.fr/
>> Logiciel de gestion des sinistres et des contentieux pour le service
> juridique
>>
>

Re: Interrupting a POST with file upload

2012-02-08T14:03:00.000-08:00

Joe Schaefer wrote:
> I don't think people groked my point very well. When you POST
> via HTTP/1.1, httpd will send a "Continue: 100" header before it
> starts doing blocking reads on the client socket (any attempts to
> read from the client will trigger this behavior). If you really
> want to interrupt an upload, the time to do it is *before* httpd
> sends that header. Afterwards httpd commits to reading the entire
> request in *before it lets you send a response* in order to maintain
> protocol compliance.

So basically, it means that there is no way to stop an upload, once the browser has
started to send the file, right ?

The best you could do, is before you start reading, check if there was a Content-length
header in the request, and if there was, check if the size it says is lower/equal to what
you are prepared to accept (aka what this user is still allowed to upload e.g.).
- if it is ok, then start reading
- if it is not ok, send an error response to block the POST, before you read
(preferably a nice one, to let the user know why it does not work)

All this depends on 2 things :
- that there was a Content-length header in the request (which is not necessarily the case
if "chunked" encoding is allowed on the part of a client)
- that the fact of retrieving the request header does not automatically cause the reading
and parsing of the whole request body

All the above just guessing, and awaiting confirmation...

(And all the above, and the rest of this discussion, assuming that the POST can be large
enough that it all matters (like uploading a multi-MB file e.g.))

>
>
> For reasons that escape me it doesn't look like mod_perl exposes
> r->remaining, which is the thing to check when looking at the
> pending number of bytes the client wants to send. If I'm not wrong
> that should be easy enough for us to address. apreq won't read
> anything in in this situation tho, so you're good on that front.
> CGI.pm I'd bet doesn't try to read either if the pending data
> is too big, but I haven't looked at that codebase in a long time.
>
>
> ----- Original Message -----
>> From: Vincent Veyron <vv.lists@wanadoo.fr>
>> To: mike cardeiro <mcardeiro@yahoo.com>
>> Cc: Torsten Förtsch <torsten.foertsch@gmx.net>; "modperl@perl.apache.org" <modperl@perl.apache.org>
>> Sent: Wednesday, February 8, 2012 4:24 PM
>> Subject: Re: Interrupting a POST with file upload
>>
>> Le mercredi 08 février 2012 à 05:53 -0800, mike cardeiro a écrit :
>>> This is a fantastic list!
>> Agreed.
>>
>> On the same note : I was recently presenting the legal case management
>> app in my sig to an institutional client in the south of France, and the
>> IT guy said that it had a 'fantastic architecture' (I assume he was
>> talking about mod_perl).
>>
>> --
>> Vincent Veyron
>> http://marica.fr/
>> Logiciel de gestion des sinistres et des contentieux pour le service juridique
>>
>

Re: Interrupting a POST with file upload

2012-02-08T13:35:00.000-08:00

I don't think people groked my point very well. When you POST
via HTTP/1.1, httpd will send a "Continue: 100" header before it
starts doing blocking reads on the client socket (any attempts to
read from the client will trigger this behavior). If you really
want to interrupt an upload, the time to do it is *before* httpd
sends that header. Afterwards httpd commits to reading the entire
request in *before it lets you send a response* in order to maintain
protocol compliance.

For reasons that escape me it doesn't look like mod_perl exposes
r->remaining, which is the thing to check when looking at the
pending number of bytes the client wants to send. If I'm not wrong
that should be easy enough for us to address. apreq won't read
anything in in this situation tho, so you're good on that front.
CGI.pm I'd bet doesn't try to read either if the pending data
is too big, but I haven't looked at that codebase in a long time.

----- Original Message -----
> From: Vincent Veyron <vv.lists@wanadoo.fr>
> To: mike cardeiro <mcardeiro@yahoo.com>
> Cc: Torsten Förtsch <torsten.foertsch@gmx.net>; "modperl@perl.apache.org" <modperl@perl.apache.org>
> Sent: Wednesday, February 8, 2012 4:24 PM
> Subject: Re: Interrupting a POST with file upload
>
> Le mercredi 08 février 2012 à 05:53 -0800, mike cardeiro a écrit :
>> This is a fantastic list!
>
> Agreed.
>
> On the same note : I was recently presenting the legal case management
> app in my sig to an institutional client in the south of France, and the
> IT guy said that it had a 'fantastic architecture' (I assume he was
> talking about mod_perl).
>
> --
> Vincent Veyron
> http://marica.fr/
> Logiciel de gestion des sinistres et des contentieux pour le service juridique
>

Re: Interrupting a POST with file upload

2012-02-08T13:24:00.000-08:00

Le mercredi 08 février 2012 à 05:53 -0800, mike cardeiro a écrit :
> This is a fantastic list!

Agreed.

On the same note : I was recently presenting the legal case management
app in my sig to an institutional client in the south of France, and the
IT guy said that it had a 'fantastic architecture' (I assume he was
talking about mod_perl).

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique

Re: Interrupting a POST with file upload

2012-02-08T05:53:00.000-08:00

> From: Torsten Förtsch <torsten.foertsch@gmx.net>

>
> Best would be if you could make an educated guess based on the Content-Length
> request header if the uploaded file will exceed the limit. Most clients send
> an "Expect: 100-continue" header and thus give the server a chance to
> decline
> the request *before* the body is sent. If the body is already on the way the
> only thing you can do is to close the connection. I don't know if httpd does
>
> that immediately or if it reads and discards the whole body.

> The code below is the relevant piece of CGI.pm. So, yes, the upload hook gets
> the data as it is written to the temp file.
>
> while (defined($data = $buffer->read)) {
> if (defined $self->{'.upload_hook'}) {
> $totalbytes += length($data);
> &{$self->{'.upload_hook'}}($filename ,$data, $totalbytes,
> $self->{'.upload_data'});
> }
> print $filehandle $data if ($self->{'use_tempfile'});
> }
>

thanks for all the knowledge Torsten (and everyone else). This stuff is the holy grail I have been looking for for years. This is a fantastic list!

Mike Cardeiro

Re: Interrupting a POST with file upload

2012-02-08T03:48:00.000-08:00

Torsten Förtsch wrote:
> On Wednesday, 08 February 2012 10:14:35 André Warnier wrote:
>> As far as I know, LimitRequestBody is an absolute POST size limit set once
>> and for all in the server config, and valid for all POSTs (and PUTs) after
>> server restart.
>
> If you look at the docs you'll find that LimitRequestBody is valid in "server
> config, virtual host, directory and .htaccess" contexts. That means you can
> modify it on a per-request basis via $r->add_config. So, assuming
> authentication takes place in httpd's authentication phase you can set the
> limit in a PerlFixupHandler per user.
>
>> And it is calculated on the base of the real bytes being
>> sent by the browser, this including the overhead caused by Base64 encoding
>> the content of a file sent for example. (So that if you set the limit to
>> 1MB, this will actually kick in as soon as the net unencoded size of the
>> file being uploaded exceeds 660KB or so.)
>
> True. But with HTTP/1.1 the client can also choose to send the body deflated.
> Thus, the actual file size may also exceed 1MB.
>
>> Then there is the $CGI_POST_MAX, which may very well be the same server
>> value being manipulated by the CGI module, or it may be a private copy by
>> CGI.pm. What is not really clear is if that value is "thread-safe" in all
>> scenarios.
>
> CGI.pm is pure perl. So, to make $CGI_POST_MAX shared among threads it has to
> declare it as such. I doubt that any sane developer would do that.
>
>> In the normal scenario, when retrieving the uploaded file's handle via the
>> CGI.pm call to param(file_input_name) or upload(file_input_name), what one
>> actually gets is a handle onto a local temporary file, into which
>> Apache/CGI.pm has already stored the whole content of the uploaded
>> file. By that time, the original file upload from the browser has already
>> happened, so doing something at this point would be too late to interrupt
>> the browser POST itself (and the bandwidth and time have already been
>> spent).
>
> True.
>
>> On the other hand, the CGI.pm documentation seems to say that if one uses
>> the "hook" functionality for a file upload, then Apache/CGI.pm do not use
>> a temporary file, and one gets a handle directly into the POST body content
>> (so to speak), as it is being received by Apache. And thus this could be a
>> way to achieve what Mike wants.
>
> yes and no. It depends upon what exactly you want to limit. On the internet
> data is buffered by routers, firewalls etc. On your server it is buffered by
> the kernel. Httpd adds it's own buffering. HTTP is TCP-based. So, there may be
> retransmits that you won't notice. You certainly may abort the transfer when
> the CGI.pm hook has received a certain amount of data. But that would not mean
> that your server or your organization has not yet received the whole body.
>
> So, if you want to limit the disk usage then yes, you can simply stop writing
> when the limit is reached. If you want to limit the amount of data your server
> receives then no.
>
> Best would be if you could make an educated guess based on the Content-Length
> request header if the uploaded file will exceed the limit. Most clients send
> an "Expect: 100-continue" header and thus give the server a chance to decline
> the request *before* the body is sent. If the body is already on the way the
> only thing you can do is to close the connection. I don't know if httpd does
> that immediately or if it reads and discards the whole body.
>
>> (I suppose that we can assume that even
>> though we get a handle into the POST body content, what we are reading is
>> the decoded data, right ?).
>
> The code below is the relevant piece of CGI.pm. So, yes, the upload hook gets
> the data as it is written to the temp file.
>
> while (defined($data = $buffer->read)) {
> if (defined $self->{'.upload_hook'}) {
> $totalbytes += length($data);
> &{$self->{'.upload_hook'}}($filename ,$data, $totalbytes,
> $self->{'.upload_data'});
> }
> print $filehandle $data if ($self->{'use_tempfile'});
> }
>
> Torsten Förtsch
>

Many, many thanks Torsten. This is all precious and usable information.

Re: Interrupting a POST with file upload

2012-02-08T03:36:00.001-08:00

On Wednesday, 08 February 2012 10:14:35 André Warnier wrote:
> As far as I know, LimitRequestBody is an absolute POST size limit set once
> and for all in the server config, and valid for all POSTs (and PUTs) after
> server restart.

If you look at the docs you'll find that LimitRequestBody is valid in "server
config, virtual host, directory and .htaccess" contexts. That means you can
modify it on a per-request basis via $r->add_config. So, assuming
authentication takes place in httpd's authentication phase you can set the
limit in a PerlFixupHandler per user.

> And it is calculated on the base of the real bytes being
> sent by the browser, this including the overhead caused by Base64 encoding
> the content of a file sent for example. (So that if you set the limit to
> 1MB, this will actually kick in as soon as the net unencoded size of the
> file being uploaded exceeds 660KB or so.)

True. But with HTTP/1.1 the client can also choose to send the body deflated.
Thus, the actual file size may also exceed 1MB.

> Then there is the $CGI_POST_MAX, which may very well be the same server
> value being manipulated by the CGI module, or it may be a private copy by
> CGI.pm. What is not really clear is if that value is "thread-safe" in all
> scenarios.

CGI.pm is pure perl. So, to make $CGI_POST_MAX shared among threads it has to
declare it as such. I doubt that any sane developer would do that.

> In the normal scenario, when retrieving the uploaded file's handle via the
> CGI.pm call to param(file_input_name) or upload(file_input_name), what one
> actually gets is a handle onto a local temporary file, into which
> Apache/CGI.pm has already stored the whole content of the uploaded
> file. By that time, the original file upload from the browser has already
> happened, so doing something at this point would be too late to interrupt
> the browser POST itself (and the bandwidth and time have already been
> spent).

True.

> On the other hand, the CGI.pm documentation seems to say that if one uses
> the "hook" functionality for a file upload, then Apache/CGI.pm do not use
> a temporary file, and one gets a handle directly into the POST body content
> (so to speak), as it is being received by Apache. And thus this could be a
> way to achieve what Mike wants.

yes and no. It depends upon what exactly you want to limit. On the internet
data is buffered by routers, firewalls etc. On your server it is buffered by
the kernel. Httpd adds it's own buffering. HTTP is TCP-based. So, there may be
retransmits that you won't notice. You certainly may abort the transfer when
the CGI.pm hook has received a certain amount of data. But that would not mean
that your server or your organization has not yet received the whole body.

So, if you want to limit the disk usage then yes, you can simply stop writing
when the limit is reached. If you want to limit the amount of data your server
receives then no.

Best would be if you could make an educated guess based on the Content-Length
request header if the uploaded file will exceed the limit. Most clients send
an "Expect: 100-continue" header and thus give the server a chance to decline
the request *before* the body is sent. If the body is already on the way the
only thing you can do is to close the connection. I don't know if httpd does
that immediately or if it reads and discards the whole body.

> (I suppose that we can assume that even
> though we get a handle into the POST body content, what we are reading is
> the decoded data, right ?).

The code below is the relevant piece of CGI.pm. So, yes, the upload hook gets
the data as it is written to the temp file.

while (defined($data = $buffer->read)) {
if (defined $self->{'.upload_hook'}) {
$totalbytes += length($data);
&{$self->{'.upload_hook'}}($filename ,$data, $totalbytes,
$self->{'.upload_data'});
}
print $filehandle $data if ($self->{'use_tempfile'});
}

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net

Re: Interrupting a POST with file upload

2012-02-08T03:05:00.000-08:00

You probably don't want to do this with a hook if you can
avoid it. The reason is that once httpd sends the 100 Continue
it will read the entire upload, even after CGI.pm or apreq
has stopped parsing it.

----- Original Message -----
> From: André Warnier <aw@ice-sa.com>
> To: mod_perl list <modperl@perl.apache.org>
> Cc:
> Sent: Wednesday, February 8, 2012 4:14 AM
> Subject: Interrupting a POST with file upload
>
>T his refers to and follows another thread originally entitled "mod perl
> installed but not running", started by Mike Cardeiro.
>
> It seemed better to start a new thread with a subject more to the point of this
> issue.
>
> Perrin Harkins wrote:
>> On Tue, Feb 7, 2012 at 7:26 PM, André Warnier <aw@ice-sa.com> wrote:
>>> You can also look at $CGI::POST_MAX in the same documentation.
>>
>> See also LimitRequestBody:
>> http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
>>
>
> As long as we have an expert..
>
> What Mike wants to do (and me too), is to limit the size of a file that a
> specific user is uploading via a POST, in real-time and depending on a limit
> variable on a per-user, per-POST manner.
> And he wants to do this in such a way as to interrupt the POST itself, while it
> is taking place (aka if possible while the browser is still sending data to the
> server), to avoid a waste of time and bandwidth when a user is exceeding his
> quota e.g.
>
> As far as I know, LimitRequestBody is an absolute POST size limit set once and
> for all in the server config, and valid for all POSTs (and PUTs) after server
> restart. And it is calculated on the base of the real bytes being sent by the
> browser, this including the overhead caused by Base64 encoding the content of a
> file sent for example.
> (So that if you set the limit to 1MB, this will actually kick in as soon as the
> net unencoded size of the file being uploaded exceeds 660KB or so.)
>
> Then there is the $CGI_POST_MAX, which may very well be the same server value
> being manipulated by the CGI module, or it may be a private copy by CGI.pm.
> What is not really clear is if that value is "thread-safe" in all
> scenarios.
>
> In the normal scenario, when retrieving the uploaded file's handle via the
> CGI.pm call to param(file_input_name) or upload(file_input_name), what one
> actually gets is a handle onto a local temporary file, into which Apache/CGI.pm
> has already stored the whole content of the uploaded file. By that time, the
> original file upload from the browser has already happened, so doing something
> at this point would be too late to interrupt the browser POST itself (and the
> bandwidth and time have already been spent).
>
> On the other hand, the CGI.pm documentation seems to say that if one uses the
> "hook" functionality for a file upload, then Apache/CGI.pm do not use
> a temporary file, and one gets a handle directly into the POST body content (so
> to speak), as it is being received by Apache. And thus this could be a way to
> achieve what Mike wants.
> (I suppose that we can assume that even though we get a handle into the POST
> body content, what we are reading is the decoded data, right ?).
>
> Now the question is, are my above interpretations correct ?
>

Interrupting a POST with file upload

2012-02-08T01:14:00.000-08:00

This refers to and follows another thread originally entitled "mod perl installed but not
running", started by Mike Cardeiro.

It seemed better to start a new thread with a subject more to the point of this issue.

Perrin Harkins wrote:
> On Tue, Feb 7, 2012 at 7:26 PM, André Warnier <aw@ice-sa.com> wrote:
>> You can also look at $CGI::POST_MAX in the same documentation.
>
> See also LimitRequestBody:
> http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
>

As long as we have an expert..

What Mike wants to do (and me too), is to limit the size of a file that a specific user is
uploading via a POST, in real-time and depending on a limit variable on a per-user,
per-POST manner.
And he wants to do this in such a way as to interrupt the POST itself, while it is taking
place (aka if possible while the browser is still sending data to the server), to avoid a
waste of time and bandwidth when a user is exceeding his quota e.g.

As far as I know, LimitRequestBody is an absolute POST size limit set once and for all in
the server config, and valid for all POSTs (and PUTs) after server restart. And it is
calculated on the base of the real bytes being sent by the browser, this including the
overhead caused by Base64 encoding the content of a file sent for example.
(So that if you set the limit to 1MB, this will actually kick in as soon as the net
unencoded size of the file being uploaded exceeds 660KB or so.)

Then there is the $CGI_POST_MAX, which may very well be the same server value being
manipulated by the CGI module, or it may be a private copy by CGI.pm. What is not really
clear is if that value is "thread-safe" in all scenarios.

In the normal scenario, when retrieving the uploaded file's handle via the CGI.pm call to
param(file_input_name) or upload(file_input_name), what one actually gets is a handle onto
a local temporary file, into which Apache/CGI.pm has already stored the whole content of
the uploaded file. By that time, the original file upload from the browser has already
happened, so doing something at this point would be too late to interrupt the browser POST
itself (and the bandwidth and time have already been spent).

On the other hand, the CGI.pm documentation seems to say that if one uses the "hook"
functionality for a file upload, then Apache/CGI.pm do not use a temporary file, and one
gets a handle directly into the POST body content (so to speak), as it is being received
by Apache. And thus this could be a way to achieve what Mike wants.
(I suppose that we can assume that even though we get a handle into the POST body content,
what we are reading is the decoded data, right ?).

Now the question is, are my above interpretations correct ?

Re: mod perl installed but not running

2012-02-07T18:01:00.001-08:00

On Tue, Feb 7, 2012 at 7:26 PM, André Warnier <aw@ice-sa.com> wrote:
> You can also look at $CGI::POST_MAX in the same documentation.

- Perrin

Re: mod perl installed but not running

2012-02-07T16:26:00.001-08:00

mike cardeiro wrote:
>
> ----- Original Message -----
>> From: André Warnier <aw@ice-sa.com>
>>
>> And it doesn't ?
>> The startup message of your Apache seemed to say that it does..
>>
>
> Yes, it now is running and I am on my way!
>
Good, then..

about your wish to limit the size of the files someone can upload,
depending on how much they are already using.

You should look at the documentation of CGI.pm, the "CREATING A FILE UPLOAD FIELD"
section, and particularly the part about the "hook" function.
I have never tried it, but there should be a way there to interrupt the upload and abort
the POST processing whenever the read file size goes over your limit.

It doesn't really require mod_perl though, it is part of CGI.pm.

You can also look at $CGI::POST_MAX in the same documentation.
The mere fact that this parameter can be set at the script level, seems to indicate that
it is dynamic, and that you could set it, at least as long as you have not started parsing
the POST itself (e.g. not called any param() yet).

Re: mod perl installed but not running

2012-02-07T14:44:00.000-08:00

----- Original Message -----
> From: André Warnier <aw@ice-sa.com>
>
> And it doesn't ?
> The startup message of your Apache seemed to say that it does..
>

Yes, it now is running and I am on my way!

Re: mod perl installed but not running

2012-02-07T14:36:00.001-08:00

mike cardeiro wrote:
>> From: André Warnier <aw@ice-sa.com>
>
>> To: mod_perl list <modperl@perl.apache.org>
>>
>> Now another question : apart from cgi-bin scripts which run much faster under
>> mod_perl, have you already tried writing mod_perl-based Apache modules ?
>> (because that's where the really interesting things start, with mod_perl).
>>
>
> I am a total newb to mod_perl. This is definitely where I am heading...but I have a loooong way to go, right now I just want to get my system running under mod_perl.
>
And it doesn't ?
The startup message of your Apache seemed to say that it does..

Re: mod perl installed but not running

2012-02-07T14:31:00.001-08:00

> From: André Warnier <aw@ice-sa.com>

> To: mod_perl list <modperl@perl.apache.org>
>
> Now another question : apart from cgi-bin scripts which run much faster under
> mod_perl, have you already tried writing mod_perl-based Apache modules ?
> (because that's where the really interesting things start, with mod_perl).
>

I am a total newb to mod_perl. This is definitely where I am heading...but I have a loooong way to go, right now I just want to get my system running under mod_perl.

Mike Cardeiro

Re: mod perl installed but not running

2012-02-07T13:34:00.001-08:00

mike cardeiro wrote:
>> From: André Warnier <aw@ice-sa.com>
>
>
>> Very good. And by the same mechanism, you are already avoiding the problem with
>> all the silly (and sometimes dangerous) names that people can give to their
>> files.
>
> that is precisely why I did it this way.

You would be surprised at the number of people who don't think of that issue until after
they have put their system in place (not even mentioning the question of international
character sets and their representation in the filesystem).

>
>
>> So if your files in the filesystem only have an unique-id as a name, then you
>> also have a download script, and this download script can also show the users a
>> nice page with the list of files that they can download, right ? and the links
>> that are shown are each in turn a call to your download script, to download the
>> file that they choose, right ?
>
> yup

I would be tempted to ask what was your original problem then ?

>
>> And another question : how many files maximum can end up being stored in that
>> upload/download directory ?
>>
>
> generally I do it by size. so a user can upload say 5 gigs worth of files and the upload script will query the database for a sum of filesizes of all of that users files to see it they still have space. This is where I am really exited about the prospect of doing this in mod_perl. in the past, if you were uploading a 1 gig file but did not have space on your account you would not get an error until the entire file is uploaded. I am thinking with the way mod_perl works I can query the db for that user before the entire request (upload) is made and throw an error immediately (though I could be wrong)
>
> I guess another thought I need is not only the size of files but the actual number of files...I suppose there is a choking point when there are just too many files in one directory.

Yes, that is why is was asking, because it is also something that many people ignore at
first. It used to be worse, but even with current OS'es, there is still a limit as to how
many files can be in a directory, before any access to it becomes extremely sluggish. I'd
say that a limit of 2000 files or so is certainly not to be crossed. Under Windows, I
would say much less, or else even viewing a directory with Explorer becomes painful.
Since you are giving each file a unique id however, you can decide to split the files into
a subdirectory structure based on different substrings within that id, to split your files
into a reasonable amount of separate (sub-)directories. You can decide on a 2-level,
3-level structure or more, depending on how many files you think you are going to have
over the next 5 years or so. Fortunately, disks are now large enough and filesystems smart
enough that you do not need to worry too quickly about space.
If you are planning to go into the hundreds of thousands of files, then you need a smarter
system, because otherwise you will have trouble keeping track, doing backups, splitting
these files logically for various purposes etc..

Now another question : apart from cgi-bin scripts which run much faster under mod_perl,
have you already tried writing mod_perl-based Apache modules ?
(because that's where the really interesting things start, with mod_perl).

Re: mod perl installed but not running

2012-02-07T12:43:00.000-08:00

> From: André Warnier <aw@ice-sa.com>

> Very good. And by the same mechanism, you are already avoiding the problem with
> all the silly (and sometimes dangerous) names that people can give to their
> files.

that is precisely why I did it this way.

>
> So if your files in the filesystem only have an unique-id as a name, then you
> also have a download script, and this download script can also show the users a
> nice page with the list of files that they can download, right ? and the links
> that are shown are each in turn a call to your download script, to download the
> file that they choose, right ?

yup

>
> And another question : how many files maximum can end up being stored in that
> upload/download directory ?
>

generally I do it by size. so a user can upload say 5 gigs worth of files and the upload script will query the database for a sum of filesizes of all of that users files to see it they still have space. This is where I am really exited about the prospect of doing this in mod_perl. in the past, if you were uploading a 1 gig file but did not have space on your account you would not get an error until the entire file is uploaded. I am thinking with the way mod_perl works I can query the db for that user before the entire request (upload) is made and throw an error immediately (though I could be wrong)

I guess another thought I need is not only the size of files but the actual number of files...I suppose there is a choking point when there are just too many files in one directory.

Mike Cardeiro

Re: mod perl installed but not running

2012-02-07T11:58:00.000-08:00

mike cardeiro wrote:
>> From: André Warnier <aw@ice-sa.com>
>
> >
>> Now, as long as we're there, what happens in your application if two people
>> upload a file with the same file name ?
>>
>
> When the upload happens the script makes an entry in a mysql table with
> the file name, mime type and other info; the table has an autoincremented id
> field as the primary key. the script names the uploaded file this id value so every file in the
> directory is named the id field of their entry in the database so they
> will all be unigue.
>

Very good. And by the same mechanism, you are already avoiding the problem with all the
silly (and sometimes dangerous) names that people can give to their files.
And I am sure that you also filter these oroginal filenames before writing them to your
database, right ? Not that people would be able to upload files with names that contain
silly characters like <,>,|,;,&,?,spaces, and all these kinds of things.

So if your files in the filesystem only have an unique-id as a name, then you also have a
download script, and this download script can also show the users a nice page with the
list of files that they can download, right ? and the links that are shown are each in
turn a call to your download script, to download the file that they choose, right ?

And another question : how many files maximum can end up being stored in that
upload/download directory ?

Re: mod perl installed but not running

2012-02-07T11:23:00.001-08:00

> From: André Warnier <aw@ice-sa.com>

>
> Now, as long as we're there, what happens in your application if two people
> upload a file with the same file name ?
>

When the upload happens the script makes an entry in a mysql table with
the file name, mime type and other info; the table has an autoincremented id
field as the primary key. the script names the uploaded file this id value so every file in the
directory is named the id field of their entry in the database so they
will all be unigue.

Thank you for your helpful response(s). I have been coding for over a
decade but always on a shared server where I had no access to apache or
anything other than my own little sandbox so I have never had to deal
with all this stuff. It is really fun (and a little scary). I am learning a lot, it's nice to get help from people who know way more than me!

Mike Cardeiro

Re: mod perl installed but not running

2012-02-07T10:49:00.000-08:00

mike cardeiro wrote:
>
>> From: André Warnier <aw@ice-sa.com>
>
>
>> You should probably analyse your requirements carefully (as to exactly /why/ you
>> want the script to run as that user).
>
>
> I am creating a file transfer site. When a user logs in they can upload a file, so I need the script to write the file to a directory that is not accessible by the webserver; when another user logs in they can retrieve the file.
>

Well, that's what I meant by analysing your requirements properly.
Presumably, your script is the one who accepts the file upload, and writes the file to
some directory.
Assuming that the script runs under the Apache user-id (the default), that script can
still write to any directory outside the Apache document_root, as long as that directory
is writeable by the Apache user-id.
Since that directory is outside the document_root, Apache by itself cannot access it.

To allow some people to retrieve the files, all you then need to do is to provide another
script that can read that same directory and send a file back to the user.
None of that really requires Apache to run your scripts as another user (which is
difficult to achieve and full of potential security holes).

Now, as long as we're there, what happens in your application if two people upload a file
with the same file name ?

Re: mod perl installed but not running

2012-02-07T10:37:00.000-08:00

On 7 Feb 2012, at 16:08, mike cardeiro wrote:

>
>
>> From: André Warnier <aw@ice-sa.com>
>
>
>> You should probably analyse your requirements carefully (as to exactly /why/ you
>> want the script to run as that user).
>
>
> I am creating a file transfer site. When a user logs in they can upload a file, so I need the script to write the file to a directory that is not accessible by the webserver;

Welcome to setuid hell.

Re: mod perl installed but not running

2012-02-07T08:08:00.000-08:00

> From: André Warnier <aw@ice-sa.com>

> You should probably analyse your requirements carefully (as to exactly /why/ you
> want the script to run as that user).

I am creating a file transfer site. When a user logs in they can upload a file, so I need the script to write the file to a directory that is not accessible by the webserver; when another user logs in they can retrieve the file.

It seems to be running the scripts as me when not using mod_perl (I assume so because the script permissions are 700)

Mike Cardeiro

Re: mod perl installed but not running

2012-02-07T07:44:00.000-08:00

mike cardeiro wrote:
>> From: Dave Hodgkinson <davehodg@gmail.com>
>>
>> What's MaxRequestsPerChild?
>>
>
>
> MaxRequestsPerChild 10000
>
> ...I think I may have figured out the problem. I think mod perl is running but my scripts are not using it. I added
>
>
> <Directory "/home/secret34/public_html/cgi-bin">
>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> Options +ExecCGI
>
> </Directory>
>
> to httpd.conf now my scripts get the following error
> slurp_filename('/home/secret34/public_html/cgi-bin/login.cgi') / opening: (13) Permission denied at /home/secret34/lib/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pm line 541
>
> progress. I assume this is happening because my script permissions are 700 under the user that owns
>
> '/home/secret34/public_html/cgi-bin/'
>
> guess I have more playing around to do. I want the scripts to run as if run by that user.
>
Cannot do that, unless you have Apache itself run as that user.
You should probably analyse your requirements carefully (as to exactly /why/ you want the
script to run as that user). Then maybe you can solve that by making the Apache user and
the other user member of the same group, and adapt your file permissions accordingly.
The other solution I can think of, is to run a separate Apache instance under the user you
want (and listening on a separate port).

Re: mod perl installed but not running

2012-02-07T07:05:00.000-08:00

> From: Dave Hodgkinson <davehodg@gmail.com>
>
>What's MaxRequestsPerChild?
>

MaxRequestsPerChild 10000

...I think I may have figured out the problem. I think mod perl is running but my scripts are not using it. I added

    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options +ExecCGI

</Directory>

to httpd.conf now my scripts get the following error
slurp_filename('/home/secret34/public_html/cgi-bin/login.cgi') / opening: (13) Permission denied at /home/secret34/lib/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pm line 541

progress. I assume this is happening because my script permissions are 700 under the user that owns

'/home/secret34/public_html/cgi-bin/'

guess I have more playing around to do. I want the scripts to run as if run by that user.

Mike Cardeiro

Re: mod perl installed but not running

2012-02-07T06:40:00.001-08:00

What's MaxRequestsPerChild?

Are there several big fat httpd's whose PIDs remain constant?

On 7 Feb 2012, at 14:18, mike cardeiro wrote:

> I asked this a few weeks ago. Is it possible that mod_perl is running but the $ENV{MOD_PERL} variable doesn't exist?
>
> it seems like it is running (the site is zippier) and when I restart apache the log file has the following line.
>
> Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.5 Perl/v5.8.8 configured -
> - resuming normal operations
>
> am I nuts? it says "mod_perl/2.0.5 Perl/v5.8.8 configured" but if I run a script listing %ENV there is no mod_perl entry.
>
> Mike Cardeiro

mod perl installed but not running

2012-02-07T06:18:00.001-08:00

I asked this a few weeks ago. Is it possible that mod_perl is running but the $ENV{MOD_PERL} variable doesn't exist?

it seems like it is running (the site is zippier) and when I restart apache the log file has the following line.

Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.5 Perl/v5.8.8 configured -
- resuming normal operations

am I nuts? it says "mod_perl/2.0.5 Perl/v5.8.8 configured" but if I run a script listing %ENV there is no mod_perl entry.

Mike Cardeiro

Re: Tool to create multiple requests

2012-02-07T02:18:00.000-08:00

On 07/02/2012 08:58, André Warnier wrote:

Tobias Wagener wrote:

Hello,

I'm currently developing a huge application with mod_perl, unixODBC and MaxDB/SAPDB.
On my developing system everything is fine. But on the productive system
with > 50 users, I have database connection errors and request aborts and
so on.

Now I want to ask if someone knows a tool or perl modules, where I can simulate
50 users. I have a list with some common request including the query parameter in order of appearence. But I don't know, how to send them to my developing system to create the same load as it will be on the productive system.

Can someone help me with this issue?

As a simple tool, have a look at the "ab" program that comes with Apache.

ab isn't usually that much use as it does strain the databases in the same way - especially as it only takes 1 URL - any "production" scaling e.g. caching etc will make it even worse. I have a simple one I wrote based on curl which can take a list of URLs which is generally a lot better.
Without being careful it is still difficult to cope with large sites acting like users (you will need to extend the code to do cookie jars!)...

Things we have come across in large production systems are.

Apache::DBI sometimes cause issues with too many database connections - we tend to turn it off and use DBIx::Connector as mentioned (and carefully selected caching) here to cope with persistence of connections;
You may be serving too many requests on the server to the users (other than the main page request).... look at caching/minimising/merging page design elements - background images, javascript, CSS;
OR - serve them from a second apache (use it either as a proxy or have a proxy in front of the two apaches)
Don't over AJAX pages - lots of "parallel" AJAX requests can effectively DOS your service;

Another trick is to add extra diagnostics to your apache logs with a couple of mod_perl handlers:

Apache configuration file:

PerlLoadModule Pagesmith::Apache::Timer PerlChildInitHandler Pagesmith::Apache::Timer::child_init_handler PerlChildExitHandler Pagesmith::Apache::Timer::child_exit_handler PerlPostReadRequestHandler Pagesmith::Apache::Timer::post_read_request_handler PerlLogHandler Pagesmith::Apache::Timer::log_handler

LogFormat "%V [%P/%{CHILD_COUNT}e %{SCRIPT_TIME}e %{outstream}n/%{instream}n=%{ratio}n] %h/%{X-Forwarded-For}i %l/%{SESSION_ID}e %u/%{user_name}e %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\ " \"%{Cookie}i\" \"%{X-Requested-With}i\" %{SCRIPT_START}e/%{SCRIPT_END}e" diagnostic

The following module sets up the four environment variables: CHILD_COUNT, SCRIPT_START, SCRIPT_END, SCRIPT_TIME so you can see which requests are slow and you can also see if you have any "clustering" of requests... Setting the "Readonly my $LEVEL" to either normal or noisy will give you more diagnostics in the error log as well....

Module:

package Pagesmith::Apache::Timer; ## Component ## Author : js5 ## Maintainer : js5 ## Created : 2009-08-12 ## Last commit by : $Author: js5 $ ## Last modified : $Date: 2011-10-26 12:44:20 +0100 (Wed, 26 Oct 2011) $ ## Revision : $Revision: 1489 $ ## Repository URL : $HeadURL: svn+ssh://web-svn.internal.sanger.ac.uk/repos/svn/shared-content/trunk/lib/Pagesmith/Apache/Timer.pm $ use strict; use warnings; use utf8; use version qw(qv); our $VERSION = qv('0.1.0'); use Readonly qw(Readonly); Readonly my $VERY_LARGE_TIME => 1_000_000; Readonly my $CENT => 100; Readonly my $LEVEL => 'normal'; # (quiet,normal,noisy) use Apache2::Const qw(OK DECLINED); use English qw(-no_match_vars $PID); use Time::HiRes qw(time); my $child_started; my $request_started; my $requests; my $total_time; my $min_time; my $max_time; my $total_time_squared; sub post_config_handler { return DECLINED if $LEVEL eq 'quiet'; printf {*STDERR} "TI: Start apache %9d\n", $PID; return DECLINED; } sub child_init_handler { return DECLINED if $LEVEL eq 'quiet'; $child_started = time; $requests = 0; $total_time = 0; $min_time = $VERY_LARGE_TIME; $max_time = 0; $total_time_squared = 0; printf {*STDERR} "TI: Start child %9d\n", $PID; return DECLINED; } sub post_read_request_handler { my $r = shift; return DECLINED if $LEVEL eq 'quiet'; $request_started = time; $requests++; return DECLINED unless $LEVEL eq 'noisy'; printf {*STDERR} "TI: Start request %9d - %4d %s\n", $PID, $requests, $r->uri; return DECLINED; } sub log_handler { my $r = shift; return DECLINED if $LEVEL eq 'quiet'; my $request_ended = time; my $t = $request_ended - $request_started; $total_time += $t; $min_time = $t if $t < $min_time; $max_time = $t if $t > $max_time; $total_time_squared += $t * $t; $r->subprocess_env->{'CHILD_COUNT'} = $requests; $r->subprocess_env->{'SCRIPT_START'} = sprintf '%0.6f', $request_started; $r->subprocess_env->{'SCRIPT_END'} = sprintf '%0.6f', $request_ended; $r->subprocess_env->{'SCRIPT_TIME'} = sprintf '%0.6f', $t; return DECLINED unless $LEVEL eq 'noisy'; printf {*STDERR} "TI: End request %9d - %4d %10.6f %s\n", $PID, $requests, $t, $r->uri; return DECLINED; } sub child_exit_handler { return DECLINED if $LEVEL eq 'quiet'; my $time_alive = time - $child_started; printf {*STDERR} "TI: End child %9d - %4d %10.6f %10.6f %7.3f%% %10.6f [%10.6f,%10.6f]\n", $PID, $requests, $total_time, $time_alive, $time_alive ? $CENT * $total_time / $time_alive : 0, $requests ? $total_time / $requests : 0, $min_time, $max_time; return DECLINED; } 1;

-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

Re: Tool to create multiple requests

2012-02-07T01:37:00.000-08:00

It's rudimentary but you can try Apache ab, the Apache benchmarking
tool. You probably have it installed already. Try 'man ab' at the prompt.

If you want to emulate 50 concurrent requests, sent twice, you'd do
something like:

ab -c 50 -n 100 http://example.com/etc?etc

If you don't have it installed already, then see
http://httpd.apache.org/docs/2.2/programs/ab.html

If that doesn't provide any clues, check

http://modperlbook.org/html/Chapter-9-Essential-Tools-for-Performance-Tuning.html

Good luck.

On 2/6/2012 11:05 PM, Tobias Wagener wrote:
> Hello,
>
> I'm currently developing a huge application with mod_perl, unixODBC and MaxDB/SAPDB.
> On my developing system everything is fine. But on the productive system
> with> 50 users, I have database connection errors and request aborts and
> so on.
>
> Now I want to ask if someone knows a tool or perl modules, where I can simulate
> 50 users. I have a list with some common request including the query parameter
> in order of appearence. But I don't know, how to send them to my developing
> system to create the same load as it will be on the productive system.
>
> Can someone help me with this issue?
>
> Thanks and best regards,
>
> Tobias
>
>
>

Re: Tool to create multiple requests

2012-02-07T00:58:00.000-08:00

Tobias Wagener wrote:
> Hello,
>
> I'm currently developing a huge application with mod_perl, unixODBC and MaxDB/SAPDB.
> On my developing system everything is fine. But on the productive system
> with > 50 users, I have database connection errors and request aborts and
> so on.
>
> Now I want to ask if someone knows a tool or perl modules, where I can simulate
> 50 users. I have a list with some common request including the query parameter
> in order of appearence. But I don't know, how to send them to my developing
> system to create the same load as it will be on the productive system.
>
> Can someone help me with this issue?
>
As a simple tool, have a look at the "ab" program that comes with Apache.

Tool to create multiple requests

2012-02-06T23:05:00.000-08:00

Hello,

I'm currently developing a huge application with mod_perl, unixODBC and MaxDB/SAPDB.
On my developing system everything is fine. But on the productive system
with > 50 users, I have database connection errors and request aborts and
so on.

Now I want to ask if someone knows a tool or perl modules, where I can simulate
50 users. I have a list with some common request including the query parameter
in order of appearence. But I don't know, how to send them to my developing
system to create the same load as it will be on the productive system.

Can someone help me with this issue?

Thanks and best regards,

Tobias

2012-02-04T08:49:00.000-08:00

http://serenity-event-s.fr/galerie-photos/zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/test.php?fish1.img

Re: mod perl installed but not running

2012-01-30T12:09:00.000-08:00

Perrin Harkins wrote:
> On Sun, Jan 29, 2012 at 5:22 PM, mike cardeiro <mcardeiro@yahoo.com> wrote:
>> can anybody help me. I have mod_perl installed, I have "LoadModule
>> perl_module /usr/local/apache/modules/mod_perl.so" in httpd.conf
>>
>> if the installation isn't right, shouldn't the server choke on restart
>> because it cant load mod_perl.so?
>
> Time for some sanity checks. Try changing the path to mod_perl.so so
> it points to nothing. See if you can still restart. If you can,
> you're restarting a different server than the one that's using this
> conf file.
>
.. or you are modifying a conf file that your server is not using. ;-)

Re: mod perl installed but not running

2012-01-30T12:01:00.001-08:00

On Sun, Jan 29, 2012 at 5:22 PM, mike cardeiro <mcardeiro@yahoo.com> wrote:
> can anybody help me. I have mod_perl installed, I have "LoadModule
> perl_module /usr/local/apache/modules/mod_perl.so" in httpd.conf
>
> if the installation isn't right, shouldn't the server choke on restart
> because it cant load mod_perl.so?

Time for some sanity checks. Try changing the path to mod_perl.so so
it points to nothing. See if you can still restart. If you can,
you're restarting a different server than the one that's using this
conf file.

- Perrin

Re: Font Problem

2012-01-30T11:39:00.001-08:00

Michel Jansen wrote:
> Hi André,
>
> This works! Thanx for your help..... Of course i now have another
> problem.....! Firefox now rejects the font saying: downloadable font:
> rejected by sanitizer ;-)
>
Michel,

Glad that it helped.

But please respond to the list, not to my private email address.

When you send to the list, the others on the list also see your answer and can see that
the problem is solved and how.
Also, that way your message will arrive in the list archives, and someone else with the
same problem and who searches the list archives, will also see it, without needing to ask.

If you send our message to me, the above does not happen.
Do not even send me a copy. I am subscribed to the list and I get all messages to the
list automatically. If you send me a copy, I get the same message twice, which is
unnecessary and annoying.
In addition, when you send an email to my address, my email filters are such that your
emails land in my "junk" folder (which I just happened to check, that's why I saw it).

Re: Font Problem

2012-01-30T11:06:00.001-08:00

André Warnier wrote:
> Michel Jansen wrote:
>> Hi There,
>>
>> I have a probem using webfonts in Firefox. It won't let me use
>> webfonts from another url than the original. Since i am working with a
>> perlhandler that "catches" all requests from / and up, i would like to
>> know of someone knows how i can bypass my handler for a specific
>> directory above / like for example /fonts/. It would be nice if the
>> handler can be told to handle all requests bot not for /fonts/ and
>> pass this request to apache....
>>
> Have you tried returning Apache2::Const::DECLINED from your handler if
> the URL is "/fonts/*" ?
>
> See here :
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlResponseHandler
> (and check RUN_FIRST)
>
> As far as I understand, if your handler returns DECLINED, and there are
> no more explicit handlers defined, then Apache should serve the request
> with it's default handler, which should be what you want.
>

Another solution which you might try, without modifying your handler :

1) read these :

http://httpd.apache.org/docs/2.2/mod/core.html#sethandler
http://httpd.apache.org/docs/2.2/mod/core.html#location

2) configure as follows :

<Location />
SetHandler mod_perl
PerlResponseHandler my_module
...
</Location>

<Location /fonts/>
SetHandler none
</Location>

Re: Font Problem

2012-01-30T10:39:00.000-08:00

Michel Jansen wrote:
> Hi There,
>
> I have a probem using webfonts in Firefox. It won't let me use webfonts
> from another url than the original. Since i am working with a
> perlhandler that "catches" all requests from / and up, i would like to
> know of someone knows how i can bypass my handler for a specific
> directory above / like for example /fonts/. It would be nice if the
> handler can be told to handle all requests bot not for /fonts/ and pass
> this request to apache....
>
Have you tried returning Apache2::Const::DECLINED from your handler if the URL is "/fonts/*" ?

See here :
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlResponseHandler
(and check RUN_FIRST)

As far as I understand, if your handler returns DECLINED, and there are no more explicit
handlers defined, then Apache should serve the request with it's default handler, which
should be what you want.

Re: mod perl installed but not running

2012-01-29T14:22:00.000-08:00

can anybody help me. I have mod_perl installed, I have "LoadModule perl_module /usr/local/apache/modules/mod_perl.so" in httpd.conf

if the installation isn't right, shouldn't the server choke on restart because it cant load mod_perl.so?

this is driving me crazy. I tried reinstalling mod_per (not sure if that was a bad idea).

Mike Cardeiro

[ANNOUNCE] Apache-Test 1.37

2012-01-29T11:57:00.000-08:00

Apache-Test 1.37 is coming to a CPAN mirror near you. Thanks to
several different contributors for this release!

md5: 179f247fc5c7d11387b9c73ae3fa6f71

1.37 January 29, 2012
Apache::TestRequest: improve compatibility for SSL requests with LWP
6 and IO::Socket::SSL, in particular [Kaspar Brand]

As of httpd revision 1053230 (version 2.3.11) the NameVirtualHost
directive became superfluous and a warning is issued when it is met.
So, Apache::Test now wraps NameVirtualHost directives in <IfVersion>
blocks. [Kaspar Brand]

Add comments about the source files of auto configurated tests to
the generated httpd.conf and improve indentation a bit. [Torsten
Foertsch]

Run t/TEST tests by default in alphabetical order and only t/SMOKE
tests by default in random order. [Rainer Jung]

Add t_file_watch_for to Apache::TestUtil [Torsten Foertsch]

Add $boolean parameter to Apache::TestHandler::ok and
Apache::TestHandler::ok1 Add a few bits of documentation [Torsten
Foertsch]

Apache::TestHandler forgot to require Apache2::RequestRec [Torsten
Foertsch]

Re: Problem with long http request generation time - process restarting

2012-01-28T17:49:00.001-08:00

Thanks Hans - that fits with what I'm seeing (including no connection with Oracle).

I had previously discovered that including DateTime in a handler made it crash at start-up (actually using DateTime wasn't actually necessary) , but didn't make the connection between that and Params::Classify partly because this crash only occurs under certain circumstances. When I later reintroduced DateTime it didn't seem to crash any more, so I never thought it would be causing this one. Oh well, live and learn...

Thanks for the response...

Andrew

On Sun, Jan 29, 2012 at 11:52 AM, Hans Scharler <hscharler@gmail.com> wrote:

The Classify.dll issue gave me much trouble to figure out. In my instance, the issue has nothing to do with the database or Oracle.

Here's what I found:

Updating DateTime to version 0.72 includes Params::Classify as a dependency.

http://search.cpan.org/~drolsky/DateTime-0.72/

Also, DateTime-TimeZone version 1.40 also includes Params::Classify.

When Classify.dll gets onto a Windows installation of mod_perl, Apache will crash/restart often. Regular Perl is fine.

The latest DateTime and DateTime-TimeZone modules that work with mod_perl are DateTime 0.70 and DateTime-TimeZone 1.34.

I spend a few days troubleshooting Classify.dll and the only way I could get it to work was to remove it and use older versions of DateTime.

I hope this helps you out.

Cheers,
Hans
On Fri, Jan 27, 2012 at 5:44 PM, Perrin Harkins <perrin@elem.com> wrote:
Sorry, just a clumsy cell phone touch.

- Perrin
On Jan 27, 2012 5:42 PM, "Perrin Harkins" <perrin@elem.com> wrote:
- Perrin
On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <amerton.signup@gmail.com> wrote:
On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
Thanks for the responses :)  However - I just read another thread somewhere that made me think of looking in the Event log.  It appears that the culprit is Oracle - there are errors naming OraOCIEI11.dll as the "Faulting Module name". 
	That's very interesting.  Windows Event Viewer is a good place to  look (I keep forgetting about it as I'm used to /var/log/messages in  Unix/Linux and similar environments). 
Well. It turns out that in this case the event log was actually a red herring. By creating another Apache instance (to avoid breaking the "production" server :)) and stripping out all references to Oracle, DBI, DBD etc from both httpd.conf and the Perl, I have determined that the problem has nothing to do with Oracle.

After doing that, I was getting exception code 0xC00000FD (Stack overflow) in Classify.dll (Params::Classify?) so I tried setting the ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown according to the Event log.

I think I'm going mad.

Is there a way to make Apache/mod_perl (on Windows 7) give me a stack dump when the child process exits? Al I get in the log is the "Parent: child process exited ..." message, which is not very helpful. I have downloaded the -symbols.zip files from ActiveState and installed them in the proper directories (alongside their .dlls), but then realised that I'm not getting the equivalent of a core dump file to analyze. The Event log points to a directory containing only a text file (*.wer) which doesn't have anything useful AFAICS...

Andrew

Re: mod perl installed but not running

2012-01-28T15:44:00.000-08:00

Try one of the examples on this page:

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

On Saturday, January 28, 2012 at 2:32 PM, mike cardeiro wrote:

> I installed mod_perl, tested it, added "LoadModule perl_module /usr/local/apache/modules/mod_perl.so" to httpd.conf
>
> apache restarts but when I look at the Environment variable as well as the server headers when I make a request, no mod perl.
>
> I am running linux, Apache2 mod_perl2. any ideas...I am sure at one point it was running, and I have been playing around with prreloading various modules it is no longer working (i think).
>
> Mike Cardeiro

Re: Problem with long http request generation time - process restarting

2012-01-28T14:52:00.000-08:00

The Classify.dll issue gave me much trouble to figure out. In my instance, the issue has nothing to do with the database or Oracle.

Here's what I found:

Updating DateTime to version 0.72 includes Params::Classify as a dependency.

http://search.cpan.org/~drolsky/DateTime-0.72/

Also, DateTime-TimeZone version 1.40 also includes Params::Classify.

When Classify.dll gets onto a Windows installation of mod_perl, Apache will crash/restart often. Regular Perl is fine.

The latest DateTime and DateTime-TimeZone modules that work with mod_perl are DateTime 0.70 and DateTime-TimeZone 1.34.

I spend a few days troubleshooting Classify.dll and the only way I could get it to work was to remove it and use older versions of DateTime.

I hope this helps you out.

Cheers,

Hans

On Fri, Jan 27, 2012 at 5:44 PM, Perrin Harkins <perrin@elem.com> wrote:

Sorry, just a clumsy cell phone touch.

- Perrin
On Jan 27, 2012 5:42 PM, "Perrin Harkins" <perrin@elem.com> wrote:
- Perrin
On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <amerton.signup@gmail.com> wrote:
On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
Thanks for the responses :)  However - I just read another thread somewhere that made me think of looking in the Event log.  It appears that the culprit is Oracle - there are errors naming OraOCIEI11.dll as the "Faulting Module name". 
	That's very interesting.  Windows Event Viewer is a good place to  look (I keep forgetting about it as I'm used to /var/log/messages in  Unix/Linux and similar environments). 
Well. It turns out that in this case the event log was actually a red herring. By creating another Apache instance (to avoid breaking the "production" server :)) and stripping out all references to Oracle, DBI, DBD etc from both httpd.conf and the Perl, I have determined that the problem has nothing to do with Oracle.

After doing that, I was getting exception code 0xC00000FD (Stack overflow) in Classify.dll (Params::Classify?) so I tried setting the ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown according to the Event log.

I think I'm going mad.

Is there a way to make Apache/mod_perl (on Windows 7) give me a stack dump when the child process exits? Al I get in the log is the "Parent: child process exited ..." message, which is not very helpful. I have downloaded the -symbols.zip files from ActiveState and installed them in the proper directories (alongside their .dlls), but then realised that I'm not getting the equivalent of a core dump file to analyze. The Event log points to a directory containing only a text file (*.wer) which doesn't have anything useful AFAICS...

Andrew

mod perl installed but not running

2012-01-28T14:32:00.000-08:00

I installed mod_perl, tested it, added "LoadModule perl_module /usr/local/apache/modules/mod_perl.so" to httpd.conf

apache restarts but when I look at the Environment variable as well as the server headers when I make a request, no mod perl.

I am running linux, Apache2 mod_perl2. any ideas...I am sure at one point it was running, and I have been playing around with prreloading various modules it is no longer working (i think).

Mike Cardeiro

Re: Problem with long http request generation time - process restarting

2012-01-27T14:44:00.001-08:00

Sorry, just a clumsy cell phone touch.

- Perrin

On Jan 27, 2012 5:42 PM, "Perrin Harkins" <perrin@elem.com> wrote:

- Perrin
On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <amerton.signup@gmail.com> wrote:
On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
Thanks for the responses :)  However - I just read another thread somewhere that made me think of looking in the Event log.  It appears that the culprit is Oracle - there are errors naming OraOCIEI11.dll as the "Faulting Module name". 
 	That's very interesting.  Windows Event Viewer is a good place to  look (I keep forgetting about it as I'm used to /var/log/messages in  Unix/Linux and similar environments). 
Well. It turns out that in this case the event log was actually a red herring. By creating another Apache instance (to avoid breaking the "production" server :)) and stripping out all references to Oracle, DBI, DBD etc from both httpd.conf and the Perl, I have determined that the problem has nothing to do with Oracle.

After doing that, I was getting exception code 0xC00000FD (Stack overflow) in Classify.dll (Params::Classify?) so I tried setting the ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown according to the Event log.

I think I'm going mad.

Is there a way to make Apache/mod_perl (on Windows 7) give me a stack dump when the child process exits? Al I get in the log is the "Parent: child process exited ..." message, which is not very helpful. I have downloaded the -symbols.zip files from ActiveState and installed them in the proper directories (alongside their .dlls), but then realised that I'm not getting the equivalent of a core dump file to analyze. The Event log points to a directory containing only a text file (*.wer) which doesn't have anything useful AFAICS...

Andrew

Re: Problem with long http request generation time - process restarting

2012-01-27T14:42:00.000-08:00

- Perrin

On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <amerton.signup@gmail.com> wrote:

On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
Thanks for the responses :)  However - I just read another thread somewhere that made me think of looking in the Event log.  It appears that the culprit is Oracle - there are errors naming OraOCIEI11.dll as the "Faulting Module name". 
 	That's very interesting.  Windows Event Viewer is a good place to  look (I keep forgetting about it as I'm used to /var/log/messages in  Unix/Linux and similar environments). 
Well. It turns out that in this case the event log was actually a red herring. By creating another Apache instance (to avoid breaking the "production" server :)) and stripping out all references to Oracle, DBI, DBD etc from both httpd.conf and the Perl, I have determined that the problem has nothing to do with Oracle.

After doing that, I was getting exception code 0xC00000FD (Stack overflow) in Classify.dll (Params::Classify?) so I tried setting the ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown according to the Event log.

I think I'm going mad.

Is there a way to make Apache/mod_perl (on Windows 7) give me a stack dump when the child process exits? Al I get in the log is the "Parent: child process exited ..." message, which is not very helpful. I have downloaded the -symbols.zip files from ActiveState and installed them in the proper directories (alongside their .dlls), but then realised that I'm not getting the equivalent of a core dump file to analyze. The Event log points to a directory containing only a text file (*.wer) which doesn't have anything useful AFAICS...

Andrew

Re: Registry and CGI::Carp

2012-01-27T14:23:00.000-08:00

Jim,

Thanks for your reply. Yes, that was my post to perlmonks. set_progname() is a function in the Carp module that lets you set/reset the name of the Carping script; that way you know which script generated the logged event. Another way is to pass "name=scriptX" to 'use CGI::Carp'.

> seeing problems with the logging. The message that is logged is correct,
> however the name of the script that generated the event is not.

The question above was implied; sorry, not ideal for this format. Being more explicit:

"What is the best way to get CGI::Carp to accurately log the names of Carping Registry scripts?"

Regarding END{}, my inconclusive tests support this:

http://perl.apache.org/docs/2.0/api/ModPerl/Registry.html#C_END__Blocks

Brett

From: Jim Schueler <jschueler@eloquency.com>
To: Brett Lee <brettlee@yahoo.com>
Cc: modperl <modperl@perl.apache.org>
Sent: Friday, January 27, 2012 2:11 PM
Subject: Re: Registry and CGI::Carp

There's no question or anything resembling a request in your email. So my response may waste a lot of time.

Is this your original post?
http://www.perlmonks.org/?node_id=949773

If so, I might be able to help.

Admittedly, I can't follow the thread. The PerlMonds responder refers to a function set_progname(). But I can't figure out what that refers to.

However, in the third exchange, you referenced a problem I have some experience with: Apache::Registry executes the BEGIN{} block once, and the END{} block repeatedly. Fundamentally, the Perl specification expects them to be balanced, and I'm still amazed at this shortcoming. I wrote a workaround that might get you over your hurdle. Please check out Apache::ChildExit.

I'm amazed that my solution wasn't generally adopted. As you note, it seems like this would be a pretty common scenario. Give it a try, and please let me know whether this solution gives you any traction.

Cheers!

-Jim

On Fri, 27 Jan 2012, Brett Lee wrote:

> Hi Folks,
>
> Running several scripts under ModPerl::Registry that use CGI::Carp. Am
> seeing problems with the logging. The message that is logged is correct,
> however the name of the script that generated the event is not.
>
> Each script contains a line similar to:
>
> use CGI::Carp qw(name=my_script_X);
>
> When the scripts are precompiled in startup.pl, the *same* script name is
> logged for each and every script. When scripts are not precompiled the name
> is frequently correct, but it is not correct all of the time.
>
> A post earlier to Perl Monks came back with the suggestion to extend
> CGI::Carp.pm to support running under Registry. As what I am trying to do
> seems like it would be a pretty common scenario, am thinking there may be
> another option.
>
> Thanks for considering this one.
> Brett
>
>

Re: Registry and CGI::Carp

2012-01-27T13:11:00.001-08:00

There's no question or anything resembling a request in your email. So my
response may waste a lot of time.

Is this your original post?
http://www.perlmonks.org/?node_id=949773

If so, I might be able to help.

Admittedly, I can't follow the thread. The PerlMonds responder refers to
a function set_progname(). But I can't figure out what that refers to.

However, in the third exchange, you referenced a problem I have some
experience with: Apache::Registry executes the BEGIN{} block once, and
the END{} block repeatedly. Fundamentally, the Perl specification expects
them to be balanced, and I'm still amazed at this shortcoming. I wrote a
workaround that might get you over your hurdle. Please check out
Apache::ChildExit.

I'm amazed that my solution wasn't generally adopted. As you note, it
seems like this would be a pretty common scenario. Give it a try, and
please let me know whether this solution gives you any traction.

Cheers!

-Jim

On Fri, 27 Jan 2012, Brett Lee wrote:

> Hi Folks,
>
> Running several scripts under ModPerl::Registry that use CGI::Carp. Am
> seeing problems with the logging. The message that is logged is correct,
> however the name of the script that generated the event is not.
>
> Each script contains a line similar to:
>
> use CGI::Carp qw(name=my_script_X);
>
> When the scripts are precompiled in startup.pl, the *same* script name is
> logged for each and every script. When scripts are not precompiled the name
> is frequently correct, but it is not correct all of the time.
>
> A post earlier to Perl Monks came back with the suggestion to extend
> CGI::Carp.pm to support running under Registry. As what I am trying to do
> seems like it would be a pretty common scenario, am thinking there may be
> another option.
>
> Thanks for considering this one.
> Brett
>
>

Registry and CGI::Carp

2012-01-27T10:07:00.000-08:00

Hi Folks,

Running several scripts under ModPerl::Registry that use CGI::Carp. Am seeing problems with the logging. The message that is logged is correct, however the name of the script that generated the event is not.

Each script contains a line similar to:

use CGI::Carp qw(name=my_script_X);

When the scripts are precompiled in startup.pl, the *same* script name is logged for each and every script. When scripts are not precompiled the name is frequently correct, but it is not correct all of the time.

A post earlier to Perl Monks came back with the suggestion to extend CGI::Carp.pm to support running under Registry. As what I am trying to do seems like it would be a pretty common scenario, am thinking there may be another option.

Thanks for considering this one.
Brett

Re: Problem with long http request generation time - process restarting

2012-01-26T15:39:00.000-08:00

> I was getting exception code 0xC00000FD (Stack overflow) in Classify.dll (Params::Classify?)

Well. This goes to show that desperation is the mother of invention :)

I went so far as to look at the code for Params::Classify, and noticed that there is a pure Perl version if the XS load fails, so I renamed the Perl/site/lib/auto/Params/Classify directory to ClassifyXXX and restarted the server.

Now it hasn't failed at all, even when I use my previously guaranteed-to-fail test case (triggering 5 simultaneous connections).

So according to this "solution" there must be non-thread-safe code in Classify.dll which is sometimes turning all infinitely-recursive on me...

Hope I'm not suffering from premature solution declaration (i.e. it'll crash again as soon as I post this), but it looks like for me it is fixed, although there may be something that needs to be looked at in the .dll?

Cheers,

Andrew Merton

RE: mod_perl.so: undefined symbol: PL_tainting

2012-01-26T08:17:00.001-08:00

Recompiling perl and producing a shared library seems to have worked. Thanks!

-----Original Message-----
From: Dave Hodgkinson [mailto:davehodg@gmail.com]
Sent: Wednesday, January 25, 2012 3:50 PM
To: Jacobs, David (NIH/NCI) [C]
Cc: modperl@perl.apache.org
Subject: Re: mod_perl.so: undefined symbol: PL_tainting

The copiousness of the ld fail suggested something fundamental missing to me.

Was there a .so in your perl tree?

On 25 Jan 2012, at 20:03, Jacobs, David (NIH/NCI) [C] wrote:

Re: mod_perl and mod_rewrite can work together ?

2012-01-26T06:21:00.001-08:00

On Thursday, 26 January 2012 13:02:09 Idel Fuschini wrote:
> $f->headers_out->set(Location => $location);

err_headers_out?

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net

ap_get_brigade failed during prefetch

2012-01-26T05:44:00.000-08:00

Hello, I am running apache2-mpm-prefork on ubuntu 11.04 with mod_perl. I have
googled as much as possible and it seems that in most cases its when there
is an upload that times out. I am not uploading anything but small json
objects. I only see this in my logs I have not been able to recreate it. The
one person I know who has this issue uses ie9 but google chrome is fine. Any
suggestions? I am at a loss.

(70007)The timeout specified has expired: ap_get_brigade failed during
prefetch, referer: http://mysite.com/home?sid=e76840b3a6f36e7c1a23c86812368

--
View this message in context: http://old.nabble.com/ap_get_brigade-failed-during-prefetch-tp33207456p33207456.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: mod_perl and mod_rewrite can work together ?

2012-01-26T05:15:00.000-08:00

I do not use the httpd.conf to redirect instead I use the following code:

use Apache2::Const qw(HTTP_MOVED_TEMPORARILY);

$r->headers_out->add(Location => "http://someplace.come/index.html?iphone=yes");
$r->status( HTTP_MOVED_TEMPORARILY);
return HTTP_MOVED_TEMPORARILY;

From: Idel Fuschini <idel.fuschini@gmail.com>
Date: Thu, 26 Jan 2012 07:02:09 -0500
To: modperl List <modperl@perl.apache.org>
Subject: mod_perl and mod_rewrite can work together ?

I've got this issue, in httpd.conf:

PerlTransHandler +Apache2::MyRedirect

RewriteRule ^/$ /home/index.html [R=301]

my mod_perl2 module in some condition need to redirect the browser to another site. But my web server ignored my module.

This is the code:

use Apache2::RequestRec ();

use Apache2::RequestUtil ();

use Apache2::SubRequest ();

use Apache2::Log;

use Apache2::Filter ();

use APR::Table ();

use LWP::Simple;

use Apache2::Const -compile => qw(OK REDIRECT DECLINED);

sub handler {

my $f = shift;

my $return_value=Apache2::Const::DECLINED;

my $user_agent=lc($f->headers_in->{'User-Agent'}|| '');

if ($user_agent =~ m/iphone/i) {

$f->headers_out->set(Location => $location);

$f->status(Apache2::Const::REDIRECT);

$return_value=Apache2::Const::REDIRECT;

}

return $return_value;

}

What is wrong, it's possible to do ?

thanks

Idel
=====================
E-Mail: idel.fuschini@gmail.com
Web Site: http://www.idelfuschini.it
AMF project: http://www.apachemobilefilter.org

AMF wiki: Apache Mobile Filter - http:/wiki.apachemobilefilter.org

mod_perl and mod_rewrite can work together ?

2012-01-26T04:02:00.001-08:00

I've got this issue, in httpd.conf:

PerlTransHandler +Apache2::MyRedirect

RewriteRule ^/$ /home/index.html [R=301]

my mod_perl2 module in some condition need to redirect the browser to another site. But my web server ignored my module.

This is the code:

use Apache2::RequestRec ();

use Apache2::RequestUtil ();

use Apache2::SubRequest ();

use Apache2::Log;

use Apache2::Filter ();

use APR::Table ();

use LWP::Simple;

use Apache2::Const -compile => qw(OK REDIRECT DECLINED);

sub handler {

my $f = shift;

my $return_value=Apache2::Const::DECLINED;

my $user_agent=lc($f->headers_in->{'User-Agent'}|| '');

if ($user_agent =~ m/iphone/i) {

$f->headers_out->set(Location => $location);

$f->status(Apache2::Const::REDIRECT);

$return_value=Apache2::Const::REDIRECT;

}

return $return_value;

}

What is wrong, it's possible to do ?

thanks

Idel
=====================
E-Mail: idel.fuschini@gmail.com
Web Site: http://www.idelfuschini.it
AMF project: http://www.apachemobilefilter.org

AMF wiki: Apache Mobile Filter - http:/wiki.apachemobilefilter.org

Font Problem

2012-01-26T00:01:00.000-08:00

Hi There,

I have a probem using webfonts in Firefox. It won't let me use webfonts
from another url than the original. Since i am working with a
perlhandler that "catches" all requests from / and up, i would like to
know of someone knows how i can bypass my handler for a specific
directory above / like for example /fonts/. It would be nice if the
handler can be told to handle all requests bot not for /fonts/ and pass
this request to apache....

Hoping for some help here....

Kindest regards,

Michel

Re: mod_perl.so: undefined symbol: PL_tainting

2012-01-25T12:50:00.001-08:00

The copiousness of the ld fail suggested something fundamental missing to me.

Was there a .so in your perl tree?

On 25 Jan 2012, at 20:03, Jacobs, David (NIH/NCI) [C] wrote:

> Trying that now. DOH! I understand now. Maybe that will fix it. (I hope).
>
> David Jacobs
> Senior Network Engineer,
> NCI Computer Services
> Contractor, TerpSys
> http://www.terpsys.com/
>
> Technology Driven. People Oriented.
>
>
> -----Original Message-----
> From: Jacobs, David (NIH/NCI) [C]
> Sent: Wednesday, January 25, 2012 2:45 PM
> To: Dave Hodgkinson
> Cc: modperl@perl.apache.org
> Subject: RE: mod_perl.so: undefined symbol: PL_tainting
>
> I thought it did by default... Do you have a link to how to do that?
>
>
> -----Original Message-----
> From: Dave Hodgkinson [mailto:davehodg@gmail.com]
> Sent: Wednesday, January 25, 2012 2:24 PM
> To: Jacobs, David (NIH/NCI) [C]
> Cc: modperl@perl.apache.org
> Subject: Re: mod_perl.so: undefined symbol: PL_tainting
>
> Have you compiled perl with libperl.so?
>
>
> On 25 Jan 2012, at 18:41, Jacobs, David (NIH/NCI) [C] wrote:
>
>>
>> Please help. After banging my head for a while, and trying in vain to find an answer from google, I am in need of some assistance.
>>
>> This is on rhel5, and has the redhat perl 5.8.8 rpm installed (I am
>> not the one who did that, and I cant remove it) I have compiled
>> perl-5.14.2 and mod_perl-2.0.5 Perl seems to be working fine (for both
>> versions)
>>
>> I run make test for mod_perl as a non-privileged user I get the following:
>
>
>
>

RE: mod_perl.so: undefined symbol: PL_tainting

2012-01-25T12:03:00.000-08:00

Trying that now. DOH! I understand now. Maybe that will fix it. (I hope).

David Jacobs
Senior Network Engineer,
NCI Computer Services
Contractor, TerpSys
http://www.terpsys.com/

Technology Driven. People Oriented.

-----Original Message-----
From: Jacobs, David (NIH/NCI) [C]
Sent: Wednesday, January 25, 2012 2:45 PM
To: Dave Hodgkinson
Cc: modperl@perl.apache.org
Subject: RE: mod_perl.so: undefined symbol: PL_tainting

I thought it did by default... Do you have a link to how to do that?

-----Original Message-----
From: Dave Hodgkinson [mailto:davehodg@gmail.com]
Sent: Wednesday, January 25, 2012 2:24 PM
To: Jacobs, David (NIH/NCI) [C]
Cc: modperl@perl.apache.org
Subject: Re: mod_perl.so: undefined symbol: PL_tainting

Have you compiled perl with libperl.so?

On 25 Jan 2012, at 18:41, Jacobs, David (NIH/NCI) [C] wrote:

>
> Please help. After banging my head for a while, and trying in vain to find an answer from google, I am in need of some assistance.
>
> This is on rhel5, and has the redhat perl 5.8.8 rpm installed (I am
> not the one who did that, and I cant remove it) I have compiled
> perl-5.14.2 and mod_perl-2.0.5 Perl seems to be working fine (for both
> versions)
>
> I run make test for mod_perl as a non-privileged user I get the following:

RE: mod_perl.so: undefined symbol: PL_tainting

2012-01-25T11:45:00.000-08:00

I thought it did by default... Do you have a link to how to do that?

Have you compiled perl with libperl.so?

On 25 Jan 2012, at 18:41, Jacobs, David (NIH/NCI) [C] wrote:

Re: mod_perl.so: undefined symbol: PL_tainting

2012-01-25T11:24:00.000-08:00

Have you compiled perl with libperl.so?

On 25 Jan 2012, at 18:41, Jacobs, David (NIH/NCI) [C] wrote:

>
> Please help. After banging my head for a while, and trying in vain to find an answer from google, I am in need of some assistance.
>
> This is on rhel5, and has the redhat perl 5.8.8 rpm installed (I am not the one who did that, and I cant remove it)
> I have compiled perl-5.14.2 and mod_perl-2.0.5
> Perl seems to be working fine (for both versions)
>
> I run make test for mod_perl as a non-privileged user I get the following:

mod_perl.so: undefined symbol: PL_tainting

2012-01-25T10:41:00.000-08:00

Please help. After banging my head for a while, and trying in vain to find an answer from google, I am in need of some assistance.

This is on rhel5, and has the redhat perl 5.8.8 rpm installed (I am not the one who did that, and I cant remove it)

I have compiled perl-5.14.2 and mod_perl-2.0.5

Perl seems to be working fine (for both versions)

I run make test for mod_perl as a non-privileged user I get the following:

make test

cd "src/modules/perl" && make

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/src/modules/perl'

make[1]: Nothing to be done for `all'.

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/src/modules/perl'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-Reload'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-Reload'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-SizeLimit'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-SizeLimit'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-Test'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/Apache-Test'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/ModPerl-Registry'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/ModPerl-Registry'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Base64'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Base64'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Brigade'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Brigade'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Bucket'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Bucket'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/BucketAlloc'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/BucketAlloc'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/BucketType'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/BucketType'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Date'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Date'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Error'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Error'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Finfo'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Finfo'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/IpSubnet'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/IpSubnet'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/OS'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/OS'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Pool'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Pool'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/SockAddr'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/SockAddr'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Socket'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Socket'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Status'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Status'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/String'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/String'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Table'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Table'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/ThreadMutex'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/ThreadMutex'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/ThreadRWLock'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/ThreadRWLock'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/URI'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/URI'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/UUID'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/UUID'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Util'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR/Util'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/APR'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Access'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Access'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/CmdParms'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/CmdParms'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Command'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Command'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Connection'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Connection'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ConnectionUtil'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ConnectionUtil'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Directive'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Directive'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Filter'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Filter'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/FilterRec'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/FilterRec'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/HookRun'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/HookRun'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Log'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Log'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/MPM'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/MPM'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Module'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Module'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Process'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Process'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestIO'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestIO'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestRec'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestRec'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestUtil'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/RequestUtil'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Response'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Response'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ServerRec'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ServerRec'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ServerUtil'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/ServerUtil'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/SubProcess'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/SubProcess'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/SubRequest'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/SubRequest'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/URI'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/URI'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Util'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2/Util'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/Apache2'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl/Global'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl/Global'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl/Util'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl/Util'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS/ModPerl'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/WrapXS'

make[1]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/APR'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/APR'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/Const'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/Const'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/PerlIO'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/PerlIO'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/aprext'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR/aprext'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/APR'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/Apache2'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/Apache2/Const'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/Apache2/Const'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/Apache2'

make[2]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/ModPerl'

make[3]: Entering directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/ModPerl/Const'

make[3]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/ModPerl/Const'

make[2]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs/ModPerl'

make[1]: Leaving directory `/usr/local/src/mod_perl/mod_perl-2.0.5/xs'

/usr/local/bin/perl -Iblib/arch -Iblib/lib \

t/TEST -clean

[warning] setting ulimit to allow core files

ulimit -c unlimited; /usr/local/bin/perl /usr/local/src/mod_perl/mod_perl-2.0.5/t/TEST -clean

APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \

/usr/local/bin/perl -Iblib/arch -Iblib/lib \

t/TEST -bugreport -verbose=0

[warning] setting ulimit to allow core files

ulimit -c unlimited; /usr/local/bin/perl /usr/local/src/mod_perl/mod_perl-2.0.5/t/TEST -bugreport -verbose=0

/usr/local/apache-2.2.21.x86_64/bin/httpd -d /usr/local/src/mod_perl/mod_perl-2.0.5/t -f /usr/local/src/mod_perl/mod_perl-2.0.5/t/conf/httpd.conf -D APACHE2

using Apache/2.2.21 (prefork MPM)

waiting 120 seconds for server to start: .[Wed Jan 25 13:18:10 2012] [warn] module ldap_module is already loaded, skipping

[Wed Jan 25 13:18:10 2012] [warn] module apreq_module is already loaded, skipping

httpd: Syntax error on line 97 of /usr/local/src/mod_perl/mod_perl-2.0.5/t/conf/httpd.conf: Cannot load /usr/local/src/mod_perl/mod_perl-2.0.5/src/modules/perl/mod_perl.so into server: /usr/local/src/mod_perl/mod_perl-2.0.5/src/modules/perl/mod_perl.so: undefined symbol: PL_tainting

[ error]

server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode)

sh: line 1: 27834 Terminated /usr/local/bin/perl /usr/local/src/mod_perl/mod_perl-2.0.5/t/TEST -bugreport -verbose=0

make: *** [run_tests] Error 143

I then did:

ldd -r mod_perl.so

linux-vdso.so.1 => (0x00007fffc89fc000)

libperl.so => /usr/local/lib/libperl.so (0x00002b27ee708000)

libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b27eea3f000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002b27eec57000)

libm.so.6 => /lib64/libm.so.6 (0x00002b27eee5b000)

libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b27ef0df000)

libutil.so.1 => /lib64/libutil.so.1 (0x00002b27ef317000)

libc.so.6 => /lib64/libc.so.6 (0x00002b27ef51a000)

libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b27ef873000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b27efa88000)

/lib64/ld-linux-x86-64.so.2 (0x0000003ff5000000)

undefined symbol: apr_bucket_shared_split (./mod_perl.so)

undefined symbol: apr_bucket_shared_copy (./mod_perl.so)

undefined symbol: PL_tainting (./mod_perl.so)

undefined symbol: core_module (./mod_perl.so)

undefined symbol: PL_perl_destruct_level (./mod_perl.so)

undefined symbol: PL_curstash (./mod_perl.so)

undefined symbol: PL_origenviron (./mod_perl.so)

undefined symbol: PL_defstash (./mod_perl.so)

undefined symbol: PL_patchlevel (./mod_perl.so)

undefined symbol: PL_modglobal (./mod_perl.so)

undefined symbol: PL_stack_sp (./mod_perl.so)

undefined symbol: apr_bucket_free (./mod_perl.so)

undefined symbol: ap_add_input_filter (./mod_perl.so)

undefined symbol: ap_server_root (./mod_perl.so)

undefined symbol: apr_pool_cleanup_null (./mod_perl.so)

undefined symbol: PL_localizing (./mod_perl.so)

undefined symbol: PL_op (./mod_perl.so)

undefined symbol: PL_hash_seed (./mod_perl.so)

undefined symbol: PL_markstack_max (./mod_perl.so)

undefined symbol: PL_gid (./mod_perl.so)

undefined symbol: boot_DynaLoader (./mod_perl.so)

undefined symbol: PL_markstack_ptr (./mod_perl.so)

undefined symbol: PL_tainted (./mod_perl.so)

undefined symbol: PL_uid (./mod_perl.so)

undefined symbol: ap_server_config_defines (./mod_perl.so)

undefined symbol: PL_stderrgv (./mod_perl.so)

undefined symbol: PL_euid (./mod_perl.so)

undefined symbol: PL_errgv (./mod_perl.so)

undefined symbol: PL_curstackinfo (./mod_perl.so)

undefined symbol: PL_curstack (./mod_perl.so)

undefined symbol: PL_endav (./mod_perl.so)

undefined symbol: PL_sv_undef (./mod_perl.so)

undefined symbol: ap_add_output_filter (./mod_perl.so)

undefined symbol: PL_curcop (./mod_perl.so)

undefined symbol: PL_rs (./mod_perl.so)

undefined symbol: PL_egid (./mod_perl.so)

undefined symbol: PL_diehook (./mod_perl.so)

undefined symbol: PL_tmps_floor (./mod_perl.so)

undefined symbol: apr_bucket_type_eos (./mod_perl.so)

undefined symbol: apr_bucket_type_flush (./mod_perl.so)

undefined symbol: PL_defoutgv (./mod_perl.so)

undefined symbol: PL_envgv (./mod_perl.so)

undefined symbol: PL_scopestack_ix (./mod_perl.so)

undefined symbol: PL_rehash_seed_set (./mod_perl.so)

undefined symbol: PL_rehash_seed (./mod_perl.so)

undefined symbol: PL_tmps_ix (./mod_perl.so)

undefined symbol: PL_stack_max (./mod_perl.so)

undefined symbol: PL_charclass (./mod_perl.so)

undefined symbol: PL_incgv (./mod_perl.so)

undefined symbol: PL_na (./mod_perl.so)

undefined symbol: PL_stack_base (./mod_perl.so)

undefined symbol: ap_top_module (./mod_perl.so)

undefined symbol: PL_origalen (./mod_perl.so)

undefined symbol: apr_hash_get (./mod_perl.so)

undefined symbol: apr_is_empty_table (./mod_perl.so)

undefined symbol: ap_hook_process_connection (./mod_perl.so)

undefined symbol: apr_strerror (./mod_perl.so)

undefined symbol: ap_create_per_dir_config (./mod_perl.so)

undefined symbol: ap_hook_open_logs (./mod_perl.so)

undefined symbol: ap_hook_child_init (./mod_perl.so)

undefined symbol: apr_stat (./mod_perl.so)

undefined symbol: apr_table_elts (./mod_perl.so)

undefined symbol: apr_bucket_flush_create (./mod_perl.so)

undefined symbol: apr_cpystrn (./mod_perl.so)

undefined symbol: ap_get_output_filter_handle (./mod_perl.so)

undefined symbol: ap_single_module_configure (./mod_perl.so)

undefined symbol: Perl_sv_2bool_flags (./mod_perl.so)

undefined symbol: apr_table_unset (./mod_perl.so)

undefined symbol: apr_pool_cleanup_register (./mod_perl.so)

undefined symbol: Perl_hv_eiter_p (./mod_perl.so)

undefined symbol: ap_register_output_filter (./mod_perl.so)

undefined symbol: ap_hook_insert_filter (./mod_perl.so)

undefined symbol: ap_hook_pre_connection (./mod_perl.so)

undefined symbol: ap_pass_brigade (./mod_perl.so)

undefined symbol: ap_remove_loaded_module (./mod_perl.so)

undefined symbol: ap_hook_post_read_request (./mod_perl.so)

undefined symbol: apr_uuid_get (./mod_perl.so)

undefined symbol: apr_file_read (./mod_perl.so)

undefined symbol: apr_bucket_shared_destroy (./mod_perl.so)

undefined symbol: apr_table_merge (./mod_perl.so)

undefined symbol: apr_array_push (./mod_perl.so)

undefined symbol: apr_brigade_create (./mod_perl.so)

undefined symbol: apr_vsnprintf (./mod_perl.so)

undefined symbol: apr_os_thread_current (./mod_perl.so)

undefined symbol: ap_walk_config (./mod_perl.so)

undefined symbol: apr_bucket_shared_make (./mod_perl.so)

undefined symbol: ap_hook_auth_checker (./mod_perl.so)

undefined symbol: apr_pool_create_ex (./mod_perl.so)

undefined symbol: apr_filepath_merge (./mod_perl.so)

undefined symbol: apr_bucket_free (./mod_perl.so)

undefined symbol: apr_table_compress (./mod_perl.so)

undefined symbol: ap_merge_per_dir_configs (./mod_perl.so)

undefined symbol: Perl_hv_riter_p (./mod_perl.so)

undefined symbol: apr_table_clear (./mod_perl.so)

undefined symbol: ap_build_config (./mod_perl.so)

undefined symbol: ap_mpm_query (./mod_perl.so)

undefined symbol: apr_pool_destroy (./mod_perl.so)

undefined symbol: ap_add_cgi_vars (./mod_perl.so)

undefined symbol: Perl_sys_term (./mod_perl.so)

undefined symbol: apr_table_make (./mod_perl.so)

undefined symbol: ap_hook_access_checker (./mod_perl.so)

undefined symbol: ap_scan_script_header_err_strs (./mod_perl.so)

undefined symbol: apr_file_open (./mod_perl.so)

undefined symbol: ap_getword (./mod_perl.so)

undefined symbol: ap_pcfg_open_custom (./mod_perl.so)

undefined symbol: ap_hook_header_parser (./mod_perl.so)

undefined symbol: ap_str_tolower (./mod_perl.so)

undefined symbol: apr_env_get (./mod_perl.so)

undefined symbol: ap_hook_post_config (./mod_perl.so)

undefined symbol: ap_hook_fixups (./mod_perl.so)

undefined symbol: apr_pstrndup (./mod_perl.so)

undefined symbol: ap_get_input_filter_handle (./mod_perl.so)

undefined symbol: apr_table_overlap (./mod_perl.so)

undefined symbol: apr_table_overlay (./mod_perl.so)

undefined symbol: apr_pool_userdata_get (./mod_perl.so)

undefined symbol: ap_cfg_getline (./mod_perl.so)

undefined symbol: ap_hook_translate_name (./mod_perl.so)

undefined symbol: Perl_sv_free2 (./mod_perl.so)

undefined symbol: ap_hook_handler (./mod_perl.so)

undefined symbol: apr_hash_set (./mod_perl.so)

undefined symbol: ap_check_cmd_context (./mod_perl.so)

undefined symbol: apr_pool_clear (./mod_perl.so)

undefined symbol: apr_pmemdup (./mod_perl.so)

undefined symbol: apr_psprintf (./mod_perl.so)

undefined symbol: apr_palloc (./mod_perl.so)

undefined symbol: ap_hook_check_user_id (./mod_perl.so)

undefined symbol: apr_brigade_cleanup (./mod_perl.so)

undefined symbol: apr_snprintf (./mod_perl.so)

undefined symbol: ap_get_brigade (./mod_perl.so)

undefined symbol: ap_add_common_vars (./mod_perl.so)

undefined symbol: apr_array_copy (./mod_perl.so)

undefined symbol: apr_file_write (./mod_perl.so)

undefined symbol: apr_table_setn (./mod_perl.so)

undefined symbol: ap_hook_type_checker (./mod_perl.so)

undefined symbol: apr_bucket_eos_create (./mod_perl.so)

undefined symbol: ap_add_loaded_module (./mod_perl.so)

undefined symbol: ap_cfg_closefile (./mod_perl.so)

undefined symbol: Perl_hv_common_key_len (./mod_perl.so)

undefined symbol: ap_add_version_component (./mod_perl.so)

undefined symbol: ap_log_error (./mod_perl.so)

undefined symbol: ap_hook_pre_config (./mod_perl.so)

undefined symbol: Perl_hv_fill (./mod_perl.so)

undefined symbol: apr_pool_userdata_set (./mod_perl.so)

undefined symbol: Perl_gv_add_by_type (./mod_perl.so)

undefined symbol: apr_pstrdup (./mod_perl.so)

undefined symbol: ap_internal_redirect_handler (./mod_perl.so)

undefined symbol: apr_table_copy (./mod_perl.so)

undefined symbol: apr_table_get (./mod_perl.so)

undefined symbol: apr_uuid_format (./mod_perl.so)

undefined symbol: apr_pool_tag (./mod_perl.so)

undefined symbol: apr_file_printf (./mod_perl.so)

undefined symbol: apr_hash_make (./mod_perl.so)

undefined symbol: apr_table_set (./mod_perl.so)

undefined symbol: apr_pstrcat (./mod_perl.so)

undefined symbol: apr_brigade_destroy (./mod_perl.so)

undefined symbol: ap_getword_nc (./mod_perl.so)

undefined symbol: apr_pstrmemdup (./mod_perl.so)

undefined symbol: ap_hook_map_to_storage (./mod_perl.so)

undefined symbol: Perl_newSV_type (./mod_perl.so)

undefined symbol: apr_initialize (./mod_perl.so)

undefined symbol: apr_brigade_flatten (./mod_perl.so)

undefined symbol: Perl_sys_init3 (./mod_perl.so)

undefined symbol: ap_log_rerror (./mod_perl.so)

undefined symbol: apr_bucket_alloc (./mod_perl.so)

undefined symbol: ap_register_input_filter (./mod_perl.so)

undefined symbol: ap_hook_log_transaction (./mod_perl.so)

undefined symbol: apr_array_make (./mod_perl.so)

undefined symbol: apr_file_close (./mod_perl.so)

undefined symbol: apr_bucket_pool_make (./mod_perl.so)

undefined symbol: apr_table_addn (./mod_perl.so)

undefined symbol: ap_hook_create_request (./mod_perl.so)

undefined symbol: apr_bucket_transient_create (./mod_perl.so)

Is there something I am missing? When I compile mod_perl it shows perl-5.14.2 as the perl version. Something is wrong, and of course those above me want this fixed.

Please advise.

Thanks!

David Jacobs

RE: Content-Disposition

2012-01-22T03:32:00.000-08:00

I'm all set, I had to use err_headers_out for some reason so,

$r->err_headers_out->add('Content-Disposition' => 'attachment; filename="' . $download_name . '"');

Works.

-Chris

From: cfaust-dougot [mailto:cfaust@doyougot.com]
Sent: Sun 1/22/2012 6:20 AM
To: Earle Ake; modperl@perl.apache.org
Subject: RE: Content-Disposition

Thanks for the reply Earle, I actually did try both "attachment" and "inline" and neither worked (I should have said that in the org post).

-Chris

From: Earle Ake [mailto:eake@woh.rr.com]
Sent: Sat 1/21/2012 9:19 PM
To: cfaust-dougot; modperl@perl.apache.org
Subject: RE: Content-Disposition

I have done it before using something like:

print “Content-Disposition:attachment;filename=$download_name\n”;

So maybe try:

$r->header_out( 'Content-Disposition' => 'attachment; filename="' . $download_name . '"');

From: cfaust-dougot [mailto:cfaust@doyougot.com]
Sent: Saturday, January 21, 2012 7:02 PM
To: modperl@perl.apache.org
Subject: Content-Disposition

Hello,

I'm guessing there is a real simple answer to my question but as uasual, I can't find it :)

Simply put I'm trying to create a Zip file and push it to the user using a filename I've defined. Everything works except the name of the file that comes up in the browser dialog. It always defaults to the script/location name. I thought that all I needed was Content-Disposition but that doesn't seem to be working.

CentOS 5.5, mod_perl 2.0.4, apache 2.2.3 (both mod_perl and apache should be backported via yum update).

my $zip = Archive::Zip->new();

my $member = $zip->addString('yadda yadda yadda');

my $download_name = 'download.zip';

if ( $zip->writeToFileNamed('someothernamed.zip');

open(ZIP, 'someothernamed.zip') or die "could not open sonz $!";

binmode ZIP;

my $output = do { local $/; <ZIP> };

close(ZIP);

$r->content_type('application/zip');

$r->header_out( 'Content-Disposition' => 'inline; filename="' . $download_name . '"');

$r->send_http_header;

print $output;

return Apache2::Const::OK;

}

I tried setting the header before the content_type and with and without "send_http_header". What am I doing wrong? How can I get the user to be prompted to save the file as "download.zip??

TIA!

RE: Content-Disposition

2012-01-22T03:20:00.000-08:00

Thanks for the reply Earle, I actually did try both "attachment" and "inline" and neither worked (I should have said that in the org post).

-Chris

From: Earle Ake [mailto:eake@woh.rr.com]
Sent: Sat 1/21/2012 9:19 PM
To: cfaust-dougot; modperl@perl.apache.org
Subject: RE: Content-Disposition

I have done it before using something like:

print “Content-Disposition:attachment;filename=$download_name\n”;

So maybe try:

$r->header_out( 'Content-Disposition' => 'attachment; filename="' . $download_name . '"');

From: cfaust-dougot [mailto:cfaust@doyougot.com]
Sent: Saturday, January 21, 2012 7:02 PM
To: modperl@perl.apache.org
Subject: Content-Disposition

Hello,

I'm guessing there is a real simple answer to my question but as uasual, I can't find it :)

CentOS 5.5, mod_perl 2.0.4, apache 2.2.3 (both mod_perl and apache should be backported via yum update).

my $zip = Archive::Zip->new();

my $member = $zip->addString('yadda yadda yadda');

my $download_name = 'download.zip';

if ( $zip->writeToFileNamed('someothernamed.zip');

open(ZIP, 'someothernamed.zip') or die "could not open sonz $!";

binmode ZIP;

my $output = do { local $/; <ZIP> };

close(ZIP);

$r->content_type('application/zip');

$r->header_out( 'Content-Disposition' => 'inline; filename="' . $download_name . '"');

$r->send_http_header;

print $output;

return Apache2::Const::OK;

}

I tried setting the header before the content_type and with and without "send_http_header". What am I doing wrong? How can I get the user to be prompted to save the file as "download.zip??

TIA!

RE: Content-Disposition

2012-01-21T18:19:00.001-08:00

I have done it before using something like:

print “Content-Disposition:attachment;filename=$download_name\n”;

So maybe try:

$r->header_out( 'Content-Disposition' => 'attachment; filename="' . $download_name . '"');

From: cfaust-dougot [mailto:cfaust@doyougot.com]
Sent: Saturday, January 21, 2012 7:02 PM
To: modperl@perl.apache.org
Subject: Content-Disposition

Hello,

I'm guessing there is a real simple answer to my question but as uasual, I can't find it :)

CentOS 5.5, mod_perl 2.0.4, apache 2.2.3 (both mod_perl and apache should be backported via yum update).

my $zip = Archive::Zip->new();

my $member = $zip->addString('yadda yadda yadda');

my $download_name = 'download.zip';

if ( $zip->writeToFileNamed('someothernamed.zip');

open(ZIP, 'someothernamed.zip') or die "could not open sonz $!";

binmode ZIP;

my $output = do { local $/; <ZIP> };

close(ZIP);

$r->content_type('application/zip');

$r->header_out( 'Content-Disposition' => 'inline; filename="' . $download_name . '"');

$r->send_http_header;

print $output;

return Apache2::Const::OK;

}

I tried setting the header before the content_type and with and without "send_http_header". What am I doing wrong? How can I get the user to be prompted to save the file as "download.zip??

TIA!

Content-Disposition

2012-01-21T16:02:00.000-08:00

Hello,

I'm guessing there is a real simple answer to my question but as uasual, I can't find it :)

CentOS 5.5, mod_perl 2.0.4, apache 2.2.3 (both mod_perl and apache should be backported via yum update).

my $zip = Archive::Zip->new();

my $member = $zip->addString('yadda yadda yadda');

my $download_name = 'download.zip';

if ( $zip->writeToFileNamed('someothernamed.zip');

open(ZIP, 'someothernamed.zip') or die "could not open sonz $!";

binmode ZIP;

my $output = do { local $/; <ZIP> };

close(ZIP);

$r->content_type('application/zip');

$r->header_out( 'Content-Disposition' => 'inline; filename="' . $download_name . '"');

$r->send_http_header;

print $output;

return Apache2::Const::OK;

}

I tried setting the header before the content_type and with and without "send_http_header". What am I doing wrong? How can I get the user to be prompted to save the file as "download.zip??

TIA!

RE: Reloading Apache::Registry modules without restarting Apache

2012-01-20T12:08:00.000-08:00

> In other words, it does not really make sense to expect a different lib path per virtual
> host, since the perl modules and scripts exist on a "one per process" base, not a "one per
> virtual host" base.
> Or, you have to really set the lib path dynamically, on a per-request base, not just when
> your script is first compiled.

Thx Andre.

What do you make of this page then:

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

which says:

---
If Perl used with mod_perl was built with ithreads support one can specify different @INC values for different VirtualHosts, using a combination of PerlOptions +Parent and PerlSwitches.
---

Is this wrong?

Maybe it's that my version is not compiled with ithreads support?

I know I have a thread-enabled version of perl, because when I run the following script:

---
use Config;
if ($Config{useithreads}) {
print "threads compiled"
} else {
print "NOT threads compiled"
}
---

It tells me that it IS threads compiled. But I know that there are two versions of thread support (an older one, and a newer one), and I am not sure which of the two is meant by 'built with ithreads support'.

Alain

Re: Reloading Apache::Registry modules without restarting Apache

2012-01-20T11:42:00.000-08:00

André Warnier wrote:
> Desilets, Alain wrote:
>> I'm using mod_perl on Windows 7, and am trying to set things up so
>> that I can reload my script and all the modules it uses, without
>> having to restart Apache.
>>
>> The problem is that my script (called webitext.cgi) updates the @INC
>> variable using statements like these:
>>
>> ---
>> use lib "$ENV{WEBITEXT_HOME}";
>> use lib "$ENV{WEBITEXT_HOME}/bin";
>> etc...
>> ---
>>
>> where the value of $ENV{WEBITEXT_HOME} is set differently depending on
>> the virtual host it's running on. I use this so I can have two
>> versions of my app on the server, a production and a test version,
>> each running under a different vhost which defines the env variable
>> differently (using Apache SetEnv).
>>
>> The problem is that when Apache::Reload tries to reload the modules,
>> it does not find them, because it seems to use the value of @INC as it
>> was BEFORE the script was run (i.e. not including the ones added with
>> the 'use lib' statements).
>>
>> This problem occurs whether I use the 'PerlSetVar ReloadTouchFile'
>> approach or the Apache::StatINC approach. It seems to be a well
>> documented limitation of Apache::Reload.
>>
>> So... I thought about setting the @INC path outside of the script. But
>> I need to do this on a per-vhost basis. According to this page:
>>
>> http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
>>
>>
>> I should be able to do this with something like this:
>>
>> ---
>> <VirtualHost ...>
>> ServerName webitextprod
>> PerlOptions +Parent
>> PerlSwitches -Idir1 -Idir2 etc...
>> </VirtualHost>
>> ---
>>
>> But when I tried this and ran httpd.exe -t -c httpd.conf, it crashed
>> with the dreaded "free to wrong pool" error:
>>
>> ---
>> Free to wrong pool 2b60100 not 3d4f10.
>> ---
>>
>> This error seems to be caused by the PerlOptions +Parent line.
>>
>> Any suggestion for how to fix or get around this problem would be
>> greatly appreciated.
>>
> Hi.
> I do not know much about the "reload" side of things, but something in
> the general logic of what you explain above is going against what I know
> of the Apache logic.
>
> Contrarily to what you seem to expect above, an Apache "virtual host" is
> not a separate process.
> Apache starts as a single process, and then it forks "children". Each of
> these children is a separate process. But the "virtual host identity"
> is something dynamic. Each Apache child can "become" one of the virtual
> hosts, at each request. It just "switches personality" depending on
> which Host: header is contained in the current request that it processes.
> In other words, it does not really make sense to expect a different lib
> path per virtual host, since the perl modules and scripts exist on a
> "one per process" base, not a "one per virtual host" base.
> Or, you have to really set the lib path dynamically, on a per-request
> base, not just when your script is first compiled.
>
>
Addendum :
I re-read your post, and noticed that you were under Windows. In that case, Apache does
not really "fork children", it runs threads. But the general idea above remains : each
thread will adopt the personality of the virtual host corresponding to the Host: header of
the current request. Things may even be a little bit more confusing; I am not sure, but I
think that if you change the lib path on-the-fly in one thread, it may even affect all
threads currently running.

Re: Reloading Apache::Registry modules without restarting Apache

2012-01-20T11:32:00.000-08:00

Desilets, Alain wrote:
> I'm using mod_perl on Windows 7, and am trying to set things up so that I can reload my script and all the modules it uses, without having to restart Apache.
>
> The problem is that my script (called webitext.cgi) updates the @INC variable using statements like these:
>
> ---
> use lib "$ENV{WEBITEXT_HOME}";
> use lib "$ENV{WEBITEXT_HOME}/bin";
> etc...
> ---
>
> where the value of $ENV{WEBITEXT_HOME} is set differently depending on the virtual host it's running on. I use this so I can have two versions of my app on the server, a production and a test version, each running under a different vhost which defines the env variable differently (using Apache SetEnv).
>
> The problem is that when Apache::Reload tries to reload the modules, it does not find them, because it seems to use the value of @INC as it was BEFORE the script was run (i.e. not including the ones added with the 'use lib' statements).
>
> This problem occurs whether I use the 'PerlSetVar ReloadTouchFile' approach or the Apache::StatINC approach. It seems to be a well documented limitation of Apache::Reload.
>
> So... I thought about setting the @INC path outside of the script. But I need to do this on a per-vhost basis. According to this page:
>
> http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost
>
> I should be able to do this with something like this:
>
> ---
> <VirtualHost ...>
> ServerName webitextprod
> PerlOptions +Parent
> PerlSwitches -Idir1 -Idir2 etc...
> </VirtualHost>
> ---
>
> But when I tried this and ran httpd.exe -t -c httpd.conf, it crashed with the dreaded "free to wrong pool" error:
>
> ---
> Free to wrong pool 2b60100 not 3d4f10.
> ---
>
> This error seems to be caused by the PerlOptions +Parent line.
>
> Any suggestion for how to fix or get around this problem would be greatly appreciated.
>
Hi.
I do not know much about the "reload" side of things, but something in the general logic
of what you explain above is going against what I know of the Apache logic.

Contrarily to what you seem to expect above, an Apache "virtual host" is not a separate
process.
Apache starts as a single process, and then it forks "children". Each of these children is
a separate process. But the "virtual host identity" is something dynamic. Each Apache
child can "become" one of the virtual hosts, at each request. It just "switches
personality" depending on which Host: header is contained in the current request that it
processes.
In other words, it does not really make sense to expect a different lib path per virtual
host, since the perl modules and scripts exist on a "one per process" base, not a "one per
virtual host" base.
Or, you have to really set the lib path dynamically, on a per-request base, not just when
your script is first compiled.

Reloading Apache::Registry modules without restarting Apache

2012-01-20T09:49:00.000-08:00

I'm using mod_perl on Windows 7, and am trying to set things up so that I can reload my script and all the modules it uses, without having to restart Apache.

The problem is that my script (called webitext.cgi) updates the @INC variable using statements like these:

---
use lib "$ENV{WEBITEXT_HOME}";
use lib "$ENV{WEBITEXT_HOME}/bin";
etc...
---

where the value of $ENV{WEBITEXT_HOME} is set differently depending on the virtual host it's running on. I use this so I can have two versions of my app on the server, a production and a test version, each running under a different vhost which defines the env variable differently (using Apache SetEnv).

The problem is that when Apache::Reload tries to reload the modules, it does not find them, because it seems to use the value of @INC as it was BEFORE the script was run (i.e. not including the ones added with the 'use lib' statements).

This problem occurs whether I use the 'PerlSetVar ReloadTouchFile' approach or the Apache::StatINC approach. It seems to be a well documented limitation of Apache::Reload.

So... I thought about setting the @INC path outside of the script. But I need to do this on a per-vhost basis. According to this page:

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

I should be able to do this with something like this:

---
<VirtualHost ...>
ServerName webitextprod
PerlOptions +Parent
PerlSwitches -Idir1 -Idir2 etc...
</VirtualHost>
---

But when I tried this and ran httpd.exe -t -c httpd.conf, it crashed with the dreaded "free to wrong pool" error:

---
Free to wrong pool 2b60100 not 3d4f10.
---

This error seems to be caused by the PerlOptions +Parent line.

Any suggestion for how to fix or get around this problem would be greatly appreciated.

Thx.

Alain Désilets

Re: preloading modules and apache::dbi

2012-01-19T09:59:00.001-08:00

On Thu, Jan 19, 2012 at 8:48 AM, Josh Narins <jnarins@seniorbridge.com> wrote:
> The idea of Apache::DBI is that you get to pool connections.
>
> If you call Apache::DBI->new and there is a spare connection, you get it, if not, one is created for you.

That's a little misleading. There's no actual pooling. Connections
can't be shared between processes or threads.

What Apache::DBI does is keep connections that you open around in a
global hash, and if you ask for another connection with the same
parameters it gives you back the one you already opened. There will
never be two connections with the same parameters. I like to call it
persistence, not pooling.

- Perrin

Re: preloading modules and apache::dbi

2012-01-19T06:41:00.001-08:00

> From: Perrin Harkins <perrin@elem.com>

> However, if you are trying to make the handle persistent
>yourself, by putting it in a global variable or something similar,
>that will be a problem. You have to close all connections you open
>during startup, and open new ones in the child processes.
>

heres kinda sorta whats going on. The library Main.pm is preloaded at apache startup. it exports a variable $dbh which is empty.

When a cgi script runs and uses Main.pm it runs an initialize subroutine from Main.pm. In that subroutine the $dbh variable gets the return from DBI::connect.

Since Main.pm is preloaded in apache startup, is there 1 $dbh variable shared amongst all httpd processes; or does each process have it's own $dbh variable?

Re: preloading modules and apache::dbi

2012-01-19T06:29:00.001-08:00

On 01/19/2012 08:48 AM, Josh Narins wrote:
> The idea of Apache::DBI is that you get to pool connections.
>
> If you call Apache::DBI->new and there is a spare connection, you get
> it, if not, one is created for you.

This isn't quite accurate. Apache::DBI doesn't do connection pooling, it
manages persistent connections. It's still one connection per-process
(per connection attributes) and connections aren't shared between child
processes (that's where things get messy).

Apache::DBI makes sure you don't create more connections than needed and
makes sure that the persistent connections are still connected before
handing them back.

> You almost certainly don't want one $db object being shared as a member
> of a class, unless your entire program also happens to represent one DB
> transaction.

This is actually a pretty common and ok pattern. Remember that execution
through a request is still linear (not threaded or handled by multiple
processes) so if you want your whole request to be a single transaction
you can, or if you want it to auto-commit you can, or if you want it to
be a mix of transactions and auto-committed statements, you can do that too.

When you use Apache::DBI and then call DBI->connect or
DBI->connect_cached you'll get the same database connection every time
(per process of course).

--
Michael Peters
Plus Three, LP

RE: preloading modules and apache::dbi

2012-01-19T05:48:00.001-08:00

The idea of Apache::DBI is that you get to pool connections.

If you call Apache::DBI->new and there is a spare connection, you get it, if not, one is created for you.

You almost certainly don't want one $db object being shared as a member of a class, unless your entire program also happens to represent one DB transaction.

Josh Narins
Director of Application Development
SeniorBridge

845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Fax: (212) 994-4260
Mobile: (917) 488-6248
jnarins@seniorbridge.com
seniorbridge.com

SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.

From: mike cardeiro [mailto:mcardeiro@yahoo.com]
Sent: Wednesday, January 18, 2012 5:08 PM
To: modper
Subject: preloading modules and apache::dbi

Hi,

I am totally new to mod perl (after 13+ years of building web applications on shared servers I now am developing on a dedicated box woo-hoo)

I have installed apache::dbi and set it to preload in the apache config file. Here is what I think my problem might be.

I have a library I want to preload. This library makes a database connection and assigns it to a variable that is exported so all programs can use this handle.

will this global handle db handle be a single handle amongst all apache processes, or will each process load this library on its own thus having a unique db handle for each httpd process?

sorry if this is incoherent.

Mike Cardeiro

Re: Problem withe memcached inside the handler

2012-01-19T03:57:00.002-08:00

Another information, in other platform working well

Idel

On 19 January 2012 12:50, Idel Fuschini <idel.fuschini@gmail.com> wrote:

Hi I've got this simple module:

#file:Apache2/AMFTest.pm;
#--------------------------------

#
# Created by Idel Fuschini
# Date: 01/08/10
# Site: http://www.apachemobilefilter.org
# Mail: idel.fuschini@gmail.com

package Apache2::AMFTest;

use strict;
use warnings;
use Apache2::AMFCommonLib ();
use Cache::Memcached;
use Apache2::RequestRec ();
use Apache2::RequestUtil ();
use Apache2::SubRequest ();
use Apache2::Log;
use Apache2::Filter ();
use Apache2::Connection ();
use APR::Table ();
use Apache2::Const -compile => qw(OK REDIRECT DECLINED);
use constant BUFF_LEN => 1024;
use vars qw($VERSION);
$VERSION= "3.50";
#
# Define the global environment
#
my $memd = new Cache::Memcached {
    'debug' => 2,
    'compress_threshold' => 10_000,
    'enable_compress' => 1,
};
my $server="localhost:11211";
my @Server = split(/,/, $server);
$memd->set_servers(\@Server);
$memd->set('AMFtest','test');
if ($memd->get('AMFtest')) {
   print "OK: >".$memd->get('AMFtest')."<\n";
} else {
   print "KO";
   exit;
}

sub handler    {
    my $f = shift;
    my $user_agent=$f->headers_in->{'User-Agent'}|| '';
    my $x_user_agent=$f->headers_in->{'X-Device-User-Agent'}|| '';
    $f->log->warn("AMFTest - User_Agent:$user_agent");
    $f->log->warn("AMFTest - Try to connect");
    my $result=$memd->get('AMFtest');
    $f->log->warn("AMFTest - Finish to connect the result is:".$result);
    return Apache2::Const::DECLINED;
}

And this is the error log:

[Thu Jan 19 12:43:58 2012] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
Cache::Memcache: set AMFtest = test (set AMFtest 0 0 4
test)
processing socket GLOB(0x209264b0)
MemCache: got AMFtest = test
processing socket GLOB(0x209264b0)
MemCache: got AMFtest = test
[Thu Jan 19 12:43:58 2012] [notice] Digest: generating secret for digest authentication ...
[Thu Jan 19 12:43:58 2012] [notice] Digest: done
Cache::Memcache: set AMFtest = test (set AMFtest 0 0 4
test)
processing socket GLOB(0x20236b40)
MemCache: got AMFtest = test
processing socket GLOB(0x20236b40)
MemCache: got AMFtest = test
[Thu Jan 19 12:43:59 2012] [notice] Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/1.0.0e DAV/2 mod_perl/2.0.5 Perl/v5.8.8 configured -- resuming normal operations
[Thu Jan 19 12:44:59 2012] [warn] [client 10.5.31.85] AMFTest - User_Agent:Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
[Thu Jan 19 12:44:59 2012] [warn] [client 10.5.31.85] AMFTest - Try to connect
[Thu Jan 19 12:44:59 2012] [error] [client 10.5.31.85] No map found matching for GLOB(0x202fee10) at /usr/lib/perl5/site_perl/5.8.8/Cache/Memcached.pm line 717.\n

So outside the handler is connecting correctly, but when inside the handler I've got this problem (the line in red color), I don't think is a memcached problem.

The version of S.O. is:

Red Hat Enterprise Linux Server release 5.6 (Tikanga)

thanks
Idel
=====================
E-Mail: idel.fuschini@gmail.com
Web Site: http://www.idelfuschini.it
AMF project: http://www.apachemobilefilter.org
AMF wiki: Apache Mobile Filter - http:/wiki.apachemobilefilter.org
------
La presente comunicazione ed i suoi allegati e' destinata esclusivamente
ai destinatari. Qualsiasi suo utilizzo, comunicazione o diffusione non autorizzata
e' proibita. Se ha ricevuto questa comunicazione per errore, la preghiamo di darne
immediata comunicazione al mittente e di cancellare tutte le informazioni
erroneamente acquisite. (Rif. D.Lgs. 196/2003). Grazie

This message and its attachments are intended only for use by the addressees. Any use,
re-transmission or dissemination not authorized of it is prohibited. If you received
this e-mail in error, please inform the sender immediately and delete all the material.
(Rif. D.Lgs. 196/2003). Thank you.

Re: preloading modules and apache::dbi

2012-01-19T03:57:00.001-08:00

On Wed, Jan 18, 2012 at 5:08 PM, mike cardeiro <mcardeiro@yahoo.com> wrote:
> I have a library I want to preload. This library makes a database
> connection and assigns it to a variable that is exported so all programs can
> use this handle.
>
> will this global handle db handle be a single handle amongst all apache
> processes, or will each process load this library on its own thus having a
> unique db handle for each httpd process?

Apache::DBI does not make handles persistent when you open them during
startup. However, if you are trying to make the handle persistent
yourself, by putting it in a global variable or something similar,
that will be a problem. You have to close all connections you open
during startup, and open new ones in the child processes.

- Perrin

Problem withe memcached inside the handler

2012-01-19T03:50:00.001-08:00

Hi I've got this simple module:

#file:Apache2/AMFTest.pm;
#--------------------------------

#
# Created by Idel Fuschini
# Date: 01/08/10
# Site: http://www.apachemobilefilter.org
# Mail: idel.fuschini@gmail.com

package Apache2::AMFTest;

use strict;
use warnings;
use Apache2::AMFCommonLib ();
use Cache::Memcached;
use Apache2::RequestRec ();
use Apache2::RequestUtil ();
use Apache2::SubRequest ();
use Apache2::Log;
use Apache2::Filter ();
use Apache2::Connection ();
use APR::Table ();
use Apache2::Const -compile => qw(OK REDIRECT DECLINED);
use constant BUFF_LEN => 1024;
use vars qw($VERSION);
$VERSION= "3.50";
#
# Define the global environment
#
my $memd = new Cache::Memcached {
    'debug' => 2,
    'compress_threshold' => 10_000,
    'enable_compress' => 1,
};
my $server="localhost:11211";
my @Server = split(/,/, $server);
$memd->set_servers(\@Server);
$memd->set('AMFtest','test');
if ($memd->get('AMFtest')) {
   print "OK: >".$memd->get('AMFtest')."<\n";
} else {
   print "KO";
   exit;
}

sub handler    {
    my $f = shift;
    my $user_agent=$f->headers_in->{'User-Agent'}|| '';
    my $x_user_agent=$f->headers_in->{'X-Device-User-Agent'}|| '';
    $f->log->warn("AMFTest - User_Agent:$user_agent");
    $f->log->warn("AMFTest - Try to connect");
    my $result=$memd->get('AMFtest');
    $f->log->warn("AMFTest - Finish to connect the result is:".$result);
    return Apache2::Const::DECLINED;
}

And this is the error log:

[Thu Jan 19 12:43:58 2012] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
Cache::Memcache: set AMFtest = test (set AMFtest 0 0 4
test)
processing socket GLOB(0x209264b0)
MemCache: got AMFtest = test
processing socket GLOB(0x209264b0)
MemCache: got AMFtest = test
[Thu Jan 19 12:43:58 2012] [notice] Digest: generating secret for digest authentication ...
[Thu Jan 19 12:43:58 2012] [notice] Digest: done
Cache::Memcache: set AMFtest = test (set AMFtest 0 0 4
test)
processing socket GLOB(0x20236b40)
MemCache: got AMFtest = test
processing socket GLOB(0x20236b40)
MemCache: got AMFtest = test
[Thu Jan 19 12:43:59 2012] [notice] Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/1.0.0e DAV/2 mod_perl/2.0.5 Perl/v5.8.8 configured -- resuming normal operations
[Thu Jan 19 12:44:59 2012] [warn] [client 10.5.31.85] AMFTest - User_Agent:Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
[Thu Jan 19 12:44:59 2012] [warn] [client 10.5.31.85] AMFTest - Try to connect
[Thu Jan 19 12:44:59 2012] [error] [client 10.5.31.85] No map found matching for GLOB(0x202fee10) at /usr/lib/perl5/site_perl/5.8.8/Cache/Memcached.pm line 717.\n

So outside the handler is connecting correctly, but when inside the handler I've got this problem (the line in red color), I don't think is a memcached problem.

The version of S.O. is:

Red Hat Enterprise Linux Server release 5.6 (Tikanga)

thanks

Idel
=====================
E-Mail: idel.fuschini@gmail.com
Web Site: http://www.idelfuschini.it
AMF project: http://www.apachemobilefilter.org

AMF wiki: Apache Mobile Filter - http:/wiki.apachemobilefilter.org
------
La presente comunicazione ed i suoi allegati e' destinata esclusivamente
ai destinatari. Qualsiasi suo utilizzo, comunicazione o diffusione non autorizzata
e' proibita. Se ha ricevuto questa comunicazione per errore, la preghiamo di darne
immediata comunicazione al mittente e di cancellare tutte le informazioni
erroneamente acquisite. (Rif. D.Lgs. 196/2003). Grazie

This message and its attachments are intended only for use by the addressees. Any use,
re-transmission or dissemination not authorized of it is prohibited. If you received
this e-mail in error, please inform the sender immediately and delete all the material.
(Rif. D.Lgs. 196/2003). Thank you.

Re: preloading modules and apache::dbi

2012-01-18T14:17:00.000-08:00

Hi Mike,

I believe the answer is that each http process will have its own handle. At least that's what it appears to be when I view the handles via http://hostname/perl-status.

Hope you enjoy mod_perl.

Best regards,
- -
Brett Lee
Encrypt your data with PDS - http://crypto.brettlee.com/

From: mike cardeiro <mcardeiro@yahoo.com>
To: modper <modperl@perl.apache.org>
Sent: Wednesday, January 18, 2012 10:08 PM
Subject: preloading modules and apache::dbi

Hi,

I am totally new to mod perl (after 13+ years of building web applications on shared servers I now am developing on a dedicated box woo-hoo)

I have installed apache::dbi and set it to preload in the apache config file. Here is what I think my problem might be.

I have a library I want to preload. This library makes a database connection and assigns it to a variable that is exported so all programs can use this handle.

will this global handle db handle be a single handle amongst all apache processes, or will each process load this library on its own thus having a unique db handle for each httpd process?

sorry if this is incoherent.

Mike Cardeiro

preloading modules and apache::dbi

2012-01-18T14:08:00.001-08:00

Hi,

I am totally new to mod perl (after 13+ years of building web applications on shared servers I now am developing on a dedicated box woo-hoo)

I have installed apache::dbi and set it to preload in the apache config file. Here is what I think my problem might be.

I have a library I want to preload. This library makes a database connection and assigns it to a variable that is exported so all programs can use this handle.

will this global handle db handle be a single handle amongst all apache processes, or will each process load this library on its own thus having a unique db handle for each httpd process?

sorry if this is incoherent.

Mike Cardeiro

Re: Problem with long http request generation time - process restarting

2012-01-17T10:41:00.000-08:00

On Fri, Dec 16, 2011 at 1:20 PM, Randolf Richardson <randolf@modperl.pl> wrote:
> I've been using DBI in threaded Perl environments for many years,
> and it works just fine for me. I used Oracle 8i in the past on
> NetWare (with ModPerl 1 in a threaded environment because the NetWare
> OS is a thread-based architecture and Apache HTTPd and ModPerl were
> both compiled accordingly), but I switched to PostgreSQL many years
> ago so I'm not up-to-date with the more recent Oracle DBD issues...

I can't really suggest anything for the main question on this thread,
but I wanted to mention that mod_perl 1 only supported a single
thread, i.e. running on Windows means running one thread that all
requests had to line up for. By contrast, mod_perl 2 runs multiple
threads so it may bring threading issues in CPAN libraries to light
where they didn't show up in mod_perl 1.

- Perrin

Re: Cache::Memcached problem

2012-01-17T10:19:00.000-08:00

On Tue, Jan 17, 2012 at 10:50 AM, Idel Fuschini <idel.fuschini@gmail.com> wrote:
> No map found matching for GLOB(0x1ed02710) at
> /usr/lib/perl5/site_perl/5.8.8/Cache/Memcached.pm line 717.
>
> anybody know what could be ? I don't find any documentation about that.

You'd probably be better off asking on the memcached mailing list,
since it's an error from the Cache::Memcached module.

- Perrin

Re: serve items in "lib" or "PATH" fashion

2012-01-17T10:16:00.001-08:00

On Tue, Jan 17, 2012 at 10:02 AM, André Warnier <aw@ice-sa.com> wrote:
> But isn't there an error in the examples shown ?
>
> RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
> RewriteRule ^(.+) /your/docroot/dir1/$1 [L]
>
> If the original URL is e.g. "/cgi-bin/myscript.pl", and I wanted to check
> the local directory "/cgi-local" first, then this would evaluate to
>
> RewriteCond /my/docroot/cgi-local/myscript.pl -f
> but the "^(.+)" of the second line would evaluate to "/cgi-bin/myscript.pl"
> which would give a final URL of :
> "/my/docroot/cgi-local/cgi-bin/myscript.pl"
> which is probably not what I want.

It's kind of out-of-scope for the mod_perl list, but I think
REQUEST_FILENAME is the whole path. Check the docs.

Regardless of the details, you seem to grasp how to make it work using
a -f RewriteCond, so play around with it until you get what you want.

- Perrin

Cache::Memcached problem

2012-01-17T07:50:00.000-08:00

I've got this problem on RedHat in production server:

No map found matching for GLOB(0x1ed02710) at /usr/lib/perl5/site_perl/5.8.8/Cache/Memcached.pm line 717.

anybody know what could be ? I don't find any documentation about that.

Thanks

Idel
=====================
E-Mail: idel.fuschini@gmail.com
Web Site: http://www.idelfuschini.it
AMF project: http://www.apachemobilefilter.org

Re: serve items in "lib" or "PATH" fashion

2012-01-17T07:02:00.000-08:00

Perrin Harkins wrote:
> On Tue, Jan 17, 2012 at 4:31 AM, André Warnier <aw@ice-sa.com> wrote:
>> E.g. I would be happy if I could write this in the Apache configuration :
>>
>> ScriptAlias /cgi-bin/ /var/www/site1/cgi-bin/;/var/www/global/cgi-bin/
>>
>> and have Apache look first in the local one, then in the global one each
>> time it is looking for a given script. And similarly for other documents
>> like javascript libraries.
>
> Use mod_rewrite. See "Search pages in more than one directory":
> http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
>
Thanks, Perrin.
I didn't know mod_rewrite could to do that.

But isn't there an error in the examples shown ?

RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]

If the original URL is e.g. "/cgi-bin/myscript.pl", and I wanted to check the local
directory "/cgi-local" first, then this would evaluate to

RewriteCond /my/docroot/cgi-local/myscript.pl -f
but the "^(.+)" of the second line would evaluate to "/cgi-bin/myscript.pl"
which would give a final URL of : "/my/docroot/cgi-local/cgi-bin/myscript.pl"
which is probably not what I want.

Instead, should the example rule not be something like :

RewriteRule ^.*$ /dir1/%{REQUEST_FILENAME} [L]

Re: serve items in "lib" or "PATH" fashion

2012-01-17T06:20:00.000-08:00

On Tue, Jan 17, 2012 at 4:31 AM, André Warnier <aw@ice-sa.com> wrote:
> E.g. I would be happy if I could write this in the Apache configuration :
>
> ScriptAlias /cgi-bin/ /var/www/site1/cgi-bin/;/var/www/global/cgi-bin/
>
> and have Apache look first in the local one, then in the global one each
> time it is looking for a given script. And similarly for other documents
> like javascript libraries.

Use mod_rewrite. See "Search pages in more than one directory":
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

- Perrin

Re: serve items in "lib" or "PATH" fashion

2012-01-17T06:07:00.000-08:00

Josh Narins wrote:
>
> Josh Narins
> Director of Application Development
> SeniorBridge
>
> 845 Third Ave
> 7th Floor
> New York, NY 10022
> Tel: (212) 994-6194
> Mobile: (917) 488-6248
> Fax: (212) 994-4260
> jnarins@seniorbridge.com
>
> SeniorBridge
> Managing Complex Chronic Care
> http://www.seniorbridge.com
>
>
> SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.-----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Tuesday, January 17, 2012 4:32 AM
>> To: mod_perl list
>> Subject: serve items in "lib" or "PATH" fashion
>
> [snip]
>
>> I have already searched, but as I do not know exactly which terms to
>> use for such a
>> search, I have not found anything yet.
>> I'll write my own PerlFixupHandler or so to do this if I have to, but
>> if it already
>> exists, I would not bother.
>
> Not sure if there is a pre-made answer already for you, but you should handle the url -> file mapping with a PerlMapToStorageHandler.
>
> That way (among other things?) Authen/Authz/Access and MIME are working with the right stuff.

Thanks. I wasn't sure, and this will save me one bad iteration.

RE: serve items in "lib" or "PATH" fashion

2012-01-17T05:58:00.000-08:00

>

Josh Narins
Director of Application Development
SeniorBridge

845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Mobile: (917) 488-6248
Fax: (212) 994-4260
jnarins@seniorbridge.com

SeniorBridge
Managing Complex Chronic Care
http://www.seniorbridge.com

SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.-----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, January 17, 2012 4:32 AM
> To: mod_perl list
> Subject: serve items in "lib" or "PATH" fashion

[snip]

> I have already searched, but as I do not know exactly which terms to
> use for such a
> search, I have not found anything yet.
> I'll write my own PerlFixupHandler or so to do this if I have to, but
> if it already
> exists, I would not bother.

Not sure if there is a pre-made answer already for you, but you should handle the url -> file mapping with a PerlMapToStorageHandler.

That way (among other things?) Authen/Authz/Access and MIME are working with the right stuff.

serve items in "lib" or "PATH" fashion

2012-01-17T01:31:00.000-08:00

Hi.

I run a series of mostly-identical websites under Apache2/mod_perl2 (and Template::Toolkit).
Most of the time, these websites use a common /js/*.js javascript snippets directory, a
common /cgi-bin/*.pl directory and so on. This is done via Alias'es in each website's
<VirtualHost> configuration file, pointing to a common location.

However, once in a while - tending over time to become "quite often" - one of these
websites will need a modified version of for example one of these javascript snippets or
cgi-bin scripts. At the moment, I solve that by giving this website, then, its own
/cgi-bin/ directory, copying *all* the standard cgi-bin scripts there, changing the
/cgi-bin/ Alias to point to this own cgi-bin directory, and then modifying the one cgi-bin
script that is special for that website.

But of course then I am stuck forever now with this separate cgi-bin directory to
maintain, containing not only the one script which is different, but all the others too.

I would much prefer if I could give each of these <VirtualHost> sections a list of
directories in which to look for a target document or script, much like the way in which
the PATH or PERL5LIB variables are used.

E.g. I would be happy if I could write this in the Apache configuration :

ScriptAlias /cgi-bin/ /var/www/site1/cgi-bin/;/var/www/global/cgi-bin/

and have Apache look first in the local one, then in the global one each time it is
looking for a given script. And similarly for other documents like javascript libraries.

Now my question is : does anyone know of an Apache add-on module doing something similar ?
; does anyone know of an add-on mod_perl module which would do something of the kind ?

I have already searched, but as I do not know exactly which terms to use for such a
search, I have not found anything yet.
I'll write my own PerlFixupHandler or so to do this if I have to, but if it already
exists, I would not bother.

RE: Perl sections in Apache conf files

2012-01-16T14:38:00.000-08:00

OK, figured out how to make the SetEnv bit work. Just set $ENV directly in the <Perl> section. Seems a bit inconsistent that you can't push on @SetEnv as you would for other directives, but oh, well.

So now, I am trying to figure out how to do the equivalent of this in a Perl section:

---
<Directory "C:/Users/Desiletsa/Documents/eclipse_workspace/WeBiText/htdocs">
Order Deny,Allow
Allow from all
</Directory>
---

Here is what I tried;

---
<Perl>
$Directory{"C:/Users/Desiletsa/Documents/eclipse_workspace/WeBiText/htdocs"} =
{
Order => 'Deny,Allow',
Allow => 'from,all'
};
</Perl>
---

But Apache does not start. What am I doing wrong here?

________________________________________
From: Desilets, Alain [Alain.Desilets@nrc-cnrc.gc.ca]
Sent: Monday, January 16, 2012 4:36 PM
To: modperl@perl.apache.org
Subject: Perl sections in Apache conf files

I am trying to use <Perl> sections in my Apache conf files, in order to automate management of my various installations on various servers.

Looking at this page:

http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.html#Configuration_Variables

I gather that any directive that can be written in an Apache conf file, can also be written as a perl statement in a <Perl> section of the Apache conf file.

As I understand it, you do this by pushing the directives arguments to an array whose name is the same as the directive.

For example, if I want to write a Perl statement which does the equivalent of this:

---
SetEnv HELLO_WORLD "Salutation earthlings"
---

I would write this:

---
<Perl>
push @SetEnv, "HELLO_WORLD", "Salutation earthlings";
</Perl>
---

Is that correct?

I have tried this, but it does not seem to work. The reason I say this is that if I run a script that prints the environment:

--- print_env.cgi:
print "Content-type: text/plain\r\n\r\n";

print "Environment variables are:\n";
foreach my $a_key ( keys %ENV ) {
print "$a_key:\t$ENV{$a_key}\n";
}
--- end of print_env.cgi

I do see a HELLO_WORLD variable, but it's empty. I also see a Salutation variable (also empty), which I guess is what Apache did with the first word the value which I intended for HELLO_WORLD. There is no "earthlings" variable.

What am I doing wrong?