The configuration part should also be valid for other main Linux distributions, such as Fedora. A machine with a Debian based Linux distro installed and updated, that will function as the rsync server, and another Linux machine with rsync installed, which will be the rsync client to test connectivity.
After installing rsync , it is needed to create and edit a pair of files, the first one being the configuration file as it is not created automatically upon installation. The word public , in brackets, is the given name to the module, the area s that will be available to reach from the rsync client. These users do not have to necessarily exist on the system. These are rsync users that should be listed in the secrets file that is described in the next line of the configuration file.
The format is as follow:. Once you have the secret files created, we need to protect it from unwanted eyes — yes, it is in plain text. Now, as stated in the beginning of the article, rsync is used to perform backups.
Usually backup of files over the network, to an rsync backup server using scheduled jobs to do so. I will detail that in another article, as it is out of scope for this one. Your email address will not be published. You can lock this down using something like iptables -uid-owner root rules for strict localhost access , various firewall rules, or you can require password authorization so that any spoofing by users will not grant extra access.
This setting is global. If you need some modules to require this and not others, then you will need to setup multiple rsync daemon processes on different ports.
This script is started prior to any chroot being setup, and runs as the daemon user not the transfer user. The nameconvert program has access to all of the environment variables that are described in the section on pre-xfer exec.
Feel free to customize it or just use it as documentation to implement your own. Enabling this parameter disables the mapping of users and groups by name for the current daemon module. This enabling makes the transfer behave as if the client had passed the --numeric-ids command-line option. By default, this parameter is enabled for chroot modules and disabled for non-chroot modules.
A chroot-enabled module should not have this parameter set to false unless you're using a "name converter" program or you've taken steps to ensure that the module has the necessary resources it needs to translate names and that it is not possible for a user to change those resources. This parameter tells rsync to modify all symlinks in the same way as the non-daemon-affecting --munge-links command-line option using a method described below. This should help protect your files from user trickery when your daemon module is writable.
If you disable this parameter on a daemon that is not read-only, there are tricks that a user can play with uploaded symlinks to access daemon-excluded items if your module has any , and, if "use chroot" is off, rsync can even be tricked into showing or changing data that is outside the module's path as access-permissions allow.
This prevents the links from being used as long as that directory does not exist. When this parameter is enabled, rsync will refuse to run if that path is a directory or a symlink to a directory.
Note: rsync makes no attempt to verify that any pre-existing symlinks in the module's hierarchy are as safe as you want them to be unless, of course, it just copied in the whole hierarchy.
There is a perl script in the support directory of the source code named "munge-symlinks" that can be used to add or remove this prefix from your symlinks. There are tricky ways to work around this, though, so you had better trust your users if you choose this combination of parameters. This specifies the name of the character set in which the module's filenames are stored. If the client uses an --iconv option, the daemon will use the value of the "charset" parameter regardless of the character set the client actually passed.
This allows the daemon to support charset conversion in a chroot module without extra files in the chroot area, and also ensures that name-translation is done in a consistent manner.
If the "charset" parameter is not set, the --iconv option is refused, just as if "iconv" had been specified via "refuse options". If you wish to force users to always use --iconv for a particular module, add "no-iconv" to the "refuse options" parameter. Keep in mind that this will restrict access to your module to very new rsync clients. This parameter allows you to specify the maximum number of simultaneous connections you will allow. Any clients connecting when the maximum has been reached will receive a message telling them to try later.
The default is 0, which means no limit. A negative value disables the module. See also the "lock file" parameter. When the "log file" parameter is set to a non-empty string, the rsync daemon will log messages to the indicated file rather than using syslog. This is particularly useful on systems such as AIX where syslog doesn't work for chrooted programs.
The file is opened before chroot is called, allowing it to be placed outside the transfer. If this value is set on a per-module basis instead of globally, the global log will still contain any authorization failures or config-file error messages. If the daemon fails to open the specified file, it will fall back to using syslog and output an error about the failure.
Note that the failure to open the specified log file used to be a fatal error. The former overrides all the log-file parameters of the daemon and all module settings. The latter sets the daemon's log file and the default for all the modules, which still allows modules to override the default setting. This parameter allows you to specify the syslog facility name to use when logging messages from the rsync daemon. You may use any standard syslog facility name which is defined on your system.
Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7. The default is daemon. This setting has no effect if the "log file" setting is a non-empty string either set in the per-modules settings, or inherited from the global settings. This parameter allows you to specify the syslog tag to use when logging messages from the rsync daemon. The default is "rsyncd".
For example, if you wanted each authenticated user's name to be included in the syslog tag, you could do something like this:. This parameter allows you to control the maximum amount of verbose information that you'll allow the daemon to generate since the information goes into the log file.
The default is 1, which allows the client to request one level of verbosity. This also affects the user's ability to request higher levels of --info and --debug logging. This parameter specifies the file to use to support the "max connections" parameter. The rsync daemon uses record locking on this file to ensure that the max connections limit is not exceeded for the modules sharing the lock file.
This parameter determines whether clients will be able to upload files or not. If "read only" is true then any attempted uploads will fail. If "read only" is false then uploads will be possible if file permissions on the daemon side allow them. The default is for all modules to be read only. This parameter determines whether clients will be able to download files or not. If "write only" is true then any attempted downloads will fail. If "write only" is false then downloads will be possible if file permissions on the daemon side allow them.
The default is for this parameter to be disabled. This parameter determines whether this module is listed when the client asks for a listing of available modules. In addition, if this is false, the daemon will pretend the module does not exist when a client denied by "hosts allow" or "hosts deny" attempts to access it. Realize that if "reverse lookup" is disabled globally but enabled for the module, the resulting reverse lookup to a potentially client-controlled DNS server may still reveal to the client that it hit an existing module.
The default is for modules to be listable. This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. In combination with the "gid" parameter this determines what file permissions are available. The default when run by a super-user is to switch to the system's "nobody" user. The default for a non-super-user is to not try to change the user.
See also the "gid" parameter. For example, if you want a rsync to run as the same user that was received for the rsync authentication, this setup is useful:. The first one will be the default group, and any extra ones be set as supplemental groups. While this is not recommended for the transfer of files across unsecured networks, such as the Internet, because the actual data transfer is not encrypted, we can use this to keep information synchronized between different computers in internal networks, as well as perform backups.
There are two different approaches to have rsync running as a daemon, one is to launch the program with the --daemon parameter, and the other is to have inetd or xinetd to launch rsync and have it running as the other services that inetd and xinetd handles. All the uses that were covered in the post Synchronizing folders with rsync can be done with the rsync daemon, the only thing that changes is the addressing of either the source folder or the destination folder, whichever is the one that resides remotely.
Topics Configuring rsyncd. We open the file in our preferred text editor, I am going to use gedit for the examples but we can use any editor such as kate in KDE, nano in a terminal, Vim, etc.
We can divide this file in two sections, the global parameters and the modules section. In its simplest form, you list the usernames that will be allowed to connect to this module. The usernames do not need to exist on the local system. The rules may contain shell wildcard characters that will be matched against the username provided by the client for authentication. If "auth users" is set then the client will be challenged to supply a username and password to connect to the module.
A challenge response authentication protocol is used for this exchange. The plain text usernames and passwords are stored in the file specified by the "secrets file" parameter.
The default is for all users to be able to connect without a password this is called "anonymous rsync". When using groupname matching, the authenticating username must be a real user on the system, or it will be assumed to be a member of no groups. For example, specifying " rsync" will match the authenticating user if the named user is a member of the rsync group.
Finally, options may be specified after a colon :. Be sure to put the rules in the order you want them to be matched, because the checking stops at the first matching user or group, and that is the only auth that is checked. Any user that is in the group "guest" is also denied access.
Any other user who is in group "rsync" will get read-only access. See the description of the secrets file for how you can have per-user passwords as well as per-group passwords. It also explains how a user can authenticate using their user password or when applicable a group password, depending on what rule is being authenticated.
This file is only consulted if the "auth users" parameter is specified. The file is line-based and contains one name:password pair per line. Any line has a hash as the very first character on the line is considered a comment and is skipped. The use of group-specific lines are only relevant when the module is being authorized using a matching " groupname" rule. When that happens, the user can be authorized via either their "username:password" line or the " groupname:password" line for the group that triggered the authentication.
It is up to you what kind of password entries you want to include, either users, groups, or both. The use of group rules in "auth users" does not require that you specify a group password if you do not want to use shared passwords.
The file must normally not be readable by "other"; see "strict modes". If the file is not found or is rejected, no logins for a "user auth" module will be possible. If "strict modes" is true, then the secrets file must not be readable by any user ID other than the one that the rsync daemon is running under.
If "strict modes" is false, the check is not performed. The default is true. This parameter was added to accommodate rsync running on the Windows operating system. If none of the patterns match then the connection is rejected. Each pattern can be in one of five forms: o a dotted decimal IPv4 address of the form a.
All IP addresses which match the masked IP address will be allowed in. If the hostname of the connecting IP as determined by a reverse lookup matches the wildcarded name using the same rules as normal unix filename matching , the client is allowed in.
This only works if "reverse lookup" is enabled the default. Any match will be allowed in. If both parameters are specified then the "hosts allow" parameter is checked first and a match results in the client being able to connect. The "hosts deny" parameter is then checked and a match means that the host is rejected. If the host does not match either the "hosts allow" or the "hosts deny" patterns then it is allowed to connect.
The default is no "hosts allow" parameter, which means all hosts can connect. If the pattern matches then the connection is rejected. See the "hosts allow" parameter for more information. The default is no "hosts deny" parameter, which means all hosts can connect.
If this parameter is enabled globally even by default , rsync performs the lookup as soon as a client connects, so disabling it for a module will not avoid the lookup. Thus, you probably want to disable it globally and then enable it for modules that need the information. By default this is enabled, allowing the use of an explicit hostname that would not be returned by reverse DNS of the connecting IP.
In some cases this test is counter productive so you can use this parameter to turn off this behavior. The daemon always logs the transfer at the end, so if a transfer is aborted, no mention will be made in the log file.
0コメント