Or maybe it's a compile-time option, but at least on Ubuntu and CentOS the file is looked up in /etc. The part about the configuration file is not correct, the daemon will look for /etc/nf instead. Remote shell and then spawning a single-use "daemon" server thatĮxpects to read its config file in the home dir of the remote user. Rsync supports connecting to a host using a Into a system (other than what is already required to allow It is sometimes useful to use various features of an rsync daemon (suchĪs named modules) without actually allowing any new socket connections This is based on a relatively obscure feature mentioned in the rsync(1) man page under "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION": Here is another option that I haven't found much information on, but that I think combines the best aspects of solutions 3 and 4: using rsync daemon mode over ssh.
RSYNC OVER SSH TUNNEL FULL
Downsides: Opens up a TCP port that has full filesystem read access and is hard to secure (Ideally you could make the rsync daemon use a unix socket instead, that could be secured by filesystem permissions, but I haven't found a way to do that). Upsides: Lots of useful options, like read-only mode, running as a different user if required, server-side excludes/includes, etc. Running rsync in daemon mode on the host being backed up.Neither idea sounds very appealing to me. Downsides: Requires either careful matching of rsync options (which might change over time), or "validator" scripts. As root, with a public key and a "forced command".Downsides: Whoever has the private key has full root access to the host being backed up. Downside: cannot back up sensitive files. There are several common ways to do rsync backups of hosts over ssh:
0 kommentar(er)
