Re: Installing mod_perl a dozen times ...
> "ml" == martin langhoff <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG & MIME spoken herehttp://www.khera.org/~vivek/
Re: Installing mod_perl a dozen times ...
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
Re: Installing mod_perl a dozen times ...
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 ...
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 ...
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 ...
martin langhoff <[EMAIL PROTECTED]> 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 -
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
