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.
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
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
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 )