On Thu, 18 Oct 2012 00:03:57 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 17.10.2012 21:29, schrieb Whiskers:
Rather than install tcp-wrappers on my Arch system, I'd like to use whatever the proper "server" is nowadays instead of /usr/sbin/tcpd - but what is it?
Why would you replace tcpd with anything? Does it serve any purpose at all?
Thanks for responding. On a system with tcp-wrappers, tcpd is the "server" which launches leafnode. From man leafnode: [...] The leafnode program itself is the NNTP server. It is run from /etc/inetd.conf when someone wants to read news. The other parts of the package, fetchnews and texpire, are responsible for fetching new news from another server, and for deleting old news. [...] No network-level access control is supported. This is a deliberate omission: Implementing this is a job which should not be redone for each and every service. I recommend that either firewalling or tcpd be used for access control. [...] Xinetd is the 'new improved' inetd, and the xinetd setup recommended in the Leafnode tarball's README has tcpd as the "server" and leafnode as the "server argument", as in the /etc/xinetd.d/nntp file previously quoted. This of course doesn't work on my Arch system, as tcp-wrappers (and thus, tcpd) is missing. So I'm trying to work out how to get leafnode available on demand, without using tcp-wrappers and tcpd, but with ufw, and with the new systemd (I've uninstalled initscripts from my system). Changing the xinetd configuration for leafnode so that tcpd isn't required, like this: $ cat /etc/xinetd.d/nntp service Leafnode { flags = NOLIBWRAP per_source = 3 port = 119 socket_type = stream protocol = tcp user = news server = /usr/local/sbin/leafnode type = UNLISTED wait = no instances = 7 only_from = 127.0.0.1 } still doesn't make leafnode accessible to my usenet client (slrn). Which is strange, as I can run leafnode manually from the command line: $ leafnode 200 Leafnode NNTP daemon, version 2.0.0.alpha20110806a at tavy.mobile.private quit 205 Always happy to serve! ... and even then, slrn reports Failed to initialize server Run-Time Error Reason: slrn fatal error: Failed to initialize server. I have even created /etc/hosts.deny and /etc/hosts.allow, in case xinetd expects to find them (although I can't find mention of that in the documentation I've seen). Still no luck. I'm beginning to wonder if xinetd itself isn't redundant; can systemd alone manage access control and work as a 'super server'? I'm still trying to get to grips with all that systemd can do - and how to make it do it. Presumably, I'll have to invent a custom systemd 'service' for systemd if that is the way to go. -- -- ^^^^^^^^^^ -- Whiskers -- ~~~~~~~~~~