[Gluster-users] One Volume Per User - Possible with Gluster?

[Joshua Hawn]

I'm okay with just using one volume for everyone. In our current storage
solution, we use what it calls 'volumes' to manage quotas, but Gluster
allows directory level quotas which would satisfy our need.

I also forgot to mention that our users are not POSIX users. Our current
storage solution uses ACLs and authentication tokens for managing access.
It would be great if Gluster had a similar way for clients to access a
directory based on their authentication token, rather than UNIX file
permissions.


On Tue, Jul 2, 2013 at 8:20 PM, Jay Vyas <jayunit100 at gmail.com> wrote:

> Hmmm... but given that glusters fuse client is posix compliant, can't you
> just create a single volume and use a customized umask setup on user-named
> subdirectories in that volume to mimic this behaviour?
>
> On Jul 2, 2013, at 7:25 PM, Joshua Hawn <josh at picloud.com> wrote:
>
> I've been looking into using Gluster to replace a system that we currently
> use for storing data for several thousand users. With our current networked
> file system, each user can create volumes and only that user has access to
> their volumes with authentication.
>
> I see that Gluster also offers a username/password auth system, which is
> great, but there are several issues about it that bother me:
>
> [1] Currently all the authentication related information is passed
> un-encrypted over the network from client to server.
> [2] Currently each volume is managed as a separate process on the server.
>
> [1] is a major security issue for me and [2] is a major scalablity issue.
>
> Are either of these issues going to be fixed in the next release or are
> there any alternatives that Gluster offers? Also, is the authentication
> layer only used by the Gluster FUSE client or is it possible with NFS or
> CIFS?
>
> I've also wondered if Gluster can support authentication on a
> sub-directory level? If not, how complicated would it be to modify the
> source code to enable it? This would enable us to go around the
> one-process-per-volume issue.
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130703/2f2b8df0/attachment.html>