[ovirt-devel] Firewalld migration.

[Edward Haas]

On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak at redhat.com> wrote:

> > Clients should be made aware their custom rules are going to be obsolete
> and
> > that they should reapply them once they reinstall.
>
> Would you want to manually fix every reinstalled host? I would
> consider that very annoying. This has to be somewhat automatic if we
> want to support custom firewall rules. And although I agree the engine
> is not the right place for that, it is the only central place we have
> and from which we are starting the reinstall task.
>

But we do not want to support custom firewall rules, we are not a firewall
manager.
IMO, oVirt should support the hardening of its services and co-exist with
other rules.
Custom firewall settings imply one of these:
- We need to extend current firewall options.
- It needs to be implemented outside oVirt.

But if the need to support back doors is proven to be a must, then
implement them
outside the main core solution, these edge cases should not block the main
business
logic.



>
> Martin
>
> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber at redhat.com>
> wrote:
> > You're right, but I don't think it matters; hosts will remain unaffected
> > until they're reinstalled via an upgraded Engine.
> >
> > Clients should be made aware their custom rules are going to be obsolete
> and
> > that they should reapply them once they reinstall.
> >
> > On Mon, Mar 27, 2017 at 9: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/e9cad868/attachment.html>