X-Git-Url: https://mattmccutchen.net/rsync/rsync.git/blobdiff_plain/2206abf88410dc19632faf6743eae525ad94199a..79daa5961899c1110b862b0d3b85276122503c69:/rsyncd.conf.yo

diff --git a/rsyncd.conf.yo b/rsyncd.conf.yo
index f6f34a6e..06768e90 100644
--- a/rsyncd.conf.yo
+++ b/rsyncd.conf.yo
@@ -195,8 +195,9 @@ to translate names, and that it is not possible for a user to change those
 resources.
 
 dit(bf(munge symlinks)) This parameter tells rsync to modify
-all incoming symlinks in a way that makes them unusable but recoverable
-(see below).  This should help protect your files from user trickery when
+all symlinks in the same way as the (non-daemon-affecting)
+bf(--munge-links) 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 "use chroot"
 is on and the inside-chroot path is "/", otherwise it is enabled.
 
@@ -216,7 +217,8 @@ to the exclude setting for the module so that
 a user can't try to create it.
 
 Note:  rsync makes no attempt to verify that any pre-existing symlinks in
-the hierarchy are as safe as you want them to be.  If you setup an rsync
+the module'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 "/rsyncd-munged/" to the start of
 every symlink's value.  There is a perl script in the support directory
@@ -630,13 +632,17 @@ manpagesection(CONFIG DIRECTIVES)
 There are currently two config directives available that allow a config file to
 incorporate the contents of other files:  bf(&include) and bf(&merge).  Both
 allow a reference to either a file or a directory.  They differ in how
-segregated the file's contents are considered to be.  The bf(&include)
-directive treats each file as more distinct, with each one inheriting the
-defaults of the parent file, and starting the parameter parsing as
-globals/defaults.  The bf(&merge) directive, on the other hand, treats the
-file's contents as if it were simply inserted in place of the directive, and
-thus it can contain parameters that can be set inside a parent file's module
-settings, or whatever you like.
+segregated the file's contents are considered to be.
+
+The bf(&include) 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.
+
+The bf(&merge) directive, on the other hand, treats the file'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.
 
 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
@@ -644,23 +650,23 @@ 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:
 
-verb(    &include = /path/rsyncd.d )
+verb(    &include /path/rsyncd.d )
 
 would be the same as this set of directives:
 
-verb(    &include = /path/rsyncd.d/bar.conf
-    &include = /path/rsyncd.d/baz.conf
-    &include = /path/rsyncd.d/foo.conf )
+verb(    &include /path/rsyncd.d/bar.conf
+    &include /path/rsyncd.d/baz.conf
+    &include /path/rsyncd.d/foo.conf )
 
 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 with only the defaults you set in the parent file
-affecting it, so you don't need to worry about the settings of a prior include
-file changing a default.  For instance, this is a useful /etc/rsyncd.conf file:
+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:
 
 verb(    port = 873
-    log file = /path/rsync.log
+    log file = /var/log/rsync.log
     pid file = /var/lock/rsync.lock
 
     &include /etc/rsyncd.d )