[ovirt-devel] Firewalld migration.

[Yaniv Kaul]

On Thu, Apr 6, 2017 at 4:03 PM, Leon Goldberg <lgoldber at redhat.com> wrote:

> p.s., we've begun implementing option #2 using the following design and
> approach:
>

I'm missing the design @ https://github.com/oVirt/ovirt-site/pulls ...


>
> Beginning with a configurable threshold for cluster compatibility levels
> (defaulted to 4.2), instead of using/deploying iptables' deploy unit, we
> set a firewalld boolean in vdsm.conf's deploy unit (similarly to iptables;
> only in case firewall override is set).
>

This is exactly what I preferred we want to - continue to extend VDSM to
perform deployment, service management and configuration...


>
> Using a new dedicated vdsm configurator for firewalld, the required
> services are added to the active zone(s) (currently being just the public
> one) and become operational. This only takes place if firewalld's boolean
> is set to true in vdsm.conf. We determine what non-baseline services should
> be added based on what is installed on the host (e.g. gluster packages).
>
> This approach guarantees that neither upgrading Engine or a host
> separately will cause unwarranted firewall related modifications (more
> specifically, custom rules/iptables' service remain intact). Explicitly
> installing/re-installing hosts in compatible clusters via an upgraded
> Engine is the only way to override custom rules/enabling firewalld's
> service over iptables' service (barring manual alterations to
> vdsm.conf...). We're also going to warn users during engine-setup and add
> alerts during host (re)installations.
>

I would not pursue this direction until we are convinced using Ansible is
not a better, easier, more user-friendly approach.
Ansible can do all the checks and understand if need to keep iptables or
switch to firewalld.
Y.


>
> On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg <lgoldber at redhat.com> wrote:
>
>> Hey,
>>
>> There seems to be a growing consensus towards moving custom rules out of
>> Engine. It is believed that Engine shouldn't have assumed the role of a
>> centralized firewall management system in he first place, and that using a
>> proper 3rd party solution will be both favorable to the users (allowing
>> better functionality and usability) and will allow us to simplify our
>> firewall deployment process.
>>
>> Considering we don't have to manage custom rules, a host will be able to
>> derive all the information regarding its firewalld services from its own
>> configuration. Consequently, option #2 becomes a forerunner with Engine's
>> involvement being even further diminished.
>>
>>
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber at redhat.com>
>> wrote:
>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required
>>> rules (based on cluster/firewall configuration) to the deployment
>>> configuration, en route to being deployed on the host via otopi and its
>>> iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>> - Many of the required services are provided by firewalld. Rewriting
>>> them is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>> Pros:
>>>
>>>  - Engine side involvement is greatly diminished.
>>>  - Simple(r).
>>>
>>> Cons:
>>>
>>>  - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in
>>> the form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created
>>> services remains an open question. I think we'd like to avoid implementing
>>> logic that ask whether some service is provided (and then write it if it
>>> isn't...), and so choosing between the dynamic and static approaches is
>>> also needed. Using the static approach, guaranteeing *all* services are
>>> provided will be required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and
>>> we'll still have to use similar mechanism as described in #1 (service
>>> string -> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>>
>>
>
> _______________________________________________
> 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/20170406/8d2207f0/attachment-0001.html>