[ovirt-devel] Firewalld migration.

Mon Mar 27 10:46:02 UTC 2017

On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <mperina at redhat.com> wrote:

>
>
> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>
>>
>>
>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> so personally I don't like the current way how we store firewall
>>> configuration within engine (saving complete iptables commands as string).
>>> I think should change the way how we store firewall configuration:
>>>
>>> 1. On engine side I'd just store which services/ports (or port ranges)
>>> need to be enabled on host. By default only those services/ports that
>>> engine needs, but we can maintain also custom services defined by users
>>>
>>
>> Agreed. I hope that's enough on one hand, on the other hand, users can
>> probably easily extend it via Ansible to the hosts and execution of a more
>> customized firewalld configuration there - we probably should not own it.
>>
>
> Right, we should take care only about services/ports which we need. So we
> probably could drop the ability for users to define their own custom
> services/ports within engine for firewalld and force them to use Ansible
> or other tools to handle their own configuration.
>

Right, so why not create an Ansible playbook which the users can change
(extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?
...

>
>
>>
>>>
>>> 2. Write plugin to ovirt-host-deploy which will translate those
>>> services/ports into actual firewall configuration on the host (it should
>>> detected what firewall is currently enabled and adapt)
>>>
>>
...  and then ovirt-host-deploy will be in charge of executing that
playbook? Seems fairly straightforward.
Y.

>> Agreed.
>>
>>
>>>
>>> 3. For newly installed host I'd just use firewalld
>>>
>>
>> Agreed.
>>
>>
>>>
>>> 4. Also for 4.2 clusters I'd switch from iptables to firewalld when you
>>> execute Reinstall (we should document this and make firewalld preferred
>>> solution)
>>>
>>
>> That's a good question. If a user had the default, non-changed policy we
>> have had in iptables - sure.
>> If not, I think it may be a bit of a challenge to switch otherwise.
>>
>
> Right. We could detect if there's some custom firewall rules in
> IPTablesConfigSiteCustom engine-config option and if not we could probably
> assume that switching to firewalld could be performed.
>
> We could also mark iptables configuration as deprecated in 4.2 and declare
> that it will be removed in 4.3. That would add some time for users to
> prepare for the switch ...
>
> Y.
>>
>>
>>>
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <didi at redhat.com>
>>> wrote:
>>>
>>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber at redhat.com>
>>>> wrote:
>>>> > Effectively, upgrading will leave lingering (but nonetheless
>>>> operational)
>>>> > iptables rules on the hosts. I'm not even sure there needs to be
>>>> special
>>>> > upgrade treatment?
>>>>
>>>> Please describe the expected flow.
>>>>
>>>> Please note that at least when I tried, 'systemctl start firewalld'
>>>> stops
>>>> iptables.
>>>>
>>>> Thanks,
>>>>
>>>> >
>>>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi at redhat.com>
>>>> wrote:
>>>> >>
>>>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber at redhat.com>
>>>> >> wrote:
>>>> >> > 1) Do we actually need iptables for any reason that isn't a legacy
>>>> >> > consideration?
>>>> >>
>>>> >> No idea personally.
>>>> >>
>>>> >> Perhaps some users prefer that, and/or need that for integration with
>>>> >> other
>>>> >> systems/solutions/whatever.
>>>> >>
>>>> >> If we drop iptables, how do you suggest to treat upgrades?
>>>> >>
>>>> >> >
>>>> >> > 2 & 3) I am in favor of treating custom services as a requirement
>>>> and
>>>> >> > plan
>>>> >> > accordingly. Many (most, even) of the services are already
>>>> provided by
>>>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>>>> packages
>>>> >> > (e.g.
>>>> >> > gluster). Some are missing (I've recently created a pull request
>>>> for
>>>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able
>>>> to get
>>>> >> > all
>>>> >> > the services to be statically provided (by either firewalld or the
>>>> >> > relevant
>>>> >> > 3rd party packages).
>>>> >> >
>>>> >> > Ideally I think we'd like use statically provided services, and
>>>> provide
>>>> >> > the
>>>> >> > capability to provide additional services (I'm not a fan of the
>>>> current
>>>> >> > methodology of converting strings into xmls). I don't think we'd
>>>> want to
>>>> >> > limit usage to just statically provided services. (2)
>>>> >> >
>>>> >> > As previously stated, I don't see a technical reason to keep
>>>> iptables
>>>> >> > under
>>>> >> > consideration. (3)
>>>> >> >
>>>> >> >
>>>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <
>>>> didi at redhat.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >> 1. Do we want to support in some version X both iptables and
>>>> firewalld,
>>>> >> >> or
>>>> >> >> is it ok to stop support for iptables and support only firewalld
>>>> >> >> without
>>>> >> >> overlap? If so, do we handle upgrades, and how?
>>>> >> >>
>>>> >> >> 2. Do we want to support custom firewalld xml to be configured on
>>>> the
>>>> >> >> host by us? Or is it ok to only support choosing among existing
>>>> >> >> services,
>>>> >> >> which will need to be added to the host using other means
>>>> (packaged by
>>>> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>>>> >> >>
>>>> >> >> 3. Opposite of (2.): Do we want to support firewalld services
>>>> that are
>>>> >> >> added to the host using other means (see there)? Obviously we do,
>>>> but:
>>>> >> >> If we do, do we still want to support also iptables (see (1.))?
>>>> And if
>>>> >> >> so, what do we want to then happen?
>>>> >> >>
>>>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Didi
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Didi
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Didi
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170327/0e54fe1e/attachment.html>