rsync - May 2002 - controlling what happens to old executables?

We're hoping to switch to updating a large software collection with
rsync.

Sometimes, we'll be using rsync to push security updates, say for setuid
binaries with a security hole.  In this case, we want rsync to get rid
of the old executable, instead of creating a ~ file or whatever.

Sometimes, we'll be using rsync to push updates to programs that people
want to leave running a long time, like a shell.  In this case, we want
the old binary to be kept around so the user doesn't get a segfault or
something (I know, this depends on just how rsync eliminates the old
file).

Is there any way, with stock rsync, that we can control when a replaced
file is left around for a while, and when a replaced file is removed
immediately?

Please note that we may have some of both in the same rsync update.

TIA.

PS: With our current software, all backup files are removed immediately,
unless there's a ".backup" file in the same directory that lists
the
file's name.  In that case, the old file is moved to a directory called
"..." for a week prior to being removed.  So security stuff isn't
treated specially, and shells (for example) are listed in a .backup
file.

-- 
Dan Stromberg                                               UCI/NACS/DCS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20020508/4451575b/attachment.bin

On Wed, May 08, 2002 at 08:49:34AM -0700, Dan Stromberg
wrote:
> We're hoping to switch to updating a large software collection with
> rsync.
> 
> Sometimes, we'll be using rsync to push security updates, say for
setuid
> binaries with a security hole.  In this case, we want rsync to get rid
> of the old executable, instead of creating a ~ file or whatever.
> 
> Sometimes, we'll be using rsync to push updates to programs that people
> want to leave running a long time, like a shell.  In this case, we want
> the old binary to be kept around so the user doesn't get a segfault or
> something (I know, this depends on just how rsync eliminates the old
> file).
Usually what it comes down to is whether or not you're going over NFS.
A single Unix filesystem (on most modern systems) have "last-close
semantics"
which doesn't actually delete an executable until all running programs
have exitted.  NFS version 3 and earlier is stateless so a server can't
tell if there's any programs running on one of the clients, and the next
time the client program has to page something in the program crashes.

> Is there any way, with stock rsync, that we can control when a replaced
> file is left around for a while, and when a replaced file is removed
> immediately?
No, sorry.

> Please note that we may have some of both in the same rsync update.
> 
> TIA.
> 
> PS: With our current software, all backup files are removed immediately,
> unless there's a ".backup" file in the same directory that
lists the
> file's name.  In that case, the old file is moved to a directory called
> "..." for a week prior to being removed.  So security stuff
isn't
> treated specially, and shells (for example) are listed in a .backup
> file.
My distribution software also does something similar, and we set it up to
only backup programs that tend to be run overnight when most of our updates
occur.  The software is based on my open source tool Not-So-Bad
Distribution (http://www.bell-labs.com/nsbd) which transfers all changed
files in a package to a scratch directory (using rsync --compare-dest) and
before moving the new files in on top of the old files it renames those
that match a pattern ("backupSubs").

- Dave Dykstra