[Bugs] [Bug 1253967] New: glusterfs doesn't include firewalld rules

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1253967

            Bug ID: 1253967
           Summary: glusterfs doesn't include firewalld rules
           Product: GlusterFS
           Version: mainline
         Component: build
          Keywords: EasyFix, Triaged
          Assignee: bugs at gluster.org
          Reporter: ndevos at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com
            Blocks: 1057295



+++ This bug was initially created as a clone of Bug #1057295 +++
+++                                                           +++
+++ Use this bug to post patches for the master branch.       +++

Description of problem:

glusterfs(d) is missing firewall rules.  As a result it doesn't
work unless you manually configure the firewall, which sucks.

I believe it should work if you drop in the following file:

/usr/lib/firewalld/services/glusterfs.xml

containing:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>glusterfs</short>
  <description>Some description here ...</description>
  <port port="24007" protocol="tcp" />
  <port port="24009" protocol="tcp" />
  <port port="24010" protocol="tcp" />
  <port port="49152" protocol="tcp" />
</service>

Version-Release number of selected component (if applicable):

3.4.2, Fedora 20.

How reproducible:

100%

Steps to Reproduce:

Just start up gluster in the default configuration.  It's
impossible to use it without consulting lots of contradictory
online documentation about what firewall ports to open up
and then manually reconfiguring the firewall.

--- Additional comment from Joe Julian on 2014-01-29 21:46:09 CET ---

Those rules are not sufficient.

The management process (glusterd) uses 24007/tcp and conditionally 24008/tcp if
you use rdma.

Bricks (glusterfsd) use 49152 *& up*.

Additionally a glusterfs process will listen on 38465-38467/tcp for nfs, and
38468 for NLM. 

NFS also depends on rpcbind/portmap on port 111 and 2049.

Without a dbus interface (or some other scripting hook), I just don't see how
firewalld can be informed of dynamic port utilization.

As community support, we currently recommend disabling firewalld and falling
back to iptables managed through tools like puppet.

Features that would communicate the port needs through dbus, or some other
method, might be good for this but it's not on the roadmap and unlikely to make
F20 (in my estimation).

To propose a more extended firewalld configuration that includes the required
ports, I hope you'll consider submitting your patch through
http://www.gluster.org/community/documentation/index.php/Development_Work_Flow

--- Additional comment from John Skeoch on 2014-03-31 03:35:19 CEST ---

User vraman at redhat.com's account has been closed

--- Additional comment from Niels de Vos on 2015-05-17 23:57:52 CEST ---

GlusterFS 3.7.0 has been released
(http://www.gluster.org/pipermail/gluster-users/2015-May/021901.html), and the
Gluster project maintains N-2 supported releases. The last two releases before
3.7 are still maintained, at the moment these are 3.6 and 3.5.

This bug has been filed against the 3,4 release, and will not get fixed in a
3.4 version any more. Please verify if newer versions are affected with the
reported problem. If that is the case, update the bug with a note, and update
the version if you can. In case updating the version is not possible, leave a
comment in this bug report with the version you tested, and set the "Need
additional information the selected bugs from" below the comment box to
"bugs at gluster.org".

If there is no response by the end of the month, this bug will get
automatically closed.

--- Additional comment from Joe Julian on 2015-05-18 19:17:29 CEST ---

This could potentially be handled with the hooks interface, but the port
information would need to be passed to the script.

This is low-hanging fruit.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1057295
[Bug 1057295] glusterfs doesn't include firewalld rules
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.