Re: Upgrading mod_perl on production machine (again)
On Fri, Jan 19, 2001 at 12:09:54PM -0800, rolf van widenfelt wrote: but, if someone can offer a procedure for setting up two independent httpd+modperl+perl environments on one machine it would be pretty interesting! You can do that but have to give up installing _anything_ into /usr/lib or other global directory. On our systems, we install everything into /packages/run/product-version-info. That way you can copy /packages/run/apache-1.3.12 to /packages/run/apache-1.3.14 and only change Port, Listen and Root and have second copy ready. But note that many Perl modules aren't happy to be linked against libraries in nonsystem locations, so you also have to do some LD_* settings. But it's doable. -- Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/ .project: Perl, mod_perl, DBI, Oracle, auth. WWW servers, XML/XSL, ... Petition for a Software Patent Free Europe http://petition.eurolinux.org
Re: Upgrading mod_perl on production machine (again)
face it, you are trying to perform surgery on a live subject... with all the Makefiles you'll be making, (httpd, modperl, perl...) you're bound to slip on one of them and install over some of your existing stuff. i went thru a conflict like this once, and avoided it by simply getting a second machine, and installing all the new stuff there. but, if someone can offer a procedure for setting up two independent httpd+modperl+perl environments on one machine it would be pretty interesting! (sorry, if this was already outlined in the responses last Sept) -rolf Bill Moseley [EMAIL PROTECTED] writes: This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all).
Re: Upgrading mod_perl on production machine (again)
make 2 directories: /opt/local1 and /opt/local/2 do an original install in /opt/local1, perl http mod_perl what ever packages you need etc. when it is time to upgrade do a new install in /opt/local2 of what you need, run the httpd on an off port, i.e. port 8765, until you get the new stuff working correctly. turn off the old httpd and move the new httpd to port 80, now you have achieved upgrade with a clean name space. when you are sure that everything is working backup /opt/local1 and delete all the files in it. the next upgrade you need to do use /opt/local1 as the build area. marc - Original Message - From: "rolf van widenfelt" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: "Bill Moseley" [EMAIL PROTECTED] Sent: Friday, January 19, 2001 3:09 PM Subject: Re: Upgrading mod_perl on production machine (again) face it, you are trying to perform surgery on a live subject... with all the Makefiles you'll be making, (httpd, modperl, perl...) you're bound to slip on one of them and install over some of your existing stuff. i went thru a conflict like this once, and avoided it by simply getting a second machine, and installing all the new stuff there. but, if someone can offer a procedure for setting up two independent httpd+modperl+perl environments on one machine it would be pretty interesting! (sorry, if this was already outlined in the responses last Sept) -rolf Bill Moseley [EMAIL PROTECTED] writes: This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all).
Upgrading mod_perl on production machine (again)
This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all). What to do in this situation? a) not worry about it, and just make install mod_perl and restart the server and hope all goes well? b) cp -rp /usr/local/lib/perl5 and use symlinks to move between the two? When ready to move, kill httpd, change the perl symlinks for the binary, perl lib, and httpd, and restart? c) setup a new set of perl, httpd, and my application and when ready to go live just change the port number? Or simply put - how would you do this: With one machine I want to upgrade perl to 5.6.0, upgrade your application code, new version of mod_perl, and allow for testing of the new setup for a few weeks, yet only require a few seconds of downtime to switch live (and back again if needed)? Then I wonder which CPAN module I'll forget to install... Bill Moseley mailto:[EMAIL PROTECTED]
Re: Upgrading mod_perl on production machine (again)
Bill Moseley wrote: This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all). What to do in this situation? a) not worry about it, and just make install mod_perl and restart the server and hope all goes well? Hum ignoring problem means that will bite you ! b) cp -rp /usr/local/lib/perl5 and use symlinks to move between the two? When ready to move, kill httpd, change the perl symlinks for the binary, perl lib, and httpd, and restart? This is what I would do. depending on present set up I would install all the above in a "new" location - and then symlink to it. Yup this does mean a few more disk stat's, but means I can roll back most installs very quickly if required. Having said that I have not done it too often on an alien box. Also is the present perl easily simlinkable (i.e the binary and the lib tree). I just play with the --prefix and usually do --prefix=package_version (eg apache_perl_1.3.14 would be a mod_perl apache version 1.3.14). Also you could script the change over if required to be xtra quick (although this is getting silly) I've used this without any issues on Linux boxes for 18 months, but I am very conservative about my perl (i.e I'm still on 5.005_03 and waiting for 5.6.1 ;-) c) setup a new set of perl, httpd, and my application and when ready to go live just change the port number? Or simply put - how would you do this: With one machine I want to upgrade perl to 5.6.0, upgrade your application code, new version of mod_perl, and allow for testing of the new setup for a few weeks, yet only require a few seconds of downtime to switch live (and back again if needed)? Then I wonder which CPAN module I'll forget to install... do a CPAN snapshot bundle of a known good install, and install that - easy no ? Just my 2 euro worth. Greg Bill Moseley mailto:[EMAIL PROTECTED]
Re: Upgrading mod_perl on production machine (again)
Not that I have an answer to this complete problem, but I have had similar situation, so I'll also be interested in the solutions you uncover. I've always handled the support of multiple perl versions by installing new versions of perl using a prefix like /usr/local/perl/5.6.0, etc., (I also place CPAN's build directory under that tree.) This makes it easy to install and test new versions of perl without affecting running applications that have been built against a previous perl version, as well as making it possible to test with specific versions just by referencing the appropriate version in the script's shebang line (or by setting my PATH appropriately when building mod_perl.) Using this method, I symlink the "current default" version of perl and its tools in the standard public directory (/usr/bin or /usr/local/bin). Upgrading mod_perl versions has been a headache though, as I'm similarly hesitant to simply 'make install' new mod_perl releases without being able to test that all of my running applications work correctly. I suppose your idea of archiving the lib tree (/usr/local/perl/5.6.0/lib in my setup) before running the 'make install' so that it's easy to roll back should something fail is prudent. But it still doesn't solve the problem of being able to fully install (in its real final location, not in a private directory...) new versions of mod_perl without affecting stuff that's already running. (Maybe I'm just tilting at windmills in worrying about testing modperl from a private directory install...) So how *do* others handle this upgrade situation? Steve On Tue, 16 Jan 2001, Bill Moseley wrote: This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all). What to do in this situation? a) not worry about it, and just make install mod_perl and restart the server and hope all goes well? b) cp -rp /usr/local/lib/perl5 and use symlinks to move between the two? When ready to move, kill httpd, change the perl symlinks for the binary, perl lib, and httpd, and restart? c) setup a new set of perl, httpd, and my application and when ready to go live just change the port number? Or simply put - how would you do this: With one machine I want to upgrade perl to 5.6.0, upgrade your application code, new version of mod_perl, and allow for testing of the new setup for a few weeks, yet only require a few seconds of downtime to switch live (and back again if needed)? Then I wonder which CPAN module I'll forget to install... Bill Moseley mailto:[EMAIL PROTECTED] =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-= Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ |
Re: Upgrading mod_perl on production machine (again)
From: Steve Reppucci [EMAIL PROTECTED] Date: Tue, 16 Jan 2001 11:02:44 -0500 (EST) Subject: Re: Upgrading mod_perl on production machine (again) I've always handled the support of multiple perl versions by installing new versions of perl using a prefix like /usr/local/perl/5.6.0, etc., (I also place CPAN's build directory under that tree.) This makes it easy to install and test new versions of perl without affecting running applications that have been built against a previous perl version, as well as making it possible to test with specific versions just by referencing the appropriate version in the script's shebang line (or by setting my PATH appropriately when building mod_perl.) That is what I do as well. Plus, I use the prefix arg to build Apache as well, so a new mod_perl/Apache gets installed in a different dir than the current one when I run make install. I then copy over my config files to the new dir, and set up the new Apache to listen on a different port, then test it. Once tested, I point the sym-links for both Apache and perl to the new locations. This is whole process is scripted for me, for both Solaris and AIX, and works great on both. (There are differences in the scripts, though, because of differences in the OS) BTW, for making sure you get all the modules your old perl had, look at the CPAN module, which has a "autobundle" command to create a Bundle file from your old perl installation, that you can then use with your new perl, by doing a "install Bundle::BundleName". David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 How can we (men) possibly use sex to get what we want?? Sex _is_ what we want!!! Dr Frasier Crane
Re: Upgrading mod_perl on production machine (again)
The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. There's no substitute for testing. If it's really important to have a very short down time, you need a similar machine where you can test a new package. Short of that, the symlink suggestions people have made are probably the best you can do. - Perrin
Re: Upgrading mod_perl on production machine (again)
On Tue, 16 Jan 2001, David McCabe wrote: From: Steve Reppucci [EMAIL PROTECTED] I've always handled the support of multiple perl versions by installing new versions of perl using a prefix like /usr/local/perl/5.6.0, etc., (I also place CPAN's build directory under that tree.) That is what I do as well. Plus, I use the prefix arg to build Apache as well, so a new mod_perl/Apache gets installed in a different dir than the current one when I run make install. I then copy over my config files to the new dir, and set up the new Apache to listen on a different port, then test it. Once tested, I point the sym-links for both Apache and perl to the new locations. we go one step further and install perl and other libraries with each version of our application, into say /usr/local/webmail/5.0.0.1 or whatever. that way everything the application depends on is in the version-specific directory. we drive our entire build and install process with make; the whole process is something like this (abbreviated): cvs co Makefile.webmail make -f Makefile.webmail checkout build install rpm checkout pulls all the library and application sources from cvs and scps pre-compiled distributions from a package machine. build compiles everything. install puts it into /usr/local/webmail/version. rpm packages up the installation directory. then to deploy in production, we rpm -i on each machine, and a post-install script flips the symlink to point at the new version. rollback is trivial.
