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