Hi, This is just a feature request. It'd be nice if rsync could be told to listen on specific interfaces (as opposed to interface addresses). e.g. I want to run rsync on a multi-homed box, and I want it to listen on eth0 but not ppp0 regards Andrew
Yes, that would be nice. The current way to do this is to run the rsync daemon as a service under something like xinetd.
isn't this resolved for 20 years , i.e. this ticket can be closed? address You can override the default IP address the daemon will listen on by specifying this value. This is ignored if the daemon is being run by inetd, and is superseded by the --address command-line option Rsync can also be run as a daemon, in which case the following options are accepted: --address=ADDRESS bind to the specified address https://download.samba.org/pub/rsync/NEWS.html NEWS for rsync 2.6.4 (30 March 2005) Added the port parameter to the rsyncd.conf file. (Promoted from the patches dir.) Also added address. The command-line options take precedence over a config-file option, as expected.
(In reply to roland from comment #2) > isn't this resolved for 20 years , i.e. this ticket can be closed? Being fair to OP, this ticket was opened 20 years ago (2005-03-09) > NEWS for rsync 2.6.4 (30 March 2005) As you can see, the NEWS date is *AFTER* this ticket was opened even. But more importantly than all of the above, OP is asking to be able to specify an INTERFACE to which to bind to, and specifically mentions that it's an interface by name, not by address which he wants to specify. The solutions you are offering appear to bind by address, not name. So, IMO, no, this ticket is not resolved and not a candidate to be closed as resolved.
to be honest, there aren't many unix daemons coming to my mind which have such feature to bind to specific interface/nic name, it's totally common to specify ip address to bind/listen to. can you provide an example where we can bind tcp based service to specific nic/interface by interface name ? most general purpose daemons (and rsyncd is one) stick to ip-based binding, and the reason for that is portability (which is important for rsync). socat is one of the very few coming to my mind which can do that. and systemd ( via BindToDevice=) and thus you could use rsyncd under control of systemd to get what you want. it won't make sense to implement this. AI tells this for it: Short answer: no, SO_BINDTODEVICE is not portable. SO_BINDTODEVICE is a Linux-specific socket option. It lets you bind a socket to a particular network interface (e.g., "eth0"), but: It is defined in Linux headers (<linux/socket.h> / <net/if.h>), not by POSIX. It works on Linux kernels, but won’t compile or run on most other systems like: -BSD variants (FreeBSD, OpenBSD, NetBSD) -macOS -Windows What to use instead (portable approaches) If you need similar behavior across platforms, you generally have to rethink the approach: - Bind to a specific IP address - Instead of binding to an interface, bind to the IP assigned to that interface using bind(). This is portable and works everywhere. - Use routing configuration - Let the OS routing table decide which interface to use (often the most idiomatic solution). Platform-specific alternatives - On BSD/macOS: IP_BOUND_IF or SO_RECV_IF (different semantics, not a drop-in replacement) - On Windows: IP_UNICAST_IF / IPV6_UNICAST_IF When SO_BINDTODEVICE makes sense It’s useful if: You are writing Linux-only software (e.g., containers, networking tools, VPNs) You need strict interface-level control beyond IP binding Otherwise, relying on it will lock you into Linux.
> to be honest, there aren't many unix daemons coming to my mind which have such feature to bind to specific interface/nic name, it's totally common to specify ip address to bind/listen to. That may be true, but ultimately it's a straw man argument to the point of OP's request. Commonality doesn't have to be true for a feature request to be valid. Indeed. Every common feature is going to lack commonality the first time it's implemented. > can you provide an example where we can bind tcp based service to specific nic/interface by interface name ? Again, that's a straw man argument. Just because no other examples exist doesn't make this request invalid. It's reason for request for some unique use-case that doesn't commonly apply to other tcp based services. > most general purpose daemons (and rsyncd is one) stick to ip-based binding, and the reason for that is portability (which is important for rsync). That might be true and a fair point. And really the only real arguable point IMO. Commonality (or lack thereof) isn't really a valid argument. Now as for portability, it might be entirely possible to allow binding-by-name as a Linux-only feature in the name of not restricting features to the lowest common denominator. All of that said, I am not arguing for or against this particular request, but just trying to keep it fair. In fact I am not even sure why I got CC'd on this ticket. The e-mails for the comments say: You are the QA Contact for the bug. But I am not. And I am not on the CC list. I suspect something has gone awry with this BZ instance and it is mis-directing ticket comments to people not involved with the ticket in any way.