----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Doron Fediuck" <dfedi...@redhat.com> > Cc: "David Jaša" <dj...@redhat.com>, engine-devel@ovirt.org > Sent: Sunday, September 2, 2012 11:51:40 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > > On 09/02/2012 05:21 PM, Doron Fediuck wrote: > > ----- Original Message ----- > >> From: "Andrew Cathrow" <acath...@redhat.com> > >> To: "Alon Bar-Lev" <alo...@redhat.com> > >> Cc: "David Jaša" <dj...@redhat.com>, engine-devel@ovirt.org > >> Sent: Friday, August 31, 2012 3:12:34 PM > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Alon Bar-Lev" <alo...@redhat.com> > >>> To: "David Jaša" <dj...@redhat.com> > >>> Cc: engine-devel@ovirt.org > >>> Sent: Friday, August 31, 2012 5:09:47 AM > >>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "David Jaša" <dj...@redhat.com> > >>>> To: engine-devel@ovirt.org > >>>> Sent: Friday, August 31, 2012 11:57:11 AM > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>> > >>>> Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Andrew Cathrow" <acath...@redhat.com> > >>>>>> To: "Alon Bar-Lev" <alo...@redhat.com> > >>>>>> Cc: "Shireesh Anjal" <san...@redhat.com>, > >>>>>> engine-devel@ovirt.org, > >>>>>> "Selvasundaram" <sesub...@redhat.com> > >>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM > >>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>>>> > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Alon Bar-Lev" <alo...@redhat.com> > >>>>>>> To: "Selvasundaram" <sesub...@redhat.com> > >>>>>>> Cc: "Shireesh Anjal" <san...@redhat.com>, > >>>>>>> engine-devel@ovirt.org > >>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM > >>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Selvasundaram" <sesub...@redhat.com> > >>>>>>>> To: engine-devel@ovirt.org > >>>>>>>> Cc: "Shireesh Anjal" <san...@redhat.com> > >>>>>>>> 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. > >>>>>> > >>>>>> > >>>>>> or create custom chains ? > >>>>> > >>>>> Can you please elaborate what is custom chains? > >>>>> Thanks! > >>>> > >>>> iptables -N my_new_chain > >>>> iptables -A my_new_chain <rule_1> > >>>> iptables -A my_new_chain ... > >>>> iptables -A my_new_chain <rule_n> > >>>> > >>>> # if this <rule> is matched, packet goes through rules in > >>>> my_new_chain > >>>> iptables -A INPUT <rule> -j my_new_chain > >>>> > >>> > >>> Hello, > >>> > >>> How does this solve the original issue? > >> > >> It makes it easier for customers who are adding their own IPTables > >> configuration - when we do rhev-h plugins it'll make things > >> easier. > >> This way we don't wipe out the original rules we just add our own > >> chain. > >> > >> > > > > Current default (virt) iptables configuration is kept in the > > engine's DB. > > So... > > > > 1. We can update the DB value to include Gluster configuration. > > or > > 2. Have an additional DB value for virt+Gluster. > > 3. gluster only, not virt. > > > > > So (1) will work, but when gluster is not relevant we have > > redundant ports. > > But my only reservation from (2) is that it's not scalable for > > additional > > services. > > > > Either way, I agree with Alon that melding the configurations at > > runtime > > is unexpected, and shouldn't be used. > > > > After some additional thought... we can have (1), and make all > > gluster > > entries commented out (let's say with #GLSTR) by default, so it'll > > be > > enabled only when gluster is being used. This will allow > > introducing future > > configurations as well without the need for additional DB values. > > why not use the chains approach, and have a chain per service? >
Since you wish to avoid collisions. So for gluster only, have a VIRT prefix as well. > > > > Sample snip of DB value: > > ================================================================================== > > :INPUT ACCEPT [0:0] > > :FORWARD ACCEPT [0:0] > > :OUTPUT ACCEPT [0:0] > > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > -A INPUT -p icmp -j ACCEPT > > -A INPUT -i lo -j ACCEPT > > # vdsm > > -A INPUT -p tcp --dport 54321 -j ACCEPT > > # libvirt tls > > -A INPUT -p tcp --dport 16514 -j ACCEPT > > # SSH > > -A INPUT -p tcp --dport 22 -j ACCEPT > > # guest consoles > > -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT > > # gluster p1 > > #GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT > > # gluster p2-p6 > > #GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT > > # Reject any other input traffic > > -A INPUT -j REJECT --reject-with icmp-host-prohibited > > -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT > > --reject-with icmp-host-prohibited > > COMMIT > > ================================================================================== > > > > So as you can see, this is something we can handle in run-time. > > Also it's easy > > to test, so predictable, and finally- human beings can look and > > understand what > > it means. > > > > > >>> The need to provide different rules to different hosts by > >>> software > >>> installed on destination? > >>> > >>> Standard host needs iptables X. > >>> Gluster host needs iptables X+Y. > >>> XXX host needs iptables X+Z. > >>> Maintainer of Gluster knows what Y is. > >>> Maintainer of XXX knows what Z is. > >>> > >>> If we merge all to one entry product comes with default X. > >>> User override X to A. > >>> New version of product comes with default Y. > >>> Upgrade options: > >>> 1. System continues to use A. > >>> 2. Some AI to upgrade and create A'. > >>> 3. Revert to Y, dropping user's customization. > >>> > >>> Or we can maintain one large table with complete configuration > >>> and > >>> conditionals. > >>> > >>> Alon. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel