You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by martin langhoff <ma...@scim.net> on 2000/07/18 15:54:19 UTC
Installing mod_perl a dozen times ...
hi,
i guess once you've been playing with mod_perl for a while, you
certainly installed perl, many modules, plus mod_perl, plus apache, plus
many more things ...
I keep a personal list of all the modules I must d/l and install on a
virgin OS, and the correct order, versions and params (if needed).
this helps me reduuce the time it takes to up/down-grade perl, for
instance. or mod_perl, maybe. I guess we all should have a list like
that, and it'd be useful to share it and cross-pollinate ideas/modules.
A goal might be making a bundle of key components to install. And maybe
make a srpm out of it, or a small perl script.
what do you think? is it already done? maybe all of a sudden I've got
this oh so great idea just because I have not read the instructions to
download the latest bundle from CPAN.
martin
Re: Installing mod_perl a dozen times ...
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
martin langhoff wrote:
>
> hi,
>
> i guess once you've been playing with mod_perl for a while, you
> certainly installed perl, many modules, plus mod_perl, plus apache, plus
> many more things ...
>
> I keep a personal list of all the modules I must d/l and install on a
> virgin OS, and the correct order, versions and params (if needed).
>
> this helps me reduuce the time it takes to up/down-grade perl, for
> instance. or mod_perl, maybe. I guess we all should have a list like
> that, and it'd be useful to share it and cross-pollinate ideas/modules.
> A goal might be making a bundle of key components to install. And maybe
> make a srpm out of it, or a small perl script.
>
> what do you think? is it already done? maybe all of a sudden I've got
> this oh so great idea just because I have not read the instructions to
> download the latest bundle from CPAN
Have you tried the CPAN shell - it has an autobundle command that allows
you to create a snap shot of all your installed modules, and then all
you need to do is install that bundle via CPAN shell on your new
machine.
As for the creating a collective one - I feel that apart from the Apache
bundles you may find little common ground on what people use.
Hope that helps
Greg Cope
> martin
Re: Installing mod_perl a dozen times ...
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "ml" == martin langhoff <ma...@scim.net> writes:
ml> this helps me reduuce the time it takes to up/down-grade perl, for
ml> instance. or mod_perl, maybe. I guess we all should have a list like
ml> that, and it'd be useful to share it and cross-pollinate ideas/modules.
These are known as "bundles" on CPAN, eg, Bundle::Apache.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-545-6996
GPG & MIME spoken here http://www.khera.org/~vivek/
Re: Installing mod_perl a dozen times ...
Posted by David Hodgkinson <da...@hodgkinson.org>.
martin langhoff <ma...@scim.net> writes:
> what do you think? is it already done? maybe all of a sudden I've got
> this oh so great idea just because I have not read the instructions to
> download the latest bundle from CPAN.
An expansion on Stas' "10 lines to installing mod_perl" in the Guide
perhaps?
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
Re: Installing mod_perl a dozen times ...
Posted by martin langhoff <ma...@scim.net>.
I guess that's good and true for those with low-cost + hi-speed +
reliable connections. I have a few servers in here, and a dial-up
connection i'd rather be careful about ;)
anyway, I find it's very important to know all the modules I'm
needing/using. Is it me?
on the other hand, it'd be nice to be able to have a bundled setup.
[working for offline installations]. it also allows to keep version
control.
martin
David Brown wrote:
>
> I always thought that if you did a CPAN installation of mod_perl, it
> automatically downloaded the modules that it needed. Am I wrong ?
Re: Installing mod_perl a dozen times ...
Posted by David Brown <da...@gisajob.com>.
I always thought that if you did a CPAN installation of mod_perl, it
automatically downloaded the modules that it needed. Am I wrong ?
Re: Installing mod_perl a dozen times ...
Posted by Michael J Schout <ms...@gkg.net>.
I guess I will chime in on this since we have dealt with this very same issue.
The problem that we have is that there are a handful of production boxes, a
handful of staging boxes (testing release candidates etc), and a handful of
developer boxes.
Our goal was to make it as easy as possible to get the machines in a state
containing the exact versions of the required CPAN packages, perl, mod_perl,
apache, system libraries etc.
One idea that has been mentioned here was to use CPAN shell to create a Bundle
of the modules you need. My personal experience was that this just didnt work
quite right :). CPAN bundles only appear to care tha tyou have *at least* a
particular version of a package installed. But if your system depends on a
previous version than the latest and greatest of a particular package, you are
pretty much out of luck there as far as I can tell. YMMV :).
We also needed the ability to apply minor patches to a few modules / packages.
CPAN shell didnt seem to be able to help us here. Also, CPAN shell requires a
certain degree of user interaction to install all of the modules we need.
The other problem was that several machines in the rotation get "loaned out" to
other projects, and when we get them back, we dont know what state things are
in on the machine. So we needed to be able to (relatively) quickly re-install
all of the packages we needed on the machines if needed.
What we finally settle on was to use RPMs to do it all. This allowed us to get
exact versions of everything we needed, and we could blast new bits onto
machines with a very simple one-liner:
rpm -Uvh --force ftp://somehost/pub/proj/\*.rpm
This was much faster than searching CPAN, and requires no human interaction.
The only caveat here is that you need to maintain a set of RPMS. Luckily this
is not to terribly difficult. We already had RPMS of apache+mod_perl, perl,
etc. The tricky part is how can we make RPMS easily out of all of those CPAN
modules we were using? Luckily someone has already done this :). On CPAN,
Jochen Wiedmann has a script called "makerpm.pl". You can download this file
from CPAN, copy it to /usr/src/redhat/SOURCES, cd to that directory, and make a
new RPM/SRPM pair like this:
makerpm.pl --specs --source Apache-AuthTicket-0.20.tar.gz
Then, build the rpm/srpm from the .spec file you just made:
rpm -ba -v Apache-AuthTicket.spec
And thats it. Pretty simple.
Of course you are limited to machines that can use .rpm here, but you can
probably adopt a similar strategy for other package management systems.
Anyways, this is how we solved this problem. Now with this in place, I just
run the rpm install from ftp, then load our sorce tree for the particular
project on the machine straight from CVS, and start working. Total setup of a
new machine takes about 5-10 minutes tops :).
Mike