On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <[email protected]> wrote:
> > > On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <[email protected]> wrote: > >> >> >> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <[email protected]> >> 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 <[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
