[Gluster-devel] Ability to turn off 'glusterfs' protocol

Deepak Shetty dpkshetty at gmail.com
Wed Jan 21 05:49:14 UTC 2015


Good point and I agree to the below.
So all we need here is a way to differentiate trusted Vs non-trusted
clients and fail GETSPEC if it comes from non-trusted client provided the
disable glusterfs protocol option has been set ?

On Wed, Jan 21, 2015 at 8:42 AM, Vijay Bellur <vbellur at redhat.com> wrote:

> On 01/19/2015 06:22 PM, Deepak Shetty wrote:
>
>> Hi All,
>>    I had opened this feature request sometime back
>> http://www.gluster.org/community/documentation/index.
>> php/Features/turn-off-glusterfs-proto-access
>>
>> I wanted to know what would be the right way to implement this ?
>>
>> The goal here is to have a volume set option to turn off glusterfs/fuse
>> protocol access
>> just like how we have it today for NFS ( volume set nfs.export-volumes
>> off)
>>
>> 1) Does GETSPEC allow passing the protocol being requested at mount, so
>> that glusterd can return success/failure and mount.gluster can error
>> accoridngly ?
>>
>> 2) Another way is to introduce another handshake after GETSPEC is
>> successfull, where client can request permission to mount using the said
>> protocol and glusterd returns success/failure based on the volume set
>> option being set or unset ?
>>
>> Thoughts ?
>>
>
> I think unconditionally disabling glusterfs protocol for trusted clients
> (clients local to the storage pool) also would not be ideal. An
> administrator might still want to access volumes through a trusted
> glusterfs client for maintenance, repair activities. Geo-replication, quota
> etc. do rely on the ability to access volumes from the trusted storage pool
> through the native glusterfs protocol for proper functioning.
>
> Given this, we could implement this feature by serving volfiles to only
> trusted clients in glusterd and fail requests from everywhere else if an
> option to disable glusterfs protocol has been set. This way all services
> accessing volumes locally from the trusted storage pool will continue to
> function without any problems.
>
> HTH,
> Vijay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150121/35f88799/attachment.html>


More information about the Gluster-devel mailing list