In a previous article we saw some basic examples of how to use rsync on Linux to transfer data efficiently. As we saw, to synchronize data with a remote machine we can use both a remote shell as ssh or the rsync daemon. In this article we will focus on the latter option, and we will see how to install and configure rsyncd on some of the most used Linux distributions.
In this tutorial you will learn:
- How to install and configure the rsync daemon
Software Requirements and Conventions Used
| Category | Requirements, Conventions or Software Version Used |
|---|---|
| System | Distribution-independent |
| Software |
|
| Other | No special requirements are needed to follow this tutorial |
| Conventions | # – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command$ – requires given linux commands to be executed as a regular non-privileged user |
Installation
Installing the rsync daemon is really easy, since the package and its dependencies are available by default in the all the major Linux distributions repositories. On Debian and Archlinux, the files related to the rsync daemon are included the rsync package, so all we have to do, is to install the latter. On Debian we can use the apt package manager:
$ sudo apt-get install rsync
On Archlinux, instead, we use pacman:
$ sudo pacman -S rsync
On distributions like Fedora, instead, rsyncd, the rsync daemon, is distributed in its own package, rsync-daemon. In recent versions of the distribution, to install it, we can use the dnf package manager. The main rsync package will be installed as a dependency:
$ sudo dnf install rsync-daemon
The rsyncd configuration file
Once rsyncd is installed, we can configure it using the /etc/rsyncd.conf file. The file is already included in the Archlinux and Fedora packages, while on Debian it must be created from scratch. Here is the content of the file on Fedora:
# /etc/rsyncd: configuration file for rsync daemon mode # See rsyncd.conf man page for more options. # configuration example: # uid = nobody # gid = nobody # use chroot = yes # max connections = 4 # pid file = /var/run/rsyncd.pid # exclude = lost+found/ # transfer logging = yes # timeout = 900 # ignore nonreadable = yes # dont compress = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2 # [ftp] # path = /home/ftp # comment = ftp export area
All the parameters are commented, and displayed as a configuration example: they represent a good starting point for our discussion. The first thing we must notice is how an rsyncd module is defined:
[ftp]
path = /home/ftp
comment = ftp export area
A module is defined in a “stanza” which begins with the declaration of the module name between square brackets, in this case [ftp]. A module is associated with a directory in the filesystem, specified with the path argument. All the parameters provided inside the stanza are local, so they are applied to the related module only; settings provided before any stanzas, are global. Let’s take a quick look at some of them.
Global parameters
As we just said, global parameters are those defined at the beginning of the /etc/rsyncd.conf file, before any module definition, or optionally inside a [global] section. Here we will discuss some of the most interesting ones.
The “pid file” parameter
This parameter is used to specify the path of a file where the rsyncd PID (Process ID) will be written. By default, the daemon launch will be aborted if the specified file already exists. It’s possible to change this behavior, and let the file be overwritten, instead, by launching the rsync daemon with the --dparam=pid‐file=FILE option.
The “port” parameter
By using this global parameter, we can specify an alternative port for the rsync daemon. The default is TCP port 873. This option can be overridden when the daemon is launched, by using the --port option.
The “address” parameter
We can use the global address parameter to specify the address the rsync daemon will listen to. The address specified in the file can be overridden by launching the daemon with the --address option, providing the desired address as argument.
In addition to the parameters we saw above, in the global section, we can specify also module parameters. When we do so, the specified parameters values will become the default ones for all the modules.
Module parameters
The module parameters are those specified inside a module section and are applied to that section only. Let’s see some of them.
The “path” parameter
This parameter is mandatory and must be provided for each module. It is used to specify the path of the directory made available by the module itself.
The “comment” parameter
The “comment” parameter is optional: we can specify a string that will be displayed near the name of the module, when the client requests a list of the available ones.
Make a module read or write only
By default, all modules are created as read-only. This means that a client can only use it as a source for the transfer. This behavior can be changed by setting the “read only” parameter to no or false. The module can also be made write-only, by using the write only parameter and providing yes or true as value. If this latter parameter is activated, the client will not be able to download files from the module. In order to read files from the module or write to it, the standard unix permissions must be also be respected, so, the user the transfer is run as, must be allowed to perform the desired action.
The uid and gid parameters
The uid and gid parameters combined, define the privileges the transfer will have. The former is used to define the user the transfer is run as when the daemon is run as root (if the daemon is run with the privileges of a normal user, the user will not change). The user can be identified by its username, or its numeric id. The latter defines one or more group name or group id to be used for the transfer.
The default value for both options is nobody, meaning that when the daemon is run as root, the transfers will be run with the privileges of the nobody user and the nobody group (on Debian the nobody group doesn’t exist – nogroup is used instead).
The “use chroot” parameter
By using the use chroot parameter, we can define if rsync should chroot to the the defined module path before the transfer is started. This can be used to enforce security, but to take advantage of it, the daemon must be configured to run with root privileges. By default this option is set to yes.
The “max connections” parameter
This is another very useful parameter, and it’s used to define the maximum number of simultaneous connections supported by the daemon. The default value used for the parameter is 0, meaning that no limit is set. If the provided value is a negative number, the connections are disabled completely.
Exclude and include files from the transfer
Sometimes we may want to exclude some files from the transfer: we can accomplish the task by using the exclude parameter, which accepts a space-separated list of patterns. The files matched by the patterns will not be synced. The include parameter works in the same way but it is used to explicitly define inclusions.
Another way of excluding or explicitly including files is by using the exclude from and include from parameters. With this parameters we can specify the path of files containing exclusion and inclusion patterns, respectively. The files must contain one pattern per line.
The exclude, include, exclude from and include from parameters can appear only once inside a module.
The “timeout” parameter
When we use the rsync client we can provide the--timeout option to set a maximum I/O timeout in seconds: if no data is transferred in the specified time, the transfer is aborted. The timeout option of the rsync daemon can be used to override the timeout defined by the client. This can be useful to avoid waiting for a dead client indeterminately. The timeout is expressed in seconds: 0 is the default, and it means no timeout.
The “ignore nonreadable” and “dont compress”
The ignore nonreadable option is used instruct rsync to ignore files that are not readable by the user the transfer is running as. The dont compress option, instead, is used to provide a space separated list of case-insensitive patterns used to select files that must not be compressed during the transfer. This can be especially useful to avoid compressing already compressed files.
The “hosts allow” and “hosts deny” parameters
By using the hosts allow and hosts deny parameters, we can specify a list of comma-separated patterns that will be matched against clients hostname or IP, to allow or deny access to them, respectively. The two parameters can be combined and appear together inside a module: the “allow” patterns are checked before the “deny” ones. By default, all hosts are allowed to connect.
Example of a module configuration
Let’s make an example and create a module on a rsync server. The first thing we must do is to allow incoming traffic on TCP port 873. If we are using firewalld we can add the pre-configured rsyncd service to the zone we are using:
$ sudo firewall-cmd --permanent --add-service rsyncd && sudo firewall-cmd --reload
If we are using ufw, instead, we can run:
$ sudo ufw allow 873/tcp
Once we configured the firewall, we can proceed and define a module. Here is our configuration:
[linuxconfig] path = /mnt/data/rsync comment = "Example of an rsync daemon module" read only = false exclude = *.txt
We called our module “linuxconfig” and we associated the /mnt/data/rsync directory to it. We also provided a comment. We set the module both readable and writable by setting the read only parameter to false, and, via the exclude parameter, we provided a pattern to exclude all files with the .txt extension.
Before we use our module we need to start the daemon. We can run rsync as a daemon by invoking the program with the --daemon option, or we can simply use systemd to accomplish the task (under the hood the systemd service does execute the same command). Under Debian based distributions, the service is called rsync; on Fedora and Archlinux, it is called rsyncd:
$ sudo systemctl start rsync
To make rsync start automatically at boot, we must use the systemctl enable subcommand:
$ sudo systemctl enable rsync
We set the /mnt/data/rsync directory as owned by the nobody user and the nogroup group (it’s a Debian machine). Here is its content:
$ ls /mnt/data/rsync csv1.csv text1.txt text2.txt
As we can see the directory contains two .txt files and one .csv. If we use the module as the source in the transfer, only the “csv1.csv” file will be included:
$ rsync -av rsync://192.168.0.39/linuxconfig/ . receiving incremental file list ./ csv1.csv
The exclusion take effect also when we use the module as destination. Let’s, say we create the “csv2.csv” and “text3.txt” files in our current working directory:
$ touch csv2.csv text3.txt
If we now run rsync and use our current working directory as source and the module as destination, we can see how the daemon refuses to receive the “text3.txt” file, since it is matched by the specified exclusion pattern:
$ rsync -av . rsync://192.168.0.39/linuxconfig sending incremental file list ERROR: daemon refused to receive file "text3.txt" ./ csv2.csv
Notice that in the commands above we used an rsync URL to specify the IP address of the server and the name of the module we want to use. How can we obtain a list of all the available modules on a machine? It is very easy, we just run the rsync command specifying only the server address in the URL:
$ rsync rsync://192.168.0.39 linuxconfig "Example of an rsync daemon module"
All the available modules and the associated comments will be displayed; in this case, only the “linuxconfig” one.
Conclusion
In this article we saw how to install and configure the rsync daemon, on some of the most used Linux distributions. We saw and learned how to use some of the available global and module-specific parameters to change the behavior of the rsyncd daemon. Finally we saw an example of a module configuration. For a more in-depth knowledge of rsyncd, we can always consult the official manual. It’s just a matter of running:
$ man rsyncd.conf
