What is the need for rsync server in daemon mode

Many, but I will cite a few off the top of my head.

1. What if ssh/rsh are not available on the remote server or if they are broken in terms of configuration or stricter network rules? Using rsh/ssh still would require the client (depends on the sender or receiver role), the remote side would have to however fork the rsync binary locally and establish the connection with the rsync process running at the local side. rsh/ssh would merely provide a connection tunnel; as far as rsync is concerned, rsync is communicating with the other rsync process over the pipe(s).

2. Having a daemon mode rsync process would make the server a true ftp look-alike server where some of the filesystems can be made available through rsync modules. Everything else can be avoided. Say I want to make available only /usr/local and /var for download and refuse any rsync client's request for other downloads. I can use discretion at the host level or at the filesystem (modules) level to allow either upload or download (read only).

3. Can control host/user level access, authentication, authorization, logging and filesystem (structure) modules for download/upload specifically through a configuration file. Every time a change is made to the configuration file, rsyncd --daemon need not be restarted or HUPped. Can also put control on how many clients can connect to the rsync server process at a time. This is good, since I do not want my rsyncd server process to hog down the host completely over CPU or disk based I/O operations.

4. chroot functionality can be made available through the configuration for rsyncd in daemon mode. I can use this as a pretty neat security feature if I want to avoid clients connecting to my rsyncd for any of the files/filesystems that must be secured on the host and should not have outside access.

5. I can outright deny some of the options used by rsync client and not entertain at the server end, such as not allowing the --delete option.

6. Can have an option to run some commands/scripts before and after the rsync process. An example would be reporting and storing the rsync stats in post-transfer mode.

These are some of them, but I am sure the expert users of rsync can throw more light on this.

1. I experienced an issue trying to sync a large folder between a linux machine and a windows machine using cygwin. After dropping the SSH tunnel in favor of using the rsync daemon, my problems went away.

2. Client doesn't need to know the filesystem layout, etc. of the server he/she is pushing/pulling to/from

A common usage for rsync is to mirror public archives of files. The operator of the primary copy doesn't want to permit remote shell access to the archive, but wants the volunteers running the remote mirrors to be able to efficiently get a complete copy of the archives. Rsync works extremely well for creating a mirror since it will only download changed bits, and if there is a slight interruption in the network, it will not re-download an entire large file (cd/dvd images).

The bit torrent protocol actually may be a better choice for this now, but rsync was released many years earlier.

Even now many major archives still use rsync for mirrors.

• https://wiki.ubuntu.com/Mirrors
• http://fedoraproject.org/wiki/Infrastructure/Mirroring
• http://www.debian.org/mirror/ftpmirror

See: http://www.debian.org/mirror/ftpmirror

The mirroring protocol which we recommend is rsync.