On 11/13/2016 12:48 PM, Per Jessen wrote:
I'm running rsyncd via xinetd.
I've long ago discontinued the use of xinetd. Back in the mists of history, the - now depreciated - inetd was a move on the part of some <strike> hackers</strike> to eliminate the need for having a mass of active daemons each listening on the relevant port. Xinetd was meant to be a clean=up of that which incorporated some feature like "TCP Wrappers". IYR, that was Wietse Venema's "shim" that implemented the ACL. Yes that was (supposed to) use /etc/hosts.allow and /etc/hosts.deny. My only observation is that its easy to get the entries for that wrong. Do check what is in /var/log/secure and /var/log/messages. The entries are supposed to be in the format <daemon list>: <client list> [: <option>: <option>: ...] One common mistake is to use the name of the service rather than the name of the daemon process. Remember, you can run Xinetd in debug mode to find out in more detail what's going on. =============== You don't mention what version of the OS you are using. If it is a later model, you may find it more manageable to use a systemd unit rather than a an Xinetd descriptor. Why? Well in one sense systemd is already doing what inetd & xinetd did, it listens on a whole bunch of sockets for requests and then fires up services. Just as Xinetd has a separate config file for each socket that it listens on, so does system have "unit" files for each socket it listens on. If you are running a later model Linux you are already running systemd, so why run Xinetd as well? You are just adding complexity. The primary reference is http://0pointer.de/blog/projects/inetd.html It uses sshd as an example but its easy enough to ... <quote> That said, there are a couple of useful features that systemd does not support, for example IP ACL management. However, most administrators will probably agree that firewalls are the better solution for these kinds of problems and on top of that, systemd supports ACL management via tcpwrap for those who indulge in retro technologies like this. On the other hand systemd also provides numerous features xinetd does not provide, starting with the individual control of instances shown above, or the more expressive configurability of the execution context for the instances. I believe that what systemd provides is quite comprehensive, comes with little legacy cruft but should provide you with everything you need. https://together.jolla.com/question/19492/rsync-daemon-mode-as-a-systemd-soc... You may find this https://lists.fedoraproject.org/pipermail/users/2011-November/408706.html more interesting or more relevant since it also discusses ACL. Oh, and *DO read the followups! You *MOST* *DEFINITELY* want the version that listens on a socket to implement a per-service instance if you want systemd to work the way Xinetd did. That means tou have to tell it about the socket with a .socket unit file. Given all that, I'm running 13.2 and I see I have a /usr/lib/systemd/system/rsyncd.service but that only starts the whole daemon, it doesn't do the systemd socket listener thing described above. Perhaps the package maintainers need a wakeup call :-) -- A military operation involves deception. Even though you are competent, appear to be incompetent. Though effective, appear to be ineffective. Sun-tzu, The Art of War. Strategic Assessments -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org