Description of problem: In https://bugzilla.redhat.com/show_bug.cgi?id=1282915, the systemd unit for glusterd was changed so that it `Requires=` rpcbind. That is, glusterd cannot run without rpcbind running. rpcbind is only required to use the NFS functionality of gluster. Because of this, rpcbind is an optional dependency of many glusterfs packages, e.g. of glusterfs-server on Debian/Ubuntu. rpcbind by default listens on all interfaces. An rpcbind running on the open Internet can be easily abused for DNS amplification attacks (see e.g. https://www.theregister.co.uk/2015/08/19/portmap_ddos_threat/). As a result, as a system administrator that does not use Gluster's NFS feature I would typically prefer to NOT have rpcbind running. I also cannot quite follow why this was added in the first place - for optional dependencies, having only `After=` seems to be the exactly right configuration. In my understanding, the solution to the problem of the original poster in https://bugzilla.redhat.com/show_bug.cgi?id=1282915 is to run `systemctl enable rpcbind` to have it start at boot, not to change glusterfs to require it. Once done so, `After=` will ensure that the two services are started in the correct order. Thus I suggest that to provide safer defaults, and to reflect how systemd recommends handling optional dependencies, the default systemd unit for glusterd should not `Requires=` rpcbind. Instead, I suggest that we update the docs, mentioning that if you want the NFS feature to be available at boot, you should use `systemctl enable rpcbind`.
As a temporary workaround, administrators that do not use NFS but do not want to change the systemd unit provided by the glusterfs package, or that do use NFS but want to expose it only to localhost or via a secure connection like a VPN, may block out non-localhost rpcbind connections by changing /etc/hosts.allow and /etc/hosts.deny as described on e.g. https://davelozier.com/glusterfs-and-rpcbind-portmap-ddos-reflection-attacks/.
This bug is getting closed because GlusterFS-3.9 has reached its end-of-life [1]. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please open a new bug against the newer release. [1]: https://www.gluster.org/community/release-schedule/
Reopened for 3.10.
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained. As a result this bug is being closed. If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.