[Engine-devel] Gluster IPTable configuration
This is a multi-part message in MIME format. --------------030709000903050400090401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 <http://gerrit.ovirt.org/#/c/7244/> #7244] 2. Having two different IP Table config (ovirt and ovirt+gluster) and use either one. Please provide your suggestions or improvements on this. -- Regards Selvasundaram --------------030709000903050400090401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I want to add gluster specific IPTable configuration in addition to the ovirt IPTable configuration (if it is gluster node). <br> There are two approaches, <br> 1. Having one more gluster specific IP table config in db and merge with ovirt IPTable config (merging NOT appending)<br> [I have the patch <a href="http://gerrit.ovirt.org/#/c/7244/" class="gwt-InlineHyperlink">engine: Gluster specific firewall configurations</a> #7244]<br> 2. Having two different IP Table config (ovirt and ovirt+gluster) and use either one.<br> <br> Please provide your suggestions or improvements on this. <br> <br> --<br> Regards<br> Selvasundaram<br> <br> <br> </body> </html> --------------030709000903050400090401--
This is a multi-part message in MIME format. --------------080303050500000508090403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 <http://gerrit.ovirt.org/#/c/7244/> #7244] 2. Having two different IP Table config (ovirt and ovirt+gluster) and use either one. Please provide your suggestions or improvements on this. -- Regards Selvasundaram --------------080303050500000508090403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I want to add gluster specific IPTable configuration in addition to the ovirt IPTable configuration (if it is gluster node). <br> <br> There are two approaches, <br> 1. Having one more gluster specific IP table config in db and merge with ovirt IPTable config (merging NOT appending)<br> [I have the patch <a moz-do-not-send="true" href="http://gerrit.ovirt.org/#/c/7244/" class="gwt-InlineHyperlink">engine: Gluster specific firewall configurations</a> #7244]<br> 2. Having two different IP Table config (ovirt and ovirt+gluster) and use either one.<br> <br> Please provide your suggestions or improvements on this. <br> <br> --<br> Regards<br> Selvasundaram<br> <br> <br> </body> </html> --------------080303050500000508090403--
----- Original Message -----
From: "Selvasundaram" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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. 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 ... Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/7244/
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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 ?
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 ...
Regards, Alon Bar-Lev
[1] http://gerrit.ovirt.org/#/c/7244/ _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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!
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 ...
Regards, Alon Bar-Lev
[1] http://gerrit.ovirt.org/#/c/7244/ _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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 David
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 ...
Regards, Alon Bar-Lev
[1] http://gerrit.ovirt.org/#/c/7244/ _______________________________________________ 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
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
----- Original Message -----
From: "David Jaša" <djasa@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" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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? 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.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "David Jaša" <djasa@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" <djasa@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" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "David Jaša" <djasa@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" <alonbl@redhat.com> To: "David Jaša" <djasa@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" <djasa@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" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> To: "Selvasundaram" <sesubram@redhat.com> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> > To: engine-devel@ovirt.org > Cc: "Shireesh Anjal" <sanjal@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. 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. 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.
On 09/02/2012 05:21 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "David Jaša" <djasa@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" <alonbl@redhat.com> To: "David Jaša" <djasa@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" <djasa@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" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Shireesh Anjal" <sanjal@redhat.com>, engine-devel@ovirt.org, "Selvasundaram" <sesubram@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@redhat.com> > To: "Selvasundaram" <sesubram@redhat.com> > Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> >> To: engine-devel@ovirt.org >> Cc: "Shireesh Anjal" <sanjal@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?
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
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "David Jaša" <djasa@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" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "David Jaša" <djasa@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" <alonbl@redhat.com> To: "David Jaša" <djasa@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" <djasa@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" <acathrow@redhat.com> > To: "Alon Bar-Lev" <alonbl@redhat.com> > Cc: "Shireesh Anjal" <sanjal@redhat.com>, > engine-devel@ovirt.org, > "Selvasundaram" <sesubram@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@redhat.com> >> To: "Selvasundaram" <sesubram@redhat.com> >> Cc: "Shireesh Anjal" <sanjal@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" <sesubram@redhat.com> >>> To: engine-devel@ovirt.org >>> Cc: "Shireesh Anjal" <sanjal@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
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "David Jaša" <djasa@redhat.com>, engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:09:04 AM Subject: Re: [Engine-devel] Gluster IPTable configuration
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.
If an implementation may separate between the WHAT and the HOW, it may be easier to be maintained. --- WHAT Merge several iptables rules into one node iptables. HOW Use templates to build string, send string as a file in remote. --- As you can see the HOW (which is the actual implementation) knows nothing about iptables. So it is simple and can be reused. The whole logic of WHAT is put into the metadata, where humans may customized without touching the code, even when iptables get messy and complex. An example of WHAT and HOW that are not separated is the authentication/authorization (Kerberos/LDAP) implementation, where both WHAT and HOW are inter-connected, the cost of adding a new environment in this case is huge. Doron suggested to use comments or some signature within the iptables configuration, this is what templates are all about, however, instead of re-inventing the wheel, a standard text based templates engine can be used. The template (the WHAT) may use custom chains, regular chains, it is not important as implementation (the HOW) is not looking into the content. Alon.
what about using netcf for the configuration similarly as libvirt does? http://libvirt.org/formatnwfilter.html IMHO it should solve the problem temporarily before firewalld matures. David PS: please keep me out of CC, I'm more than happy when I watch these discussions via list Alon Bar-Lev píše v Po 03. 09. 2012 v 05:51 -0400:
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "David Jaša" <djasa@redhat.com>, engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:09:04 AM Subject: Re: [Engine-devel] Gluster IPTable configuration
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.
If an implementation may separate between the WHAT and the HOW, it may be easier to be maintained.
--- WHAT
Merge several iptables rules into one node iptables.
HOW
Use templates to build string, send string as a file in remote. ---
As you can see the HOW (which is the actual implementation) knows nothing about iptables. So it is simple and can be reused. The whole logic of WHAT is put into the metadata, where humans may customized without touching the code, even when iptables get messy and complex.
An example of WHAT and HOW that are not separated is the authentication/authorization (Kerberos/LDAP) implementation, where both WHAT and HOW are inter-connected, the cost of adding a new environment in this case is huge.
Doron suggested to use comments or some signature within the iptables configuration, this is what templates are all about, however, instead of re-inventing the wheel, a standard text based templates engine can be used.
The template (the WHAT) may use custom chains, regular chains, it is not important as implementation (the HOW) is not looking into the content.
Alon. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Selvasundaram" <sesubram@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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?
Regards, Alon Bar-Lev
[1] http://gerrit.ovirt.org/#/c/7244/ _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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 think that while we at it we should consider how to effect only appropriate subset of nodes. Alon.
On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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?
I think that while we at it we should consider how to effect only appropriate subset of nodes.
Alon.
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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? Alon.
On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> To: engine-devel@ovirt.org Cc: "Shireesh Anjal" <sanjal@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.
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.
Alon.
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> > To: engine-devel@ovirt.org > Cc: "Shireesh Anjal" <sanjal@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.
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. Alon
On Monday 03 September 2012 07:20 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> >> To: engine-devel@ovirt.org >> Cc: "Shireesh Anjal" <sanjal@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. > > 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.
I don't see what is so complex about the above approach, but do agree that it is not completely generic. A new service will require a new if condition in the VdsInstaller. In order to understand the templates approach better, can you please point me to some existing code in oVirt that uses such an approach? I see an example of the template text above, but I'm not sure how it can be used from the code.
Alon _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Shireesh Anjal" <sanjal@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:50:52 AM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: engine-devel@ovirt.org Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" <sesubram@redhat.com> 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@redhat.com> >> To: engine-devel@ovirt.org >> Cc: "Shireesh Anjal" <sanjal@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. > > 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. 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? [1] https://fedoraproject.org/wiki/FirewallD
Alon _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com> Sent: Monday, September 3, 2012 11:05:20 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Shireesh Anjal" <sanjal@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:50:52 AM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> > To: engine-devel@ovirt.org > Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" > <sesubram@redhat.com> > 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@redhat.com> >>> To: engine-devel@ovirt.org >>> Cc: "Shireesh Anjal" <sanjal@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. >> >> 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/
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com> Sent: Monday, September 3, 2012 4:50:00 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com> Sent: Monday, September 3, 2012 11:05:20 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Shireesh Anjal" <sanjal@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, September 3, 2012 9:50:52 AM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Selvasundaram" <sesubram@redhat.com>, engine-devel@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@redhat.com> >> To: engine-devel@ovirt.org >> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Selvasundaram" >> <sesubram@redhat.com> >> 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@redhat.com> >>>> To: engine-devel@ovirt.org >>>> Cc: "Shireesh Anjal" <sanjal@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. >>> >>> 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?
Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to overwrite existing rules we can extend them. The advantage of using something like firewalld to add rules is that we don't have to worry about parsing existing rules, etc we can let that service handle it. We need to handle firewall rules for ovirt-node plugins (eg. open port XYZ for monitoring agent ABC) - I'm not sure if this has been discussed yet, adding Mike ....
Regards, Alon
[1] http://libvirt.org/formatnwfilter.html [2] http://firehol.sourceforge.net/
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com>, "Mike Burns" <mburns@redhat.com> Sent: Monday, September 3, 2012 11:57:57 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
<snip>
Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to
Here I lost you... :) I thought ovirt-engine is the master and ovirt-hypervisor is a slave. This derives that all management activities of slave is done by master... There should be no setting at slave that master is not aware of. This also enables you to duplicate hipervisor, recover configuration or push mass configuration change. In your above case, this rule for monitoring agent may be added at master repository and pushed to slaves belongs to specific group, just like the gluster case. The template mechanism is what enable you to create a custom configuration per environment. Using push and not re-integrate derives much simpler and deterministic implementation. But maybe I did not understand some of the fundamental concepts of the architecture. Regards, Alon.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com>, "Mike Burns" <mburns@redhat.com> Sent: Monday, September 3, 2012 5:09:34 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com>, "Mike Burns" <mburns@redhat.com> Sent: Monday, September 3, 2012 11:57:57 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
<snip>
Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to
Here I lost you... :)
I thought ovirt-engine is the master and ovirt-hypervisor is a slave.
This derives that all management activities of slave is done by master...
Let's say I use nagios for my host monitoring. I setup a rhel/fedora/*EL host using my standard corporate and include port 5667/5666 for nagios. ovirt engine connects to it and blocks nagios. While it would be great to have all firewall rules (and other settings) managed from ovirt-engine we are a long way away from that. Adding rules rather than overwriting iptables config would allow us not to stomp on the user's existing settings.
There should be no setting at slave that master is not aware of.
This also enables you to duplicate hipervisor, recover configuration or push mass configuration change.
In your above case, this rule for monitoring agent may be added at master repository and pushed to slaves belongs to specific group, just like the gluster case.
yes, but in the 24 months between now and when we get to implement that feature ......
The template mechanism is what enable you to create a custom configuration per environment.
Using push and not re-integrate derives much simpler and deterministic implementation.
But maybe I did not understand some of the fundamental concepts of the architecture.
Regards, Alon.
Andrew Cathrow píše v Po 03. 09. 2012 v 17:21 -0400:
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com>, "Mike Burns" <mburns@redhat.com> Sent: Monday, September 3, 2012 5:09:34 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
From: "Andrew Cathrow" <acathrow@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Shireesh Anjal" <sanjal@redhat.com>, "Mike Burns" <mburns@redhat.com> Sent: Monday, September 3, 2012 11:57:57 PM Subject: Re: [Engine-devel] Gluster IPTable configuration
<snip>
Right now we just overwrite the existing iptables configuration with our own, so if a user already added a rule to their host - eg. for a monitoring agent the we stomp over it. Adding our rules as a custom chain means that we don't need to
Here I lost you... :)
I thought ovirt-engine is the master and ovirt-hypervisor is a slave.
This derives that all management activities of slave is done by master...
Let's say I use nagios for my host monitoring. I setup a rhel/fedora/*EL host using my standard corporate and include port 5667/5666 for nagios. ovirt engine connects to it and blocks nagios.
While it would be great to have all firewall rules (and other settings) managed from ovirt-engine we are a long way away from that. Adding rules rather than overwriting iptables config would allow us not to stomp on the user's existing settings.
This sounds like you want precise feature set of firewalld, just faster. David
There should be no setting at slave that master is not aware of.
This also enables you to duplicate hipervisor, recover configuration or push mass configuration change.
In your above case, this rule for monitoring agent may be added at master repository and pushed to slaves belongs to specific group, just like the gluster case.
yes, but in the 24 months between now and when we get to implement that feature ......
The template mechanism is what enable you to create a custom configuration per environment.
Using push and not re-integrate derives much simpler and deterministic implementation.
But maybe I did not understand some of the fundamental concepts of the architecture.
Regards, Alon.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
participants (7)
-
Alon Bar-Lev -
Andrew Cathrow -
David Jaša -
Doron Fediuck -
Itamar Heim -
Selvasundaram -
Shireesh Anjal