andy/glusterfs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

doc: added did-you-know.md to document the less-known

Browse Source 
behaviours and features of GlusterFS

Change-Id: Ibabc6398be9fb1c20127aaad2c51a629fed7c10b
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/9103
Reviewed-by: Humble Devassy Chirammal <humble.devassy@gmail.com>
Reviewed-by: Lalatendu Mohanty <lmohanty@redhat.com>
Tested-by: Lalatendu Mohanty <lmohanty@redhat.com>
This commit is contained in:
Krishnan Parthasarathi 2014-11-12 17:36:37 +05:30 committed by Lalatendu Mohanty
parent 0250eb0698
commit 59a195ba9c
1 changed files with 36 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
doc/admin-guide/en-US/markdown/did-you-know.md Normal file
View File

@ -0,0 +1,36 @@
#Did you know?
This document is an attempt to describe less-documented behaviours and features
of GlusterFS that an admin always wanted to know but was too shy or busy to
ask.
## Trusted Volfiles
Observant admins would have wondered why there are two similar volume files for
every volume, namely trusted-<VOLNAME>-fuse.vol and <VOLNAME>-fuse.vol. To
appreciate this one needs to know about the IP address/hostname based access
restriction schemes available in GlusterFS. They are "auth-allow" and
"auth-reject". The "auth-allow" and "auth-reject" options take a comma
separated list of IP addresses/hostnames as value. "auth-allow" allows access
_only_ to clients running on machines whose IP address/hostname are on this
list. It is highly likely for an admin to configure the "auth-allow" option
without including the list of nodes in the cluster. One would expect this to
work. Previously, in this configuration (internal) clients such as
gluster-nfs, glustershd etc., running in the trusted storage pool, would be
denied access to the volume. This is undesirable and counter-intuitive. The
work around was to add the IP address/hostnames of all the nodes in the trusted
storage pool to the "auth-allow" list. This is bad for a reasonably large
number of nodes. To fix this, an alternate authentication mechanism for nodes
in the storage pool was introduced. Following is a brief explanation of how
this works.
The volume file with trusted prefix in its name (i.e trusted-volfile) has a
username and password option in the client xlator. The trusted-volfile is used
_only_ by mount processes running in the trusted storage pool (hence the name).
The username and password, when present, allow "mount" (and other glusterfs)
processes to access the brick processes even if the node they are running on is
not explicitly added in "auth-allow" addresses. 'Regular' mount processes,
running on nodes outside the trusted storage pool, use the non-trusted-volfile.
The important thing to note is that "trusted" in this context only implied
belonging to the trusted storage pool.