On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge@xxxxxxxxx) wrote: > > Well, all mails servers as well as sshd have much better ways to do > > such filtering. sshd has "Match", Postfix for example has > > "smtpd_client_restrictions=", and so on. > > > And now I need to have X number applications special syntax to > whitelist/blacklist a site. I need to change X files to make that change. > Each of those could be a separate change control process depending on the > size of the organization. Or I have 1 file that I can make a change to > which has usually one syntax and one set of reviews. Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses, but also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms, ... It's a very good thing being able to control this in a unified, but domain-specific way. There are also proper firewalls, for traffic-level filtering. But where's the place for tcpwrappers in all of this? It's neither really generic, nor domain-specific, and also crappy code. We really don't need 3 layers checking the very same thing... postfix and sshd have mechanisms to filter for on specific domain each, however covering a multitude of domain-specific high-level, matches and actions. A firewall has mechanisms to filter for all domains, however only covering a smaller number of generic, low-level matches and actions. tcpwrap otoh is somewhere in the middle, it's neither really generic, nor really powerful. It's not a convincing, a very redundant option, since it gets you very little features on top of a firewall, and is not that universal either. > Look I am not saying it isn't horrible to look at from a coding side. From > a systems administrators side it does stuff in a very clean, easily audited > way. It is also a nice key place where every application is actually using > the same syntax versus each custom version. Having spent several ITIL > meetings where you have to explain the syntax of each application to > non-sysadmins, then prove that the change is correct, then prove that the > change is easily backed out, and then other parts.. having 1 syntax to do > that versus doing every applications custom version makes it a lot easier > to deal with. If you want that unified language that can actually cover all kinds of apps and traffic, then use a firewall. It is truly universal (unlike tcpwrappers), and at least as powerful... > I am not saying rip it out, but I am saying that you need something that > replaces that one syntax, one file control, simple syntax method. Let that be the firewall. It does the same thing, just better. > I am giving you a standard enterprise problem. You are constantly going on > about how systemd solves enterprise level problems and enterprises will > love them. I am giving you a standard problem that tcpwrappers solves and > you need to come up with some sort of replacement for them. Most real > problems enterprise administrators deal with are people oriented and this > is a tool which deals with those problems in a way that is clean and > clear. Yupp, here's my replacement: a proper firewall. And no, it's not a standard enterprise problem that firewalls need higher people's sign-off than tcpwrappers in your theoretic firewall.. > All I am trying to do is point them out to you so that you don't end up > having to spend all of 2016 recoding a replacement because it became a deal > breaker for the various enterprise downstreams. If you want to make this a > "You dare question me?" then fine, I can go do something else and know in > the future that you aren't really looking for feedback. You know, we have more powerful replacements both high-level (in postfix, sshd, ...) and lower-level, we really don't need tcp wrappers. I posted this here for feedback, and yes I got it, please understand though at I will at least try to convince you that tcpwrap is a dead-end. I mean, take it as an indication that I am actually taking your feedback seriously, that I spend a lot of time arguing against it. If I wouldn't take it seriously I wouldn't have started this discussion and would certainly not have replied to this message... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
