[Gluster-devel] Dynamically changing firewalld services
Anand Nekkunti
anekkunt at redhat.com
Mon Sep 7 16:25:31 UTC 2015
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.
*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).
>
>>
>> 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
>
> _______________________________________________
> 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/20150907/f7f74a6c/attachment-0001.html>
More information about the Gluster-devel
mailing list