Le jeudi 15 novembre 2012 à 09:06 -0800, Adam Williamson a écrit : > On Thu, 2012-11-15 at 14:48 +0100, Reindl Harald wrote: > > > > Am 15.11.2012 13:33, schrieb Michael Scherer: > > > Le jeudi 15 novembre 2012 à 03:23 +0100, Kevin Kofler a écrit : > > >> iptables rules are a long-established cross- > > >> distribution interface > > > > > > Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian > > > offered several frontend, but IIRC, didn't use one by default > > > > and they ALL using iptables/netfilter > > > > so if you write a iptables.sh you get it run on ANY distribution > > and that was the point > > Right. I hate to say it, but Harald is correct here: AFAIK, all those > and other firewall configuration mechanisms were ultimately just > UI/abstraction layers wrapped around iptables. They wrote iptables > rules. firewalld is very different. Usually, if you use shorewall, nuface, ufw, etc and iptables side by side, there is inconsistency. As long iptables exist, you will have to do the exact same thing : - disable the firewall of the distribution ( which is already a non portable part of the installation ) - run either : - a script with lots of iptables calls ( quite awful, slow and unauditable in practice as Reindl explained in another mail, and as I too often seen at customers deployment ) - a script that run 1 command, iptables-restore < file. Which is equally as awful and unauditable, but faster. I do not see what firewalld would change to that. Disable it, run what you want instead. The only issue is always the same, if you want to run 2 systems side by side, you have to make work to integrate them. For example, shorewall will set the default policy for a table, create new one, flush the current one, etc. So as a sane iptables scripts will do the same, you cannot run them one after the other and expect things to work smoothly. And for firewalld, the problem is that firewalld do stuff that a simple script cannot, namely offering a dbus interface, and so the script cannot simply replace firewalld ( and never will ). Previous systems were simple enough that you could just remove them and do the work by hand. Firewalld provides more and if applications do not cope with non existant firewalld, then this will be bad. However, I do not expect having a hard dependency on it for a few years, since this would mean that such applications no longer work on distribution that do not ship firewalld ( like for example current version of RHEL ). -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
