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.
Re: upgrading mod_perl on production machine
On Wed, 6 Sep 2000, Perrin Harkins wrote: On Wed, 6 Sep 2000, Bill Moseley wrote: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. We use RPMs. Some form of package, even if it's just a tarball, is a good idea. Build it on a different server and then just install it. Having multiple servers really comes in handy here because you can take some off line, upgrade them while the others are live, and then switch. Then your site remains up the whole time. The problem of the tar-ball is that it doesn't know to cleanup previously installed files. Imagine a situation where some module that was previously installed in perl5/5.00503 now installed in perl5/site_perl/5.005 -- You get the problem where the old version is loaded before the new one. Therefore tar-ball is not a good solution, unless you scratch the whole tree a moment before you untar the ball. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: upgrading mod_perl on production machine
Stas Bekman wrote: On Wed, 6 Sep 2000, Perrin Harkins wrote: On Wed, 6 Sep 2000, Bill Moseley wrote: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. We use RPMs. Some form of package, even if it's just a tarball, is a good idea. Build it on a different server and then just install it. Having multiple servers really comes in handy here because you can take some off line, upgrade them while the others are live, and then switch. Then your site remains up the whole time. The problem of the tar-ball is that it doesn't know to cleanup previously installed files. Imagine a situation where some module that was previously installed in perl5/5.00503 now installed in perl5/site_perl/5.005 -- You get the problem where the old version is loaded before the new one. Therefore tar-ball is not a good solution, unless you scratch the whole tree a moment before you untar the ball. Ah - what about this ... install (using tarballs complie target dirs) in a package_name-version_number directory. Then symlink to that dir from where ever you need to. My /usr/local looks like this on some of my production machines: drwxr-xr-x6 root root 4096 Jun 28 16:25 BerkeleyDB.3.1 lrwxrwxrwx1 root root 13 Jul 7 06:21 apache - apache1.3.12/ drwxr-xr-x3 root root 4096 Jun 18 22:55 apache1.3.12 drwxr-xr-x2 root bin 4096 Jun 18 23:09 bin drwxr-xr-x2 root root 4096 Jun 18 23:12 include drwxr-xr-x2 root root 4096 Jun 15 18:15 lib lrwxrwxrwx1 root root 30 Sep 2 11:57 mysql - /usr/local/mysql-3.23.23-alpha drwxr-xr-x7 root root 4096 Jul 31 17:28 mysql-3.23.22-alpha drwxr-xr-x7 root root 4096 Sep 2 11:14 mysql-3.23.23-alpha drwxr-xr-x2 root bin 4096 Jun 8 21:42 sbin drwxrwxr-x9 root root 4096 May 29 11:38 ssl I can now roll back any new installs by just changing the symlink, and a tarball of the required dir does the trick. After testing I brought up new versions in the time in takes to make a online command with a few 's in and apache is backup in the time it takes for apache to restart - which depends on the ammount of perl modules it needs to deal with etc ... Greg Cope _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: upgrading mod_perl on production machine
On Thu, 7 Sep 2000, Greg Cope wrote: Stas Bekman wrote: On Wed, 6 Sep 2000, Perrin Harkins wrote: On Wed, 6 Sep 2000, Bill Moseley wrote: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. We use RPMs. Some form of package, even if it's just a tarball, is a good idea. Build it on a different server and then just install it. Having multiple servers really comes in handy here because you can take some off line, upgrade them while the others are live, and then switch. Then your site remains up the whole time. The problem of the tar-ball is that it doesn't know to cleanup previously installed files. Imagine a situation where some module that was previously installed in perl5/5.00503 now installed in perl5/site_perl/5.005 -- You get the problem where the old version is loaded before the new one. Therefore tar-ball is not a good solution, unless you scratch the whole tree a moment before you untar the ball. Ah - what about this ... install (using tarballs complie target dirs) in a package_name-version_number directory. Then symlink to that dir from where ever you need to. Nice. Will work with mysql immediately. Will work with plain Apache if you alter apachectl to invoke -d dir_of_httpd.conf. Since you have compiled thing with a specific path. But not Perl -- remember the @INC thingy? Probably compile on a different machine into the normal /usr/lib/perl5 (or equivalent). Then untar it into a different location on the production machine. When 'ln -sf' mod_perl should see the normal path... I guess the same will work with plain Apache. My /usr/local looks like this on some of my production machines: drwxr-xr-x6 root root 4096 Jun 28 16:25 BerkeleyDB.3.1 lrwxrwxrwx1 root root 13 Jul 7 06:21 apache - apache1.3.12/ drwxr-xr-x3 root root 4096 Jun 18 22:55 apache1.3.12 drwxr-xr-x2 root bin 4096 Jun 18 23:09 bin drwxr-xr-x2 root root 4096 Jun 18 23:12 include drwxr-xr-x2 root root 4096 Jun 15 18:15 lib lrwxrwxrwx1 root root 30 Sep 2 11:57 mysql - /usr/local/mysql-3.23.23-alpha drwxr-xr-x7 root root 4096 Jul 31 17:28 mysql-3.23.22-alpha drwxr-xr-x7 root root 4096 Sep 2 11:14 mysql-3.23.23-alpha drwxr-xr-x2 root bin 4096 Jun 8 21:42 sbin drwxrwxr-x9 root root 4096 May 29 11:38 ssl I can now roll back any new installs by just changing the symlink, and a tarball of the required dir does the trick. After testing I brought up new versions in the time in takes to make a online command with a few 's in and apache is backup in the time it takes for apache to restart - which depends on the ammount of perl modules it needs to deal with etc ... Greg Cope _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
upgrading mod_perl on production machine
Hi, Some basic questions here: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. Is it typical to just do a make install with mod_perl on a running production server, then restart httpd? Or do people tend to take down the server, make install to update the Apache::* files, copy the httpd binary and then restart? And what about perl5.6? Have most people been installing it on existing 5.00503, so that @INC also includes the site_perl/5.005 directories or building a new 5.6 tree and using CPAN autobundle to move and update modules into the new version? Thanks, Bill Moseley mailto:[EMAIL PROTECTED]
Re: upgrading mod_perl on production machine
On Wed, 6 Sep 2000, Bill Moseley wrote: Hi, Some basic questions here: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. Is it typical to just do a make install with mod_perl on a running production server, then restart httpd? Or do people tend to take down the server, make install to update the Apache::* files, copy the httpd binary and then restart? And what about perl5.6? Have most people been installing it on existing 5.00503, so that @INC also includes the site_perl/5.005 directories or building a new 5.6 tree and using CPAN autobundle to move and update modules into the new version? I won't do anything on the live server, but installing RPM, or a similar package tested on another machine. It takes a few seconds to install new stuff (and remove old) and a few more secs to restart the server -- you are done. Another approach is to use CVS, if you have a very fast connection, so you can ensure that all the data will be updated very fast. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: upgrading mod_perl on production machine
On Wed, 6 Sep 2000, Bill Moseley wrote: I hope I didn't miss anything in the Guide at install.html and in control.html, but I was looking for any suggestions on upgrading mod_perl and Perl on a running production machine to limit the amount of down time. We use RPMs. Some form of package, even if it's just a tarball, is a good idea. Build it on a different server and then just install it. Having multiple servers really comes in handy here because you can take some off line, upgrade them while the others are live, and then switch. Then your site remains up the whole time. - Perrin
