On 29/11/2017 11:06, Ingo Wichmann wrote: > Hi there, > > Am 29.11.2017 um 06:34 schrieb Bryan Smith: > >> One thing I love about the LPIC-1 program is that it exposes >> candidates to _all_ common technologies on a system ... especially >> useful for troubleshooting. I.e., if one can't figure out why a >> service isn't accessible, knowing _all_ the common places to look is >> very useful. > > I question, whether tcp wrappers are really commonly used today. > I do not question, that they are available for some services. > I do not question, that they are useful in some corner cases.
I'm probably going to agree in large part with Ingo here. I have not myself used tcpd for anything in over 5 years. Like all tools that originate from the 90s era, the original reason for tcpd seems to have gone, way back then we seldom bothered writing access control into the many daemons around and preferred to ship it off to something else. But the software landscape has changed dramatically since and every daemon I care about does it's own access control in some way. Even nrpe has allowed_hosts, and were I to pick one app where offloading access control elsewhere was suitable, it would be that. It's also a prime candidate for running under xinetd but that's another story. Sooner or later, tcpd will go the way of all old software, to my mind it's now time to put it on the sunset path > > I'd say, iptables, ACL's, capabilities, AppArmor, SELinux, cgroups are > much more commonly used than TCP wrappers. So candidates are much more > likely to be hit by one of these. > > The most common service mentioned in this thread was ssh. But which > admin still implements TCP wrappers on sshd, if he knows the Match > keyword in sshd_config? > > There is only one reason to me: because he did so 15 years ago. hehe. That's the truth > >> Alessandro Selli <[email protected]> wrote: >>> Say you change in.ftpd service >>> port to some non-standard one in it's configuration file. >>> in.ftpd: 192.168.0.0/255.255.0.0 EXCEPT 192.168.1.0/255.255.255.0 >>> in /etc/hosts.allow is still going to work, >>> iptables -I INPUT -i eth0 -p tcp --dport ftp -m conntrack --ctstate NEW -j >>> REJECT >>> no longer will. > > FTP is an example of a protocol, that has lost importance. If this is > the best use case for TCP wrappers we come up with, we should remove it > from LPIC 1. Don't deal with corporate billing departments much? When these guys start moving files with 100 million CDRs around, everything except ftp falls over and dies. But I get your point, the days when everyone had an ftp.mycompany.com are long gone, and those users that do use ftp likely have corporate-quality network firewalls doing what tcpd would do > > Here's some indication, that on servers iptables is more commonly used > than TCP wrappers: > > * No distro comes with TCP wrappers blocking some service by default, > other than iptables > * Ansible has an iptables module by default, TCP wrappers are in galaxy > * PuppetForge finds 4 modules tagged with 'tcpwrappers' - none of them > is supported by puppetlabs. And 22 modules tagged with 'iptables', one > of them the "official" puppetlabs module > > So please TCP wrappers users: where is the indication, that TCP wrappers > kept their importance since they have been introduced in LPIC 1 in 2001? > Linux has changed, since! I still like good old tcpd, I find it's a very valuable tool to demonstrate access control concepts to bright-eyed shiny uni grads. But I don't let them actually *use* it, mostly because none of the sysadmins team ever think to look in hosts.{allow,deny} (unless they happen to grep -r /etc) I don't say tcpd is useless, it obviously has it's uses. But we can't included everything in the exam, and LPI is not in the business of certifying that someone knows hwo to use tcpd/httpd/sshd correctly. LPI is in the business of giving employers a reasonable assurance that the new hire probably won't destroy the servers while trying to do routine work. I also like rcs but would never think of putting it on any exam. -- Alan McKinnon [email protected] _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
