Net2/usr/src/contrib/isode/others/rfa/rfa.tr

.\"
.\" RFA - Remote File Access
.\"
.\" rfa.tr : RFA User Manual (run through "roff -ms")
.\"
.\" Contributed by Oliver Wenzel, GMD Berlin, 1990
.\"
.\"
.\" $Header: /f/osi/others/rfa/RCS/rfa.tr,v 7.3 91/02/22 09:28:17 mrose Interim $
.\"
.\" $Log:	rfa.tr,v $
.\" Revision 7.3  91/02/22  09:28:17  mrose
.\" Interim 6.8
.\" 
.\" Revision 7.2  91/01/14  13:54:52  mrose
.\" update
.\" 
Revision 1.1  91/01/04  16:25:50  ow
Initial revision

.\"
.AM
.nr LL 7i
.pl 11i
.nr li 1 1
.nr PD 50
.TL
RFA - Remote File Access

.br
A tool for managing access to files that are distributed at multiple sites
.AU
Oliver Wenzel
GMD - Fokus
Berlin - Germany

.br
Version 1.0

.sp 4
.NH
Introduction
.XS
Introduction
.XE
.LP
This software tool called \fIRemote File
Access\fP (RFA) has been designed to allow access to a set
of files in a UNIX(TM) filesystem that are shared between multiple
sites. It has been created within the VERDI 3 project as a result of our
own requirements for a distributed document and file management system.
Basis for this requirements is the VERDI 3 project which members are
located at two different sites. Both sites of the project share a common
set of documents and files which need to be accessed and modified during
the everyday-project-work. For some time we used the FTAM software to
exchange files between the two sites, but after the number of shared
files and transfer operations grew, very often questions like
.ds is \(bu
.RS
.IP \*(is 3
at which site the up-to-date (master) version of the file is
located ?
.IP \*(is 3
is the local version up-to-date ?
.IP \*(is 3
is anyone already editing this file ?
.IP \*(is 3
are there any newly created files ?
.RE
.LP
appeared. Using a distributed filesystem like NFS was discussed as
an alternative solution, but this did not seemed to be practicable
because of the very slow communication links between the sites
(9600Bps). Therefore, we tried to build a simple tool to handle theses
questions. So the RFA tool was born and because the project is working
with ISO protocols, we built the tool on top of the ISODE software
package using the remote operation compiler
\fBrosy(1)\fP. Currently the tools only
supports to share files between two sites (because this was our primary
goal), but it should be possible to extend it to support multiple
sites.
.NH
The Model
.XS
The Model
.XE

.NH 2
The Data Model
.XS
The Data Model
.XE
.LP
The Data Model is based on the hierarchical structure of the
UNIX(TM) filesystem. The RFA tools allows to share a subtree of the
hierarchical filesystem structure between (currently) two sites. The
structure of the shared subtree must be identical at both sites. The
local root of the shared subtree may be different at both sites. Subject
of the operation of the RFA tool are the files and directories within
the shared subtree. 
.NH 3
File Version-Time
.XS
File Version-Time
.XE
.LP
A file within a shared subtree exists at the different sites as
different (local) versions of the file. The version-time (state of
modification) of a file version at a site is determined by the
\fBmodification time\fP provided by the
UNIX(TM) system call \fBstat(2)\fP. To
determine which version of file is up-to-date, the youngest version-time
is chosen. This requires that the sites participating in the file
sharing use synchronized clocks. This is necessary because the
modification time is set automatically by the UNIX system using the
local operating system clock. The RFA tool provides an operation to
synchronize the clocks where one of the sites is declared to be the
\fBtime-master\fP which provides the time
to the \fBtime-slave\fP.
.NH 3
RFA File Status
.XS
RFA File Status
.XE
.LP
Each local version of a file that exists within the shared subtree
at a site has a RFA-specific status which is one of:
.IP "MASTER" 15
the file is the up-to-date version of the file and
modifications to the local version of the file are allowed.
.IP "SLAVE" 15
the file is the read-only version of the file and may be
up-to-date but it need not. For each local file with SLAVE status there
must be a MASTER version at the remote site. File version with SLAVE
status will have file write permissions cleared.
.IP "UNREGISTERED" 15
the file not shared and has only local significance. It may
be modified locally.
.LP
.LP
This file status allows to determine which site has the up-to-date
version of a file and is allowed to do modifications to the file. The
site holding a SLAVE version of the file has to request the mastership
before it is allowed to do any modifications. Further, it has to be
assured that the local version of the file at the new MASTER site is
up-to-date. Otherwise the file has to be transferred first. A local
version of a file may change its status during its lifetime (e.g. from
UNREGISTERED to MASTER) as a result of several RFA operations described
later.
.NH 3
File Locking
.XS
File Locking
.XE
.LP
To avoid that a file is modified by multiple users at the MASTER
site or that the mastership is transferred to the remote site while the
local version is under modify-access by a local user, a local version of
a file can be (soft)-locked. Locking of files is only applicable to file
versions with status MASTER or UNREGISTERED.
.LP
Setting the lock flag of a directory has the effect, that the
\fB.rfaexec\fP file is not executed during
a RFA \fBsync\fP or
\fBrsync\fP command. This can be used to
enable the execution of the \fB.rfaexec\fP
file for a period of time (e.g. while doing incomplete modifications to
the source-code when \fB.rfaexec\fP
contains commands for re-compilation).
.NH 3
Transferlevel
.XS
Transferlevel
.XE
.LP
One mode of operation of the RFA tool is to synchronize sets of
local version of files with the remote site. To determine if a file that
is mastered remote should be transferred during this synchronization, a
transferlevel can be associated with each file:
.IP "REQUEST" 15
The file is not transferred automatically during
synchronization. If a new MASTER file is detected at the remote site,
only a local dummy (empty file) is created to indicate the existence of
the file.
.IP "AUTOMATIC" 15
The file is transferred automatically during synchronization
if the local version is not up-to-date. If a new MASTER file is detected
at the remote site, it is transferred.
.NH 2
The Functional Model
.XS
The Functional Model
.XE
.LP
The RFA tools is built using the
\fBClient-Server\fP model of the ISODE
remote operations environment. There is a RFA server (called
\fBros.rfa)\fP at each site which is
started dynamically by the ISODE
\fBtsapd\fP. Most of the RFA commands are
interpreted by the RFA client (called
\fBrfa\fP) which issues a remote operation
to the remote RFA server. The RFA client does not perform a 1-to-1
mapping of its commands onto the remote operations. It uses none, one or
more remote operations to execute a RFA command. The association
establishment is done when the first remote operation is invoked. The
RFA client can operate in an interactive mode or a command mode.
.LP
One of the basic principles of RFA is that modifications to any
files are only performed locally by the RFA client. The remote RFA
server never modifies any file, so no remote file modifications are
possible. The ensure a certain autonomy of the two sites concerning
modifications of their local files.
.NH
The RFA Client
.XS
The RFA Client
.XE
.LP
The RFA client (\fBrfa\fP) provides an
interactive mode and a command mode. The rfa command has the following
syntax:

.DS I 3
rfa [ -u username -p password ] [ -h hostname] [ -q ] 
     [ -c rfa-command ]
.DE
.LP
The name of the host (as defined in the
\fBisoentities\fP database) where the
remote site is located can be specified using the
\fB-h\fP option. Because the RFA client
binds to the remote RFA server with a username that must be valid at the
remote site, the \fB-u\fP and
\fB-p\fP options can be used to specify the
username and the password for the remote site. The
\fB-q\fP option directs
\fBrfa\fP to run in quit-mode, where only
severe errors are reported and no user interaction is performed. Using
the \fB-c\fP option, a command can be
passed to rfa in command mode. This can be any command described
below.
.LP
If the rfa is called without the
\fB-c\fP option, is runs in interactive
mode. The \fBrfa\fP provides the following
commands. A command can be abbreviated with its unambiguous
prefix.
.NH 2
pwd
.XS
pwd
.XE
.LP
During interactive mode, \fBrfa\fP has
a current directory. This directory is relative to the root of the
shared subtree. The \fBpwd\fP command shows
the name of the current working directory relative to the root of the
shared subtree. Initially this is the current working directory of the
UNIX \fBsh(1)\fP where
\fBrfa\fP has been called if it is within
the shared subtree. 
.NH 2
cd
.XS
cd
.XE
.LP
The \fBcd\fP command changes the
current directory of \fBrfa\fP in
interactive mode to the directory given as the first argument. No check
is made if this directory exists. It is not possible to change the
working directory above the root of the shared subtree.
.NH 2
list
.XS
list
.XE
.LP
The \fBlist\fP command provides a
listing of the files within the directories given as the command
arguments. If no argument is given, the current working directory is
listed. The output of the \fBlist\fP
command is similar to the output of the UNIX \fBls
-lg\fP command, e.g.

.DS I 3
-rw-rw-r-- M-A ow       verdi         754 Jul 12 13:59  .sunview
drwxr-xr-x --- ow       verdi         512 Jul 12 14:01  bin
.DE
.LP
The three character field after the file permissions is used to
indicated the different rfa-specific states of the file. The first
character indicates the status of the file, with M 
for master version, S  for slave Version and
-  for unregistered version. The second character is
the lock indicator with an L  indicating that the
file is currently locked and an -  for unlocked. The
third character indicates the transfer mode of the files with
A  for automatic transfer and - 
for transfer on request.
.NH 2
rlist
.XS
rlist
.XE
.LP
The \fBrlist\fP command is similar to
the \fBlist\fP command with the difference
that the files in the directory at the remote site are listed.
.NH 2
lock
.XS
lock
.XE
.LP
The \fBlock\fP command is used to get
a locked local version of the file(s) that are provided as argument(s)
to the command. Only regular files within the shared subtree are valid.
It is not possible to lock directories, links, etc. . If the name of the
file to be locked is a symbolic link, the file referenced by the link is
locked if it is located within the shared subtree.
.LP
The \fBlock\fP command should be used
whenever a file within the shared subtree is modified to ensure that the
local version of the file is a) the master version and b) not currently
under modify-access by another local user.
.LP
If the local version of the files has a SLAVE status, the lock
command will try to get the mastership for the file. Therefore, it first
verifies that the local version is up-to-date, otherwise it transfers
the up-to-date version from the current master, similar to the
\fBgetfile\fP command. After an up-to-date
local version of the requested file exists, a
\fBRequestMaster\fP operation is issued to
the remote site to transfer the mastership. If the file is not locked at
the remote site, the mastership is granted to the local site which then
is the new master. The local lock is set the by setting the
L (ocked) flag in the local files state.
.LP
If the local version of the requested file already is the MASTER
version or is an UNREGISTERED file, it is checked if the file is already
locked by another local user, where the requested lock is rejected.
Otherwise the local lock is set the by setting the
L (ocked) flag in the local files state.
.LP
Because the lock command will be applied in the most cases to a
local version of the file that is already master, it is not necessary to
execute the whole \fBrfa\fP program to do
the local lock. Because the \fBrfa\fP
program includes the whole code needed for the execution of the remote
operations (ISODE stack, etc.), there may be a significant time delay
while loading this huge program. To optimize this, a stand-alone program
called \fBllock\fP is provided which is
able to perform the locking if the local version is the master version.
If \fBllock\fP could perform the local
lock, it exits with exit-code 0. If the file is already locked
locally or an error condition occurred it exits with exit-code 1. If the
local version of the file is not MASTER, it returns 2 which indicates
that the \fBrfa\fP command is needed to
perform the locking.
.NH 2
unlock
.XS
unlock
.XE
.LP
The \fBunlock\fP command is used to
release a lock for a local MASTER version of the file(s) provided as
command argument(s).  If the name of the file to be unlocked is a
symbolic link, the file referenced by the link is unlocked if it is
located within the shared subtree. There is are no checks made if the
file has been locked by the user that performs the unlock operation.
.LP
Similar to the \fBllock\fP command
there exists an \fBlunlock\fP command which
is capable to perform the release of the (always) local locks to avoid
the expensive use of the \fBrfa\fP
command.
.NH 2
master
.XS
master
.XE
.LP
The \fBmaster\fP command can be used
to request that the local version of the file(s) provided as argument(s)
will become the MASTER version.  If the name of the file is a symbolic
link, the file referenced by the link is target of the operation if it
is located within the shared subtree.
.LP
If the local version of the file is in UNREGISTERED status, its
status is set to MASTER if there is no version of the file with MASTER
status at the remote site. This is the way how locally created files
will be introduced into the set of shared files where the creating site
becomes the initial master.
.LP
If the local version of the file is in SLAVE status, then the
mastership for the file is requested from the remote site similar to the
\fBlock\fP command. The write access
permissions of the new local MASTER version are set.
.NH 2
slave
.XS
slave
.XE
.LP
The \fBslave\fP command can be used to
request that the local version of the file(s) provided as argument(s)
will become a SLAVE version. If the name of the file is a symbolic link,
the file referenced by the link is target of the operation if it is
located within the shared subtree.
.LP
If the local version of the file is in UNREGISTERED or MASTER
status, its status is set to SLAVE if there is version of the file with
MASTER status at the remote site. The write access permissions of the
new local SLAVE version are cleared.
.NH 2
unregister
.XS
unregister
.XE
.LP
The \fBunregister\fP command can be
used to request that the local version of the file(s) provided as
argument(s) will become an UNREGISTERED version. If the local version of
the file is locked, this results in an error. If the name of the file is
a symbolic link, the file referenced by the link is target of the
operation if it is located within the shared subtree.
.NH 2
setrequest
.XS
setrequest
.XE
.LP
The \fBsetrequest\fP command is used
to set the transfer mode of the local version of the file(s) provided as
argument(s) to REQUEST mode. If the name of the file is a symbolic link,
the file referenced by the link is target of the operation if it is
located within the shared subtree.
.NH 2
setauto
.XS
setauto
.XE
.LP
The \fBsetauto\fP command is used to
set the transfer mode of the local version of the file(s) provided as
argument(s) to AUTOMATIC mode. If the name of the file is a symbolic
link, the file referenced by the link is target of the operation if it
is located within the shared subtree.
.NH 2
getfile
.XS
getfile
.XE
.LP
The \fBgetfile\fP command is used to
request the transfer of the shared file(s) provided as argument(s). If
the name of the file is a symbolic link, the file referenced by the link
is target of the operation if it is located within the shared
subtree.
.LP
If the remote version of the file is in MASTER status, a local
SLAVE version is created if the file does locally not exist. If a local
SLAVE version already exists, it is updated from the remote MASTER
version.
.LP
If the remote version of the file is in UNREGISTERED status, a
local version of the file with status UNREGISTERED is created if the
file does locally not exist. If a local  version already exists, it is
updated from the remote version.
.LP
The transfer of the file is performed according the version-time
(time of last modification) of the local and remote files. If both the
version-times of both files are equal, no transfer has to be performed
because the SLAVE version is already up-to-date. If the version-time of
the remote MASTER is older that the version-time of the local SLAVE (or
UNREGISTERED) version, an inconsistency has been detected and an error
is reported. Otherwise, the content of the file has to be transmitted to
update the local SLAVE (or UNREGISTERED) version of the file.
.LP
The content of the file can be transferred either in uncompressed
or in compressed mode, depending on the size of the file. The size limit
when compression shall occur can be configured as described in
chapter 5. The compression and decompression is done using
the UNIX(TM) \fBcompress(1)\fP and
\fBuncompress(1)\fP commands.
.LP
Optionally, the old version of the local file will be saved in as a
file with the suffix \fB.bak\fP if the
local file is updated. This option can be configured as described in
chapter 5.
.NH 2
syncdir
.XS
syncdir
.XE
.LP
The \fBsyncdir\fP command is used to
synchronize the files within the directory/ies provided as argument(s)
with their counterparts at the remote site. Here the basic principle is,
that the site executing the \fBsyncdir\fP
command is only synchronizing the local site by applying the following
actions to the list of files that exists at the
\fIremote\fP site within the given
directory:
.ds is \(bu
.RS
.IP \*(is 3
Create a local SLAVE file versions for newly found remote MASTER
version file. This is done according to the transfer mode of the file.
If the transfer mode is set to REQUEST, only a dummy SLAVE version of
file is created which indicates the existence of the file, but does not
have its actual content. Otherwise, the content of the file is
transferred as described with the
\fBgetfile\fP command.
.IP \*(is 3
Update local SLAVE file version with a remote MASTER version if
the transfer mode of the file is AUTOMATIC
.IP \*(is 3
Create local SLAVE sub-directory if a new MASTER sub-directory has
been found at the remote site. By this, the shared subtree will grow in
size. Directories found at the remote site that are in status
UNREGISTERED are \fINOT\fP created
locally.
.IP \*(is 3
Create a local symbolic link if a symbolic link has been found at
the remote site. This is only done if the file referenced by the link is
located within the shared subtree.
.IP \*(is 3
Perform various checks to insure consistency between local and
remote sites views of the files within the directory.
.IP \*(is 3
Removes local SLAVE files if there is no corresponding MASTER file
at the remote site. If there is a UNREGISTERED file at remote, the local
file state is set to UNREGISTERED.
.IP \*(is 3
Execute a existing \fB.rfaexec\fP
file if any file within the directory has been updated and the directory
itself in not LOCKED.
.RE
.LP
To achieve a fully synchronized directory, both sites need to
perform a \fBsyncdir\fP operation for that
directory at periodic times. This will be typically done by creating an
entry into the systems \fBcrontab\fP.
.NH 2
rsyncdir
.XS
rsyncdir
.XE
.LP
The \fBrsyncdir\fP command is very
similar to the \fBsyncdir\fP command, but
performs a recursive synchronization of the whole subtree starting at
the directory/ies provided as argument(s). The same actions are
performed as within the \fBsyncdir\fP
command with an additional actions:
.LP

.ds is \(bu
.RS
.IP \*(is 3
If a MASTER directory is detected at the remote site and the
transfer mode of this directory is set to AUTOMATIC, the directory is
synchronized recursively.   
.IP \*(is 3
It does not follow symbolic links pointing to directories
.RE
.LP
Directories found at the remote site that are in status
UNREGISTERED or don't have transfer mode AUTOMATIC are
\fINOT\fP synchronized recursively. They have
to be updated individually by applying the
\fBsyncdir\fP command.
.LP
Using the \fBrsyncdir\fP command it is
possible to synchronize the whole shared subtree. The configuration
which parts of a subtree at a site belongs to that shared subtree is
done by setting the MASTER status and the transfer level of the files
and directories appropriately.
.NH 2
timesync
.XS
timesync
.XE
.LP
To synchronize the local clocks of the participating sites, the
\fBtimesync\fP command can be used. This
command synchronizes the local clock of the site acting as the
\fBtime slave\fP with the clock of the
\fBtime master\fP site. The command can be
called at both sites to initiate the synchronization. The configuration
of a site to be \fBtime slave\fP or
\fBtime master\fP is described in chapter
5
.NH 2
help
.XS
help
.XE
.LP
The \fBhelp\fP command shows the list
of available command and gives a one-line description of each
command.
.NH 2
quit
.XS
quit
.XE
.LP
Obviously, the \fBquit\fP commands
terminates the \fBrfa\fP session.
.NH
The RFA-EXEC facility
.XS
The RFA-EXEC facility
.XE
.LP
When a directory within the shared subtree is synchronized using
the RFA \fBsync\fP or
\fBrsync\fP commands, in most cases there
are further actions required if any files have been updated, e.g.
issuing a \fBmake\fP command to re-build
the updated software. This can be achieved by RFA's facility to create a
file called \fB.rfaexec\fP in each
directory. This file is executed by
\fBsh(1)\fP every time the directory is
synchronized and minimally one file within the directory has been
updated. The file \fB.rfaexec\fP can be
have executable format (sh, csh, binary) and should have the executed
permission set. When RFA executed this file, it passes the names of the
files that have been updated as arguments to it.
.LP
This facility can be disabled by setting the
\fBrfaexec\fP tailoring option to
\fBoff\fP. Further, it can be disabled for
a single directory by setting the LOCKED status of the directory. This
is useful to prevent re-compilations of software during an unfinished
development cycle. 
.LP
For security reasons, the
\fB.rfaexec\fP file can
\fINOT\fP be registered as MASTER or SLAVE
file. An automatic transfer of this file may cause a user to execute
something during the \fBsync\fP command
which has been "imported" from the remote site. Therefore,
the \fB.rfaexec\fP file is always a local
unregistered file.
.NH
RFA Configuration
.XS
RFA Configuration
.XE
.LP
The configuration of the RFA client
(\fBrfa\fP)  and the RFA server
(\fBros.rfa)\fP server can be tailored at
start time by a configuration file. This file is called
\fBrfatailor\fP and can exist either in the
ISODE's $(ETCDIR) or the RFA specific tailoring directory which is
defined in the \fBconfig.h\fP file of RFA
as \fBRFA_TAILDIR\fP. This file is read by
both the RFA client and server. The file consists of a number of
tailoring statements with the syntax
tailoringOption     =    tailoringValue 
.LP
Lines with comments start with a "#". 
.LP
The options that are valid for both the RFA client and server
are:
.IP "root" 15
the pathname of the root of the shared subtree at the local
site
.IP "time" 15
the role that the local site plays for time synchronization.
Possible values are \fBmaster\fP or
\fBslave\fP.
.LP
The following options are only recognized by the RFA server:
.IP "compress" 15
The limit for the filesize in bytes when compression during
the transfer operation shall occur.
.IP "chmod" 15
determines if the write permissions of local SLAVE files
shall be removed and write permissions to local MASTER and UNREGISTERED
versions shall be set. This requires that user executing the
\fBrfa\fP command is the owner of the file
or the \fBrfa\fP program runs under the
effective user id of root. Possible values are
\fBon\fP and
\fBoff\fP.
.IP "debuglog" 15
enables more detailed logging information to be written to
the RFA logfile \fBrfa.log\fP in the ISODE
logdir. Possible values are \fBon\fP and
\fBoff\fP.  
.LP
The following options are only recognized by the RFA client. They
may additionally be defined on a per-user basis in a file called
\fB.rfarc\fP in the users home
directory.
.IP "host" 15
the name of the remote host. This name must be defined in
the ISODE's \fBisoentities\fP
database.
.IP "user" 15
the username that shall be used to authenticate with the
remote RFA server. This must be a UNIX(TM) login name that is valid
on the remote site.
.IP "password" 15
The password corresponding to the user name. This password
must be the password for the given login name at the remote
site.
.IP "backup" 15
determines if a backup file with suffix
\fB.bak\fP shall be created when a local
file is updated. Possible values are
\fBon\fP and
\fBoff\fP.
.IP "chgrp" 15
determines if the group-id of local SLAVE files shall be set
according to the group-id of the remote MASTER file. This requires that
user executing the \fBrfa\fP command is
member of all groups that may appear or the
\fBrfa\fP program runs under the effective
user id of root. Possible values are
\fBon\fP and
\fBoff\fP.
.IP "chown" 15
determines if the user-id of local SLAVE files shall be set
according to the user-id of the remote MASTER file. This requires that
user executing the \fBrfa\fP command is the
owner of the file or the \fBrfa\fP program
runs under the effective user id of root. Possible values are
\fBon\fP and
\fBoff\fP.
.IP "transfer" 15
the default transfer mode that is set when a file is
registered the first time. Possible values are
\fBauto\fP and
\fBrequest\fP
.IP "clearsuid" 15
determines if the set-uid-on-execution bit of files is
cleared if they are transferred to the remote site.  Possible values are
\fBon\fP and
\fBoff\fP. If RFA runs with effective
user-id of root and \fBchown\fP options is
enabled, \fBclearsuid\fP should be enabled
to avoid that privileged users from one sites are able to gain illegal
privileges at the other site.
.IP "rmslaves" 15
determines if slave files with no remote master file are
deleted during the \fBsync\fP and
\fBrsync\fP command. Possible values are
\fBon\fP and
\fBoff\fP. If a there is a remote
UNREGISTERED file, the status of the local SLAVE file is only changed to
UNREGISTERED. 
.IP "rfaexec" 15
determines if the
\fB.rfaexec\fP files are executed during a
\fBsync\fP or
\fBrsync\fP command. Possible values are
\fBon\fP and
\fBoff\fP. 
.NH
Some Words on User-IDs and Permissions
.XS
Some Words on User-IDs and Permissions
.XE
.LP
In principle, the RFA client runs with the user-id of the user that
invokes the client. The RFA server either runs with the user-id of the
user who owns the server program (as performed by
\fBtsapd(8)\fP), or it runs with the
user-id the invoker has supplied with the bind arguments (a username and
password valid at the remote server host). In the later case
\fBtsapd\fP needs to run with user-id of
root and ros.rfa needs to be owned by root.
.LP
Under certain circumstances, RFA client and server need to do
modification to files which are not owned by the user-id that RFA is
running with, such as
.ds is \(bu
.RS
.IP \*(is 3
changing a files access right (e.g. if it becomes a slave
version)
.IP \*(is 3
changing a files owner of group (e.g. if a local slave is updates
according to a remote master and the
\fBchown\fP and
\fBchmod\fP options are enabled
.RE
.LP
One way to deal with these problems is to disable these facilities
of RFA by setting the \fBchown\fP,
\fBchgrp\fP and
\fBchmod\fP options to
\fBoff\fP. This will be suitable in an
environment where all files within the shared subtree belong to a single
user and only this user runs RFA client and server processes.
.LP
Otherwise, if different users access the files, minimally the
\fBchmod\fP option should be enabled to
avoid modifications to slave files (remember that locking in rfa is
advisory) by making slave files read-only. Further, the
\fBchown\fP and
\fBchgrp\fP options should be enabled if
the users and groups are the same at both sites to maintain the
ownership (and originatorship of modification) across the two sites.
.LP
This can be achieved by running the RFA client and server with the
effective user-id of root (by setting the set-uid-on-execution flag).
The RFA client will set his effective user-id during start-up to his
real user-id and switches back to the effective user-id of root only for
these sections of code where the root permissions are really required to
change the access mode, owner or group of files. Otherwise, the RFA
client run with the effective user-id equal to his real user-id.
.LP
The RFA server changes his effective user-id during start-up to the
user-id provided by the calling client. Like the RFA client, it switches
back to the effective user-id of root only for these sections of code
where the root permissions are really required to change the access mode
of a file.
.LP
If the RFA client and server do not run with effective user-id of
root, the time synchronization command of RFA can only be used, if the
external program \fBrfatime\fP of the RFA
package is installed to run with set-uid root
.NH
What is still missing ...
.XS
What is still missing ...
.XE
.LP
The current version of RFA is a first shot which needs some
completion and extensions.
.ds is \(bu
.RS
.IP \*(is 3
A command like "remote-diff" could be helpful for
resolving inconsistencies.
.IP \*(is 3
The time synchronization only works if the local time of a
\fBtime-slave\fP site can be modified,
which may not hold true in each environment.
.IP \*(is 3
There is a problem with the
\fBchown\fP,
\fBchgrp\fP and
\fBchmod\fP facilities of RFA because the
enabling of them may cause "permission denied" errors if the
RFA does not run with the effective used id of root.
.IP \*(is 3
RFA is only capable to support distribution over two sites, which
should be extended to allow a multiple site configuration. This may
require the redesign of the RFA model and will introduce a new level of
complexity.
.RE