rsyncd.conf.yo 34 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734
  1. mailto(rsync-bugs@samba.org)
  2. manpage(rsyncd.conf)(5)(26 Mar 2011)()()
  3. manpagename(rsyncd.conf)(configuration file for rsync in daemon mode)
  4. manpagesynopsis()
  5. rsyncd.conf
  6. manpagedescription()
  7. The rsyncd.conf file is the runtime configuration file for rsync when
  8. run as an rsync daemon.
  9. The rsyncd.conf file controls authentication, access, logging and
  10. available modules.
  11. manpagesection(FILE FORMAT)
  12. The file consists of modules and parameters. A module begins with the
  13. name of the module in square brackets and continues until the next
  14. module begins. Modules contain parameters of the form "name = value".
  15. The file is line-based -- that is, each newline-terminated line represents
  16. either a comment, a module name or a parameter.
  17. Only the first equals sign in a parameter is significant. Whitespace before
  18. or after the first equals sign is discarded. Leading, trailing and internal
  19. whitespace in module and parameter names is irrelevant. Leading and
  20. trailing whitespace in a parameter value is discarded. Internal whitespace
  21. within a parameter value is retained verbatim.
  22. Any line beginning with a hash (#) is ignored, as are lines containing
  23. only whitespace.
  24. Any line ending in a \ is "continued" on the next line in the
  25. customary UNIX fashion.
  26. The values following the equals sign in parameters are all either a string
  27. (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or
  28. true/false. Case is not significant in boolean values, but is preserved
  29. in string values.
  30. manpagesection(LAUNCHING THE RSYNC DAEMON)
  31. The rsync daemon is launched by specifying the bf(--daemon) option to
  32. rsync.
  33. The daemon must run with root privileges if you wish to use chroot, to
  34. bind to a port numbered under 1024 (as is the default 873), or to set
  35. file ownership. Otherwise, it must just have permission to read and
  36. write the appropriate data, log, and lock files.
  37. You can launch it either via inetd, as a stand-alone daemon, or from
  38. an rsync client via a remote shell. If run as a stand-alone daemon then
  39. just run the command "bf(rsync --daemon)" from a suitable startup script.
  40. When run via inetd you should add a line like this to /etc/services:
  41. verb( rsync 873/tcp)
  42. and a single line something like this to /etc/inetd.conf:
  43. verb( rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon)
  44. Replace "/usr/bin/rsync" with the path to where you have rsync installed on
  45. your system. You will then need to send inetd a HUP signal to tell it to
  46. reread its config file.
  47. Note that you should bf(not) send the rsync daemon a HUP signal to force
  48. it to reread the tt(rsyncd.conf) file. The file is re-read on each client
  49. connection.
  50. manpagesection(GLOBAL PARAMETERS)
  51. The first parameters in the file (before a [module] header) are the
  52. global parameters.
  53. You may also include any module parameters in the global part of the
  54. config file in which case the supplied value will override the
  55. default for that parameter.
  56. startdit()
  57. dit(bf(motd file)) This parameter allows you to specify a
  58. "message of the day" to display to clients on each connect. This
  59. usually contains site information and any legal notices. The default
  60. is no motd file.
  61. dit(bf(pid file)) This parameter tells the rsync daemon to write
  62. its process ID to that file. If the file already exists, the rsync
  63. daemon will abort rather than overwrite the file.
  64. dit(bf(port)) You can override the default port the daemon will listen on
  65. by specifying this value (defaults to 873). This is ignored if the daemon
  66. is being run by inetd, and is superseded by the bf(--port) command-line option.
  67. dit(bf(address)) You can override the default IP address the daemon
  68. will listen on by specifying this value. This is ignored if the daemon is
  69. being run by inetd, and is superseded by the bf(--address) command-line option.
  70. dit(bf(socket options)) This parameter can provide endless fun for people
  71. who like to tune their systems to the utmost degree. You can set all
  72. sorts of socket options which may make transfers faster (or
  73. slower!). Read the man page for the code(setsockopt()) system call for
  74. details on some of the options you may be able to set. By default no
  75. special socket options are set. These settings can also be specified
  76. via the bf(--sockopts) command-line option.
  77. enddit()
  78. manpagesection(MODULE PARAMETERS)
  79. After the global parameters you should define a number of modules, each
  80. module exports a directory tree as a symbolic name. Modules are
  81. exported by specifying a module name in square brackets [module]
  82. followed by the parameters for that module.
  83. The module name cannot contain a slash or a closing square bracket. If the
  84. name contains whitespace, each internal sequence of whitespace will be
  85. changed into a single space, while leading or trailing whitespace will be
  86. discarded.
  87. startdit()
  88. dit(bf(comment)) This parameter specifies a description string
  89. that is displayed next to the module name when clients obtain a list
  90. of available modules. The default is no comment.
  91. dit(bf(path)) This parameter specifies the directory in the daemon's
  92. filesystem to make available in this module. You must specify this parameter
  93. for each module in tt(rsyncd.conf).
  94. dit(bf(use chroot)) If "use chroot" is true, the rsync daemon will chroot
  95. to the "path" before starting the file transfer with the client. This has
  96. the advantage of extra protection against possible implementation security
  97. holes, but it has the disadvantages of requiring super-user privileges,
  98. of not being able to follow symbolic links that are either absolute or outside
  99. of the new root path, and of complicating the preservation of users and groups
  100. by name (see below).
  101. As an additional safety feature, you can specify a dot-dir in the module's
  102. "path" to indicate the point where the chroot should occur. This allows rsync
  103. to run in a chroot with a non-"/" path for the top of the transfer hierarchy.
  104. Doing this guards against unintended library loading (since those absolute
  105. paths will not be inside the transfer hierarchy unless you have used an unwise
  106. pathname), and lets you setup libraries for the chroot that are outside of the
  107. transfer. For example, specifying "/var/rsync/./module1" will chroot to the
  108. "/var/rsync" directory and set the inside-chroot path to "/module1". If you
  109. had omitted the dot-dir, the chroot would have used the whole path, and the
  110. inside-chroot path would have been "/".
  111. When "use chroot" is false or the inside-chroot path is not "/", rsync will:
  112. (1) munge symlinks by
  113. default for security reasons (see "munge symlinks" for a way to turn this
  114. off, but only if you trust your users), (2) substitute leading slashes in
  115. absolute paths with the module's path (so that options such as
  116. bf(--backup-dir), bf(--compare-dest), etc. interpret an absolute path as
  117. rooted in the module's "path" dir), and (3) trim ".." path elements from
  118. args if rsync believes they would escape the module hierarchy.
  119. The default for "use chroot" is true, and is the safer choice (especially
  120. if the module is not read-only).
  121. When this parameter is enabled, rsync will not attempt to map users and groups
  122. by name (by default), but instead copy IDs as though bf(--numeric-ids) had
  123. been specified. In order to enable name-mapping, rsync needs to be able to
  124. use the standard library functions for looking up names and IDs (i.e.
  125. code(getpwuid()), code(getgrgid()), code(getpwname()), and code(getgrnam())).
  126. This means the rsync
  127. process in the chroot hierarchy will need to have access to the resources
  128. used by these library functions (traditionally /etc/passwd and
  129. /etc/group, but perhaps additional dynamic libraries as well).
  130. If you copy the necessary resources into the module's chroot area, you
  131. should protect them through your OS's normal user/group or ACL settings (to
  132. prevent the rsync module's user from being able to change them), and then
  133. hide them from the user's view via "exclude" (see how in the discussion of
  134. that parameter). At that point it will be safe to enable the mapping of users
  135. and groups by name using the "numeric ids" daemon parameter (see below).
  136. Note also that you are free to setup custom user/group information in the
  137. chroot area that is different from your normal system. For example, you
  138. could abbreviate the list of users and groups.
  139. dit(bf(numeric ids)) Enabling this parameter disables the mapping
  140. of users and groups by name for the current daemon module. This prevents
  141. the daemon from trying to load any user/group-related files or libraries.
  142. This enabling makes the transfer behave as if the client had passed
  143. the bf(--numeric-ids) command-line option. By default, this parameter is
  144. enabled for chroot modules and disabled for non-chroot modules.
  145. A chroot-enabled module should not have this parameter enabled unless you've
  146. taken steps to ensure that the module has the necessary resources it needs
  147. to translate names, and that it is not possible for a user to change those
  148. resources.
  149. dit(bf(munge symlinks)) This parameter tells rsync to modify
  150. all incoming symlinks in a way that makes them unusable but recoverable
  151. (see below). This should help protect your files from user trickery when
  152. your daemon module is writable. The default is disabled when "use chroot"
  153. is on and the inside-chroot path is "/", otherwise it is enabled.
  154. If you disable this parameter on a daemon that is not read-only, there
  155. are tricks that a user can play with uploaded symlinks to access
  156. daemon-excluded items (if your module has any), and, if "use chroot"
  157. is off, rsync can even be tricked into showing or changing data that
  158. is outside the module's path (as access-permissions allow).
  159. The way rsync disables the use of symlinks is to prefix each one with
  160. the string "/rsyncd-munged/". This prevents the links from being used
  161. as long as that directory does not exist. When this parameter is enabled,
  162. rsync will refuse to run if that path is a directory or a symlink to
  163. a directory. When using the "munge symlinks" parameter in a chroot area
  164. that has an inside-chroot path of "/", you should add "/rsyncd-munged/"
  165. to the exclude setting for the module so that
  166. a user can't try to create it.
  167. Note: rsync makes no attempt to verify that any pre-existing symlinks in
  168. the module's hierarchy are as safe as you want them to be (unless, of
  169. course, it just copied in the whole hierarchy). If you setup an rsync
  170. daemon on a new area or locally add symlinks, you can manually protect your
  171. symlinks from being abused by prefixing "/rsyncd-munged/" to the start of
  172. every symlink's value. There is a perl script in the support directory
  173. of the source code named "munge-symlinks" that can be used to add or remove
  174. this prefix from your symlinks.
  175. When this parameter is disabled on a writable module and "use chroot" is off
  176. (or the inside-chroot path is not "/"),
  177. incoming symlinks will be modified to drop a leading slash and to remove ".."
  178. path elements that rsync believes will allow a symlink to escape the module's
  179. hierarchy. There are tricky ways to work around this, though, so you had
  180. better trust your users if you choose this combination of parameters.
  181. dit(bf(charset)) This specifies the name of the character set in which the
  182. module's filenames are stored. If the client uses an bf(--iconv) option,
  183. the daemon will use the value of the "charset" parameter regardless of the
  184. character set the client actually passed. This allows the daemon to
  185. support charset conversion in a chroot module without extra files in the
  186. chroot area, and also ensures that name-translation is done in a consistent
  187. manner. If the "charset" parameter is not set, the bf(--iconv) option is
  188. refused, just as if "iconv" had been specified via "refuse options".
  189. If you wish to force users to always use bf(--iconv) for a particular
  190. module, add "no-iconv" to the "refuse options" parameter. Keep in mind
  191. that this will restrict access to your module to very new rsync clients.
  192. dit(bf(max connections)) This parameter allows you to
  193. specify the maximum number of simultaneous connections you will allow.
  194. Any clients connecting when the maximum has been reached will receive a
  195. message telling them to try later. The default is 0, which means no limit.
  196. A negative value disables the module.
  197. See also the "lock file" parameter.
  198. dit(bf(log file)) When the "log file" parameter is set to a non-empty
  199. string, the rsync daemon will log messages to the indicated file rather
  200. than using syslog. This is particularly useful on systems (such as AIX)
  201. where code(syslog()) doesn't work for chrooted programs. The file is
  202. opened before code(chroot()) is called, allowing it to be placed outside
  203. the transfer. If this value is set on a per-module basis instead of
  204. globally, the global log will still contain any authorization failures
  205. or config-file error messages.
  206. If the daemon fails to open the specified file, it will fall back to
  207. using syslog and output an error about the failure. (Note that the
  208. failure to open the specified log file used to be a fatal error.)
  209. dit(bf(syslog facility)) This parameter allows you to
  210. specify the syslog facility name to use when logging messages from the
  211. rsync daemon. You may use any standard syslog facility name which is
  212. defined on your system. Common names are auth, authpriv, cron, daemon,
  213. ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0,
  214. local1, local2, local3, local4, local5, local6 and local7. The default
  215. is daemon. This setting has no effect if the "log file" setting is a
  216. non-empty string (either set in the per-modules settings, or inherited
  217. from the global settings).
  218. dit(bf(max verbosity)) This parameter allows you to control
  219. the maximum amount of verbose information that you'll allow the daemon to
  220. generate (since the information goes into the log file). The default is 1,
  221. which allows the client to request one level of verbosity.
  222. dit(bf(lock file)) This parameter specifies the file to use to
  223. support the "max connections" parameter. The rsync daemon uses record
  224. locking on this file to ensure that the max connections limit is not
  225. exceeded for the modules sharing the lock file.
  226. The default is tt(/var/run/rsyncd.lock).
  227. dit(bf(read only)) This parameter determines whether clients
  228. will be able to upload files or not. If "read only" is true then any
  229. attempted uploads will fail. If "read only" is false then uploads will
  230. be possible if file permissions on the daemon side allow them. The default
  231. is for all modules to be read only.
  232. dit(bf(write only)) This parameter determines whether clients
  233. will be able to download files or not. If "write only" is true then any
  234. attempted downloads will fail. If "write only" is false then downloads
  235. will be possible if file permissions on the daemon side allow them. The
  236. default is for this parameter to be disabled.
  237. dit(bf(list)) This parameter determines if this module should be
  238. listed when the client asks for a listing of available modules. By
  239. setting this to false you can create hidden modules. The default is
  240. for modules to be listable.
  241. dit(bf(uid)) This parameter specifies the user name or user ID that
  242. file transfers to and from that module should take place as when the daemon
  243. was run as root. In combination with the "gid" parameter this determines what
  244. file permissions are available. The default is uid -2, which is normally
  245. the user "nobody".
  246. dit(bf(gid)) This parameter specifies the group name or group ID that
  247. file transfers to and from that module should take place as when the daemon
  248. was run as root. This complements the "uid" parameter. The default is gid -2,
  249. which is normally the group "nobody".
  250. dit(bf(fake super)) Setting "fake super = yes" for a module causes the
  251. daemon side to behave as if the bf(--fake-super) command-line option had
  252. been specified. This allows the full attributes of a file to be stored
  253. without having to have the daemon actually running as root.
  254. dit(bf(filter)) The daemon has its own filter chain that determines what files
  255. it will let the client access. This chain is not sent to the client and is
  256. independent of any filters the client may have specified. Files excluded by
  257. the daemon filter chain (bf(daemon-excluded) files) are treated as non-existent
  258. if the client tries to pull them, are skipped with an error message if the
  259. client tries to push them (triggering exit code 23), and are never deleted from
  260. the module. You can use daemon filters to prevent clients from downloading or
  261. tampering with private administrative files, such as files you may add to
  262. support uid/gid name translations.
  263. The daemon filter chain is built from the "filter", "include from", "include",
  264. "exclude from", and "exclude" parameters, in that order of priority. Anchored
  265. patterns are anchored at the root of the module. To prevent access to an
  266. entire subtree, for example, "/secret", you em(must) exclude everything in the
  267. subtree; the easiest way to do this is with a triple-star pattern like
  268. "/secret/***".
  269. The "filter" parameter takes a space-separated list of daemon filter rules,
  270. though it is smart enough to know not to split a token at an internal space in
  271. a rule (e.g. "- /foo - /bar" is parsed as two rules). You may specify one or
  272. more merge-file rules using the normal syntax. Only one "filter" parameter can
  273. apply to a given module in the config file, so put all the rules you want in a
  274. single parameter. Note that per-directory merge-file rules do not provide as
  275. much protection as global rules, but they can be used to make bf(--delete) work
  276. better during a client download operation if the per-dir merge files are
  277. included in the transfer and the client requests that they be used.
  278. dit(bf(exclude)) This parameter takes a space-separated list of daemon
  279. exclude patterns. As with the client bf(--exclude) option, patterns can be
  280. qualified with "- " or "+ " to explicitly indicate exclude/include. Only one
  281. "exclude" parameter can apply to a given module. See the "filter" parameter
  282. for a description of how excluded files affect the daemon.
  283. dit(bf(include)) Use an "include" to override the effects of the "exclude"
  284. parameter. Only one "include" parameter can apply to a given module. See the
  285. "filter" parameter for a description of how excluded files affect the daemon.
  286. dit(bf(exclude from)) This parameter specifies the name of a file
  287. on the daemon that contains daemon exclude patterns, one per line. Only one
  288. "exclude from" parameter can apply to a given module; if you have multiple
  289. exclude-from files, you can specify them as a merge file in the "filter"
  290. parameter. See the "filter" parameter for a description of how excluded files
  291. affect the daemon.
  292. dit(bf(include from)) Analogue of "exclude from" for a file of daemon include
  293. patterns. Only one "include from" parameter can apply to a given module. See
  294. the "filter" parameter for a description of how excluded files affect the
  295. daemon.
  296. dit(bf(incoming chmod)) This parameter allows you to specify a set of
  297. comma-separated chmod strings that will affect the permissions of all
  298. incoming files (files that are being received by the daemon). These
  299. changes happen after all other permission calculations, and this will
  300. even override destination-default and/or existing permissions when the
  301. client does not specify bf(--perms).
  302. See the description of the bf(--chmod) rsync option and the bf(chmod)(1)
  303. manpage for information on the format of this string.
  304. dit(bf(outgoing chmod)) This parameter allows you to specify a set of
  305. comma-separated chmod strings that will affect the permissions of all
  306. outgoing files (files that are being sent out from the daemon). These
  307. changes happen first, making the sent permissions appear to be different
  308. than those stored in the filesystem itself. For instance, you could
  309. disable group write permissions on the server while having it appear to
  310. be on to the clients.
  311. See the description of the bf(--chmod) rsync option and the bf(chmod)(1)
  312. manpage for information on the format of this string.
  313. dit(bf(auth users)) This parameter specifies a comma and
  314. space-separated list of usernames that will be allowed to connect to
  315. this module. The usernames do not need to exist on the local
  316. system. The usernames may also contain shell wildcard characters. If
  317. "auth users" is set then the client will be challenged to supply a
  318. username and password to connect to the module. A challenge response
  319. authentication protocol is used for this exchange. The plain text
  320. usernames and passwords are stored in the file specified by the
  321. "secrets file" parameter. The default is for all users to be able to
  322. connect without a password (this is called "anonymous rsync").
  323. See also the section entitled "USING RSYNC-DAEMON FEATURES VIA A REMOTE
  324. SHELL CONNECTION" in bf(rsync)(1) for information on how handle an
  325. rsyncd.conf-level username that differs from the remote-shell-level
  326. username when using a remote shell to connect to an rsync daemon.
  327. dit(bf(secrets file)) This parameter specifies the name of
  328. a file that contains the username:password pairs used for
  329. authenticating this module. This file is only consulted if the "auth
  330. users" parameter is specified. The file is line based and contains
  331. username:password pairs separated by a single colon. Any line starting
  332. with a hash (#) is considered a comment and is skipped. The passwords
  333. can contain any characters but be warned that many operating systems
  334. limit the length of passwords that can be typed at the client end, so
  335. you may find that passwords longer than 8 characters don't work.
  336. There is no default for the "secrets file" parameter, you must choose a name
  337. (such as tt(/etc/rsyncd.secrets)). The file must normally not be readable
  338. by "other"; see "strict modes".
  339. dit(bf(strict modes)) This parameter determines whether or not
  340. the permissions on the secrets file will be checked. If "strict modes" is
  341. true, then the secrets file must not be readable by any user ID other
  342. than the one that the rsync daemon is running under. If "strict modes" is
  343. false, the check is not performed. The default is true. This parameter
  344. was added to accommodate rsync running on the Windows operating system.
  345. dit(bf(hosts allow)) This parameter allows you to specify a
  346. list of patterns that are matched against a connecting clients
  347. hostname and IP address. If none of the patterns match then the
  348. connection is rejected.
  349. Each pattern can be in one of five forms:
  350. quote(itemization(
  351. it() a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address
  352. of the form a:b:c::d:e:f. In this case the incoming machine's IP address
  353. must match exactly.
  354. it() an address/mask in the form ipaddr/n where ipaddr is the IP address
  355. and n is the number of one bits in the netmask. All IP addresses which
  356. match the masked IP address will be allowed in.
  357. it() an address/mask in the form ipaddr/maskaddr where ipaddr is the
  358. IP address and maskaddr is the netmask in dotted decimal notation for IPv4,
  359. or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP
  360. addresses which match the masked IP address will be allowed in.
  361. it() a hostname. The hostname as determined by a reverse lookup will
  362. be matched (case insensitive) against the pattern. Only an exact
  363. match is allowed in.
  364. it() a hostname pattern using wildcards. These are matched using the
  365. same rules as normal unix filename matching. If the pattern matches
  366. then the client is allowed in.
  367. ))
  368. Note IPv6 link-local addresses can have a scope in the address specification:
  369. quote(
  370. tt( fe80::1%link1)nl()
  371. tt( fe80::%link1/64)nl()
  372. tt( fe80::%link1/ffff:ffff:ffff:ffff::)nl()
  373. )
  374. You can also combine "hosts allow" with a separate "hosts deny"
  375. parameter. If both parameters are specified then the "hosts allow" parameter is
  376. checked first and a match results in the client being able to
  377. connect. The "hosts deny" parameter is then checked and a match means
  378. that the host is rejected. If the host does not match either the
  379. "hosts allow" or the "hosts deny" patterns then it is allowed to
  380. connect.
  381. The default is no "hosts allow" parameter, which means all hosts can connect.
  382. dit(bf(hosts deny)) This parameter allows you to specify a
  383. list of patterns that are matched against a connecting clients
  384. hostname and IP address. If the pattern matches then the connection is
  385. rejected. See the "hosts allow" parameter for more information.
  386. The default is no "hosts deny" parameter, which means all hosts can connect.
  387. dit(bf(ignore errors)) This parameter tells rsyncd to
  388. ignore I/O errors on the daemon when deciding whether to run the delete
  389. phase of the transfer. Normally rsync skips the bf(--delete) step if any
  390. I/O errors have occurred in order to prevent disastrous deletion due
  391. to a temporary resource shortage or other I/O error. In some cases this
  392. test is counter productive so you can use this parameter to turn off this
  393. behavior.
  394. dit(bf(ignore nonreadable)) This tells the rsync daemon to completely
  395. ignore files that are not readable by the user. This is useful for
  396. public archives that may have some non-readable files among the
  397. directories, and the sysadmin doesn't want those files to be seen at all.
  398. dit(bf(transfer logging)) This parameter enables per-file
  399. logging of downloads and uploads in a format somewhat similar to that
  400. used by ftp daemons. The daemon always logs the transfer at the end, so
  401. if a transfer is aborted, no mention will be made in the log file.
  402. If you want to customize the log lines, see the "log format" parameter.
  403. dit(bf(log format)) This parameter allows you to specify the
  404. format used for logging file transfers when transfer logging is enabled.
  405. The format is a text string containing embedded single-character escape
  406. sequences prefixed with a percent (%) character. An optional numeric
  407. field width may also be specified between the percent and the escape
  408. letter (e.g. "bf(%-50n %8l %07p)").
  409. The default log format is "%o %h [%a] %m (%u) %f %l", and a "%t [%p] "
  410. is always prefixed when using the "log file" parameter.
  411. (A perl script that will summarize this default log format is included
  412. in the rsync source code distribution in the "support" subdirectory:
  413. rsyncstats.)
  414. The single-character escapes that are understood are as follows:
  415. quote(itemization(
  416. it() %a the remote IP address
  417. it() %b the number of bytes actually transferred
  418. it() %B the permission bits of the file (e.g. rwxrwxrwt)
  419. it() %c the total size of the block checksums received for the basis file (only when sending)
  420. it() %f the filename (long form on sender; no trailing "/")
  421. it() %G the gid of the file (decimal) or "DEFAULT"
  422. it() %h the remote host name
  423. it() %i an itemized list of what is being updated
  424. it() %l the length of the file in bytes
  425. it() %L the string " -> SYMLINK", " => HARDLINK", or "" (where bf(SYMLINK) or bf(HARDLINK) is a filename)
  426. it() %m the module name
  427. it() %M the last-modified time of the file
  428. it() %n the filename (short form; trailing "/" on dir)
  429. it() %o the operation, which is "send", "recv", or "del." (the latter includes the trailing period)
  430. it() %p the process ID of this rsync session
  431. it() %P the module path
  432. it() %t the current date time
  433. it() %u the authenticated username or an empty string
  434. it() %U the uid of the file (decimal)
  435. ))
  436. For a list of what the characters mean that are output by "%i", see the
  437. bf(--itemize-changes) option in the rsync manpage.
  438. Note that some of the logged output changes when talking with older
  439. rsync versions. For instance, deleted files were only output as verbose
  440. messages prior to rsync 2.6.4.
  441. dit(bf(timeout)) This parameter allows you to override the
  442. clients choice for I/O timeout for this module. Using this parameter you
  443. can ensure that rsync won't wait on a dead client forever. The timeout
  444. is specified in seconds. A value of zero means no timeout and is the
  445. default. A good choice for anonymous rsync daemons may be 600 (giving
  446. a 10 minute timeout).
  447. dit(bf(refuse options)) This parameter allows you to
  448. specify a space-separated list of rsync command line options that will
  449. be refused by your rsync daemon.
  450. You may specify the full option name, its one-letter abbreviation, or a
  451. wild-card string that matches multiple options.
  452. For example, this would refuse bf(--checksum) (bf(-c)) and all the various
  453. delete options:
  454. quote(tt( refuse options = c delete))
  455. The reason the above refuses all delete options is that the options imply
  456. bf(--delete), and implied options are refused just like explicit options.
  457. As an additional safety feature, the refusal of "delete" also refuses
  458. bf(remove-source-files) when the daemon is the sender; if you want the latter
  459. without the former, instead refuse "delete-*" -- that refuses all the
  460. delete modes without affecting bf(--remove-source-files).
  461. When an option is refused, the daemon prints an error message and exits.
  462. To prevent all compression when serving files,
  463. you can use "dont compress = *" (see below)
  464. instead of "refuse options = compress" to avoid returning an error to a
  465. client that requests compression.
  466. dit(bf(dont compress)) This parameter allows you to select
  467. filenames based on wildcard patterns that should not be compressed
  468. when pulling files from the daemon (no analogous parameter exists to
  469. govern the pushing of files to a daemon).
  470. Compression is expensive in terms of CPU usage, so it
  471. is usually good to not try to compress files that won't compress well,
  472. such as already compressed files.
  473. The "dont compress" parameter takes a space-separated list of
  474. case-insensitive wildcard patterns. Any source filename matching one
  475. of the patterns will not be compressed during transfer.
  476. See the bf(--skip-compress) parameter in the bf(rsync)(1) manpage for the list
  477. of file suffixes that are not compressed by default. Specifying a value
  478. for the "dont compress" parameter changes the default when the daemon is
  479. the sender.
  480. dit(bf(pre-xfer exec), bf(post-xfer exec)) You may specify a command to be run
  481. before and/or after the transfer. If the bf(pre-xfer exec) command fails, the
  482. transfer is aborted before it begins.
  483. The following environment variables will be set, though some are
  484. specific to the pre-xfer or the post-xfer environment:
  485. quote(itemization(
  486. it() bf(RSYNC_MODULE_NAME): The name of the module being accessed.
  487. it() bf(RSYNC_MODULE_PATH): The path configured for the module.
  488. it() bf(RSYNC_HOST_ADDR): The accessing host's IP address.
  489. it() bf(RSYNC_HOST_NAME): The accessing host's name.
  490. it() bf(RSYNC_USER_NAME): The accessing user's name (empty if no user).
  491. it() bf(RSYNC_PID): A unique number for this transfer.
  492. it() bf(RSYNC_REQUEST): (pre-xfer only) The module/path info specified
  493. by the user (note that the user can specify multiple source files,
  494. so the request can be something like "mod/path1 mod/path2", etc.).
  495. it() bf(RSYNC_ARG#): (pre-xfer only) The pre-request arguments are set
  496. in these numbered values. RSYNC_ARG0 is always "rsyncd", and the last
  497. value contains a single period.
  498. it() bf(RSYNC_EXIT_STATUS): (post-xfer only) the server side's exit value.
  499. This will be 0 for a successful run, a positive value for an error that the
  500. server generated, or a -1 if rsync failed to exit properly. Note that an
  501. error that occurs on the client side does not currently get sent to the
  502. server side, so this is not the final exit status for the whole transfer.
  503. it() bf(RSYNC_RAW_STATUS): (post-xfer only) the raw exit value from code(waitpid()).
  504. ))
  505. Even though the commands can be associated with a particular module, they
  506. are run using the permissions of the user that started the daemon (not the
  507. module's uid/gid setting) without any chroot restrictions.
  508. enddit()
  509. manpagesection(AUTHENTICATION STRENGTH)
  510. The authentication protocol used in rsync is a 128 bit MD4 based
  511. challenge response system. This is fairly weak protection, though (with
  512. at least one brute-force hash-finding algorithm publicly available), so
  513. if you want really top-quality security, then I recommend that you run
  514. rsync over ssh. (Yes, a future version of rsync will switch over to a
  515. stronger hashing method.)
  516. Also note that the rsync daemon protocol does not currently provide any
  517. encryption of the data that is transferred over the connection. Only
  518. authentication is provided. Use ssh as the transport if you want
  519. encryption.
  520. Future versions of rsync may support SSL for better authentication and
  521. encryption, but that is still being investigated.
  522. manpagesection(EXAMPLES)
  523. A simple rsyncd.conf file that allow anonymous rsync to a ftp area at
  524. tt(/home/ftp) would be:
  525. verb(
  526. [ftp]
  527. path = /home/ftp
  528. comment = ftp export area
  529. )
  530. A more sophisticated example would be:
  531. verb(
  532. uid = nobody
  533. gid = nobody
  534. use chroot = yes
  535. max connections = 4
  536. syslog facility = local5
  537. pid file = /var/run/rsyncd.pid
  538. [ftp]
  539. path = /var/ftp/./pub
  540. comment = whole ftp area (approx 6.1 GB)
  541. [sambaftp]
  542. path = /var/ftp/./pub/samba
  543. comment = Samba ftp area (approx 300 MB)
  544. [rsyncftp]
  545. path = /var/ftp/./pub/rsync
  546. comment = rsync ftp area (approx 6 MB)
  547. [sambawww]
  548. path = /public_html/samba
  549. comment = Samba WWW pages (approx 240 MB)
  550. [cvs]
  551. path = /data/cvs
  552. comment = CVS repository (requires authentication)
  553. auth users = tridge, susan
  554. secrets file = /etc/rsyncd.secrets
  555. )
  556. The /etc/rsyncd.secrets file would look something like this:
  557. quote(
  558. tt(tridge:mypass)nl()
  559. tt(susan:herpass)nl()
  560. )
  561. manpagefiles()
  562. /etc/rsyncd.conf or rsyncd.conf
  563. manpageseealso()
  564. bf(rsync)(1)
  565. manpagediagnostics()
  566. manpagebugs()
  567. Please report bugs! The rsync bug tracking system is online at
  568. url(http://rsync.samba.org/)(http://rsync.samba.org/)
  569. manpagesection(VERSION)
  570. This man page is current for version 3.0.8 of rsync.
  571. manpagesection(CREDITS)
  572. rsync is distributed under the GNU public license. See the file
  573. COPYING for details.
  574. The primary ftp site for rsync is
  575. url(ftp://rsync.samba.org/pub/rsync)(ftp://rsync.samba.org/pub/rsync).
  576. A WEB site is available at
  577. url(http://rsync.samba.org/)(http://rsync.samba.org/)
  578. We would be delighted to hear from you if you like this program.
  579. This program uses the zlib compression library written by Jean-loup
  580. Gailly and Mark Adler.
  581. manpagesection(THANKS)
  582. Thanks to Warren Stanley for his original idea and patch for the rsync
  583. daemon. Thanks to Karsten Thygesen for his many suggestions and
  584. documentation!
  585. manpageauthor()
  586. rsync was written by Andrew Tridgell and Paul Mackerras.
  587. Many people have later contributed to it.
  588. Mailing lists for support and development are available at
  589. url(http://lists.samba.org)(lists.samba.org)