Re: [RELEASE CANDIDATE] mod_perl-2.0.13 RC1

[Fred Moyer]

On Sep 11, 2023, at 2:13 PM, Steve Hay  wrote:
> 
> Fred, are you still looking into this, or shall we assume it's
> Apache::Test related and proceed with this mod_perl release?

Sorry I missed this; MP emails were ending up in my httpd filter for some 
reason. It looks AT related; +1 to release.

> 
>> On Sat, 26 Aug 2023 at 17:20, Steve Hay  wrote:
>> 
>> Thanks. Is it the same problem that Adam has reproduced?
>> 
>> If so then perhaps we can go ahead with the release and deal with this
>> issue afterwards since it seems to be more related to Apache::Test
>> than mod_perl.
>> 
>>> On Thu, 24 Aug 2023 at 05:55, Fred Moyer  wrote:
>>> 
>>> On Fri, Aug 18, 2023 at 2:47 AM Steve Hay  
>>> wrote:
>>>> Were there any build errors/warnings?
>>>> Is this a clean set-up, or do either httpd or perl have an old
>>>> mod_perl in them already?
>>> 
>>> Digging into this; appears to be a problem with the perl I build mp
>>> with and the system mod_perl. Will keep you posted.
>>> 
>>> 
>>>> 
>>>> 
>>>>> 
>>>>> On Sun, Aug 6, 2023 at 5:00 AM Steve Hay  wrote:
>>>>>> 
>>>>>> Please download, test, and report back on this mod_perl 2.0.13 release
>>>>>> candidate.
>>>>>> 
>>>>>> https://dist.apache.org/repos/dist/dev/perl/mod_perl-2.0.13-rc1.tar.gz
>>>>>> 
>>>>>> SHA256:
>>>>>> mod_perl-2.0.13-rc1.tar.gz: EC72BC99 EC01DAE5 BEB1DC8F 2F3807CB A4A9BF4D
>>>>>>D492E846 858DABC0 EEA8E6B7
>>>>>> 
>>>>>> SHA512:
>>>>>> mod_perl-2.0.13-rc1.tar.gz: 15EA2E30 B5BE0B76 7E49FC46 20F93AA0 FF4E9EBA
>>>>>>03E7EDFD 64166223 5C1E652B B3C1CB69 CB60DF33
>>>>>>C64121C5 C74F3ABB A9ACDB6B 19E9B19A 46790DFE
>>>>>>015C77C9
>>>>>> 
>>>>>> Major changes in this release are as follows:
>>>>>> 
>>>>>> Use get_server_banner() instead of deprecated get_server_version() in
>>>>>> Apache2::Status.  [Petr Písař >>>>> 
>>>>>> Avoid generating APR precompiled headers. [Sam James ]
>>>>>> 
>>>>>> Fix build for perl >= 5.37.1. [Jitka Plesnikova ]
>>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>>>>>> For additional commands, e-mail: dev-h...@perl.apache.org
>>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>>>>> For additional commands, e-mail: dev-h...@perl.apache.org
>>>>> 

Re: [RELEASE CANDIDATE] mod_perl-2.0.13 RC1

[Fred Moyer]

On Fri, Aug 18, 2023 at 2:47 AM Steve Hay  wrote:
> Were there any build errors/warnings?
> Is this a clean set-up, or do either httpd or perl have an old
> mod_perl in them already?

Digging into this; appears to be a problem with the perl I build mp
with and the system mod_perl. Will keep you posted.


>
>
> >
> > On Sun, Aug 6, 2023 at 5:00 AM Steve Hay  wrote:
> > >
> > > Please download, test, and report back on this mod_perl 2.0.13 release
> > > candidate.
> > >
> > > https://dist.apache.org/repos/dist/dev/perl/mod_perl-2.0.13-rc1.tar.gz
> > >
> > > SHA256:
> > > mod_perl-2.0.13-rc1.tar.gz: EC72BC99 EC01DAE5 BEB1DC8F 2F3807CB A4A9BF4D
> > > D492E846 858DABC0 EEA8E6B7
> > >
> > > SHA512:
> > > mod_perl-2.0.13-rc1.tar.gz: 15EA2E30 B5BE0B76 7E49FC46 20F93AA0 FF4E9EBA
> > > 03E7EDFD 64166223 5C1E652B B3C1CB69 CB60DF33
> > > C64121C5 C74F3ABB A9ACDB6B 19E9B19A 46790DFE
> > > 015C77C9
> > >
> > > Major changes in this release are as follows:
> > >
> > > Use get_server_banner() instead of deprecated get_server_version() in
> > > Apache2::Status.  [Petr Písař  > >
> > > Avoid generating APR precompiled headers. [Sam James ]
> > >
> > > Fix build for perl >= 5.37.1. [Jitka Plesnikova ]
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> > > For additional commands, e-mail: dev-h...@perl.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> > For additional commands, e-mail: dev-h...@perl.apache.org
> >

Re: [RELEASE CANDIDATE] mod_perl-2.0.13 RC1

[Fred Moyer]

Hitting an issue on MacOS, perl 5.36.1, httpd 2.4.57. Not sure if this
is me out of practice or not. Do I need to build against httpd 2.2?

ulimit -c unlimited; /opt/homebrew/Cellar/perl/5.36.1/bin/perl
/Users/phred/dev/mod_perl-2.0.13-rc1/t/TEST -bugreport -verbose=0
/opt/homebrew/opt/httpd/bin/httpd  -d
/Users/phred/dev/mod_perl-2.0.13-rc1/t -f
/Users/phred/dev/mod_perl-2.0.13-rc1/t/conf/httpd.conf -D APACHE2 -D
APACHE2_4 -D PERL_USEITHREADS
using Apache/2.4.57 (prefork MPM)

waiting 300 seconds for server to start: .httpd: Syntax error on line
85 of /Users/phred/dev/mod_perl-2.0.13-rc1/t/conf/httpd.conf: Cannot
load /Users/phred/dev/mod_perl-2.0.13-rc1/src/modules/perl/mod_perl.so
into server: 
dlopen(/Users/phred/dev/mod_perl-2.0.13-rc1/src/modules/perl/mod_perl.so,
0x000A): symbol not found in flat namespace
'_modperl_handler_anon_add'
.^C[warning]
halting tests

On Sun, Aug 6, 2023 at 5:00 AM Steve Hay  wrote:
>
> Please download, test, and report back on this mod_perl 2.0.13 release
> candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/mod_perl-2.0.13-rc1.tar.gz
>
> SHA256:
> mod_perl-2.0.13-rc1.tar.gz: EC72BC99 EC01DAE5 BEB1DC8F 2F3807CB A4A9BF4D
> D492E846 858DABC0 EEA8E6B7
>
> SHA512:
> mod_perl-2.0.13-rc1.tar.gz: 15EA2E30 B5BE0B76 7E49FC46 20F93AA0 FF4E9EBA
> 03E7EDFD 64166223 5C1E652B B3C1CB69 CB60DF33
> C64121C5 C74F3ABB A9ACDB6B 19E9B19A 46790DFE
> 015C77C9
>
> Major changes in this release are as follows:
>
> Use get_server_banner() instead of deprecated get_server_version() in
> Apache2::Status.  [Petr Písař 
> Avoid generating APR precompiled headers. [Sam James ]
>
> Fix build for perl >= 5.37.1. [Jitka Plesnikova ]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> For additional commands, e-mail: dev-h...@perl.apache.org
>

Re: [DISCUSS] The future of mod_perl

[Fred Moyer]

Longer response here.

So I'm happy to be another active PMC member still involved. As
someone with a growing family, my time is limited, but not too much to
review and lend a +1 or feedback. I think that may be the case for a
few of the folks on this list. I'd like to see Steve Hay lead the
future of mod_perl project as I know a lot of the old guard have
personal duties now that take precedence.

mod_perl is not a new Apache project. It's approaching two decades,
close to the age of the Apache httpd project itself. It was a core
driver in developing my career in software, as well as many key
professional relationships associated there. I remember a *lot* of
weekends early in my career hacking on mod_perl for *fun* - the coding
was the reward, as well as the community feedback.

There are still many shops out there using mod_perl, but not much new
development, which makes sense. The project is in maintenance mode,
and there are developers willing to support needed releases as Adam
mentioned. If you are developing a new project, you should not use
mod_perl. But if you are maintaining legacy mod_perl infrastructure,
we will not leave you behind.

The open source project model has changed significantly, especially
over the last ten years. IMHO, while the ASF model was instrumental in
the rise of open source projects into commercial environments, more
recent approaches such as those supported by the Linux Foundation
(which is *definitely* more commercially supported, and reflected by
the platitude of industry sponsors and resources) have achieved
greater growth levels in the short term. Will they still be here in 20
years? No idea.

A takeaway from my reflections there is that the ASF can benefit from
a bit less formality in structure to keep up with the new kids on the
block. I'm just a mostly inactive PMC member, but I think it's clear
that the project rules are preventing us keeping up with the needed
leadership changes.

On Wed, Mar 17, 2021 at 8:02 PM Fred Moyer  wrote:
>
> Happy to continue being a maintainer. Longer response coming soon :)
>
> On Wed, Mar 17, 2021, 7:39 PM Adam Prime  wrote:
>>
>> I think if you want to discuss alternatives, then a new thread would be
>> the place to do that.
>>
>> With regards to plug being pulled, I think that it is up to the
>> community if, when, and how that happens. That's what the point of this
>> thread is. If there aren't people that are committed enough to the
>> project for whatever reason to step up and keep it from going to the
>> attic, then that's what will happen.
>>
>> Adam
>>
>>
>>
>> On 3/17/2021 9:50 PM, Jim Albert wrote:
>> > Not that I want to be the guy that says it sounds like we'll be pulling
>> > the mod_perl plug at any time the right scenario arises, but is it
>> > reasonable to have a discussion here on mod_perl alternatives inline
>> > with the various means of using mod_perl from the low level means of
>> > interfacing with the Apache server to the quick and dirty stuff
>> > (ModPerl::PerlRun, I believe to keep Perl and modules in memory).
>> >
>> > For those drawing the same conclusions from this thread as me, I've seen
>> > mod_fcgid proposed as an alternative, but I haven't yet played with it.
>> > Anyone with similar thoughts would ideally be looking for something that
>> > doesn't require months of redeveloping to a proposed replacement to
>> > mod_perl.
>> >
>> > I like mod_perl and it does a good job for what I use it for, but if we
>> > have no one developing, it sounds like we're waiting for the catalyst to
>> > come along that puts and end to it. EG.. some future Apache
>> > incompatibility.  I'd really like someone with mod_perl authority to
>> > tell me I'm wrong, but my take on Adam's reply pretty much leaves me
>> > with that conclusion. I don't see another way to draw a better conclusion.
>> >
>> > Jim
>> >

Re: [DISCUSS] The future of mod_perl

[Fred Moyer]

Happy to continue being a maintainer. Longer response coming soon :)

On Wed, Mar 17, 2021, 7:39 PM Adam Prime  wrote:

> I think if you want to discuss alternatives, then a new thread would be
> the place to do that.
>
> With regards to plug being pulled, I think that it is up to the
> community if, when, and how that happens. That's what the point of this
> thread is. If there aren't people that are committed enough to the
> project for whatever reason to step up and keep it from going to the
> attic, then that's what will happen.
>
> Adam
>
>
>
> On 3/17/2021 9:50 PM, Jim Albert wrote:
> > Not that I want to be the guy that says it sounds like we'll be pulling
> > the mod_perl plug at any time the right scenario arises, but is it
> > reasonable to have a discussion here on mod_perl alternatives inline
> > with the various means of using mod_perl from the low level means of
> > interfacing with the Apache server to the quick and dirty stuff
> > (ModPerl::PerlRun, I believe to keep Perl and modules in memory).
> >
> > For those drawing the same conclusions from this thread as me, I've seen
> > mod_fcgid proposed as an alternative, but I haven't yet played with it.
> > Anyone with similar thoughts would ideally be looking for something that
> > doesn't require months of redeveloping to a proposed replacement to
> > mod_perl.
> >
> > I like mod_perl and it does a good job for what I use it for, but if we
> > have no one developing, it sounds like we're waiting for the catalyst to
> > come along that puts and end to it. EG.. some future Apache
> > incompatibility.  I'd really like someone with mod_perl authority to
> > tell me I'm wrong, but my take on Adam's reply pretty much leaves me
> > with that conclusion. I don't see another way to draw a better
> conclusion.
> >
> > Jim
> >
>

Re: [ANNOUNCE] mod_perl-2.0.10

[Fred Moyer]

Great news. Thanks Steve!

On Thu, Oct 27, 2016, 2:49 PM Steve Hay  wrote:

> We are pleased to announce the release of mod_perl 2.0.10.
>
> mod_perl is an Apache HTTP Server module for embedding a Perl
> interpreter in your web server, giving you super-fast dynamic content
> by avoiding the overhead of starting an external interpreter.
>
> This release is now, or soon will be, available for download from a
> mirror site near you via:
>
> http://perl.apache.org/download/index.html
>
> or in the meantime directly from:
>
> http://apache.org/dist/perl/
> http://search.cpan.org/dist/mod_perl/
> https://metacpan.org/release/SHAY/mod_perl-2.0.10
>
> Checksums for this release are:
>
> MD5  = cef55e715b5770a63b3becbe9d271121
> SHA1 = 61b5b0fe4449440258ad45dee6efa0e2264a9701
>
> Major changes in this release are as follows:
>
> Add support for Perl 5.22.x. [Niko Tyni , Steve Hay]
>
> Fix non-threaded Perl 5.22.x build and tests. [Klaus S. Madsen
> ]
>
> Automatically select the appropriate c89 option when modperl is being
> built with either gcc 5 or clang. [Klaus S. Madsen ]
>
> Declare MP_vtbl_env and MP_vtbl_envelem as 'extern' to fix linker
> errors on OSX/Darwin. [Michael Schout ]
>

Re: my mod_perl project

[Fred Moyer]

This is a captive portal I wrote in mod_perl -
https://github.com/redhotpenguin/App-SilverSplash

Here's a backend app I wrote for managing ads on wifi networks -
https://github.com/redhotpenguin/SL/tree/master/SL-App

Both are far from polished - I'm sure you can find better examples out there :)

On Fri, Oct 2, 2015 at 1:30 PM, Bruce  Johnson
 wrote:
> And I’d like to just poke at it to see what a working mod_perl site looks 
> like, because all the programming examples I’ve ever found are pretty trivial.
>
> Yes, it's easy to make a website that only ever says ‘mod_perl rocks’ :-/
>
>
>> On Oct 2, 2015, at 11:22 AM, Fred Moyer  wrote:
>>
>> I'm a believer that open sourcing something is the process by which it
>> becomes polished. There's a saying that CPAN is successful because of
>> the volume of sh*t uploaded to it, not in spite of it. I'd say don't
>> worry that it isn't polished - working code > pretty code.
>>
>> On Fri, Oct 2, 2015 at 9:21 AM, viva marai  wrote:
>>> I hadn't planned on open sourcing it - I was partly doing it to learn the
>>> technologies myself - so it's not in a polished enough state to be open
>>> sourced. But I'll keep that in mind and try to clean up the code so that
>>> eventually it can be open sourced.
>>>
>>> thanks!
>>>
>>>
>>> On Thu, Oct 1, 2015 at 7:23 PM, Fred Moyer  wrote:
>>>>
>>>> That's awesome!
>>>>
>>>> Are you open sourcing it?
>>>>
>>>> On Thu, Oct 1, 2015 at 4:12 PM, viva marai  wrote:
>>>>> Sorry if these kinds of messages are against the guidelines (I didn't
>>>>> see
>>>>> anything prohibiting announcing projects built on mod_perl).
>>>>> I built a Hacker News clone for books as my pet project on mod_perl and
>>>>> wanted to shamelessly plug it here :-)
>>>>>
>>>>> I would love some feedback:
>>>>> https://news.ycombinator.com/item?id=10313289
>>>>>
>>>>> Thanks!
>>>
>>>
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>

Re: my mod_perl project

[Fred Moyer]

I'm a believer that open sourcing something is the process by which it
becomes polished. There's a saying that CPAN is successful because of
the volume of sh*t uploaded to it, not in spite of it. I'd say don't
worry that it isn't polished - working code > pretty code.

On Fri, Oct 2, 2015 at 9:21 AM, viva marai  wrote:
> I hadn't planned on open sourcing it - I was partly doing it to learn the
> technologies myself - so it's not in a polished enough state to be open
> sourced. But I'll keep that in mind and try to clean up the code so that
> eventually it can be open sourced.
>
> thanks!
>
>
> On Thu, Oct 1, 2015 at 7:23 PM, Fred Moyer  wrote:
>>
>> That's awesome!
>>
>> Are you open sourcing it?
>>
>> On Thu, Oct 1, 2015 at 4:12 PM, viva marai  wrote:
>> > Sorry if these kinds of messages are against the guidelines (I didn't
>> > see
>> > anything prohibiting announcing projects built on mod_perl).
>> > I built a Hacker News clone for books as my pet project on mod_perl and
>> > wanted to shamelessly plug it here :-)
>> >
>> > I would love some feedback:
>> > https://news.ycombinator.com/item?id=10313289
>> >
>> > Thanks!
>
>

Re: my mod_perl project

[Fred Moyer]

That's awesome!

Are you open sourcing it?

On Thu, Oct 1, 2015 at 4:12 PM, viva marai  wrote:
> Sorry if these kinds of messages are against the guidelines (I didn't see
> anything prohibiting announcing projects built on mod_perl).
> I built a Hacker News clone for books as my pet project on mod_perl and
> wanted to shamelessly plug it here :-)
>
> I would love some feedback: https://news.ycombinator.com/item?id=10313289
>
> Thanks!

Re: Enquiry about mod_perl project state

[Fred Moyer]

 I know of a lot of shops out there still running mod_perl. I'd say
the focus has narrowed to web services that need to be really
performant. There's a ton of web application frameworks out there, and
those that are written in Perl can be served by mod_perl via Plack,
etc.

It's more of an API into the Apache http request cycle now than
something that directly serves up websites. Which is initially what it
started out as :)

On Sat, Aug 15, 2015 at 9:34 AM, Randolf Richardson  wrote:
> (This reply to Dr. James Smith's message is also intended for Ashish
> Mukherjee...)
>
> You're hooking in to more handlers than I typically do -- I hook
> into PerlAuthenHandler and PerlAuthzHandler (to implement a custom
> login system I created that uses one cookie, so it's been great that
> cookies are accessible at these stages), so that's two places (I
> found that I have to set up handlers for both or else neither works,
> which is fine because simply returning Apache2::Const::OK for authz
> is trivially easy).
>
> In my test environments, I use PerlInitHandler with Apache2::Reload,
> which I find does come with a slight performance hit, but that's okay
> because they're not as busy as the production environments.
>
> So, aside from that I use PerlRequire to load my main module (which
> includes the "authen" and "authz" handlers), and then I use the
> following stanza in a VirtualHost container in httpd.conf to handle
> all .pl files with mod_perl:
>
>   
> SetHandler modperl
> PerlOptions +SetupEnv
> PerlResponseHandler ModPerl::Registry
> AddOutputFilter INCLUDES .pl
> Options +Includes +ExecCGI
>   
>
> My main Perl module, at the authen() stage, connects to PostgreSQL
> with DBI using connect_cached, and then stores a referenced to itself
> with $r->pnotes, which is later used by all the .pl files in my web
> sites to use the same database connection (why waste CPU resources by
> reconnecting and re-processing the cookie twice when we can just
> re-use what's already been established in the authen() stage?).
>
> One of the nice things about using the pnotes mechanism is that it
> also means that I can write my .pl files in a generic manner so that
> they can easily be copied to other web sites that use different main
> modules (as long as I support the same functions for generating
> headers and footers, and other web site styling, which I do).
>
> For me, mod_perl has been an amazing productivity tool, and I've
> been building nearly all my web sites with it (where I don't use
> mod_perl is when all I need is plain HTML without any server-side
> functionality).  One of the greatest things about using mod_perl is
> the consistently high performance it provides, even when enduring
> heavy traffic loads (there are limits, of course, but comparatively I
> find that mod_perl handles a lot more traffic than many other systems
> like PHP, and so hardware infrastructure costs are less overall too).
>
>> I agree with Randolf,
>>
>> I have watched a number of projects move away from mod_perl - often to
>> Dancer/
>> Catalyst etc and then they ask can I do X, Y or Z...
>>
>> I say "if you were using mod_perl you could do that easily" but usually
>> find the tool chain for
>> doing something similar in Dancer or Catalyst is infinitely more
>> complex, because you can't
>> simply add a handler here or an output filter there. You can do this
>> with chained middleware
>> in Dancer but it is not that easy to implement...
>>
>> The main thing with mod_perl is - as long as Apache doesn't mess around
>> with the core HTTPD
>> interface (like they did with 2.4) then there isn't anything much that
>> needs changing - because
>> it is good solid and just works... If it ain't broke then it doesn't
>> need changing.
>>
>> I probably use more "pure" mod_perl - no registry scripts here thank
>> you! - and hook into the
>> apache process at about 7- 8 places to handle users, templating,
>> diagnostics, optimisation etc
>>
>> On 14/08/2015 18:51, Randolf Richardson wrote:
>> >> Hello,
>> >>
>> >> I wanted to enquire about the status of mod_perl, since there is largely 
>> >> an
>> >> impression it is end of life. The project site also does not say much. I
>> >> see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
>> >> or going the Java way.
>> > I'm still using mod_perl to develop new web sites.  The most recent
>> > one I've published is called the "atheist Blog Roll" and it uses a
>> > PostgreSQL database in the back-end:
>> >
>> > http://www.atheistblogroll.com/
>> >
>> > There are other projects on my horizon that continue to be developed
>> > in mod_perl, and they range from simple web sites to fully
>> > interactive projects.
>> >
>> > When there is a need for a client-side application, I use Java
>> > because I only have to write the code once to gain support on
>> > multiple Operating Systems (e.g., Unix/Linux, 

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC3

[Fred Moyer]

+1, all tests passed on httpd 2.4.12, perl 5.20.1, Centos 6.5. Nice work Steve!

On Wed, Jun 10, 2015 at 10:13 AM, Steve Hay  wrote:
> Please download, test, and report back on this release candidate of
> the long-awaited mod_perl 2.0.9.
>
> http://people.apache.org/~stevehay/mod_perl-2.0.9-rc3.tar.gz
>
> MD5 = 61d07fe00919d9da2b49dbf7b821b1a7
> SHA1 = 09e1d5f19312742db9da38c8e7f8955a77d29dfd
>
> Changes since RC2:
>
> Fix t/api/aplog.t for apr-1.5.2. [Steve Hay]
>
> Note that Perl 5.22.x is currently not supported. This is logged as
> CPAN RT#101962 and will hopefully be addressed in 2.0.10. [Steve Hay]
>
> Fix unthreaded build, which was broken in 2.0.9-rc2. [Steve Hay]

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC1

[Fred Moyer]

I've been struggling with this same issue on OS X. Jan K. indicated
that it was the result of perlbrew, httpd, and mod_perl not all being
built with the same C compiler. I had tried to get everything built
with gcc, but I had to symlink /usr/bin/cc to gcc instead of clang,
and even then I think other parts of my toolchain were still using
clang based utilities.

On Tue, Jun 2, 2015 at 10:24 AM, David E. Wheeler  wrote:
> On May 13, 2015, at 3:52 PM, David E. Wheeler  wrote:
>
>> Tested builds on CentOS 6 and 7, with the system Perl and a custom 5.20 
>> build. Both build nicely, with just a simple patch for the system Perl 
>> wanting a header with “CentOS” in it instead of “Unix”. Yay!
>
> Having difficulting testing against my Perlbrew-installed 5.22.0 and Apache 
> 2.2.27 on OS X:
>
> waiting 120 seconds for server to start: .[Tue Jun 02 10:20:16 2015] [warn] 
> module apreq_module is already loaded, skipping
> httpd: Syntax error on line 70 of 
> /Users/david/Desktop/mod_perl-2.0.9-rc1/t/conf/httpd.conf: Cannot load 
> /Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so into 
> server: 
> dlopen(/Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so, 
> 10): Symbol not found: _modperl_handler_name
>   Referenced from: 
> /Users/david/Desktop/mod_perl-2.0.9-rc1/src/modules/perl/mod_perl.so
>   Expected in: dynamic lookup
>
> Best,
>
> David
>

Re: How Do I change the Document Root Per Request

[Fred Moyer]

Can you show us your relevant httpd.conf snippet? No guesses right
now, but that might help.

On Sun, Mar 1, 2015 at 4:46 PM, David E. Wheeler  wrote:
> Hi,
>
> I want to set the document root for a request to map to the basic auth 
> username. I tried this in a PerlFixupHandler:
>
> sub handler {
> my $r = shift;
>
> # We only want to do this once per request.
> return DECLINED unless $r->is_initial_req;
>
> # Get the username.
> my $user = $r->user or return HTTP_UNAUTHORIZED;
>
> # Return forbidden if the username subdiectory does not exist.
> my $doc_root = File::Spec->catdir($r->document_root, $user);
> return HTTP_FORBIDDEN unless -d $doc_root;
>
> # Set the document root for the duration of this request and return.
> $r->document_root($doc_root);
> return DECLINED;
> }
>
> But alas, it still serves the original document root. How can I get it to 
> change the document root on a per-request basis? If I cant, should I change 
> the URI or the filename, instead?
>
> Thnks,
>
> David

Re: Apache::DBI and Pgbouncer

[Fred Moyer]

Apache::DBI caches database connection per process so you avoid the cost of
creating a connection on each requests.

Pgbouncer pools database connections so that you don't tie up one
postmaster process per httpd process.

If you only have one webserver you may not have a real need for pgbouncer;
it really is most useful when you have more httpd processes than you have
postmaster processes. However you should be in the best position to grow
using both.
On Apr 22, 2014 7:03 AM, "jbiskofski"  wrote:

> I just want to confirm something with all you smart folks.
>
> I recently separated my web servers from my database servers, before I was
> using Apache::DBI to maintain persistent connections between Apache and
> Postgres. With this new setup I had to install PgBouncer. Can I now safely
> remove Apache::DBI from my application and use regular DBI ??
>
> Thank you.
>
>

Re: support for Apache 2.4

[Fred Moyer]

After a quick chat with Jie, I've updated perl.apache.org and removed
the links to the snapshots directory which was broken.

Apache.org is no longer supporting snapshot releases, which is why
they are no longer available.

If you have trouble viewing the updated site, please try
'shift-reload' so that your browser doesn't serve up a cached page.

On Sat, Feb 15, 2014 at 4:53 PM, Jie Gao  wrote:
> Hi Fred
>
> Thanks very much for the update.
>
> I have just tried to acces it, but I didn't see a difference. Will you please 
> double-check the udpate?
>
> Regards,
>
> Jie
>
> * Fred Moyer  wrote:
>
>> Date: Sat, 15 Feb 2014 15:22:29 -0800
>> From: Fred Moyer 
>> To: Perrin Harkins 
>> CC: Jie Gao , Randolf Richardson ,
>>  mod_perl list 
>> Subject: Re: support for Apache 2.4
>>
>> On Sat, Feb 15, 2014 at 6:48 AM, Perrin Harkins  wrote:
>> > On Fri, Feb 14, 2014 at 8:01 PM, Jie Gao  wrote:
>> >> The link http://svn.apache.org/snapshots/modperl-2.0/ on page
>> >> http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
>> >> returns 404; http://perl.apache.org/dist/ is full of broken links.
>> >
>> > Apologies for the disruptions on the site.  We have had to make some
>> > changes in how it is generated in order to catch up to current Apache
>> > policies, and that has exposed some parts of the site generation
>> > process that were only understood by developers who are no longer
>> > around.  We're working on it.
>>
>> I had some tuits available today, and was able to update
>> perl.apache.org to the most up to date documentation and links to the
>> new apache.org based source repository.
>>
>> The updated source links are now available at
>> http://perl.apache.org/download/source.html
>>
>> There may be some nits with the search, please post to the list if you
>> find any. However, the site generation process (which took 10 minutes
>> on my 3.4ghz quad core i7) was successful, so I think perl.apache.org
>> should be back to full operating capacity now.

Re: support for Apache 2.4

[Fred Moyer]

On Sat, Feb 15, 2014 at 6:48 AM, Perrin Harkins  wrote:
> On Fri, Feb 14, 2014 at 8:01 PM, Jie Gao  wrote:
>> The link http://svn.apache.org/snapshots/modperl-2.0/ on page
>> http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
>> returns 404; http://perl.apache.org/dist/ is full of broken links.
>
> Apologies for the disruptions on the site.  We have had to make some
> changes in how it is generated in order to catch up to current Apache
> policies, and that has exposed some parts of the site generation
> process that were only understood by developers who are no longer
> around.  We're working on it.

I had some tuits available today, and was able to update
perl.apache.org to the most up to date documentation and links to the
new apache.org based source repository.

The updated source links are now available at
http://perl.apache.org/download/source.html

There may be some nits with the search, please post to the list if you
find any. However, the site generation process (which took 10 minutes
on my 3.4ghz quad core i7) was successful, so I think perl.apache.org
should be back to full operating capacity now.

Scoreboard effects on server performance [was Re: Accessing list of worker statuses in /server-status via Apache2::Status]

[Fred Moyer]

Figured it out - declaring the location of the scoreboard file in
httpd.conf creates it there.

Getting a segfault with httpd 2.2.24/5.14.2, will get a coredump and
backtrace and report back.

Guessing that the most performant means of using this scoreboard would
be to put it on a ram based tempdisk.

I'm trying to query the scoreboard per request, so that if my server
hits MaxChildren I can turn request based profiling to determine where
requests are spending their time. Seems easier than trying to
replicate the slowness issues I'm seeing with load testing.


On Wed, Jan 8, 2014 at 11:06 AM, Fred Moyer  wrote:
> Apache2::ScoreBoardFile seems to be what I want:
>
> https://metacpan.org/pod/Apache2::ScoreBoardFile
>
> However I'm not sure how to enable the scoreboard file. Torsten??
>
> On Wed, Jan 8, 2014 at 10:42 AM, Fred Moyer  wrote:
>> I'm poking around the source code seeing if it's possible to
>> programmatically access the data normally displayed at /server-status
>> when 'SetHandler server-status' is enabled.
>>
>> I've spelunked through Apache2::Status but I don't see any hooks for
>> accessing worker status data. Has anyone done this before? Or do I
>> need to map the functions in mod_status.c into mod_perl land?

Re: Accessing list of worker statuses in /server-status via Apache2::Status

[Fred Moyer]

Apache2::ScoreBoardFile seems to be what I want:

https://metacpan.org/pod/Apache2::ScoreBoardFile

However I'm not sure how to enable the scoreboard file. Torsten??

On Wed, Jan 8, 2014 at 10:42 AM, Fred Moyer  wrote:
> I'm poking around the source code seeing if it's possible to
> programmatically access the data normally displayed at /server-status
> when 'SetHandler server-status' is enabled.
>
> I've spelunked through Apache2::Status but I don't see any hooks for
> accessing worker status data. Has anyone done this before? Or do I
> need to map the functions in mod_status.c into mod_perl land?

Accessing list of worker statuses in /server-status via Apache2::Status

[Fred Moyer]

I'm poking around the source code seeing if it's possible to
programmatically access the data normally displayed at /server-status
when 'SetHandler server-status' is enabled.

I've spelunked through Apache2::Status but I don't see any hooks for
accessing worker status data. Has anyone done this before? Or do I
need to map the functions in mod_status.c into mod_perl land?

First release of Apache::Hendrix. Sinatra / Dancer like route declaration for mod_perl.

[Fred Moyer]

Looks similar to Apache2::Dispatch

http://www.reddit.com/r/perl/comments/1pezkh/first_release_of_apachehendrix_sinatra_dancer/

Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?

[Fred Moyer]

Where does Oracle.so live on your filesystem?


On Mon, Oct 21, 2013 at 11:37 AM, Bruce Johnson <
john...@pharmacy.arizona.edu> wrote:

>
> On Oct 21, 2013, at 11:20 AM, Fred Moyer  wrote:
>
> > This is annoying but it happens on 64 bit architectures.
> >
> > > The path is correct, the script works fine on the command line, and if
> I comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > Sounds like some environment variable is not getting passed correctly to
> mod_perl. Maybe dump out %ENV from the command line and see if there are
> additional vars you need to pass?
>
> Nope, good idea but the vars I need are present, even with the modperl
> handler in place. The only ones you need for DBD::Oracle to work are
> ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command
> line, either.
>
> >
> > I'd dump out %INC from the command line and mod_perl also to make sure
> that you are loading the needed modules. You could try to install
> DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that
> it's looking for the Oracle.so in /usr/local/lib but it is located
> somewhere else.
>
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
> >
> >
> > On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <
> john...@pharmacy.arizona.edu> wrote:
> > We've set a Directory directive for some perl scripts, setting a
> mod_perl handler:
> >
> > Alias /card_access /home/allwebfiles/perl/catcard
> >
> >  
> >  SetHandler perl-script
> >  PerlResponseHandler ModPerl::Registry
> >  PerlOptions +ParseHeaders
> >  Options +ExecCGI
> >  PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> >  PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> >  
> >
> > The %ENV variable is there, if I print the %ENV values:
> >
> > LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> > MOD_PERL --> mod_perl/2.0.4
> > MOD_PERL_API_VERSION --> 2
> > ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> > PATH --> /sbin:/usr/sbin:/bin:/usr/bin
> >
> > But trying to initialize a DBI database connection results in the
> following error:
> >
> > [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't
> load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module
> DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file
> or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11)
> line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a
> required shared library or dll isn't installed where expected\n at
> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
> >
> > Which is precisely the error you get when LD_LIBRARY_PATH is unset or
> incorrect.
> >
> > libocci.so.11.1 is where it's supposed to be.
> >
> > [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> > total 185016
> > -rw-r--r-- 1 root root   368 Sep 17  2011 glogin.sql
> > lrwxrwxrwx 1 root root17 May 20 12:07 libclntsh.so ->
> libclntsh.so.11.1
> > -rw-r--r-- 1 root root  52761218 Sep 17  2011 libclntsh.so.11.1
> > -rw-r--r-- 1 root root   7955322 Sep 17  2011 libnnz11.so
> > lrwxrwxrwx 1 root root15 May 20 12:07 libocci.so ->
> libocci.so.11.1
> > -rw-r--r-- 1 root root   1971762 Sep 17  2011 libocci.so.11.1
> > -rw-r--r-- 1 root root 118408281 Sep 17  2011 libociei.so
> > -rw-r--r-- 1 root root164836 Sep 17  2011 libocijdbc11.so
> > -rw-r--r-- 1 root root   1503303 Sep 17  2011 libsqlplusic.so
> > -rw-r--r-- 1 root root   1477446 Sep 17  2011 libsqlplus.so
> > -rw-r--r-- 1 root root   2095661 Sep 17  2011 ojdbc5.jar
> > -rw-r--r-- 1 root root   2714016 Sep 17  2011 ojdbc6.jar
> > -rw-r--r-- 1 root root300666 Sep 17  2011 ottclasses.zip
> > -rw-r--r-- 1 root root 66779 Sep 17  2011 xstreams.jar
> >
> > The path is corre

Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?

[Fred Moyer]

This is annoying but it happens on 64 bit architectures.

> The path is correct, the script works fine on the command line, and if I
comment out the handler directives in the perl.conf script, put in a
ScriptAlias and process the script as a normal CGI script, it also works.

Sounds like some environment variable is not getting passed correctly to
mod_perl. Maybe dump out %ENV from the command line and see if there are
additional vars you need to pass?

I'd dump out %INC from the command line and mod_perl also to make sure that
you are loading the needed modules. You could try to install DBD::Oracle in
/usr/lib instead of /usr/local/lib also - my guess is that it's looking for
the Oracle.so in /usr/local/lib but it is located somewhere else.


On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <
john...@pharmacy.arizona.edu> wrote:

> We've set a Directory directive for some perl scripts, setting a mod_perl
> handler:
>
> Alias /card_access /home/allwebfiles/perl/catcard
>
>  
>  SetHandler perl-script
>  PerlResponseHandler ModPerl::Registry
>  PerlOptions +ParseHeaders
>  Options +ExecCGI
>  PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
>  PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
>  
>
> The %ENV variable is there, if I print the %ENV values:
>
> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> MOD_PERL --> mod_perl/2.0.4
> MOD_PERL_API_VERSION --> 2
> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>
> But trying to initialize a DBI database connection results in the
> following error:
>
> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't
> load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module
> DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file
> or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11)
> line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a
> required shared library or dll isn't installed where expected\n at
> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>
> Which is precisely the error you get when LD_LIBRARY_PATH is unset or
> incorrect.
>
> libocci.so.11.1 is where it's supposed to be.
>
> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> total 185016
> -rw-r--r-- 1 root root   368 Sep 17  2011 glogin.sql
> lrwxrwxrwx 1 root root17 May 20 12:07 libclntsh.so ->
> libclntsh.so.11.1
> -rw-r--r-- 1 root root  52761218 Sep 17  2011 libclntsh.so.11.1
> -rw-r--r-- 1 root root   7955322 Sep 17  2011 libnnz11.so
> lrwxrwxrwx 1 root root15 May 20 12:07 libocci.so -> libocci.so.11.1
> -rw-r--r-- 1 root root   1971762 Sep 17  2011 libocci.so.11.1
> -rw-r--r-- 1 root root 118408281 Sep 17  2011 libociei.so
> -rw-r--r-- 1 root root164836 Sep 17  2011 libocijdbc11.so
> -rw-r--r-- 1 root root   1503303 Sep 17  2011 libsqlplusic.so
> -rw-r--r-- 1 root root   1477446 Sep 17  2011 libsqlplus.so
> -rw-r--r-- 1 root root   2095661 Sep 17  2011 ojdbc5.jar
> -rw-r--r-- 1 root root   2714016 Sep 17  2011 ojdbc6.jar
> -rw-r--r-- 1 root root300666 Sep 17  2011 ottclasses.zip
> -rw-r--r-- 1 root root 66779 Sep 17  2011 xstreams.jar
>
> The path is correct, the script works fine on the command line, and if I
> comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
>
> I'm confident the issue doesn't have anything to do with DBI or
> DBD::Oracle.
>
> It ONLY fails when the script is executed as a mod_perl handler.
>
> The script itself is very simple; all I do is create a database handle and
> if no error is thrown, print 'It works'.
>
> #!/usr/bin/perl
> use DBI;
> use strict;
>
> my $login="xx";
> my $dbpass='';
> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError
> =>1});
>
> print "Content-type: text/html\n\n";
> print "It Works";
> exit;
>
> (and this is just a test , any script using DBI fails with this error.)
>
> What am I missing?
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>

Re: [mod_proxy] ProxyPass without slash not working

[Fred Moyer]

You may also need a ProxyPassReverse directive.
On Oct 8, 2013 3:11 PM, "Tiago Braga"  wrote:

> Hello!
>
> I'm using the httpd Apache/2.2.15 in Linux RedHat with mod_proxy.
>
> I have the below configuration:
>
> 
> ServerName www.host.com.br
> ProxyPass / http://static.host.com.br/html/directory/
> 
>
> When the url is: www.host.com.br/test/
> It's works.
>
> When the url is: www.host.com.br/test
> It's not works with the message in the log bellow:
>
> 127.0.0.1 - - [08/Oct/2013:18:14:28 -0300] "GET /test HTTP/1.1" 302 301
> "-" "lwp-request/5.827 libwww-perl/5.833"
> 127.0.0.1 - - [08/Oct/2013:18:14:28 -0300] "GET /html/directory/test/
> HTTP/1.1" 404 594 "-" "lwp-request/5.827 libwww-perl/5.833"
>
> Why?
>
> --
> Atenciosamente,
> Tiago Braga Machado
>

Re: Inconsistency about latest version

[Fred Moyer]

Sorry about that, I pinged the Apache infrastructure team about this a
couple months ago but there hasn't been any movement. I'll ping them again.


On Sat, Sep 7, 2013 at 2:48 AM, Martin von Gagern wrote:

> Hello!
>
> I noticed that http://projects.apache.org/projects/mod_perl.html lists
> 2.0.8 as the latest version. http://perl.apache.org/dist/ is given as
> the location for downloads, but the 2.0.7 release is the latest there.
> Also following the Homepage link to http://perl.apache.org/, and the
> Download link there to http://perl.apache.org/download/index.html, one
> ends up on a page naming 2.0.7 the latest release. It takes some effort
> to actually locate the 2.0.8 tarball in http://apache.org/dist/perl/. I
> take it that this inconsistency and confusion is not intentional. Please
> make things more consistent.
>
> Thanks a lot,
>  Martin von Gagern
>
>

Re: Apache::DBI "connection lost contact" error

[Fred Moyer]

Apache-DBI 1.12 was just pushed to CPAN with this update. Thanks for
the great work on the fix Perrin.

On Thu, Jun 6, 2013 at 2:53 PM, Perrin Harkins  wrote:
> That's great!  I'll commit the patch and see about getting a new release out
> to CPAN.
>
> - Perrin
>
>
> On Thu, Jun 6, 2013 at 5:02 PM, Xinhuan Zheng 
> wrote:
>>
>> Hi Perrin,
>>
>> I did a testing with debugging. I don't see the "connection lost contact"
>> error anymore. The patch looks good to me.
>>
>> Thanks,
>> - xinhuan
>>
>> From: Perrin Harkins 
>> Date: Thursday, June 6, 2013 3:02 PM
>> To: Xinhuan Zheng 
>> Cc: "modperl@perl.apache.org" 
>>
>> Subject: Re: Apache::DBI "connection lost contact" error
>>
>> On Thu, Jun 6, 2013 at 12:22 PM, Xinhuan Zheng 
>> wrote:
>> > The database handle that is created in startup.pl needs to be really
>> > disconnected (not overloaded disconnect) so that won't leave an idle server
>> > process running on the database side. Once it's really disconnected, the
>> > server process can be cleaned up on the server side.
>>
>> Right, that's what the bug is preventing.
>>
>> Because my flight was delayed last night, I had time to make a patch.
>> Please try this on your system and send the debug, like you did before.
>>
>> - Perrin
>>
>

Re: Install Question

[Fred Moyer]

> You need to pass either MP_AP_PREFIX or MP_APXS, but not both.

I'd suggest building via MP_APXS. Building mod_perl statically is not
widely tested.

On Tue, Jun 4, 2013 at 11:48 AM, Tracy Kukuselis  wrote:
> Hi!  Ok, I implemented the changes that you stated and now I received the
> following error:
>
>
> You need to pass either MP_AP_PREFIX or MP_APXS, but not both.
>
>
> Configuration for makefile:
> /usr/local/bin/perl Makefile.PL
> MP_USE_STATIC=1
> MP_AP_PREFIX=/data/links/httpd
> MP_APXS=/usr/sbin/apxs
>
>
> Any suggestions you have would be great.
>
> Thanks,
> Tracy
>
>
> From: Eugene Toropov 
> To: Tracy Kukuselis 
> Cc: "modperl-h...@perl.apache.org" ;
> "modperl@perl.apache.org" 
> Sent: Monday, June 3, 2013 12:18 PM
> Subject: Re: Install Question
>
> Hi Tracy,
>
> As far as I remember must be something like
>
> perl Makefile.PL MP_APXS=/usr/bin/apxs
>
> Cheers
> Eugene
>
> On Jun 3, 2013, at 7:42 PM, Tracy Kukuselis  wrote:
>
>
> Hello,
>
> I am trying to install modperl 2.0.3 with httpd 2.4.2 (also tried 2.4.4),
> but am getting the following error:
> Failed to obtain the MPM name. Please specify MP_APXS=/full/path/to/apxs to
> solve this problem.
> make:*** [path] Error 255
>
> Using the following configure command
> configure --prefix=/usr/local/apache2 --disable-userdir --enable-expires
> --enable-headers --enable-ldap --enable-logio --enable-mime-magic
> --enable-so --enable-speling --endable-usertrack --enable-vhost-alias
> --with-port=80 --with-included-apr --with-included-apr-util
> --with-ssl=/usr/local/ssl/
>
> Where can I put the MPM name to get it to be picked up.   I tried to add
> --mpm-name=prefork, to the configure command, but the same problem.
>
>
> Thanks
> Tracy
>
>
>
>
>

Re: Apache::DBI "connection lost contact" error

[Fred Moyer]

On Mon, Jun 3, 2013 at 2:36 PM, Dave Morgan  wrote:
> On 06/03/2013 03:14 PM, Perrin Harkins wrote:
>
> DO NOT USE Apache::DBI with DBI::Connector or any other database caching
> technique. This requires
> knowledge of the code!!!

DBIx::Class monkey patches Apache::DBI so that the caching behavior of
Apache::DBI is overriden. I don't think the best approach, but you can
safely use DBIx::Class with mod_perl and have it handle the database
connections. Enable the verbose debug setting in Apache::DBI to verify
that.

Re: Install Question

[Fred Moyer]

Please cc the list on your responses so that you can get support from
any of the thousands of mod_perl users on this list :)

On Mon, Jun 3, 2013 at 10:52 AM, Tracy Kukuselis  wrote:
> And this one
>
> From: Fred Moyer 
> To: Tracy Kukuselis 
> Cc: "modperl@perl.apache.org" 
> Sent: Monday, June 3, 2013 12:43 PM
> Subject: Re: Install Question
>
> On Mon, Jun 3, 2013 at 8:42 AM, Tracy Kukuselis 
> wrote:
>> I am trying to install modperl 2.0.3 with httpd 2.4.2 (also tried 2.4.4),
>> but am getting the following error:
>
> 2.4 isn't officially supported yet, although there are a couple builds
> on the list you might try. See the list archives for those.
>
>> Failed to obtain the MPM name. Please specify MP_APXS=/full/path/to/apxs
>> to
>> solve this problem.
>> make:*** [path] Error 255
>
> What OS and Perl version are you running? What command are you using
> to build mod_perl? Do you know where your apxs executable is? ('which
> apxs' should output the location).
>
>>
>> Using the following configure command
>> configure --prefix=/usr/local/apache2 --disable-userdir --enable-expires
>> --enable-headers --enable-ldap --enable-logio --enable-mime-magic
>> --enable-so --enable-speling --endable-usertrack --enable-vhost-alias
>> --with-port=80 --with-included-apr --with-included-apr-util
>> --with-ssl=/usr/local/ssl/
>>
>> Where can I put the MPM name to get it to be picked up.  I tried to add
>> --mpm-name=prefork, to the configure command, but the same problem.
>>
>>
>> Thanks
>> Tracy
>>
>>
>
>

Re: Install Question

[Fred Moyer]

On Mon, Jun 3, 2013 at 8:42 AM, Tracy Kukuselis  wrote:
> I am trying to install modperl 2.0.3 with httpd 2.4.2 (also tried 2.4.4),
> but am getting the following error:

2.4 isn't officially supported yet, although there are a couple builds
on the list you might try. See the list archives for those.

> Failed to obtain the MPM name. Please specify MP_APXS=/full/path/to/apxs to
> solve this problem.
> make:*** [path] Error 255

What OS and Perl version are you running? What command are you using
to build mod_perl? Do you know where your apxs executable is? ('which
apxs' should output the location).

>
> Using the following configure command
> configure --prefix=/usr/local/apache2 --disable-userdir --enable-expires
> --enable-headers --enable-ldap --enable-logio --enable-mime-magic
> --enable-so --enable-speling --endable-usertrack --enable-vhost-alias
> --with-port=80 --with-included-apr --with-included-apr-util
> --with-ssl=/usr/local/ssl/
>
> Where can I put the MPM name to get it to be picked up.   I tried to add
> --mpm-name=prefork, to the configure command, but the same problem.
>
>
> Thanks
> Tracy
>
>

[offtopic] Re: Problem installing SOAP::SOM, in dependency SOAP::Lite

[Fred Moyer]

[please post any non mod_perl issues on rt.cpan.org or
stackoverflow.com or email me directly (no response guaranteed)]

That's fixed in 0.717. Can you verify the Apache SOAP handler works in
that distro?

On Sat, Jun 1, 2013 at 7:58 AM, André Warnier  wrote:
> Hi.
>
> I don't really know if SOAP::Lite is supported or not ;-), but
> I saw PHRED lurking around here, so I'll try my luck.
>
> While trying to find my way around to interface with a Sharepoint web
> service, I encounter the following issue (visible at end if you want to skip
> to the flesh) :
>
> Platform : Windows XP SP3
> Perl (Strawberry) :
> C:\WINDOWS>perl -V
> Summary of my perl5 (revision 5 version 16 subversion 3) configuration:
>
>   Platform:
> osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
> uname='Win32 strawberry-perl 5.16.3.1 #1 Tue Mar 12 13:55:20 2013 i386'
> config_args='undef'
> hint=recommended, useposix=true, d_sigaction=undef
> useithreads=define, usemultiplicity=define
> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> use64bitint=undef, use64bitall=undef, uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
>   Compiler:
> cc='gcc', ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS
> -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict
> -aliasing -mms-bitfields',
> optimize='-s -O2',
> cppflags='-DWIN32'
> ccversion='', gccversion='4.6.3', gccosandvers=''
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long',
> lseeksize=8
> alignbytes=8, prototype=define
>   Linker and Libraries:
> ld='g++', ldflags ='-s -L"C:\sperl\perl\lib\CORE" -L"C:\sperl\c\lib"'
> libpth=C:\sperl\c\lib C:\sperl\c\i686-w64-mingw32\lib
> libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
> -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32
>  -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
> perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
> -ladvapi32 -lshell32 -lole32 -loleaut32 -lneta
> pi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
> libc=, so=dll, useshrplib=true, libperl=libperl516.a
> gnulibc_version=''
>   Dynamic Linking:
> dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
> cccdlflags=' ', lddlflags='-mdll -s -L"C:\sperl\perl\lib\CORE"
> -L"C:\sperl\c\lib"'
>
>
> Characteristics of this binary (from libperl):
>   Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
> PERLIO_LAYERS PERL_DONT_CREATE_GVSV
> PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
> PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC
> USE_ITHREADS USE_LARGE_FILES USE_LOCALE
> USE_LOCALE_COLLATE USE_LOCALE_CTYPE
> USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
>   Built under MSWin32
>   Compiled at Mar 12 2013 14:01:07
>   @INC:
> C:/sperl/perl/site/lib
> C:/sperl/perl/vendor/lib
> C:/sperl/perl/lib
> .
>
>
> Problem:
>
> C:\WINDOWS>cpan SOAP::SOM
> CPAN: CPAN::SQLite loaded ok (v0.202)
> Database was generated on Sat, 01 Jun 2013 14:34:32 GMT
> Running install for module 'SOAP::SOM'
> Running make for P/PH/PHRED/SOAP-Lite-0.716.tar.gz
> CPAN: LWP::UserAgent loaded ok (v6.04)
> CPAN: Time::HiRes loaded ok (v1.9725)
> Fetching with LWP:
> http://cpan.strawberryperl.com/authors/id/P/PH/PHRED/SOAP-Lite-0.716.tar.gz
> CPAN: YAML::XS loaded ok (v0.39)
> CPAN: Digest::SHA loaded ok (v5.84)
> Fetching with LWP:
> http://cpan.strawberryperl.com/authors/id/P/PH/PHRED/CHECKSUMS
> CPAN: Compress::Zlib loaded ok (v2.06)
> Checksum for
> C:\sperl\cpan\sources\authors\id\P\PH\PHRED\SOAP-Lite-0.716.tar.gz ok
> CPAN: Archive::Tar loaded ok (v1.90)
> CPAN: File::Temp loaded ok (v0.22)
> CPAN: Parse::CPAN::Meta loaded ok (v1.4404)
> CPAN: CPAN::Meta loaded ok (v2.120921)
> CPAN: Module::CoreList loaded ok (v2.83)
>
>   CPAN.pm: Building P/PH/PHRED/SOAP-Lite-0.716.tar.gz
>
> We are about to install SOAP::Lite and for your convenience will provide
> you with list of modules and prerequisites, so you'll be able to choose
> only modules you need for your configuration.
>
> XMLRPC::Lite, UDDI::Lite, and XML::Parser::Lite are included by default.
> Installed transports can be used for both SOAP::Lite and XMLRPC::Lite.
>
> Press  to see the detailed list.
>
> Feature   PrerequisitesInstall?
> -  
> Core Package  [*] Scalar::Util always
>   [*] URI
>   [*] constant
>   [*] Test::More
>   [*] MIME::Base64
>

Re: [OT] Apache::DBI

[Fred Moyer]

> Modules with reliable owners, such as Soap::Lite, deserve the highest
> level of confidence.

Currently SOAP::Lite doesn't have an 'owner' per se. I sent a patch
into rt.cpan.org a few weeks ago, and as a result I was given COMAINT
on CPAN for it, applied many fixes, and released 0.716 (which contains
at least one regression) a couple weeks ago. Now I'm working on 0.717,
and hopefully someone else will take this module on in a year.

So there are maintainers - when one becomes occupied with real world
tasks such as job, family, etc, then bugs get filed, and others step
up. It's generally how CPAN (and now Github) works to a large degree.

On Fri, May 31, 2013 at 1:41 PM, Jim Schueler  wrote:
>> With regards to Apache::DBI, it is very much supported :)
>
>
> No.  It is not.  What little I know of you, you seem knowledgable and
> experienced.  But you don't seem to have read this thread.  The
> documentation says that the module will be supported by this list, and the
> facts now demonstrate otherwise.
>
> Several contributors have responded now.  To paraphrase, they will (and I
> will and so will others) help the best they can.  But that's not what the
> documentation says.  I guess I'm just one of those whiners who expects the
> documentation to be reliable.
>
> I followed this thread from the beginning.  I compared the original
> observations with the documentation.  And either the documentation is wrong
> or (more likely) incomplete.  I think it's reasonable to assume that if no
> one steps up to take ownership, there is no owner.  And hence the code is
> unsupported.
>
> Early on, I tried to clarify.  Which I'll repeat:
>
>   If the code has no significant user base and no identifiable
>   owner/maintainer, use at your own risk.  Pretty much what you say
>   below.
>
>   If the code has a significant user base but no identifiable owner,
>   there's a lot less risk because you can get support from other users.
>
>   Modules with reliable owners, such as Soap::Lite, deserve the highest
>   level of confidence.
>
> Apache::DBI has no owner and therefore falls in category #2.  Or maybe
> someone will step foward, and thus category #3.  Otherwise, your comments
> below say the same thing.  Yet for some reason, you turned the big platitude
> guns on me.
>
> By omission, there seems to be consensus on these guidelines.  All the
> quibbling revolves around my estimate that most modules fall in the first
> category.  Personally, I would prefer no one estimated that 97.5% (or
> 118,000 perl modules) are still actively supported by their authors/
> designated successors.  Because I think that claim strains credibility.
>
>> ...this comes with the general open source software caveat - "Using open
>>
>> source software doesn't mean someone will do *your work* for free".
>
>
> I didn't originate the thread, but this response offends me.  If someone
> observes a problem with a module, is the point to discredit them instead?
>
> So far, there seems to be a tendency to overlook the substance of the
> discussion and react defensively to outsiders (as though I haven't
> participated here for 14 or 15 years).  What's up with that?
>
> Thanks for letting me get that off my chest.
>
>  -Jim
>
>
>
>
> On Fri, 31 May 2013, Fred Moyer wrote:
>
>>> In their absence, I'd note that your post has an interesting ambiguity:
>>> Is
>>> the number of unsupported modules 2.5% or 25%?
>>
>>
>> The 'supported' metric doesn't really translate the same in reference
>> to open source software as it does to commercial software. When a
>> commercial software product becomes unsupported (think IE6), then you
>> are out in the cold. You don't have the source code, so you can't fix
>> an issue with it, or hire someone to fix the issue. Unless you are
>> really good with a hex code editor and patching binary files, you're
>> out of luck.
>>
>> With open source software like Perl, you may see statements like 'Perl
>> 5.6 is no longer officially supported'. This means you probably won't
>> be able to get the P5P team to fix bugs or security issues if they
>> come up. Still, you have the source code, so you can fix it yourself.
>>
>> CPAN is a bit more murky in that individual authors can decide to
>> deprecate modules, or they can drop off the face of the earth, but
>> widely used modules such as Apache::DBI, SOAP::Lite (maintenance
>> recently stewarded by yours truly) will almost always have volunteers
>> step up and maintain them, because those volunteers need t

Re: [OT] Apache::DBI

[Fred Moyer]

> In their absence, I'd note that your post has an interesting ambiguity: Is
> the number of unsupported modules 2.5% or 25%?

The 'supported' metric doesn't really translate the same in reference
to open source software as it does to commercial software. When a
commercial software product becomes unsupported (think IE6), then you
are out in the cold. You don't have the source code, so you can't fix
an issue with it, or hire someone to fix the issue. Unless you are
really good with a hex code editor and patching binary files, you're
out of luck.

With open source software like Perl, you may see statements like 'Perl
5.6 is no longer officially supported'. This means you probably won't
be able to get the P5P team to fix bugs or security issues if they
come up. Still, you have the source code, so you can fix it yourself.

CPAN is a bit more murky in that individual authors can decide to
deprecate modules, or they can drop off the face of the earth, but
widely used modules such as Apache::DBI, SOAP::Lite (maintenance
recently stewarded by yours truly) will almost always have volunteers
step up and maintain them, because those volunteers need those modules
to be functioning for own work. In terms of a supported metric, I'd
say modules that are used by more than a few people are supported
100%.

With regards to Apache::DBI, it is very much supported :) But this
comes with the general open source software caveat - "Using open
source software doesn't mean someone will do *your work* for free". If
there's a feature that appeals to more than a couple users, or a bug
that affects more than a couple users, odds are that it will get
fixed. Features that only one user is after will likely not be
implemented by the maintainers, but patches for those features are
usually readily accepted.

On Fri, May 31, 2013 at 10:30 AM, Jim Schueler  wrote:
> No apology please.  In terms of trying to qualify any of this, a larger
> statistical pool is better.  And I am no authority.  My perceptions are
> largely based on forum postings which causes an inherent bias.
>
> I'd love to see this conversation continue, especially if participants
> included those who commit significant resources to their technology
> decisions.  In other words, people who hire and pay Perl programmers.
> They're likely to be as skeptical as I am.  I've never been a cheerleader.
>
> In their absence, I'd note that your post has an interesting ambiguity: Is
> the number of unsupported modules 2.5% or 25%?  (For more rhetorical
> nit-picking, you probably don't use the ones that don't work :)  Also, the
> significant question seems to be whether Apache::DBI is supported or not.
> From Mr. Zheng's point-of-view (in this case, the one that matters) the
> number might be much higher.
>
>  -Jim
>
>
> On Fri, 31 May 2013, André Warnier wrote:
>
>> Just butting in, apologies.
>>
>> It may not have been Jim's intention below, but I get the impression that
>> his comments on CPAN are a bit harsh.
>>
>> It is true that a number of modules are apparently no longer supported.  I
>> have used many modules over the years, and sometimes have had problems with
>> some of them (mostly not though). And when for these problematic cases, I
>> have tried to get help, the results have beem mixed; but the mix for me has
>> been rather good. I would say that in my case, 90% of the CPAN modules I
>> ever used worked out of the box.  For the 10% remaining, in 75% of the cases
>> I did get help from the person advertised as the author or the maintainer,
>> and in 25% of cases I never got a response.
>> But then, as Jim himself indicated, people move on, without necessarily
>> changing their email addresses.  Considering how old some of these modules
>> are, I guess people also retire, or even pass away.
>>
>> But the fact of the matter is that CPAN is still an incredible resource,
>> unequalled in my view by any other similar module library of any other
>> language anywhere. And I find it amazing that at least 90% of the modules
>> which I have downloaded from CPAN and used over the last 15 years, just
>> work, and moreover keep on working through many, many iterations of programs
>> and perl versions, and that in fact one very rarely needs additional support
>> for them.  When I compare this with other programming languages and support
>> libraries, I believe we perl programmers are incredibly spoiled.
>>
>> Another area where CPAN shines, is the documentation of most modules.  I
>> cannot count the times where I was faced with a request in an area of which
>> I knew nothing at all, and have just browsed CPAN for modules related to
>> that area, just to read their documentation and get at least an idea of what
>> this was all about.
>> In recent years, Wikipedia may slowly becoming a runner-up, in terms of
>> general information.  But when it comes down to the nitty-gritty of
>> interfacing with whatever API (or lack of ditto) programmers in their most
>> delirious moments might have c

Re: [ANNOUNCE] mod_perl 2.0.8

[Fred Moyer]

Thanks for the spot. I just pinged the Apache infrastructure team to see if
there's a cron job which makes the sync that needs a poke.


On Sat, Apr 20, 2013 at 10:43 AM, Dominic Hargreaves  wrote:

> On Wed, Apr 17, 2013 at 07:25:45PM -0700, Fred Moyer wrote:
> > I'm pleased to announce that mod_perl 2.0.8 is coming to a CPAN mirror
> near
> > you, as well as the following Apache project website links (note that the
> > Apache.org links may take a few hours to propagate to the mirrors).
> >
> > Thanks to all the contributors on this version!
> >
> >
> > http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
> > http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz.asc (pgp sig)
>
> I noticed that the Debian package watch file has
>
> http://perl.apache.org/dist/
>
> configured as the place to look for new versions, but 2.0.8 hasn't
> appeared there. Is this a deliberate or accidental divergence?
>
> Cheers,
> Dominic.
>
> --
> Dominic Hargreaves | http://www.larted.org.uk/~dom/
> PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
>

[ANNOUNCE] mod_perl 2.0.8

[Fred Moyer]

I'm pleased to announce that mod_perl 2.0.8 is coming to a CPAN mirror near
you, as well as the following Apache project website links (note that the
Apache.org links may take a few hours to propagate to the mirrors).

Thanks to all the contributors on this version!


http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz.asc (pgp sig)

  file: $CPAN/authors/id/P/PH/PHRED/mod_perl-2.0.8.tar.gz
  size: 3790026 bytes
   md5: df89f50a39e93ba5054651c281483ffb

=item 2.0.8 April 17, 2013

Perl 5.16.3's fix for a rehash-based DoS makes it more difficult to invoke
the workaround for the old hash collision attack, which breaks mod_perl's
t/perl/hash_attack.t. Patch from rt.cpan.org #83916 improves the fix
previously applied as revision 1455340. [Zefram]

On Perl 5.17.6 and above, hash seeding has changed, and HvREHASH has
disappeared. Patch to update mod_perl accordingly from rt.cpan.org #83921.
[Zefram]

Restore build with Perl 5.8.1, 5.8.2 etc: take care to use
$Config{useithreads} rather than $Config{usethreads}, and supply definitions
of Newx and Newxz as necessary. [Steve Hay]

On Perl 5.17.9, t/apache/read2.t fails because an "uninitialized value"
warning is generated for the buffer being autovivified. This is because
the sv_setpvn() that's meant to vivify the buffer doesn't perform set
magic; the warning is generated by the immediately following SvPV_force().
Patch to fix this from rt.cpan.org #83922. [Zefram]

Fix t/perl/hash_attack.t to work with Perl 5.14.4, 5.16.3 etc, which
contain a fix for CVE-2013-1667 (memory exhaustion with arbitrary hash
keys). This resolves rt.perl.org #116863, from where the patch was taken.
[Hugo van der Sanden]

use APR::Finfo instead of Perl's stat() in ModPerl::RegistryCooker to
generate HTTP code 404 even if the requested filename contains newlines
[Torsten]

Remove all uses of deprecated core perl symbols. [Steve Hay]

Add branch release tag to 'make tag' target. [Phred]

Re: [RELEASE CANDIDATE]: mod_perl-2.0.8 RC1

[Fred Moyer]

+1 on OS X, 5.16.2, 2.2.23.

We have 3 +1's, should be releasing shortly.

On Fri, Apr 5, 2013 at 1:31 AM, Steve Hay  wrote:
> Steve Hay wrote on 2013-04-02:
>> Fred Moyer wrote on 2013-04-02:
>>> A release candidate for mod_perl 2.0.8 is now available! Please
>>> download, test, and report back.
>>>
>>> http://people.apache.org/~phred/mod_perl-2.0.8-rc1.tar.gz
>>>
>>> MD5 (mod_perl-2.0.8-rc1.tar.gz) = ed056c6910914f5ecc2ac8171082a264
>>>
>>
>> +1 on Windows 7 x64 using VC++ 2010 and Apache 2.2.22 / Perl 5.17.10.
>> Will try with more Perl versions in the next day or two.
>
> Now tested successfully with Perls 5.8.2 (patched for VC++ 2010),
> 5.10.1, 5.12.4, 5.12.5, 5.14.3, 5.14.4, 5.16.2, 5.16.3 and 5.17.5 too
> (all on Windows 7 x64 using VC++ 2010 and Apache 2.2.22), so definitely
> a +1 from me!

[RELEASE CANDIDATE]: mod_perl-2.0.8 RC1

[Fred Moyer]

A release candidate for mod_perl 2.0.8 is now available! Please
download, test, and report back.

http://people.apache.org/~phred/mod_perl-2.0.8-rc1.tar.gz

MD5 (mod_perl-2.0.8-rc1.tar.gz) = ed056c6910914f5ecc2ac8171082a264

=item 2.0.8-rc1

Perl 5.16.3's fix for a rehash-based DoS makes it more difficult to invoke
the workaround for the old hash collision attack, which breaks mod_perl's
t/perl/hash_attack.t. Patch from rt.cpan.org #83916 improves the fix
previously applied as revision 1455340. [Zefram]

On Perl 5.17.6 and above, hash seeding has changed, and HvREHASH has
disappeared. Patch to update mod_perl accordingly from rt.cpan.org #83921.
[Zefram]

Restore build with Perl 5.8.1, 5.8.2 etc: take care to use
$Config{useithreads} rather than $Config{usethreads}, and supply definitions
of Newx and Newxz as necessary. [Steve Hay]

On Perl 5.17.9, t/apache/read2.t fails because an "uninitialized value"
warning is generated for the buffer being autovivified. This is because
the sv_setpvn() that's meant to vivify the buffer doesn't perform set
magic; the warning is generated by the immediately following SvPV_force().
Patch to fix this from rt.cpan.org #83922. [Zefram]

Fix t/perl/hash_attack.t to work with Perl 5.14.4, 5.16.3 etc, which
contain a fix for CVE-2013-1667 (memory exhaustion with arbitrary hash
keys). This resolves rt.perl.org #116863, from where the patch was taken.
[Hugo van der Sanden]

use APR::Finfo instead of Perl's stat() in ModPerl::RegistryCooker to
generate HTTP code 404 even if the requested filename contains newlines
[Torsten]

Remove all uses of deprecated core perl symbols. [Steve Hay]

Add branch release tag to 'make tag' target. [Phred]

Re: Wrong code example in /docs/general/testing/testing.html

[Fred Moyer]

Thanks for the spot, update committed.

On Mon, Mar 18, 2013 at 9:51 AM, Torsten Förtsch
 wrote:
> On 03/12/2013 02:59 AM, Martín Ferrari wrote:
>> +$r->write("ok 1");
>> +$r->write("not ok 2");
>
> I think it should read (missing \n):
>
> +$r->write("ok 1\n");
> +$r->write("not ok 2\n");
>
>
> Torsten

Re: Wrong code example in /docs/general/testing/testing.html

[Fred Moyer]

Thanks, change applied r1457851.

On Mon, Mar 11, 2013 at 6:59 PM, Martín Ferrari
 wrote:
> Hi,
>
> I was trying to set up a test environment for a mod_perl module, and
> -among many other problems I had with the docs, that I'll try to put
> in other reports-, I've found some code that does not even compile,
> and is missing required modules, under
> http://perl.apache.org/docs/general/testing/testing.html#Developing_Response_only_Part_of_a_Test
>
> The patch I manually generated (I don't have the sources for the docs):
>
> @@ -1,21 +1,23 @@
>  #file:t/response/TestApache/write.pm
>  #---
>  package TestApache::write;
>
>  use strict;
>  use warnings FATAL => 'all';
>
>  use constant BUFSIZ => 512; #small for testing
>  use Apache2::Const -compile => 'OK';
> +use Apache2::RequestIO;
> +use Apache2::RequestRec;
>
>  sub handler {
>  my $r = shift;
>  $r->content_type('text/plain');
>
>  $r->write("1..2\n");
> -$r->write("ok 1")
> -$r->write("not ok 2")
> +$r->write("ok 1");
> +$r->write("not ok 2");
>
>  Apache2::Const::OK;
>  }
>  1;
>
>
> --
> Martín Ferrari

Re: mod_perl resulting Apache failure

[Fred Moyer]

Can you post your failing tests? I'd give it a shot with 2.2.20 to see
if it works.

On Sun, Jan 20, 2013 at 6:38 AM,   wrote:
> Hi Fred,
>
> Thanks for the response.
>
> I tried 2.0.7 also but faced the same issue - Segmentation fault while 
> restarting Apache. But when I read the README document of mod_perl 2.0.7 its 
> stating that this version is not compatible with Apache httpd 2.2.20. Also, I 
> tried make test for mod_perl for both 2.0.7 and 2.0.5 but with non-root user 
> but its also failing.
>
> Please suggest.
>
> Thanks & Regards,
> Jitendra Soni
>
>
> 
> From: Fred Moyer [f...@redhotpenguin.com]
> Sent: Sunday, January 20, 2013 10:22 AM
> To: Soni, Jitendra
> Cc: modperl@perl.apache.org
> Subject: Re: mod_perl resulting Apache failure
>
> Have you tried 2.0.7?
>
> http://perl.apache.org/download/index.html
>
> On Sat, Jan 19, 2013 at 7:15 AM,   wrote:
>> Hi Team,
>>
>> I am installing Apache Mobile Filter on solaris 5.10 but after installing
>> mod_perl, Apache restart is failing. Below are steps executed by me:
>>
>> (1) Solaris 5.10 Sparx 64
>> (2) Installed perl 5.14.2
>> (3) Installed mod_perl 2.0.5
>> (4) Included mod_perl module in Apache httpd.conf ( iam using apache
>> 2.2.20).
>> (5) Restarted Apache - FAILED - by error - Segmentation Fault (Core Dumped).
>>
>> Can someone let me know did I missed anything during installation or what
>> can I do to fix this issue and make this work for me.
>>
>> Thanks in advance. I will greatly appreciate if you guys can help in fixing
>> the issue as this is very critical for our project.
>>
>> Regards,
>> Jitendra
>>
>> 
>> This message is for the designated recipient only and may contain
>> privileged, proprietary, or otherwise private information. If you have
>> received it in error, please notify the sender immediately and delete the
>> original. Any other use of the e-mail by you is prohibited.
>>
>> Where allowed by local law, electronic communications with Accenture and its
>> affiliates, including e-mail and instant messaging (including content), may
>> be scanned by our systems for the purposes of information security and
>> assessment of internal compliance with Accenture policy.
>>
>> __
>>
>> www.accenture.com
>
>
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise private information. If you have received it in 
> error, please notify the sender immediately and delete the original. Any 
> other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and its 
> affiliates, including e-mail and instant messaging (including content), may 
> be scanned by our systems for the purposes of information security and 
> assessment of internal compliance with Accenture policy.
>
> __
>
> www.accenture.com
>

Re: mod_perl resulting Apache failure

[Fred Moyer]

Have you tried 2.0.7?

http://perl.apache.org/download/index.html

On Sat, Jan 19, 2013 at 7:15 AM,   wrote:
> Hi Team,
>
> I am installing Apache Mobile Filter on solaris 5.10 but after installing
> mod_perl, Apache restart is failing. Below are steps executed by me:
>
> (1) Solaris 5.10 Sparx 64
> (2) Installed perl 5.14.2
> (3) Installed mod_perl 2.0.5
> (4) Included mod_perl module in Apache httpd.conf ( iam using apache
> 2.2.20).
> (5) Restarted Apache - FAILED - by error - Segmentation Fault (Core Dumped).
>
> Can someone let me know did I missed anything during installation or what
> can I do to fix this issue and make this work for me.
>
> Thanks in advance. I will greatly appreciate if you guys can help in fixing
> the issue as this is very critical for our project.
>
> Regards,
> Jitendra
>
> 
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and its
> affiliates, including e-mail and instant messaging (including content), may
> be scanned by our systems for the purposes of information security and
> assessment of internal compliance with Accenture policy.
>
> __
>
> www.accenture.com

Re: mod_perl2 memory problem

[Fred Moyer]

On Sat, Jan 19, 2013 at 12:45 PM, Idel Fuschini  wrote:
> Hi all,
> I have compiled apache webserver with this configuration:
>
> ./configure --prefix=/foo/apache-2.2.23-worker-1st --enable-modules=all
> --enable-mods-shared=all --disable-ipv6 --enable-ssl
> --with-ssl=/foo/openssl-1.0.1c --enable-proxy --enable-proxy-connect
> --enable-proxy-http --with-mpm=worker --enable-cgi
>
> without mod_perl without mod_perl each httpd process take 12m
>
> with mod_perl  each httpd process takes 38m
>
> and each request the memory increase the memory.

Either you are not loading all your modules into the parent httpd
process at startup time (startup.pl, process growth is code), or your
processes are setting globals that hold data from request handling
(process growth is data related.

If you can test on Solaris or OS X, I recommend running iosnoop (a
dtrace script) which will identify what files your application
touches. If you see your application accessing modules after the app
has started, put those modules in startup.pl

Although, 38 megabytes is small. I work with applications that have
512+ megabyte process footprints.

>
> mod_perl version is 2.0.5.
>
> Thanks
> idel

Re: Problem compiling 1.0 on linux

[Fred Moyer]

On Mon, Dec 3, 2012 at 6:26 AM, Hans C. Poo  wrote:
> I've continued looking with more atention, and the format messages were just 
> warnings, the error appears with an lvalue assignement in mod_perl.c:

Are you able to implement mod_perl2? Apache 1.x in particular has
reached end of life status.

>
> mod_perl.c:790:15: error: lvalue required as left operand of assignment
>
> And the aforementioned line is:
>
>   GvCV(exitgp) = perl_get_cv("Apache::exit", TRUE);
>
>
> ¿ Not sure but it's a gcc thing ?
>
> Hans
>
> Hans Poo, Welinux S.A.
> Bombero Ossa #1010, oficina 800,
> +56-2-3729770, Movil: +56-9-3199305
> Santiago, Chile
>
>
> - Mensaje original -
>> De: "Hans C. Poo" 
>> Para: modperl@perl.apache.org
>> Enviados: Lunes, 3 de Diciembre 2012 11:02:56
>> Asunto: Problem compiling 1.0 on linux
>>
>> Hi.
>>
>> I have a legacy mod_perl project, and need to create a development
>> environment.
>>
>> mod_perl-1.31 y apache_1.3.41 on Ubuntu Linux 12.04
>>
>> The makefile is created fine:
>> hans@tierra:~/desarrollo/mod_perl-1.31$ perl Makefile.PL DO_HTTPD=1
>> USE_APACI=1 EVERYTHING=1
>>
>> Then, when issuing make:
>>
>> cc -O2 -g -I/usr/lib/perl/5.14/CORE -D_REENTRANT  -DDEBIAN
>> -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> -DMOD_PERL_VERSION=\"1.31\"
>> -DMOD_PERL_STRING_VERSION=\"mod_perl/1.31\" -I../..
>> -I/usr/lib/perl/5.14/CORE -I../../os/unix -I../../include
>>-DLINUX=22 -DHAVE_SET_DUMPABLE -DMOD_PERL -DUSE_PERL_SSI
>> -D_REENTRANT  -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector
>> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> -DUSE_HSREGEX -DNO_DL_NEEDED -D_REENTRANT  -DDEBIAN
>> -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 `../../apaci` -c
>> mod_perl.c
>> mod_perl.c: En la función ‘mp_check_version’:
>> mod_perl.c:538:2: aviso: se desconoce el carácter de tipo de
>> conversión ‘_’ en el formato [-Wformat]
>> mod_perl.c: En la función ‘perl_module_init’:
>> mod_perl.c:564:2: aviso: se desconoce el carácter de tipo de
>> conversión ‘v’ en el formato [-Wformat]
>> mod_perl.c: En la función ‘perl_startup’:
>> mod_perl.c:790:15: error: se requiere un l-valor como operando
>> izquierdo de la asignación
>> make[5]: *** [mod_perl.o] Error 1
>> make[4]: *** [all] Error 1
>> make[3]: *** [subdirs] Error 1
>>
>> Looking at the code, there are some formats en the form %_ until i
>> can see it is complaining for the underscore.
>>
>> Thanks
>> Hans
>>

Re: get the incoming TCP protocol type

[Fred Moyer]

> But I do not find an "apxs" anywhere.
> Do I need to install some "dev" package to get it ?

The Debian executables can have non-standard names - try apxs2?

On Sat, Nov 24, 2012 at 2:51 PM, André Warnier  wrote:
> Torsten Förtsch wrote:
>>
>> On 11/24/2012 08:11 PM, Fred Moyer wrote:
>>>
>>> On Sat, Nov 24, 2012 at 7:58 AM, André Warnier  wrote:
>>>>>
>>>>> Inside a mod_perl2 request handler, how can I find out if the current
>>>>> request was received via HTTP or HTTPS ?
>>>
>>> Torsten is the author of this module, so he can explain it in more
>>> detail, but it looks like it can do part of what you need:
>>>
>>> https://metacpan.org/module/Apache2::ModSSL
>>
>>
>> That is, of course, what I would use. If I recall correctly, the module
>> was written to have access to the SSL related information *prior to* the
>> response phase. If you need it only in the response phase you can have
>> mod_ssl export almost all of the stuff accessible via Apache2::ModSSL as
>> environment variables accessible via $r->subprocess_env.
>>
>
> I'm in the Fixup phase.
>
> Hmm.
> C:\develop\06_SVN\AP2lib\trunk\modlib\PROXY>ppm search Apache2::ModSSL
> Downloading ActiveState Package Repository packlist...done
> Updating ActiveState Package Repository database...done
> Downloading bribes-5.12 packlist...not modified
> Downloading trouchelle-5.12 packlist...not modified
> Downloading winnipeg-5.12 packlist...not modified
> Downloading wxperl packlist...not modified
> *** no packages matching 'Apache2::ModSSL' found ***
>
> No Win32 port available for that, I guess.
> (We work mostly (whenever we can get away with it, essentially) on Linux
> servers, but try
> to keep our solutions portable to Windows too, since we occasionally have
> clients that
> insist on it.)
>
> Building it on Windows from the tar.gz doesn't seem to work either, as it
> appears to require gcc (and probably a lot of other things not available on
> my XP laptop).
>
> However, the real target system this time is Linux, and it's kind of
> one-of-a-kind for
> now, so let's try :
>
> root@arthur:~# apt-cache search apache2 | grep SSL
> libapache2-mod-log-sql-ssl - Use SQL to store/write your apache queries logs
> - SSL extension
> libapache2-mod-gnutls - Apache module for SSL and TLS encryption with GnuTLS
>
> Hmm, no handy Debian package.  So, the hard way :
>
> 
> GOT /root/.cpan/sources/authors/id/O/OP/OPI/CHECKSUMS.tmp8430
> Checksum for
> /root/.cpan/sources/authors/id/O/OP/OPI/Apache2-ModSSL-0.08.tar.gz ok
> CPAN: Archive::Tar loaded ok (v1.88)
> Apache2-ModSSL-0.08/
> Apache2-ModSSL-0.08/t/
> Apache2-ModSSL-0.08/t/conf/
> Apache2-ModSSL-0.08/t/conf/localhost.cert
> Apache2-ModSSL-0.08/t/conf/extra.conf.in
> Apache2-ModSSL-0.08/t/TestSSL/
> Apache2-ModSSL-0.08/t/TestSSL/is_https.pm
> Apache2-ModSSL-0.08/t/TestSSL/lookup.pm
> Apache2-ModSSL-0.08/t/2lookup.t
> Apache2-ModSSL-0.08/t/1is_https.t
> Apache2-ModSSL-0.08/t/TEST.PL
> Apache2-ModSSL-0.08/META.yml
> Apache2-ModSSL-0.08/Changes
> Apache2-ModSSL-0.08/perl-Apache2-ModSSL.spec
> Apache2-ModSSL-0.08/MANIFEST
> Apache2-ModSSL-0.08/Makefile.PL
> Apache2-ModSSL-0.08/lib/
> Apache2-ModSSL-0.08/lib/Apache2/
> Apache2-ModSSL-0.08/lib/Apache2/ModSSL.pm
> Apache2-ModSSL-0.08/README
> Apache2-ModSSL-0.08/mk_README.sh
> Apache2-ModSSL-0.08/ModSSL.xs
> CPAN: File::Temp loaded ok (v0.22)
>
>   CPAN.pm: Going to build O/OP/OPI/Apache2-ModSSL-0.08.tar.gz
>
> Could not figure out which apxs to use. Try the -apxs option.
> Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
>   OPI/Apache2-ModSSL-0.08.tar.gz
>   /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
> Running make test
>   Make had some problems, won't test
> Running make install
>   Make had some problems, won't install
> root@arthur:~#
>
> Ok, I'm a bit rusty about building from CPAN.
>
> This is Linux Debian :
>
> root@arthur:~# uname -a
> Linux arthur 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux
>
> Perl is :
> root@arthur:~# perl -vv
>
> This is perl, v5.10.1 (*) built for i486-linux-gnu-thread-multi
> (with 56 registered patches, see perl -V for more detail)
>
> Apache httpd is :
> [Mon Nov 12 15:01:23 2012] [notice] Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12
> mod_jk/1.2.30
> PHP/5.3.3-7+squeeze8 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o
> mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming
> normal operations
>
> But I do not find an "apxs" anywhere.
> Do I need to install some "dev" package to get it ?
>
> root@arthur:~# apt-cache search apache2 | grep dev
> apache2-prefork-dev - Apache development headers - non-threaded MPM
> apache2-threaded-dev - Apache development headers - threaded MPM
> libapache2-mod-perl2-dev - Integration of perl with the Apache2 web server -
> development files
>
> ?
>
>
>

Re: use "global" data in handler (was : custom proxy setup with mod_perl)

[Fred Moyer]

On Sat, Nov 24, 2012 at 5:09 AM, André Warnier  wrote:
> For the PerlFixupHandler which was discussed before, I need to compare the
> current request URL to a predefined static list of URLs, to decide how
> exactly to proxy this call.
> At the moment, there are about 15 URLs in that list; and I believe that
> there might, maybe in some cases, be up to 100.

Maybe read the variables in startup.pl, and setup a package to provide
them to other modules at runtime?
http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File

# pass $urllist var from httpd.conf?

startup.pl:
> my $fh;
> open($fh,'<',$urllist) or safe_die;
> my @list = <$fh>;
> close $fh;
My::Proxy->set_urllist(\@list);


There are a few different ways to specify $urllist in httpd.conf I
think so that startup.pl can get at it at startup time. Remember that
startup.pl is actually read twice I think (when apache starts, it
starts twice to make sure it can survive a restart).

http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html#C_restart_count_

Hope that helps - there are some details I'm probably glossing over here.

>
> I suppose that I could make this list of URLs available to the handler by
> doing something like this :
>
> 
>   ...
>   PerlFixupHandler My::Proxy->handler
>   PerlAddVar CHKU "http://www.site-1.com/";
>   PerlAddVar CHKU "http://www.site-2.org/path?query";
>   PerlAddVar CHKU "http://www.site-3.biz/";
>   PerlAddVar CHKU "http://www.site-4.edu/";
>   etc.. 50 times
> 
>
> and then do
> my @list = $r->dir_config('CHKU');
> in the handler.
>
> On the other hand, I could also put these URLs in a separate configuration
> text file, and have the handler read it at each invocation :
>
> 
>   ...
>   PerlFixupHandler My::Proxy->handler
>   PerlSetVar URL_LIST "/etc/apache2/conf/urllist.txt"
> 
>
> and in the handler :
>
> my $urllist = $r->dir_config('URL_LIST') || "default.list";
> my @list = ();
> my $fh;
> open($fh,'<',$urllist) or safe_die;
> @list = <$fh>;
> close $fh;
>
> But neither of these is very satisfying.
> The first one above is OK up to 10-20 URLs, but becomes a bit unsightly and
> clumsy for more.
> The second one has the handler read and parse a file at each invocation
> (even if the request URL turns out not to be in the list, and the call
> should just be proxy-ed as is).
> Sounds inefficient.
>
> So, I would like to do this :
>
> Package My::Proxy;
>
> our $URLS;
>
> sub handler {
> my $r = shift;
> unless (defined($URLS)) {
> my $urllist = $r->dir_config('URL_LIST') ||
> "/etc/apache2/default_urls.list";
> my $fh;
> my @list;
> open($fh,'<',$urllist) or safe_die;
> @list = <$fh>;
> close $fh;
> $URLS = \@list;  # or = [ @list ] ??
> }
> .. use @$URLS, read-only ..
>
>
> }
>
> As I understand the above, in a pre-fork MPM, each time Apache forks a new
> child, at the first handler invocation $URLS will be undef, and thus the
> code in the handler will define it, as a reference to an array of URLs read
> from the file.
> And from then on, the list accessible through $URLS should remain available
> and unvariable at each subsequent invocation of this handler (in this
> child), as long as this Apache child process lives.
>
> First, I may be wrong in my understanding. (that's a question).
>
> Second, if I am right in the above, then does this same understanding extend
> to all possible Apache MPMs ?  Or am I creating a horrible risk of some race
> condition, or memory leak here ?
>
>
>
>
>
>

Re: get the incoming TCP protocol type

[Fred Moyer]

On Sat, Nov 24, 2012 at 7:58 AM, André Warnier  wrote:
> Inside a mod_perl2 request handler, how can I find out if the current
> request was received via HTTP or HTTPS ?

Torsten is the author of this module, so he can explain it in more
detail, but it looks like it can do part of what you need:

https://metacpan.org/module/Apache2::ModSSL

use Apache2::ModSSL;

my $c=$r->connection;
if( $c->is_https )

>
> I mean :
> The client (browser e.g.) gets a URL "http://host.x.y/path1/path2..";, and
> - translates host.x.y to an IP
> - makes a connection to that IP (and port)
> - sends a request like :
>   GET /path1/path2.. HTTP/1.1
>   Host: host.x.y
>   ...
>
> OR
> The client (browser e.g.) gets a URL "https://host.x.y/path1/path2..";, and
> - translates host.x.y to an IP
> - makes an *SSL* connection to that IP (and port)
> - sends a request like :
>   GET /path1/path2.. HTTP/1.1
>   Host: host.x.y
>   ...
>
> and
>
> Inside a handler, I can get
> $r->hostname   ==> host.x.y
> $r->uri and $r->unparsed_uri  ==> /path1/path2..
>
> and I can also get the port on which the request was received (presumably),
> via
> $r->get_server_port
> but that is not really a guarantee, any port could be set for either HTTP or
> HTTPS.
>
> and then I see
> $r->proto and $r->proto_num
> but these are relative to the protocol string as it appears in the first
> request line, not to the type of connection that was used for the request.
> And in the request, I guess it would always be HTTP/1.1, or ?
> (I don't have a HTTPS host right now to check this)
>
> And I haven't really found anything yet in Apache2:RequestRec,
> Apache2::Connection or Apache2::ServerRec which would provide that
> information.
>
> Is there somewhere a "is_secure()" or something which provides that ?
> Or can I rely on the presence/absence of some request header ?
>
> Help..
>
>
> The point is, I'd like to write the handler once, and use it inside a HTTP
> or a HTTPS host indifferently.  And if possible, I'd also like to avoid
> having to tell the handler where he lives via some PerlSetVar just for that.
> But maybe that's the easiest solution ?
>

Re: custom proxy setup with mod_perl

[Fred Moyer]

On Fri, Nov 23, 2012 at 3:06 PM, André Warnier  wrote:

> Ok, get it, thanks.
> All-in-one, as a substitute for mod_proxy.
> I will have a second look now.

Feel free to write me off list with any questions you have specific to
this module, but if you can do what you need with mod_proxy I would
recommend that approach.

Re: custom proxy setup with mod_perl

[Fred Moyer]

On Fri, Nov 23, 2012 at 2:18 PM, André Warnier  wrote:
> Fred Moyer wrote:
>>
>> You might want to take a look at a mod_perl based proxy module I wrote
>> - https://metacpan.org/module/Apache2::Proxy
>>
>> It was used in conjunction with Perlbal and a couple other tricks, but
>> was pretty speedy given the crude nature of how I implemented it.
>
>
> No offense intended, Fred, but without much of a documentation, this is bit
> above my level.  I have trouble even understanding where it fits in.

None taken, you're quite right, this needs (more) documentation. It
was open sourced when still in rough form. I'll send a ping when I get
it cleaned up and 0.05 released. Anyway, here's the basic way I used
it. Torsten's solution is probably technically more adept, but I
couldn't do what I needed to using filtering, so I had to write this.


SetHandler  modperl
PerlHeaderParserHandler Apache2::Const::OK
PerlAccessHandler   Apache2::Const::OK
PerlAuthenHandler   Apache2::Const::OK
PerlAuthzHandlerApache2::Const::OK
PerlTypeHandler Apache2::Const::OK
PerlFixupHandlerApache2::Const::OK
PerlResponseHandler My::Proxy->handler


package My::Proxy;
use base 'Apache2::Proxy';

sub handler {
my ($r, $class) = @_;

# examine request to see if it needs to be modified

# if not, pass to Apache2::Proxy
return $class->SUPER::handler($r);

# else fixup the request as needed.
}

Re: custom proxy setup with mod_perl

[Fred Moyer]

You might want to take a look at a mod_perl based proxy module I wrote
- https://metacpan.org/module/Apache2::Proxy

It was used in conjunction with Perlbal and a couple other tricks, but
was pretty speedy given the crude nature of how I implemented it.

On Fri, Nov 23, 2012 at 9:39 AM, André Warnier  wrote:
> Hi.
>
> I am trying to solve an unconventional (I think) issue with mod_perl (or
> even without it).
> Environment : Apache 2.2/mod_perl 2 under Linux.
>
> The issue :
> A number of workstations are in a LAN, using a local DNS server under my
> control.
> In the same LAN (192.168.45.0), I have a Linux host running Apache
> 2.2/mod_perl 2, also under my full control (IP 192.168.45.100).
>
> Currently, the LAN workstations access external websites such as (for the
> sake of example) :
> 1) http://www.site-1.com  (IP 1.2.3.4)
> 2) http://www.site-2.biz  (IP 2.3.4.5)
> 3) http://www.site-3.org  (IP 3.4.5.6)
> 4) http://www.site-4.co.uk (IP 4.5.6.7)
> (all these IP's being supposedly real public Internet IP addresses)
>
> In the future, I would like that when the workstations try to access
> websites (2) and (4) above, they access them through my Apache/mod_perl
> host.
> The reason for this is that
> a) I need to authenticate the users
> b) I need to allow some users to access these external servers, and deny
> other users (and for those, I need to return a nice page explaining why)
>
> I already do the authentication/authorization using custom PerlAuth*
> handlers.
> I also know how to write PerlFixupHandler and PerlTransHandler modules, and
> how to "push" other Perl "HTTP cycle" handlers when needed.
>
> My basic scheme is as follows :
> - the DNS server configuration is modified so that when resolving the
> hostnames (2) and (4) above, it returns the IP address of the internal
> Apache host (192.168.45.100).
> When a workstation thus wants to connect to webserver (2) above, in reality
> it connects to the internal Apache host, where I want to perform my mod_perl
> magic.
> - on the Apache host, there is a virtual host configured with
>   ServerAlias www.site-2.biz
>   ServerAlias www.site-4.co.uk
> so it responds to these requests.
>
> The Apache host has access to the "real" IP addresses of the above external
> webservers.
> (For example, in its own "hosts" file; or it has itself an "uncorrupted" DNS
> server which delivers the original IP addresses).
>
> In the Apache host, I have the following configuration section :
> 
>   AuthType MyOwn
>   AuthName CheckProxy
>   PerlAuthenHandler my:AuthHandler->get_id
>   PerlAuthzHandler my:AuthHandler->allow_or_not
>   Require valid-user
>   PerlFixupHandler 
>   PerlTransHandler 
>   ProxyPass http://(corresponding hostname)/(path and query as received)
> 
>
> Now my questions are : if I do something at the level of the
> PerlFixupHandler or PerlTransHandler,
> 1) is that "early enough" to be before the Apache ProxyPass step ?
> 2) can I set the "(corresponding hostname)" above in such a Perl handler, or
> otherwise manipulate the URI before it gets proxy-ed ?
> 3) do I need this ProxyPass directive in my configuration, or can I just set
> the Apache response handler to be mod_proxy_http, in one of the Perl
> handlers ? and if yes, how ?
>
> I'd be thankful for any answer or tip, even about a solution which does not
> involve mod_perl at all. (But in reality, I do need to do a bit more in my
> handlers than I allude to above).
>
>
>
>
>
>
>
>
>
>

Re: Apache2::SizeLimit still broken on OS X?

[Fred Moyer]

The issue appears to lie in BSD::Resource:

https://metacpan.org/module/Apache::SizeLimit#BSD-and-OSX-

On Tue, Oct 30, 2012 at 9:50 AM, Ken Youens-Clark  wrote:
> I'm writing to ask if Apache2::SizeLimit is still considered broken on OS X?
>
> Ken

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

[Fred Moyer]

On Wed, Oct 10, 2012 at 12:39 PM, Perrin Harkins  wrote:
>> 2) Do you believe that there are any compelling reasons to pick a mod_perl
>> approach over a plack runner approach that we may be missing?
>
> Advantages of a mod_perl approach:
> - Access to all the mod_perl stuff on CPAN (auth modules, SizeLimit,
> rate-limiting, etc.).
> - Ability to use the Apache API when handling requests.
> - Sounds like at least some of your team has real-life experience
> running a site on mod_perl.

- Knowledge that the base Apache httpd codebase is used by many other
websites, and has been through security audits, performance tuning,
and is composed of a set of developers who are committed to the long
term health of the codebase.

- A stable history of distribution packaging. Odds are the platform
you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite
some time.

- Knowledge that mod_perl has been proven in large scale deployments.
The biggest I've worked on is about 500 servers if I recall correctly.

Re: mod_perl build with perlbrew

[Fred Moyer]

On Wed, Sep 19, 2012 at 2:34 PM, bluedome  wrote:
>
> That works, thanks.
>
> Now it can't locate: ApacheTest/PerlRequireTest.pm, is that a dynamically
> created module? Because the file isn't in the mod_perl source tree at all.

It is created as a test file:

phred@pooky ~/dev/svn/modperl/mod_perl-2.0 $ find . -name 'PerlRequireTest.pm'
./t/htdocs/testdirective/main/ApacheTest/PerlRequireTest.pm
./t/htdocs/testdirective/vh/ApacheTest/PerlRequireTest.pm

phred@pooky ~/dev/svn/modperl/mod_perl-2.0 $ more
t/htdocs/testdirective/vh/ApacheTest/PerlRequireTest.pm

package ApacheTest::PerlRequireTest;
$ApacheTest::PerlRequireTest::MAGIC = 'PerlRequired by VirtualHost';
1;

>
>
> Andy Colson-2 wrote:
>>
>> On 9/19/2012 2:43 PM, bluedome wrote:
>>>
>>>
>>> I'm building mod_perl with a perl built using perlbrew.
>>>
>>> The build succeeds but make test fails because @INC is not correct.
>>>
>>> @INC for the perlbrew-built perl is:
>>>
>>>@INC:
>>>
>>> /opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0/x86_64-linux
>>>  /opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0
>>>
>>> /opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/5.16.0/x86_64-linux
>>>  /opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/5.16.0
>>>
>>> I built mod_perl with this perl, so it seems like it should keep this in
>>> INC, but it doesn't.  When I run
>>> apache the INC is:
>>>
>>> /usr/sbin/httpd  -d /opt/comms/be/code/apache_extensions/mod_perl-2.0.7/t
>>> -f
>>> /opt/comms/be/code/apache_extensions/mod_perl-2.0.7/t/conf/httpd.conf -D
>>> APACHE2
>>> using Apache/2.2.15 (prefork MPM)
>>>
>>> waiting 120 seconds for server to start: .Can't locate lib.pm in @INC
>>> (@INC
>>> contains:
>>> /opt/comms/be/code/apache_extensions/mod_perl-2.0.7/t/htdocs/testdirective/main
>>> /opt/comms/be/code/apache_extensions/mod_perl-2.0.7/t/htdocs/testdirective/perlmodule-vh
>>> /usr/lib/site_perl/5.16.0/x86_64-linux /usr/lib/site_perl/5.16.0
>>> /usr/lib/5.16.0/x86_64-linux /usr/lib/5.16.0).
>>>
>>> I have tried modifying the INC setting during the mod_perl build by using
>>> a
>>> command of the form:
>>>
>>> perl Makefile.PL MP_APXS=/usr/sbin/apxs INC="-I -I..."
>>>
>>> and also I've tried setting LD_LIBRARY_PATH environment variable to those
>>> paths when running httpd, and still getting this error.
>>>
>>> My questions are:
>>>
>>> 1. why does mod_perl lose the INC that is required to run the perl that
>>> it
>>> is built with?
>>> 2. what do I try next?
>>>
>>> Thanks
>>>
>>
>> Maybe setting @INC in apache.conf?
>>
>> add:
>>
>> PerlSwitches -I
>> "/opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0/x86_64-linux"
>>
>> PerlSwitches -I
>> "/opt/comms/be/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0"
>>
>> etc...
>>
>>
>> its not perfect... but maybe?
>>
>> -Andy
>>
>>
>>
>>
>>
>>
>
> --
> View this message in context: 
> http://old.nabble.com/mod_perl-build-with-perlbrew-tp34454307p34454815.html
> Sent from the mod_perl - General mailing list archive at Nabble.com.
>

Re: Mod_Perl2 getting started

[Fred Moyer]

Try this link:

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

For handling POST data you will likely want to install libapreq2,
which is basically the equivalent of CGI:

http://search.cpan.org/dist/libapreq2/

use Apache2::Request;

$req = Apache2::Request->new($r);
@foo = $req->param("foo");
$bar = $req->args("bar");

On Tue, Aug 21, 2012 at 12:27 PM,   wrote:
> Hi,
>
> I’m finding the online documentation regarding mod_perl2 confusing
> with regards to all the various modules dealing with request structures etc:
> APR::Request, Apache2::Request, Apache2::RequestRec, Apache2::Upload,
> etc.
>
> Does anyone know of a tutorial or example code that sorts these out?
>
> Ideally a simple one module working code response handler that illustrates
> access to the
> parsed request,
> handles args as querystrings and Post data, uploads a file or
> two, and returns an html
> page to the requestor. Anyone have something like that?
>
> Thanks very much in advance,
> Joe N

Re: [mp2] mod_perl 2.0.7 Segfault When Loading Certain Perl Module

[Fred Moyer]

Can you try the latest version from source?

http://perl.apache.org/download/source.html

It looks like you are using perl 5.16, some recent fixes were
committed there. The subversion tip will likely be the 2.0.8 RC in a
week or so.

On Mon, Aug 13, 2012 at 3:01 PM, Jason Lin  wrote:
> Hi,
>
> I work for a project that has been using mod_perl for quite a while.
> Recently, we upgraded our 64-bit web server with Perl 5.16, mod_perl 2.0.7
> (it's 2.0.6 with patch), and apache 2.2.22 on CentOS 6.3. Since then, we've
> been unable to start Apache server (segmentation faults) with same
> httpd.conf which worked previously.
>
> As far as I can tell, the segfault seems to be triggered while trying to
> load any Perl module using either PerlModule directive or in  block in
> httpd.conf that directly or indirectly use Carp, or even just try to load
> Carp itself. Strace shows that the process would segfault while loading (or
> right after loading) Carp.pm. The server can still successfully start and
> work when carefully removing such modules in httpd.conf.
>
> Is anyone seeing this same issue or have any ideas how it can be fixed other
> than trying to hack through all the Perl modules to make sure Carp is not
> called?
>
>
> perl -V
> Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
>
>   Platform:
> osname=linux, osvers=2.6.32-279.1.1.el6.x86_64, archname=x86_64-linux
> uname='linux fox.cosmic.ucar.edu 2.6.32-279.1.1.el6.x86_64 #1 smp tue
> jul 10 13:47:21 utc 2012 x86_64 x86_64 x86_64 gnulinux '
> config_args='-Dprefix=/ops/tools -des
> -Accflags=-DPERL_RELOCATABLE_INCPUSH'
> hint=recommended, useposix=true, d_sigaction=define
> useithreads=undef, usemultiplicity=undef
> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> use64bitint=define, use64bitall=define, uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
>   Compiler:
> cc='cc', ccflags ='-DPERL_RELOCATABLE_INCPUSH -fno-strict-aliasing -pipe
> -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64',
> optimize='-O2',
> cppflags='-DPERL_RELOCATABLE_INCPUSH -fno-strict-aliasing -pipe
> -fstack-protector -I/usr/local/include'
> ccversion='', gccversion='4.4.6 20120305 (Red Hat 4.4.6-4)',
> gccosandvers=''
> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
> alignbytes=8, prototype=define
>   Linker and Libraries:
> ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
> libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib
> /lib64 /usr/lib64 /usr/local/lib64
> libs=-lnsl -lgdbm -ldl -lm -lcrypt -lutil -lc
> perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
> libc=, so=so, useshrplib=false, libperl=libperl.a
> gnulibc_version='2.12'
>   Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
> -fstack-protector'
>
>
> Characteristics of this binary (from libperl):
>   Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
> PERL_MALLOC_WRAP PERL_PRESERVE_IVUV
> PERL_RELOCATABLE_INCPUSH USE_64_BIT_ALL
> USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE
> USE_LOCALE_COLLATE USE_LOCALE_CTYPE
> USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
>   Built under linux
>   Compiled at Aug  1 2012 16:14:39
>   %ENV:
> PERL5LIB="/ops/tools/lib"
>   @INC:
> /ops/tools/lib
> /ops/tools/lib/perl5/site_perl/5.16.0/x86_64-linux
> /ops/tools/lib/perl5/site_perl/5.16.0
> /ops/tools/lib/perl5/5.16.0/x86_64-linux
> /ops/tools/lib/perl5/5.16.0
> .
>
> Note that we compiled Perl with relocation flag (-DPERL_RELOCATABLE_INCPUSH)
> turned on, yet same issue can also be found without the flag in our test.
>
> Any help/advice would be appreciated, thank you in advance.
>
>
> Best,
> Jason

Re: development state of MP

[Fred Moyer]

On Wed, Aug 8, 2012 at 10:30 AM, Randolf Richardson  wrote:
>> I have not used modperl for long days. Is Apache mod_perl in actively
>> development recently? or just in maintenance state?
>
> It seems to me that it's quite active as a lot of people have been
> discussing some aspects of its code.

Yes, we've had 2 mod_perl core releases so far in 2012, and another
one is expected soon. While not a lot of new features are being added,
we've been keeping up with the newer Perl and Apache versions. Since
mod_perl exposes the Apache API, the development follows suit there in
terms of features.

>
> The thing that's improtant to remember about ModPerl is that it's
> very well written, most likely because it's well thought out, and so
> it doesn't seem to need a lot of changes.
>
> Where most of the activity will occur, I've noticed, is within the
> various CPAN modules that provide specific functionality.  ModPerl is
> more of a facilitator to integrate Perl into Apache and APR, and make
> it persistent (which has the wonderful side-effect of major
> performance gains).
>
>> Thank you.
>
> Randolf Richardson - rand...@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> http://www.inter-corporate.com/
>
>

[ANNOUNCE] Apache-Test 1.38

[Fred Moyer]

Coming to a CPAN mirror near you.

MD5 (Apache-Test-1.38.tar.gz) = dc7edf358dfea5bcf6ef4cdfe81e5dad

=item 1.38 Aug 6 2012

Fix log_watch.t on Windows, which can't (naturally) delete open files.
[Steve Hay]

Fix t_filepath_cmp, t_catfile and t_catfile_apache in Apache::TestUtil on
Windows: their use of Win32::GetLongPathName() was broken for non-existent
files. [Steve Hay]

Remove use of Nullsv as per modperl commit 1362399. [Steve Hay]

have Apache::TestConfigPerl::configure_inc set up @INC to include
../blib/lib and ../blib/arch if they exist. The bundled Apache::Reload
may fail to load Apache2::Const & co otherwise when testing.
[Torsten Foertsch]

Re: error compiling 2.0.7

[Fred Moyer]

You might want to try what David Wheeler did on this thread. Getting
Perl built with -fPIC correctly can be tricky.

http://www.gossamer-threads.com/lists/modperl/modperl/101165

On Mon, Jul 23, 2012 at 11:19 AM, Jiří Pavlovský  wrote:
> On 23.7.2012 19:59, Fred Moyer wrote:
>>
>> On Mon, Jul 23, 2012 at 9:59 AM, Jiří Pavlovský  wrote:
>>>
>>> I'm trying (unsuccessfully)  to compile 2.0.7 with perl-5.16 and
>>> httpd-2.2.22. The error is below. I have a perl compiled with fPIC. I put
>>> fPIC into LDFLAGS when compiling mod_perl.
>>> Anyway to make this work?
>>
>> Are you sure it is compiled with -fPIC? Can you post 'perl -V'?
>>
>
>
> Here it is
>
> Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
>
>   Platform:
> osname=linux, osvers=3.2.21-1.32.6.amzn1.x86_64, archname=x86_64-linux
> uname='linux ip-10-54-250-162 3.2.21-1.32.6.amzn1.x86_64 #1 smp sat jun
> 23 02:32:15 utc 2012 x86_64 x86_64 x86_64 gnulinux '
> config_args=''
> hint=recommended, useposix=true, d_sigaction=define
> useithreads=undef, usemultiplicity=undef
> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> use64bitint=define, use64bitall=define, uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
>   Compiler:
> cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-O2',
> cppflags='-fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include'
> ccversion='', gccversion='4.4.6 20110731 (Red Hat 4.4.6-3)',
> gccosandvers=''
> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
> alignbytes=8, prototype=define
>   Linker and Libraries:
> ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
> libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib
> /lib64 /usr/lib64 /usr/local/lib64
> libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
> perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
> libc=/lib/libc-2.12.so, so=so, useshrplib=false, libperl=libperl.a
> gnulibc_version='2.12'
>   Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
> -fstack-protector'
>
>
> Characteristics of this binary (from libperl):
>   Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
> PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_ALL
> USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE
> USE_LOCALE_COLLATE USE_LOCALE_CTYPE
> USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
>   Built under linux
>   Compiled at Jul 22 2012 19:09:19
>   @INC:
> /opt/perl/lib/site_perl/5.16.0/x86_64-linux
> /opt/perl/lib/site_perl/5.16.0
> /opt/perl/lib/5.16.0/x86_64-linux
> /opt/perl/lib/5.16.0
> .
>
> --
> Jiří Pavlovský
>

Re: error compiling 2.0.7

[Fred Moyer]

On Mon, Jul 23, 2012 at 9:59 AM, Jiří Pavlovský  wrote:
> I'm trying (unsuccessfully)  to compile 2.0.7 with perl-5.16 and
> httpd-2.2.22. The error is below. I have a perl compiled with fPIC. I put
> fPIC into LDFLAGS when compiling mod_perl.
> Anyway to make this work?

Are you sure it is compiled with -fPIC? Can you post 'perl -V'?


>
>
> /usr/bin/ld: /opt/perl/lib/5.16.0/x86_64-linux/CORE/libperl.a(op.o):
> relocation R_X86_64_32S against `PL_sv_yes' can not be used when making a
> shared object; recompile with -fPIC
> /opt/perl/lib/5.16.0/x86_64-linux/CORE/libperl.a: could not read symbols:
> Bad value
>
> --
> Jiří Pavlovský
>

Re: Mod_perl with Apache 2.4 and Perl 5.16

[Fred Moyer]

mp 2.0.7 has 5.16 compatibility and was released June 5th.

The 2.4 work is still underway. Check the threads on the dev list for
the status.

On Sun, Jul 22, 2012 at 6:20 PM, Bruce Pettyjohn
 wrote:
>
> Hello,
>
> Is there a projected release date for mod_perl that works with the latest 
> Apache and Perl.
>
> Specifically, Perl 5.16 and Apache 2.4.2.
>
> Thanks,
>
> Bruce
>

Re: Mod_perl with Apache 2.4 and Perl 5.16

[Fred Moyer]

mp 2.0.7 has 5.16 compatibility and was released June 5th.

The 2.4 work is still underway.

On Sun, Jul 22, 2012 at 6:20 PM, Bruce Pettyjohn
 wrote:
>
> Hello,
>
> Is there a projected release date for mod_perl that works with the latest 
> Apache and Perl.
>
> Specifically, Perl 5.16 and Apache 2.4.2.
>
> Thanks,
>
> Bruce
>

Re: [MP2] Nullav undeclared make error

[Fred Moyer]

On Tue, Jul 17, 2012 at 2:02 AM, Steve Hay  wrote:
>
> I've now eliminated our uses of deprecated core perl symbols in commits 
> 1362399, 1362409 and 1362414, although we'll need to update Apache-Test in 
> mod_perl to get the commit which touched that.

What update needs to happen to Apache-Test? If you want to make the
needed commit I can start the release process.

> This gets mod_perl building again with a perl that doesn't have large files 
> support.
>
> I still think we should also remove our usage of PERL_CORE, though...

Does this affect the minimum version of Perl we can support? I
remember from the last mp2 release that there was a file with
httpd/perl dependencies in it that I had to update.


>
>
>
> From: Steve Hay [mailto:steve.m....@googlemail.com]
> Sent: 13 July 2012 08:23
> To: Fred Moyer
> Cc: d...@rentrak.com; modperl@perl.apache.org; mod_perl Dev
> Subject: Re: [MP2] Nullav undeclared make error
>
> Various perl changes removed Nullsv, Nullav etc from the core (e.g. see 
> 24792b8dab and 3ae1b22641), but left definitions of them for when PERL_CORE 
> is not defined, for backwards compatibility with all those CPAN modules out 
> there which use them.
>
> The problem here is what Nick hinted at in his comment for 24792b8dab, namely 
> that "obviously" nobody outside of the perl core is defining PERL_CORE... 
> It's a rather too common and surely always wrong thing to do that, and we're 
> guilty of it ourselves: modperl_perl_includes.h defines PERL_CORE as some 
> kind of optimization, but only when USE_ITHREADS is defined and 
> USE_LARGE_FILES is not. That's not a common configuration, hence we haven't 
> seen this happen before, but the last line which I've quoted below does 
> indeed undefine large file support, hence PERL_CORE gets defined and the 
> definitions of Nullsv, Nullav etc are not provided.
>
> I replaced all uses of Nullxx with (XX*)NULL in my modules some time ago in 
> the belief that if it was good for the core then it was good for me, so I 
> will do likewise for mod_perl unless anyone objects (or beats me to it).
>

Re: Build error, requiring threads when threads are not built in

[Fred Moyer]

Apache 2.4 support hasn't been added yet, so I'm guessing that may
have contributed to this build failure. You may want to try with just
the MP_APXS build arguments though.

On Thu, Jul 12, 2012 at 2:46 PM, Susan  wrote:
> I keep getting this error trying to build the dso mod_perl2 with apache2.
> Httpd was built with mpm-prefork, perl was not compiled with threads. below
> are configure options.
>
> this is the build error with the configure options:
>
> root [ ~/.cpan/build/mod_perl-2.0.7-gdtpWS ]# perl Makefile.PL
> MP_APXS=/usr/bin/apxs MP_APR_CONFIG=/usr/bin/apr-1-config \
>> MP_USE_DSO=1 MP_AP_CONFIGURE="--with-mpm=prefork"
> Reading Makefile.PL args from @ARGV
>MP_APXS = /usr/bin/apxs
>MP_APR_CONFIG = /usr/bin/apr-1-config
>MP_USE_DSO = 1
>MP_AP_CONFIGURE = --with-mpm=prefork
> no conflicting prior mod_perl version found - good.
> Configuring Apache/2.4.2 mod_perl/2.0.7 Perl/v5.14.2
> [  error] Using Perl 5.014002 w/o ithreads and 'dynamic' mpm httpd.
> [  error] Failed requirements:
> [  error]   - Perl built with ithreads (build perl with -Dusethreads)
>
>
> 
>
> this is config info from apache and perl:
>
> root [ ~/.cpan/build/mod_perl-2.0.7-gdtsWQ ]# httpd -V
> Server version: Apache/2.4.2 (Unix)
> Server loaded:  APR 1.4.6, APR-UTIL 1.4.1
> Compiled using: APR 1.4.6, APR-UTIL 1.4.1
> Architecture:   32-bit
> Server MPM: prefork
>   threaded: no
> forked: yes (variable process count)
>
>
>
> root [ ~/.cpan/build/mod_perl-2.0.7-gdtsWQ ]# perl -V
> Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
>
>   Platform:
> osname=linux, osvers=3.2.15, archname=i686-linux
> uname='linux c5 3.2.15 #0 smp sat apr 28 12:52:13 edt 2012 i686 gnulinux
> '
> config_args='-des  -isR -Duseshrplib'
> hint=recommended, useposix=true, d_sigaction=define
> useithreads=undef, usemultiplicity=undef
> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> use64bitint=undef, use64bitall=undef, uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
>
>
>
> ---
>
> any help would be appreciated. I do not want threads compiled into perl.
>
> Susan
>
> Message 1 of 90
>

Re: [MP2] Nullav undeclared make error

[Fred Moyer]

> mod_perl.c:265: error: ‘Nullav’ undeclared (first use in this function)

Hmm, found this in
http://search.cpan.org/~rjbs/perl-5.16.0/pod/perl5101delta.pod

Uses of Nullav, Nullcv, Nullhv, Nullop, Nullsv etc have been replaced
by NULL in the core code, and non-dual-life modules, as NULL is
clearer to those unfamiliar with the core code.

Maybe we need to replace these instances? Torsten/Gozer/SteveHay?? I'm
not sure if those are backwards compatible with 5.14 at first glace.

On Fri, Jun 22, 2012 at 12:50 PM, David Shultz  wrote:
> Apache2 src: 2.2.22
> mod_per src: 2.0.7
> Installed Perl 5.16.0 hand built as:
> CFLAGS='-m64 -mtune=nocona' ./Configure -A ccflags=-fPIC \
> -Dprefix=/usr/local/stow/perl-5.16.0 -Dusethreads \
> -Accflags=-DPERL_REENTRANT_MAXSIZE=65536 \
> -Uuselargefiles -Dusemorebits
>
>> perl Makefile.PL MP_USE_STATIC=1 \
> MP_AP_PREFIX=/home/dxs/code/httpd-2.2.22 \
> MP_AP_CONFIGURE="--with-mpm=prefork"
>
> works fine
>
>> make
>
> produces the following error:
>
> cd "src/modules/perl" && make
> make[1]: Entering directory `/home/dxs/code/mod_perl-2.0.7/src/modules/perl'
> cc -I/home/dxs/code/mod_perl-2.0.7/src/modules/perl
> -I/home/dxs/code/mod_perl-2.0.7/xs
> -I/home/dxs/code/mod_perl-2.0.7/../httpd-2.2.22/include
> -I/home/dxs/code/mod_perl-2.0.7/../httpd-2.2.22/srclib/apr/include
> -I/home/dxs/code/mod_perl-2.0.7/../httpd-2.2.22/srclib/apr-util/include
> -I/home/dxs/code/mod_perl-2.0.7/../httpd-2.2.22/os/unix -D_REENTRANT
> -D_GNU_SOURCE -fPIC -DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing
> -pipe -fstack-protector -I/usr/local/include -fPIC
> -DPERL_REENTRANT_MAXSIZE=65536
> -I/usr/local/stow/perl-5.16.0/lib/5.16.0/x86_64-linux-thread-multi-ld/CORE
> -DMOD_PERL -DMP_COMPAT_1X -O2 -c mod_perl.c
> mod_perl.c: In function ‘modperl_startup’:
> mod_perl.c:265: error: ‘Nullav’ undeclared (first use in this function)
> mod_perl.c:265: error: (Each undeclared identifier is reported only once
> mod_perl.c:265: error: for each function it appears in.)
> make[1]: *** [mod_perl.o] Error 1
> make[1]: Leaving directory `/home/dxs/code/mod_perl-2.0.7/src/modules/perl'
> make: *** [modperl_lib] Error 2
>
>
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
>   [DESCRIBE THE PROBLEM HERE]
>
> 2. Used Components and their Configuration:
>
> *** mod_perl version 2.07
>
> *** using /home/dxs/code/mod_perl-2.0.7/lib/Apache2/BuildConfig.pm
>
> *** Makefile.PL options:
>   MP_APR_LIB  => aprext
>   MP_AP_CONFIGURE => --with-mpm=prefork
>   MP_AP_PREFIX=> /home/dxs/code/httpd-2.2.22
>   MP_COMPAT_1X=> 1
>   MP_GENERATE_XS  => 1
>   MP_LIBNAME  => mod_perl
>   MP_USE_STATIC   => 1
>
>
> *** The httpd binary was not found
>
>
> *** (apr|apu)-config linking info
>
> -L/home/dxs/code/httpd-2.2.22/srclib/apr-util/.libs
>  -L/home/dxs/code/httpd-2.2.22/srclib/apr-util -laprutil-1
> /home/dxs/code/httpd-2.2.22/srclib/apr-util/xml/expat/libexpat.la
> -L/home/dxs/code/httpd-2.2.22/srclib/apr/.libs
>  -L/home/dxs/code/httpd-2.2.22/srclib/apr -lapr-1 -luuid -lrt -lcrypt
> -lpthread -ldl
>
>
>
> *** /usr/local/stow/perl-5.16.0/bin/perl -V
> Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
>
>   Platform:
> osname=linux, osvers=2.6.18-308.8.2.el5,
> archname=x86_64-linux-thread-multi-ld
> uname='linux *** 2.6.18-308.8.2.el5 #1 smp tue jun
> 12 09:58:12 edt 2012 x86_64 x86_64 x86_64 gnulinux '
> config_args='-A ccflags=-fPIC -Dprefix=/usr/local/stow/perl-5.16.0
> -Dusethreads -Accflags=-DPERL_REENTRANT_MAXSIZE=65536 -Uuselargefiles
> -Dusemorebits'
> hint=previous, useposix=true, d_sigaction=define
> useithreads=define, usemultiplicity=define
> useperlio=define, d_sfio=undef, uselargefiles=undef, usesocks=undef
> use64bitint=define, use64bitall=define, uselongdouble=define
> usemymalloc=n, bincompat5005=undef
>   Compiler:
> cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC
> -DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -fPIC -DPERL_REENTRANT_MAXSIZE=65536',
> optimize='-O2',
> cppflags='-D_REENTRANT -D_GNU_SOURCE -fPIC
> -DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_REENTRANT -D_GNU_SOURCE -fPIC
> -DPERL_REENTRANT_MAXSIZE=65536 -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -fPIC -DPERL_REENTRANT_MAXSIZE=65536'
> ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-52)',
> gccosandvers=''
> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t',
> lseeksize=8
> alignbytes=16, prototype=define
>   Linker and Libraries:
> ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
> libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
>

Re: [mp2] Install error with Makefile.PL - uninitialized value at TestRun.pm

[Fred Moyer]

st
> Writing Makefile for ModPerl
> Writing Makefile for ModPerl::XS
> Writing Makefile for mod_perl2
> [warning] mod_perl dso library will be built as mod_perl.so
> [warning] You'll need to add the following to httpd.conf:
> [warning]
> [warning]   LoadModule perl_module modules/mod_perl.so
> [warning]
> [warning] depending on your build, mod_perl might not live in
> [warning] the modules/ directory.
>
> [warning] Check the results of
> [warning]
> [warning]   $ /opt/hpws22/apache/bin/apxs -q LIBEXECDIR
> [warning]
> [warning] and adjust the LoadModule directive accordingly
>
> % make
> cd "src/modules/perl" && make
> cc -I/opt/mod_perl-2.0.7/src/modules/perl -I/opt/mod_perl-2.0.7/xs 
> -I/op
> t/hpws22/apache/include -I/opt/hpws22/apache/include 
> -I/opt/iexpress/openldap/in
> clude  -I/opt/hpws22/apache/include -D_POSIX_C_SOURCE=199506L -D_REENTRANT 
> -Ae -
> D_HPUX_SOURCE -Wl,+vnocompatwarnings +DSitanium2 +Z -DUSE_SITECUSTOMIZE 
> -DNO_HAS
> H_SEED -I/opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/CORE -DMOD_PERL 
> -DMP
> _COMPAT_1X -DHPUX11 -D_HPUX_SOURCE -fast +Ofltacc=strict +Z \
> -c modperl_config.c && mv modperl_config.o modperl_config.lo
> "modperl_config.c", line 525: error #2020: identifier "OPT_INCNOEXEC" is
>   undefined
>   parms.override_opts = MP_HTTPD_OVERRIDE_OPTS_DEFAULT;
> ^
>
> "modperl_config.c", line 644: warning #2068-D: integer conversion resulted in
>   a change of sign
>   if ((flag = modperl_flags_lookup_dir(name)) != -1) {
>  ^
>
> "modperl_config.c", line 653: warning #2068-D: integer conversion resulted in
>   a change of sign
>   if ((flag = modperl_flags_lookup_srv(name)) != -1) {
>  ^
>
> "modperl_config.c", line 662: warning #2940-D: missing return statement at end
>   of non-void function "modperl_config_is_perl_option_enabled"
>   }
>   ^
>
> 1 error detected in the compilation of "modperl_config.c".
> *** Error exit code 2
>
> Stop.
> *** Error exit code 1
>
>
>
>
> -Todd
>
> Todd Froyland
>
>
> -Original Message-
> From: Fred Moyer [mailto:f...@redhotpenguin.com]
> Sent: Tuesday, July 10, 2012 4:27 PM
> To: Froyland, Todd
> Subject: Re: [mp2] Install error with Makefile.PL - uninitialized value at 
> TestRun.pm
>
> Can you try this?
>
> perl Makefile.PL MP_APXS=/opt/hpws22/apache/bin/apxs
>
>
> On Tue, Jul 10, 2012 at 4:18 PM, Froyland, Todd
>  wrote:
>> Fred,
>>
>> Thanks for the quick response! Here is the results of your test:
>>
>>
>>
>>
>> % perl Makefile.PL MP_AP_PREFIX=/opt/hpws22/apache
>> Reading Makefile.PL args from @ARGV
>>MP_AP_PREFIX = /opt/hpws22/apache
>> no conflicting prior mod_perl version found - good.
>> Configuring Apache/2.2.*/ mod_perl/2.0.7 Perl/v5.8.8
>> Checking if your kit is complete...
>> Looks good
>> ERROR from evaluation of /opt/mod_perl-2.0.7/Apache-Reload/Makefile.PL: key 
>> apxs
>>  has no value at Apache-Test/lib/Apache/TestRun.pm line 1101.
>>
>>
>>
>> I seem to have apxs on my machine:
>>
>> % which apxs
>> /opt/hpws22/apache/bin/apxs
>>
>> Although, I noticed on the bug report that it says that the httpd binary was 
>> not found, even though it is on my path. Is the script using some other 
>> configuration for that?
>>
>> -Todd
>>
>>
>>
>> -Original Message-
>> From: Fred Moyer [mailto:f...@redhotpenguin.com]
>> Sent: Tuesday, July 10, 2012 4:06 PM
>> To: Froyland, Todd
>> Cc: modperl@perl.apache.org
>> Subject: Re: [mp2] Install error with Makefile.PL - uninitialized value at 
>> TestRun.pm
>>
>> Can you try this patch in Apache-Test and report back the output?
>> Looks like the eval fails because of fatal warnings from the undef
>> value.
>>
>> Index: lib/Apache/TestRun.pm
>> ===
>> --- lib/Apache/TestRun.pm   (revision 1359945)
>> +++ lib/Apache/TestRun.pm   (working copy)
>> @@ -1097,6 +1097,9 @@
>>
>>  my %args = @Apache::TestMM::Argv;
>>  while (my($k, $v) = each %args) {
>> +unless (defined $v) {
>> +die "key $k has no value";
>> +}
>>  $v =~ s/\|/\\|/g;
>>  $body .= &q

Re: [mp2] Install error with Makefile.PL - uninitialized value at TestRun.pm

[Fred Moyer]

Can you try this patch in Apache-Test and report back the output?
Looks like the eval fails because of fatal warnings from the undef
value.

Index: lib/Apache/TestRun.pm
===
--- lib/Apache/TestRun.pm   (revision 1359945)
+++ lib/Apache/TestRun.pm   (working copy)
@@ -1097,6 +1097,9 @@

 my %args = @Apache::TestMM::Argv;
 while (my($k, $v) = each %args) {
+unless (defined $v) {
+die "key $k has no value";
+}
 $v =~ s/\|/\\|/g;
 $body .= "\n\$Apache::TestConfig::Argv{'$k'} = q|$v|;\n";
 }


On Tue, Jul 10, 2012 at 3:52 PM, Froyland, Todd
 wrote:
> 1. Problem Description:
>
>   Installing mod_perl2, latest version(2.0.7), on hp-ux machine(B.11.31).
>   The "perl Makefile.PL" command returns the following error:
>
> % perl Makefile.PL MP_AP_PREFIX=/opt/hpws22/apache
> Reading Makefile.PL args from @ARGV
>MP_AP_PREFIX = /opt/hpws22/apache
> no conflicting prior mod_perl version found - good.
> Configuring Apache/2.2.*/ mod_perl/2.0.7 Perl/v5.8.8
> Checking if your kit is complete...
> Looks good
> ERROR from evaluation of /opt/mod_perl-2.0.7/Apache-Reload/Makefile.PL: 
> Use of
> uninitialized value in substitution (s///) at 
> Apache-Test/lib/Apache/TestRun.pm
> line 1100.
>
>   A few other details:
>
> % httpd -v
> Server version: Apache/2.2.8  HP-UX_Apache-based_Web_Server (Unix)
> Server built:   May  7 2010 12:11:23
>
> % perl -v
> This is perl, v5.8.8 built for IA64.ARCHREV_0-thread-multi
>
> There is no apr-config or apu-config on my machine, but there is an
> apr-1-config and apu-1-config, so I created symlinks to both of those.
>
> There is a previously existing mod_perl installation (1.99), but it
> is in an obscure directory that is not in @INC.
>
>   I have searched the mail archives and internets for anything related to
>   this problem, but could not find anything useful. I am neither a Perl
>   nor sysadmin guru, and I don't understand enough of what the TestRun.pm
>   program is doing to figure out what might be wrong.
>   Any suggestions would be helpful.
>
>   Thanks!
>
> 2. Used Components and their Configuration:
>
> *** mod_perl version 2.07
>
> *** using /opt/mod_perl-2.0.7/lib/Apache2/BuildConfig.pm
>
> *** Makefile.PL options:
>   MP_APR_LIB => aprext
>   MP_AP_PREFIX   => /opt/hpws22/apache
>   MP_COMPAT_1X   => 1
>   MP_GENERATE_XS => 1
>   MP_LIBNAME => mod_perl
>   MP_USE_DSO => 1
>
>
> *** The httpd binary was not found
>
>
> *** (apr|apu)-config linking info
>
>  -L/opt/hpws22/apache/lib -laprutil-1 -lldap  -lexpat -L/opt/hpws22/apache/lib
>  -L/opt/hpws22/apache/lib -lapr-1 -lrt -lm -lgss -L/opt/hpws22/apache/lib 
> -uldap
> _compare_s -uldap_simple_bind_s -uldap_err2string -l:liblber-2.4.so 
> -l:libldap-2
> .4.so -l:libsasl2.a -L/opt/openssl/0.9.8/lib/hpux64 -l:libssl.so 
> -l:libcrypto.so
>  -L/user/apinteg/BerkelyDBIA64/lib -ldb -Wl,+b,/opt/hpws22/apache/lib 
> -lpthread
>
>
> ***  -V
>
> *** Packages of interest status:
>
> Apache2: -
> Apache2::Request   : -
> CGI: 3.59
> ExtUtils::MakeMaker: 6.30
> LWP: 6.04
> mod_perl   : -
> mod_perl2  : -
>
>
> 3. This is the core dump trace: (if you get a core dump):
>
>   [CORE TRACE COMES HERE]
>
> This report was generated by t/REPORT on Tue Jul 10 22:36:48 2012 GMT.

Re: [mp2] Configure fails w/Perl 5.16.0

[Fred Moyer]

There is a patch under development on the dev list
(d...@perl.apache.org) for httpd 2.4 compatibility. mod_perl 2.0.7 was
released yesterday, which includes the Perl 5.16 compatibility.

On Mon, Jun 4, 2012 at 11:01 AM, Bruce Pettyjohn
 wrote:
> Thanks for any help in resolving this bug.  I have been using mod_perl for
> years and been happy.  I would like to take advantage of the new Apache and
> need mod_perl to be part of it.
>
>
>
> Cheers,
>
>
>
> Bruce Pettyjohn
>
>
>
>
>
> -8<-- Start Bug Report 8<--
>
> 1. Problem Description:
>
>
>
>
>
> I am trying to configure with Apache 2.4.2, mp 2.0.6 and Perl 5.16.0 with no
> luck.
>
>
>
> Perl was compiled with and without threads.
>
>
>
> $ ./Configure -des -Dusethreads
>
> $ ./Configure -des -Uusethreads
>
>
>
> Apache 2.4.2 was compiled with
>
>
>
> $ ./configure --prefix=/usr/local/apache2/httpd/prefork \
>
> --with-mpm=prefork \
>
> --enable-mods-shared=all \
>
> --with-included-apr \
>
> --with-perl=/usr/local/perl \
>
> --enable-ssl --enable-so
>
>
>
> The latest patch for modperl_perl.c was applied and the make process stops
> prematurely with this error note.
>
>
>
>
>
> root@dev2 downloads]# cd mod_perl-2.0.6
>
> [root@dev2 mod_perl-2.0.6]# perl Makefile.PL
> MP_APXS=/usr/local/apache2/httpd/prefork/bin/apxs
> MP_APR_CONFIG=/usr/local/apr/bin/apu-1-config
>
> Reading Makefile.PL args from @ARGV
>
>    MP_APXS = /usr/local/apache2/httpd/prefork/bin/apxs
>
>    MP_APR_CONFIG = /usr/local/apr/bin/apu-1-config
>
> no conflicting prior mod_perl version found - good.
>
> Configuring Apache/2.4.2 mod_perl/2.0.7 Perl/v5.16.0
>
> [  error] Using Perl 5.016000 w/o ithreads and 'dynamic' mpm httpd.
>
> [  error] Failed requirements:
>
> [  error]   - Perl built with ithreads (build perl with -Dusethreads)
>
>
>
> The error_log file (t/logs/error_log) is non-existent.  The “logs” directory
> is missing in this distribution.  After adding the “logs” directory the
> “error_log” file was not created.
>
>
>
>
>
>
>
>
>
> 2. Used Components and their Configuration:
>
>
>
> *** mod_perl version 2.06
>
>
>
> *** using /var/downloads/mod_perl-2.0.6/lib/Apache2/BuildConfig.pm
>
>
>
> *** Makefile.PL options:
>
>   MP_APR_CONFIG  => /usr/local/apr/bin/apu-1-config
>
>   MP_APR_LIB => aprext
>
>   MP_APXS    => /usr/local/apache2/httpd/prefork/bin/apxs
>
>   MP_COMPAT_1X   => 1
>
>   MP_GENERATE_XS => 1
>
>   MP_LIBNAME => mod_perl
>
>   MP_USE_DSO => 1
>
>
>
>
>
> *** The httpd binary was not found
>
>
>
>
>
> *** (apr|apu)-config linking info
>
>
>
>  -L/usr/local/apr/lib -laprutil-1 -lexpat
>
>
>
>
>
>
>
> ***  -V
>
>
>
> *** Packages of interest status:
>
>
>
> Apache2    : -
>
> Apache2::Request   : -
>
> CGI    : 3.59
>
> ExtUtils::MakeMaker: 6.63_02
>
> LWP    : 5.834, 6.04, 6.04
>
> mod_perl   : -
>
> mod_perl2  : -
>
>
>
>
>
> 3. This is the core dump trace: (if you get a core dump):
>
>
>
>   [CORE TRACE COMES HERE]
>
>
>
> None
>
>
>
>
>
> This report was generated by t/REPORT on Mon Jun  4 17:35:24 2012 GMT.
>
>
>
> -8<-- End Bug Report --8<--
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[ANNOUNCE] mod_perl 2.0.7

[Fred Moyer]

I'm pleased to announce the release of mod_perl 2.0.7, available at
the following apache.org URL, along with a CPAN mirror near you
shortly, as well as http://perl.apache.org.

This release of mod_perl contains an update for perl 5.16, see the
change log below. Thanks to the code contributor and mod_perl dev team
members who made this quick release possible!

http://apache.org/dist/perl/mod_perl-2.0.7.tar.gz
http://apache.org/dist/perl/mod_perl-2.0.7.tar.gz.asc (pgp sig)

MD5 (mod_perl-2.0.7.tar.gz) = e8b3d7b6d67505a8e3050cb9042b944b


=item 2.0.7 June 5, 2012

Fix breakage caused by removal of PL_uid et al from perl 5.16.0. Patch from
rt.cpan.org #77129. [Zefram]

Re: Trouble with Makefile.PL

[Fred Moyer]

You might want to give 2.0.6 a go, which was released a few weeks ago.
However, you'll need Apache 2.2.x, as 2.4 compatibility isn't working
yet.

On Mon, May 14, 2012 at 2:18 PM, Furst, Carl  wrote:
> Hello all,
>
> I'm having a lot of trouble trying to statically build mod_perl and apache
> on Solaris 10 Sparc. I get the following error when I try and build
> statically:
>
> Configuring Apache/2.4.2 mod_perl/2.0.5 Perl/v5.12.3
> [  error] Failed to obtain the MPM name. Please specify
> MP_APXS=/full/path/to/apxs to solve this problem.
>
>
> Here is the command I am using:
>
> CC=`which gcc` CPP="`which gcc` -E" perl Makefile.PL
> MP_AP_PREFIX=$HOME/httpd-2.4.2 MP_USE_STATIC=1 MP_AP_CONFIGURE=" \
> --prefix=/cms/usr/local/www \
> --with-ssl=/opt/mlb \
> --enable-static-support \
> --enable-mods-shared='most' --with-mpm=prefork \
> --enable-mods-static='perl ssl so prefork cgi' \
>
> `which gcc` yields: /usr/local/bin/gcc
> It's version :
> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
> Configured with: ../configure --with-as=/usr/ccs/bin/as
> --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
> Thread model: posix
> gcc version 3.4.6
>
> Perl –V compiler section:
> Compiler:
>     cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing -pipe
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
>     optimize='-O',
>     cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
>     ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10'
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
>     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
>     alignbytes=8, prototype=define
>
>
> Any ideas? I don't have apache currently installed and the docs said I
> didn't need it. However this would indicate that I would.
>
> Many thanks in advance.
>
> Carl Furst
>
>
>
>
>
>
> **
>
> MLB.com: Where Baseball is Always On

Re: Can't build mod_perl-2.0.5 for Apache -2.4.2 under FreeBSD 9.0

[Fred Moyer]

On Tue, May 1, 2012 at 12:31 PM, Bernard Higonnet  wrote:
> I have built Apache -2.4.2 "It works!" and am trying to add mod_perl-2.0.5

You might want to try 2.0.6 which was released last week.

http://perl.apache.org/download/index.html

I don't think it builds with 2.4 yet though.

> but I get this
>
> perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs
> Reading Makefile.PL args from @ARGV
>   MP_APXS = /usr/local/apache2/bin/apxs
> no conflicting prior mod_perl version found - good.
> Configuring Apache/2.4.2 mod_perl/2.0.5 Perl/v5.12.4
> [  error] '/usr/local/apache2/bin/apxs -q MPM_NAME' failed:
> [  error] apxs:Error: Invalid query string `MPM_NAME'.
> [  error] Failed to obtain the MPM name.
>
>
>
> I reinstalled Apache adding --with-mpm=prefork just in case but got same
> result?
>
> TIA
> Bernard Higonnet

Re: mod_perl and RedHat 6

[Fred Moyer]

> t/api/server_const.t                  (Wstat: 0 Tests: 6 Failed: 2)

> I'm not sure how serious this failure is and whether I should consider

The RedHat Apache uses a custom server signature so there is a bit of
a mismatch on that test. Nothing to worry about, you can install and
it will work fine.


On Tue, May 1, 2012 at 6:34 AM, Dan Axtell  wrote:
> I'm trying to migrate a server to a new machine running 64-bit RedHat 6.  The
> stock RedHat setup is apache 2.2.15, php 5.3.3 and perl 5.10.1.  Normally I
> build the latest Apache 2.2 and Perl/mod_perl in /usr/local and just use that.
> However, this server will also use Drupal so I figured I'd build PHP locally
> as well.
>
> I'm unable to get PHP 5.3 or 5.4 to link properly with the installed mysql,
> pcre and gd libraries (all of which are installed along with the devel
> packages), so I was thinking of just using the stock Apache and PHP and trying
> to build a newer mod_perl with the /usr/local/bin/perl which is 5.14.2.  So I
> tried
> /usr/local/bin/perl Makefile.PL MP_APXS=/usr/sbin/apxs
>
> This compiles, but make test gives me this:
>
> Test Summary Report
> ---
> t/api/server_const.t                  (Wstat: 0 Tests: 6 Failed: 2)
>  Failed tests:  5-6
> Files=242, Tests=2614, 122 wallclock secs ( 1.30 usr  0.41 sys + 91.90 cusr
> 10.94 csys = 104.55 CPU)
> Result: FAIL
> Failed 1/242 test programs. 2/2614 subtests failed.
>
> I'm not sure how serious this failure is and whether I should consider
> installing the resulting mod_perl.so file instead of the stock one.  I can
> always just use the stock Perl/mod_perl but I'd really prefer a newer Perl.
>
> Alternatively, I suppose I can try and set up a reverse proxy to run the
> Drupal stuff on the stock Apache and mod_perl stuff on the custom
> Apache/mod_perl, but I expect I'll run into complications there with various
> virtual hosts and such.
>
> Any suggestions?
>
> Thanks,
> Dan

Re: [ANNOUNCE] mod_perl 2.0.6

[Fred Moyer]

On Thu, Apr 26, 2012 at 7:41 AM, John D Groenveld
 wrote:
> In message 
> 
> , Fred Moyer writes:
>>I'm pleased to announce the release of mod_perl 2.0.6, available at
>>the following apache.org URL, along with a CPAN mirror near you.
>
> Still core dumping with 64-bit perl 5.14.2 but works beautifully with
> 5.12.4 on Solaris.

Thanks for the stacktrace. I think 2.0.7 will follow suit shortly,
there's an apache 2.4 patch in the works, and if we can resolve this
it will probably get in that release as well.

>
> John
> groenv...@acm.org
>
> $ pstack /tmp/mod_perl-2.0.6/core
> core '/tmp/mod_perl-2.0.6/core' of 11620:       /opt/apache2/bin/httpd -d 
> /tmp/mod_perl-2.0.6/t -f /tmp/mod_perl-2.0.6
>  dd7ffe810851 Perl_sv_vcatpvfn () + 2271
>  dd7ffe80c4c6 Perl_vnewSVpvf () + c6
>  dd7ffe80c3ef Perl_newSVpvf () + 8f
>  dd7ffe80813a S_anonymise_cv_maybe () + ba
>  dd7ffe8077b7 Perl_sv_kill_backrefs () + 97
>  dd7ffe7dfd2d Perl_magic_killbackrefs () + d
>  dd7ffe807338 S_sv_unmagicext_flags () + 128
>  dd7ffe80838a Perl_sv_clear () + 1ca
>  dd7ffe808ec6 Perl_sv_free2 () + 56
>  dd7ffe7ffa58 S_visit () + d8
>  dd7ffe775c5e perl_destruct () + a2e
>  dd7ffe926d69 modperl_perl_destruct () + 59
>  dd7ffe918a0b modperl_shutdown () + 1b
>  dd7fffbc8a54 run_cleanups () + 24
>  dd7fffbc7db0 apr_pool_destroy () + 40
>  dd7fffbc7cf8 apr_pool_clear () + 28
>  0043300b main () + 6eb
>  00431f4b  ()
>
> $ env 
> PATH=/opt/apache2/perl-5.14.2/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/solarisstudio12.3/bin
>  perl -Iblib/arch -Iblib/lib build/config.pl
> *** mod_perl version 2.06
>
> *** using /tmp/mod_perl-2.0.6/lib/Apache2/BuildConfig.pm
>
> *** Makefile.PL options:
>  MP_APR_LIB     => aprext
>  MP_APXS        => /opt/apache2/bin/apxs
>  MP_COMPAT_1X   => 1
>  MP_GENERATE_XS => 1
>  MP_LIBNAME     => mod_perl
>  MP_USE_DSO     => 1
>
>
> *** /opt/apache2/bin/httpd -V
> Server version: Apache/2.2.22 (Unix)
> Server built:   Apr 25 2012 22:05:08
> Server's Module Magic Number: 20051115:30
> Server loaded:  APR 1.4.5, APR-Util 1.4.1
> Compiled using: APR 1.4.5, APR-Util 1.4.1
> Architecture:   64-bit
> Server MPM:     Prefork
>  threaded:     no
>    forked:     yes (variable process count)
> Server compiled with
>  -D APACHE_MPM_DIR="server/mpm/prefork"
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_PROC_PTHREAD_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  -D APR_HAS_OTHER_CHILD
>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>  -D DYNAMIC_MODULE_LIMIT=128
>  -D HTTPD_ROOT="/opt/apache2"
>  -D SUEXEC_BIN="/opt/apache2/bin/suexec"
>  -D DEFAULT_PIDLOG="logs/httpd.pid"
>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>  -D DEFAULT_LOCKFILE="logs/accept.lock"
>  -D DEFAULT_ERRORLOG="logs/error_log"
>  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
>  -D SERVER_CONFIG_FILE="conf/httpd.conf"
>
> *** /bin/ldd /opt/apache2/bin/httpd
>        libm.so.2 =>     /lib/64/libm.so.2
>        libaprutil-1.so.0 =>     /opt/apache2/lib/libaprutil-1.so.0
>        libexpat.so.1 =>         /usr/lib/64/libexpat.so.1
>        libapr-1.so.0 =>         /opt/apache2/lib/libapr-1.so.0
>        libuuid.so.1 =>  /lib/64/libuuid.so.1
>        libsendfile.so.1 =>      /lib/64/libsendfile.so.1
>        libsocket.so.1 =>        /lib/64/libsocket.so.1
>        libnsl.so.1 =>   /lib/64/libnsl.so.1
>        libpthread.so.1 =>       /lib/64/libpthread.so.1
>        libc.so.1 =>     /lib/64/libc.so.1
>        libdlpi.so.1 =>  /lib/64/libdlpi.so.1
>        libmp.so.2 =>    /lib/64/libmp.so.2
>        libmd.so.1 =>    /lib/64/libmd.so.1
>        libinetutil.so.1 =>      /lib/64/libinetutil.so.1
>        libdladm.so.1 =>         /lib/64/libdladm.so.1
>        libdevinfo.so.1 =>       /lib/64/libdevinfo.so.1
>        libscf.so.1 =>   /lib/64/libscf.so.1
>        librcm.so.1 =>   /lib/64/librcm.so.1
>        libnvpair.so.1 =>        /lib/64/libnvpair.so.1
>        libexacct.so.1 =>        /usr/lib/64/libexacct.so.1
>        libkstat.so.1 =>         /lib/64/libkstat.so.1
>        libcurses.so.1 =>        /lib/64/libcurses.so.1
>        libpool.so.1 =>  /usr/lib/64/libpool.so.1
>        liblldp.so.1 =>  /usr/lib/64/liblldp.so.1
>        libsec.so.1 =>   /lib/64/libsec.so.1
>        libgen.so.1 =>   /lib/64/libgen.so.1
>        libsysevent.so.1 =>      /l

[ANNOUNCE] mod_perl 2.0.6

[Fred Moyer]

I'm pleased to announce the release of mod_perl 2.0.6, available at
the following apache.org URL, along with a CPAN mirror near you.

http://apache.org/dist/perl/mod_perl-2.0.6.tar.gz
http://apache.org/dist/perl/mod_perl-2.0.6.tar.gz.asc (pgp sig)

md5: 76f4154cffb15972246f03080e9d133c


Thanks to the many contributors to this release! Please see the full
changelog below.


=> Changes for mod_perl 2.0.6:

Preserve 5.8 compatibility surrounding use of MUTABLE_CV [Adam Prime]

Move code after declarations to keep MSVC++ compiler happy. [Steve Hay]

Adopt modperl_pcw.c changes from httpd24 branch. [Torsten Foertsch]

Pool cleanup functions must not longjmp. Catch these exceptions and turn
them into warnings. [Torsten Foertsch]

Fix a race condition in our tipool management.
See http://www.gossamer-threads.com/lists/modperl/dev/104026
Patch submitted by: SalusaSecondus 
Reviewed by: Torsten Foertsch

Ensure that MP_APXS is set when building on Win32 with MP_AP_PREFIX,
otherwise the bundled Reload and SizeLimit builds will fail to find a
properly configured Test environment.
[Steve Hay]

Fix a few REFCNT bugs.
Patch submitted by: Niko Tyni 
Reviewed by: Torsten Foertsch

Correct the initialization of the build config in ModPerl::MM. The global
variable was only being set once on loading the module, which was before
Apache2::BuildConfig.pm had been written, leading to cwd and MP_LIBNAME
being unset when writing the Reload and SizeLimit makefiles.
[Steve Hay]

Discover apr-2-config from Apache 2.4 onwards. [Gozer]

Apache 2.4 and onwards doesn't require linking the MPM module directly in
the httpd binary anymore. APXS lost the MPM_NAME query, so we can't assume
a given MPM anymore. Introduce a fake MPM 'dynamic' to represent this.
[Torsten Foertsch, Gozer]

Perl 5.14 brought a few changes in Perl_sv_dup() that made a threaded apache
segfault while cloning interpreters.
[Torsten Foertsch]

PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer throw
exceptions when modperl_wbucket_flush() fails if the failure was just a reset
connection or an aborted connection. The failure is simply logged to the error
log instead. This should fix cases of httpd.exe crashing when users press the
Stop button in their web browsers.
[Steve Hay]

Fixed a few issues that came up with LWP 6.00:
- t/response/TestAPI/request_rec.pm assumes HTTP/1.0 but LWP 6 uses 1.1
- t/api/err_headers_out.t fails due to a bug somewhere in LWP 6
- t/filter/TestFilter/out_str_reverse.pm sends the wrong content-length header
[Torsten Foertsch]

Bugfix: Apache2::ServerUtil::get_server{description,banner,version} cannot
be declared as perl constants or they won't reflect added version components
if Apache2::ServerUtil is loaded before the PostConfig phase. Now, they
are ordinary perl functions. [Torsten Foertsch]

Check for the right ExtUtils::Embed version during build [Torsten Foertsch]

Take a lesson from rt.cpan.org #66085 and pass LD_LIBRARY_PATH if mod_env
is present.  Should prevent test failures on some platforms.
[Fred Moyer]

Re: [mp2] Test fails with undefined symbols on AIX [mod_perl 2.0.5/apache-2.2.22/perl-5.14.2]

[Fred Moyer]

>  httpd: Syntax error on line 13 of .../t/conf/httpd.conf: Cannot load
> .../src/modules/perl/mod_perl.so into server: rtld: 0712-001 Symbol
> MUTABLE_CV was referenced\n      from module
> .../src/modules/perl/mod_perl.so(), but a runtime definition\n      of
> the symbol was not found.

We discovered this issue on the dev list also with 5.8.8, and are
rolling release candidate 6 shortly which should resolve this.


On Fri, Apr 20, 2012 at 12:27 AM, Peter Heimann  wrote:
> Here are a few more 'make test'results:
>
> Perl 5.8.8/Apache 2.2.22/mod_perl 2.0.4:
>  All t/apr-ext/* testcases successful
>
> Perl 5.8.8/Apache 2.2.22/mod_perl 2.0.6 rc5:
>  Test server fails to start:
>
>  Can't load '.../blib/arch/auto/ModPerl/Const/Const.so' for module
> ModPerl::Const: rtld: 0712-001 Symbol MUTABLE_CV was referenced
>      from module .../blib/arch/auto/ModPerl/Const/Const.so(), but a
> runtime definition
>      of the symbol was not found. at
> .../perl/lib/aix-thread-multi/DynaLoader.pm line 230.
>  ...
>  httpd: Syntax error on line 13 of .../t/conf/httpd.conf: Cannot load
> .../src/modules/perl/mod_perl.so into server: rtld: 0712-001 Symbol
> MUTABLE_CV was referenced\n      from module
> .../src/modules/perl/mod_perl.so(), but a runtime definition\n      of
> the symbol was not found.
>
>
> Perl 5.10.1/Apache 2.2.22/mod_perl 2.0.4:
>  t/apr-ext/brigade.t and other t/apr-ext/* tests fail:
>
>  Can't load '.../blib/arch/auto/APR/Brigade/Brigade.so' for module
> APR::Brigade: rtld: 0712-001 Symbol modperl_croak was referenced
>      from module .../blib/arch/auto/APR/Brigade/Brigade.so(), but a
> runtime definition
>      of the symbol was not found. at
> .../perl510/lib/5.10.1/aix-thread-multi/DynaLoader.pm line 200.
>  at .../blib/lib/APR/XSLoader.pm line 31
> Compilation failed in require at .../t/lib/TestAPRlib/brigade.pm line 15.
>
> Perl 5.10.1/Apache 2.2.22/mod_perl 2.0.6 rc5:
>  t/apr-ext/brigade.t and other t/apr-ext/* tests fail:
>
>  Can't load '.../blib/arch/auto/APR/Brigade/Brigade.so' for module
> APR::Brigade: rtld: 0712-001 Symbol modperl_croak was referenced
>      from module .../blib/arch/auto/APR/Brigade/Brigade.so(), but a
> runtime definition
>      of the symbol was not found. at
> .../perl510/lib/5.10.1/aix-thread-multi/DynaLoader.pm line 200.
>  at .../t/lib/TestAPRlib/brigade.pm line 15
> Compilation failed in require at .../t/lib/TestAPRlib/brigade.pm line 15.
>
> Perl 5.12.4/Apache 2.2.22/mod_perl 2.0.4:
> Perl 5.12.4/Apache 2.2.22/mod_perl 2.0.6 rc5:
>  Same test failures as with Perl 5.10.1
>
>
> All Perl versions have been configured with
>  ./Configure -d -Dcc=cc_r -Duseshrplib -Dusethreads -Dprefix=/some/path
>
> All mod_perl versions have been configured with
>  perl Makefile.PL MP_APXS=/usr/local/apache/bin/apxs
> (after changing the PATH definition to use the desired Perl version)
>
> --
> Peter Heimann

Re: highscalability.com report

[Fred Moyer]

On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron  wrote:
> Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
>> Well, finding (good) developers is certainly an issue.
>>
> Over the years, I have seen more than one of those being driven out of
> the field by the inane management that most developers toil under. And
> considering how demanding it is to be a good programmer, I can see why
> they give up : you just can't have both.
>
> On the other hand, I see scores of good developers in open source
> projects (their products certainly are very good)

I think the one of the main reasons this dichotomy exists is that in
open source, developers spend the bulk of their time programming. In
closed source work, developers start out doing a lot of programming,
but over time spend less time programming, and more time going to
meetings, writing status reports, and filling out HR paperwork,
killing processes on overloaded dev servers, etc. The best development
managers I've seen shield their programmers from those tasks and allow
them to get work done. There is no agile silver bullet to make
programmers more effective except giving them uninterrupted time to do
their jobs.

Re: Replacement for Apache::TaintRequest

[Fred Moyer]

It looks like you're trying to install Apache::TaintRequest against
mod_perl 2.2 (httpd 2.2.15).

Since you're using mod_perl2, you'll need Apache2::TaintRequest. I
just pushed 0.01 to CPAN, so it should be coming to a mirror near you
in the next 24-72 hours.

Warning - that code only passes compilation test and replaces
Apache::Util::escape_html with HTML::Entities::encode_entities.  It
was written when I had half an hour to spare today with Paris Roubaix
2011 and a nice Alaskan IPA, so some assembly may be required. Feel
free to file bugs against RT, but it also might 'just work'.

On Thu, Apr 5, 2012 at 2:05 PM, Bruce Johnson
 wrote:
> Based on this  I was trying to 
> install Apache::TaintRequest so as to sanitize requests, but when I tried to 
> install via CPAN I go the following error:
>
> " CPAN.pm: Going to build G/GO/GOZER/mod_perl-1.31.tar.gz
>
> * WARNING *
>
>  Your Perl is configured to link against libgdbm,
>  but libgdbm.so was not found.
>  You could just symlink it to /usr/lib64/libgdbm.so.2.0.0
>
>
> * WARNING *
> Enter `q' to stop search
> Please tell me where I can find your apache src
>  [../apache_x.x/src] /root/httpd-2.2.15
> Configure mod_perl with /root/httpd-2.2.15 ? [y]
> * WARNING *
>
>  Apache Version 1.3.0 required, aborting..."
>
> This is the latest version from CPANis there a more modern replacement 
> for this?
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>

Re: [mp2] Test fails with undefined symbols on AIX [mod_perl 2.0.5/apache-2.2.22/perl-5.14.2]

[Fred Moyer]

Do you have another set of APR libraries installed, perhaps with the packaging 
system that comes with AIX? It looks like mod_perl was built against a 
different set of APR libs than is being loaded at runtime. 

> Symbol modperl_hash_tied_object
> was referenced
> from module
> /home/user/tmp/mod_perl-2.0.6-rc2/blib/arch/auto/APR/Table/Table.so(),
> but a runtime definition
> of the symbol was not found.


RC3 is now available - see d...@perl.apache.org for the link.  


On Tuesday, April 3, 2012 at 2:06 PM, Peter Heimann wrote:

> 
> 1. Problem Description:
> 
> On AIX 5.3, with both mod_perl 2.0.5 and 2.0.6-rc2,
> "perl -e 'use Apache2::Request;'" fails because the loader cannot find
> runtime definitions for several symbols:
> "Symbol modperl_hash_tied_object was referenced from module
> /usr/local/perl/lib/site_perl/5.14.2/aix-thread-multi/auto/APR/Table/Table.so(),
> but a runtime definition of the symbol was not found."
> 
> The problem is shown by the t/apr-ext/brigade.t, t/apr-ext/finfo.t,
> t/apr-ext/pool.t, t/apr-ext/table.t, t/apr-ext/threadmutex.t,
> and t/apr-ext/uri.t test cases as well:
> 
> 
> cd "src/modules/perl" && make
> Target "all" is up to date.
> /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
> /home/user/tmp/mod_perl-2.0.6-rc2/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=1 apr-ext/brigade.t
> apr-ext/finfo.t apr-ext/pool.t apr-ext/table.t apr-ext/threadmutex.t
> apr-ext/uri.t
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/local/bin/perl
> /home/user/tmp/mod_perl-2.0.6-rc2/t/TEST -bugreport -verbose=1
> 'apr-ext/brigade.t' 'apr-ext/finfo.t' 'apr-ext/pool.t' 'apr-ext/table.t'
> 'apr-ext/threadmutex.t' 'apr-ext/uri.t'
> /usr/local/apache/bin/httpd -d /home/user/tmp/mod_perl-2.0.6-rc2/t -f
> /home/user/tmp/mod_perl-2.0.6-rc2/t/conf/httpd.conf -D APACHE2 -D
> PERL_USEITHREADS
> using Apache/2.2.22 (prefork MPM)
> 
> waiting 120 seconds for server to start: .[Tue Apr 03 13:09:10 2012]
> [info] 6 Apache2:: modules loaded
> [Tue Apr 03 13:09:10 2012] [info] 0 APR:: modules loaded
> [Tue Apr 03 13:09:10 2012] [info] base server + 29 vhosts ready to run tests
> ...
> waiting 120 seconds for server to start: ok (waited 3 secs)
> server localhost:8529 started
> server localhost:8530 listening (filter_out_apache)
> server localhost:8531 listening (perlsections)
> server localhost:8532 listening (inherit)
> server localhost:8533 listening (TestModperl::merge)
> server localhost:8534 listening (TestModperl::perl_options)
> server localhost:8535 listening (TestModperl::perl_options2)
> server localhost:8536 listening (TestModperl::setupenv)
> server localhost:8537 listening (TestModules::proxy)
> server localhost:8538 listening (TestUser::rewrite)
> server localhost:8539 listening (TestVhost::config)
> server localhost:8540 listening (TestVhost::log)
> server localhost:8541 listening (TestProtocol::echo_bbs)
> server localhost:8542 listening (TestProtocol::echo_bbs2)
> server localhost:8543 listening (TestProtocol::echo_block)
> server localhost:8544 listening (TestProtocol::echo_filter)
> server localhost:8545 listening (TestProtocol::echo_nonblock)
> server localhost:8546 listening (TestProtocol::echo_timeout)
> server localhost:8547 listening (TestProtocol::pseudo_http)
> server localhost:8548 listening (TestPreConnection::note)
> server localhost:8549 listening (TestHooks::hookrun)
> server localhost:8550 listening (TestHooks::init)
> server localhost:8551 listening (TestHooks::stacked_handlers2)
> server localhost:8552 listening (TestHooks::startup)
> server localhost:8553 listening (TestHooks::trans)
> server localhost:8554 listening (TestFilter::both_str_con_add)
> server localhost:8555 listening (TestFilter::in_bbs_inject_header)
> server localhost:8556 listening (TestFilter::in_bbs_msg)
> server localhost:8557 listening (TestFilter::in_str_msg)
> server localhost:8558 listening (TestDirective::perlmodule)
> server localhost:8559 listening (TestDirective::perlrequire)
> server localhost:8560 listening (TestAPI::add_config)
> server localhost:8561 listening (TestDirective::perlloadmodule3)
> server localhost:8562 listening (TestDirective::perlloadmodule4)
> server localhost:8563 listening (TestDirective::perlloadmodule5)
> server localhost:8564 listening (TestDirective::perlloadmodule6)
> server localhost:8565 listening (TestHooks::push_handlers_anon)
> Can't load
> '/home/user/tmp/mod_perl-2.0.6-rc2/blib/arch/auto/APR/Brigade/Brigade.so' for
> module APR::Brigade: rtld: 0712-001 Symbol modperl_croak was referenced
> from module
> /home/user/tmp/mod_perl-2.0.6-rc2/blib/arch/auto/APR/Brigade/Brigade.so(),
> but a runtime definition
> of the symbol was not found. at
> /usr/local/perl/lib/5.14.2/aix-thread-multi/DynaLoader.pm line 1

Re: highscalability.com report

[Fred Moyer]

On Wed, Apr 4, 2012 at 6:37 AM, demerphq  wrote:
> On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
>>
>> When was the last time you built perl with no threading support?  It's
>> certainly a 5%-15% win.
>
> Not certainly. We did that and saw almost no difference.

I've done two perlbench sets of comparisons with threaded/non-threaded
across a couple different versions of perl. I don't have the results
posted on the web anymore, but non-threaded was up to 20% faster for
some operations.

As far as real world differences go, I don't think you are likely to
see differences with mod_perl in production environments with threaded
vs non-threaded.  That 20% increase probably only affects 1% of your
application.

Compiling mod_perl 2 on OS X Lion (blog post)

[Fred Moyer]

Might be useful for building mod_perl on your Lion based machine.

http://blogs.perl.org/users/jason_a_crome/2012/04/compiling-mod-perl-2-on-os-x-lion.html
 

[ANNOUNCE] Apache-SizeLimit-0.97

[Fred Moyer]

A new version of Apache-SizeLimit is coming to a CPAN mirror near you.
Minor changes, you probably don't need to upgrade.

MD5 (Apache-SizeLimit-0.97.tar.gz) = 947390505b4cf9d9b449b67fa741c1e0

=item 0.97 2012-04-02

Set the -apxs argument correctly when building from mod_perl.
[Steve Hay]

[announce] Apache-Reload 0.12

[Fred Moyer]

Apache-Reload 0.12 is headed to a CPAN mirror near you.

MD5  232daa7e1f6ddfbbeac505010f1b20f7


Changes summary

=item 0.12 March 31, 2012

Set the -apxs argument correctly when building from mod_perl.
[Steve Hay]

Doc spelling fix
[Nicholas Bamber]

Add Apache-Test 1.34 dependency.
[Phred]

Re: Minor issue with AuthenNTLM

[Fred Moyer]

> I was considering forking the module and fixing bugs like these, but I
> am not quite sure how much sense that makes given the fact that NTLM is
> deprecated technology.

 

If you're considering forking it, it may not be deprecated.

I'd suggest trying to release a module to CPAN that resolves your specific 
issue, but has a slightly different namespace than Apache2::NTLM. Make it clear 
what your module does that Apache2::NTLM does not. Maybe Apache2::NTLM::OTRS.

If the bug you are running is a blocker for a lot of NTLM users, you should see 
an increase in the use of your module. This is a very healthy software 
development process, one that I think GitHub is really doing a great job of 
executing on.


On Wednesday, March 28, 2012 at 11:18 PM, Michiel Beijen wrote:

> Hi,
> 
> IP schreef op 2012-03-27 16:03:
> 
> > I've successfuly managed to make AuthenNTLM work with my PHP script,
> > but the for some reason the Apache error log is now flooded with
> > messages like:
> > [error] Bad/Missing NTLM/Basic Authorization Header for
> > /somefile.php
> 
> 
> 
> This is actually reported as a (very old) bug in the RT queue for the 
> module:
> https://rt.cpan.org/Public/Bug/Display.html?id=39602
> 
> 
> 
> --
> Mike

Re: Hello, I think TestRunPerl can save me, but I am not sure how to go about it...

[Fred Moyer]

Steve, please direct these questions to the mod_perl list which I have
cc'd.  You're much more likely to get an answer from any one of the
thousands of experienced users on this list than emailing any of the
posters directly.

On Tue, Mar 13, 2012 at 1:18 PM, Steven Lembark  wrote:
>
> Say I have a mod_perl2 handler that does nothing more
> than pass off its request object to another sub. The
> sub gets a few things out of $request->args and the
> headers, proceses its result, and life is good.
>
> 99% of the work inside the handler has nothing whatever
> to do with mod_perl.
>
> I would like to run:
>
>    perl -d submit_a_fake_request;
>
> and watch the request get handled.
>
> I think that PerlTest or PerlTestRun might offer some
> way to do this but, but the POD includes only:
>
>     My::TestRun->new->run(@ARGV);
>
> and I have no idea what to pass in as @ARGV.
>
> Note that I am not trying to debug Apache itself,
> just the code that lives below the handler sub. Nor
> am I writing tests for the most part, I just need
> to see the code in "perl -d" to find out some things
> about what is going on inside the code.
>
> If this were mod_perl with an HTTP::Request object
> I could take an old $r->as_string, strip the method
> and uri, split the headers on newlines, extract the
> query and construct a new HTTP::Request object. I
> am trying to duplicate this procedure in Apache2.
>
> I'll be happy to hand back POD for the PerlTestRun
> that shows someone how to assemble a working Apache2
> request out of as_string output in order to run a
> test. But several days of stumbling through google and
> mod_perl archives leave me with no examples that don't
> already assume that someone knows all of the appropriate
> arguments and methods to call for setting up an object.
>
> Any help would be appreciated.
>
> --
> Steven Lembark                                             3646 Flora Pl
> Workhorse Computing                                   St Louis, MO 63110
> lemb...@wrkhors.com                                      +1 888 359 3508

Re: Apache::compat and new Perl

[Fred Moyer]

On Wed, Mar 7, 2012 at 5:46 AM, Josh Narins  wrote:
>
> Do I need mod_perl1 installed to get Apache::compat and mod_perl2 to work?
>
> mp2 will be using a different Perl, and I'd prefer not to install it if I 
> don't have to.

You should be fine without mp1, but remember you'll need to build it
against another httpd with your different perl. You can't build
mod_perl against the same httpd that already has one built or it will
replace that module you've built against the original perl.

Re: trying to compile mod_perl against httpd-2.4.1

[Fred Moyer]

Thanks for the spot. We're rolling rc3 for 2.0.6 right now, I have
cc'd the dev list about this issue.  I may have some tuits to look at
this, but am guessing someone else will fix it more quickly.

On Tue, Feb 21, 2012 at 11:49 AM, Brian Millett  wrote:
> Well, its a no go, even after checking out the latest SVN code,
>
> Problem is the ‘conn_rec’ structure has changed.  It no longer has 'remote_ip'
> defined in it.
>
>
> [bpm]$ make
> cd "src/modules/perl" && make
> make[1]: Entering directory
> `/home/bpm/src/apache/mod_perl-2.0/src/modules/perl' gcc
> -I/home/bpm/src/apache/mod_perl-2.0/src/modules/perl
> -I/home/bpm/src/apache/mod_perl-2.0/xs -I/usr/include/apr-1
> -I/usr/include/httpd -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe
> -fstack-protector -I/usr/local/include -I/usr/lib64/perl5/CORE -DMOD_PERL
> -DMP_COMPAT_1X -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC \ -c
> modperl_interp.c && mv modperl_interp.o modperl_interp.lo modperl_interp.c: In
> function ‘modperl_interp_select’: modperl_interp.c:503:35: error: ‘conn_rec’
> has no member named ‘remote_ip’ make[1]: *** [modperl_interp.lo] Error 1
> make[1]: Leaving directory
> `/home/bpm/src/apache/mod_perl-2.0/src/modules/perl' make: *** [modperl_lib]
> Error 2
>
>
> Did see the following in the httpd-2.4.1 src, httpd-2.4.1/include/ap_mmn.h
> that seems to be a major API change.
>
> * 2030.0 (2.4.0-dev)  c->remote_ip becomes c->peer_ip and r->client_ip,
> *                         c->remote_addr becomes c->peer_addr and
>  r->client_addr
>
> I guess I'm asking is anyone has made any progress with mod_perl with the new
> httpd 2.4 ??
> --
> Brian Millett
> "We used to have them back home long ago. They use science to achieve the
>  effect of magic. I haven't seen one in years. They almost never travel.
>  They don't like to leave their places of power. To see even one of them
>  is a rare thing. To see more than one at a time is considered a very
>  bad omen."
> [3 mages walk by]
> "Three...this is definitely not good."
>           -- [ Londo (re: technomages), "The Geometry of Shadows"]

[ANNOUNCE] Apache-Test 1.37

[Fred Moyer]

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 
  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: mod perl installed but not running

[Fred Moyer]

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: Perl include directories no longer work in mod_perl

[Fred Moyer]

Try 'yum install perl-Config-Simple'.  If that doesn't work, search for the rpm 
with 'yum search Config-Simple'.  


On Friday, December 23, 2011 at 2:45 PM, Mayuran Yogarajah wrote:

>  
> We just did an upgrade from Centos 5.5 to Centos 5.7 and it seems like the 
> extensions we added to the Perl library directories stopped working:
>  
>  
>  
>  
> [Fri Dec 23 16:40:04 2011] [error] Can't locate Config/Simple.pm in @INC 
> (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi 
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl 
> /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi 
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl 
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 . 
> /etc/httpd)
>  
>  
>  
>  
> We’ve been adding to the library path through /etc/profile:
>  
>  
>  
>  
> LIB_LOCAL=/opt/custom/local
>  
>  
> PERL5LIB=${PERL5LIB}:$LIB_LOCAL/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
>  
>  
> PERL5LIB=${PERL5LIB}:$LIB_LOCAL/lib/perl5/site_perl/5.8.8
>  
>  
>  
>  
> And it looks to be fine:
>  
>  
> echo $PERL5LIB
>  
>  
> :/opt/custom/local/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi:/opt/custom/local/lib/perl5/site_perl/5.8.8
>  
>  
>  
>  
> It’s been working fine until this upgrade to Centos 5.7.
>  
>  
>  
>  
> Please advise. Any help is appreciated.
>  
>  
>  
>  
> Thanks,
>  
>  
> M  

Fw: CPAN Upload: P/PH/PHRED/Apache-SizeLimit-0.96.tar.gz

[Fred Moyer]

Apache::SizeLimit 0.96 has been released and will be available via CPAN soon. 

Changes:

=item 0.96 2011-12-21

eval Linux::Smaps->new call when checking for /proc/self/smaps
[Christian Ruppert ]

Require Apache::Test 1.36 [Fred]

Unshared size is now interpreted as RSS - shared instead of VSIZE - shared
on Linux [Torsten]

Subtest 1 checks that Apache2::SizeLimit->_limits_are_exceeded() returns
false without any limits. But if the test runs near the end of the test
suite it may very well be that some other test has set a limit. [Torsten]




Forwarded message:

> From: PAUSE 
> Reply To: cpan-uplo...@perl.org
> To: Fred Moyer 
> Date: Wednesday, December 21, 2011 7:53:00 PM
> Subject: CPAN Upload: P/PH/PHRED/Apache-SizeLimit-0.96.tar.gz
> 
> The uploaded file
> 
> Apache-SizeLimit-0.96.tar.gz
> 
> has entered CPAN as
> 
> file: $CPAN/authors/id/P/PH/PHRED/Apache-SizeLimit-0.96.tar.gz
> size: 24216 bytes
> md5: 421cc1af83e0a838de965715676cb935
> 
> No action is required on your part
> Request entered by: PHRED (Fred Moyer)
> Request entered on: Thu, 22 Dec 2011 03:52:21 GMT
> Request completed: Thu, 22 Dec 2011 03:53:00 GMT
> 
> Thanks,
> -- 
> paused, v1049
> 

Re: Is it me or is mod_perl extremely dangerous?

[Fred Moyer]

(cc'ing the mod_perl list on this one also, please remember to reply all :)

On Tue, Dec 6, 2011 at 11:28 AM, Dr James A Smith  wrote:
> On 06/12/2011 19:09, Fred Moyer wrote:
>> (cc'ing mod_perl list)
>>
>> On Tue, Dec 6, 2011 at 5:35 AM, Desilets, Alain
>>  wrote:
>>> Thx to Fred, Andre and Jon for answering. BTW: I hope I didn't offend 
>>> anyone. What I really meant was:
>>
>> No offense taken at all.  Welcome to mod_perl!
>>
>>>
>>>   "Is it me or is mod_perl *much more slippery than standard CGI*?"
>>>
>>> I know that there are lots of folks out there using mod_perl, so I assume 
>>> it can be used in a safe way. I am just trying to figure out where the 
>>> slippery patches are, and how easy it will be to slip on them for me, my 
>>> team, my external collaborators, and even writers of CPAN modules.
>>>
>>> The last point is important. Fred wrote:
>>>
>>> " Most developers find it useful to use CPAN modules which are generally 
>>> high quality."
>>>
>>> That's what I do also. In fact, I don't think I have ever used a third 
>>> party module that wasn't from CPAN, and they are, as you say, generally 
>>> high quality.
>>>
>>> However, even those high quality CPAN modules can fall flat on their face 
>>> when they are used in contexts that they weren't designed for. For example, 
>>> I recently discovered that several CPAN modules cannot be used safely in a 
>>> multithreaded or forked environment. Some of them fail "nicely" (i.e. they 
>>> KNOW they aren't supposed to be used in this kind of environment and tell 
>>> you at run time), but others just crash the process upon spawning a new 
>>> fork or thread, and leave you with no indication as to what caused this. I 
>>> am concerned that similar issues might arise when using certain CPAN 
>>> modules in a mod_perl context.
>>>
>>> ---
>>> Question: Is this something that has been known to happen (CPAN modules 
>>> that don't work well in mod_perl), and if so, how common is it?
>>> ---
>>>
>>> Coming back to where the slippery patches are. Initially, it looked to me 
>>> that the main thing to watch out for was global variables. By this, I mean 
>>> variables that can be seen from anywhere in the code. I was OK with that, 
>>> because I never use global variables, and I have taught everyone in my team 
>>> to stay away from them. Also, I don't see global variables being used in 
>>> CPAN modules.
>
> Perl::Critic is your friend in number of places - there are some subtle
> gotchas that people don't realise that are more subtle than the ones
> you mentioned - and perlcritic will point a lot of these out
>
> In a mod_perl registry script, what is wrong with the following:
>
>  my $user = $self->user_from_cookie( $user_cookie ) if $user_cookie;
>
> ?

Re: Is it me or is mod_perl extremely dangerous?

[Fred Moyer]

(cc'ing mod_perl list)

On Tue, Dec 6, 2011 at 5:35 AM, Desilets, Alain
 wrote:
> Thx to Fred, Andre and Jon for answering. BTW: I hope I didn't offend anyone. 
> What I really meant was:

No offense taken at all.  Welcome to mod_perl!

>
>   "Is it me or is mod_perl *much more slippery than standard CGI*?"
>
> I know that there are lots of folks out there using mod_perl, so I assume it 
> can be used in a safe way. I am just trying to figure out where the slippery 
> patches are, and how easy it will be to slip on them for me, my team, my 
> external collaborators, and even writers of CPAN modules.
>
> The last point is important. Fred wrote:
>
> " Most developers find it useful to use CPAN modules which are generally high 
> quality."
>
> That's what I do also. In fact, I don't think I have ever used a third party 
> module that wasn't from CPAN, and they are, as you say, generally high 
> quality.
>
> However, even those high quality CPAN modules can fall flat on their face 
> when they are used in contexts that they weren't designed for. For example, I 
> recently discovered that several CPAN modules cannot be used safely in a 
> multithreaded or forked environment. Some of them fail "nicely" (i.e. they 
> KNOW they aren't supposed to be used in this kind of environment and tell you 
> at run time), but others just crash the process upon spawning a new fork or 
> thread, and leave you with no indication as to what caused this. I am 
> concerned that similar issues might arise when using certain CPAN modules in 
> a mod_perl context.
>
> ---
> Question: Is this something that has been known to happen (CPAN modules that 
> don't work well in mod_perl), and if so, how common is it?
> ---
>
> Coming back to where the slippery patches are. Initially, it looked to me 
> that the main thing to watch out for was global variables. By this, I mean 
> variables that can be seen from anywhere in the code. I was OK with that, 
> because I never use global variables, and I have taught everyone in my team 
> to stay away from them. Also, I don't see global variables being used in CPAN 
> modules.
>
> But after doing a couple experiments, I now realize that package variables 
> are also unsafe in a mod_perl environment. Although I try to avoid them, I 
> don't consider package variables to be "sloppy". Even though they are public 
> and can be seen outside of the package, they can only be seen by those files 
> which actually load the package. So, I am a bit more uncomfortable with that 
> particular slippery patch, because I know that I and some of my team members 
> use package variables occasionally. I also see lots of CPAN modules that use 
> them as well.
>
> One thing that I think will greatly mitigate the risk for us is that we use 
> Test Driven Development, and have PerlUnit tests for every class in our 
> application. This forces us to write our classes that don't assume they will 
> be used in a single CGI script call context. That's because  the tests 
> process instantiated and uses a the class several times in a number of tests 
> and scenarios. But I think this will only help to a point. It's one thing to 
> have a process that runs dozens of tests on a class, but it's a completely 
> different thing to have a process which uses that class to execute thousands 
> of requests per day, and which stays up and running for months at a time.
>
> I guess the only way to find out whether mod_perl works for us is to try it, 
> while keeping the door for going back to standard CGI in case our app is too 
> brittle for it.
>
> Time to buy a mod_perl cookbook I guess ;-).
>
> Again, thx for your useful answers.
>
> Alain
>
> -Original Message-
> From: Fred Moyer [mailto:f...@redhotpenguin.com]
> Sent: Monday, December 05, 2011 4:45 PM
> To: Desilets, Alain
> Cc: mod_perl list
> Subject: Re: Is it me or is mod_perl extremely dangerous?
>
> On Mon, Dec 5, 2011 at 1:06 PM, Desilets, Alain
>  wrote:
>> I'm a complete newbie to mod_perl, and after reading the following
>> documentation:
>>
>> http://perl.apache.org/docs/1.0/guide/porting.html
>>
>> I am scared witless by the fact that many variables don't get reinitialized
>> between calls to the CGI scripts.
>>
>> Particularly scary is the example provided on that page, where the
>> authentication status is stored in a global variable that doesn't get
>> reinitialized. In that example, if Joe logs into the system, and Jane then
>> runs the script, she can get access to the system also without every logging
>> in, because Jo

Re: Is it me or is mod_perl extremely dangerous?

[Fred Moyer]

On Mon, Dec 5, 2011 at 1:06 PM, Desilets, Alain
 wrote:
> I’m a complete newbie to mod_perl, and after reading the following
> documentation:
>
> http://perl.apache.org/docs/1.0/guide/porting.html
>
> I am scared witless by the fact that many variables don’t get reinitialized
> between calls to the CGI scripts.
>
> Particularly scary is the example provided on that page, where the
> authentication status is stored in a global variable that doesn’t get
> reinitialized. In that example, if Joe logs into the system, and Jane then
> runs the script, she can get access to the system also without every logging
> in, because Joe’s authentication status is still there. YIKES!

If you read through the entire example, you will see the point of the
example is to show what can happen from bad programming.

"Because of sloppy programming, a global variable was not reset at the
beginning of the program and voila, you can easily peek into someone
else's email! Here is an example of sloppy code"

> But I’m not convinced, because package variables are not reinitialized
> either!

"The solution is trivial--reset $authenticated to 0 at the beginning
of the program."

> But… we don’t have control over how third party modules were implemented,
> and we use A LOT OF THEM. So I am still very concerned about that, because
> we could end up using a third party module that makes use of package
> variables in a way that is not mod_perl friendly.

You're always free to write your own modules which you have complete
control over.  Most developers find it useful to use CPAN modules
which are generally high quality.


> Am I being too conservative here, or am I right to be that nervous?

I do not think you are justified in stating that mod_perl is
'extremely dangerous'.


> What precautions can we take to prevent this sort of thing from happening?

If you are just starting out with mod_perl, I would skip over the
porting documentation and go straight to the mod_perl2 specific
documentation.  I would also suggest reviewing the following links for
mod_perl development best practices

http://perl.apache.org

http://www.modperlcookbook.org/

http://modperlbook.org/

Re: Apache Children Stuck on futex

[Fred Moyer]

 Have you tried this with mod_perl 2.0.5, or 2.0.6-dev?  May have been resolved 
already. 


On Wednesday, October 26, 2011 at 3:06 PM, Max Barry wrote:

> 
> On 26/10/11 14:56, Max Barry wrote:
> > I'm trying to solve a long-running problem whereby my Apache mod_perl
> > processes get stuck in a "FUTEX_WAIT" state instead of exiting.
> > 
> > I believe this is the same issue as reported here:
> > http://www.gossamer-threads.com/lists/modperl/modperl/99879
> > 
> > The problem occurs fairly frequently following a burst of traffic, when
> > Apache spawns new processes, then attempts to cull them afterward. It
> > also occurred, before I disabled this, when Apache tried to cull a
> > process upon reaching MaxRequestsPerChild.
> 
> Further to this, I've found that the problem occurs even on a fresh
> Apache/mod_perl install; i.e. after completely removing Apache &
> mod_perl, including /etc/apache2/, and doing only this:
> 
>  1. sudo apt-get install apache2-mpm-worker libapache2-mod-perl2
> apache2-doc
> 
>  2. Edit the 'default' site thusly:
> 
> --- /etc/apache2/sites-available/default.original 2011-10-27
> 08:44:11.383803928 +1100
> +++ /etc/apache2/sites-available/default 2011-10-27 08:44:51.795391116 +1100
> @@ -19,6 +19,9 @@
>  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
>  Order allow,deny
>  Allow from all
> +
> + SetHandler perl-script
> + PerlResponseHandler ModPerl::RegistryBB
> 
> 
>  ErrorLog ${APACHE_LOG_DIR}/error.log
> 
>  3. Add a low 'MaxRequestsPerChild' directive (not strictly necessary,
> but makes the problem much more visible):
> 
> --- /etc/apache2/httpd.conf.original 2011-10-27 08:52:48.898361041 +1100
> +++ /etc/apache2/httpd.conf 2011-10-27 08:58:52.384091605 +1100
> @@ -0,0 +1 @@
> +MaxRequestsPerChild 10
> 
>  4. sudo /etc/init.d/apache2 restart
> 
>  5. ab -n 450 -c 175 http://localhost/cgi-bin/
> 
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
> 
> Benchmarking localhost (be patient)
> Completed 100 requests
> Completed 200 requests
> Completed 300 requests
> Completed 400 requests
> apr_poll: The timeout specified has expired (70007)
> Total of 426 requests completed
> 
> (The number "426" above varies: sometimes it's as low as 400, sometimes
> all requests complete. Usually, though, it's around 430.)
> 
> I've also established that:
> 
> * The problem occurs regardless of whether ModPerl::Registry,
> ModPerl::RegistryBB, or ModPerl::PerlRun is used.
> 
> * The problem occurs even when all Apache modules are disabled except
> for alias, authz_host, and mod_perl.
> 
> * The problem occurs even when no script is being run: i.e. Apache is
> asked for "/cgi-bin/nonexistentscript.cgi", or just "/cgi-bin/".
> 
> This is pretty perplexing.
> 
> Max.

Re: $r vs. Apache2::RequestUtil->request

[Fred Moyer]

Apache2::Request is a Perl module which is part of the libapreq Apache
software project.  You have to install apreq (
http://httpd.apache.org/apreq/ ) and then load the shared object in
httpd.conf via LoadModule.  It contains many convenience methods that
CGI.pm normally provides.

Apache2::RequestUtil is part of the mod_perl2 core.

If you are using $r->log then you need to 'use Apache2::Log;' in
either startup.pl or your module.

Hope that helps.

On Tue, Oct 25, 2011 at 11:53 AM, Charlie Katz  wrote:
> Okay, never mind.  The Apache2::Log methods are in fact working for me.
>  Stupid error.
> I am still curious about the difference between the Apache2::Request object
> which is the default request record accessor, and the Apache2::RequestRec
> object which comes out of Apache2::RequestUtil::request.
>
> On Tue, Oct 25, 2011 at 1:43 PM, Charlie Katz  wrote:
>>
>> Hi, I'm confused about something.  I am cleaning up some legacy Perl code
>> in our application, and I find a number of our custom Perl modules have
>> functions which require $r be passed to them solely for use in logging (e.g.
>> $r->log->error()). I want to remove that requirement, so I am changing
>> things around so that the code uses Apache2::RequestUtil::request to get the
>> request object when needed.  This is working fine, except when I use the
>> object retrieved that way, the $r->log methods fail to write to the server
>> log.   In addition, I see that the original $r and the new one from
>> A::RU::request are different:
>> use Data::Dumper;
>> print STDERR Dumper($r);
>> print STDERR Dumper(Apache2::RequestUtil->request);
>> yields
>> $VAR1 = bless( do{\(my $o = 158143776)}, 'Apache2::Request' );
>> $VAR1 = bless( do{\(my $o = 158116376)}, 'Apache2::RequestRec' );
>> Can someone help me understand this difference, and how to use the object
>> retrieved from A::RU::request to access the Apache2::Log methods?  Why isn't
>> the original $r an Apache2::RequestRec object?
>> This is Perl 5.14.2, mod_perl 2.0.5
>> Thanks.
>> Charlie Katz
>
>

Re: [mp2] mod_perl 2.0.5 pre-installation test failures

[Fred Moyer]

Thanks for the report, will try to reproduce these issues. Some of them may 
have been resolved with 2.0.6-dev though (available at http://perl.apache.org).

On Thursday, October 13, 2011 at 5:47 AM, Charles Jardine wrote:

> -8<-- Start Bug Report 8<--
> 1. Problem Description:
> 
> I am getting 'make test' failures in the following tests:
> 
>  t/api/request_rec.t, t/filter/out_str_reverse.t, t/api/err_headers_out.t
> 
> The output of t/TEST -verbose for these tests is:
> 
> ===
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/local/perl/5.14.2-A/bin/perl 
> /usr/local/src/httpd/apache/mod_perl-2.0.5/t/TEST -verbose 
> 't/api/request_rec.t' 't/filter/out_str_reverse.t' 't/api/err_headers_out.t'
> /usr/local/httpd/apache/2.2.21-perl.5.14.2-A-mod-perl.2.0.5-mod-ucam-webauth.1.4.3/bin/httpd
>  -d /usr/local/src/httpd/apache/mod_perl-2.0.5/t -f 
> /usr/local/src/httpd/apache/mod_perl-2.0.5/t/conf/httpd.conf -D APACHE2 -D 
> PERL_USEITHREADS
> using Apache/2.2.21 (prefork MPM)
> 
> waiting 120 seconds for server to start: .[Thu Oct 13 12:55:44 2011] [info] 6 
> Apache2:: modules loaded
> [Thu Oct 13 12:55:44 2011] [info] 0 APR:: modules loaded
> [Thu Oct 13 12:55:44 2011] [info] base server + 29 vhosts ready to run tests
> .
> waiting 120 seconds for server to start: ok (waited 0 secs)
> server localhost:8529 started
> server localhost:8530 listening (filter_out_apache)
> server localhost:8531 listening (perlsections)
> server localhost:8532 listening (inherit)
> server localhost:8533 listening (TestModperl::merge)
> server localhost:8534 listening (TestModperl::perl_options)
> server localhost:8535 listening (TestModperl::perl_options2)
> server localhost:8536 listening (TestModperl::setupenv)
> server localhost:8537 listening (TestModules::proxy)
> server localhost:8538 listening (TestUser::rewrite)
> server localhost:8539 listening (TestVhost::config)
> server localhost:8540 listening (TestVhost::log)
> server localhost:8541 listening (TestProtocol::echo_bbs)
> server localhost:8542 listening (TestProtocol::echo_bbs2)
> server localhost:8543 listening (TestProtocol::echo_block)
> server localhost:8544 listening (TestProtocol::echo_filter)
> server localhost:8545 listening (TestProtocol::echo_nonblock)
> server localhost:8546 listening (TestProtocol::echo_timeout)
> server localhost:8547 listening (TestProtocol::pseudo_http)
> server localhost:8548 listening (TestPreConnection::note)
> server localhost:8549 listening (TestHooks::hookrun)
> server localhost:8550 listening (TestHooks::init)
> server localhost:8551 listening (TestHooks::stacked_handlers2)
> server localhost:8552 listening (TestHooks::startup)
> server localhost:8553 listening (TestHooks::trans)
> server localhost:8554 listening (TestFilter::both_str_con_add)
> server localhost:8555 listening (TestFilter::in_bbs_inject_header)
> server localhost:8556 listening (TestFilter::in_bbs_msg)
> server localhost:8557 listening (TestFilter::in_str_msg)
> server localhost:8558 listening (TestDirective::perlmodule)
> server localhost:8559 listening (TestDirective::perlrequire)
> server localhost:8560 listening (TestAPI::add_config)
> server localhost:8561 listening (TestDirective::perlloadmodule3)
> server localhost:8562 listening (TestDirective::perlloadmodule4)
> server localhost:8563 listening (TestDirective::perlloadmodule5)
> server localhost:8564 listening (TestDirective::perlloadmodule6)
> server localhost:8565 listening (TestHooks::push_handlers_anon)
> [warning] Using random number seed: 1750998099 (autogenerated)
> t/filter/out_str_reverse.t .. 
> 1..2
> # Running under perl version 5.014002 for linux
> # Current time local: Thu Oct 13 12:55:46 2011
> # Current time GMT: Thu Oct 13 11:55:46 2011
> # Using Test.pm version 1.25_02
> # Using Apache/Test.pm version 1.36
> # testing : reverse filter
> # expected: abcdefghijklmnopqrstuvwxyz
> # 0123456789
> # Reversed by mod_perl 2.0
> # received: abcdefghijklmnopqrstuvwxyz
> # 0123456789
> # Reversed by mod_perl 2.0
> ok 1
> # testing : reverse filter
> # expected: abcdefghijklmnopqrstuvwxyz
> # 0123456789
> # Reversed by mod_perl 2.0
> # received: abcdefghijklmnopqrstuvwxyz
> # 0123456789
> not ok 2
> # Failed test 2 in t/filter/out_str_reverse.t at line 30
> Failed 1/2 subtests 
> t/api/err_headers_out.t . 
> 1..6
> # Running under perl version 5.014002 for linux
> # Current time local: Thu Oct 13 12:55:46 2011
> # Current time GMT: Thu Oct 13 11:55:46 2011
> # Using Test.pm version 1.25_02
> # Using Apache/Test.pm version 1.36
> # testing : OK
> # expected: 200
> # received: 200
> ok 1
> # testing : X-err_headers_out: made it
> # expected: err_headers_out
> # received: undef
> not ok 2
> # testing : X-headers_out: made it
> # expected: headers_out
> # received: undef
> not ok 3
> # Failed test 2 in t/api/err_headers_out.t at line 22
> # Failed test 3 in t/api/err_hea

Re: Building mod_perl for authentication

[Fred Moyer]

You should be able to run 5.14.1 with 2.06-dev available on
http://perl.apache.org.

If that doesn't work, I'd suggest posting your handlers to this list.

Looking at that symbol error though, it suggests that you may have
built mod_perl with a different binary build than it is being run
with.  Undefined symbols are generally an indication of incompatible
Perl internal apis.

On Sat, Oct 8, 2011 at 6:50 AM, Dan Axtell  wrote:
> I've now tried various version of Perl (5.10.1, 5.12.4, 5.14.1), and various
> version of Apache, but I'm unable to get Apache to run when mod_perl is
> installed.
>
> The error logs show
>  symbol lookup error: /usr/local/lib/perl5/site_perl/5.14.1/x86_64-
> linux/auto/ModPerl/Util/Util.so: undefined symbol:
> Perl_xs_apiversion_bootcheck
>
> This is from an earlier attempt to test more recent versions of Perl, which
> seemed to do everything I need OK.  That led me to remove ./site_perl/5.14.1
> altogether, so at least I'm able to run Apache version 2.2.21 with Perl 5.12.4
> and mod_perl 2.0.5.
>
> However authentication still doesn't work.  When I call $r->user in my
> authenticaion script for a URL that uses basic authentication, I don't get the
> login pop-up at all, and $r->user returns a value of  ' (single quote)
>
> when I run make test in mod_perl, the logs show:
>
> *** The following error entry is expected and harmless ***
> [Sat Oct 08 08:27:58 2011] [error] [client 127.0.0.1] custom die hook:
> Undefined subroutine &TestError::runtime::no_such_func called at
> /home/daxtell/src/mod_perl-2.0.5/t/response/TestError/runtime.pm line 150.\n
> [Sat Oct 08 08:28:03 2011] [error] [client 127.0.0.1] user stas:
> authentication failure for "/": Password Mismatch
>
> *** The following error entry is expected and harmless ***
> [Sat Oct 08 08:28:08 2011] [error] [client 127.0.0.1] need AuthName:
> /TestModperl__setauth
> [Sat Oct 08 08:28:15 2011] [error] [client 127.0.0.1] Undefined subroutine
> &TestHooks::error::bomb called at
> /home/daxtell/src/mod_perl-2.0.5/t/hooks/TestHooks/error.pm line 21.\n
> [Sat Oct 08 08:28:15 2011] [error] [client 127.0.0.1] Undefined subroutine
> &TestHooks::error::bomb called at
> /home/daxtell/src/mod_perl-2.0.5/t/hooks/TestHooks/error.pm line 21.\n
>
>
> Any thoughts on why this would suddenly stop working?  Also, is there any
> reason not to try and use Perl 5.14.2 with mod_perl?
>
> Thanks,
> Dan
>

Re: Building mod_perl 2.0.5

[Fred Moyer]

On Friday, October 7, 2011 at 1:50 PM, Dan Axtell wrote:
> On Friday, October 07, 2011 04:35:08 pm Fred Moyer wrote:
> > On Fri, Oct 7, 2011 at 1:15 PM, Dan Axtell  > (mailto:daniel.axt...@snet.net)> wrote:
> > 
> > That version of Apache is the legacy 2.0.x branch. Any chance you can
> > upgrade to 2.2.x? Some of the authentication handling changed IIRC.
> 
> I'm sorry, I meant to say I'm building Apache 2.2.21, mod_perl 2.0.5., perl 
> 5.14.2 I wanted to upgrade Apache because of some of the recent security 
> holes found.
In that case, you could run 'make test TEST_VERBOSE=1', and then post the 
t/log/error_logs content here.  Also the httpd configuration options.  Last 
time I worked with 64-bit I had to compile Perl with the -fPIC option.  
mod_perl though should fail to build without Perl configured like that however.

Fw: CPAN Upload: P/PH/PHRED/Apache-DBI-1.11.tar.gz

[Fred Moyer]

Apache::DBI 1.11 has been released with a perl 5.14 compatibility update.

1.11 October 7, 2011
 - RT 69087, Perl 5.14 'Using qw(...) as parentheses' fix

Forwarded message: 
> From: PAUSE 
> Reply To: cpan-uplo...@perl.org
> To: Fred Moyer 
> Date: Friday, October 7, 2011 1:40:39 PM
> Subject: CPAN Upload: P/PH/PHRED/Apache-DBI-1.11.tar.gz
> 
> The uploaded file
> 
>  Apache-DBI-1.11.tar.gz
> 
> has entered CPAN as
> 
>  file: $CPAN/authors/id/P/PH/PHRED/Apache-DBI-1.11.tar.gz
>  size: 34664 bytes
>  md5: b973fdf5292bbe6caa38a664d0a83f0b
> 
> No action is required on your part
> Request entered by: PHRED (Fred Moyer)
> Request entered on: Fri, 07 Oct 2011 20:39:17 GMT
> Request completed: Fri, 07 Oct 2011 20:40:39 GMT
> 
> Thanks,
> -- 
> paused, v1049

Re: Building mod_perl 2.0.5

[Fred Moyer]

On Fri, Oct 7, 2011 at 1:15 PM, Dan Axtell  wrote:
> Hi,
>
> I'm trying to upgrade some 64-bit Linux servers and though I'd upgrade Perl as
> well.  I've built the latest Apache (2.0.21), Perl (5.14.2) and mod_perl

That version of Apache is the legacy 2.0.x branch.  Any chance you can
upgrade to 2.2.x?  Some of the authentication handling changed IIRC.


> (2.0.5),  but mod_perl fails three tests:
> api/request_rec
> filter/out_str_reverse
> err_headers_out
>
> When I went ahead and installed this on a test server, some stuff worked but
> some custom authentication handlers failed.
>
> The last time I built everything from source I used Perl 5.10.1 and mod_perl
> 2.0.4, I believe.  Is there a recommended version of Perl to use  when
> building mod_perl?
>
> Thanks,
> Dan
>

Re: mod_perl 2.0.5 Centos 6 rpms

[Fred Moyer]

On Tue, Sep 27, 2011 at 10:13 AM, Dave Morgan  wrote:
> On 26/09/11 11:51 AM, Fred Moyer wrote:
>>
>> For those Centos 6 users here looking for mod_perl 2.0.5, I rolled a few
>> rpms.
>
> Thank you Fred, I cannot (but I'll try :) explain how useful this is to us.

No problem, I submitted these rpms to the Centos devel list and it
looks like they'll be getting pushed upstream for Centos 6, and
possibly Centos 5 also.


>
> We started with mod-perl around 1999, I believe. We used/had to do
> do every thing by hand. A typical web server machine build
> took 2 to 4 days and involved:
>
> in rare cases make and install gcc
> install the base linux distribution
> make and install a custom kernel
> make and install required kernel modules
> make and install perl 5
> make and install apache, mod-perl, mod-ssl etc.
>
> I am sure I am missing stuff. There were no central repositories.
> You had to visit each source site manually. The software stack was
> rarely updated, once you got it working you left it alone ;)
>
> Now we build a machine in 2-4 hours;
> - linux install
> - yum install *many things*
> - yum update
>
> Thank you once again.
>
> Dave
> --
> Dave Morgan
> Operations Manager, Cool Places In Canada
> http://www.coolplaces.ca
> dave.mor...@coolplaces.ca
> 403 288 8759
>

Re: [mp 2.0.5] Early core dump:-( OpenSolaris-x86, Apache 2.2.21 & Perl 5.14.1

[Fred Moyer]

Have you tried 2.0.5? 


On Wednesday, September 21, 2011 at 7:24 PM, Marco Walther wrote:

> -8<-- Start Bug Report 8<--
> 1. Problem Description:
> 
> Apache with enabled mod_perl runs into a SIGSEGV quickly during the 
> initialization of mod_perl:-( This run is from a worker-mpm but the same 
> happens with the prefork-mpm.
> 
> We were running mod_perl 2.0.4 + Perl 5.10.1 successfully before.
> 
> Any idea??
> 
> Thanks,
> -- Marco
> 
> 2. Used Components and their Configuration:
> 
> *** mod_perl version 2.05
> 
> *** using 
> /export/home/marcow/src/kenai-packages~subversion/mod_perl/mod_perl-2.0.5/lib/Apache2/BuildConfig.pm
> 
> *** Makefile.PL options:
>  MP_APR_LIB => aprext
>  MP_APXS => /opt/kenai/apache2/bin/apxs
>  MP_COMPAT_1X => 1
>  MP_GENERATE_XS => 1
>  MP_LIBNAME => mod_perl
>  MP_USE_DSO => 1
> 
> 
> *** /opt/kenai/apache2/bin/httpd -V
> Server version: Apache/2.2.21 (Unix)
> Server built: Sep 14 2011 22:10:21
> Server's Module Magic Number: 20051115:30
> Server loaded: APR 1.4.5, APR-Util 1.3.12
> Compiled using: APR 1.4.5, APR-Util 1.3.12
> Architecture: 32-bit
> Server MPM: Worker
>  threaded: yes (fixed thread count)
>  forked: yes (variable process count)
> Server compiled with
>  -D APACHE_MPM_DIR="server/mpm/worker"
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_PROC_PTHREAD_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  -D APR_HAS_OTHER_CHILD
>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>  -D DYNAMIC_MODULE_LIMIT=128
>  -D HTTPD_ROOT="/opt/kenai/apache2"
>  -D SUEXEC_BIN="/opt/kenai/apache2/bin/suexec"
>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>  -D DEFAULT_ERRORLOG="logs/error_log"
>  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
>  -D SERVER_CONFIG_FILE="conf/httpd.conf"
> 
> *** /usr/bin/ldd /opt/kenai/apache2/bin/httpd
>  libm.so.2 => /usr/lib/libm.so.2
>  libaprutil-1.so.0 => /opt/kenai/apache2/lib/libaprutil-1.so.0
>  libdb-4.6.so => /opt/kenai/lib/libdb-4.6.so
>  libresolv.so.2 => /usr/lib/libresolv.so.2
>  libexpat.so.1 => /usr/lib/libexpat.so.1
>  libiconv.so.2 => /opt/kenai/lib/libiconv.so.2
>  libapr-1.so.0 => /opt/kenai/apache2/lib/libapr-1.so.0
>  libuuid.so.1 => /usr/lib/libuuid.so.1
>  libsendfile.so.1 => /usr/lib/libsendfile.so.1
>  libsocket.so.1 => /usr/lib/libsocket.so.1
>  libnsl.so.1 => /usr/lib/libnsl.so.1
>  libpthread.so.1 => /usr/lib/libpthread.so.1
>  libc.so.1 => /usr/lib/libc.so.1
>  libdlpi.so.1 => /lib/libdlpi.so.1
>  libmp.so.2 => /lib/libmp.so.2
>  libmd.so.1 => /lib/libmd.so.1
>  libscf.so.1 => /lib/libscf.so.1
>  libinetutil.so.1 => /lib/libinetutil.so.1
>  libdladm.so.1 => /lib/libdladm.so.1
>  libuutil.so.1 => /lib/libuutil.so.1
>  libgen.so.1 => /lib/libgen.so.1
>  libdevinfo.so.1 => /lib/libdevinfo.so.1
>  librcm.so.1 => /lib/librcm.so.1
>  libnvpair.so.1 => /lib/libnvpair.so.1
>  libexacct.so.1 => /usr/lib/libexacct.so.1
>  libkstat.so.1 => /lib/libkstat.so.1
>  libcurses.so.1 => /lib/libcurses.so.1
>  libsec.so.1 => /lib/libsec.so.1
>  libavl.so.1 => /lib/libavl.so.1
>  libidmap.so.1 => /usr/lib/libidmap.so.1
>  libldap.so.5 => /usr/lib/libldap.so.5
>  libsldap.so.1 => /usr/lib/libsldap.so.1
>  libadutils.so.1 => /usr/lib/libadutils.so.1
>  libsasl.so.1 => /usr/lib/libsasl.so.1
>  libnspr4.so => /usr/lib/mps/libnspr4.so
>  libplc4.so => /usr/lib/mps/libplc4.so
>  libnss3.so => /usr/lib/mps/libnss3.so
>  libssl3.so => /usr/lib/mps/libssl3.so
>  librt.so.1 => /lib/librt.so.1
>  libdl.so.1 => /lib/libdl.so.1
>  libsoftokn3.so => /usr/lib/mps/libsoftokn3.so
>  libplds4.so => /usr/lib/mps/libplds4.so
>  libthread.so.1 => /lib/libthread.so.1
>  libbsm.so.1 => /lib/libbsm.so.1
>  libsecdb.so.1 => /lib/libsecdb.so.1
>  libtsol.so.2 => /lib/libtsol.so.2
> 
> 
> *** (apr|apu)-config linking info
> 
>  -L/opt/kenai/apache2/lib -laprutil-1 -lldap -llber -ldb-4.6 
> -lexpat -liconv -L/opt/kenai/lib -R/opt/kenai/lib 
> -L/opt/kenai/apache2/lib -R/opt/kenai/apache2/lib
>  -L/opt/kenai/apache2/lib -lapr-1 -luuid -lsendfile -lsocket -lnsl 
> -lpthread
> 
> 
> 
> *** /opt/kenai/bin/perl -V
> Summary of my perl5 (revision 5 version 14 subversion 1) configuration:
> 
>  Platform:
>  osname=solaris, osvers=2.11, archname=i86pc-solaris-thread-multi
>  uname='sunos kexdev03z1 5.11 snv_111b i86pc i386 i86pc '
>  config_args='-Dprefix=/opt/kenai -A 
> prepend:ccflags=-I/opt/kenai/include -A prepend:libpth=/opt/kenai/lib 
> /opt/SUNWspro/prod/lib/sparc/ /opt/SUNWspro/prod/lib/ /lib /usr/lib -A 
> prepend:ldflags=-L/opt/kenai/lib -R/opt/kenai/lib -Doptimize=-g -U 
> locincpth= -U loclibpth= -U glibpth= -Dusethreads -d -e'
>  hint=recommended, useposix=true, d_sigaction=define
>  useithreads=define, usemultiplicity=define
>  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>  use64bitint=undef, use64bitall=undef, uselongdouble=undef
>  usemymalloc=n, bincompat5005=undef
>  Compiler:
>  cc='/opt/SUNWspro/b

mod_perl 2.0.5 Centos 6 rpms

[Fred Moyer]

For those Centos 6 users here looking for mod_perl 2.0.5, I rolled a few rpms. 
Centos 6 is awesome, and so is mod_perl 2.0.5. Double awesomeness.

Standard disclaimer - these rpms have no warranty, are licensed under the same 
terms as Perl. They may come into your kitchen at night and empty any the bags 
of flour all over the kitchen, so use with caution. Test on your testing 
systems before deploying to production. Feedback welcome.

 http://people.apache.org/~phred/mod_perl-2.0.5-1.src.rpm 
http://people.apache.org/~phred/mod_perl-2.0.5-1.i386.rpm
http://people.apache.org/~phred/mod_perl-devel-2.0.5-1.i386.rpm