[Gluster-users] Dose Gluster 3.1 support authorisation control and how to do
HU Zhong
hz02ruc at gmail.com
Mon Jan 10 03:36:00 UTC 2011
Hi, Cheng
I think you did the configuration in the wrong place. Instead of
/etc/glusterd/nfs/nfs-server.vol, you need to modify files
under /etc/glusterd/vols/.
As a simple example, consider a one-server-one-client system, both
server and client are one machine(localhost, ip:192.168.4.112), and
export directory /home/huz/share for sharing, the client wants to mount
it on /home/huz/mnt.
if i modify default
configuration /etc/glusterd/vols/testvol/testvol.192.168.4.112.home-huz-share.vol
from
......
26 volume testvol-server
27 type protocol/server
28 option transport-type tcp
29 option auth.addr./home/huz/share.allow *
30 subvolumes /home/huz/share
31 end-volume
to
......
26 volume testvol-server
27 type protocol/server
28 option transport-type tcp
29 option auth.addr./home/huz/share.reject *
30 subvolumes /home/huz/share
31 end-volume
the mount command will fail:
$sudo mount -o mountproto=tcp -t nfs localhost:/testvol /home/huz/mnt
mount.nfs: mounting localhost:/testvol failed, reason given by server:
No such file or directory
and the log shows that the authentication error.
11-01-10 11:09:58.203600] E
[client-handshake.c:786:client_setvolume_cbk] testvol-client-0:
SETVOLUME on remote-host failed: Authentication failed
change "reject" to "allow", the mount operation will be ok.
you can configure you own ip rule. As for how to use ip auth and
usrname/password auth, you can check the attachment. It's a
documentation file under the directory "doc" of glusterfs src project.
On Sun, 2011-01-09 at 22:31 +0800, 第二信箱 wrote:
> Hi, HU:
> Thanks for your help.
>
> I have the following environment:
> Gluster 3.1.1
> Volume Name: gluster-volume
> Type: Distributed-Replicate
> Status: Started
> Number of Bricks: 2 x 2 = 4
> Transport-type: tcp
> Bricks:
> Brick1: gluster1:/mnt/gluster1
> Brick2: gluster2:/mnt/gluster2
> Brick3: gluster3:/mnt/gluster3
> Brick4: gluster4:/mnt/gluster4
>
>
> I want to use authenticate module by your suggestion.
> The way I used below:
> 1. Stop Volume
> 2. Edit /etc/glusterd/nfs/nfs-server.vol on Brick1(Gluster1)
> 3. Modify and Add From
> volume nfs-server
> type nfs/server
> option nfs.dynamic-volumes on
> option rpc-auth.addr.gluster-volume.allow *
> option nfs3.gluster-volume.volume-id 907941d9-6950-425b-
> b3d5-4e43dd420d9e
> subvolumes gluster-volume
> end-volume
>
> to
>
> volume nfs-server
> type nfs/server
> option nfs.dynamic-volumes on
> option rpc-auth.addr.gluster-volume.allow 10.18.14.1
> option auth.addr.gluster-volume.allow 10.18.14.1
> option nfs3.gluster-volume.volume-id
> 907941d9-6950-425b-b3d5-4e43dd420d9e
> subvolumes gluster-volume
> end-volume
>
> 4.Start Volume
>
> --> But I still be able to mount volume from 10.18.14.2 by NFS.
>
> Anything I missed or be wrong?
>
> And I find
>
> A. After I started volume , nfs-server.vol was initialed to option
> rpc-auth.addr.gluster-volume.allow * .
> B. 4 nodes all have /etc/glusterd/nfs/nfs-server.vol , Should I Edit
> every .vol file on 4 nodes?
>
>
>
>
>
>
> -----Original message-----
> From:HU Zhong <hz02ruc at gmail.com>
> To:wei.cheng at m2k.com.tw
> Cc:gluster-users <gluster-users at gluster.org>
> Date:Fri, 07 Jan 2011 21:17:14 +0800
> Subject:Re: [Gluster-users] Dose Gluster 3.1 support authorisation
> control and how to do
>
> Hi, Cheng
>
> There are 2 types of authenticate module that you can config:
> 1. IP address
> 2. login user/password
>
> please check this site:
> http://www.gluster.com/community/documentation/index.php/Translators/protocol/server
>
>
> On Fri, 2011-01-07 at 17:07 +0800, 第二信箱 wrote:
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>
>
-------------- next part --------------
* Authentication is provided by two modules addr and login. Login based authentication uses username/password from client for authentication. Each module returns either ACCEPT, REJCET or DONT_CARE. DONT_CARE is returned if the input authentication information to the module is not concerned to its working. The theory behind authentication is that "none of the auth modules should return REJECT and atleast one of them should return ACCEPT"
* Currently all the authentication related information is passed un-encrypted over the network from client to server.
----------------------------------------------------------------------------------------------------
* options provided in protocol/client:
* for username/password based authentication:
option username <username>
option password <password>
* client can have only one set of username/password
* for addr based authentication:
* no options required in protocol/client. Client has to bind to privileged port (port < 1024 ) which means the process in which protocol/client is loaded has to be run as root.
----------------------------------------------------------------------------------------------------
* options provided in protocol/server:
* for username/password based authentication:
option auth.login.<brick>.allow [comma seperated list of usernames using which clients can connect to volume <brick>]
option auth.login.<username>.password <password> #specify password <password> for username <username>
* for addr based authentication:
option auth.addr.<brick>.allow [comma seperated list of ip-addresses/unix-paths from which clients are allowed to connect to volume <brick>]
option auth.addr.<brick>.reject [comma seperated list of ip-addresses/unix-paths from which clients are not allowed to connect to volume <brick>]
* negation operator '!' is used to invert the sense of matching.
Eg., option auth.addr.brick.allow !a.b.c.d #do not allow client from a.b.c.d to connect to volume brick
option auth.addr.brick.reject !w.x.y.z #allow client from w.x.y.z to connect to volume brick
* wildcard '*' can be used to match any ip-address/unix-path
----------------------------------------------------------------------------------------------------
* Usecases:
* username/password based authentication only
protocol/client:
option username foo
option password foo-password
option remote-subvolume foo-brick
protocol/server:
option auth.login.foo-brick.allow foo,who #,other users allowed to connect to foo-brick
option auth.login.foo.password foo-password
option auth.login.who.password who-password
* in protocol/server, dont specify ip from which client is connecting in auth.addr.foo-brick.reject list
****************************************************************************************************
* ip based authentication only
protocol/client:
option remote-subvolume foo-brick
* Client is connecting from a.b.c.d
protocol/server:
option auth.addr.foo-brick.allow a.b.c.d,e.f.g.h,i.j.k.l #, other ip addresses from which clients are allowed to connect to foo-brick
****************************************************************************************************
* ip and username/password based authentication
* allow only "user foo from a.b.c.d"
protocol/client:
option username foo
option password foo-password
option remote-subvolume foo-brick
protocol/server:
option auth.login.foo-brick.allow foo
option auth.login.foo.password foo-password
option auth.addr.foo-brick.reject !a.b.c.d
* allow only "user foo" from a.b.c.d i.e., only user foo is allowed from a.b.c.d, but anyone is allowed from ip addresses other than a.b.c.d
protocol/client:
option username foo
option password foo-password
option remote-subvolume foo-brick
protocol/server:
option auth.login.foo-brick.allow foo
option auth.login.foo.password foo-password
option auth.addr.foo-brick.allow !a.b.c.d
* reject only "user shoo from a.b.c.d"
protcol/client:
option remote-subvolume shoo-brick
protocol/server:
# observe that no "option auth.login.shoo-brick.allow shoo" given
# Also other users from a.b.c.d have to be explicitly allowed using auth.login.shoo-brick.allow ...
option auth.addr.shoo-brick.allow !a.b.c.d
* reject only "user shoo" from a.b.c.d i.e., user shoo from a.b.c.d has to be rejected.
* same as reject only "user shoo from a.b.c.d" above, but rules have to be added whether to allow ip addresses (and users from those ips) other than a.b.c.d
****************************************************************************************************
* ip or username/password based authentication
* allow user foo or clients from a.b.c.d
protocol/client:
option remote-subvolume foo-brick
protocol/server:
option auth.login.foo-brick.allow foo
option auth.login.foo.password foo-password
option auth.addr.foo-brick.allow a.b.c.d
* reject user shoo or clients from a.b.c.d
protocol/client:
option remote-subvolume shoo-brick
protocol/server:
option auth.login.shoo-brick.allow <usernames other than shoo>
#for each username mentioned in the above <usernames other than shoo> list, specify password as below
option auth.login.<username other than shoo>.password password
option auth.addr.shoo-brick.reject a.b.c.d
More information about the Gluster-users
mailing list