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?
On September 4, 2015 6:37:15 AM PDT, Christopher Blum cblum@redhat.com 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@redhat.com 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@redhat.com 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 <%2B49%20711%2096%2043%207009>
On Tue, Sep 1, 2015 at 8:58 AM, Kaushal M < kshlmster@gmail.com kshlmster@gmail.com> wrote:
On Mon, Aug 31, 2015 at 5:15 PM, Kaushal M kshlmster@gmail.com
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,
- 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
- 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
https://www.mankier.com/5/firewalld.dbus#Interfaces-Org.fedoraproject.firewa...
Gluster-devel mailing
listGluster-devel@gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-devel
Gluster-devel mailing
listGluster-devel@gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-devel
Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel