How do I use a vendor Apache with a self-compiled Perl and mod_perl?

Question

I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my @INC path. I don't mind compiling my own mod_perl.

Fairman

Answer 1

1. Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0

2. Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:

   /usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs

3. Install and configure mod_perl like normal.

It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:

export PATH=/usr/local/perl/5.10.0/bin:$PATH

Szabo

But I don't want to install my mod_perl over the top of the vendor's mod_perl... How do I tell Apache to use mine? Maybe mod_so, as suggested by another commenter? – Fairman

apxs has an option that allows you to build only. You can then move the mod_perl.so somewhere and refer to it with a full path in the LoadModule line. You may also want to pass Makefile.PL a PREFIX argument to install the Apache:: and/or ModPerl:: perl modules someplace non-standard. – Szabo

Answer 2

You'll want to look into mod_so

Weimer

I think this misses the point. Compiling your own mod_perl and installing it is easy. It's hard to do it in a maintainable, scalable way. – Castara

I'm not sure I understand. Are you saying I should build my own mod_perl.so somewhere and just point Apache to load that version of mod_perl via "LoadModule perl_module /some/absolute/path/mod_perl.so"? – Fairman

Answer 3

I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.

I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.

Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.

It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.

I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.

If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.

Castara