synchronising automount redundant mounts.

From: MacDonell, Dennis (DennisMacDonell@auslig.gov.au)
Date: Sun May 11 2003 - 21:01:54 EDT


Hi,

I have a couple of servers running Tru64 5.1 and 5.0A, that I was hoping to
setup as redundant automounts for user login areas. I looked at rdist, but
it all looked a little complicated, and the documentation seemed to be a
little vague. Then I noticed on the list that other people had some info on
rdist, one mentioned rsync. I setup rsync, but I can' t quite work out how
it can keep the directories the same in the case of deletions. It would
appear to me that when a user deleted a file, which could be on either
server, there is no way of detecting this and propogating it to the other
server. The best I could see that would happen is that the deleted file is
copied back from the server which still retains a copy to the one on which
the file was deleted.

The problem seems to be,
(a) the servers don't know which one has the latest version of a user's
directory,
(b) the sync operations carried out between the servers are done in a
predetermined order, which may lead to the server with the stallest version
trying to update the server with the latest first.
(c) user's can logon a number of machines at the same time, and different
machines may be connected to different servers for the user's home
directory.

What would need to happen is that deleted files have their name changed and
at the same time the mtime of the file is changed. That way you could setup
a system of comparing the dates on existing files, with the dates on the
deleted files. But if the file has been deleted, I can't see how any system
could work out whether the file should be deleted from the other server or
copied from the other server back to the first server.

Dennis

######################################
Dennis Macdonell
Systems Administrator
National Mapping Division, Geoscience Australia
mail: PO Box 2, Belconnen, ACT 2617
email: mcdonell@auslig.gov.au
ph: 61 2 6201 4326
fax: 61 2 6201 4377
######################################



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:18 EDT