On 09/07/2015 09:25 AM, Anand Nekkunti
wrote:
On 09/07/2015 05:08 PM, Joe Julian
wrote:
On 09/06/2015 09:01 PM, Kaushal M wrote:
After more investigation and further
discussions (sorry these happened
internally), what I've found is that there is no way currently
to
dynamically change a firewalld service in runtime without side
effects. I'll be opening an RFE for this with firewalld, and
see where
it goes.
What are these side-effects?
Below Issues are dynamically handling ports :
In firewalld:
1. Dynamically service update is not supported in firewalld( as
per my knowledge we can't do it using D-bus also)
2. We can do dynamically add/ remove port from zone but if admin
wants change the zone , then restart volume is required to open
ports in new zone and manually admin has to remove ports from old
zone.
Which could be solved by having a dbus listener.
In
Glusterd :
1.mount may fail : hook script runs after brick start and it runs
in back ground , due to this there will chance that volume mount
fail (brick is started but port not yet opened ).
Note :ports of the bricks are known after commit(i.e brick start)
2. io error in client during add-brick: Brick is started and
notified to client about new brick but port is not yet opened for
that brick then it leads to io error in client which causes the
data lost.
3. Selinux : SELinux permission required to run firewalld
commands in hook script.
Considering all these the best approach IMO is to statically open
up a range of ports for the bricks( I have seen some other
applications doing the same).
Yet another reason we should have dbus integration. Then the
glusterd systemd service could be a dbus type and won't emit until
everything is listening. Since the ports are known before the hooks
are run, this would give dbus a leg up on the upcoming hook scripts.
This also solves the selinux problem.
For now, our best option is to open up a range of ports
statically in
our service file. This isn't the best solution, but I've seen
some
other applications doing the same. This also avoids some
selinux
issues we saw during our tests. If no one has any objections
to this
we can proceed with this.
~kaushal
On Mon, Sep 7, 2015 at 9:25 AM, Kaushal M <kshlmster@xxxxxxxxx>
wrote:
On Fri, Sep 4, 2015 at 7:44 PM, Joe
Julian <joe@xxxxxxxxxxxxxxxx>
wrote:
As an upstream admin, one of the
things I abhor about debian/ubuntu is how
services are enabled upon installation. I sure hope
Fedora/EL doesn't follow
their broken example.
Can we enable the static firewall rule in
glusterd.service?
Joe,
The services we are talking about are firewalld services,
not systemd
services. A firewalld service is a collection of firewall
rules for an
application, which the application can ship with it. The
admin is free
to enable/disable these services on the networks they want
(not
directly, but through firewalld zones). A firewalld service
cannot be
enabled automatically, and requires admin to do it. I hope
this
answers your question.
~kaushal
On September 4, 2015 6:37:15 AM PDT, Christopher Blum <cblum@xxxxxxxxxx>
wrote:
Wasn't the idea behind this all
that we have the necessary firewall rules
active by default? Why would an admin install Gluster,
but NOT allow it to
work?
Do you know if we will have the service pre-enabled
after the install of
RHGS3.1.1?
Christopher Blum
Associate Storage Consultant
Global Storage Consulting, Red Hat
+49 711 96 43 7009
On Fri, Sep 4, 2015 at 2:05 PM, Anand Nekkunti <anekkunt@xxxxxxxxxx>
wrote:
On 09/04/2015 05:20 PM, Christopher Blum wrote:
Where do you add the services to the zone? I couldn't
find that in your
code...
By default it is not attached to any zone, admin
has to enable
glusterfs-static service to his/her active zone after
installation.
Christopher Blum
Associate Storage Consultant
Global Storage Consulting, Red Hat
+49 711 96 43 7009
On Fri, Sep 4, 2015 at 5:37 AM, Anand Nekkunti <anekkunt@xxxxxxxxxx>
wrote:
see comments below
On 09/01/2015 02:47 PM, Anand Nekkunti wrote:
Hi All
From firewalld doc and my experiments , I
understood that we don't have
any option to add/remove port to/from service
runtime/permanent (this can
double for zone) . The only way is modifying
service xml file but it
requires firewall reload (which cause the loosing
run time settings).
Is there any way to reload firewall
without loosing run time
settings or is there any way to reload particular
service.
Regards
Anand.N
On 09/01/2015 12:49 PM, Christopher Blum wrote:
There is a function in the d-bus interface:
getZoneOfInterface(s: interface) → s
that will return the current zone of the interface
and you can then add
ports to that interface.
As far as I see it, the hooks get only executed when
I start the volume,
right? So when I created and started the volume, but
then change the zone of
the interface, we need to detect that (I guess it
would be enough to handle
that on reboot) and move the ports/services to the
new zone.
Regarding
Org.fedoraproject.firewalld1.config.service - I
think that
would need additional tests if that is really only
for the persistent
config, or if the changes are also applied in the
running config.
Christopher Blum
Associate Storage Consultant
Global Storage Consulting, Red Hat
+49 711 96 43 7009
On Tue, Sep 1, 2015 at 8:58 AM, Kaushal M <kshlmster@xxxxxxxxx>
wrote:
On Mon, Aug 31, 2015 at 5:15
PM, Kaushal M <kshlmster@xxxxxxxxx>
wrote:
Hi all,
I wanted know if there is any existing
information on how to manage
dynamically changing services using firewalld.
If there are none
existing, could you please let us know if the
approach we're
following
below is correct.
We want to provide firewalld service
configuration for GlusterFS. One
of the properties of GlusterFS is that it has a
set of fixed ports,
and a set of dynamic ports, which need to be
opened.
We propose to ship 2 firewalld services with
GlusterFS.
- glusterfs-static - This contains the list of
static ports that
should be opened up. This is placed in
/usr/lib/firewalld/services
- glusterfs-dynamic - This will contain the list
of dynamic ports.
This will be shipped empty, and be placed in
/etc/firewalld/services
.
The ports in this service will be kept updated
by a couple of
scripts,
which hook into the glusterfs start/stop events.
The scripts, add or remove ports from the
glusterfs-dyanmic.xml file,
and call `firewall-cmd --reload` to have
firewalld reload
configuration. We do it this way, instead of
using a dbus call
because
we want the configuration to be persisted, and
also applied live.
We've tested this, and this works. But we'd like
to validate this
solution with you guys.
Do you see any issues with our approach? Is
there anything we could
do
to improve the solution.
For reference, the glusterfs bug and proposed
solution are available
at [1] and [2].
Thanks.
Kaushal
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1253967
[2] http://review.gluster.org/11989
PS: Apologies if I should have posted this to
the users list instead.
I've had a private conversation with Christopher
Blum (CCd), who
identified a major flaw with our current solution.
Having firewalld
reload will cause any runtime rules that were set
to be lost. This
should be avoided at all costs.
Chris suggested using firewalld dbus commands [1]
which could solve
this. We have dbus commands to add/remove ports
from a service
permanently. This is an alternative to updating
the service xml files.
But we don't see a method to update a service
during runtime.
There are dbus commands to add/remove ports to
zones during runtime.
But this is not useful as we wouldn't know which
zone to apply it to.
One of the reasons we chose to use services was
this.
So now we have two questions,
1. Is there a way to do a runtime modification of
a firewalld service
it seems firewalld not supporting for
run time service
update, but we can add and remove ports
from zone
2. If not, is there a easy
way to get active zones, which have our
services enabled and add/remove ports from them.
we can get the services which are
enabled in zone using below
command
firewall-cmd --zone=$zone
--list-services
I have updated hook script in my
patch[1] , it identify the
zones which have gluster services enabled and it
add/remove the port in
zone(s) so that we can avoid
firewall reload. I have tested this
script with different
test cases
[1].http://review.gluster.org/#/c/11989/
Thanks.
Kaushal
[1] https://www.mankier.com/5/firewalld.dbus
[2]
https://www.mankier.com/5/firewalld.dbus#Interfaces-Org.fedoraproject.firewalld1.config.service
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
--
Sent from my Android device with K-9 Mail. Please excuse
my brevity.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
|
