On Mon, Sep 7, 2015 at 5:08 PM, Joe Julian <joe@xxxxxxxxxxxxxxxx> 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? The side-effect is that reloading firewalld would cause any runtime changes done to be lost. So we cannot do reloads in our hooks. > > >> >> 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@xxxxxxxxx> wrote: >>> >>> On Fri, Sep 4, 2015 at 7:44 PM, Joe Julian <joe@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> >>>> 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@xxxxxxxxxx> >>>>> 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@xxxxxxxxxx> >>>>>> 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@xxxxxxxxx> >>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, Aug 31, 2015 at 5:15 PM, Kaushal M <kshlmster@xxxxxxxxx> >>>>>>>> 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@xxxxxxxxxxx >>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Gluster-devel mailing list >>>>>>> Gluster-devel@xxxxxxxxxxx >>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>> >>>>>>> >>>>>> >>>>> ________________________________ >>>>> >>>>> Gluster-devel mailing list >>>>> Gluster-devel@xxxxxxxxxxx >>>>> 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@xxxxxxxxxxx >>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
