[ovirt-devel] Firewalld migration.

Mon Mar 27 11:38:16 UTC 2017

Hi,
I like option number 3 the most from reading the comments.
We are not a configuration management system, so custom rules should not be
a main consideration.
VDSM should probably enable the firewalld rules it needs to work and engine
should not care about firewall at all.
A user wanting to add more rules then this should probably use the ones
planned in:
https://github.com/cockpit-project/system-api-roles

Thanks,

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
        8272306
Email: ydary at redhat.com
IRC : ydary

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

> > Right, so why not create an Ansible playbook which the users can change
> > (extend?), based on http://docs.ansible.com/
> ansible/firewalld_module.html ?
>
> I think I like the playbook proposal the best.
>
> Lets assume the engine provides a firewall.yaml playbook somewhere in /etc:
>
>  - The default playbook would contain our default firewalld
> configuration (we should also provide it in /usr/share/doc to give the
> user a reference)
>  - The engine or host deploy script can provide ansible variables so
> the playbook can even be a parametrized one (port numbers)
>  - The user can add rules he needs
>  - The user can REPLACE the content with iptables rules if he wishes
> so (we can even say it is unsupported, but possible)
>
> As an extension:
>
>  - We can provide ovirt-engine-firewalld ansible role with the default
> config so we can properly update files using RPM. The user defined (or
> default) playbook would just call this role and would stay intact
> during package upgrades.
>
> This is outside of database, allows customization and adapts to
> whatever firewall backend we might need.
>
> --
> Martin Sivak
> SLA / oVirt
>
> On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
> >
> >
> > 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
> >>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > 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/34137a03/attachment-0001.html>