From 59a195ba9ca5485697802eec3550d5535f437b47 Mon Sep 17 00:00:00 2001 From: Krishnan Parthasarathi Date: Wed, 12 Nov 2014 17:36:37 +0530 Subject: doc: added did-you-know.md to document the less-known behaviours and features of GlusterFS Change-Id: Ibabc6398be9fb1c20127aaad2c51a629fed7c10b Signed-off-by: Krishnan Parthasarathi Reviewed-on: http://review.gluster.org/9103 Reviewed-by: Humble Devassy Chirammal Reviewed-by: Lalatendu Mohanty Tested-by: Lalatendu Mohanty --- doc/admin-guide/en-US/markdown/did-you-know.md | 36 ++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/admin-guide/en-US/markdown/did-you-know.md (limited to 'doc/admin-guide/en-US') diff --git a/doc/admin-guide/en-US/markdown/did-you-know.md b/doc/admin-guide/en-US/markdown/did-you-know.md new file mode 100644 index 00000000000..085b4a81a7a --- /dev/null +++ b/doc/admin-guide/en-US/markdown/did-you-know.md @@ -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--fuse.vol and -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. + -- cgit