6:41 a.m.
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--
8:30 a.m.
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--
1:35 p.m.
----- Original Message -----
From: "Selvasundaram" <sesubram(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
Sent: Thursday, August 30, 2012 4:30:16 PM
Subject: [Engine-devel] Gluster IPTable configuration
Hi,
I want to add gluster specific IPTable configuration in addition to
the ovirt IPTable configuration (if it is gluster node).
There are two approaches,
1. Having one more gluster specific IP table config in db and merge
with ovirt IPTable config (merging NOT appending)
[I have the patch engine: Gluster specific firewall configurations
#7244]
2. Having two different IP Table config (ovirt and ovirt+gluster) and
use either one.
Please provide your suggestions or improvements on this.
Hello all,
The mentioned patch[1], adds hard coded gluster code into the bootstrap code, manipulate
the firewall configuration to be gluster specific. It hardcoded search for
"reject", insert before some other rules.
I believe this hardcode approach is obsolete now that we have proper tools for templates.
A more robust solution would be defining generic profiles, each profile as a template,
each template can refer to different profiles, and assign profile to a node.
This way the implementation is not gluster [or any] specific and can be reused for more
setups, code is cleaner.
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/
1:37 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Selvasundaram" <sesubram(a)redhat.com>
Cc: "Shireesh Anjal" <sanjal(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, August 30, 2012 2:35:16 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Selvasundaram" <sesubram(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> Sent: Thursday, August 30, 2012 4:30:16 PM
> Subject: [Engine-devel] Gluster IPTable configuration
>
>
> Hi,
>
> I want to add gluster specific IPTable configuration in addition to
> the ovirt IPTable configuration (if it is gluster node).
>
> There are two approaches,
> 1. Having one more gluster specific IP table config in db and merge
> with ovirt IPTable config (merging NOT appending)
> [I have the patch engine: Gluster specific firewall configurations
> #7244]
> 2. Having two different IP Table config (ovirt and ovirt+gluster)
> and
> use either one.
>
> Please provide your suggestions or improvements on this.
>
Hello all,
The mentioned patch[1], adds hard coded gluster code into the
bootstrap code, manipulate the firewall configuration to be gluster
specific. It hardcoded search for "reject", insert before some other
rules.
I believe this hardcode approach is obsolete now that we have proper
tools for templates.
A more robust solution would be defining generic profiles, each
profile as a template, each template can refer to different
profiles, and assign profile to a node.
This way the implementation is not gluster [or any] specific and can
be reused for more setups, code is cleaner.
or create custom chains ?
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:40 p.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Shireesh Anjal" <sanjal(a)redhat.com>, engine-devel(a)ovirt.org,
"Selvasundaram" <sesubram(a)redhat.com>
Sent: Thursday, August 30, 2012 9:37:59 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Selvasundaram" <sesubram(a)redhat.com>
> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Thursday, August 30, 2012 2:35:16 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
> > From: "Selvasundaram" <sesubram(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> > Sent: Thursday, August 30, 2012 4:30:16 PM
> > Subject: [Engine-devel] Gluster IPTable configuration
> >
> >
> > Hi,
> >
> > I want to add gluster specific IPTable configuration in addition
> > to
> > the ovirt IPTable configuration (if it is gluster node).
> >
> > There are two approaches,
> > 1. Having one more gluster specific IP table config in db and
> > merge
> > with ovirt IPTable config (merging NOT appending)
> > [I have the patch engine: Gluster specific firewall
> > configurations
> > #7244]
> > 2. Having two different IP Table config (ovirt and ovirt+gluster)
> > and
> > use either one.
> >
> > Please provide your suggestions or improvements on this.
> >
>
> Hello all,
>
> The mentioned patch[1], adds hard coded gluster code into the
> bootstrap code, manipulate the firewall configuration to be gluster
> specific. It hardcoded search for "reject", insert before some
> other
> rules.
>
> I believe this hardcode approach is obsolete now that we have
> proper
> tools for templates.
>
> A more robust solution would be defining generic profiles, each
> profile as a template, each template can refer to different
> profiles, and assign profile to a node.
>
> This way the implementation is not gluster [or any] specific and
> can
> be reused for more setups, code is cleaner.
or create custom chains ?
Can you please elaborate what is custom chains?
Thanks!
>
> 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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
3:57 a.m.
Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>, engine-devel(a)ovirt.org,
"Selvasundaram" <sesubram(a)redhat.com>
> Sent: Thursday, August 30, 2012 9:37:59 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > To: "Selvasundaram" <sesubram(a)redhat.com>
> > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
engine-devel(a)ovirt.org
> > Sent: Thursday, August 30, 2012 2:35:16 PM
> > Subject: Re: [Engine-devel] Gluster IPTable configuration
> >
> >
> >
> > ----- Original Message -----
> > > From: "Selvasundaram" <sesubram(a)redhat.com>
> > > To: engine-devel(a)ovirt.org
> > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > Sent: Thursday, August 30, 2012 4:30:16 PM
> > > Subject: [Engine-devel] Gluster IPTable configuration
> > >
> > >
> > > Hi,
> > >
> > > I want to add gluster specific IPTable configuration in addition
> > > to
> > > the ovirt IPTable configuration (if it is gluster node).
> > >
> > > There are two approaches,
> > > 1. Having one more gluster specific IP table config in db and
> > > merge
> > > with ovirt IPTable config (merging NOT appending)
> > > [I have the patch engine: Gluster specific firewall
> > > configurations
> > > #7244]
> > > 2. Having two different IP Table config (ovirt and ovirt+gluster)
> > > and
> > > use either one.
> > >
> > > Please provide your suggestions or improvements on this.
> > >
> >
> > Hello all,
> >
> > The mentioned patch[1], adds hard coded gluster code into the
> > bootstrap code, manipulate the firewall configuration to be gluster
> > specific. It hardcoded search for "reject", insert before some
> > other
> > rules.
> >
> > I believe this hardcode approach is obsolete now that we have
> > proper
> > tools for templates.
> >
> > A more robust solution would be defining generic profiles, each
> > profile as a template, each template can refer to different
> > profiles, and assign profile to a node.
> >
> > This way the implementation is not gluster [or any] specific and
> > can
> > be reused for more setups, code is cleaner.
>
>
> or create custom chains ?
Can you please elaborate what is custom chains?
Thanks!
iptables -N my_new_chain
iptables -A my_new_chain <rule_1>
iptables -A my_new_chain ...
iptables -A my_new_chain <rule_n>
# if this <rule> is matched, packet goes through rules in my_new_chain
iptables -A INPUT <rule> -j my_new_chain
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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
4:09 a.m.
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Friday, August 31, 2012 11:57:11 AM
Subject: Re: [Engine-devel] Gluster IPTable configuration
Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
>
> ----- Original Message -----
> > From: "Andrew Cathrow" <acathrow(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
engine-devel(a)ovirt.org,
> > "Selvasundaram" <sesubram(a)redhat.com>
> > Sent: Thursday, August 30, 2012 9:37:59 PM
> > Subject: Re: [Engine-devel] Gluster IPTable configuration
> >
> >
> >
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > To: "Selvasundaram" <sesubram(a)redhat.com>
> > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
> > > engine-devel(a)ovirt.org
> > > Sent: Thursday, August 30, 2012 2:35:16 PM
> > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Selvasundaram" <sesubram(a)redhat.com>
> > > > To: engine-devel(a)ovirt.org
> > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > > Sent: Thursday, August 30, 2012 4:30:16 PM
> > > > Subject: [Engine-devel] Gluster IPTable configuration
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I want to add gluster specific IPTable configuration in
> > > > addition
> > > > to
> > > > the ovirt IPTable configuration (if it is gluster node).
> > > >
> > > > There are two approaches,
> > > > 1. Having one more gluster specific IP table config in db and
> > > > merge
> > > > with ovirt IPTable config (merging NOT appending)
> > > > [I have the patch engine: Gluster specific firewall
> > > > configurations
> > > > #7244]
> > > > 2. Having two different IP Table config (ovirt and
> > > > ovirt+gluster)
> > > > and
> > > > use either one.
> > > >
> > > > Please provide your suggestions or improvements on this.
> > > >
> > >
> > > Hello all,
> > >
> > > The mentioned patch[1], adds hard coded gluster code into the
> > > bootstrap code, manipulate the firewall configuration to be
> > > gluster
> > > specific. It hardcoded search for "reject", insert before some
> > > other
> > > rules.
> > >
> > > I believe this hardcode approach is obsolete now that we have
> > > proper
> > > tools for templates.
> > >
> > > A more robust solution would be defining generic profiles, each
> > > profile as a template, each template can refer to different
> > > profiles, and assign profile to a node.
> > >
> > > This way the implementation is not gluster [or any] specific
> > > and
> > > can
> > > be reused for more setups, code is cleaner.
> >
> >
> > or create custom chains ?
>
> Can you please elaborate what is custom chains?
> Thanks!
iptables -N my_new_chain
iptables -A my_new_chain <rule_1>
iptables -A my_new_chain ...
iptables -A my_new_chain <rule_n>
# if this <rule> is matched, packet goes through rules in
my_new_chain
iptables -A INPUT <rule> -j my_new_chain
Hello,
How does this solve the original issue?
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.
7:12 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "David Jaša" <djasa(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Friday, August 31, 2012 5:09:47 AM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "David Jaša" <djasa(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Friday, August 31, 2012 11:57:11 AM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
> Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
> >
> > ----- Original Message -----
> > > From: "Andrew Cathrow" <acathrow(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
> > > engine-devel(a)ovirt.org,
> > > "Selvasundaram" <sesubram(a)redhat.com>
> > > Sent: Thursday, August 30, 2012 9:37:59 PM
> > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > To: "Selvasundaram" <sesubram(a)redhat.com>
> > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
> > > > engine-devel(a)ovirt.org
> > > > Sent: Thursday, August 30, 2012 2:35:16 PM
> > > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Selvasundaram" <sesubram(a)redhat.com>
> > > > > To: engine-devel(a)ovirt.org
> > > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > > > Sent: Thursday, August 30, 2012 4:30:16 PM
> > > > > Subject: [Engine-devel] Gluster IPTable configuration
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I want to add gluster specific IPTable configuration in
> > > > > addition
> > > > > to
> > > > > the ovirt IPTable configuration (if it is gluster node).
> > > > >
> > > > > There are two approaches,
> > > > > 1. Having one more gluster specific IP table config in db
> > > > > and
> > > > > merge
> > > > > with ovirt IPTable config (merging NOT appending)
> > > > > [I have the patch engine: Gluster specific firewall
> > > > > configurations
> > > > > #7244]
> > > > > 2. Having two different IP Table config (ovirt and
> > > > > ovirt+gluster)
> > > > > and
> > > > > use either one.
> > > > >
> > > > > Please provide your suggestions or improvements on this.
> > > > >
> > > >
> > > > Hello all,
> > > >
> > > > The mentioned patch[1], adds hard coded gluster code into the
> > > > bootstrap code, manipulate the firewall configuration to be
> > > > gluster
> > > > specific. It hardcoded search for "reject", insert before
> > > > some
> > > > other
> > > > rules.
> > > >
> > > > I believe this hardcode approach is obsolete now that we have
> > > > proper
> > > > tools for templates.
> > > >
> > > > A more robust solution would be defining generic profiles,
> > > > each
> > > > profile as a template, each template can refer to different
> > > > profiles, and assign profile to a node.
> > > >
> > > > This way the implementation is not gluster [or any] specific
> > > > and
> > > > can
> > > > be reused for more setups, code is cleaner.
> > >
> > >
> > > or create custom chains ?
> >
> > Can you please elaborate what is custom chains?
> > Thanks!
>
> iptables -N my_new_chain
> iptables -A my_new_chain <rule_1>
> iptables -A my_new_chain ...
> iptables -A my_new_chain <rule_n>
>
> # if this <rule> is matched, packet goes through rules in
> my_new_chain
> iptables -A INPUT <rule> -j my_new_chain
>
Hello,
How does this solve the original issue?
It makes it easier for customers who are adding their own IPTables configuration - when we
do rhev-h plugins it'll make things easier.
This way we don't wipe out the original rules we just add our own chain.
The need to provide different rules to different hosts by software
installed on destination?
Standard host needs iptables X.
Gluster host needs iptables X+Y.
XXX host needs iptables X+Z.
Maintainer of Gluster knows what Y is.
Maintainer of XXX knows what Z is.
If we merge all to one entry product comes with default X.
User override X to A.
New version of product comes with default Y.
Upgrade options:
1. System continues to use A.
2. Some AI to upgrade and create A'.
3. Revert to Y, dropping user's customization.
Or we can maintain one large table with complete configuration and
conditionals.
Alon.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:21 a.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Friday, August 31, 2012 3:12:34 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "David Jaša" <djasa(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Friday, August 31, 2012 5:09:47 AM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
> > From: "David Jaša" <djasa(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Sent: Friday, August 31, 2012 11:57:11 AM
> > Subject: Re: [Engine-devel] Gluster IPTable configuration
> >
> > Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
> > >
> > > ----- Original Message -----
> > > > From: "Andrew Cathrow" <acathrow(a)redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
> > > > engine-devel(a)ovirt.org,
> > > > "Selvasundaram" <sesubram(a)redhat.com>
> > > > Sent: Thursday, August 30, 2012 9:37:59 PM
> > > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > > To: "Selvasundaram" <sesubram(a)redhat.com>
> > > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
> > > > > engine-devel(a)ovirt.org
> > > > > Sent: Thursday, August 30, 2012 2:35:16 PM
> > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Selvasundaram"
<sesubram(a)redhat.com>
> > > > > > To: engine-devel(a)ovirt.org
> > > > > > Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > > > > Sent: Thursday, August 30, 2012 4:30:16 PM
> > > > > > Subject: [Engine-devel] Gluster IPTable configuration
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I want to add gluster specific IPTable configuration in
> > > > > > addition
> > > > > > to
> > > > > > the ovirt IPTable configuration (if it is gluster node).
> > > > > >
> > > > > > There are two approaches,
> > > > > > 1. Having one more gluster specific IP table config in db
> > > > > > and
> > > > > > merge
> > > > > > with ovirt IPTable config (merging NOT appending)
> > > > > > [I have the patch engine: Gluster specific firewall
> > > > > > configurations
> > > > > > #7244]
> > > > > > 2. Having two different IP Table config (ovirt and
> > > > > > ovirt+gluster)
> > > > > > and
> > > > > > use either one.
> > > > > >
> > > > > > Please provide your suggestions or improvements on this.
> > > > > >
> > > > >
> > > > > Hello all,
> > > > >
> > > > > The mentioned patch[1], adds hard coded gluster code into
> > > > > the
> > > > > bootstrap code, manipulate the firewall configuration to be
> > > > > gluster
> > > > > specific. It hardcoded search for "reject", insert
before
> > > > > some
> > > > > other
> > > > > rules.
> > > > >
> > > > > I believe this hardcode approach is obsolete now that we
> > > > > have
> > > > > proper
> > > > > tools for templates.
> > > > >
> > > > > A more robust solution would be defining generic profiles,
> > > > > each
> > > > > profile as a template, each template can refer to different
> > > > > profiles, and assign profile to a node.
> > > > >
> > > > > This way the implementation is not gluster [or any]
> > > > > specific
> > > > > and
> > > > > can
> > > > > be reused for more setups, code is cleaner.
> > > >
> > > >
> > > > or create custom chains ?
> > >
> > > Can you please elaborate what is custom chains?
> > > Thanks!
> >
> > iptables -N my_new_chain
> > iptables -A my_new_chain <rule_1>
> > iptables -A my_new_chain ...
> > iptables -A my_new_chain <rule_n>
> >
> > # if this <rule> is matched, packet goes through rules in
> > my_new_chain
> > iptables -A INPUT <rule> -j my_new_chain
> >
>
> Hello,
>
> How does this solve the original issue?
It makes it easier for customers who are adding their own IPTables
configuration - when we do rhev-h plugins it'll make things easier.
This way we don't wipe out the original rules we just add our own
chain.
Current default (virt) iptables configuration is kept in the engine's DB.
So...
1. We can update the DB value to include Gluster configuration.
or
2. Have an additional DB value for virt+Gluster.
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.
3:51 p.m.
On 09/02/2012 05:21 PM, Doron Fediuck wrote:
----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Friday, August 31, 2012 3:12:34 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> To: "David Jaša" <djasa(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Friday, August 31, 2012 5:09:47 AM
>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>
>>
>>
>> ----- Original Message -----
>>> From: "David Jaša" <djasa(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Friday, August 31, 2012 11:57:11 AM
>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>
>>> Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Andrew Cathrow" <acathrow(a)redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
>>>>> engine-devel(a)ovirt.org,
>>>>> "Selvasundaram" <sesubram(a)redhat.com>
>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM
>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>> To: "Selvasundaram" <sesubram(a)redhat.com>
>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
>>>>>> engine-devel(a)ovirt.org
>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM
>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Selvasundaram" <sesubram(a)redhat.com>
>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to add gluster specific IPTable configuration in
>>>>>>> addition
>>>>>>> to
>>>>>>> the ovirt IPTable configuration (if it is gluster node).
>>>>>>>
>>>>>>> There are two approaches,
>>>>>>> 1. Having one more gluster specific IP table config in db
>>>>>>> and
>>>>>>> merge
>>>>>>> with ovirt IPTable config (merging NOT appending)
>>>>>>> [I have the patch engine: Gluster specific firewall
>>>>>>> configurations
>>>>>>> #7244]
>>>>>>> 2. Having two different IP Table config (ovirt and
>>>>>>> ovirt+gluster)
>>>>>>> and
>>>>>>> use either one.
>>>>>>>
>>>>>>> Please provide your suggestions or improvements on this.
>>>>>>>
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> The mentioned patch[1], adds hard coded gluster code into
>>>>>> the
>>>>>> bootstrap code, manipulate the firewall configuration to be
>>>>>> gluster
>>>>>> specific. It hardcoded search for "reject", insert
before
>>>>>> some
>>>>>> other
>>>>>> rules.
>>>>>>
>>>>>> I believe this hardcode approach is obsolete now that we
>>>>>> have
>>>>>> proper
>>>>>> tools for templates.
>>>>>>
>>>>>> A more robust solution would be defining generic profiles,
>>>>>> each
>>>>>> profile as a template, each template can refer to different
>>>>>> profiles, and assign profile to a node.
>>>>>>
>>>>>> This way the implementation is not gluster [or any]
>>>>>> specific
>>>>>> and
>>>>>> can
>>>>>> be reused for more setups, code is cleaner.
>>>>>
>>>>>
>>>>> or create custom chains ?
>>>>
>>>> Can you please elaborate what is custom chains?
>>>> Thanks!
>>>
>>> iptables -N my_new_chain
>>> iptables -A my_new_chain <rule_1>
>>> iptables -A my_new_chain ...
>>> iptables -A my_new_chain <rule_n>
>>>
>>> # if this <rule> is matched, packet goes through rules in
>>> my_new_chain
>>> iptables -A INPUT <rule> -j my_new_chain
>>>
>>
>> Hello,
>>
>> How does this solve the original issue?
>
> It makes it easier for customers who are adding their own IPTables
> configuration - when we do rhev-h plugins it'll make things easier.
> This way we don't wipe out the original rules we just add our own
> chain.
>
>
Current default (virt) iptables configuration is kept in the engine's DB.
So...
1. We can update the DB value to include Gluster configuration.
or
2. Have an additional DB value for virt+Gluster.
3. gluster only, not virt.
So (1) will work, but when gluster is not relevant we have redundant ports.
But my only reservation from (2) is that it's not scalable for additional
services.
Either way, I agree with Alon that melding the configurations at runtime
is unexpected, and shouldn't be used.
After some additional thought... we can have (1), and make all gluster
entries commented out (let's say with #GLSTR) by default, so it'll be
enabled only when gluster is being used. This will allow introducing future
configurations as well without the need for additional DB values.
why not use the chains approach, and have a chain per service?
Sample snip of DB value:
==================================================================================
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
# vdsm
-A INPUT -p tcp --dport 54321 -j ACCEPT
# libvirt tls
-A INPUT -p tcp --dport 16514 -j ACCEPT
# SSH
-A INPUT -p tcp --dport 22 -j ACCEPT
# guest consoles
-A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT
# gluster p1
#GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT
# gluster p2-p6
#GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT
# Reject any other input traffic
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m physdev ! --physdev-is-bridged -j REJECT --reject-with
icmp-host-prohibited
COMMIT
==================================================================================
So as you can see, this is something we can handle in run-time. Also it's easy
to test, so predictable, and finally- human beings can look and understand what
it means.
>> The need to provide different rules to different hosts by software
>> installed on destination?
>>
>> Standard host needs iptables X.
>> Gluster host needs iptables X+Y.
>> XXX host needs iptables X+Z.
>> Maintainer of Gluster knows what Y is.
>> Maintainer of XXX knows what Z is.
>>
>> If we merge all to one entry product comes with default X.
>> User override X to A.
>> New version of product comes with default Y.
>> Upgrade options:
>> 1. System continues to use A.
>> 2. Some AI to upgrade and create A'.
>> 3. Revert to Y, dropping user's customization.
>>
>> Or we can maintain one large table with complete configuration and
>> conditionals.
>>
>> Alon.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:09 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Doron Fediuck" <dfediuck(a)redhat.com>
Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Sunday, September 2, 2012 11:51:40 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
On 09/02/2012 05:21 PM, Doron Fediuck wrote:
> ----- Original Message -----
>> From: "Andrew Cathrow" <acathrow(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)ovirt.org
>> Sent: Friday, August 31, 2012 3:12:34 PM
>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> To: "David Jaša" <djasa(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org
>>> Sent: Friday, August 31, 2012 5:09:47 AM
>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "David Jaša" <djasa(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Friday, August 31, 2012 11:57:11 AM
>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>>
>>>> Alon Bar-Lev píše v Čt 30. 08. 2012 v 14:40 -0400:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Andrew Cathrow" <acathrow(a)redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
>>>>>> engine-devel(a)ovirt.org,
>>>>>> "Selvasundaram" <sesubram(a)redhat.com>
>>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM
>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>>> To: "Selvasundaram" <sesubram(a)redhat.com>
>>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>,
>>>>>>> engine-devel(a)ovirt.org
>>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM
>>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Selvasundaram"
<sesubram(a)redhat.com>
>>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>>> Cc: "Shireesh Anjal"
<sanjal(a)redhat.com>
>>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I want to add gluster specific IPTable configuration in
>>>>>>>> addition
>>>>>>>> to
>>>>>>>> the ovirt IPTable configuration (if it is gluster
node).
>>>>>>>>
>>>>>>>> There are two approaches,
>>>>>>>> 1. Having one more gluster specific IP table config in
db
>>>>>>>> and
>>>>>>>> merge
>>>>>>>> with ovirt IPTable config (merging NOT appending)
>>>>>>>> [I have the patch engine: Gluster specific firewall
>>>>>>>> configurations
>>>>>>>> #7244]
>>>>>>>> 2. Having two different IP Table config (ovirt and
>>>>>>>> ovirt+gluster)
>>>>>>>> and
>>>>>>>> use either one.
>>>>>>>>
>>>>>>>> Please provide your suggestions or improvements on
this.
>>>>>>>>
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> The mentioned patch[1], adds hard coded gluster code into
>>>>>>> the
>>>>>>> bootstrap code, manipulate the firewall configuration to be
>>>>>>> gluster
>>>>>>> specific. It hardcoded search for "reject", insert
before
>>>>>>> some
>>>>>>> other
>>>>>>> rules.
>>>>>>>
>>>>>>> I believe this hardcode approach is obsolete now that we
>>>>>>> have
>>>>>>> proper
>>>>>>> tools for templates.
>>>>>>>
>>>>>>> A more robust solution would be defining generic profiles,
>>>>>>> each
>>>>>>> profile as a template, each template can refer to different
>>>>>>> profiles, and assign profile to a node.
>>>>>>>
>>>>>>> This way the implementation is not gluster [or any]
>>>>>>> specific
>>>>>>> and
>>>>>>> can
>>>>>>> be reused for more setups, code is cleaner.
>>>>>>
>>>>>>
>>>>>> or create custom chains ?
>>>>>
>>>>> Can you please elaborate what is custom chains?
>>>>> Thanks!
>>>>
>>>> iptables -N my_new_chain
>>>> iptables -A my_new_chain <rule_1>
>>>> iptables -A my_new_chain ...
>>>> iptables -A my_new_chain <rule_n>
>>>>
>>>> # if this <rule> is matched, packet goes through rules in
>>>> my_new_chain
>>>> iptables -A INPUT <rule> -j my_new_chain
>>>>
>>>
>>> Hello,
>>>
>>> How does this solve the original issue?
>>
>> It makes it easier for customers who are adding their own IPTables
>> configuration - when we do rhev-h plugins it'll make things
>> easier.
>> This way we don't wipe out the original rules we just add our own
>> chain.
>>
>>
>
> Current default (virt) iptables configuration is kept in the
> engine's DB.
> So...
>
> 1. We can update the DB value to include Gluster configuration.
> or
> 2. Have an additional DB value for virt+Gluster.
3. gluster only, not virt.
>
> So (1) will work, but when gluster is not relevant we have
> redundant ports.
> But my only reservation from (2) is that it's not scalable for
> additional
> services.
>
> Either way, I agree with Alon that melding the configurations at
> runtime
> is unexpected, and shouldn't be used.
>
> After some additional thought... we can have (1), and make all
> gluster
> entries commented out (let's say with #GLSTR) by default, so it'll
> be
> enabled only when gluster is being used. This will allow
> introducing future
> configurations as well without the need for additional DB values.
why not use the chains approach, and have a chain per service?
Since you wish to avoid collisions.
So for gluster only, have a VIRT prefix as well.
>
> Sample snip of DB value:
> ==================================================================================
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> # vdsm
> -A INPUT -p tcp --dport 54321 -j ACCEPT
> # libvirt tls
> -A INPUT -p tcp --dport 16514 -j ACCEPT
> # SSH
> -A INPUT -p tcp --dport 22 -j ACCEPT
> # guest consoles
> -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT
> # gluster p1
> #GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT
> # gluster p2-p6
> #GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT
> # Reject any other input traffic
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT
> --reject-with icmp-host-prohibited
> COMMIT
> ==================================================================================
>
> So as you can see, this is something we can handle in run-time.
> Also it's easy
> to test, so predictable, and finally- human beings can look and
> understand what
> it means.
>
>
>>> The need to provide different rules to different hosts by
>>> software
>>> installed on destination?
>>>
>>> Standard host needs iptables X.
>>> Gluster host needs iptables X+Y.
>>> XXX host needs iptables X+Z.
>>> Maintainer of Gluster knows what Y is.
>>> Maintainer of XXX knows what Z is.
>>>
>>> If we merge all to one entry product comes with default X.
>>> User override X to A.
>>> New version of product comes with default Y.
>>> Upgrade options:
>>> 1. System continues to use A.
>>> 2. Some AI to upgrade and create A'.
>>> 3. Revert to Y, dropping user's customization.
>>>
>>> Or we can maintain one large table with complete configuration
>>> and
>>> conditionals.
>>>
>>> Alon.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:51 a.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)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.
6:42 a.m.
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(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "David Jaša" <djasa(a)redhat.com>, engine-devel(a)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(a)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
7:42 a.m.
On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Selvasundaram" <sesubram(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> Sent: Thursday, August 30, 2012 4:30:16 PM
> Subject: [Engine-devel] Gluster IPTable configuration
>
>
> Hi,
>
> I want to add gluster specific IPTable configuration in addition to
> the ovirt IPTable configuration (if it is gluster node).
>
> There are two approaches,
> 1. Having one more gluster specific IP table config in db and merge
> with ovirt IPTable config (merging NOT appending)
> [I have the patch engine: Gluster specific firewall configurations
> #7244]
> 2. Having two different IP Table config (ovirt and ovirt+gluster) and
> use either one.
>
> Please provide your suggestions or improvements on this.
>
Hello all,
The mentioned patch[1], adds hard coded gluster code into the bootstrap code, manipulate
the firewall configuration to be gluster specific. It hardcoded search for
"reject", insert before some other rules.
I believe this hardcode approach is obsolete now that we have proper tools for
templates.
A more robust solution would be defining generic profiles, each profile as a template,
each template can refer to different profiles, and assign profile to a node.
This way the implementation is not gluster [or any] specific and can be reused for more
setups, code is cleaner.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:52 a.m.
----- Original Message -----
From: "Shireesh Anjal" <sanjal(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Selvasundaram"
<sesubram(a)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(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>> Sent: Thursday, August 30, 2012 4:30:16 PM
>> Subject: [Engine-devel] Gluster IPTable configuration
>>
>>
>> Hi,
>>
>> I want to add gluster specific IPTable configuration in addition
>> to
>> the ovirt IPTable configuration (if it is gluster node).
>>
>> There are two approaches,
>> 1. Having one more gluster specific IP table config in db and
>> merge
>> with ovirt IPTable config (merging NOT appending)
>> [I have the patch engine: Gluster specific firewall configurations
>> #7244]
>> 2. Having two different IP Table config (ovirt and ovirt+gluster)
>> and
>> use either one.
>>
>> Please provide your suggestions or improvements on this.
>>
> Hello all,
>
> The mentioned patch[1], adds hard coded gluster code into the
> bootstrap code, manipulate the firewall configuration to be
> gluster specific. It hardcoded search for "reject", insert before
> some other rules.
>
> I believe this hardcode approach is obsolete now that we have
> proper tools for templates.
>
> A more robust solution would be defining generic profiles, each
> profile as a template, each template can refer to different
> profiles, and assign profile to a node.
>
> This way the implementation is not gluster [or any] specific and
> can be reused for more setups, code is cleaner.
>
> 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.
8 a.m.
On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Selvasundaram"
<sesubram(a)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(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>
>>>
>>> Hi,
>>>
>>> I want to add gluster specific IPTable configuration in addition
>>> to
>>> the ovirt IPTable configuration (if it is gluster node).
>>>
>>> There are two approaches,
>>> 1. Having one more gluster specific IP table config in db and
>>> merge
>>> with ovirt IPTable config (merging NOT appending)
>>> [I have the patch engine: Gluster specific firewall configurations
>>> #7244]
>>> 2. Having two different IP Table config (ovirt and ovirt+gluster)
>>> and
>>> use either one.
>>>
>>> Please provide your suggestions or improvements on this.
>>>
>> Hello all,
>>
>> The mentioned patch[1], adds hard coded gluster code into the
>> bootstrap code, manipulate the firewall configuration to be
>> gluster specific. It hardcoded search for "reject", insert before
>> some other rules.
>>
>> I believe this hardcode approach is obsolete now that we have
>> proper tools for templates.
>>
>> A more robust solution would be defining generic profiles, each
>> profile as a template, each template can refer to different
>> profiles, and assign profile to a node.
>>
>> This way the implementation is not gluster [or any] specific and
>> can be reused for more setups, code is cleaner.
>>
>> 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.
8:11 a.m.
----- Original Message -----
From: "Shireesh Anjal" <sanjal(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Selvasundaram" <sesubram(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Monday, September 3, 2012 4:00:14 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
>> <sesubram(a)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(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I want to add gluster specific IPTable configuration in addition
>>>> to
>>>> the ovirt IPTable configuration (if it is gluster node).
>>>>
>>>> There are two approaches,
>>>> 1. Having one more gluster specific IP table config in db and
>>>> merge
>>>> with ovirt IPTable config (merging NOT appending)
>>>> [I have the patch engine: Gluster specific firewall
>>>> configurations
>>>> #7244]
>>>> 2. Having two different IP Table config (ovirt and
>>>> ovirt+gluster)
>>>> and
>>>> use either one.
>>>>
>>>> Please provide your suggestions or improvements on this.
>>>>
>>> Hello all,
>>>
>>> The mentioned patch[1], adds hard coded gluster code into the
>>> bootstrap code, manipulate the firewall configuration to be
>>> gluster specific. It hardcoded search for "reject", insert before
>>> some other rules.
>>>
>>> I believe this hardcode approach is obsolete now that we have
>>> proper tools for templates.
>>>
>>> A more robust solution would be defining generic profiles, each
>>> profile as a template, each template can refer to different
>>> profiles, and assign profile to a node.
>>>
>>> This way the implementation is not gluster [or any] specific and
>>> can be reused for more setups, code is cleaner.
>>>
>>> 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.
8:21 a.m.
On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Selvasundaram" <sesubram(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Monday, September 3, 2012 4:00:14 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
>> ----- Original Message -----
>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
>>> <sesubram(a)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(a)redhat.com>
>>>>> To: engine-devel(a)ovirt.org
>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I want to add gluster specific IPTable configuration in addition
>>>>> to
>>>>> the ovirt IPTable configuration (if it is gluster node).
>>>>>
>>>>> There are two approaches,
>>>>> 1. Having one more gluster specific IP table config in db and
>>>>> merge
>>>>> with ovirt IPTable config (merging NOT appending)
>>>>> [I have the patch engine: Gluster specific firewall
>>>>> configurations
>>>>> #7244]
>>>>> 2. Having two different IP Table config (ovirt and
>>>>> ovirt+gluster)
>>>>> and
>>>>> use either one.
>>>>>
>>>>> Please provide your suggestions or improvements on this.
>>>>>
>>>> Hello all,
>>>>
>>>> The mentioned patch[1], adds hard coded gluster code into the
>>>> bootstrap code, manipulate the firewall configuration to be
>>>> gluster specific. It hardcoded search for "reject", insert
before
>>>> some other rules.
>>>>
>>>> I believe this hardcode approach is obsolete now that we have
>>>> proper tools for templates.
>>>>
>>>> A more robust solution would be defining generic profiles, each
>>>> profile as a template, each template can refer to different
>>>> profiles, and assign profile to a node.
>>>>
>>>> This way the implementation is not gluster [or any] specific and
>>>> can be reused for more setups, code is cleaner.
>>>>
>>>> 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.
8:50 a.m.
----- Original Message -----
From: "Shireesh Anjal" <sanjal(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Selvasundaram" <sesubram(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Monday, September 3, 2012 4:21:58 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> Cc: "Selvasundaram" <sesubram(a)redhat.com>,
engine-devel(a)ovirt.org
>> Sent: Monday, September 3, 2012 4:00:14 PM
>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>
>> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
>>> ----- Original Message -----
>>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
>>>> <sesubram(a)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(a)redhat.com>
>>>>>> To: engine-devel(a)ovirt.org
>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I want to add gluster specific IPTable configuration in
>>>>>> addition
>>>>>> to
>>>>>> the ovirt IPTable configuration (if it is gluster node).
>>>>>>
>>>>>> There are two approaches,
>>>>>> 1. Having one more gluster specific IP table config in db and
>>>>>> merge
>>>>>> with ovirt IPTable config (merging NOT appending)
>>>>>> [I have the patch engine: Gluster specific firewall
>>>>>> configurations
>>>>>> #7244]
>>>>>> 2. Having two different IP Table config (ovirt and
>>>>>> ovirt+gluster)
>>>>>> and
>>>>>> use either one.
>>>>>>
>>>>>> Please provide your suggestions or improvements on this.
>>>>>>
>>>>> Hello all,
>>>>>
>>>>> The mentioned patch[1], adds hard coded gluster code into the
>>>>> bootstrap code, manipulate the firewall configuration to be
>>>>> gluster specific. It hardcoded search for "reject",
insert
>>>>> before
>>>>> some other rules.
>>>>>
>>>>> I believe this hardcode approach is obsolete now that we have
>>>>> proper tools for templates.
>>>>>
>>>>> A more robust solution would be defining generic profiles, each
>>>>> profile as a template, each template can refer to different
>>>>> profiles, and assign profile to a node.
>>>>>
>>>>> This way the implementation is not gluster [or any] specific
>>>>> and
>>>>> can be reused for more setups, code is cleaner.
>>>>>
>>>>> 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
9:34 a.m.
On Monday 03 September 2012 07:20 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Selvasundaram" <sesubram(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Monday, September 3, 2012 4:21:58 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
> On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
>> ----- Original Message -----
>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> Cc: "Selvasundaram" <sesubram(a)redhat.com>,
engine-devel(a)ovirt.org
>>> Sent: Monday, September 3, 2012 4:00:14 PM
>>> Subject: Re: [Engine-devel] Gluster IPTable configuration
>>>
>>> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
>>>> ----- Original Message -----
>>>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>>> To: engine-devel(a)ovirt.org
>>>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
>>>>> <sesubram(a)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(a)redhat.com>
>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to add gluster specific IPTable configuration in
>>>>>>> addition
>>>>>>> to
>>>>>>> the ovirt IPTable configuration (if it is gluster node).
>>>>>>>
>>>>>>> There are two approaches,
>>>>>>> 1. Having one more gluster specific IP table config in db
and
>>>>>>> merge
>>>>>>> with ovirt IPTable config (merging NOT appending)
>>>>>>> [I have the patch engine: Gluster specific firewall
>>>>>>> configurations
>>>>>>> #7244]
>>>>>>> 2. Having two different IP Table config (ovirt and
>>>>>>> ovirt+gluster)
>>>>>>> and
>>>>>>> use either one.
>>>>>>>
>>>>>>> Please provide your suggestions or improvements on this.
>>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> The mentioned patch[1], adds hard coded gluster code into the
>>>>>> bootstrap code, manipulate the firewall configuration to be
>>>>>> gluster specific. It hardcoded search for "reject",
insert
>>>>>> before
>>>>>> some other rules.
>>>>>>
>>>>>> I believe this hardcode approach is obsolete now that we have
>>>>>> proper tools for templates.
>>>>>>
>>>>>> A more robust solution would be defining generic profiles, each
>>>>>> profile as a template, each template can refer to different
>>>>>> profiles, and assign profile to a node.
>>>>>>
>>>>>> This way the implementation is not gluster [or any] specific
>>>>>> and
>>>>>> can be reused for more setups, code is cleaner.
>>>>>>
>>>>>> 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:05 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Shireesh Anjal" <sanjal(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, September 3, 2012 9:50:52 AM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Selvasundaram" <sesubram(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Monday, September 3, 2012 4:21:58 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
> On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> >> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> >> Cc: "Selvasundaram" <sesubram(a)redhat.com>,
> >> engine-devel(a)ovirt.org
> >> Sent: Monday, September 3, 2012 4:00:14 PM
> >> Subject: Re: [Engine-devel] Gluster IPTable configuration
> >>
> >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
> >>> ----- Original Message -----
> >>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> >>>> To: engine-devel(a)ovirt.org
> >>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
> >>>> <sesubram(a)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(a)redhat.com>
> >>>>>> To: engine-devel(a)ovirt.org
> >>>>>> Cc: "Shireesh Anjal" <sanjal(a)redhat.com>
> >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
> >>>>>> Subject: [Engine-devel] Gluster IPTable configuration
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I want to add gluster specific IPTable configuration in
> >>>>>> addition
> >>>>>> to
> >>>>>> the ovirt IPTable configuration (if it is gluster node).
> >>>>>>
> >>>>>> There are two approaches,
> >>>>>> 1. Having one more gluster specific IP table config in db
> >>>>>> and
> >>>>>> merge
> >>>>>> with ovirt IPTable config (merging NOT appending)
> >>>>>> [I have the patch engine: Gluster specific firewall
> >>>>>> configurations
> >>>>>> #7244]
> >>>>>> 2. Having two different IP Table config (ovirt and
> >>>>>> ovirt+gluster)
> >>>>>> and
> >>>>>> use either one.
> >>>>>>
> >>>>>> Please provide your suggestions or improvements on this.
> >>>>>>
> >>>>> Hello all,
> >>>>>
> >>>>> The mentioned patch[1], adds hard coded gluster code into the
> >>>>> bootstrap code, manipulate the firewall configuration to be
> >>>>> gluster specific. It hardcoded search for "reject",
insert
> >>>>> before
> >>>>> some other rules.
> >>>>>
> >>>>> I believe this hardcode approach is obsolete now that we have
> >>>>> proper tools for templates.
> >>>>>
> >>>>> A more robust solution would be defining generic profiles,
> >>>>> each
> >>>>> profile as a template, each template can refer to different
> >>>>> profiles, and assign profile to a node.
> >>>>>
> >>>>> This way the implementation is not gluster [or any] specific
> >>>>> and
> >>>>> can be reused for more setups, code is cleaner.
> >>>>>
> >>>>> 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:50 p.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)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(a)redhat.com>
> To: "Shireesh Anjal" <sanjal(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, September 3, 2012 9:50:52 AM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
> > From: "Shireesh Anjal" <sanjal(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Selvasundaram" <sesubram(a)redhat.com>,
engine-devel(a)ovirt.org
> > Sent: Monday, September 3, 2012 4:21:58 PM
> > Subject: Re: [Engine-devel] Gluster IPTable configuration
> >
> > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > >> Cc: "Selvasundaram" <sesubram(a)redhat.com>,
> > >> engine-devel(a)ovirt.org
> > >> Sent: Monday, September 3, 2012 4:00:14 PM
> > >> Subject: Re: [Engine-devel] Gluster IPTable configuration
> > >>
> > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> > >>>> To: engine-devel(a)ovirt.org
> > >>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
> > >>>> <sesubram(a)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(a)redhat.com>
> > >>>>>> To: engine-devel(a)ovirt.org
> > >>>>>> Cc: "Shireesh Anjal"
<sanjal(a)redhat.com>
> > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
> > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration
> > >>>>>>
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> I want to add gluster specific IPTable configuration
in
> > >>>>>> addition
> > >>>>>> to
> > >>>>>> the ovirt IPTable configuration (if it is gluster
node).
> > >>>>>>
> > >>>>>> There are two approaches,
> > >>>>>> 1. Having one more gluster specific IP table config in
db
> > >>>>>> and
> > >>>>>> merge
> > >>>>>> with ovirt IPTable config (merging NOT appending)
> > >>>>>> [I have the patch engine: Gluster specific firewall
> > >>>>>> configurations
> > >>>>>> #7244]
> > >>>>>> 2. Having two different IP Table config (ovirt and
> > >>>>>> ovirt+gluster)
> > >>>>>> and
> > >>>>>> use either one.
> > >>>>>>
> > >>>>>> Please provide your suggestions or improvements on
this.
> > >>>>>>
> > >>>>> Hello all,
> > >>>>>
> > >>>>> The mentioned patch[1], adds hard coded gluster code into
> > >>>>> the
> > >>>>> bootstrap code, manipulate the firewall configuration to
be
> > >>>>> gluster specific. It hardcoded search for
"reject", insert
> > >>>>> before
> > >>>>> some other rules.
> > >>>>>
> > >>>>> I believe this hardcode approach is obsolete now that we
> > >>>>> have
> > >>>>> proper tools for templates.
> > >>>>>
> > >>>>> A more robust solution would be defining generic
profiles,
> > >>>>> each
> > >>>>> profile as a template, each template can refer to
different
> > >>>>> profiles, and assign profile to a node.
> > >>>>>
> > >>>>> This way the implementation is not gluster [or any]
> > >>>>> specific
> > >>>>> and
> > >>>>> can be reused for more setups, code is cleaner.
> > >>>>>
> > >>>>> 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/
3:57 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com>
Sent: Monday, September 3, 2012 4:50:00 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)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(a)redhat.com>
> > To: "Shireesh Anjal" <sanjal(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Monday, September 3, 2012 9:50:52 AM
> > Subject: Re: [Engine-devel] Gluster IPTable configuration
> >
> >
> >
> > ----- Original Message -----
> > > From: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: "Selvasundaram" <sesubram(a)redhat.com>,
> > > engine-devel(a)ovirt.org
> > > Sent: Monday, September 3, 2012 4:21:58 PM
> > > Subject: Re: [Engine-devel] Gluster IPTable configuration
> > >
> > > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > >> Cc: "Selvasundaram" <sesubram(a)redhat.com>,
> > > >> engine-devel(a)ovirt.org
> > > >> Sent: Monday, September 3, 2012 4:00:14 PM
> > > >> Subject: Re: [Engine-devel] Gluster IPTable configuration
> > > >>
> > > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Shireesh Anjal"
<sanjal(a)redhat.com>
> > > >>>> To: engine-devel(a)ovirt.org
> > > >>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"Selvasundaram"
> > > >>>> <sesubram(a)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(a)redhat.com>
> > > >>>>>> To: engine-devel(a)ovirt.org
> > > >>>>>> Cc: "Shireesh Anjal"
<sanjal(a)redhat.com>
> > > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM
> > > >>>>>> Subject: [Engine-devel] Gluster IPTable
configuration
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> I want to add gluster specific IPTable
configuration in
> > > >>>>>> addition
> > > >>>>>> to
> > > >>>>>> the ovirt IPTable configuration (if it is gluster
node).
> > > >>>>>>
> > > >>>>>> There are two approaches,
> > > >>>>>> 1. Having one more gluster specific IP table
config in
> > > >>>>>> db
> > > >>>>>> and
> > > >>>>>> merge
> > > >>>>>> with ovirt IPTable config (merging NOT
appending)
> > > >>>>>> [I have the patch engine: Gluster specific
firewall
> > > >>>>>> configurations
> > > >>>>>> #7244]
> > > >>>>>> 2. Having two different IP Table config (ovirt
and
> > > >>>>>> ovirt+gluster)
> > > >>>>>> and
> > > >>>>>> use either one.
> > > >>>>>>
> > > >>>>>> Please provide your suggestions or improvements
on this.
> > > >>>>>>
> > > >>>>> Hello all,
> > > >>>>>
> > > >>>>> The mentioned patch[1], adds hard coded gluster code
into
> > > >>>>> the
> > > >>>>> bootstrap code, manipulate the firewall configuration
to
> > > >>>>> be
> > > >>>>> gluster specific. It hardcoded search for
"reject",
> > > >>>>> insert
> > > >>>>> before
> > > >>>>> some other rules.
> > > >>>>>
> > > >>>>> I believe this hardcode approach is obsolete now that
we
> > > >>>>> have
> > > >>>>> proper tools for templates.
> > > >>>>>
> > > >>>>> A more robust solution would be defining generic
> > > >>>>> profiles,
> > > >>>>> each
> > > >>>>> profile as a template, each template can refer to
> > > >>>>> different
> > > >>>>> profiles, and assign profile to a node.
> > > >>>>>
> > > >>>>> This way the implementation is not gluster [or any]
> > > >>>>> specific
> > > >>>>> and
> > > >>>>> can be reused for more setups, code is cleaner.
> > > >>>>>
> > > >>>>> 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/
4:09 p.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com>,
"Mike Burns" <mburns(a)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.
4:21 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com>,
"Mike Burns" <mburns(a)redhat.com>
Sent: Monday, September 3, 2012 5:09:34 PM
Subject: Re: [Engine-devel] Gluster IPTable configuration
----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com>,
> "Mike Burns" <mburns(a)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.
4:06 a.m.
Andrew Cathrow píše v Po 03. 09. 2012 v 17:21 -0400:
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Andrew Cathrow" <acathrow(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" <sanjal(a)redhat.com>,
"Mike Burns" <mburns(a)redhat.com>
> Sent: Monday, September 3, 2012 5:09:34 PM
> Subject: Re: [Engine-devel] Gluster IPTable configuration
>
>
>
> ----- Original Message -----
> > From: "Andrew Cathrow" <acathrow(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal"
<sanjal(a)redhat.com>,
> > "Mike Burns" <mburns(a)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(a)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
4491
days inactive
4496
days old
25 comments
7 participants
participants (7)
-
Alon Bar-Lev -
Andrew Cathrow -
David Jaša -
Doron Fediuck -
Itamar Heim -
Selvasundaram -
Shireesh Anjal