Bug 1048761

Summary:	nfs: sequence of using nfs.rpc-auth-reject and volume reset cmd, still mount fails on the client earlier rejected to mount a volume
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Saurabh <saujain>
Component:	glusterd	Assignee:	santosh pradhan <spradhan>
Status:	CLOSED DUPLICATE	QA Contact:	Sudhir D <sdharane>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	mzywusko, saujain, vagarwal, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-18 06:57:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Saurabh 2014-01-06 10:15:49 UTC

Description of problem:
Option nfs.rpc-auth-reject was used to prohibit a client(s) to mount a volume. 
So the volume mount fails on that prohibited client.
Now, a well known command called "gluster volume reset" is used to bring all the "volume set" variables back to default. 

Still the volume mount fails on the prohibited client, as the client is no more prohibited after using the "reset" command.

Version-Release number of selected component (if applicable):
glusterfs-3.4.0.53rhs-1.el6rhs.x86_64

How reproducible:
always

Steps to Reproduce:
1. create a volume, start it
2. set the option, nfs.addr-namelookup to "on"
3. set the ooption, nfs.rpc-auth-reject "client(s) to be rejected" 
4. try mount from the prohibited client
5. gluster volume reset <volume-name>
6. repeat step 4.

Actual results:
step4 --- works as expected, as it does not allow the prohibited client to mount the volume.

step 6 ---- fails, as mount operations still fails.

volume info after step 3, 

[root@quota5 ~]# gluster volume info dist-rep
 
Volume Name: dist-rep
Type: Distributed-Replicate
Volume ID: 4ee792db-48f0-463e-8ad1-d1507d161227
Status: Started
Number of Bricks: 6 x 2 = 12
Transport-type: tcp
Bricks:
Brick1: 10.70.35.219:/rhs/brick1/d1r1
Brick2: 10.70.35.108:/rhs/brick1/d1r2
Brick3: 10.70.35.191:/rhs/brick1/d2r1
Brick4: 10.70.35.144:/rhs/brick1/d2r2
Brick5: 10.70.35.219:/rhs/brick1/d3r1
Brick6: 10.70.35.108:/rhs/brick1/d3r2
Brick7: 10.70.35.191:/rhs/brick1/d4r1
Brick8: 10.70.35.144:/rhs/brick1/d4r2
Brick9: 10.70.35.219:/rhs/brick1/d5r1
Brick10: 10.70.35.108:/rhs/brick1/d5r2
Brick11: 10.70.35.191:/rhs/brick1/d6r1
Brick12: 10.70.35.144:/rhs/brick1/d6r2
Options Reconfigured:
nfs.rpc-auth-reject: rhsauto005.lab.eng.blr.redhat.com
nfs.rpc-auth-allow: rhsauto002.lab.eng.blr.redhat.com
nfs.addr-namelookup: on
features.quota: off

mount info after step4, 
[root@rhsauto005 ~]# mount -t nfs 10.70.35.219:dist-rep /mnt/nfs-test
mount.nfs: access denied by server while mounting 10.70.35.219:dist-rep


volume info after step5,
[root@quota5 ~]# gluster volume info dist-rep
 
Volume Name: dist-rep
Type: Distributed-Replicate
Volume ID: 4ee792db-48f0-463e-8ad1-d1507d161227
Status: Started
Number of Bricks: 6 x 2 = 12
Transport-type: tcp
Bricks:
Brick1: 10.70.35.219:/rhs/brick1/d1r1
Brick2: 10.70.35.108:/rhs/brick1/d1r2
Brick3: 10.70.35.191:/rhs/brick1/d2r1
Brick4: 10.70.35.144:/rhs/brick1/d2r2
Brick5: 10.70.35.219:/rhs/brick1/d3r1
Brick6: 10.70.35.108:/rhs/brick1/d3r2
Brick7: 10.70.35.191:/rhs/brick1/d4r1
Brick8: 10.70.35.144:/rhs/brick1/d4r2
Brick9: 10.70.35.219:/rhs/brick1/d5r1
Brick10: 10.70.35.108:/rhs/brick1/d5r2
Brick11: 10.70.35.191:/rhs/brick1/d6r1
Brick12: 10.70.35.144:/rhs/brick1/d6r2
Options Reconfigured:
features.quota: off


mount info after step6,
[root@rhsauto005 ~]# mount -t nfs 10.70.35.219:dist-rep /mnt/nfs-test
mount.nfs: access denied by server while mounting 10.70.35.219:dist-rep

Expected results:
step6----as after volume reset command, the volume mount should be allowed.

Additional info:

Comment 2 santosh pradhan 2014-01-30 10:22:23 UTC

This seems to be working as expected. Could you please recheck. I have tested with build 57.

Make sure that the hosts are n/w resolvable (getaddrinfo() should PASS) !

Comment 3 santosh pradhan 2014-06-18 06:57:40 UTC

The same issue is being worked/tracked on BZ 1102647. Lets close the issue as duplicate of BZ 1102647. Please reopen if you disagree. 

Thanks,
Santosh

*** This bug has been marked as a duplicate of bug 1102647 ***

Comment 4 Red Hat Bugzilla 2023-09-14 01:56:29 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days