On Tue, Jan 27, 2015 at 02:10:17AM +0100, Csaba Henk wrote: > Hi Niels, > > On Mon, Jan 26, 2015 at 10:07 AM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > On Sun, Jan 25, 2015 at 10:08:20PM +0530, Ramana Raja wrote: > >> 1) How would the above suggestion impact gfapi access? > > > > gfapi uses the GlusterFS protocol. When access through the protocol is > > denied, only clients from within the trusted storage pool can use it. > > gfapi is just a client, similar to the FUSE mount. > > > >> 2) Would the list of trusted clients be configured via "gluster volume set"? > > > > There are the 'auth.allow' and 'auth.reject' volume options. I think > > they would be used as an alternative to a "turn off glusterfs protocol" > > feature. > > Does it mean that the implementation of feature would essentially boil down > to an auth ruleset calculated by glusterfs? I guess that depends on the goal of the feature. Where does the need arrise to "turn off the glusterfs protocol"? Should nothing outside of the trusted storage pool be able to connect to the bricks? This would effectively only allow NFS/Samba/... when the service is located on a system that is part of the trusted storage pool. If you need a more fine-grained permission scheme, auth.allow and auth.reject might be more appropriate. Or, use SSL authentication? HTH, Niels
Attachment:
pgpQvnDkA2PMy.pgp
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
