Firewalld migration.

26 Mar 2017

--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

> On 27 Mar 2017, at 17:05, Leon Goldberg <lgoldber@redhat.com> wrote:
>=20
> > Why do we need to use firewalld?
> I think that the initial trigger was the realization we're completely lack=
ing ipv6 handling (which requires use of another, similar tool in ip6tables)=
 in the current infrastructure.=20
>=20
> Assessing the situation and reviewing the code for potential solutions led=
 us to a couple of conclusions:
>=20
> - Current flow is overly complex and should be reexamined regardless.
> - The naive solution would be to duplicate the current flow for ip6tables,=
 potentially leading to a lot of boilerplate code. I'm sure there are more s=
ophisticated solutions that could be implemented within the current infrastr=
ucture, but firewalld naturally came up as it allows us to handle both ipv4 a=
nd ipv6 via a single entity.
> - As many of the services are already statically provided by either firewa=
lld or 3rd party packages, we'll be able to merely pass names of services in=
stead of complete rule sets.
> - el7 is shipped with and makes use of firewalld by default.
>=20
> > What is the role of the central management in this regard?
> I'd like its role to be as insignificant as possible.
>=20
> > -- Does it need to manage firewalls per host in detail? (are we acting a=
s a firewall management system?)
> No. Ansible was recently brought up as a solution/replacement to custom  r=
ules/service deployment, and other than that, there is no justification to h=
aving central management. The hosts have the required information to determi=
ne which services/rules should be enabled on them (via either vdsm or otopi)=

>=20
> > -- Does it need to apply a firewall template configuration to all the ho=
sts? (all being identical)
> > -- Does it need to specify what services it wants the host to run and me=
ntion if the whole setup should be harden or not?
> If we do decide to keep Engine's involvement, it should be as minimal as p=
ossible. Names of required services should be provided and that's it, in my o=
pinion (and even that sounds wasteful).
>=20
> > As far as I know, firewalld and iptables can co-exist, therefore, I do n=
ot see the need to 'upgrade' or perform a hard replacement.
> > It can be done as an option (firewall-type: iptables/firewalld).
> > On upgrade it continues with the 'old' definition and on new created hos=
t the default can be firewalld.
> > Is someone will explicitly want to change it from one to the other, we c=
ould go with remove/add approach to make things simpler.
> firewalld doesn't play well with iptables' service. Enabling firewalld dis=
ables iptables' service and flushes its rules.=20

Understood, good to know.
But still, this approach will work fine, we do the same with linux/ovs bridg=
e options. Add an option to choose the  firewall type. Support both at phase=
 1, allowing to change the type and at phase 2 deprecate the iptables type.

>=20
> > I personally like the distributed approach, where the upper management l=
ayer passes what it wants to the lower layers with minimum information. Lett=
ing the lower levels
> > do the explicit work and figure out what they need to do.
> > If that was the original approach, Engine would have not 'care' what typ=
e of firewall you use down at the host, you could even use a custom firewall=
, an NFV firewall solution
> > or anything that may pop up in the future.
> > Engine would have just said: I want libvirt, vdsm, ssh, etc... services o=
pened (for access from ...).
> > Custom settings? That implies we manage firewalls. So either let the use=
r add their special stuff on the hosts or provide them with a proper firewal=
l management interface.
> Agreed. I'll go even further and write that Engine shouldn't even state th=
e services hosts require; a host should be self aware of the services it nee=
ds to use based on the relevant configuration (e.g. if gluster is supported i=
n the cluster, enable gluster service)
>=20
>> On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <ehaas@redhat.com> wrote:
>>=20
>> I may be too naive, but it all sounds too complex to me.
>> Is there any reference to the use cases of the firewall configuration?
>>=20
>> Few questions:
>> - Why do we need to use firewalld?
>> - What is the role of the central management in this regard?
>> -- Does it need to manage firewalls per host in detail? (are we acting as=
 a firewall management system?)
>> -- Does it need to apply a firewall template configuration to all the hos=
ts? (all being identical)
>> -- Does it need to specify what services it wants the host to run and men=
tion if the whole setup should be harden or not?
>>=20
>> As far as I know, firewalld and iptables can co-exist, therefore, I do no=
t see the need to 'upgrade' or perform a hard replacement.
>> It can be done as an option (firewall-type: iptables/firewalld).
>> On upgrade it continues with the 'old' definition and on new created host=
 the default can be firewalld.
>> Is someone will explicitly want to change it from one to the other, we co=
uld go with remove/add approach to make things simpler.
>>=20
>> I personally like the distributed approach, where the upper management la=
yer passes what it wants to the lower layers with minimum information. Letti=
ng the lower levels
>> do the explicit work and figure out what they need to do.
>> If that was the original approach, Engine would have not 'care' what type=
 of firewall you use down at the host, you could even use a custom firewall,=
 an NFV firewall solution
>> or anything that may pop up in the future.
>> Engine would have just said: I want libvirt, vdsm, ssh, etc... services o=
pened (for access from ...).
>> Custom settings? That implies we manage firewalls. So either let the user=
 add their special stuff on the hosts or provide them with a proper firewall=
 management interface.
>>=20
>> Thanks,
>> Edy.
>>=20
>>=20
>>> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi@redhat.com> wr=
ote:
>>> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <oourfali@redhat.com> wrot=
e:
>>> >
>>> >
>>> > On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgoldber@redhat.com> w=
rote:
>>> >>
>>> >> Hey Oved,
>>> >>
>>> >> I don't think completely moving away from iptables is foreseeable at t=
his
>>> >> point, but I could be of course wrong. Either way, upgrading still ne=
eds to
>>> >> be thought of.
>>> >>
>>> >
>>> > I see.
>>> >
>>> >>
>>> >> By stating that the current infrastructure is complex, I was referrin=
g to
>>> >> the entire chain of storing rules in the database, fetching them usin=
g a
>>> >> dedicated deployment class consisting of include/exclude logic, sendi=
ng them
>>> >> over, unpacking, deploying...
>>> >>
>>> >> This procedure involves a lot of code that could be made redundant if=
 the
>>> >> required logic is present in the host, which to me seems favorable. I=
t of
>>> >> course entails other potential difficulties, primarily in the form of=
 custom
>>> >> services.
>>> >>
>>> >> I don't think otopi's firewalld plugin is any more complex than the
>>> >> potential code that will have to be written in vdsm-tool, however it
>>> >> currently expects the data generated by aforementioned chain. The hyb=
rid
>>> >> approach briefly touches on simplifying Engine's involvement while re=
taining
>>> >> use of otopi's plugin.
>>> >>
>>> >
>>> > Okay. I think that writing a new plugin for firewalld is indeed a good=

>>> > option, whether you "refactor" the engine side or not.
>>>=20
>>> otopi already has a 'firewalld' plugin. It's already in use, at least
>>> by engine-setup, so we should be a bit careful if we want to change it.
>>> Not preventing/objecting anything, just mentioning.
>>>=20
>>> This plugin's interface currently only takes XML-content as input.
>>> It has no place for configuring existing firewalld services presumably
>>> already provided elsewhere (by firewalld itself or 3rd party packages,
>>> such as vdsm). So if we go that route we probably want to extend this
>>> interface to allow passing service names and rely on them being defined
>>> elsewhere.
>>>=20
>>> A related issue is that for engine-setup, the _input_ is currently
>>> firewalld xml content, and if users choose to configure 'iptables',
>>> this is parsed to generate iptables rules. This is currently an engine-s=
etup
>>> issue only, but will affect also host deploy flow if we decided to
>>> allow passing service names (without their xml content) and still keep
>>> compatibility to current state and allow configuring iptables on the
>>> host. We'll then be there in the same situation we are at with engine-se=
tup.
>>> See also https://bugzilla.redhat.com/1432354 . An alternative is obvious=
ly
>>> deciding to remove iptables support and support only firewalld, but this=

>>> is a rather radical change for users, imo.
>>>=20
>>> See also this for some of the existing behavior of engine-setup:
>>>=20
>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1024707#c9
>>>=20
>>> IMO we first need to decide what we want, then how to do that. IMO the
>>> questions we have re "what we want" are, more-or-less:
>>>=20
>>> 1. Do we want to support in some version X both iptables and firewalld, o=
r
>>> is it ok to stop support for iptables and support only firewalld without=

>>> overlap? If so, do we handle upgrades, and how?
>>>=20
>>> 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)?
>>>=20
>>> 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?
>>>=20
>>> (2.) and (3.) are not conflicting, each needs its own answer.
>>>=20
>>> My (thoughts about) answers:
>>>=20
>>> 1. If done well enough, and considerably simplifies things, I think it's=

>>> ok to jump directly from "only iptables" to "only firewalld", but then
>>> we should announce this ahead of time to give users time to plan/prepare=
.
>>> If it's not too costly, I'd prefer to support both for the foreseeable
>>> future, though.
>>>=20
>>> 2. Latter option here is problematic, if we need/want to allow
>>> customizing services during deploy. E.g. suppose that one day we want
>>> to make the vdsm port configurable. It will be nice if this can be done
>>> by only changing things on the engine, without having to distribute
>>> changes (conf and/or packages) to all hosts before host-deploy.
>>> I'd say we can go a long way here by having a strict requirement from
>>> all services that we need/want on hosts to have official IANA-registered=

>>> port numbers - then, it's imo much easier to tell users "If you want to
>>> change the port for service X, you have to (long list of complex actions=

>>> goes here)". Currently, where services are not registered, we risk
>>> conflicts with existing services, requiring the user to change ports -
>>> and so we can't make this process too difficult. No idea how important
>>> this is in practice.
>>>=20
>>> 3. Not sure :-( I'd say that if we want to support both iptables and
>>> firewalld together, and support both "xml in engine" and "xml in host",
>>> then it might be ok if the custom rules/services will not automatically
>>> apply to both iptables and firewalld. Meaning - you can set both custom
>>> iptables rules and firewalld services, but it's up to you to make sure
>>> they actually do the same thing if that's important to you.
>>>=20
>>> Bottom line: I think we should summarize the open questions in a way
>>> that will make it clear to users how each answer will affect them, and
>>> ask what they think. Leon already started doing this [1], I only saw
>>> one reply. Perhaps this means that users do not care that much, and
>>> expect us to just decide and tell them what we decided (and always to
>>> keep the option to disable this feature, as is possible today, and do
>>> this themselves, if our choice of solution does not fit their needs).
>>>=20
>>> I know this is way too loooong, sorry. Feel free to ignore, but then
>>> please ask simpler questions if you want shorter answers :-)
>>>=20
>>> [1] http://lists.ovirt.org/pipermail/users/2017-March/080600.html
>>>=20
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali@redhat.com> w=
rote:
>>> >>>
>>> >>> top-posting:
>>> >>> You need to also consider how upgrade will be handled, right?
>>> >>> Or iptables will still remain supported?
>>> >>>
>>> >>> Also, see some comments inline.
>>> >>>
>>> >>> Regards,
>>> >>> Oved
>>> >>>
>>> >>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber@redhat.com>=

>>> >>> wrote:
>>> >>>>
>>> >>>>
>>> >>>> Hey,
>>> >>>>
>>> >>>> We're looking to migrate from iptables to firewalld. We came up wit=
h a
>>> >>>> couple of possible approaches we'd like opinions on. I'll list the o=
ptions
>>> >>>> first, and will
>>> >>>>
>>> >>>> 1) Replicate existing flow:
>>> >>>>
>>> >>>> As of date, iptable rules are inserted in the database via SQL conf=
ig
>>> >>>> files. During host deployment, VdsDeployIptablesUnit adds the requi=
red rules
>>> >>>> (based on cluster/firewall configuration) to the deployment configu=
ration,
>>> >>>> en route to being deployed on the host via otopi and its iptables p=
lugin.
>>> >>>>
>>> >>>> Pros:
>>> >>>>
>>> >>>> - Reuse of existing infrastructure.
>>> >>>>
>>> >>>> Cons:
>>> >>>>
>>> >>>> - Current infrastructure is overly complex...
>>> >>>
>>> >>>
>>> >>> Can you elaborate?
>>> >>> I'm not an otopi expert, but I think that otopi plugins shouldn't be=
 more
>>> >>> complex than what you describe in section #2, and the plugins were m=
eant in
>>> >>> order to handle such cases.
>>> >>>
>>> >>>> - Many of the required services are provided by firewalld. Rewritin=
g
>>> >>>> them is wasteful; specifying them (instead of providing actual serv=
ice .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/firewal=
l
>>> >>>> configuration) to determine if/how firewalld should be deployed cou=
ld be
>>> >>>> passed on to the host via ohd. Vdsm could take on the responsibilit=
y of
>>> >>>> examining the relevant configuration, and then creating and/or addi=
ng the
>>> >>>> required services (using vdsm.conf and vdsm-tool).
>>> >>>>
>>> >>>
>>> >>> So here you replace the otopi plugin with relevant vdsm-tool code, a=
nd
>>> >>> the question is why is that better?
>>> >>>
>>> >>>>
>>> >>>> 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 rul=
es 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 cou=
ld be
>>> >>>> replicated and be made more simpler. Instead of providing xml conte=
nt in the
>>> >>>> form of strings, service names could be supplied. The responsibilit=
y of
>>> >>>> actual service deployment becomes easier, and could be left to otop=
i (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 imple=
menting
>>> >>>> logic that ask whether some service is provided (and then write it i=
f it
>>> >>>> isn't...), and so choosing between the dynamic and static approache=
s is also
>>> >>>> needed. Using the static approach, guaranteeing all services are pr=
ovided
>>> >>>> will be required.
>>> >>>>
>>> >>>> I do believe guaranteeing the presence of all required services is w=
orth
>>> >>>> it, however custom services aren't going to be naively compatible, a=
nd we'll
>>> >>>> still have to use similar mechanism as described in #1 (service str=
ing ->
>>> >>>> .xml -> addition of service name to active zone).
>>> >>>>
>>> >>>>
>>> >>>> Your thoughts are welcome.
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Leon
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>=20
>>>=20
>>>=20
>>> --
>>> Didi
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>=20
>>=20
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>=20

--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><br></div><div><br>On 27 Mar 2017, at 1=
7:05, Leon Goldberg <<a href=3D"mailto:lgoldber@redhat.com">lgoldber@redh=
at.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D=
"ltr">> Why do we need to use firewalld?<br><span class=3D"gmail-"></span=
><div>I
 think that the initial trigger was the realization we're completely=20
lacking ipv6 handling (which requires use of another, similar tool in=20
ip6tables) in the current infrastructure. <br><br>Assessing the situation an=
d reviewing the code for potential solutions led us to a couple of conclusio=
ns:<br><br></div><div>- Current flow is overly complex and should be reexami=
ned regardless.<br></div><div>-
 The naive solution would be to duplicate the current flow for=20
ip6tables, potentially leading to a lot of boilerplate code. I'm sure=20
there are more sophisticated solutions that could be implemented within=20
the current infrastructure, but firewalld naturally came up as it allows
 us to handle both ipv4 and ipv6 via a single entity.<br></div><div>- As
 many of the services are already statically provided by either=20
firewalld or 3rd party packages, we'll be able to merely pass names of=20
services instead of complete rule sets.<br></div><div>- el7 is shipped with a=
nd makes use of firewalld by default.<br><br></div><div><span class=3D"gmail=
-">> What is the role of the central management in this regard?<br></span=
>I'd like its role to be as insignificant as possible.<span class=3D"gmail-"=
><br><br>> -- Does it need to manage firewalls per host in detail? (are w=
e acting as a firewall management system?)<br></span></div><div>No.
 Ansible was recently brought up as a solution/replacement to custom=20
rules/service deployment, and other than that, there is no justification
 to having central management. The hosts have the required information=20
to determine which services/rules should be enabled on them (via either=20
vdsm or otopi)<br><br></div><span class=3D"gmail-"><div>> -- Does it need=
 to apply a firewall template configuration to all the hosts? (all being ide=
ntical)<br>> -- Does it need to specify what services it wants the host t=
o run and mention if the whole setup should be harden or not?<br></div></spa=
n><div>If
 we do decide to keep Engine's involvement, it should be as minimal as=20
possible. Names of required services should be provided and that's it,=20
in my opinion (and even that sounds wasteful).<span class=3D"gmail-"><br><br=
>> As far as I know, firewalld and=20
iptables can co-exist, therefore, I do not see the need to 'upgrade' or=20
perform a hard replacement.<br>> It can be done as an option (firewall-ty=
pe: iptables/firewalld).<br>> On upgrade it continues with the 'old' defi=
nition and on new created host the default can be firewalld.<br>>
 Is someone will explicitly want to change it from one to the other, we=20
could go with remove/add approach to make things simpler.<br></span></div><d=
iv>firewalld doesn't play well with iptables' service. Enabling firewalld di=
sables iptables' service and flushes its rules. <br></div></div></div></bloc=
kquote><div><br></div>Understood, good to know.<div>But still, this approach=
 will work fine, we do the same with linux/ovs bridge options. Add an option=
 to choose the  firewall type. Support both at phase 1, allowing to cha=
nge the type and at phase 2 deprecate the iptables type.</div><div><br><bloc=
kquote type=3D"cite"><div><div dir=3D"ltr"><span class=3D"gmail-"><div><br>&=
gt; I
 personally like the distributed approach, where the upper management=20
layer passes what it wants to the lower layers with minimum information.
 Letting the lower levels<br>> do the explicit work and figure out what t=
hey need to do.<br>> If
 that was the original approach, Engine would have not 'care' what type=20
of firewall you use down at the host, you could even use a custom=20
firewall, an NFV firewall solution<br>> or anything that may pop up in th=
e future.<br><div>> Engine would have just said: I want libvirt, vdsm, ss=
h, etc... services opened (for access from ...).<br></div>> Custom
 settings? That implies we manage firewalls. So either let the user add=20
their special stuff on the hosts or provide them with a proper firewall=20
management interface.<br></div></span>Agreed. I'll go even further=20
and write that Engine shouldn't even state the services hosts require; a
 host should be self aware of the services it needs to use based on the=20
relevant configuration (e.g. if gluster is supported in the cluster,=20
enable gluster service)</div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ehaas@redhat.com" target=3D"_blank">ehaas@redhat.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div><div><div><div><div><div><div><div><div><div><br>I may be too naive, b=
ut it all sounds too complex to me.<br>Is there any reference to the use cas=
es of the firewall configuration?<br><br></div><div>Few questions:<br></div>=
- Why do we need to use firewalld?<br></div>- What is the role of the centra=
l management in this regard?<br>-- Does it need to manage firewalls per host=
 in detail? (are we acting as a firewall management system?)<br>-- Does it n=
eed to apply a firewall template configuration to all the hosts? (all being i=
dentical)<br></div>-- Does it need to specify what services it wants the hos=
t to run and mention if the whole setup should be harden or not?<br><br></di=
v>As far as I know, firewalld and iptables can co-exist, therefore, I do not=
 see the need to 'upgrade' or perform a hard replacement.<br></div>It can be=
 done as an option (firewall-type: iptables/firewalld).<br>On upgrade it con=
tinues with the 'old' definition and on new created host the default can be f=
irewalld.<br></div>Is someone will explicitly want to change it from one to t=
he other, we could go with remove/add approach to make things simpler.<br><b=
r></div>I personally like the distributed approach, where the upper manageme=
nt layer passes what it wants to the lower layers with minimum information. L=
etting the lower levels<br></div>do the explicit work and figure out what th=
ey need to do.<br></div>If that was the original approach, Engine would have=
 not 'care' what type of firewall you use down at the host, you could even u=
se a custom firewall, an NFV firewall solution<br></div>or anything that may=
 pop up in the future.<br></div><div>Engine would have just said: I want lib=
virt, vdsm, ssh, etc... services opened (for access from ...).<br></div><div=
>Custom settings? That implies we manage firewalls. So either let the user a=
dd their special stuff on the hosts or provide them with a proper firewall m=
anagement interface.<br></div><div><br></div>Thanks,<br></div>Edy.<br><div><=
div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></=
div></div></div></div></div></div></div></div></div></div></div></div></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div cl=
ass=3D"h5">On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <span dir=3D"=
ltr"><<a href=3D"mailto:didi@redhat.com" target=3D"_blank">didi@redhat.co=
m</a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><d=
iv class=3D"h5"><span>On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <<a h=
ref=3D"mailto:oourfali@redhat.com" target=3D"_blank">oourfali@redhat.com</a>=
> wrote:<br>
><br>
><br>
> On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <<a href=3D"mailto:lg=
oldber@redhat.com" target=3D"_blank">lgoldber@redhat.com</a>> wrote:<br>
>><br>
>> Hey Oved,<br>
>><br>
>> I don't think completely moving away from iptables is foreseeable a=
t this<br>
>> point, but I could be of course wrong. Either way, upgrading still n=
eeds to<br>
>> be thought of.<br>
>><br>
><br>
> I see.<br>
><br>
>><br>
>> By stating that the current infrastructure is complex, I was referr=
ing to<br>
>> the entire chain of storing rules in the database, fetching them us=
ing a<br>
>> dedicated deployment class consisting of include/exclude logic, sen=
ding them<br>
>> over, unpacking, deploying...<br>
>><br>
>> This procedure involves a lot of code that could be made redundant i=
f the<br>
>> required logic is present in the host, which to me seems favorable.=
 It of<br>
>> course entails other potential difficulties, primarily in the form o=
f custom<br>
>> services.<br>
>><br>
>> I don't think otopi's firewalld plugin is any more complex than the=
<br>
>> potential code that will have to be written in vdsm-tool, however i=
t<br>
>> currently expects the data generated by aforementioned chain. The h=
ybrid<br>
>> approach briefly touches on simplifying Engine's involvement while r=
etaining<br>
>> use of otopi's plugin.<br>
>><br>
><br>
> Okay. I think that writing a new plugin for firewalld is indeed a good<=
br>
> option, whether you "refactor" the engine side or not.<br>
<br>
</span>otopi already has a 'firewalld' plugin. It's already in use, at least=
<br>
by engine-setup, so we should be a bit careful if we want to change it.<br>
Not preventing/objecting anything, just mentioning.<br>
<br>
This plugin's interface currently only takes XML-content as input.<br>
It has no place for configuring existing firewalld services presumably<br>
already provided elsewhere (by firewalld itself or 3rd party packages,<br>
such as vdsm). So if we go that route we probably want to extend this<br>
interface to allow passing service names and rely on them being defined<br>
elsewhere.<br>
<br>
A related issue is that for engine-setup, the _input_ is currently<br>
firewalld xml content, and if users choose to configure 'iptables',<br>
this is parsed to generate iptables rules. This is currently an engine-setup=
<br>
issue only, but will affect also host deploy flow if we decided to<br>
allow passing service names (without their xml content) and still keep<br>
compatibility to current state and allow configuring iptables on the<br>
host. We'll then be there in the same situation we are at with engine-setup.=
<br>
See also <a href=3D"https://bugzilla.redhat.com/1432354" rel=3D"noreferrer" t=
arget=3D"_blank">https://bugzilla.redhat.com/14<wbr>32354</a> . An alternati=
ve is obviously<br>
deciding to remove iptables support and support only firewalld, but this<br>=

is a rather radical change for users, imo. 
 
See also this for some of the existing behavior of engine-setup: 
 
<a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1024707#c9" rel=3D"=
noreferrer" target=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?=
id=3D1024707#c9</a> 
 
IMO we first need to decide what we want, then how to do that. IMO the 
questions we have re "what we want" are, more-or-less: 
 
1. Do we want to support in some version X both iptables and firewalld, or<b=
r>
is it ok to stop support for iptables and support only firewalld without =

overlap? If so, do we handle upgrades, and how?<br>
<br>
2. Do we want to support custom firewalld xml to be configured on the<br>
host by us? Or is it ok to only support choosing among existing services,<br=
>
which will need to be added to the host using other means (packaged by<br>
firewalld, packaged by 3rd parties, added manually by users)?<br>
<br>
3. Opposite of (2.): Do we want to support firewalld services that are<br>
added to the host using other means (see there)? Obviously we do, but:<br>
If we do, do we still want to support also iptables (see (1.))? And if<br>
so, what do we want to then happen?<br>
<br>
(2.) and (3.) are not conflicting, each needs its own answer.<br>
<br>
My (thoughts about) answers:<br>
<br>
1. If done well enough, and considerably simplifies things, I think it's<br>=

ok to jump directly from "only iptables" to "only firewalld", but then<br>
we should announce this ahead of time to give users time to plan/prepare.<br=
>
If it's not too costly, I'd prefer to support both for the foreseeable<br>
future, though.<br>
<br>
2. Latter option here is problematic, if we need/want to allow<br>
customizing services during deploy. E.g. suppose that one day we want<br>
to make the vdsm port configurable. It will be nice if this can be done<br>
by only changing things on the engine, without having to distribute<br>
changes (conf and/or packages) to all hosts before host-deploy.<br>
I'd say we can go a long way here by having a strict requirement from<br>
all services that we need/want on hosts to have official IANA-registered<br>=

port numbers - then, it's imo much easier to tell users "If you want to<br>
change the port for service X, you have to (long list of complex actions<br>=

goes here)". Currently, where services are not registered, we risk<br>
conflicts with existing services, requiring the user to change ports -<br>
and so we can't make this process too difficult. No idea how important<br>
this is in practice.<br>
<br>
3. Not sure :-( I'd say that if we want to support both iptables and<br>
firewalld together, and support both "xml in engine" and "xml in host",<br>
then it might be ok if the custom rules/services will not automatically<br>
apply to both iptables and firewalld. Meaning - you can set both custom<br>
iptables rules and firewalld services, but it's up to you to make sure<br>
they actually do the same thing if that's important to you.<br>
<br>
Bottom line: I think we should summarize the open questions in a way<br>
that will make it clear to users how each answer will affect them, and<br>
ask what they think. Leon already started doing this [1], I only saw<br>
one reply. Perhaps this means that users do not care that much, and<br>
expect us to just decide and tell them what we decided (and always to<br>
keep the option to disable this feature, as is possible today, and do<br>
this themselves, if our choice of solution does not fit their needs).<br>
<br>
I know this is way too loooong, sorry. Feel free to ignore, but then<br>
please ask simpler questions if you want shorter answers :-)<br>
<br>
[1] <a href=3D"http://lists.ovirt.org/pipermail/users/2017-March/080600.html=
" rel=3D"noreferrer" target=3D"_blank">http://lists.ovirt.org/piperma<wbr>il=
/users/2017-March/080600.<wbr>html</a><br>
<div class=3D"m_7457438430304499453HOEnZb"><div class=3D"m_74574384303044994=
53h5"><br>
><br>
>><br>
>><br>
>><br>
>> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <<a href=3D"mailto=
:oourfali@redhat.com" target=3D"_blank">oourfali@redhat.com</a>> wrote:<b=
r>
>>><br>
>>> top-posting:<br>
>>> You need to also consider how upgrade will be handled, right?<b=
r>
>>> Or iptables will still remain supported?<br>
>>><br>
>>> Also, see some comments inline.<br>
>>><br>
>>> Regards,<br>
>>> Oved<br>
>>><br>
>>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <<a href=3D"m=
ailto:lgoldber@redhat.com" target=3D"_blank">lgoldber@redhat.com</a>><br>=

>>> wrote:<br>
>>>><br>
>>>><br>
>>>> Hey,<br>
>>>><br>
>>>> We're looking to migrate from iptables to firewalld. We cam=
e up with a<br>
>>>> couple of possible approaches we'd like opinions on. I'll l=
ist the options<br>
>>>> first, and will<br>
>>>><br>
>>>> 1) Replicate existing flow:<br>
>>>><br>
>>>> As of date, iptable rules are inserted in the database via S=
QL config<br>
>>>> files. During host deployment, VdsDeployIptablesUnit adds t=
he required rules<br>
>>>> (based on cluster/firewall configuration) to the deployment=
 configuration,<br>
>>>> en route to being deployed on the host via otopi and its ip=
tables plugin.<br>
>>>><br>
>>>> Pros:<br>
>>>><br>
>>>> - Reuse of existing infrastructure.<br>
>>>><br>
>>>> Cons:<br>
>>>><br>
>>>> - Current infrastructure is overly complex...<br>
>>><br>
>>><br>
>>> Can you elaborate?<br>
>>> I'm not an otopi expert, but I think that otopi plugins shouldn=
't be more<br>
>>> complex than what you describe in section #2, and the plugins w=
ere meant in<br>
>>> order to handle such cases.<br>
>>><br>
>>>> - Many of the required services are provided by firewalld. R=
ewriting<br>
>>>> them is wasteful; specifying them (instead of providing act=
ual service .xml<br>
>>>> content) will require adaptations on both (engine/host) sid=
es. More on that<br>
>>>> later.<br>
>>>><br>
>>>><br>
>>>> 2) Host side based configuration:<br>
>>>><br>
>>>> Essentially, all the required logic (aforementioned cluster=
/firewall<br>
>>>> configuration) to determine if/how firewalld should be depl=
oyed could be<br>
>>>> passed on to the host via ohd. Vdsm could take on the respo=
nsibility of<br>
>>>> examining the relevant configuration, and then creating and=
/or adding the<br>
>>>> required services (using vdsm.conf and vdsm-tool).<br>
>>>><br>
>>><br>
>>> So here you replace the otopi plugin with relevant vdsm-tool co=
de, and<br>
>>> the question is why is that better?<br>
>>><br>
>>>><br>
>>>> Pros:<br>
>>>><br>
>>>>  - Engine side involvement is greatly diminished.<br>
>>>>  - Simple(r).<br>
>>>><br>
>>>> Cons:<br>
>>>><br>
>>>>  - Custom services/rules capabilities will have to be r=
ethought and<br>
>>>> re-implemented (current infrastructure supports custom ipta=
bles rules by<br>
>>>> being specified in the SQL config file).<br>
>>>><br>
>>>><br>
>>>> 3) Some other hybrid approach:<br>
>>>><br>
>>>> If we're able to guarantee all the required firewalld servi=
ces are<br>
>>>> statically provided one way or the other, the current proce=
dure could be<br>
>>>> replicated and be made more simpler. Instead of providing x=
ml content in the<br>
>>>> form of strings, service names could be supplied. The respo=
nsibility of<br>
>>>> actual service deployment becomes easier, and could be left=
 to otopi (with<br>
>>>> the appropriate modifications) or switched over to vdsm.<br=
>
>>>><br>
>>>> --<br>
>>>><br>
>>>> Regardless, usage of statically provided vs. dynamically cr=
eated<br>
>>>> services remains an open question. I think we'd like to avo=
id implementing<br>
>>>> logic that ask whether some service is provided (and then w=
rite it if it<br>
>>>> isn't...), and so choosing between the dynamic and static a=
pproaches is also<br>
>>>> needed. Using the static approach, guaranteeing all service=
s are provided<br>
>>>> will be required.<br>
>>>><br>
>>>> I do believe guaranteeing the presence of all required serv=
ices is worth<br>
>>>> it, however custom services aren't going to be naively comp=
atible, and we'll<br>
>>>> still have to use similar mechanism as described in #1 (ser=
vice string -><br>
>>>> .xml -> addition of service name to active zone).<br>
>>>><br>
>>>><br>
>>>> Your thoughts are welcome.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Leon<br>
>>>><br>
>>><br>
>><br>
><br>
<br>
<br>
<br>
</div></div></div></div><span class=3D"HOEnZb"><font color=3D"#888888"><span=
 class=3D"m_7457438430304499453HOEnZb"><font color=3D"#888888">--<br>
Didi<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href=3D"mailto:Devel@ovirt.org" target=3D"_blank">Devel@ovirt.org</a><br>=

<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" rel=3D"noreferrer"=
 target=3D"_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br=
>
</font></span></font></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href=3D"mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" rel=3D"noreferrer"=
 target=3D"_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br=
></blockquote></div><br></div>
</div></blockquote></div></body></html>=

--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37--

tags

participants (10)