Point out that the file_struct in log_delete is zero-initialized because
[rsync/rsync.git] / rsyncd.conf.yo
index f96fc9e..240c63a 100644 (file)
@@ -120,6 +120,9 @@ 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 bf(--sockopts) command-line option.
 
+dit(bf(listen backlog)) You can override the default backlog value when the
+daemon listens for connections.  It defaults to 5.
+
 enddit()
 
 manpagesection(MODULE PARAMETERS)
@@ -153,6 +156,12 @@ For example, this would use the authorizing user's name in the path:
 
 verb(    path = /home/%RSYNC_USER_NAME% )
 
+It is fine if the path includes internal spaces -- they will be retained
+verbatim (which means that you shouldn'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.
+
 dit(bf(use chroot)) If "use chroot" is true, the rsync daemon will chroot
 to the "path" before starting the file transfer with the client.  This has
 the advantage of extra protection against possible implementation security
@@ -532,13 +541,14 @@ quote(itemization(
   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.
-  it() 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.  This only works if "reverse lookup" is enabled
-  (the default).
-  it() 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.
+  it() 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 "reverse lookup" is enabled (the default).
+  it() a hostname. A plain hostname is matched against the reverse DNS of the
+  connecting IP (if "reverse lookup" is enabled), and/or the IP of the given
+  hostname is matched against the connecting IP (if "forward lookup" is
+  enabled, as it is by default).  Any match will be allowed in.
 ))
 
 Note IPv6 link-local addresses can have a scope in the address specification:
@@ -578,6 +588,11 @@ 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.
 
+dit(bf(forward lookup)) 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.
+
 dit(bf(ignore errors)) 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 bf(--delete) step if any
@@ -697,7 +712,12 @@ the sender.
 
 dit(bf(pre-xfer exec), bf(post-xfer exec)) You may specify a command to be run
 before and/or after the transfer.  If the bf(pre-xfer exec) command fails, the
-transfer is aborted before it begins.
+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's stderr, which is typically discarded (though see
+--no-detatch option for a way to see the stderr output, which can assist with
+debugging).
 
 The following environment variables will be set, though some are
 specific to the pre-xfer or the post-xfer environment:
@@ -747,7 +767,8 @@ parameters in a module started in another file, can affect the defaults for
 other files, etc.
 
 When an bf(&include) or bf(&merge) directive refers to a directory, it will read
-in all the bf(*.conf) files contained inside that directory (without any
+in all the bf(*.conf) or bf(*.inc) 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 "rsyncd.d" with the files "foo.conf", "bar.conf", and
 "baz.conf" inside it, this directive:
@@ -764,17 +785,25 @@ except that it adjusts as files are added and removed from the directory.
 
 The advantage of the bf(&include) 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.  For instance, this is a useful
-/etc/rsyncd.conf file:
+between the self-contained module files.
+
+The advantage of the bf(&merge) 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 bf(motd file)), or globals
+that will affect other include files.
+
+For example, this is a useful /etc/rsyncd.conf file:
 
 verb(    port = 873
     log file = /var/log/rsync.log
     pid file = /var/lock/rsync.lock
 
+    &merge /etc/rsyncd.d
     &include /etc/rsyncd.d )
 
-The advantage of the bf(&merge) directive is that you can load config snippets
-that can be included into multiple module definitions.
+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).
 
 manpagesection(AUTHENTICATION STRENGTH)