6:11 p.m.
--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
><br ><br >
On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <<a href=3D"mailto:lg=
oldber(a)redhat.com"
target=3D"_blank">lgoldber(a)redhat.com</a>&gt; 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>32... .
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.<br
<br See also this for some of the
existing behavior of engine-setup:<br
<br <a
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1024707#c9" rel=3D"=
noreferrer"
target=3D"_blank">https://bugzilla.redhat.com/sh<wbr>o...
id=3D1024707#c9</a><br <br IMO we
first need to decide what we want, then how to do that. IMO the<br questions we have re "what we want" are,
more-or-less:<br <br 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<br>=
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(a)redhat.com</a>&gt; 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(a)redhat.com</a>&gt;<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(a)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>/...
</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/...
></blockquote></div><br></div
</div></blockquote></div></body></html>=
--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37--
On 27 Mar 2017, at 17:05, Leon Goldberg <lgoldber(a)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(a)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(a)redhat.com> wr=
ote:
>> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali
<oourfali(a)redhat.com> wrot=
e:
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(a)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(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>=20
>=20
> _______________________________________________
> Devel mailing list
> Devel(a)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(a)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(a)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(a)redhat.com</a>=
> wrote:<br