Re: [Engine-devel] Gluster IPTable configuration

From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; To: "Andrew Cathrow" <acathrow(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com&gt; Sent: Monday, September 3, 2012 4:50:00 PM Subject: Re: [Engine-devel] Gluster IPTable configuration ----- Original Message ----- > From: "Andrew Cathrow" <acathrow(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com&gt; > Sent: Monday, September 3, 2012 11:05:20 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > To: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > > Cc: engine-devel(a)ovirt.org > > Sent: Monday, September 3, 2012 9:50:52 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > > > > ----- Original Message ----- > > > From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > Cc: "Selvasundaram" <sesubram(a)redhat.com&gt;, > > > engine-devel(a)ovirt.org > > > Sent: Monday, September 3, 2012 4:21:58 PM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > > > > > > > ----- Original Message ----- > > > >> From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > > > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > >> Cc: "Selvasundaram" <sesubram(a)redhat.com&gt;, > > > >> engine-devel(a)ovirt.org > > > >> Sent: Monday, September 3, 2012 4:00:14 PM > > > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > >> > > > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > > >>> ----- Original Message ----- > > > >>>> From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > > > >>>> To: engine-devel(a)ovirt.org > > > >>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "Selvasundaram" > > > >>>> <sesubram(a)redhat.com&gt; > > > >>>> Sent: Monday, September 3, 2012 3:42:17 PM > > > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > >>>> > > > >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Selvasundaram" <sesubram(a)redhat.com&gt; > > > >>>>>> To: engine-devel(a)ovirt.org > > > >>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com&gt; > > > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > > > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration > > > >>>>>> > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> I want to add gluster specific IPTable configuration in > > > >>>>>> addition > > > >>>>>> to > > > >>>>>> the ovirt IPTable configuration (if it is gluster node). > > > >>>>>> > > > >>>>>> There are two approaches, > > > >>>>>> 1. Having one more gluster specific IP table config in > > > >>>>>> db > > > >>>>>> and > > > >>>>>> merge > > > >>>>>> with ovirt IPTable config (merging NOT appending) > > > >>>>>> [I have the patch engine: Gluster specific firewall > > > >>>>>> configurations > > > >>>>>> #7244] > > > >>>>>> 2. Having two different IP Table config (ovirt and > > > >>>>>> ovirt+gluster) > > > >>>>>> and > > > >>>>>> use either one. > > > >>>>>> > > > >>>>>> Please provide your suggestions or improvements on this. > > > >>>>>> > > > >>>>> Hello all, > > > >>>>> > > > >>>>> The mentioned patch[1], adds hard coded gluster code into > > > >>>>> the > > > >>>>> bootstrap code, manipulate the firewall configuration to > > > >>>>> be > > > >>>>> gluster specific. It hardcoded search for "reject", > > > >>>>> insert > > > >>>>> before > > > >>>>> some other rules. > > > >>>>> > > > >>>>> I believe this hardcode approach is obsolete now that we > > > >>>>> have > > > >>>>> proper tools for templates. > > > >>>>> > > > >>>>> A more robust solution would be defining generic > > > >>>>> profiles, > > > >>>>> each > > > >>>>> profile as a template, each template can refer to > > > >>>>> different > > > >>>>> profiles, and assign profile to a node. > > > >>>>> > > > >>>>> This way the implementation is not gluster [or any] > > > >>>>> specific > > > >>>>> and > > > >>>>> can be reused for more setups, code is cleaner. > > > >>>>> > > > >>>>> Example: > > > >>>>> > > > >>>>> BASIC.PRE > > > >>>>> :INPUT ACCEPT [0:0] > > > >>>>> :FORWARD ACCEPT [0:0] > > > >>>>> :OUTPUT ACCEPT [0:0] > > > >>>>> BASIC.IN > > > >>>>> accept ... > > > >>>>> accept ... > > > >>>>> BASIC.POST > > > >>>>> reject ... > > > >>>>> reject ... > > > >>>>> > > > >>>>> BASIC > > > >>>>> ${BASIC.PRE} > > > >>>>> ${BASIC.IN} > > > >>>>> ${BASIC.POST} > > > >>>>> > > > >>>>> GLUSTER > > > >>>>> ${BASIC.PRE} > > > >>>>> ${BASIC.IN} > > > >>>>> accept ... > > > >>>>> ${BASIC.POST} > > > >>>>> reject ... > > > >>>> I like the separation of PRE/IN/POST rules here. However I > > > >>>> think > > > >>>> it > > > >>>> is > > > >>>> better to keep the service specific rules in separate > > > >>>> configurations. > > > >>>> Currently, whole iptables rules script is kept in the vdc > > > >>>> option > > > >>>> "IPTablesConfig". How about changing this as follows? > > > >>>> > > > >>>> - Split the current config into three: IPTablesConfig.PRE, > > > >>>> IPTablesConfig.VIRT and IPTablesConfig.POST > > > >>>> - Let services like Gluster add their own vdc options e.g. > > > >>>> IPTablesConfig.GLUSTER > > > >>>> - When assembling the full script in VdsInstaller, > > > >>>> - Take IPTablesConfig.PRE > > > >>>> - Append it with IPTablesConfig.<service> for every > > > >>>> service > > > >>>> to > > > >>>> be > > > >>>> enabled on the host/cluster > > > >>>> - Append it with IPTablesConfig.POST > > > >>>> > > > >>>> Thoughts? > > > >>> This is a simple approach that will work for current > > > >>> implementation > > > >>> and configuration. > > > >>> > > > >>> However, it will effect all nodes, with or without gluster. > > > >> I don't get the concern here. Could you please elaborate? > > > > If we have 500 nodes, out of them 200 gluster, why do I need > > > > to > > > > distribute gluster specific rules to all 500? > > > > > > When I say "Append it with IPTablesConfig.<service> for every > > > service > > > to be enabled on the host/cluster", I mean every service that > > > "needs > > > to be enabled" on the host. In today's scenario, where virt and > > > gluster are the only two services, it will look something like: > > > > > > - If cluster supports virt, append IPTablesConfig.VIRT > > > - If cluster supports gluster, append IPTablesConfig.GLUSTER > > > > > > So it will be driven by the cluster in which the host is being > > > added. > > > And gluster rules will be sent to only the hosts of clusters > > > that > > > have gluster enabled. > > > > OK... this is why I prefer templates. Much more simple and > > generic. > > No need to have custom application logic within application. > > > Do we want to use a template that's so tightly tied into iptables - > does it lock is into an implementation in the config files? > Wouldn't > we rather have the rules in the config file (eg. tcp.port 80, > udp.port xyz, etc) rather than be so closely tied to an > implementation. You refer to a model similar to libvirt[1] referred by David - abstract anything. This model will not work well without templates, as one probably need to construct the abstract rule base similar manner by merging of hunks of configuration. You can take the result in whatever language and either convert it to another language (iptables) or to dbus calls (firewalld). My main questions are: a. Do we want to invest NOW in generic language to define firewall rules? b. Is such decision is required at this point? There are so many projects out there that are specialized in this particular domain. I, personally, find firehol[2] very useful for my configurations. But I don't know many that are intermediate between generic rules into an interface other than iptables (eg. firewalld). So we can have dependency of firewalld at node side, and feed it with whatever it accepts, however, having firewalld as dependency will make the cost of porting to other distributions much higher. > How will things look when we move to firewalld[1], or some other > system, rather than creating and managing our own iptables rules? > > What happened to the custom chain discussion, did I miss that or > was > it silently dropped? As I did not fully understand your suggestion asked, but not answered. How do you use custom chains in order to meet the requirement of providing different firewall configurations to different hosts?

Regards, Alon [1] http://libvirt.org/formatnwfilter.html [2] http://firehol.sourceforge.net/