1: .TH "rsyncd.conf" "5" "21 Dec 2015" "" ""
2: .SH "NAME"
3: rsyncd.conf \- configuration file for rsync in daemon mode
4: .SH "SYNOPSIS"
5:
6: .PP
7: rsyncd.conf
8: .PP
9: .SH "DESCRIPTION"
10:
11: .PP
12: The rsyncd.conf file is the runtime configuration file for rsync when
13: run as an rsync daemon.
14: .PP
15: The rsyncd.conf file controls authentication, access, logging and
16: available modules.
17: .PP
18: .SH "FILE FORMAT"
19:
20: .PP
21: The file consists of modules and parameters. A module begins with the
22: name of the module in square brackets and continues until the next
23: module begins. Modules contain parameters of the form \(dq\&name = value\(dq\&.
24: .PP
25: The file is line\-based \-\- that is, each newline\-terminated line represents
26: either a comment, a module name or a parameter.
27: .PP
28: Only the first equals sign in a parameter is significant. Whitespace before
29: or after the first equals sign is discarded. Leading, trailing and internal
30: whitespace in module and parameter names is irrelevant. Leading and
31: trailing whitespace in a parameter value is discarded. Internal whitespace
32: within a parameter value is retained verbatim.
33: .PP
34: Any line \fBbeginning\fP with a hash (#) is ignored, as are lines containing
35: only whitespace. (If a hash occurs after anything other than leading
36: whitespace, it is considered a part of the line\(cq\&s content.)
37: .PP
38: Any line ending in a \e is \(dq\&continued\(dq\& on the next line in the
39: customary UNIX fashion.
40: .PP
41: The values following the equals sign in parameters are all either a string
42: (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or
43: true/false. Case is not significant in boolean values, but is preserved
44: in string values.
45: .PP
46: .SH "LAUNCHING THE RSYNC DAEMON"
47:
48: .PP
49: The rsync daemon is launched by specifying the \fB\-\-daemon\fP option to
50: rsync.
51: .PP
52: The daemon must run with root privileges if you wish to use chroot, to
53: bind to a port numbered under 1024 (as is the default 873), or to set
54: file ownership. Otherwise, it must just have permission to read and
55: write the appropriate data, log, and lock files.
56: .PP
57: You can launch it either via inetd, as a stand\-alone daemon, or from
58: an rsync client via a remote shell. If run as a stand\-alone daemon then
59: just run the command \(dq\&\fBrsync \-\-daemon\fP\(dq\& from a suitable startup script.
60: .PP
61: When run via inetd you should add a line like this to /etc/services:
62: .PP
63: .nf
64: rsync 873/tcp
65: .fi
66:
67: .PP
68: and a single line something like this to /etc/inetd.conf:
69: .PP
70: .nf
71: rsync stream tcp nowait root /usr/bin/rsync rsyncd \-\-daemon
72: .fi
73:
74: .PP
75: Replace \(dq\&/usr/bin/rsync\(dq\& with the path to where you have rsync installed on
76: your system. You will then need to send inetd a HUP signal to tell it to
77: reread its config file.
78: .PP
79: Note that you should \fBnot\fP send the rsync daemon a HUP signal to force
80: it to reread the \f(CWrsyncd.conf\fP file. The file is re\-read on each client
81: connection.
82: .PP
83: .SH "GLOBAL PARAMETERS"
84:
85: .PP
86: The first parameters in the file (before a [module] header) are the
87: global parameters.
88: Rsync also allows for the use of a \(dq\&[global]\(dq\& module name to indicate the
89: start of one or more global\-parameter sections (the name must be lower case).
90: .PP
91: You may also include any module parameters in the global part of the
92: config file in which case the supplied value will override the
93: default for that parameter.
94: .PP
95: You may use references to environment variables in the values of parameters.
96: String parameters will have %VAR% references expanded as late as possible (when
97: the string is used in the program), allowing for the use of variables that
98: rsync sets at connection time, such as RSYNC_USER_NAME. Non\-string parameters
99: (such as true/false settings) are expanded when read from the config file. If
100: a variable does not exist in the environment, or if a sequence of characters is
101: not a valid reference (such as an un\-paired percent sign), the raw characters
102: are passed through unchanged. This helps with backward compatibility and
103: safety (e.g. expanding a non\-existent %VAR% to an empty string in a path could
104: result in a very unsafe path). The safest way to insert a literal % into a
105: value is to use %%.
106: .PP
107: .IP "\fBmotd file\fP"
108: This parameter allows you to specify a
109: \(dq\&message of the day\(dq\& to display to clients on each connect. This
110: usually contains site information and any legal notices. The default
111: is no motd file.
112: This can be overridden by the \fB\-\-dparam=motdfile=FILE\fP
113: command\-line option when starting the daemon.
114: .IP
115: .IP "\fBpid file\fP"
116: This parameter tells the rsync daemon to write
117: its process ID to that file. If the file already exists, the rsync
118: daemon will abort rather than overwrite the file.
119: This can be overridden by the \fB\-\-dparam=pidfile=FILE\fP
120: command\-line option when starting the daemon.
121: .IP
122: .IP "\fBport\fP"
123: You can override the default port the daemon will listen on
124: by specifying this value (defaults to 873). This is ignored if the daemon
125: is being run by inetd, and is superseded by the \fB\-\-port\fP command\-line option.
126: .IP
127: .IP "\fBaddress\fP"
128: You can override the default IP address the daemon
129: will listen on by specifying this value. This is ignored if the daemon is
130: being run by inetd, and is superseded by the \fB\-\-address\fP command\-line option.
131: .IP
132: .IP "\fBsocket options\fP"
133: This parameter can provide endless fun for people
134: who like to tune their systems to the utmost degree. You can set all
135: sorts of socket options which may make transfers faster (or
136: slower!). Read the man page for the
137: \f(CWsetsockopt()\fP
138: system call for
139: details on some of the options you may be able to set. By default no
140: special socket options are set. These settings can also be specified
141: via the \fB\-\-sockopts\fP command\-line option.
142: .IP
143: .IP "\fBlisten backlog\fP"
144: You can override the default backlog value when the
145: daemon listens for connections. It defaults to 5.
146: .IP
147: .SH "MODULE PARAMETERS"
148:
149: .PP
150: After the global parameters you should define a number of modules, each
151: module exports a directory tree as a symbolic name. Modules are
152: exported by specifying a module name in square brackets [module]
153: followed by the parameters for that module.
154: The module name cannot contain a slash or a closing square bracket. If the
155: name contains whitespace, each internal sequence of whitespace will be
156: changed into a single space, while leading or trailing whitespace will be
157: discarded.
158: Also, the name cannot be \(dq\&global\(dq\& as that exact name indicates that
159: global parameters follow (see above).
160: .PP
161: As with GLOBAL PARAMETERS, you may use references to environment variables in
162: the values of parameters. See the GLOBAL PARAMETERS section for more details.
163: .PP
164: .IP "\fBcomment\fP"
165: This parameter specifies a description string
166: that is displayed next to the module name when clients obtain a list
167: of available modules. The default is no comment.
168: .IP
169: .IP "\fBpath\fP"
170: This parameter specifies the directory in the daemon\(cq\&s
171: filesystem to make available in this module. You must specify this parameter
172: for each module in \f(CWrsyncd.conf\fP.
173: .IP
174: You may base the path\(cq\&s value off of an environment variable by surrounding
175: the variable name with percent signs. You can even reference a variable
176: that is set by rsync when the user connects.
177: For example, this would use the authorizing user\(cq\&s name in the path:
178: .IP
179: .nf
180: path = /home/%RSYNC_USER_NAME%
181: .fi
182:
183: .IP
184: It is fine if the path includes internal spaces \-\- they will be retained
185: verbatim (which means that you shouldn\(cq\&t try to escape them). If your final
186: directory has a trailing space (and this is somehow not something you wish to
187: fix), append a trailing slash to the path to avoid losing the trailing
188: whitespace.
189: .IP
190: .IP "\fBuse chroot\fP"
191: If \(dq\&use chroot\(dq\& is true, the rsync daemon will chroot
192: to the \(dq\&path\(dq\& before starting the file transfer with the client. This has
193: the advantage of extra protection against possible implementation security
194: holes, but it has the disadvantages of requiring super\-user privileges,
195: of not being able to follow symbolic links that are either absolute or outside
196: of the new root path, and of complicating the preservation of users and groups
197: by name (see below).
198: .IP
199: As an additional safety feature, you can specify a dot\-dir in the module\(cq\&s
200: \(dq\&path\(dq\& to indicate the point where the chroot should occur. This allows rsync
201: to run in a chroot with a non\-\(dq\&/\(dq\& path for the top of the transfer hierarchy.
202: Doing this guards against unintended library loading (since those absolute
203: paths will not be inside the transfer hierarchy unless you have used an unwise
204: pathname), and lets you setup libraries for the chroot that are outside of the
205: transfer. For example, specifying \(dq\&/var/rsync/./module1\(dq\& will chroot to the
206: \(dq\&/var/rsync\(dq\& directory and set the inside\-chroot path to \(dq\&/module1\(dq\&. If you
207: had omitted the dot\-dir, the chroot would have used the whole path, and the
208: inside\-chroot path would have been \(dq\&/\(dq\&.
209: .IP
210: When \(dq\&use chroot\(dq\& is false or the inside\-chroot path is not \(dq\&/\(dq\&, rsync will:
211: (1) munge symlinks by
212: default for security reasons (see \(dq\&munge symlinks\(dq\& for a way to turn this
213: off, but only if you trust your users), (2) substitute leading slashes in
214: absolute paths with the module\(cq\&s path (so that options such as
215: \fB\-\-backup\-dir\fP, \fB\-\-compare\-dest\fP, etc. interpret an absolute path as
216: rooted in the module\(cq\&s \(dq\&path\(dq\& dir), and (3) trim \(dq\&..\(dq\& path elements from
217: args if rsync believes they would escape the module hierarchy.
218: The default for \(dq\&use chroot\(dq\& is true, and is the safer choice (especially
219: if the module is not read\-only).
220: .IP
221: When this parameter is enabled, the \(dq\&numeric\-ids\(dq\& option will also default to
222: being enabled (disabling name lookups). See below for what a chroot needs in
223: order for name lookups to succeed.
224: .IP
225: If you copy library resources into the module\(cq\&s chroot area, you
226: should protect them through your OS\(cq\&s normal user/group or ACL settings (to
227: prevent the rsync module\(cq\&s user from being able to change them), and then
228: hide them from the user\(cq\&s view via \(dq\&exclude\(dq\& (see how in the discussion of
229: that parameter). At that point it will be safe to enable the mapping of users
230: and groups by name using this \(dq\&numeric ids\(dq\& daemon parameter.
231: .IP
232: Note also that you are free to setup custom user/group information in the
233: chroot area that is different from your normal system. For example, you
234: could abbreviate the list of users and groups.
235: .IP
236: .IP "\fBnumeric ids\fP"
237: Enabling this parameter disables the mapping
238: of users and groups by name for the current daemon module. This prevents
239: the daemon from trying to load any user/group\-related files or libraries.
240: This enabling makes the transfer behave as if the client had passed
241: the \fB\-\-numeric\-ids\fP command\-line option. By default, this parameter is
242: enabled for chroot modules and disabled for non\-chroot modules.
243: Also keep in mind that uid/gid preservation requires the module to be
244: running as root (see \(dq\&uid\(dq\&) or for \(dq\&fake super\(dq\& to be configured.
245: .IP
246: A chroot\-enabled module should not have this parameter enabled unless you\(cq\&ve
247: taken steps to ensure that the module has the necessary resources it needs
248: to translate names, and that it is not possible for a user to change those
249: resources. That includes being the code being able to call functions like
250: \f(CWgetpwuid()\fP
251: ,
252: \f(CWgetgrgid()\fP
253: ,
254: \f(CWgetpwname()\fP
255: , and
256: \f(CWgetgrnam()\fP
257: ).
258: You should test what libraries and config files are required for your OS
259: and get those setup before starting to test name mapping in rsync.
260: .IP
261: .IP "\fBmunge symlinks\fP"
262: This parameter tells rsync to modify
263: all symlinks in the same way as the (non\-daemon\-affecting)
264: \fB\-\-munge\-links\fP command\-line option (using a method described below).
265: This should help protect your files from user trickery when
266: your daemon module is writable. The default is disabled when \(dq\&use chroot\(dq\&
267: is on and the inside\-chroot path is \(dq\&/\(dq\&, otherwise it is enabled.
268: .IP
269: If you disable this parameter on a daemon that is not read\-only, there
270: are tricks that a user can play with uploaded symlinks to access
271: daemon\-excluded items (if your module has any), and, if \(dq\&use chroot\(dq\&
272: is off, rsync can even be tricked into showing or changing data that
273: is outside the module\(cq\&s path (as access\-permissions allow).
274: .IP
275: The way rsync disables the use of symlinks is to prefix each one with
276: the string \(dq\&/rsyncd\-munged/\(dq\&. This prevents the links from being used
277: as long as that directory does not exist. When this parameter is enabled,
278: rsync will refuse to run if that path is a directory or a symlink to
279: a directory. When using the \(dq\&munge symlinks\(dq\& parameter in a chroot area
280: that has an inside\-chroot path of \(dq\&/\(dq\&, you should add \(dq\&/rsyncd\-munged/\(dq\&
281: to the exclude setting for the module so that
282: a user can\(cq\&t try to create it.
283: .IP
284: Note: rsync makes no attempt to verify that any pre\-existing symlinks in
285: the module\(cq\&s hierarchy are as safe as you want them to be (unless, of
286: course, it just copied in the whole hierarchy). If you setup an rsync
287: daemon on a new area or locally add symlinks, you can manually protect your
288: symlinks from being abused by prefixing \(dq\&/rsyncd\-munged/\(dq\& to the start of
289: every symlink\(cq\&s value. There is a perl script in the support directory
290: of the source code named \(dq\&munge\-symlinks\(dq\& that can be used to add or remove
291: this prefix from your symlinks.
292: .IP
293: When this parameter is disabled on a writable module and \(dq\&use chroot\(dq\& is off
294: (or the inside\-chroot path is not \(dq\&/\(dq\&),
295: incoming symlinks will be modified to drop a leading slash and to remove \(dq\&..\(dq\&
296: path elements that rsync believes will allow a symlink to escape the module\(cq\&s
297: hierarchy. There are tricky ways to work around this, though, so you had
298: better trust your users if you choose this combination of parameters.
299: .IP
300: .IP "\fBcharset\fP"
301: This specifies the name of the character set in which the
302: module\(cq\&s filenames are stored. If the client uses an \fB\-\-iconv\fP option,
303: the daemon will use the value of the \(dq\&charset\(dq\& parameter regardless of the
304: character set the client actually passed. This allows the daemon to
305: support charset conversion in a chroot module without extra files in the
306: chroot area, and also ensures that name\-translation is done in a consistent
307: manner. If the \(dq\&charset\(dq\& parameter is not set, the \fB\-\-iconv\fP option is
308: refused, just as if \(dq\&iconv\(dq\& had been specified via \(dq\&refuse options\(dq\&.
309: .IP
310: If you wish to force users to always use \fB\-\-iconv\fP for a particular
311: module, add \(dq\&no\-iconv\(dq\& to the \(dq\&refuse options\(dq\& parameter. Keep in mind
312: that this will restrict access to your module to very new rsync clients.
313: .IP
314: .IP "\fBmax connections\fP"
315: This parameter allows you to
316: specify the maximum number of simultaneous connections you will allow.
317: Any clients connecting when the maximum has been reached will receive a
318: message telling them to try later. The default is 0, which means no limit.
319: A negative value disables the module.
320: See also the \(dq\&lock file\(dq\& parameter.
321: .IP
322: .IP "\fBlog file\fP"
323: When the \(dq\&log file\(dq\& parameter is set to a non\-empty
324: string, the rsync daemon will log messages to the indicated file rather
325: than using syslog. This is particularly useful on systems (such as AIX)
326: where
327: \f(CWsyslog()\fP
328: doesn\(cq\&t work for chrooted programs. The file is
329: opened before
330: \f(CWchroot()\fP
331: is called, allowing it to be placed outside
332: the transfer. If this value is set on a per\-module basis instead of
333: globally, the global log will still contain any authorization failures
334: or config\-file error messages.
335: .IP
336: If the daemon fails to open the specified file, it will fall back to
337: using syslog and output an error about the failure. (Note that the
338: failure to open the specified log file used to be a fatal error.)
339: .IP
340: This setting can be overridden by using the \fB\-\-log\-file=FILE\fP or
341: \fB\-\-dparam=logfile=FILE\fP command\-line options. The former overrides
342: all the log\-file parameters of the daemon and all module settings.
343: The latter sets the daemon\(cq\&s log file and the default for all the
344: modules, which still allows modules to override the default setting.
345: .IP
346: .IP "\fBsyslog facility\fP"
347: This parameter allows you to
348: specify the syslog facility name to use when logging messages from the
349: rsync daemon. You may use any standard syslog facility name which is
350: defined on your system. Common names are auth, authpriv, cron, daemon,
351: ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0,
352: local1, local2, local3, local4, local5, local6 and local7. The default
353: is daemon. This setting has no effect if the \(dq\&log file\(dq\& setting is a
354: non\-empty string (either set in the per\-modules settings, or inherited
355: from the global settings).
356: .IP
357: .IP "\fBmax verbosity\fP"
358: This parameter allows you to control
359: the maximum amount of verbose information that you\(cq\&ll allow the daemon to
360: generate (since the information goes into the log file). The default is 1,
361: which allows the client to request one level of verbosity.
362: .IP
363: This also affects the user\(cq\&s ability to request higher levels of \fB\-\-info\fP and
364: \fB\-\-debug\fP logging. If the max value is 2, then no info and/or debug value
365: that is higher than what would be set by \fB\-vv\fP will be honored by the daemon
366: in its logging. To see how high of a verbosity level you need to accept for a
367: particular info/debug level, refer to \(dq\&rsync \-\-info=help\(dq\& and \(dq\&rsync \-\-debug=help\(dq\&.
368: For instance, it takes max\-verbosity 4 to be able to output debug TIME2 and FLIST3.
369: .IP
370: .IP "\fBlock file\fP"
371: This parameter specifies the file to use to
372: support the \(dq\&max connections\(dq\& parameter. The rsync daemon uses record
373: locking on this file to ensure that the max connections limit is not
374: exceeded for the modules sharing the lock file.
375: The default is \f(CW/var/run/rsyncd.lock\fP.
376: .IP
377: .IP "\fBread only\fP"
378: This parameter determines whether clients
379: will be able to upload files or not. If \(dq\&read only\(dq\& is true then any
380: attempted uploads will fail. If \(dq\&read only\(dq\& is false then uploads will
381: be possible if file permissions on the daemon side allow them. The default
382: is for all modules to be read only.
383: .IP
384: Note that \(dq\&auth users\(dq\& can override this setting on a per\-user basis.
385: .IP
386: .IP "\fBwrite only\fP"
387: This parameter determines whether clients
388: will be able to download files or not. If \(dq\&write only\(dq\& is true then any
389: attempted downloads will fail. If \(dq\&write only\(dq\& is false then downloads
390: will be possible if file permissions on the daemon side allow them. The
391: default is for this parameter to be disabled.
392: .IP
393: .IP "\fBlist\fP"
394: This parameter determines whether this module is
395: listed when the client asks for a listing of available modules. In addition,
396: if this is false, the daemon will pretend the module does not exist
397: when a client denied by \(dq\&hosts allow\(dq\& or \(dq\&hosts deny\(dq\& attempts to access it.
398: Realize that if \(dq\&reverse lookup\(dq\& is disabled globally but enabled for the
399: module, the resulting reverse lookup to a potentially client\-controlled DNS
400: server may still reveal to the client that it hit an existing module.
401: The default is for modules to be listable.
402: .IP
403: .IP "\fBuid\fP"
404: This parameter specifies the user name or user ID that
405: file transfers to and from that module should take place as when the daemon
406: was run as root. In combination with the \(dq\&gid\(dq\& parameter this determines what
407: file permissions are available. The default when run by a super\-user is to
408: switch to the system\(cq\&s \(dq\&nobody\(dq\& user. The default for a non\-super\-user is to
409: not try to change the user. See also the \(dq\&gid\(dq\& parameter.
410: .IP
411: The RSYNC_USER_NAME environment variable may be used to request that rsync run
412: as the authorizing user. For example, if you want a rsync to run as the same
413: user that was received for the rsync authentication, this setup is useful:
414: .IP
415: .nf
416: uid = %RSYNC_USER_NAME%
417: gid = *
418: .fi
419:
420: .IP
421: .IP "\fBgid\fP"
422: This parameter specifies one or more group names/IDs that will be
423: used when accessing the module. The first one will be the default group, and
424: any extra ones be set as supplemental groups. You may also specify a \(dq\&*\(dq\& as
425: the first gid in the list, which will be replaced by all the normal groups for
426: the transfer\(cq\&s user (see \(dq\&uid\(dq\&). The default when run by a super\-user is to
427: switch to your OS\(cq\&s \(dq\&nobody\(dq\& (or perhaps \(dq\&nogroup\(dq\&) group with no other
428: supplementary groups. The default for a non\-super\-user is to not change any
429: group attributes (and indeed, your OS may not allow a non\-super\-user to try to
430: change their group settings).
431: .IP
432: .IP "\fBfake super\fP"
433: Setting \(dq\&fake super = yes\(dq\& for a module causes the
434: daemon side to behave as if the \fB\-\-fake\-super\fP command\-line option had
435: been specified. This allows the full attributes of a file to be stored
436: without having to have the daemon actually running as root.
437: .IP
438: .IP "\fBfilter\fP"
439: The daemon has its own filter chain that determines what files
440: it will let the client access. This chain is not sent to the client and is
441: independent of any filters the client may have specified. Files excluded by
442: the daemon filter chain (\fBdaemon\-excluded\fP files) are treated as non\-existent
443: if the client tries to pull them, are skipped with an error message if the
444: client tries to push them (triggering exit code 23), and are never deleted from
445: the module. You can use daemon filters to prevent clients from downloading or
446: tampering with private administrative files, such as files you may add to
447: support uid/gid name translations.
448: .IP
449: The daemon filter chain is built from the \(dq\&filter\(dq\&, \(dq\&include from\(dq\&, \(dq\&include\(dq\&,
450: \(dq\&exclude from\(dq\&, and \(dq\&exclude\(dq\& parameters, in that order of priority. Anchored
451: patterns are anchored at the root of the module. To prevent access to an
452: entire subtree, for example, \(dq\&/secret\(dq\&, you \fImust\fP exclude everything in the
453: subtree; the easiest way to do this is with a triple\-star pattern like
454: \(dq\&/secret/***\(dq\&.
455: .IP
456: The \(dq\&filter\(dq\& parameter takes a space\-separated list of daemon filter rules,
457: though it is smart enough to know not to split a token at an internal space in
458: a rule (e.g. \(dq\&\- /foo \- /bar\(dq\& is parsed as two rules). You may specify one or
459: more merge\-file rules using the normal syntax. Only one \(dq\&filter\(dq\& parameter can
460: apply to a given module in the config file, so put all the rules you want in a
461: single parameter. Note that per\-directory merge\-file rules do not provide as
462: much protection as global rules, but they can be used to make \fB\-\-delete\fP work
463: better during a client download operation if the per\-dir merge files are
464: included in the transfer and the client requests that they be used.
465: .IP
466: .IP "\fBexclude\fP"
467: This parameter takes a space\-separated list of daemon
468: exclude patterns. As with the client \fB\-\-exclude\fP option, patterns can be
469: qualified with \(dq\&\- \(dq\& or \(dq\&+ \(dq\& to explicitly indicate exclude/include. Only one
470: \(dq\&exclude\(dq\& parameter can apply to a given module. See the \(dq\&filter\(dq\& parameter
471: for a description of how excluded files affect the daemon.
472: .IP
473: .IP "\fBinclude\fP"
474: Use an \(dq\&include\(dq\& to override the effects of the \(dq\&exclude\(dq\&
475: parameter. Only one \(dq\&include\(dq\& parameter can apply to a given module. See the
476: \(dq\&filter\(dq\& parameter for a description of how excluded files affect the daemon.
477: .IP
478: .IP "\fBexclude from\fP"
479: This parameter specifies the name of a file
480: on the daemon that contains daemon exclude patterns, one per line. Only one
481: \(dq\&exclude from\(dq\& parameter can apply to a given module; if you have multiple
482: exclude\-from files, you can specify them as a merge file in the \(dq\&filter\(dq\&
483: parameter. See the \(dq\&filter\(dq\& parameter for a description of how excluded files
484: affect the daemon.
485: .IP
486: .IP "\fBinclude from\fP"
487: Analogue of \(dq\&exclude from\(dq\& for a file of daemon include
488: patterns. Only one \(dq\&include from\(dq\& parameter can apply to a given module. See
489: the \(dq\&filter\(dq\& parameter for a description of how excluded files affect the
490: daemon.
491: .IP
492: .IP "\fBincoming chmod\fP"
493: This parameter allows you to specify a set of
494: comma\-separated chmod strings that will affect the permissions of all
495: incoming files (files that are being received by the daemon). These
496: changes happen after all other permission calculations, and this will
497: even override destination\-default and/or existing permissions when the
498: client does not specify \fB\-\-perms\fP.
499: See the description of the \fB\-\-chmod\fP rsync option and the \fBchmod\fP(1)
500: manpage for information on the format of this string.
501: .IP
502: .IP "\fBoutgoing chmod\fP"
503: This parameter allows you to specify a set of
504: comma\-separated chmod strings that will affect the permissions of all
505: outgoing files (files that are being sent out from the daemon). These
506: changes happen first, making the sent permissions appear to be different
507: than those stored in the filesystem itself. For instance, you could
508: disable group write permissions on the server while having it appear to
509: be on to the clients.
510: See the description of the \fB\-\-chmod\fP rsync option and the \fBchmod\fP(1)
511: manpage for information on the format of this string.
512: .IP
513: .IP "\fBauth users\fP"
514: This parameter specifies a comma and/or space\-separated
515: list of authorization rules. In its simplest form, you list the usernames
516: that will be allowed to connect to
517: this module. The usernames do not need to exist on the local
518: system. The rules may contain shell wildcard characters that will be matched
519: against the username provided by the client for authentication. If
520: \(dq\&auth users\(dq\& is set then the client will be challenged to supply a
521: username and password to connect to the module. A challenge response
522: authentication protocol is used for this exchange. The plain text
523: usernames and passwords are stored in the file specified by the
524: \(dq\&secrets file\(dq\& parameter. The default is for all users to be able to
525: connect without a password (this is called \(dq\&anonymous rsync\(dq\&).
526: .IP
527: In addition to username matching, you can specify groupname matching via a \(cq\&@\(cq\&
528: prefix. When using groupname matching, the authenticating username must be a
529: real user on the system, or it will be assumed to be a member of no groups.
530: For example, specifying \(dq\&@rsync\(dq\& will match the authenticating user if the
531: named user is a member of the rsync group.
532: .IP
533: Finally, options may be specified after a colon (:). The options allow you to
534: \(dq\&deny\(dq\& a user or a group, set the access to \(dq\&ro\(dq\& (read\-only), or set the access
535: to \(dq\&rw\(dq\& (read/write). Setting an auth\-rule\-specific ro/rw setting overrides
536: the module\(cq\&s \(dq\&read only\(dq\& setting.
537: .IP
538: Be sure to put the rules in the order you want them to be matched, because the
539: checking stops at the first matching user or group, and that is the only auth
540: that is checked. For example:
541: .IP
542: .nf
543: auth users = joe:deny @guest:deny admin:rw @rsync:ro susan joe sam
544: .fi
545:
546: .IP
547: In the above rule, user joe will be denied access no matter what. Any user
548: that is in the group \(dq\&guest\(dq\& is also denied access. The user \(dq\&admin\(dq\& gets
549: access in read/write mode, but only if the admin user is not in group \(dq\&guest\(dq\&
550: (because the admin user\-matching rule would never be reached if the user is in
551: group \(dq\&guest\(dq\&). Any other user who is in group \(dq\&rsync\(dq\& will get read\-only
552: access. Finally, users susan, joe, and sam get the ro/rw setting of the
553: module, but only if the user didn\(cq\&t match an earlier group\-matching rule.
554: .IP
555: See the description of the secrets file for how you can have per\-user passwords
556: as well as per\-group passwords. It also explains how a user can authenticate
557: using their user password or (when applicable) a group password, depending on
558: what rule is being authenticated.
559: .IP
560: See also the section entitled \(dq\&USING RSYNC\-DAEMON FEATURES VIA A REMOTE
561: SHELL CONNECTION\(dq\& in \fBrsync\fP(1) for information on how handle an
562: rsyncd.conf\-level username that differs from the remote\-shell\-level
563: username when using a remote shell to connect to an rsync daemon.
564: .IP
565: .IP "\fBsecrets file\fP"
566: This parameter specifies the name of a file that contains
567: the username:password and/or @groupname:password pairs used for authenticating
568: this module. This file is only consulted if the \(dq\&auth users\(dq\& parameter is
569: specified. The file is line\-based and contains one name:password pair per
570: line. Any line has a hash (#) as the very first character on the line is
571: considered a comment and is skipped. The passwords can contain any characters
572: but be warned that many operating systems limit the length of passwords that
573: can be typed at the client end, so you may find that passwords longer than 8
574: characters don\(cq\&t work.
575: .IP
576: The use of group\-specific lines are only relevant when the module is being
577: authorized using a matching \(dq\&@groupname\(dq\& rule. When that happens, the user
578: can be authorized via either their \(dq\&username:password\(dq\& line or the
579: \(dq\&@groupname:password\(dq\& line for the group that triggered the authentication.
580: .IP
581: It is up to you what kind of password entries you want to include, either
582: users, groups, or both. The use of group rules in \(dq\&auth users\(dq\& does not
583: require that you specify a group password if you do not want to use shared
584: passwords.
585: .IP
586: There is no default for the \(dq\&secrets file\(dq\& parameter, you must choose a name
587: (such as \f(CW/etc/rsyncd.secrets\fP). The file must normally not be readable
588: by \(dq\&other\(dq\&; see \(dq\&strict modes\(dq\&. If the file is not found or is rejected, no
589: logins for a \(dq\&user auth\(dq\& module will be possible.
590: .IP
591: .IP "\fBstrict modes\fP"
592: This parameter determines whether or not
593: the permissions on the secrets file will be checked. If \(dq\&strict modes\(dq\& is
594: true, then the secrets file must not be readable by any user ID other
595: than the one that the rsync daemon is running under. If \(dq\&strict modes\(dq\& is
596: false, the check is not performed. The default is true. This parameter
597: was added to accommodate rsync running on the Windows operating system.
598: .IP
599: .IP "\fBhosts allow\fP"
600: This parameter allows you to specify a
601: list of patterns that are matched against a connecting clients
602: hostname and IP address. If none of the patterns match then the
603: connection is rejected.
604: .IP
605: Each pattern can be in one of five forms:
606: .IP
607: .RS
608: .IP o
609: a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address
610: of the form a:b:c::d:e:f. In this case the incoming machine\(cq\&s IP address
611: must match exactly.
612: .IP o
613: an address/mask in the form ipaddr/n where ipaddr is the IP address
614: and n is the number of one bits in the netmask. All IP addresses which
615: match the masked IP address will be allowed in.
616: .IP o
617: an address/mask in the form ipaddr/maskaddr where ipaddr is the
618: IP address and maskaddr is the netmask in dotted decimal notation for IPv4,
619: or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP
620: addresses which match the masked IP address will be allowed in.
621: .IP o
622: a hostname pattern using wildcards. If the hostname of the connecting IP
623: (as determined by a reverse lookup) matches the wildcarded name (using the
624: same rules as normal unix filename matching), the client is allowed in. This
625: only works if \(dq\&reverse lookup\(dq\& is enabled (the default).
626: .IP o
627: a hostname. A plain hostname is matched against the reverse DNS of the
628: connecting IP (if \(dq\&reverse lookup\(dq\& is enabled), and/or the IP of the given
629: hostname is matched against the connecting IP (if \(dq\&forward lookup\(dq\& is
630: enabled, as it is by default). Any match will be allowed in.
631: .RE
632:
633: .IP
634: Note IPv6 link\-local addresses can have a scope in the address specification:
635: .IP
636: .RS
637: \f(CW fe80::1%link1\fP
638: .br
639: \f(CW fe80::%link1/64\fP
640: .br
641: \f(CW fe80::%link1/ffff:ffff:ffff:ffff::\fP
642: .br
643: .RE
644:
645: .IP
646: You can also combine \(dq\&hosts allow\(dq\& with a separate \(dq\&hosts deny\(dq\&
647: parameter. If both parameters are specified then the \(dq\&hosts allow\(dq\& parameter is
648: checked first and a match results in the client being able to
649: connect. The \(dq\&hosts deny\(dq\& parameter is then checked and a match means
650: that the host is rejected. If the host does not match either the
651: \(dq\&hosts allow\(dq\& or the \(dq\&hosts deny\(dq\& patterns then it is allowed to
652: connect.
653: .IP
654: The default is no \(dq\&hosts allow\(dq\& parameter, which means all hosts can connect.
655: .IP
656: .IP "\fBhosts deny\fP"
657: This parameter allows you to specify a
658: list of patterns that are matched against a connecting clients
659: hostname and IP address. If the pattern matches then the connection is
660: rejected. See the \(dq\&hosts allow\(dq\& parameter for more information.
661: .IP
662: The default is no \(dq\&hosts deny\(dq\& parameter, which means all hosts can connect.
663: .IP
664: .IP "\fBreverse lookup\fP"
665: Controls whether the daemon performs a reverse lookup
666: on the client\(cq\&s IP address to determine its hostname, which is used for
667: \(dq\&hosts allow\(dq\&/\(dq\&hosts deny\(dq\& checks and the \(dq\&%h\(dq\& log escape. This is enabled by
668: default, but you may wish to disable it to save time if you know the lookup will
669: not return a useful result, in which case the daemon will use the name
670: \(dq\&UNDETERMINED\(dq\& instead.
671: .IP
672: If this parameter is enabled globally (even by default), rsync performs the
673: lookup as soon as a client connects, so disabling it for a module will not
674: avoid the lookup. Thus, you probably want to disable it globally and then
675: enable it for modules that need the information.
676: .IP
677: .IP "\fBforward lookup\fP"
678: Controls whether the daemon performs a forward lookup
679: on any hostname specified in an hosts allow/deny setting. By default this is
680: enabled, allowing the use of an explicit hostname that would not be returned
681: by reverse DNS of the connecting IP.
682: .IP
683: .IP "\fBignore errors\fP"
684: This parameter tells rsyncd to
685: ignore I/O errors on the daemon when deciding whether to run the delete
686: phase of the transfer. Normally rsync skips the \fB\-\-delete\fP step if any
687: I/O errors have occurred in order to prevent disastrous deletion due
688: to a temporary resource shortage or other I/O error. In some cases this
689: test is counter productive so you can use this parameter to turn off this
690: behavior.
691: .IP
692: .IP "\fBignore nonreadable\fP"
693: This tells the rsync daemon to completely
694: ignore files that are not readable by the user. This is useful for
695: public archives that may have some non\-readable files among the
696: directories, and the sysadmin doesn\(cq\&t want those files to be seen at all.
697: .IP
698: .IP "\fBtransfer logging\fP"
699: This parameter enables per\-file
700: logging of downloads and uploads in a format somewhat similar to that
701: used by ftp daemons. The daemon always logs the transfer at the end, so
702: if a transfer is aborted, no mention will be made in the log file.
703: .IP
704: If you want to customize the log lines, see the \(dq\&log format\(dq\& parameter.
705: .IP
706: .IP "\fBlog format\fP"
707: This parameter allows you to specify the
708: format used for logging file transfers when transfer logging is enabled.
709: The format is a text string containing embedded single\-character escape
710: sequences prefixed with a percent (%) character. An optional numeric
711: field width may also be specified between the percent and the escape
712: letter (e.g. \(dq\&\fB%\-50n %8l %07p\fP\(dq\&).
713: In addition, one or more apostrophes may be specified prior to a numerical
714: escape to indicate that the numerical value should be made more human\-readable.
715: The 3 supported levels are the same as for the \fB\-\-human\-readable\fP
716: command\-line option, though the default is for human\-readability to be off.
717: Each added apostrophe increases the level (e.g. \(dq\&\fB%'\&'\&l %'\&b %f\fP\(dq\&).
718: .IP
719: The default log format is \(dq\&%o %h [%a] %m (%u) %f %l\(dq\&, and a \(dq\&%t [%p] \(dq\&
720: is always prefixed when using the \(dq\&log file\(dq\& parameter.
721: (A perl script that will summarize this default log format is included
722: in the rsync source code distribution in the \(dq\&support\(dq\& subdirectory:
723: rsyncstats.)
724: .IP
725: The single\-character escapes that are understood are as follows:
726: .IP
727: .RS
728: .IP o
729: %a the remote IP address (only available for a daemon)
730: .IP o
731: %b the number of bytes actually transferred
732: .IP o
733: %B the permission bits of the file (e.g. rwxrwxrwt)
734: .IP o
735: %c the total size of the block checksums received for the basis file (only when sending)
736: .IP o
737: %C the full\-file MD5 checksum if \fB\-\-checksum\fP is enabled or a file was transferred (only for protocol 30 or above).
738: .IP o
739: %f the filename (long form on sender; no trailing \(dq\&/\(dq\&)
740: .IP o
741: %G the gid of the file (decimal) or \(dq\&DEFAULT\(dq\&
742: .IP o
743: %h the remote host name (only available for a daemon)
744: .IP o
745: %i an itemized list of what is being updated
746: .IP o
747: %l the length of the file in bytes
748: .IP o
749: %L the string \(dq\& \-> SYMLINK\(dq\&, \(dq\& => HARDLINK\(dq\&, or \(dq\&\(dq\& (where \fBSYMLINK\fP or \fBHARDLINK\fP is a filename)
750: .IP o
751: %m the module name
752: .IP o
753: %M the last\-modified time of the file
754: .IP o
755: %n the filename (short form; trailing \(dq\&/\(dq\& on dir)
756: .IP o
757: %o the operation, which is \(dq\&send\(dq\&, \(dq\&recv\(dq\&, or \(dq\&del.\(dq\& (the latter includes the trailing period)
758: .IP o
759: %p the process ID of this rsync session
760: .IP o
761: %P the module path
762: .IP o
763: %t the current date time
764: .IP o
765: %u the authenticated username or an empty string
766: .IP o
767: %U the uid of the file (decimal)
768: .RE
769:
770: .IP
771: For a list of what the characters mean that are output by \(dq\&%i\(dq\&, see the
772: \fB\-\-itemize\-changes\fP option in the rsync manpage.
773: .IP
774: Note that some of the logged output changes when talking with older
775: rsync versions. For instance, deleted files were only output as verbose
776: messages prior to rsync 2.6.4.
777: .IP
778: .IP "\fBtimeout\fP"
779: This parameter allows you to override the
780: clients choice for I/O timeout for this module. Using this parameter you
781: can ensure that rsync won\(cq\&t wait on a dead client forever. The timeout
782: is specified in seconds. A value of zero means no timeout and is the
783: default. A good choice for anonymous rsync daemons may be 600 (giving
784: a 10 minute timeout).
785: .IP
786: .IP "\fBrefuse options\fP"
787: This parameter allows you to
788: specify a space\-separated list of rsync command line options that will
789: be refused by your rsync daemon.
790: You may specify the full option name, its one\-letter abbreviation, or a
791: wild\-card string that matches multiple options.
792: For example, this would refuse \fB\-\-checksum\fP (\fB\-c\fP) and all the various
793: delete options:
794: .IP
795: .RS
796: \f(CW refuse options = c delete\fP
797: .RE
798:
799: .IP
800: The reason the above refuses all delete options is that the options imply
801: \fB\-\-delete\fP, and implied options are refused just like explicit options.
802: As an additional safety feature, the refusal of \(dq\&delete\(dq\& also refuses
803: \fBremove\-source\-files\fP when the daemon is the sender; if you want the latter
804: without the former, instead refuse \(dq\&delete\-*\(dq\& \-\- that refuses all the
805: delete modes without affecting \fB\-\-remove\-source\-files\fP.
806: .IP
807: When an option is refused, the daemon prints an error message and exits.
808: To prevent all compression when serving files,
809: you can use \(dq\&dont compress = *\(dq\& (see below)
810: instead of \(dq\&refuse options = compress\(dq\& to avoid returning an error to a
811: client that requests compression.
812: .IP
813: .IP "\fBdont compress\fP"
814: This parameter allows you to select
815: filenames based on wildcard patterns that should not be compressed
816: when pulling files from the daemon (no analogous parameter exists to
817: govern the pushing of files to a daemon).
818: Compression is expensive in terms of CPU usage, so it
819: is usually good to not try to compress files that won\(cq\&t compress well,
820: such as already compressed files.
821: .IP
822: The \(dq\&dont compress\(dq\& parameter takes a space\-separated list of
823: case\-insensitive wildcard patterns. Any source filename matching one
824: of the patterns will not be compressed during transfer.
825: .IP
826: See the \fB\-\-skip\-compress\fP parameter in the \fBrsync\fP(1) manpage for the list
827: of file suffixes that are not compressed by default. Specifying a value
828: for the \(dq\&dont compress\(dq\& parameter changes the default when the daemon is
829: the sender.
830: .IP
831: .IP "\fBpre\-xfer exec\fP, \fBpost\-xfer exec\fP"
832: You may specify a command to be run
833: before and/or after the transfer. If the \fBpre\-xfer exec\fP command fails, the
834: transfer is aborted before it begins. Any output from the script on stdout (up
835: to several KB) will be displayed to the user when aborting, but is NOT
836: displayed if the script returns success. Any output from the script on stderr
837: goes to the daemon\(cq\&s stderr, which is typically discarded (though see
838: \-\-no\-detatch option for a way to see the stderr output, which can assist with
839: debugging).
840: .IP
841: The following environment variables will be set, though some are
842: specific to the pre\-xfer or the post\-xfer environment:
843: .IP
844: .RS
845: .IP o
846: \fBRSYNC_MODULE_NAME\fP: The name of the module being accessed.
847: .IP o
848: \fBRSYNC_MODULE_PATH\fP: The path configured for the module.
849: .IP o
850: \fBRSYNC_HOST_ADDR\fP: The accessing host\(cq\&s IP address.
851: .IP o
852: \fBRSYNC_HOST_NAME\fP: The accessing host\(cq\&s name.
853: .IP o
854: \fBRSYNC_USER_NAME\fP: The accessing user\(cq\&s name (empty if no user).
855: .IP o
856: \fBRSYNC_PID\fP: A unique number for this transfer.
857: .IP o
858: \fBRSYNC_REQUEST\fP: (pre\-xfer only) The module/path info specified
859: by the user. Note that the user can specify multiple source files,
860: so the request can be something like \(dq\&mod/path1 mod/path2\(dq\&, etc.
861: .IP o
862: \fBRSYNC_ARG#\fP: (pre\-xfer only) The pre\-request arguments are set
863: in these numbered values. RSYNC_ARG0 is always \(dq\&rsyncd\(dq\&, followed by
864: the options that were used in RSYNC_ARG1, and so on. There will be a
865: value of \(dq\&.\(dq\& indicating that the options are done and the path args
866: are beginning \-\- these contain similar information to RSYNC_REQUEST,
867: but with values separated and the module name stripped off.
868: .IP o
869: \fBRSYNC_EXIT_STATUS\fP: (post\-xfer only) the server side\(cq\&s exit value.
870: This will be 0 for a successful run, a positive value for an error that the
871: server generated, or a \-1 if rsync failed to exit properly. Note that an
872: error that occurs on the client side does not currently get sent to the
873: server side, so this is not the final exit status for the whole transfer.
874: .IP o
875: \fBRSYNC_RAW_STATUS\fP: (post\-xfer only) the raw exit value from
876: \f(CWwaitpid()\fP
877: \&.
878: .RE
879:
880: .IP
881: Even though the commands can be associated with a particular module, they
882: are run using the permissions of the user that started the daemon (not the
883: module\(cq\&s uid/gid setting) without any chroot restrictions.
884: .IP
885: .SH "CONFIG DIRECTIVES"
886:
887: .PP
888: There are currently two config directives available that allow a config file to
889: incorporate the contents of other files: \fB&include\fP and \fB&merge\fP. Both
890: allow a reference to either a file or a directory. They differ in how
891: segregated the file\(cq\&s contents are considered to be.
892: .PP
893: The \fB&include\fP directive treats each file as more distinct, with each one
894: inheriting the defaults of the parent file, starting the parameter parsing
895: as globals/defaults, and leaving the defaults unchanged for the parsing of
896: the rest of the parent file.
897: .PP
898: The \fB&merge\fP directive, on the other hand, treats the file\(cq\&s contents as
899: if it were simply inserted in place of the directive, and thus it can set
900: parameters in a module started in another file, can affect the defaults for
901: other files, etc.
902: .PP
903: When an \fB&include\fP or \fB&merge\fP directive refers to a directory, it will read
904: in all the \fB*.conf\fP or \fB*.inc\fP files (respectively) that are contained inside
905: that directory (without any
906: recursive scanning), with the files sorted into alpha order. So, if you have a
907: directory named \(dq\&rsyncd.d\(dq\& with the files \(dq\&foo.conf\(dq\&, \(dq\&bar.conf\(dq\&, and
908: \(dq\&baz.conf\(dq\& inside it, this directive:
909: .PP
910: .nf
911: &include /path/rsyncd.d
912: .fi
913:
914: .PP
915: would be the same as this set of directives:
916: .PP
917: .nf
918: &include /path/rsyncd.d/bar.conf
919: &include /path/rsyncd.d/baz.conf
920: &include /path/rsyncd.d/foo.conf
921: .fi
922:
923: .PP
924: except that it adjusts as files are added and removed from the directory.
925: .PP
926: The advantage of the \fB&include\fP directive is that you can define one or more
927: modules in a separate file without worrying about unintended side\-effects
928: between the self\-contained module files.
929: .PP
930: The advantage of the \fB&merge\fP directive is that you can load config snippets
931: that can be included into multiple module definitions, and you can also set
932: global values that will affect connections (such as \fBmotd file\fP), or globals
933: that will affect other include files.
934: .PP
935: For example, this is a useful /etc/rsyncd.conf file:
936: .PP
937: .nf
938: port = 873
939: log file = /var/log/rsync.log
940: pid file = /var/lock/rsync.lock
941:
942: &merge /etc/rsyncd.d
943: &include /etc/rsyncd.d
944: .fi
945:
946: .PP
947: This would merge any /etc/rsyncd.d/*.inc files (for global values that should
948: stay in effect), and then include any /etc/rsyncd.d/*.conf files (defining
949: modules without any global\-value cross\-talk).
950: .PP
951: .SH "AUTHENTICATION STRENGTH"
952:
953: .PP
954: The authentication protocol used in rsync is a 128 bit MD4 based
955: challenge response system. This is fairly weak protection, though (with
956: at least one brute\-force hash\-finding algorithm publicly available), so
957: if you want really top\-quality security, then I recommend that you run
958: rsync over ssh. (Yes, a future version of rsync will switch over to a
959: stronger hashing method.)
960: .PP
961: Also note that the rsync daemon protocol does not currently provide any
962: encryption of the data that is transferred over the connection. Only
963: authentication is provided. Use ssh as the transport if you want
964: encryption.
965: .PP
966: Future versions of rsync may support SSL for better authentication and
967: encryption, but that is still being investigated.
968: .PP
969: .SH "EXAMPLES"
970:
971: .PP
972: A simple rsyncd.conf file that allow anonymous rsync to a ftp area at
973: \f(CW/home/ftp\fP would be:
974: .PP
975: .nf
976:
977: [ftp]
978: path = /home/ftp
979: comment = ftp export area
980:
981: .fi
982:
983: .PP
984: A more sophisticated example would be:
985: .PP
986: .nf
987:
988: uid = nobody
989: gid = nobody
990: use chroot = yes
991: max connections = 4
992: syslog facility = local5
993: pid file = /var/run/rsyncd.pid
994:
995: [ftp]
996: path = /var/ftp/./pub
997: comment = whole ftp area (approx 6.1 GB)
998:
999: [sambaftp]
1000: path = /var/ftp/./pub/samba
1001: comment = Samba ftp area (approx 300 MB)
1002:
1003: [rsyncftp]
1004: path = /var/ftp/./pub/rsync
1005: comment = rsync ftp area (approx 6 MB)
1006:
1007: [sambawww]
1008: path = /public_html/samba
1009: comment = Samba WWW pages (approx 240 MB)
1010:
1011: [cvs]
1012: path = /data/cvs
1013: comment = CVS repository (requires authentication)
1014: auth users = tridge, susan
1015: secrets file = /etc/rsyncd.secrets
1016:
1017: .fi
1018:
1019: .PP
1020: The /etc/rsyncd.secrets file would look something like this:
1021: .PP
1022: .RS
1023: \f(CWtridge:mypass\fP
1024: .br
1025: \f(CWsusan:herpass\fP
1026: .br
1027: .RE
1028:
1029: .PP
1030: .SH "FILES"
1031:
1032: .PP
1033: /etc/rsyncd.conf or rsyncd.conf
1034: .PP
1035: .SH "SEE ALSO"
1036:
1037: .PP
1038: \fBrsync\fP(1)
1039: .PP
1040: .SH "DIAGNOSTICS"
1041:
1042: .PP
1043: .SH "BUGS"
1044:
1045: .PP
1046: Please report bugs! The rsync bug tracking system is online at
1047: http://rsync.samba.org/
1048: .PP
1049: .SH "VERSION"
1050:
1051: .PP
1052: This man page is current for version 3.1.2 of rsync.
1053: .PP
1054: .SH "CREDITS"
1055:
1056: .PP
1057: rsync is distributed under the GNU General Public License. See the file
1058: COPYING for details.
1059: .PP
1060: The primary ftp site for rsync is
1061: ftp://rsync.samba.org/pub/rsync.
1062: .PP
1063: A WEB site is available at
1064: http://rsync.samba.org/
1065: .PP
1066: We would be delighted to hear from you if you like this program.
1067: .PP
1068: This program uses the zlib compression library written by Jean\-loup
1069: Gailly and Mark Adler.
1070: .PP
1071: .SH "THANKS"
1072:
1073: .PP
1074: Thanks to Warren Stanley for his original idea and patch for the rsync
1075: daemon. Thanks to Karsten Thygesen for his many suggestions and
1076: documentation!
1077: .PP
1078: .SH "AUTHOR"
1079:
1080: .PP
1081: rsync was written by Andrew Tridgell and Paul Mackerras.
1082: Many people have later contributed to it.
1083: .PP
1084: Mailing lists for support and development are available at
1085: http://lists.samba.org
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to rsyncd.conf.5 CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / rsync