On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >> > >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <[email protected]> > >> 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 <[email protected]> > >> > wrote: > >> >> > >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <[email protected]> > >> >> 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 < > [email protected]> > >> >> > 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
