[Gluster-devel] Dynamically changing firewalld services

Anand Nekkunti anekkunt at redhat.com
Fri Sep 4 03:37:21 UTC 2015


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 <tel:%2B49%20711%2096%2043%207009>
>>
>> On Tue, Sep 1, 2015 at 8:58 AM, Kaushal M <kshlmster at gmail.com 
>> <mailto:kshlmster at gmail.com>> wrote:
>>
>>     On Mon, Aug 31, 2015 at 5:15 PM, Kaushal M <kshlmster at gmail.com
>>     <mailto:kshlmster at 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,
>>     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 at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150904/43f1b8bd/attachment-0001.html>


More information about the Gluster-devel mailing list