--- embedaddon/rsync/rsyncd.conf.yo	2013/10/14 07:51:14	1.1.1.2
+++ embedaddon/rsync/rsyncd.conf.yo	2016/11/01 09:54:32	1.1.1.3
@@ -1,5 +1,5 @@
 mailto(rsync-bugs@samba.org)
-manpage(rsyncd.conf)(5)(28 Sep 2013)()()
+manpage(rsyncd.conf)(5)(21 Dec 2015)()()
 manpagename(rsyncd.conf)(configuration file for rsync in daemon mode)
 manpagesynopsis()
 
@@ -74,6 +74,8 @@ manpagesection(GLOBAL PARAMETERS)
 
 The first parameters in the file (before a [module] header) are the
 global parameters.
+Rsync also allows for the use of a "[global]" module name to indicate the
+start of one or more global-parameter sections (the name must be lower case).
 
 You may also include any module parameters in the global part of the
 config file in which case the supplied value will override the
@@ -136,6 +138,8 @@ The module name cannot contain a slash or a closing sq
 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 "global" as that exact name indicates that
+global parameters follow (see above).
 
 As with GLOBAL PARAMETERS, you may use references to environment variables in
 the values of parameters.  See the GLOBAL PARAMETERS section for more details.
@@ -193,22 +197,16 @@ args if rsync believes they would escape the module hi
 The default for "use chroot" is true, and is the safer choice (especially
 if the module is not read-only).
 
-When this parameter is enabled, rsync will not attempt to map users and groups
-by name (by default), but instead copy IDs as though bf(--numeric-ids) had
-been specified.  In order to enable name-mapping, rsync needs to be able to
-use the standard library functions for looking up names and IDs (i.e.
-code(getpwuid()), code(getgrgid()), code(getpwname()), and code(getgrnam())).
-This means the rsync
-process in the chroot hierarchy will need to have access to the resources
-used by these library functions (traditionally /etc/passwd and
-/etc/group, but perhaps additional dynamic libraries as well).
+When this parameter is enabled, the "numeric-ids" option will also default to
+being enabled (disabling name lookups).  See below for what a chroot needs in
+order for name lookups to succeed.
 
-If you copy the necessary resources into the module's chroot area, you
+If you copy library resources into the module's chroot area, you
 should protect them through your OS's normal 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" (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 the "numeric ids" daemon parameter (see below).
+and groups by name using this "numeric ids" daemon parameter.
 
 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
@@ -220,11 +218,16 @@ the daemon from trying to load any user/group-related 
 This enabling makes the transfer behave as if the client had passed
 the bf(--numeric-ids) 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 "uid") or for "fake super" to be configured.
 
 A chroot-enabled module should not have this parameter enabled unless you'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.
+resources.  That includes being the code being able to call functions like
+code(getpwuid()), code(getgrgid()), code(getpwname()), and code(getgrnam())).
+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.
 
 dit(bf(munge symlinks)) This parameter tells rsync to modify
 all symlinks in the same way as the (non-daemon-affecting)
@@ -318,6 +321,13 @@ the maximum amount of verbose information that you'll 
 generate (since the information goes into the log file). The default is 1,
 which allows the client to request one level of verbosity.
 
+This also affects the user's ability to request higher levels of bf(--info) and
+bf(--debug) logging.  If the max value is 2, then no info and/or debug value
+that is higher than what would be set by bf(-vv) 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 "rsync --info=help" and "rsync --debug=help".
+For instance, it takes max-verbosity 4 to be able to output debug TIME2 and FLIST3.
+
 dit(bf(lock file)) This parameter specifies the file to use to
 support the "max connections" parameter. The rsync daemon uses record
 locking on this file to ensure that the max connections limit is not
@@ -894,7 +904,7 @@ url(http://rsync.samba.org/)(http://rsync.samba.org/)
 
 manpagesection(VERSION)
 
-This man page is current for version 3.1.0 of rsync.
+This man page is current for version 3.1.2 of rsync.
 
 manpagesection(CREDITS)