updating a location-sensitive program on a running production box

updating a location-sensitive program on a running production box

Post by John Wiers » Sat, 30 Jun 2001 08:14:24



It seems that sysadmins must run in to this kind of problem all the time.
There must be a standard answer.  Can anyone point me in the right
direction?

The question:  can I reliably install a new version of some package (say,
perl) on a running production box?  For example, I want to rebuild the perl
distribution with a new set of configuration parameters.  There are two
problems that I see:

1) How to build *and test* a package that has it's installed path hard-coded
into the executable (e.g. perl) without perturbing users who are running the
old version of perl.  I can only think of a few possibilities.
   a) Build the new version to some other install dir.  Test it there.  When
confident that it works, rebuild it to the actual install dir.  Install it
atomically so no one notices that it just changed (how to do this magic?).
   b) Set some global switch (i.e. symlink) which causes all new users of
perl to start using a version installed in a different place.  Eventually
(hopefully) no one will be using the old version of perl.  Then,
build/test/install.  Finally, switch users back.  This is a really flakey
idea.
   c) Build and test on some extra identical machine.  When confident, copy
and install on the actual target machine.
   d) Same as a), but boot everyone off for maintenance when it comes time
to install the new version.

2) How to *atomically* install *all* the files of a package on a running
system?  I have no clue on this one other than some flakey idea related to
1b) above.

Thanks,
John Wiersba

 
 
 

updating a location-sensitive program on a running production box

Post by Juergen Hein » Sat, 30 Jun 2001 09:36:43



> It seems that sysadmins must run in to this kind of problem all the time.
> There must be a standard answer.  Can anyone point me in the right
> direction?

> The question:  can I reliably install a new version of some package (say,
> perl) on a running production box?  For example, I want to rebuild the perl
> distribution with a new set of configuration parameters.  There are two
> problems that I see:

[-]
Yes/no/maybe - for Perl - at times the behaviour of certain constructs
may change, e.g. due to fixed bugs (see Perl 5.6.1) and so existing
scripts are free to stop working.

IMHO the only really safe way is to use the full path, say something
along the line ...
#! /opt/perl6/bin/perl5.6.0
#! /opt/perl6/bin/perl5.6.1
... in ones scripts and to keep older versions around until people
have made sure all *critical* stuff at least works. Some things may
rely on "buggy" behaviour, actually !!

You still can give people a warning ...
"Version ... being phased out in two weeks time"
"Version ... being phased out in one weeks time"
"Don't even think about complaining"
...

Quote:> 1) How to build *and test* a package that has it's installed path hard-coded
> into the executable (e.g. perl) without perturbing users who are running the
> old version of perl.  I can only think of a few possibilities.
>    a) Build the new version to some other install dir.  Test it there.  When
> confident that it works, rebuild it to the actual install dir.  Install it
> atomically so no one notices that it just changed (how to do this magic?).

[-]
Not possible IMHO. You need at least two steps ...
delete o. rename the previous binary to something like blablabla.old
installing the new binary
... and even if your system allows you to just overwrite a busy binary
this may not work, as while writing "something" may try to run it.
[-]
In short - if there's really really no time to get people off the machine,
then I'd just not upgrade anything and should there be a good reason for
an upgrade, then it should be good enough to get people off, too.

Ta',
Juergen

--
\ Real name     : Juergen Heinzl                \       no flames      /