Imported Upstream version 3.1.2upstream/3.1.2

1 files changed, 1085 insertions, 0 deletions

diff --git a/rsyncd.conf.5 b/rsyncd.conf.5
new file mode 100644
index 00000000..272f20b5
--- /dev/null
+++ b/rsyncd.conf.5
@@ -0,0 +1,1085 @@
+.TH "rsyncd.conf" "5" "21 Dec 2015" "" ""
+.SH "NAME"
+rsyncd.conf \- configuration file for rsync in daemon mode
+.SH "SYNOPSIS"
+
+.PP 
+rsyncd.conf
+.PP 
+.SH "DESCRIPTION"
+
+.PP 
+The rsyncd.conf file is the runtime configuration file for rsync when
+run as an rsync daemon.
+.PP 
+The rsyncd.conf file controls authentication, access, logging and
+available modules.
+.PP 
+.SH "FILE FORMAT"
+
+.PP 
+The file consists of modules and parameters. A module begins with the
+name of the module in square brackets and continues until the next
+module begins. Modules contain parameters of the form \(dq\&name = value\(dq\&.
+.PP 
+The file is line\-based \-\- that is, each newline\-terminated line represents
+either a comment, a module name or a parameter.
+.PP 
+Only the first equals sign in a parameter is significant. Whitespace before
+or after the first equals sign is discarded. Leading, trailing and internal
+whitespace in module and parameter names is irrelevant. Leading and
+trailing whitespace in a parameter value is discarded. Internal whitespace
+within a parameter value is retained verbatim.
+.PP 
+Any line \fBbeginning\fP with a hash (#) is ignored, as are lines containing
+only whitespace. (If a hash occurs after anything other than leading
+whitespace, it is considered a part of the line\(cq\&s content.)
+.PP 
+Any line ending in a \e is \(dq\&continued\(dq\& on the next line in the
+customary UNIX fashion.
+.PP 
+The values following the equals sign in parameters are all either a string
+(no quotes needed) or a boolean, which may be given as yes/no, 0/1 or
+true/false. Case is not significant in boolean values, but is preserved
+in string values.
+.PP 
+.SH "LAUNCHING THE RSYNC DAEMON"
+
+.PP 
+The rsync daemon is launched by specifying the \fB\-\-daemon\fP option to
+rsync.
+.PP 
+The daemon must run with root privileges if you wish to use chroot, to
+bind to a port numbered under 1024 (as is the default 873), or to set
+file ownership.  Otherwise, it must just have permission to read and
+write the appropriate data, log, and lock files.
+.PP 
+You can launch it either via inetd, as a stand\-alone daemon, or from
+an rsync client via a remote shell.  If run as a stand\-alone daemon then
+just run the command \(dq\&\fBrsync \-\-daemon\fP\(dq\& from a suitable startup script.
+.PP 
+When run via inetd you should add a line like this to /etc/services:
+.PP 
+.nf 
+  rsync           873/tcp
+.fi 
+
+.PP 
+and a single line something like this to /etc/inetd.conf:
+.PP 
+.nf 
+  rsync   stream  tcp     nowait  root   /usr/bin/rsync rsyncd \-\-daemon
+.fi 
+
+.PP 
+Replace \(dq\&/usr/bin/rsync\(dq\& with the path to where you have rsync installed on
+your system.  You will then need to send inetd a HUP signal to tell it to
+reread its config file.
+.PP 
+Note that you should \fBnot\fP send the rsync daemon a HUP signal to force
+it to reread the \f(CWrsyncd.conf\fP file. The file is re\-read on each client
+connection.
+.PP 
+.SH "GLOBAL PARAMETERS"
+
+.PP 
+The first parameters in the file (before a [module] header) are the
+global parameters.
+Rsync also allows for the use of a \(dq\&[global]\(dq\& module name to indicate the
+start of one or more global\-parameter sections (the name must be lower case).
+.PP 
+You may also include any module parameters in the global part of the
+config file in which case the supplied value will override the
+default for that parameter.
+.PP 
+You may use references to environment variables in the values of parameters.
+String parameters will have %VAR% references expanded as late as possible (when
+the string is used in the program), allowing for the use of variables that
+rsync sets at connection time, such as RSYNC_USER_NAME.  Non\-string parameters
+(such as true/false settings) are expanded when read from the config file.  If
+a variable does not exist in the environment, or if a sequence of characters is
+not a valid reference (such as an un\-paired percent sign), the raw characters
+are passed through unchanged.  This helps with backward compatibility and
+safety (e.g. expanding a non\-existent %VAR% to an empty string in a path could
+result in a very unsafe path).  The safest way to insert a literal % into a
+value is to use %%.
+.PP 
+.IP "\fBmotd file\fP"
+This parameter allows you to specify a
+\(dq\&message of the day\(dq\& to display to clients on each connect. This
+usually contains site information and any legal notices. The default
+is no motd file.
+This can be overridden by the \fB\-\-dparam=motdfile=FILE\fP
+command\-line option when starting the daemon.
+.IP 
+.IP "\fBpid file\fP"
+This parameter tells the rsync daemon to write
+its process ID to that file.  If the file already exists, the rsync
+daemon will abort rather than overwrite the file.
+This can be overridden by the \fB\-\-dparam=pidfile=FILE\fP
+command\-line option when starting the daemon.
+.IP 
+.IP "\fBport\fP"
+You can override the default port the daemon will listen on
+by specifying this value (defaults to 873).  This is ignored if the daemon
+is being run by inetd, and is superseded by the \fB\-\-port\fP command\-line option.
+.IP 
+.IP "\fBaddress\fP"
+You can override the default IP address the daemon
+will listen on by specifying this value.  This is ignored if the daemon is
+being run by inetd, and is superseded by the \fB\-\-address\fP command\-line option.
+.IP 
+.IP "\fBsocket options\fP"
+This parameter can provide endless fun for people
+who like to tune their systems to the utmost degree. You can set all
+sorts of socket options which may make transfers faster (or
+slower!). Read the man page for the 
+\f(CWsetsockopt()\fP
+system call for
+details on some of the options you may be able to set. By default no
+special socket options are set.  These settings can also be specified
+via the \fB\-\-sockopts\fP command\-line option.
+.IP 
+.IP "\fBlisten backlog\fP"
+You can override the default backlog value when the
+daemon listens for connections.  It defaults to 5.
+.IP 
+.SH "MODULE PARAMETERS"
+
+.PP 
+After the global parameters you should define a number of modules, each
+module exports a directory tree as a symbolic name. Modules are
+exported by specifying a module name in square brackets [module]
+followed by the parameters for that module.
+The module name cannot contain a slash or a closing square bracket.  If the
+name contains whitespace, each internal sequence of whitespace will be
+changed into a single space, while leading or trailing whitespace will be
+discarded.
+Also, the name cannot be \(dq\&global\(dq\& as that exact name indicates that
+global parameters follow (see above).
+.PP 
+As with GLOBAL PARAMETERS, you may use references to environment variables in
+the values of parameters.  See the GLOBAL PARAMETERS section for more details.
+.PP 
+.IP "\fBcomment\fP"
+This parameter specifies a description string
+that is displayed next to the module name when clients obtain a list
+of available modules. The default is no comment.
+.IP 
+.IP "\fBpath\fP"
+This parameter specifies the directory in the daemon\(cq\&s
+filesystem to make available in this module.  You must specify this parameter
+for each module in \f(CWrsyncd.conf\fP.
+.IP 
+You may base the path\(cq\&s value off of an environment variable by surrounding
+the variable name with percent signs.  You can even reference a variable
+that is set by rsync when the user connects.
+For example, this would use the authorizing user\(cq\&s name in the path:
+.IP 
+.nf 
+    path = /home/%RSYNC_USER_NAME% 
+.fi 
+
+.IP 
+It is fine if the path includes internal spaces \-\- they will be retained
+verbatim (which means that you shouldn\(cq\&t try to escape them).  If your final
+directory has a trailing space (and this is somehow not something you wish to
+fix), append a trailing slash to the path to avoid losing the trailing
+whitespace.
+.IP 
+.IP "\fBuse chroot\fP"
+If \(dq\&use chroot\(dq\& is true, the rsync daemon will chroot
+to the \(dq\&path\(dq\& before starting the file transfer with the client.  This has
+the advantage of extra protection against possible implementation security
+holes, but it has the disadvantages of requiring super\-user privileges,
+of not being able to follow symbolic links that are either absolute or outside
+of the new root path, and of complicating the preservation of users and groups
+by name (see below).
+.IP 
+As an additional safety feature, you can specify a dot\-dir in the module\(cq\&s
+\(dq\&path\(dq\& to indicate the point where the chroot should occur.  This allows rsync
+to run in a chroot with a non\-\(dq\&/\(dq\& path for the top of the transfer hierarchy.
+Doing this guards against unintended library loading (since those absolute
+paths will not be inside the transfer hierarchy unless you have used an unwise
+pathname), and lets you setup libraries for the chroot that are outside of the
+transfer.  For example, specifying \(dq\&/var/rsync/./module1\(dq\& will chroot to the
+\(dq\&/var/rsync\(dq\& directory and set the inside\-chroot path to \(dq\&/module1\(dq\&.  If you
+had omitted the dot\-dir, the chroot would have used the whole path, and the
+inside\-chroot path would have been \(dq\&/\(dq\&.
+.IP 
+When \(dq\&use chroot\(dq\& is false or the inside\-chroot path is not \(dq\&/\(dq\&, rsync will:
+(1) munge symlinks by
+default for security reasons (see \(dq\&munge symlinks\(dq\& for a way to turn this
+off, but only if you trust your users), (2) substitute leading slashes in
+absolute paths with the module\(cq\&s path (so that options such as
+\fB\-\-backup\-dir\fP, \fB\-\-compare\-dest\fP, etc. interpret an absolute path as
+rooted in the module\(cq\&s \(dq\&path\(dq\& dir), and (3) trim \(dq\&..\(dq\& path elements from
+args if rsync believes they would escape the module hierarchy.
+The default for \(dq\&use chroot\(dq\& is true, and is the safer choice (especially
+if the module is not read\-only).
+.IP 
+When this parameter is enabled, the \(dq\&numeric\-ids\(dq\& option will also default to
+being enabled (disabling name lookups).  See below for what a chroot needs in
+order for name lookups to succeed.
+.IP 
+If you copy library resources into the module\(cq\&s chroot area, you
+should protect them through your OS\(cq\&s normal user/group or ACL settings (to
+prevent the rsync module\(cq\&s user from being able to change them), and then
+hide them from the user\(cq\&s view via \(dq\&exclude\(dq\& (see how in the discussion of
+that parameter).  At that point it will be safe to enable the mapping of users
+and groups by name using this \(dq\&numeric ids\(dq\& daemon parameter.
+.IP 
+Note also that you are free to setup custom user/group information in the
+chroot area that is different from your normal system.  For example, you
+could abbreviate the list of users and groups.
+.IP 
+.IP "\fBnumeric ids\fP"
+Enabling this parameter disables the mapping
+of users and groups by name for the current daemon module.  This prevents
+the daemon from trying to load any user/group\-related files or libraries.
+This enabling makes the transfer behave as if the client had passed
+the \fB\-\-numeric\-ids\fP command\-line option.  By default, this parameter is
+enabled for chroot modules and disabled for non\-chroot modules.
+Also keep in mind that uid/gid preservation requires the module to be
+running as root (see \(dq\&uid\(dq\&) or for \(dq\&fake super\(dq\& to be configured.
+.IP 
+A chroot\-enabled module should not have this parameter enabled unless you\(cq\&ve
+taken steps to ensure that the module has the necessary resources it needs
+to translate names, and that it is not possible for a user to change those
+resources.  That includes being the code being able to call functions like
+\f(CWgetpwuid()\fP
+, 
+\f(CWgetgrgid()\fP
+, 
+\f(CWgetpwname()\fP
+, and 
+\f(CWgetgrnam()\fP
+).
+You should test what libraries and config files are required for your OS
+and get those setup before starting to test name mapping in rsync.
+.IP 
+.IP "\fBmunge symlinks\fP"
+This parameter tells rsync to modify
+all symlinks in the same way as the (non\-daemon\-affecting)
+\fB\-\-munge\-links\fP command\-line option (using a method described below).
+This should help protect your files from user trickery when
+your daemon module is writable.  The default is disabled when \(dq\&use chroot\(dq\&
+is on and the inside\-chroot path is \(dq\&/\(dq\&, otherwise it is enabled.
+.IP 
+If you disable this parameter on a daemon that is not read\-only, there
+are tricks that a user can play with uploaded symlinks to access
+daemon\-excluded items (if your module has any), and, if \(dq\&use chroot\(dq\&
+is off, rsync can even be tricked into showing or changing data that
+is outside the module\(cq\&s path (as access\-permissions allow).
+.IP 
+The way rsync disables the use of symlinks is to prefix each one with
+the string \(dq\&/rsyncd\-munged/\(dq\&.  This prevents the links from being used
+as long as that directory does not exist.  When this parameter is enabled,
+rsync will refuse to run if that path is a directory or a symlink to
+a directory.  When using the \(dq\&munge symlinks\(dq\& parameter in a chroot area
+that has an inside\-chroot path of \(dq\&/\(dq\&, you should add \(dq\&/rsyncd\-munged/\(dq\&
+to the exclude setting for the module so that
+a user can\(cq\&t try to create it.
+.IP 
+Note:  rsync makes no attempt to verify that any pre\-existing symlinks in
+the module\(cq\&s hierarchy are as safe as you want them to be (unless, of
+course, it just copied in the whole hierarchy).  If you setup an rsync
+daemon on a new area or locally add symlinks, you can manually protect your
+symlinks from being abused by prefixing \(dq\&/rsyncd\-munged/\(dq\& to the start of
+every symlink\(cq\&s value.  There is a perl script in the support directory
+of the source code named \(dq\&munge\-symlinks\(dq\& that can be used to add or remove
+this prefix from your symlinks.
+.IP 
+When this parameter is disabled on a writable module and \(dq\&use chroot\(dq\& is off
+(or the inside\-chroot path is not \(dq\&/\(dq\&),
+incoming symlinks will be modified to drop a leading slash and to remove \(dq\&..\(dq\&
+path elements that rsync believes will allow a symlink to escape the module\(cq\&s
+hierarchy.  There are tricky ways to work around this, though, so you had
+better trust your users if you choose this combination of parameters.
+.IP 
+.IP "\fBcharset\fP"
+This specifies the name of the character set in which the
+module\(cq\&s filenames are stored.  If the client uses an \fB\-\-iconv\fP option,
+the daemon will use the value of the \(dq\&charset\(dq\& 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 the \(dq\&charset\(dq\& parameter is not set, the \fB\-\-iconv\fP option is
+refused, just as if \(dq\&iconv\(dq\& had been specified via \(dq\&refuse options\(dq\&.
+.IP 
+If you wish to force users to always use \fB\-\-iconv\fP for a particular
+module, add \(dq\&no\-iconv\(dq\& to the \(dq\&refuse options\(dq\& parameter.  Keep in mind
+that this will restrict access to your module to very new rsync clients.
+.IP 
+.IP "\fBmax connections\fP"
+This parameter allows you to
+specify the maximum number of simultaneous connections you will allow.
+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 \(dq\&lock file\(dq\& parameter.
+.IP 
+.IP "\fBlog file\fP"
+When the \(dq\&log file\(dq\& parameter is set to a non\-empty
+string, the rsync daemon will log messages to the indicated file rather
+than using syslog. This is particularly useful on systems (such as AIX)
+where 
+\f(CWsyslog()\fP
+doesn\(cq\&t work for chrooted programs.  The file is
+opened before 
+\f(CWchroot()\fP
+is called, allowing it to be placed outside
+the transfer.  If this value is set on a per\-module basis instead of
+globally, the global log will still contain any authorization failures
+or config\-file error messages.
+.IP 
+If the daemon fails to open the specified file, it will fall back to
+using syslog and output an error about the failure.  (Note that the
+failure to open the specified log file used to be a fatal error.)
+.IP 
+This setting can be overridden by using the \fB\-\-log\-file=FILE\fP or
+\fB\-\-dparam=logfile=FILE\fP command\-line options.  The former overrides
+all the log\-file parameters of the daemon and all module settings.
+The latter sets the daemon\(cq\&s log file and the default for all the
+modules, which still allows modules to override the default setting.
+.IP 
+.IP "\fBsyslog facility\fP"
+This parameter allows you to
+specify the syslog facility name to use when logging messages from the
+rsync daemon. You may use any standard syslog facility name which is
+defined on your system. 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.  This setting has no effect if the \(dq\&log file\(dq\& setting is a
+non\-empty string (either set in the per\-modules settings, or inherited
+from the global settings).
+.IP 
+.IP "\fBmax verbosity\fP"
+This parameter allows you to control
+the maximum amount of verbose information that you\(cq\&ll allow the daemon to
+generate (since the information goes into the log file). The default is 1,
+which allows the client to request one level of verbosity.
+.IP 
+This also affects the user\(cq\&s ability to request higher levels of \fB\-\-info\fP and
+\fB\-\-debug\fP logging.  If the max value is 2, then no info and/or debug value
+that is higher than what would be set by \fB\-vv\fP will be honored by the daemon
+in its logging.  To see how high of a verbosity level you need to accept for a
+particular info/debug level, refer to \(dq\&rsync \-\-info=help\(dq\& and \(dq\&rsync \-\-debug=help\(dq\&.
+For instance, it takes max\-verbosity 4 to be able to output debug TIME2 and FLIST3.
+.IP 
+.IP "\fBlock file\fP"
+This parameter specifies the file to use to
+support the \(dq\&max connections\(dq\& parameter. The rsync daemon uses record
+locking on this file to ensure that the max connections limit is not
+exceeded for the modules sharing the lock file.
+The default is \f(CW/var/run/rsyncd.lock\fP.
+.IP 
+.IP "\fBread only\fP"
+This parameter determines whether clients
+will be able to upload files or not. If \(dq\&read only\(dq\& is true then any
+attempted uploads will fail. If \(dq\&read only\(dq\& is false then uploads will
+be possible if file permissions on the daemon side allow them. The default
+is for all modules to be read only.
+.IP 
+Note that \(dq\&auth users\(dq\& can override this setting on a per\-user basis.
+.IP 
+.IP "\fBwrite only\fP"
+This parameter determines whether clients
+will be able to download files or not. If \(dq\&write only\(dq\& is true then any
+attempted downloads will fail. If \(dq\&write only\(dq\& is false then downloads
+will be possible if file permissions on the daemon side allow them.  The
+default is for this parameter to be disabled.
+.IP 
+.IP "\fBlist\fP"
+This parameter determines whether this module is
+listed when the client asks for a listing of available modules.  In addition,
+if this is false, the daemon will pretend the module does not exist
+when a client denied by \(dq\&hosts allow\(dq\& or \(dq\&hosts deny\(dq\& attempts to access it.
+Realize that if \(dq\&reverse lookup\(dq\& is disabled globally but enabled for the
+module, the resulting reverse lookup to a potentially client\-controlled DNS
+server may still reveal to the client that it hit an existing module.
+The default is for modules to be listable.
+.IP 
+.IP "\fBuid\fP"
+This parameter specifies the user name or user ID that
+file transfers to and from that module should take place as when the daemon
+was run as root. In combination with the \(dq\&gid\(dq\& parameter this determines what
+file permissions are available. The default when run by a super\-user is to
+switch to the system\(cq\&s \(dq\&nobody\(dq\& user.  The default for a non\-super\-user is to
+not try to change the user.  See also the \(dq\&gid\(dq\& parameter.
+.IP 
+The RSYNC_USER_NAME environment variable may be used to request that rsync run
+as the authorizing user.  For example, if you want a rsync to run as the same
+user that was received for the rsync authentication, this setup is useful:
+.IP 
+.nf 
+    uid = %RSYNC_USER_NAME%
+    gid = * 
+.fi 
+
+.IP 
+.IP "\fBgid\fP"
+This parameter specifies one or more group names/IDs that will be
+used when accessing the module.  The first one will be the default group, and
+any extra ones be set as supplemental groups.  You may also specify a \(dq\&*\(dq\& as
+the first gid in the list, which will be replaced by all the normal groups for
+the transfer\(cq\&s user (see \(dq\&uid\(dq\&).  The default when run by a super\-user is to
+switch to your OS\(cq\&s \(dq\&nobody\(dq\& (or perhaps \(dq\&nogroup\(dq\&) group with no other
+supplementary groups.  The default for a non\-super\-user is to not change any
+group attributes (and indeed, your OS may not allow a non\-super\-user to try to
+change their group settings).
+.IP 
+.IP "\fBfake super\fP"
+Setting \(dq\&fake super = yes\(dq\& for a module causes the
+daemon side to behave as if the \fB\-\-fake\-super\fP command\-line option had
+been specified.  This allows the full attributes of a file to be stored
+without having to have the daemon actually running as root.
+.IP 
+.IP "\fBfilter\fP"
+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
+the daemon filter chain (\fBdaemon\-excluded\fP 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.  You can use daemon filters to prevent clients from downloading or
+tampering with private administrative files, such as files you may add to
+support uid/gid name translations.
+.IP 
+The daemon filter chain is built from the \(dq\&filter\(dq\&, \(dq\&include from\(dq\&, \(dq\&include\(dq\&,
+\(dq\&exclude from\(dq\&, and \(dq\&exclude\(dq\& parameters, in that order of priority.  Anchored
+patterns are anchored at the root of the module.  To prevent access to an
+entire subtree, for example, \(dq\&/secret\(dq\&, you \fImust\fP exclude everything in the
+subtree; the easiest way to do this is with a triple\-star pattern like
+\(dq\&/secret/***\(dq\&.
+.IP 
+The \(dq\&filter\(dq\& parameter takes a space\-separated list of daemon filter rules,
+though it is smart enough to know not to split a token at an internal space in
+a rule (e.g. \(dq\&\- /foo  \- /bar\(dq\& is parsed as two rules).  You may specify one or
+more merge\-file rules using the normal syntax.  Only one \(dq\&filter\(dq\& 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 \fB\-\-delete\fP 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.
+.IP 
+.IP "\fBexclude\fP"
+This parameter takes a space\-separated list of daemon
+exclude patterns.  As with the client \fB\-\-exclude\fP option, patterns can be
+qualified with \(dq\&\- \(dq\& or \(dq\&+ \(dq\& to explicitly indicate exclude/include.  Only one
+\(dq\&exclude\(dq\& parameter can apply to a given module.  See the \(dq\&filter\(dq\& parameter
+for a description of how excluded files affect the daemon.
+.IP 
+.IP "\fBinclude\fP"
+Use an \(dq\&include\(dq\& to override the effects of the \(dq\&exclude\(dq\&
+parameter.  Only one \(dq\&include\(dq\& parameter can apply to a given module.  See the
+\(dq\&filter\(dq\& parameter for a description of how excluded files affect the daemon.
+.IP 
+.IP "\fBexclude from\fP"
+This parameter specifies the name of a file
+on the daemon that contains daemon exclude patterns, one per line.  Only one
+\(dq\&exclude from\(dq\& parameter can apply to a given module; if you have multiple
+exclude\-from files, you can specify them as a merge file in the \(dq\&filter\(dq\&
+parameter.  See the \(dq\&filter\(dq\& parameter for a description of how excluded files
+affect the daemon.
+.IP 
+.IP "\fBinclude from\fP"
+Analogue of \(dq\&exclude from\(dq\& for a file of daemon include
+patterns.  Only one \(dq\&include from\(dq\& parameter can apply to a given module.  See
+the \(dq\&filter\(dq\& parameter for a description of how excluded files affect the
+daemon.
+.IP 
+.IP "\fBincoming chmod\fP"
+This parameter allows you to specify 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 \fB\-\-perms\fP.
+See the description of the \fB\-\-chmod\fP rsync option and the \fBchmod\fP(1)
+manpage for information on the format of this string.
+.IP 
+.IP "\fBoutgoing chmod\fP"
+This parameter allows you to specify a 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 \fB\-\-chmod\fP rsync option and the \fBchmod\fP(1)
+manpage for information on the format of this string.
+.IP 
+.IP "\fBauth users\fP"
+This parameter specifies a comma and/or space\-separated
+list of authorization rules.  In its simplest form, you list the usernames
+that will be allowed to connect to
+this module. The usernames do not need to exist on the local
+system. The rules may contain shell wildcard characters that will be matched
+against the username provided by the client for authentication. If
+\(dq\&auth users\(dq\& 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
+\(dq\&secrets file\(dq\& parameter. The default is for all users to be able to
+connect without a password (this is called \(dq\&anonymous rsync\(dq\&).
+.IP 
+In addition to username matching, you can specify groupname matching via a \(cq\&@\(cq\&
+prefix.  When using groupname matching, the authenticating username must be a
+real user on the system, or it will be assumed to be a member of no groups.
+For example, specifying \(dq\&@rsync\(dq\& will match the authenticating user if the
+named user is a member of the rsync group.
+.IP 
+Finally, options may be specified after a colon (:).  The options allow you to
+\(dq\&deny\(dq\& a user or a group, set the access to \(dq\&ro\(dq\& (read\-only), or set the access
+to \(dq\&rw\(dq\& (read/write).  Setting an auth\-rule\-specific ro/rw setting overrides
+the module\(cq\&s \(dq\&read only\(dq\& setting.
+.IP 
+Be sure to put the rules in the order you want them to be matched, because the
+checking stops at the first matching user or group, and that is the only auth
+that is checked.  For example:
+.IP 
+.nf 
+  auth users = joe:deny @guest:deny admin:rw @rsync:ro susan joe sam 
+.fi 
+
+.IP 
+In the above rule, user joe will be denied access no matter what.  Any user
+that is in the group \(dq\&guest\(dq\& is also denied access.  The user \(dq\&admin\(dq\& gets
+access in read/write mode, but only if the admin user is not in group \(dq\&guest\(dq\&
+(because the admin user\-matching rule would never be reached if the user is in
+group \(dq\&guest\(dq\&).  Any other user who is in group \(dq\&rsync\(dq\& will get read\-only
+access.  Finally, users susan, joe, and sam get the ro/rw setting of the
+module, but only if the user didn\(cq\&t match an earlier group\-matching rule.
+.IP 
+See the description of the secrets file for how you can have per\-user passwords
+as well as per\-group passwords.  It also explains how a user can authenticate
+using their user password or (when applicable) a group password, depending on
+what rule is being authenticated.
+.IP 
+See also the section entitled \(dq\&USING RSYNC\-DAEMON FEATURES VIA A REMOTE
+SHELL CONNECTION\(dq\& in \fBrsync\fP(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.
+.IP 
+.IP "\fBsecrets file\fP"
+This parameter specifies the name of a file that contains
+the username:password and/or @groupname:password pairs used for authenticating
+this module. This file is only consulted if the \(dq\&auth users\(dq\& parameter is
+specified.  The file is line\-based and contains one name:password pair per
+line.  Any line has a hash (#) as the very first character on the line is
+considered a comment and is skipped.  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, so you may find that passwords longer than 8
+characters don\(cq\&t work.
+.IP 
+The use of group\-specific lines are only relevant when the module is being
+authorized using a matching \(dq\&@groupname\(dq\& rule.  When that happens, the user
+can be authorized via either their \(dq\&username:password\(dq\& line or the
+\(dq\&@groupname:password\(dq\& line for the group that triggered the authentication.
+.IP 
+It is up to you what kind of password entries you want to include, either
+users, groups, or both.  The use of group rules in \(dq\&auth users\(dq\& does not
+require that you specify a group password if you do not want to use shared
+passwords.
+.IP 
+There is no default for the \(dq\&secrets file\(dq\& parameter, you must choose a name
+(such as \f(CW/etc/rsyncd.secrets\fP).  The file must normally not be readable
+by \(dq\&other\(dq\&; see \(dq\&strict modes\(dq\&.  If the file is not found or is rejected, no
+logins for a \(dq\&user auth\(dq\& module will be possible.
+.IP 
+.IP "\fBstrict modes\fP"
+This parameter determines whether or not
+the permissions on the secrets file will be checked.  If \(dq\&strict modes\(dq\& is
+true, then the secrets file must not be readable by any user ID other
+than the one that the rsync daemon is running under.  If \(dq\&strict modes\(dq\& is
+false, the check is not performed.  The default is true.  This parameter
+was added to accommodate rsync running on the Windows operating system.
+.IP 
+.IP "\fBhosts allow\fP"
+This parameter allows you to specify a
+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.
+.IP 
+Each pattern can be in one of five forms:
+.IP 
+.RS 
+.IP o 
+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\(cq\&s IP address
+must match exactly.
+.IP o 
+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.
+.IP o 
+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.
+.IP o 
+a hostname pattern using wildcards. If the hostname of the connecting IP
+(as determined by a reverse lookup) matches the wildcarded name (using the
+same rules as normal unix filename matching), the client is allowed in.  This
+only works if \(dq\&reverse lookup\(dq\& is enabled (the default).
+.IP o 
+a hostname. A plain hostname is matched against the reverse DNS of the
+connecting IP (if \(dq\&reverse lookup\(dq\& is enabled), and/or the IP of the given
+hostname is matched against the connecting IP (if \(dq\&forward lookup\(dq\& is
+enabled, as it is by default).  Any match will be allowed in.
+.RE
+
+.IP 
+Note IPv6 link\-local addresses can have a scope in the address specification:
+.IP 
+.RS 
+\f(CW    fe80::1%link1\fP
+.br 
+\f(CW    fe80::%link1/64\fP
+.br 
+\f(CW    fe80::%link1/ffff:ffff:ffff:ffff::\fP
+.br 
+.RE
+
+.IP 
+You can also combine \(dq\&hosts allow\(dq\& with a separate \(dq\&hosts deny\(dq\&
+parameter. If both parameters are specified then the \(dq\&hosts allow\(dq\& parameter is
+checked first and a match results in the client being able to
+connect. The \(dq\&hosts deny\(dq\& parameter is then checked and a match means
+that the host is rejected. If the host does not match either the
+\(dq\&hosts allow\(dq\& or the \(dq\&hosts deny\(dq\& patterns then it is allowed to
+connect.
+.IP 
+The default is no \(dq\&hosts allow\(dq\& parameter, which means all hosts can connect.
+.IP 
+.IP "\fBhosts deny\fP"
+This parameter allows you to specify a
+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 \(dq\&hosts allow\(dq\& parameter for more information.
+.IP 
+The default is no \(dq\&hosts deny\(dq\& parameter, which means all hosts can connect.
+.IP 
+.IP "\fBreverse lookup\fP"
+Controls whether the daemon performs a reverse lookup
+on the client\(cq\&s IP address to determine its hostname, which is used for
+\(dq\&hosts allow\(dq\&/\(dq\&hosts deny\(dq\& checks and the \(dq\&%h\(dq\& log escape.  This is enabled by
+default, but you may wish to disable it to save time if you know the lookup will
+not return a useful result, in which case the daemon will use the name
+\(dq\&UNDETERMINED\(dq\& instead.
+.IP 
+If this parameter is enabled globally (even by default), rsync performs the
+lookup as soon as a client connects, so disabling it for a module will not
+avoid the lookup.  Thus, you probably want to disable it globally and then
+enable it for modules that need the information.
+.IP 
+.IP "\fBforward lookup\fP"
+Controls whether the daemon performs a forward lookup
+on any hostname specified in an hosts allow/deny setting.  By default this is
+enabled, allowing the use of an explicit hostname that would not be returned
+by reverse DNS of the connecting IP.
+.IP 
+.IP "\fBignore errors\fP"
+This parameter tells rsyncd to
+ignore I/O errors on the daemon when deciding whether to run the delete
+phase of the transfer. Normally rsync skips the \fB\-\-delete\fP step if any
+I/O errors have occurred in order to prevent disastrous deletion due
+to a temporary resource shortage or other I/O error. In some cases this
+test is counter productive so you can use this parameter to turn off this
+behavior.
+.IP 
+.IP "\fBignore nonreadable\fP"
+This tells the rsync daemon to completely
+ignore files that are not readable by the user. This is useful for
+public archives that may have some non\-readable files among the
+directories, and the sysadmin doesn\(cq\&t want those files to be seen at all.
+.IP 
+.IP "\fBtransfer logging\fP"
+This parameter 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.
+.IP 
+If you want to customize the log lines, see the \(dq\&log format\(dq\& parameter.
+.IP 
+.IP "\fBlog format\fP"
+This parameter allows you to specify the
+format used for logging file transfers when transfer logging is enabled.
+The format is 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. \(dq\&\fB%\-50n %8l %07p\fP\(dq\&).
+In addition, one or more apostrophes may be specified prior to a numerical
+escape to indicate that the numerical value should be made more human\-readable.
+The 3 supported levels are the same as for the \fB\-\-human\-readable\fP
+command\-line option, though the default is for human\-readability to be off.
+Each added apostrophe increases the level (e.g. \(dq\&\fB%'\&'\&l %'\&b %f\fP\(dq\&).
+.IP 
+The default log format is \(dq\&%o %h [%a] %m (%u) %f %l\(dq\&, and a \(dq\&%t [%p] \(dq\&
+is always prefixed when using the \(dq\&log file\(dq\& parameter.
+(A perl script that will summarize this default log format is included
+in the rsync source code distribution in the \(dq\&support\(dq\& subdirectory:
+rsyncstats.)
+.IP 
+The single\-character escapes that are understood are as follows:
+.IP 
+.RS 
+.IP o 
+%a the remote IP address (only available for a daemon)
+.IP o 
+%b the number of bytes actually transferred
+.IP o 
+%B the permission bits of the file (e.g. rwxrwxrwt)
+.IP o 
+%c the total size of the block checksums received for the basis file (only when sending)
+.IP o 
+%C the full\-file MD5 checksum if \fB\-\-checksum\fP is enabled or a file was transferred (only for protocol 30 or above).
+.IP o 
+%f the filename (long form on sender; no trailing \(dq\&/\(dq\&)
+.IP o 
+%G the gid of the file (decimal) or \(dq\&DEFAULT\(dq\&
+.IP o 
+%h the remote host name (only available for a daemon)
+.IP o 
+%i an itemized list of what is being updated
+.IP o 
+%l the length of the file in bytes
+.IP o 
+%L the string \(dq\& \-> SYMLINK\(dq\&, \(dq\& => HARDLINK\(dq\&, or \(dq\&\(dq\& (where \fBSYMLINK\fP or \fBHARDLINK\fP is a filename)
+.IP o 
+%m the module name
+.IP o 
+%M the last\-modified time of the file
+.IP o 
+%n the filename (short form; trailing \(dq\&/\(dq\& on dir)
+.IP o 
+%o the operation, which is \(dq\&send\(dq\&, \(dq\&recv\(dq\&, or \(dq\&del.\(dq\& (the latter includes the trailing period)
+.IP o 
+%p the process ID of this rsync session
+.IP o 
+%P the module path
+.IP o 
+%t the current date time
+.IP o 
+%u the authenticated username or an empty string
+.IP o 
+%U the uid of the file (decimal)
+.RE
+
+.IP 
+For a list of what the characters mean that are output by \(dq\&%i\(dq\&, see the
+\fB\-\-itemize\-changes\fP option in the rsync manpage.
+.IP 
+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.
+.IP 
+.IP "\fBtimeout\fP"
+This parameter allows you to override the
+clients choice for I/O timeout for this module. Using this parameter you
+can ensure that rsync won\(cq\&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).
+.IP 
+.IP "\fBrefuse options\fP"
+This parameter allows you to
+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 \fB\-\-checksum\fP (\fB\-c\fP) and all the various
+delete options:
+.IP 
+.RS 
+\f(CW    refuse options = c delete\fP
+.RE
+
+.IP 
+The reason the above refuses all delete options is that the options imply
+\fB\-\-delete\fP, and implied options are refused just like explicit options.
+As an additional safety feature, the refusal of \(dq\&delete\(dq\& also refuses
+\fBremove\-source\-files\fP when the daemon is the sender; if you want the latter
+without the former, instead refuse \(dq\&delete\-*\(dq\& \-\- that refuses all the
+delete modes without affecting \fB\-\-remove\-source\-files\fP.
+.IP 
+When an option is refused, the daemon prints an error message and exits.
+To prevent all compression when serving files,
+you can use \(dq\&dont compress = *\(dq\& (see below)
+instead of \(dq\&refuse options = compress\(dq\& to avoid returning an error to a
+client that requests compression.
+.IP 
+.IP "\fBdont compress\fP"
+This parameter allows you to 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\(cq\&t compress well,
+such as already compressed files.
+.IP 
+The \(dq\&dont compress\(dq\& 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.
+.IP 
+See the \fB\-\-skip\-compress\fP parameter in the \fBrsync\fP(1) manpage for the list
+of file suffixes that are not compressed by default.  Specifying a value
+for the \(dq\&dont compress\(dq\& parameter changes the default when the daemon is
+the sender.
+.IP 
+.IP "\fBpre\-xfer exec\fP, \fBpost\-xfer exec\fP"
+You may specify a command to be run
+before and/or after the transfer.  If the \fBpre\-xfer exec\fP command fails, the
+transfer is aborted before it begins.  Any output from the script on stdout (up
+to several KB) will be displayed to the user when aborting, but is NOT
+displayed if the script returns success.  Any output from the script on stderr
+goes to the daemon\(cq\&s stderr, which is typically discarded (though see
+\-\-no\-detatch option for a way to see the stderr output, which can assist with
+debugging).
+.IP 
+The following environment variables will be set, though some are
+specific to the pre\-xfer or the post\-xfer environment:
+.IP 
+.RS 
+.IP o 
+\fBRSYNC_MODULE_NAME\fP: The name of the module being accessed.
+.IP o 
+\fBRSYNC_MODULE_PATH\fP: The path configured for the module.
+.IP o 
+\fBRSYNC_HOST_ADDR\fP: The accessing host\(cq\&s IP address.
+.IP o 
+\fBRSYNC_HOST_NAME\fP: The accessing host\(cq\&s name.
+.IP o 
+\fBRSYNC_USER_NAME\fP: The accessing user\(cq\&s name (empty if no user).
+.IP o 
+\fBRSYNC_PID\fP: A unique number for this transfer.
+.IP o 
+\fBRSYNC_REQUEST\fP: (pre\-xfer only) The module/path info specified
+by the user.  Note that the user can specify multiple source files,
+so the request can be something like \(dq\&mod/path1 mod/path2\(dq\&, etc.
+.IP o 
+\fBRSYNC_ARG#\fP: (pre\-xfer only) The pre\-request arguments are set
+in these numbered values. RSYNC_ARG0 is always \(dq\&rsyncd\(dq\&, followed by
+the options that were used in RSYNC_ARG1, and so on.  There will be a
+value of \(dq\&.\(dq\& indicating that the options are done and the path args
+are beginning \-\- these contain similar information to RSYNC_REQUEST,
+but with values separated and the module name stripped off.
+.IP o 
+\fBRSYNC_EXIT_STATUS\fP: (post\-xfer only) the server side\(cq\&s exit value.
+This will be 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.
+.IP o 
+\fBRSYNC_RAW_STATUS\fP: (post\-xfer only) the raw exit value from 
+\f(CWwaitpid()\fP
+\&.
+.RE
+
+.IP 
+Even though the commands can be associated with a particular module, they
+are run using the permissions of the user that started the daemon (not the
+module\(cq\&s uid/gid setting) without any chroot restrictions.
+.IP 
+.SH "CONFIG DIRECTIVES"
+
+.PP 
+There are currently two config directives available that allow a config file to
+incorporate the contents of other files:  \fB&include\fP and \fB&merge\fP.  Both
+allow a reference to either a file or a directory.  They differ in how
+segregated the file\(cq\&s contents are considered to be.
+.PP 
+The \fB&include\fP directive treats each file as more distinct, with each one
+inheriting the defaults of the parent file, starting the parameter parsing
+as globals/defaults, and leaving the defaults unchanged for the parsing of
+the rest of the parent file.
+.PP 
+The \fB&merge\fP directive, on the other hand, treats the file\(cq\&s contents as
+if it were simply inserted in place of the directive, and thus it can set
+parameters in a module started in another file, can affect the defaults for
+other files, etc.
+.PP 
+When an \fB&include\fP or \fB&merge\fP directive refers to a directory, it will read
+in all the \fB*.conf\fP or \fB*.inc\fP files (respectively) that are contained inside
+that directory (without any
+recursive scanning), with the files sorted into alpha order.  So, if you have a
+directory named \(dq\&rsyncd.d\(dq\& with the files \(dq\&foo.conf\(dq\&, \(dq\&bar.conf\(dq\&, and
+\(dq\&baz.conf\(dq\& inside it, this directive:
+.PP 
+.nf 
+    &include /path/rsyncd.d 
+.fi 
+
+.PP 
+would be the same as this set of directives:
+.PP 
+.nf 
+    &include /path/rsyncd.d/bar.conf
+    &include /path/rsyncd.d/baz.conf
+    &include /path/rsyncd.d/foo.conf 
+.fi 
+
+.PP 
+except that it adjusts as files are added and removed from the directory.
+.PP 
+The advantage of the \fB&include\fP directive is that you can define one or more
+modules in a separate file without worrying about unintended side\-effects
+between the self\-contained module files.
+.PP 
+The advantage of the \fB&merge\fP directive is that you can load config snippets
+that can be included into multiple module definitions, and you can also set
+global values that will affect connections (such as \fBmotd file\fP), or globals
+that will affect other include files.
+.PP 
+For example, this is a useful /etc/rsyncd.conf file:
+.PP 
+.nf 
+    port = 873
+    log file = /var/log/rsync.log
+    pid file = /var/lock/rsync.lock
+
+    &merge /etc/rsyncd.d
+    &include /etc/rsyncd.d 
+.fi 
+
+.PP 
+This would merge any /etc/rsyncd.d/*.inc files (for global values that should
+stay in effect), and then include any /etc/rsyncd.d/*.conf files (defining
+modules without any global\-value cross\-talk).
+.PP 
+.SH "AUTHENTICATION STRENGTH"
+
+.PP 
+The authentication protocol used in rsync is a 128 bit MD4 based
+challenge response system. This is fairly weak protection, though (with
+at least one brute\-force hash\-finding algorithm publicly available), so
+if you want really top\-quality security, then I recommend that you run
+rsync over ssh.  (Yes, a future version of rsync will switch over to a
+stronger hashing method.)
+.PP 
+Also note that the rsync daemon protocol does not currently provide any
+encryption of the data that is transferred over the connection. Only
+authentication is provided. Use ssh as the transport if you want
+encryption.
+.PP 
+Future versions of rsync may support SSL for better authentication and
+encryption, but that is still being investigated.
+.PP 
+.SH "EXAMPLES"
+
+.PP 
+A simple rsyncd.conf file that allow anonymous rsync to a ftp area at
+\f(CW/home/ftp\fP would be:
+.PP 
+.nf 
+
+[ftp]
+        path = /home/ftp
+        comment = ftp export area
+
+.fi 
+
+.PP 
+A more sophisticated example would be:
+.PP 
+.nf 
+
+uid = nobody
+gid = nobody
+use chroot = yes
+max connections = 4
+syslog facility = local5
+pid file = /var/run/rsyncd.pid
+
+[ftp]
+        path = /var/ftp/./pub
+        comment = whole ftp area (approx 6.1 GB)
+
+[sambaftp]
+        path = /var/ftp/./pub/samba
+        comment = Samba ftp area (approx 300 MB)
+
+[rsyncftp]
+        path = /var/ftp/./pub/rsync
+        comment = rsync ftp area (approx 6 MB)
+
+[sambawww]
+        path = /public_html/samba
+        comment = Samba WWW pages (approx 240 MB)
+
+[cvs]
+        path = /data/cvs
+        comment = CVS repository (requires authentication)
+        auth users = tridge, susan
+        secrets file = /etc/rsyncd.secrets
+
+.fi 
+
+.PP 
+The /etc/rsyncd.secrets file would look something like this:
+.PP 
+.RS 
+\f(CWtridge:mypass\fP
+.br 
+\f(CWsusan:herpass\fP
+.br 
+.RE
+
+.PP 
+.SH "FILES"
+
+.PP 
+/etc/rsyncd.conf or rsyncd.conf
+.PP 
+.SH "SEE ALSO"
+
+.PP 
+\fBrsync\fP(1)
+.PP 
+.SH "DIAGNOSTICS"
+
+.PP 
+.SH "BUGS"
+
+.PP 
+Please report bugs! The rsync bug tracking system is online at
+http://rsync.samba.org/
+.PP 
+.SH "VERSION"
+
+.PP 
+This man page is current for version 3.1.2 of rsync.
+.PP 
+.SH "CREDITS"
+
+.PP 
+rsync is distributed under the GNU General Public License.  See the file
+COPYING for details.
+.PP 
+The primary ftp site for rsync is
+ftp://rsync.samba.org/pub/rsync.
+.PP 
+A WEB site is available at
+http://rsync.samba.org/
+.PP 
+We would be delighted to hear from you if you like this program.
+.PP 
+This program uses the zlib compression library written by Jean\-loup
+Gailly and Mark Adler.
+.PP 
+.SH "THANKS"
+
+.PP 
+Thanks to Warren Stanley for his original idea and patch for the rsync
+daemon. Thanks to Karsten Thygesen for his many suggestions and
+documentation!
+.PP 
+.SH "AUTHOR"
+
+.PP 
+rsync was written by Andrew Tridgell and Paul Mackerras.
+Many people have later contributed to it.
+.PP 
+Mailing lists for support and development are available at
+http://lists.samba.org