[Engine-devel] Gluster IPTable configuration

Mon Sep 3 06:09:04 UTC 2012

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "David Jaša" <djasa at redhat.com>, engine-devel at 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" <acathrow at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "David Jaša" <djasa at redhat.com>, engine-devel at ovirt.org
> >> Sent: Friday, August 31, 2012 3:12:34 PM
> >> Subject: Re: [Engine-devel] Gluster IPTable configuration
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> To: "David Jaša" <djasa at redhat.com>
> >>> Cc: engine-devel at ovirt.org
> >>> Sent: Friday, August 31, 2012 5:09:47 AM
> >>> Subject: Re: [Engine-devel] Gluster IPTable configuration
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "David Jaša" <djasa at redhat.com>
> >>>> To: engine-devel at 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" <acathrow at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: "Shireesh Anjal" <sanjal at redhat.com>,
> >>>>>> engine-devel at ovirt.org,
> >>>>>> "Selvasundaram" <sesubram at redhat.com>
> >>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM
> >>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>>> To: "Selvasundaram" <sesubram at redhat.com>
> >>>>>>> Cc: "Shireesh Anjal" <sanjal at redhat.com>,
> >>>>>>> engine-devel at ovirt.org
> >>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM
> >>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Selvasundaram" <sesubram at redhat.com>
> >>>>>>>> To: engine-devel at ovirt.org
> >>>>>>>> Cc: "Shireesh Anjal" <sanjal at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 