<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 09/07/2015 09:25 AM, Anand Nekkunti
      wrote:<br>
    </div>
    <blockquote cite="mid:55EDBA7B.5010705@redhat.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <br>
      <br>
      <div class="moz-cite-prefix">On 09/07/2015 05:08 PM, Joe Julian
        wrote:<br>
      </div>
      <blockquote cite="mid:55ED771D.8000907@julianfamily.org"
        type="cite"> <br>
        <br>
        On 09/06/2015 09:01 PM, Kaushal M wrote: <br>
        <blockquote type="cite">After more investigation and further
          discussions (sorry these happened <br>
          internally), what I've found is that there is no way currently
          to <br>
          dynamically change a firewalld service in runtime without side
          <br>
          effects. I'll be opening an RFE for this with firewalld, and
          see where <br>
          it goes. <br>
        </blockquote>
        <br>
        What are these side-effects? <br>
      </blockquote>
      <b><br>
      </b>
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <b>Below Issues are dynamically handling ports :</b><br>
       <b>In firewalld: </b><br>
      1. Dynamically service update is not supported in firewalld( as
      per my knowledge we can't do it using D-bus also) <br>
      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. <br>
    </blockquote>
    <br>
    Which could be solved by having a dbus listener.<br>
    <br>
    <blockquote cite="mid:55EDBA7B.5010705@redhat.com" type="cite"> <b>In
        Glusterd : </b><br>
      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 ).<br>
       Note :ports of the bricks are known after commit(i.e brick start)
      <br>
      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.<br>
       3. Selinux : SELinux permission required to run firewalld
      commands in hook script.<br>
      <br>
       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).<br>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:55EDBA7B.5010705@redhat.com" type="cite"> <br>
      <blockquote cite="mid:55ED771D.8000907@julianfamily.org"
        type="cite"> <br>
        <blockquote type="cite"> <br>
          For now, our best option is to open up a range of ports
          statically in <br>
          our service file. This isn't the best solution, but I've seen
          some <br>
          other applications doing the same. This also avoids some
          selinux <br>
          issues we saw during our tests. If no one has any objections
          to this <br>
          we can proceed with this. <br>
          <br>
          ~kaushal <br>
          <br>
          On Mon, Sep 7, 2015 at 9:25 AM, Kaushal M <a
            moz-do-not-send="true" class="moz-txt-link-rfc2396E"
            href="mailto:kshlmster@gmail.com"><a class="moz-txt-link-rfc2396E" href="mailto:kshlmster@gmail.com">&lt;kshlmster@gmail.com&gt;</a></a>
          wrote: <br>
          <blockquote type="cite">On Fri, Sep 4, 2015 at 7:44 PM, Joe
            Julian <a moz-do-not-send="true"
              class="moz-txt-link-rfc2396E"
              href="mailto:joe@julianfamily.org">&lt;joe@julianfamily.org&gt;</a>
            wrote: <br>
            <blockquote type="cite">As an upstream admin, one of the
              things I abhor about debian/ubuntu is how <br>
              services are enabled upon installation. I sure hope
              Fedora/EL doesn't follow <br>
              their broken example. <br>
              <br>
              Can we enable the static firewall rule in
              glusterd.service? <br>
              <br>
            </blockquote>
            Joe, <br>
            The services we are talking about are firewalld services,
            not systemd <br>
            services. A firewalld service is a collection of firewall
            rules for an <br>
            application, which the application can ship with it. The
            admin is free <br>
            to enable/disable these services on the networks they want
            (not <br>
            directly, but through firewalld zones). A firewalld service
            cannot be <br>
            enabled automatically, and requires admin to do it. I hope
            this <br>
            answers your question. <br>
            <br>
            ~kaushal <br>
            <br>
            <blockquote type="cite"> <br>
              <br>
              On September 4, 2015 6:37:15 AM PDT, Christopher Blum <a
                moz-do-not-send="true" class="moz-txt-link-rfc2396E"
                href="mailto:cblum@redhat.com"><a class="moz-txt-link-rfc2396E" href="mailto:cblum@redhat.com">&lt;cblum@redhat.com&gt;</a></a>
              <br>
              wrote: <br>
              <blockquote type="cite">Wasn't the idea behind this all
                that we have the necessary firewall rules <br>
                active by default? Why would an admin install Gluster,
                but NOT allow it to <br>
                work? <br>
                Do you know if we will have the service pre-enabled
                after the install of <br>
                RHGS3.1.1? <br>
                <br>
                Christopher Blum <br>
                Associate Storage Consultant <br>
                Global Storage Consulting, Red Hat <br>
                <br>
                +49 711 96 43 7009 <br>
                <br>
                On Fri, Sep 4, 2015 at 2:05 PM, Anand Nekkunti <a
                  moz-do-not-send="true" class="moz-txt-link-rfc2396E"
                  href="mailto:anekkunt@redhat.com"><a class="moz-txt-link-rfc2396E" href="mailto:anekkunt@redhat.com">&lt;anekkunt@redhat.com&gt;</a></a>
                <br>
                wrote: <br>
                <blockquote type="cite"> <br>
                  <br>
                  On 09/04/2015 05:20 PM, Christopher Blum wrote: <br>
                  <br>
                  Where do you add the services to the zone? I couldn't
                  find that in your <br>
                  code... <br>
                  <br>
                       By default it is not attached to any zone, admin
                  has to enable <br>
                  glusterfs-static service to his/her active zone after
                  installation. <br>
                  <br>
                  <br>
                  Christopher Blum <br>
                  Associate Storage Consultant <br>
                  Global Storage Consulting, Red Hat <br>
                  <br>
                  +49 711 96 43 7009 <br>
                  <br>
                  On Fri, Sep 4, 2015 at 5:37 AM, Anand Nekkunti <a
                    moz-do-not-send="true" class="moz-txt-link-rfc2396E"
                    href="mailto:anekkunt@redhat.com"><a class="moz-txt-link-rfc2396E" href="mailto:anekkunt@redhat.com">&lt;anekkunt@redhat.com&gt;</a></a>
                  <br>
                  wrote: <br>
                  <blockquote type="cite">see comments below <br>
                    <br>
                    <br>
                    On 09/01/2015 02:47 PM, Anand Nekkunti wrote: <br>
                    <br>
                    Hi All <br>
                     From firewalld doc and my experiments , I
                    understood that we don't have <br>
                    any option to add/remove port to/from service
                    runtime/permanent  (this can <br>
                    double for  zone) . The only way is modifying
                    service xml file but it <br>
                    requires firewall reload (which cause the loosing
                    run time settings). <br>
                               Is there any way to reload firewall
                    without loosing run time <br>
                    settings or is there any way to reload particular
                    service. <br>
                    <br>
                    Regards <br>
                    Anand.N <br>
                    <br>
                    On 09/01/2015 12:49 PM, Christopher Blum wrote: <br>
                    <br>
                    There is a function in the d-bus interface: <br>
                    <br>
                    getZoneOfInterface(s: interface) → s <br>
                    <br>
                    that will return the current zone of the interface
                    and you can then add <br>
                    ports to that interface. <br>
                    As far as I see it, the hooks get only executed when
                    I start the volume, <br>
                    right? So when I created and started the volume, but
                    then change the zone of <br>
                    the interface, we need to detect that (I guess it
                    would be enough to handle <br>
                    that on reboot) and move the ports/services to the
                    new zone. <br>
                    <br>
                    Regarding
                    Org.fedoraproject.firewalld1.config.service - I
                    think that <br>
                    would need additional tests if that is really only
                    for the persistent <br>
                    config, or if the changes are also applied in the
                    running config. <br>
                    <br>
                    Christopher Blum <br>
                    Associate Storage Consultant <br>
                    Global Storage Consulting, Red Hat <br>
                    <br>
                    +49 711 96 43 7009 <br>
                    <br>
                    On Tue, Sep 1, 2015 at 8:58 AM, Kaushal M <a
                      moz-do-not-send="true"
                      class="moz-txt-link-rfc2396E"
                      href="mailto:kshlmster@gmail.com"><a class="moz-txt-link-rfc2396E" href="mailto:kshlmster@gmail.com">&lt;kshlmster@gmail.com&gt;</a></a>
                    wrote: <br>
                    <blockquote type="cite">On Mon, Aug 31, 2015 at 5:15
                      PM, Kaushal M <a moz-do-not-send="true"
                        class="moz-txt-link-rfc2396E"
                        href="mailto:kshlmster@gmail.com">&lt;kshlmster@gmail.com&gt;</a>
                      wrote: <br>
                      <blockquote type="cite">Hi all, <br>
                        <br>
                        I wanted know if there is any existing
                        information on how to manage <br>
                        dynamically changing services using firewalld.
                        If there are none <br>
                        existing, could you please let us know if the
                        approach we're <br>
                        following <br>
                        below is correct. <br>
                        <br>
                        We want to provide firewalld service
                        configuration for GlusterFS. One <br>
                        of the properties of GlusterFS is that it has a
                        set of fixed ports, <br>
                        and a set of dynamic ports, which need to be
                        opened. <br>
                        <br>
                        We propose to ship 2 firewalld services with
                        GlusterFS. <br>
                        - glusterfs-static - This contains the list of
                        static ports that <br>
                        should be opened up. This is placed in
                        /usr/lib/firewalld/services <br>
                        - glusterfs-dynamic - This will contain the list
                        of dynamic ports. <br>
                        This will be shipped empty, and be placed in
                        /etc/firewalld/services <br>
                        . <br>
                        The ports in this service will be kept updated
                        by a couple of <br>
                        scripts, <br>
                        which hook into the glusterfs start/stop events.
                        <br>
                        <br>
                        The scripts, add or remove ports from the
                        glusterfs-dyanmic.xml file, <br>
                        and call `firewall-cmd --reload` to have
                        firewalld reload <br>
                        configuration. We do it this way, instead of
                        using a dbus call <br>
                        because <br>
                        we want the configuration to be persisted, and
                        also applied live. <br>
                        <br>
                        We've tested this, and this works. But we'd like
                        to validate this <br>
                        solution with you guys. <br>
                        <br>
                        Do you see any issues with our approach? Is
                        there anything we could <br>
                        do <br>
                        to improve the solution. <br>
                        <br>
                        For reference, the glusterfs bug and proposed
                        solution are available <br>
                        at [1] and [2]. <br>
                        <br>
                        Thanks. <br>
                        <br>
                        Kaushal <br>
                        <br>
                        [1] <a moz-do-not-send="true"
                          class="moz-txt-link-freetext"
                          href="https://bugzilla.redhat.com/show_bug.cgi?id=1253967">https://bugzilla.redhat.com/show_bug.cgi?id=1253967</a>
                        <br>
                        [2] <a moz-do-not-send="true"
                          class="moz-txt-link-freetext"
                          href="http://review.gluster.org/11989">http://review.gluster.org/11989</a>
                        <br>
                        <br>
                        PS: Apologies if I should have posted this to
                        the users list instead. <br>
                      </blockquote>
                      I've had a private conversation with Christopher
                      Blum (CCd), who <br>
                      identified a major flaw with our current solution.
                      Having firewalld <br>
                      reload will cause any runtime rules that were set
                      to be lost. This <br>
                      should be avoided at all costs. <br>
                      <br>
                      Chris suggested using firewalld dbus commands [1]
                      which could solve <br>
                      this. We have dbus commands to add/remove ports
                      from a service <br>
                      permanently. This is an alternative to updating
                      the service xml files. <br>
                      But we don't see a method to update a service
                      during runtime. <br>
                      <br>
                      There are dbus commands to add/remove ports to
                      zones during runtime. <br>
                      But this is not useful as we wouldn't know which
                      zone to apply it to. <br>
                      One of the reasons we chose to use services was
                      this. <br>
                      <br>
                      So now we have two questions, <br>
                      1. Is there a way to do a runtime modification of
                      a firewalld service <br>
                    </blockquote>
                                 it seems  firewalld not supporting for
                    run time service <br>
                    update, but  we can add and remove ports <br>
                                  from zone <br>
                    <blockquote type="cite">2. If not, is there a easy
                      way to get active zones, which have our <br>
                      services enabled and add/remove ports from them. <br>
                    </blockquote>
                                we can get the services which are
                    enabled in zone using below <br>
                    command <br>
                                 firewall-cmd --zone=$zone
                    --list-services <br>
                                I have updated  hook script in my
                    patch[1] , it identify the <br>
                    zones which have gluster services enabled and  it
                    add/remove the port in <br>
                    zone(s) so that we can avoid <br>
                                firewall reload. I have tested this
                    script with different <br>
                    test cases <br>
                                
                    [1].http://review.gluster.org/#/c/11989/ <br>
                    <br>
                    <br>
                    <blockquote type="cite">Thanks. <br>
                      <br>
                      Kaushal <br>
                      <br>
                      [1] <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
                        href="https://www.mankier.com/5/firewalld.dbus">https://www.mankier.com/5/firewalld.dbus</a>
                      <br>
                      [2] <br>
                      <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
href="https://www.mankier.com/5/firewalld.dbus#Interfaces-Org.fedoraproject.firewalld1.config.service">https://www.mankier.com/5/firewalld.dbus#Interfaces-Org.fedoraproject.firewalld1.config.service</a>
                      <br>
                    </blockquote>
                    <br>
                    <br>
                    <br>
                    _______________________________________________ <br>
                    Gluster-devel mailing list <br>
                    <a moz-do-not-send="true"
                      class="moz-txt-link-abbreviated"
                      href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
                    <br>
                    <a moz-do-not-send="true"
                      class="moz-txt-link-freetext"
                      href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
                    <br>
                    <br>
                    <br>
                    <br>
                    <br>
                    _______________________________________________ <br>
                    Gluster-devel mailing list <br>
                    <a moz-do-not-send="true"
                      class="moz-txt-link-abbreviated"
                      href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
                    <br>
                    <a moz-do-not-send="true"
                      class="moz-txt-link-freetext"
                      href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
                    <br>
                    <br>
                    <br>
                  </blockquote>
                  <br>
                </blockquote>
                ________________________________ <br>
                <br>
                Gluster-devel mailing list <br>
                <a moz-do-not-send="true"
                  class="moz-txt-link-abbreviated"
                  href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
                <br>
                <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
                <br>
              </blockquote>
              <br>
              -- <br>
              Sent from my Android device with K-9 Mail. Please excuse
              my brevity. <br>
              <br>
              _______________________________________________ <br>
              Gluster-devel mailing list <br>
              <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
                href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
              <br>
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
                href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
              <br>
              <br>
            </blockquote>
          </blockquote>
          _______________________________________________ <br>
          Gluster-devel mailing list <br>
          <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
            href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
          <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
          <br>
        </blockquote>
        <br>
        _______________________________________________ <br>
        Gluster-devel mailing list <br>
        <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>