On Thu, Apr 23, 2020 at 12:21 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote:
On April 22, 2020 10:45:49 PM GMT+03:00, Edson Richter <edsonrichter(a)hotmail.com>
wrote:
>De: Strahil Nikolov <hunter86_bg(a)yahoo.com>
>Enviado: quarta-feira, 22 de abril de 2020 15:45
>Para: users(a)ovirt.org <users(a)ovirt.org>; Edson Richter
><edsonrichter(a)hotmail.com>; eevans(a)digitaldatatechs.com
><eevans(a)digitaldatatechs.com>; francesco(a)shellrent.com
><francesco(a)shellrent.com>
>Assunto: Re: [ovirt-users] Re: Safely disable firewalld [Ovirt 4.3]
>
>On April 22, 2020 6:33:40 PM GMT+03:00, Edson Richter
><edsonrichter(a)hotmail.com> wrote:
>>I'm in no way a ovirt expert. But as Linux administrator, I would say
>>that firewalld and iptables are "front-end" to kernel internal
>security
>>tables, so, in the final of the day, will provide *almost* same
>>functionality.
>>
>>Seems that firewalld is able to activate modules without restarting
>>entire firewall infra-structure, which iptables is not capable of.
>This
>>leverage an advantage for firewalld, specially where you would not
>have
>>interruptions in existing stateful connections.
>>
>>I've used iptables *always* as replacement for firewalld because of
>>almost 20 yrs using iptables - this is the first step in all about
>>hundred Centos7 installations I've done past few years. I just can't
>>throw away all my scripts that block hackers, provide 2 and 3 way
>>"knock-knock" lockers, fail2ban customizations, nat rules, DMZ, and
>>all, everytime a new "firewall" front end appears. I've seen at
least
>>two or three "iptables killers tech" in the past, and iptables still
>is
>>the king - at least for me.
>>
>>Again, repeating myself, I'm no ovirt specialist. Just a sazonal linux
>>admin which will not jump from iptables train yet.
>>
>>Perhaps, I would not reccomend to completely deactivate all firewall
>in
>>any server! If it is the case, I would instead to advice to just
>>replace firewalld with iptables-service (at least, in Centos7) - but
>>only in case you have too much to loose without iptables (as am I).
(A long and non-important reply follows. Feel free to ignore...)
I'd like to add to the other answers given (which I agree with):
I too, when I was a sysadmin, had colleagues that insisted on long shell
scripts with iptables commands. I also started that way myself, but at
some point realized I actually don't like all these long lists of iptables
commands, and that I start using control structures around them (loops,
conditionals, etc.), and eventually that likely other people were in my
position and probably some of them created wrappers that I might like.
So I searched a bit, and eventually settled on firehol, which served me
very well for quite many years. I admit I didn't check it much since I
started working for Red Hat, but I did see it eventually added support
of IPv6 (which is very nice, IMO, and does save you from lots of duplication
in your custom script), as well as some other additions.
Most of these wrappers, though, have a single kind of audience in mind -
the sysadmin. Some are for people that prefer GUIs, some, like firehol,
are for those that want to be expressive but concise, there are quite
many - I heartily recommend to go and have a look, if you didn't yet.
firewalld arrived rather later in the game, and I think it did/does
serve a specific niche quite well, in addition to sysadmins (which IMO
it also serves reasonably well, but that's a matter of taste, obviously.
It's definitely quite different from e.g. firehol). It serves well the
audience of 3rd-party developers. Both those that want to define a specific
service, so that sysadmins can allow/deny/etc it for some zone etc. without
having to deal with the specifics (which in some cases are somewhat more
complex than a single tcp port, although that's the common case), and those
that want to create wrappers above firewalld itself.
Going back to the list's topic, for oVirt, it's much much easier and less
risky to add or remove firewalld services than to try and insert rules
inside your custom iptables setup. iptables is simply meant to be general
purpose - programmatically updating one's arbitrary configuration is similar
in complexity to programmatically editing source code of some program to make
it do something. Even if your script has no flow control, just a long stream
of iptables commands, or alternatively if the tool tries to edit the output
of 'iptables-save' rather than your "source" script, you can still have
custom
tables, conditional terminals (REJECT if $something), etc. - and a tool simply
can't know what to do. I guess at least in some cases even you have to think
carefully before updating your scripts :-). firewalld, OTOH, creates a rather
strict structure, which is both general enough to be useful in almost all
cases, and strict enough to make it much less risky to automatically update.
I guess you'll never even think about letting some tool take your custom
scripts as input and amend them to add some service. With firewalld, that's
possible, easy, and almost always safe. I am not saying there aren't other
wrappers that are similar in this regard - there might very well be. But I
can see why it was started and eventually adopted as the main tool in RHEL -
and therefore CentOS, although nothing prevents you from using other ones if
you don't mind building/packaging/installing them yourself.
Best regards,
>>
>>Regards,
>>
>>Edson
>>
>>
>>________________________________
>>De: eevans(a)digitaldatatechs.com <eevans(a)digitaldatatechs.com>
>>Enviado: quarta-feira, 22 de abril de 2020 12:18
>>Para: francesco(a)shellrent.com <francesco(a)shellrent.com>;
>>users(a)ovirt.org <users(a)ovirt.org>
>>Assunto: [ovirt-users] Re: Safely disable firewalld [Ovirt 4.3]
>>
>>If you log in to the cockpit, you can add services or custom ports
>>easily. I would not disable the firewall.
>><hostname:9090> for the cockpit.
>>
>>Eric Evans
>>Digital Data Services LLC.
>>304.660.9080
>>
>>
>>-----Original Message-----
>>From: francesco(a)shellrent.com <francesco(a)shellrent.com>
>>Sent: Tuesday, April 21, 2020 12:54 PM
>>To: users(a)ovirt.org
>>Subject: [ovirt-users] Safely disable firewalld [Ovirt 4.3]
>>
>>Hi all,
>>
>>I was wondering if it's "safe" disabling entirely the firewalld
>service
>>and manage the firewall only via iptables, on the host and on the
>>hosted engine (a self-hosted engine). It would make a lot easier the
>>managing the firewall rules for me because of many automatisms I
>>created based on iptables. Did anyone manage to do this? Any
>>contraindication for doing this or precaution that I have to take care
>>of?
>>
>>Thanks for your time and help,
>>Francesco
>>_______________________________________________
>>Users mailing list -- users(a)ovirt.org
>>To unsubscribe send an email to users-leave(a)ovirt.org Privacy
>>Statement:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.html&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078297638&sdata=vqS7cjtftiP1F%2Bv1akulAA0KqCLTh4In2pltWIdJBd0%3D&reserved=0
>>oVirt Code of Conduct:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2F&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078297638&sdata=EdDGteCs4vPuBkZvwU4f9JmSozZcSxdO9zL9qILnH68%3D&reserved=0
>>List Archives:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2FPNKTCSWLJXKK6FAIJ7EJMWIFTH4GGCL5%2F&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078307635&sdata=V0wxXmGJpwqbmToN4h9NOLQ1dd61nkWJ4fP3z%2Bq4njU%3D&reserved=0
>>_______________________________________________
>>Users mailing list -- users(a)ovirt.org
>>To unsubscribe send an email to users-leave(a)ovirt.org
>>Privacy Statement:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.html&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078307635&sdata=L37Na1hFCWmjMbxeXLxk4A%2B9qVDNj24xrHKsqeVUYjk%3D&reserved=0
>>oVirt Code of Conduct:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2F&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078307635&sdata=YmbRQIouTnJPYOW4EKC%2F8iyrpzzmdfN%2F%2FMi5b1guiUE%3D&reserved=0
>>List Archives:
>>https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2FJOTFQ5SPDUET7MUU3MYQVDGZDMRO7GWQ%2F&data=02%7C01%7C%7Cd8353bf8e03c4bd40ad308d7e6ed4733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231779078307635&sdata=edpMNR73QTQDZ6WH6fwNm2CPMUNZwq2AglDckVrgz0k%3D&reserved=0
>
>Keep in mind that I had some issues with oVirt (was more than a year
>ago - so don't ask for details) when either firewalld or SELINUX were
>down.
>
>With so much experience in IPTABLES - it's understandable, but keep in
>mind that in CentOS/RHEL 8 iptables command is just a translator to
>nftables - with limited capability and I don't think that it was a
>coincidence . With firewalld you can still achive 90-95% of what you
>could do in IPTABLES while the rules are quite clear even for a new
>admin.
>
>What I really like is that you can predefine the ports and protos for
>a specific service and easily deploy it via salt or ansible.
>
>Best Regards,
>Strahil Nikolov
>
>
>Good to know!
>When I have time to return to my oVirt tests, I"ll take a careull look
>at it.
>I'll also add a note into our Centos 8 migration plans that all
>iptables scripts will have to be rewriten.
>
>Thanks,
>
>Edson Richter
As you are not the only one with zillions of iptables rules - check the CentOS mailing
list.
Maybe they got a way to keep you on iptables.
Best Regards,
Sttrahil Nikolov
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LNS6S5JYWKI...
--
Didi