On Thu, 30 Oct 2014 14:04:32 +0000
Always Learning <cen...@u62.u22.net> wrote:
> 
> The order of rules in any IPtables table is pure common sense and very
> logical. Essentially, the first rule is the first action. The second
> rule is the second action etc.

Sure, I do know how it works. :-) However, the iptables requires me to
think about it when specifying -I or -A every time I modify the rules.
My beef is that in most situations I don't really need to be bothered
with that --- if I want to open a http port, the machine should be the
one to figure out where to put the rule. I want to be bothered with
rule order only when I am doing something complicated enough, not for
every firewall modification.

> The firewall-cmd syntax appears to me to be dumbing-down and
> de-skilling. It hides the technical information behind the command, to
> the detriment of the technical user.

I'd say that the vast majority of users never actually need to
see that technical information. Most server deployments are
standardized, and the user just wants to say "I have http, ssh,
openvpn, dhcp... services running on this machine, open appropriate
ports". Only the more intricate configurations should require a
learning curve.

You seem to be pushing the argument that we should give up Office
suites and force the user to write everything in TeX, since it is more
powerful and exposes a lot more technical details to the user. But TeX
comes with a steep learning curve, and the vast majority of people
don't really need it. Similarly, C is far more powerful then, say,
Phyton or a bash script, so should we do all our scripting in C?

I have a feeling that RedHat has some internal statistics coming from
customer support channels, and that in 99% of the cases the question is
"how do I open a firewall port for httpd", while only in 1% of the
cases the question is "I'm masquerading a subnet from one LAN, while I
want trusted access for three machines from another LAN, but only
through a customized sshd port, while everything else should go as
usual, except for mail originating from a local server...". So the idea
is to adapt the firewall-cmd tool for the most common usecases, and not
requre them to touch stuff "under the hood" for simple tasks.

People who need complicated setups can either learn how to achieve that
using firewall-cmd itself, or shut down firewalld and configure
iptables manually. But this should be an exception, rather than a
rule, IMHO.

> In IPtables
> 
>       -A 4web -p tcp --dport 81 -j ACCEPT
> 
> In firewall-cmd
> 
>       firewall-cmd --add-service=http
> 
> but that refers to port 80.

  firewall-cmd --add-port=81/tcp

Look at the examples section of "man firewall-cmd". :-)

> Hence IPtables is a lot more flexible. The
> contrast is like playing a piano without gloves and then wearing
> boxing gloves - the precision has vanished.

Running httpd on port 81 is not really common, since all
real-world clients are expecting it on to be on port 80. Besides, I
haven't came across a configuration which can be achieved via iptables
but not via firewall-cmd (though that doesn't mean that such a config
doesn't exist). IMO firewall-cmd and iptables are fairly equivalent in
expressive power, while the former is easier to use in most common
situations. So precision is not lost, should you require it. But in
most cases you don't really need it.

> An informed user derives more from his computer system than someone
> who uses the 'dumb-down' simplified pre-packaged alternative -
> especially when there is a problem.

I have a feeling that it's just the case of lazy sysadmins who don't
want to bother reading the man page for firewall-cmd. They seem to be
the ones who are not informed. Moreover, the lockdown and panic options
seem to be an improvement in functionality, which does not exist if you
only use iptables. There might also be other functionality upgrades, I
haven't studied firewalld in detail yet.

Best, :-)
Marko

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Reply via email to