rfa.tr

ftam等标准协议服务器和客户端的源代码。

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