[Gluster-devel] Dynamically changing firewalld services

Joe Julian joe at julianfamily.org
Mon Sep 7 16:33:16 UTC 2015 


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 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/0150aa3c/attachment-0001.html>

More information about the Gluster-devel mailing list