On Tue, Jan 27, 2015 at 08:29:49PM +0000, Csaba Henk wrote:
> 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).
Ok.
> 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.
The High-Availability NFS-Ganesha design puts the NFS-Ganesha service in
the trusted storage pool, possibly on the servers hosting bricks. Maybe
you can comment on why this is not suitable or wished for in your
environment? This design basically swaps Gluster/NFS for NFS-Ganesha.
http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha
> 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".)
I'm not sure if you're talking about this?
http://www.gluster.org/community/documentation/index.php/Features/Gluster_CLI_for_ganesha
At the moment, I think that also assumes the NFS-Ganesha service is
running inside the trusted storage pool. If you need any of those
functions available outside of the trusted storage pool, get in touch
with the feature owners and keep the gluster-devel list on CC.
Thanks,
Niels
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
