You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Bill Moseley <mo...@hank.org> on 2000/09/06 15:06:28 UTC

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:moseley@hank.org

Re: upgrading mod_perl on production machine

Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org



Re: upgrading mod_perl on production machine

Posted by Stas Bekman <st...@stason.org>.
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-x    6 root     root         4096 Jun 28 16:25 BerkeleyDB.3.1
> lrwxrwxrwx    1 root     root           13 Jul  7 06:21 apache ->
> apache1.3.12/
> drwxr-xr-x    3 root     root         4096 Jun 18 22:55 apache1.3.12
> drwxr-xr-x    2 root     bin          4096 Jun 18 23:09 bin
> drwxr-xr-x    2 root     root         4096 Jun 18 23:12 include
> drwxr-xr-x    2 root     root         4096 Jun 15 18:15 lib
> lrwxrwxrwx    1 root     root           30 Sep  2 11:57 mysql ->
> /usr/local/mysql-3.23.23-alpha
> drwxr-xr-x    7 root     root         4096 Jul 31 17:28
> mysql-3.23.22-alpha
> drwxr-xr-x    7 root     root         4096 Sep  2 11:14
> mysql-3.23.23-alpha
> drwxr-xr-x    2 root     bin          4096 Jun  8 21:42 sbin
> drwxrwxr-x    9 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:stas@stason.org   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:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org



Re: upgrading mod_perl on production machine

Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
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-x    6 root     root         4096 Jun 28 16:25 BerkeleyDB.3.1
lrwxrwxrwx    1 root     root           13 Jul  7 06:21 apache ->
apache1.3.12/
drwxr-xr-x    3 root     root         4096 Jun 18 22:55 apache1.3.12
drwxr-xr-x    2 root     bin          4096 Jun 18 23:09 bin
drwxr-xr-x    2 root     root         4096 Jun 18 23:12 include
drwxr-xr-x    2 root     root         4096 Jun 15 18:15 lib
lrwxrwxrwx    1 root     root           30 Sep  2 11:57 mysql ->
/usr/local/mysql-3.23.23-alpha
drwxr-xr-x    7 root     root         4096 Jul 31 17:28
mysql-3.23.22-alpha
drwxr-xr-x    7 root     root         4096 Sep  2 11:14
mysql-3.23.23-alpha
drwxr-xr-x    2 root     bin          4096 Jun  8 21:42 sbin
drwxrwxr-x    9 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:stas@stason.org   http://apachetoday.com http://jazzvalley.com
> http://singlesheaven.com http://perlmonth.com   perl.org   apache.org



Re: upgrading mod_perl on production machine

Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org



Re: upgrading mod_perl on production machine

Posted by Perrin Harkins <pe...@primenet.com>.
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