Multiple mod_perl 2.0 installations on one Linux machine
Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 11:56:32 von Michael Ludwig
What does a mod_perl 2.0 installation on Linux consist of?
* Apache 2.0 or 2.2
* mod_perl 2.0
* libapreq (optional, true, but indispensable for convenience)
The Apache, let's say the worker MPM, is going to be installed
under /usr/local/apache22w. If I now want to install a prefork
MPM next to it, this is no problem at all, it goes to, say,
/usr/local/apache22pf.
But what about the mod_perl 2.0 installation?
The mod_perl DSO itself is installed to $ServerRoot/modules. Doing
an ldd on the module doesn't reveal any dependencies on libraries
under $ServerRoot/lib, but I guess that nevertheless, this mod_perl
does very well depend on the particular Apache version it is
configured and built to work with. True?
There is also the Perl interface to Apache/mod_perl, a bunch
of modules installed under, say, /usr/local/lib/perl/5.8.8 and
/usr/local/lib/perl/5.8.8/auto.
Doing a crude ldd on all those modules:
find /usr/local/lib/perl/5.8.8/auto/Apache2 -type f -name \*.so \
| while read so; do ldd $so; done | sort | uniq -c
I can only see dependencies on /lib/ld-linux.so.2, libc.so.6, and
linux-gate.so.1. But this certainly doesn't mean that there is no
dependency on the particular version of mod_perl that is installed?
Or does it?
Doing the same find/ldd loop for /usr/local/lib/perl/5.8.8/auto/APR,
I can see more dependencies, including dependencies on the
particular Apache installation:
/usr/local/apache22w/lib/libapr-1.so.0 (0xb7eb8000)
/usr/local/apache22w/lib/libaprutil-1.so.0
/usr/local/apache22w/lib/libexpat.so.0
And even - horrors - this one (which looks like an error in the
configure/build logic):
/usr/local/src/libapreq2-2.08/library/.libs/libapreq2.so.3
Now, what happens if I am going to install a new Apache
2.2/prefork with mod_perl in addition to the already existing
Apache 2.2/worker with mod_perl? The new mod_perl modules are
going to clobber the existing one, probably rendering the old
mod_perl useless by supplanting their own versions linked to the
prefork MPM libraries, and I imagine the worker MPM won't be happy
when being asked to interact with these. True?
Does anyone know what the dependencies are?
And how would I deal with this situation if my above observation
was true and I wanted a worker and a prefork MPM on the same
machine, both with mod_perl?
Michael Ludwig
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 18:22:00 von Philip Gollucci
Michael Ludwig wrote:
> The mod_perl DSO itself is installed to $ServerRoot/modules. Doing
> an ldd on the module doesn't reveal any dependencies on libraries
> under $ServerRoot/lib, but I guess that nevertheless, this mod_perl
> does very well depend on the particular Apache version it is
> configured and built to work with. True?
Very true.
> I can only see dependencies on /lib/ld-linux.so.2, libc.so.6, and
> linux-gate.so.1. But this certainly doesn't mean that there is no
> dependency on the particular version of mod_perl that is installed?
> Or does it?
it most definitely dpends on libperl.so, httpd, apr, apr-util, and
mod_perl.so
> Doing the same find/ldd loop for /usr/local/lib/perl/5.8.8/auto/APR,
> I can see more dependencies, including dependencies on the
> particular Apache installation:
libapreq2.so and mod_apreq2.so + all the above ones.
>
> /usr/local/apache22w/lib/libapr-1.so.0 (0xb7eb8000)
> /usr/local/apache22w/lib/libaprutil-1.so.0
> /usr/local/apache22w/lib/libexpat.so.0
>
> And even - horrors - this one (which looks like an error in the
> configure/build logic):
>
> /usr/local/src/libapreq2-2.08/library/.libs/libapreq2.so.3
we [joes] just fixed this though it doesn't affect everyone. Its will
be in the next release which will be soonish
> Now, what happens if I am going to install a new Apache
> 2.2/prefork with mod_perl in addition to the already existing
> Apache 2.2/worker with mod_perl? The new mod_perl modules are
> going to clobber the existing one, probably rendering the old
> mod_perl useless by supplanting their own versions linked to the
> prefork MPM libraries, and I imagine the worker MPM won't be happy
> when being asked to interact with these. True?
Correct, you get to play magical paths.
Consider yourself a developer now and the following tree:
/sfw
/perl
5.8.1
5.8.8
none-stdio-mymalloc
ithread-perlio-perlmalloc
/cpans
5.8.8-none-perlio-perlmalloc
/apr
1.3.3
threaded
none
/apu
1.3.4
apr-1.3.3-threaded
threaded
none
apr-1.3.3-none
/httpd
2.2.11
prefork
apr-1.3.3-none=apu-1.3.4-none
worker
event
/mod_perl
2.0.3
2.0.4
r732904
5.8.8-none-perlio-mymalloc=httpd-2.2.11-apr-1.3.3-none-apu-1 .3.4-none
/libapreq2
2.0.7
2.0.8
2.0.4=5.8.8-none-perlio-mymalloc=httpd-2.2.11-apr-1.3.3-none -apu-1.3.4
After doing this with a bug of ./configure, Makefile.PL and Configure
flags you have 2 options
1) use the path to the .so in the install directories
2) install the .so into modules/
BUT rename it to something like
mod_perl-5.8.8-none-perlio-mymalloc=httpd-2.2.11-apr-1.3.3-n one-apu-1.3.4-none.so
Then load the correct one.
The good part is that Apache-Test lets you pass flags to name the
mod_perl.so you want. When testing stuff or running the perl test suite.
This also applies to libapreq2.so, but not quite yet with the
Apache-Test cli naming.
Doing the above will allow you to install ALMOST the full permutations
of what we support. To get the full amount, you have to through GCC into
the mix for older httpd's.
Be warned, you'll need a good sized disk for this. Of course, if there
are combinations you know you'll never care about, then you leave them
out and your directory names get shorter.
my @perl_io_types = qw(perlio stdio);
my @perl_thread_types = qw(none ithreads);
my @perl_malloc_types = qw(mymalloc perlmalloc);
## only some were actually bundled
## 0.x for 2.0.xx 1.2.x and 1.3.x for 2.2.xx)
## threadedness of apr/apu should match
my @apr_vers = qw(lots);
my @apu_vers = qw(lots);
my @apr_thread_types = qw(threaded none);
my @apu_thread_types = qw(threaded none)
## XXX: dbd, gdbm, mysql, pgsql, oracle, freetds, ldap, etc...
## prefork is apr/apu without threads
## prefork_threaded is them with threads
my @httpd2_vers = qw(2.0.48...2.0.63, 2.2.0..2.2.11);
my @httpd2_mpms = qw(prefork prefork_threaded worker event);
my @mod_perl_vers = qw(2.0.4);
MP_MAINTAINER MP_DEBUG MP_APXS
my @libapreq2_vers = qw(2.0.8)
--
------------------------------------------------------------ ------------
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior System Admin - RideCharge, Inc. http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 19:26:45 von Perrin Harkins
On Mon, Jan 19, 2009 at 5:56 AM, Michael Ludwig wrote:
> Now, what happens if I am going to install a new Apache
> 2.2/prefork with mod_perl in addition to the already existing
> Apache 2.2/worker with mod_perl?
Hmm, isn't the MPM just a runtime configuration? Why would you need
another httpd install? It sounds like a separate config file would do
it, if that's all you want to change.
If you want to change other things, like using different version of
httpd, the safest thing is to run two separate perls, one for each
mod_perl setup.
- Perrin
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 19:37:29 von Adam Prime
Perrin Harkins wrote:
> Hmm, isn't the MPM just a runtime configuration? Why would you need
> another httpd install? It sounds like a separate config file would do
> it, if that's all you want to change.
MPM is a build time configuration via the --with-mpm= to ./configure
Adam
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 19:41:17 von Perrin Harkins
On Mon, Jan 19, 2009 at 1:37 PM, Adam Prime wrote:
> Perrin Harkins wrote:
>>
>> Hmm, isn't the MPM just a runtime configuration? Why would you need
>> another httpd install? It sounds like a separate config file would do
>> it, if that's all you want to change.
>
> MPM is a build time configuration via the --with-mpm= to ./configure
I thought you could build more than one and load the one you want at
runtime. Isn't that what Red Hat does?
- Perrin
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 19:45:38 von Adam Prime
Perrin Harkins wrote:
> On Mon, Jan 19, 2009 at 1:37 PM, Adam Prime wrote:
>> Perrin Harkins wrote:
>>> Hmm, isn't the MPM just a runtime configuration? Why would you need
>>> another httpd install? It sounds like a separate config file would do
>>> it, if that's all you want to change.
>> MPM is a build time configuration via the --with-mpm= to ./configure
>
> I thought you could build more than one and load the one you want at
> runtime. Isn't that what Red Hat does?
>
If redhat's shipping more than one mpm, they've patched httpd.
According to the 2.2 docs, you have to choose exactly one MPM:
--with-mpm=MPM
Choose the process model for your server. You have to select
exactly one Multi-Processing Module. Otherwise the default MPM for your
operating system will be taken. Possible MPMs are beos, mpmt_os2,
prefork, and worker.
http://httpd.apache.org/docs/2.2/programs/configure.html
Adam
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 19:52:20 von R P
Why not just run multiple httpds? I do it, but I have multiple IPs
and that may be a requirement for running different httpds.
On Jan 19, 2009, at 12:45 PM, Adam Prime wrote:
> Perrin Harkins wrote:
>> On Mon, Jan 19, 2009 at 1:37 PM, Adam Prime
>> wrote:
>>> Perrin Harkins wrote:
>>>> Hmm, isn't the MPM just a runtime configuration? Why would you
>>>> need
>>>> another httpd install? It sounds like a separate config file
>>>> would do
>>>> it, if that's all you want to change.
>>> MPM is a build time configuration via the --with-mpm= to ./configure
>> I thought you could build more than one and load the one you want at
>> runtime. Isn't that what Red Hat does?
>
> If redhat's shipping more than one mpm, they've patched httpd.
> According to the 2.2 docs, you have to choose exactly one MPM:
>
> --with-mpm=MPM
>
> Choose the process model for your server. You have to select
> exactly one Multi-Processing Module. Otherwise the default MPM for
> your operating system will be taken. Possible MPMs are beos,
> mpmt_os2, prefork, and worker.
>
> http://httpd.apache.org/docs/2.2/programs/configure.html
>
> Adam
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 20:08:12 von torsten.foertsch
On Mon 19 Jan 2009, Adam Prime wrote:
> > I thought you could build more than one and load the one you want
> > at runtime. =A0Isn't that what Red Hat does?
>
> If redhat's shipping more than one mpm, they've patched httpd.
Probably not httpd. At least Suse has not. Instead they configure and=20
build a prefork httpd and a worker httpd one by one and then merge the=20
result. The apache API does not depend on the chosen MPM. So, almost=20
certainly you can build modules (including mod_perl) with one MPM and=20
use it with another.
Usually I build mod_perl against a httpd with worker MPM and TEST is=20
with both worker and prefork. So far I have never found something that=20
went bad only because of the other MPM.
Torsten
=2D-=20
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 20:20:47 von wrowe
Torsten Foertsch wrote:
> On Mon 19 Jan 2009, Adam Prime wrote:
>>> I thought you could build more than one and load the one you want
>>> at runtime. Isn't that what Red Hat does?
>> If redhat's shipping more than one mpm, they've patched httpd.
>
> Probably not httpd. At least Suse has not. Instead they configure and
> build a prefork httpd and a worker httpd one by one and then merge the
> result. The apache API does not depend on the chosen MPM. So, almost
> certainly you can build modules (including mod_perl) with one MPM and
> use it with another.
Built with a threaded MPM and any module should also work on prefork etc.
But not visa-versa!!!
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 19.01.2009 22:53:51 von Philip Gollucci
William A. Rowe, Jr. wrote:
> Built with a threaded MPM and any module should also work on prefork etc.
>
> But not visa-versa!!!
100% correct, the linkage is wrong the other way.
--
------------------------------------------------------------ ------------
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior System Admin - RideCharge, Inc. http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 20.01.2009 16:49:32 von Michael Ludwig
Philip,
thanks a lot for this thorough and exhaustive answer!
Philip M. Gollucci schrieb:
> Michael Ludwig wrote:
So, to summarize: The mod_perl DSO depends on the particular versions of
Perl and Apache.
The modules in the Apache2:: namespace
> most definitely dpends on libperl.so, httpd, apr, apr-util, and
> mod_perl.so
The modules in the Apache2:: namespace depend on
> libapreq2.so and mod_apreq2.so + all the above ones.
Plus, maybe incidentally, on libexpat, as shown in my ldd output:
>> /usr/local/apache22w/lib/libapr-1.so.0 (0xb7eb8000)
>> /usr/local/apache22w/lib/libaprutil-1.so.0
>> /usr/local/apache22w/lib/libexpat.so.0
>>
>> (which looks like an error in the configure/build logic):
>>
>> /usr/local/src/libapreq2-2.08/library/.libs/libapreq2.so.3
> we [joes] just fixed this though it doesn't affect everyone. Its will
> be in the next release which will be soonish
Thanks.
>> Now, what happens if I am going to install a new Apache
>> 2.2/prefork with mod_perl in addition to the already existing
>> Apache 2.2/worker with mod_perl? The new mod_perl modules are
>> going to clobber the existing one, probably rendering the old
>> mod_perl useless by supplanting their own versions linked to the
>> prefork MPM libraries, and I imagine the worker MPM won't be happy
>> when being asked to interact with these. True?
> Correct, you get to play magical paths.
>
> Consider yourself a developer now and the following tree:
Thanks for the following [snipped] as well - I need some more time to
understand it.
Michael Ludwig
Re: Multiple mod_perl 2.0 installations on one Linux machine
am 20.01.2009 16:59:27 von Michael Ludwig
Torsten Foertsch schrieb:
> On Mon 19 Jan 2009, Adam Prime wrote:
>>> I thought you could build more than one and load the one you want
>>> at runtime. Isn't that what Red Hat does?
>> If redhat's shipping more than one mpm, they've patched httpd.
>
> Probably not httpd. At least Suse has not. Instead they configure and
> build a prefork httpd and a worker httpd one by one and then merge the
> result.
The same thing can be observed on Debian. There are a couple of MPMs to
select from - and they're (more or less) mutually exclusive.
root@colinux:~ # apt-cache search -n apache2-mpm-
apache2-mpm-event - Event driven model for Apache HTTPD 2.1
apache2-mpm-itk - multiuser MPM for Apache 2.2
apache2-mpm-perchild - Transitional package - please remove
apache2-mpm-prefork - Traditional model for Apache HTTPD 2.1
apache2-mpm-worker - High speed threaded model for Apache HTTPD 2.1
root@colinux:~ # apt-cache search -f -n apache2-mpm- | grep -i conflict
Conflicts: apache2-mpm-worker, apache2-mpm-perchild, apache2-common
Conflicts: apache2-mpm-prefork, apache2-mpm-worker,
apache2-mpm-perchild, apache2-mpm-event, apache2-common
Conflicts: apache2-mpm-worker, apache2-mpm-perchild, apache2-mpm-event,
apache2-common
Conflicts: apache2-mpm-prefork, apache2-mpm-event, apache2-common
> The apache API does not depend on the chosen MPM. So, almost
> certainly you can build modules (including mod_perl) with one MPM and
> use it with another.
>
> Usually I build mod_perl against a httpd with worker MPM and TEST is
> with both worker and prefork. So far I have never found something that
> went bad only because of the other MPM.
Thanks for triggering William's and Philip's rectifications :-)
Michael Ludwig