27 Mar
2017
27 Mar
'17
2:11 p.m.
--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.<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>ow_bug.cgi?= 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@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--