[Gluster-devel] Dynamically changing firewalld services

Joe Julian joe at julianfamily.org
Mon Sep 7 11:38:05 UTC 2015 


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?

>
> 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 at gmail.com> wrote:
>> On Fri, Sep 4, 2015 at 7:44 PM, Joe Julian <joe at julianfamily.org> 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 at 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 at 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 at 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
>>>>>>
>>>>>> On Tue, Sep 1, 2015 at 8:58 AM, Kaushal M <kshlmster at gmail.com> wrote:
>>>>>>> On Mon, Aug 31, 2015 at 5:15 PM, Kaushal M <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
>>>>>>
>>>>>>
>>>>>
>>>> ________________________________
>>>>
>>>> Gluster-devel mailing list
>>>> Gluster-devel at gluster.org
>>>> 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 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

More information about the Gluster-devel mailing list