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