motd file=file "message of the day" to display to clients on connect.
Usually contains site information and any legal notices. Default no motd file.
See moduile specific comment.
pid file=file If the file exists, the rsync daemon aborts to prevent multiple instances from running.
Left over versions may be a reason that rsyncd does not to start.
| port=ppppp Required when run by non-root user.
When run by inetd since it is defined in /etc/services,
Superseded by --port (default 873 (priviledged)).
| IPaddress=ddd.ddd.ddd.ddd ignored if run by inetd,,
superseded by --address
| socket options=oooo see setsockopt(),
Superceeded by --sockopts
| Module Specific Parameters
A "module" exports a directory tree as a symbolic name with restrictions, permissions etc.
| [moduleName] (no slash)
| path=directory directory in the daemon's filesystem available to the client by referencing moduleName.
Required for each module.
| comment=string description displayed when clients list available modules using
rsync host::
| use chroot=true | false If true, rsyncd will chroot
to directory
This protects against possible implementation security holes.
Disadvantages: - requires super-user privileges,
- not able to follow symbolic links outside
of the new root path or are absolute and of
- complicating the preservation of users and groups by name (see below).
Specify a dot-dir as directory
to guard against unintended library loading (since those absolute
paths will not be inside the transfer hierarchy, and permits setup of libraries for the chroot that are outside of the
transfer.
For example, the client specifies "/var/rsync/./module1" chroot will go to
/var/rsync and set the inside-chroot path to "/module1".
Without the dot-dir, the chroot would have used the whole path, and the
inside-chroot path would have been "/".
When false or the inside-chroot path is not "/", rsync will:
- munge symlinks by default for security reasons (see munge symlinks to turn this off)
- cause client usage of an absolute path to be relative to the module's path
- remove ".." in the client's path specification if they would escape the module hierarchy.
The default is true.
When use chroot is enabled, rsync will not attempt to map users and groups
by name (by default), but copies IDs as though --numeric-ids had
been specified
danger! if IDs are not the same names this will cause different owners on destination system.
To enable name-mapping, rsync needs to be able to
use the standard library functions for looking up names and IDs (i.e.
getpwuid() , getgrgid() , getpwname() , and getgrnam()
).
The rsync process in the chroot hierarchy needs access to the resources
used by these library functions (traditionally /etc/passwd and
/etc/group, but perhaps additional dynamic libraries as well).
Copy the necessary resources into the module's chroot area, protect them through the OS's user/group or ACL settings (to
prevent the rsync module's user from being able to change them), and then
hide them from the user's view via exclude.).
At that point it will be safe to enable the mapping of users and groups by name using the numeric ids daemon parameter
Custom user/group information in the chroot area is optional that is different from your normal system. For example,
abbreviatons for users and groups.
| numeric ids=true|false Enabling this parameter disables the mapping
of users and groups by name for the current daemon module, preventing
the daemon from loading user/group-related files or libraries.
This makes the transfer behave as if the client had passed
--numeric-ids .
Default : for chroot modules enabled
Ensure that the module has the resources to translate names, and that it is not possible for a user to replace them.
| munge symlinks = true|false modify incoming symlinks to make them unusable but recoverable (see below).
Protect files from user trickery when daemon module is writable.
Default when "use chroot" is false and the inside-chroot path is "/".
If munge symlinks disabled on a daemon that is not read-only, there
are security issues a user can perform with uploaded symlinks to access
daemon-excluded items if "use chroot"
is off, rsync can show or change data that
is outside the module's path (as access-permissions allow).
Symlinks are prefixed with /rsyncd-munged/ preventing the links from being used
as long as that directory does not exist.
When enabled,rsync aborts if that path is a directory or a symlink to a directory.
When using munge symlinks in a chroot area with an inside-chroot path of "/",
add /rsyncd-munged/ to the excludes for the module so a user can't create it.
No attempt is made to verify that any pre-existing symlinks in
the module's hierarchy are as safe (unless, of course, it just copied in the whole hierarchy).
When setting up an rsync daemon on a new area or locally,
add symlinks, manually protect your symlinks from being abused by prefixing "/rsyncd-munged/" to the start of
every symlink's value. munge-symlinks is a perl script in the support directory that adds or removes
this prefix from symlinks.
When munge symlinks is disabled on a writable module and "use chroot" is off
(or the inside-chroot path is not "/"),
incoming symlinks will be modified to drop a leading slash and to remove ".."
path elements that rsync believes will allow a symlink to escape the module's
hierarchy. There are ways to work around this!
| charset specifies the name of the character set in which the
module's filenames are stored. If the client uses an --iconv option,
the daemon will use the value of the "charset" parameter regardless of the
character set the client actually passed. This allows the daemon to
support charset conversion in a chroot module without extra files in the
chroot area, and also ensures that name-translation is done in a consistent
manner.
If charset is not set, the --iconv option is
refused, just as if "iconv" had been specified via "refuse options".
To force users to always use --iconv for a particular
module, add "no-iconv" to the "refuse options" parameter.
| max connections
specify the maximum number of simultaneous connections
Any clients connecting when the maximum has been reached will receive a
message telling them to try later. The default is 0, which means no limit.
A negative value disables the module.
See also the "lock file" parameter.
| log file log messages to the file rather
than using syslog.
The file is opened before chroot() is called, allowing it to be placed outside
the transfer. If set on a per-module basis instead of
globally, the global log will still contain any authorization failures
or config-file error messages.
If the daemon fails to open the log file, it will use syslog and output an error about the failure.
| syslog facility
Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0,
local1, local2, local3, local4, local5, local6 and local7.
The default is daemon.
| max verbosity| to the log . default 1, allows the client to request one level of verbosity.
| lock file to support the "max connections" parameter. Default /var/run/rsyncd.lock.
| read only if true clients are not able to upload files.
If false uploads will be possible if file permissions on the daemon side allow them.
Default all modules read only.
| write only true: downloads are prohibited .
false :downloads will be possible if file permissions on the daemon side allow them.
default disabled.
| list this module should be listed when the client asks for a listing of available modules.
Setting this to false creates hidden modules.
Default listable.
| uid=uname or ID# to assume when the started as root.
In combination with the "gid" parameter this determines what
file permissions are available. default -2, normally the user "nobody".
| gid| group name or group ID that file transfers to and from that module should take place as when the daemon
was run as root. complements "uid" . The default is gid -2,
normally the group "nobody".
| fake super causes the daemon to behave as if the --fake-user command-line option had
been specified.
Allows full attributes of a file to be stored without having to have the daemon actually running as root.
| filter The daemon has its own filter chain that determines what files
it will let the client access. This chain is not sent to the client and is
independent of any filters the client may have specified.
Files excluded by daemon-excluded files are treated as non-existent
if the client tries to pull them, are skipped with an error message if the
client tries to push them (triggering exit code 23), and are never deleted from
the module.
filters prevent clients from accessing with private administrative files, such as files you may add to
support uid/gid name translations.
The daemon filter chain is built from thefilter,include from,include,exclude from, andexclude parameters, in that order of priority. Anchored
patterns are anchored at the root of the module. To prevent access to an
entire subtree, , "/secret", exclude everything in the
subtree; using a triple-star pattern like "/secret/***".
The "filter" parameter takes a space-separated list of daemon filter rules,
It will split a token at an internal space in a rule (e.g. "- /foo - /bar" is parsed as two rules).
specify one or more merge-file rules using the normal syntax.
Only one "filter" parameter can
apply to a given module in the config file, so put all the rules you want in a
single parameter. Note that per-directory merge-file rules do not provide as
much protection as global rules, but they can be used to make --delete work
better during a client download operation if the per-dir merge files are
included in the transfer and the client requests that they be used.
| exclude takes a space-separated list of daemon
exclude patterns. As with the client --exclude option, patterns can be
qualified with "- " or "+ " to explicitly indicate exclude/include. Only one
"exclude" parameter can apply to a given module. See the "filter" parameter
for a description of how excluded files affect the daemon.
| include| Use an "include" to override the effects of the "exclude"
parameter. Only one "include" parameter can apply to a given module. See the
"filter" parameter for a description of how excluded files affect the daemon.
| exclude from| name of a file
on the daemon that contains daemon exclude patterns, one per line. Only one
"exclude from" parameter can apply to a given module; if you have multiple
exclude-from files, you can specify them as a merge file in the "filter"
parameter. See the "filter" parameter for a description of how excluded files
affect the daemon.
| include from| Analogue of "exclude from" for a file of daemon include
patterns. Only one "include from" parameter can apply to a given module. See
the "filter" parameter for a description of how excluded files affect the
daemon.
| incoming chmod a set of comma-separated chmod strings that will affect the permissions of all
incoming files (files that are being received by the daemon). These
changes happen after all other permission calculations, and this will
even override destination-default and/or existing permissions when the client does not specify --perms.
See the description of the --chmod rsync option and the chmod(1)
manpage for information on the format of this string.
| outgoing chmod set of comma-separated chmod strings that will affect the permissions of all
outgoing files (files that are being sent out from the daemon). These
changes happen first, making the sent permissions appear to be different
than those stored in the filesystem itself. For instance, you could
disable group write permissions on the server while having it appear to be on to the clients.
See the description of the --chmod rsync option and the chmod(1)
manpage for information on the format of this string.
| auth users a comma and space-separated list of usernames that will be allowed to connect to
this module.
The usernames do not need to exist on the local system.
The usernames may contain shell wildcard characters.
If "auth users" is set then the client will be challenged to supply a
username and password to connect to the module. A challenge response
authentication protocol is used for this exchange. The plain text
usernames and passwords are stored in the file specified by the "secrets file" parameter.
default allow connect without a password (this is called "anonymous rsync").
See also the section entitled "USING RSYNC-DAEMON FEATURES VIA A REMOTE
SHELL CONNECTION" in rsync(1) for information on how handle an
rsyncd.conf-level username that differs from the remote-shell-level
username when using a remote shell to connect to an rsync daemon.
| secrets file name of a file that contains the username:password pairs used for
authenticating this module only consulted if auth users" is specified.
line based and contains username:password pairs separated by a single colon.
The passwords can contain any characters but be warned that many operating systems
limit the length of passwords that can be typed at the client end, passwords longer than 8 characters may not work.
There is no default for the "secrets file" , choose a name (such as /etc/rsyncd.secrets). The file must not be readable
by "other"; see "strict modes".
| strict modes whether or not the permissions on the secrets file will be checked.
true the secrets file must not be readable by any user ID other than the one that the rsync daemon is running under.
false, the check is not performed. The default is true.
was added to accommodate rsync running on the MS Windows
| hosts allow| list of patterns that are matched against a connecting clients
hostname and IP address. If none of the patterns match then the connection is rejected.
Each pattern can be in forms:
-
a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address
of the form a:b:c::d:e:f. In this case the incoming machine's IP address must match exactly.
- an address/mask in the form ipaddr/n where ipaddr is the IP address
and n is the number of one bits in the netmask. All IP addresses which
match the masked IP address will be allowed in.
- an address/mask in the form ipaddr/maskaddr where ipaddr is the
IP address and maskaddr is the netmask in dotted decimal notation for IPv4,
or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP
addresses which match the masked IP address will be allowed in.
- a hostname. The hostname as determined by a reverse lookup will
be matched (case insensitive) against the pattern. Only an exact
match is allowed in.
- a hostname pattern using wildcards. These are matched using the
same rules as normal unix filename matching. If the pattern matches
then the client is allowed in.
Note IPv6 link-local addresses can have a scope in the address specification:
fe80::1%link1
fe80::%link1/64
fe80::%link1/ffff:ffff:ffff:ffff::
You can also combine "hosts allow" with a separate "hosts deny"
parameter. If both parameters are specified then the "hosts allow" parameter is
checked first and a match results in the client being able to
connect. The "hosts deny" parameter is then checked and a match means
that the host is rejected. If the host does not match either the
"hosts allow" or the "hosts deny" patterns then it is allowed to
connect.
The default is no "hosts allow" parameter, which means all hosts can connect.
| hosts deny| list of patterns that are matched against a connecting clients
hostname and IP address. If the pattern matches then the connection is
rejected. See the "hosts allow" parameter for more information.
The default is no "hosts deny" parameter, which means all hosts can connect.
| ignore errors ignores I/O errors when deciding whether to run the delete
phase of the transfer.
Normally rsync skips the --delete step if any
I/O errors have occurred in order to prevent disastrous deletion due
to a temporary resource shortage (no remaining spave) or other I/O error.
| ignore nonreadable| ignore files that are not readable by the user. useful for
public archives that may have some non-readable files among the
directories, and the sysadmin doesn't want those files to be seen at all.
| transfer logging| enables per-file
logging of downloads and uploads in a format somewhat similar to that
used by ftp daemons. The daemon always logs the transfer at the end, so
if a transfer is aborted, no mention will be made in the log file.
To customize the log lines, see the "log format" parameter.
| log format format used for logging file transfers when transfer logging is enabled.
a text string containing embedded single-character escape
sequences prefixed with a percent (%) character. An optional numeric
field width may also be specified between the percent and the escape
letter (e.g. "%-50n %8l %07p").
The default log format is "%o %h [%a] %m (%u) %f %l", and a "%t [%p] "
is always prefixed when using the "log file" parameter.
(A perl script that will summarize this default log format is included
in the rsync source code distribution in the "support" subdirectory:
rsyncstats.)
The single-character escapes that are understood are as follows:
- %a the remote IP address
- %b the number of bytes actually transferred
- %B the permission bits of the file (e.g. rwxrwxrwt)
- %c the total size of the block checksums received for the basis file (only when sending)
- %f the filename (long form on sender; no trailing "/")
- %G the gid of the file (decimal) or "DEFAULT"
- %h the remote host name
- %i an itemized list of what is being updated
- %l the length of the file in bytes
- %L the string " -> SYMLINK", " => HARDLINK", or "" (where
SYMLINK or HARDLINK is a filename)
- %m the module name
- %M the last-modified time of the file
- %n the filename (short form; trailing "/" on dir)
- %o the operation, which is "send", "recv", or "del." (the latter includes the trailing period)
- %p the process ID of this rsync session
- %P the module path
- %t the current date time
- %u the authenticated username or an empty string
- %U the uid of the file (decimal)
For a list of what the characters mean that are output by "%i", see the
--itemize-changes option in the rsync manpage.
Note that some of the logged output changes when talking with older
rsync versions. For instance, deleted files were only output as verbose
messages prior to rsync 2.6.4.
| timeout| override the
clients choice for I/O timeout for this module. Using this parameter you
can ensure that rsync won't wait on a dead client forever. The timeout
is specified in seconds. A value of zero means no timeout and is the
default. A good choice for anonymous rsync daemons may be 600 (giving
a 10 minute timeout).
| refuse options
specify a space-separated list of rsync command line options that will
be refused by your rsync daemon.
You may specify the full option name, its one-letter abbreviation, or a
wild-card string that matches multiple options.
For example, this would refuse --checksum (-c) and all the various
delete options:
refuse options = c delete
The reason the above refuses all delete options is that the options imply
--delete, and implied options are refused just like explicit options.
As an additional safety feature, the refusal of "delete" also refuses
remove-source-files when the daemon is the sender; if you want the latter
without the former, instead refuse "delete-*" -- that refuses all the
delete modes without affecting --remove-source-files.
When an option is refused, the daemon prints an error message and exits.
To prevent all compression when serving files,
you can use "dont compress = *" (see below)
instead of "refuse options = compress" to avoid returning an error to a
client that requests compression.
| dont compress| select
filenames based on wildcard patterns that should not be compressed
when pulling files from the daemon (no analogous parameter exists to
govern the pushing of files to a daemon).
Compression is expensive in terms of CPU usage, so it
is usually good to not try to compress files that won't compress well,
such as already compressed files.
The "dont compress" parameter takes a space-separated list of
case-insensitive wildcard patterns. Any source filename matching one
of the patterns will not be compressed during transfer.
See --skip-compress parameter in the rsync(1) manpage for the list
of file suffixes that are not compressed by default. Specifying a value
for the "dont compress" parameter changes the default when the daemon is
the sender.
| pre-xfer exec
post-xfer exec command to be run before and/or after the transfer.
If the pre-xfer exec command fails, the transfer is aborted before it begins.
The some environment variables are specific to the pre-xfer or the post-xfer :
-
$RSYNC_MODULE_NAME: name of the module being accessed.
-
$RSYNC_MODULE_PATH: path configured for the module.
-
$RSYNC_HOST_ADDR: accessing host's IP address.
-
$RSYNC_HOST_NAME: accessing host's name.
-
$RSYNC_USER_NAME: accessing user's name (empty if no user).
-
$RSYNC_PID: unique number for this transfer.
-
$RSYNC_REQUEST: (pre-xfer only) module/path info specified
by the user (note that the user can specify multiple source files,
so the request can be something like "mod/path1 mod/path2", etc.).
-
$RSYNC_ARG#: (pre-xfer only) pre-request arguments are set
in these numbered values. RSYNC_ARG0 is always "rsyncd", and the last
value contains a single period.
-
$RSYNC_EXIT_STATUS: (post-xfer only) server side's exit value. 0 for a successful run, a positive value for an error that the
server generated, or a -1 if rsync failed to exit properly. Note that an
error that occurs on the client side does not currently get sent to the
server side, so this is not the final exit status for the whole transfer.
-
$RSYNC_RAW_STATUS: (post-xfer only) raw exit value from waitpid()
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |