On Tue, 27 Jan 2015 11:39:52, Niels de Vos <ndevos at redhat.com> wrote: > On Tue, Jan 27, 2015 at 02:10:17AM +0100, Csaba Henk wrote: > > 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. So, the basic use case is when in a cloud environment we make a Gluster volume (entirely or partially) accessible via Gluster-NFS. Then the NFS server is part of the Gluster cluster and a simple semantics of "turn off glusterfs proto" (involving the earlier discussed internal exceptions) seems to do the job (for preventint uncurated access). However, a variant of that -- which is supposed to become more prevalent -- is when the Gluster volume is made accessible with the help of NFS-Ganesha. The Ganesha server typically resides outside of the cluster, but should be handled as a trusted entity. That is, we still need a simplistic semantics which lets us (cloud integrators) to be assured that uncurated glusterfs access is prevented, but we need to allow execptions for the occasional external trusted entity. Furthermore, the one who knows of these (transient) execptions is (the admin of / some component of) the cloud, so their management should also happen from the cloud side. That led me to asking about "gluster volume set". (Anyway, the model case, turning of gluster NFS, is also managed from the cloud side by "gluster volume set".) Csaba _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
