Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1103050

Summary: nfs: reset command does not alter the result for nfs options earlier set
Product: [Community] GlusterFS Reporter: santosh pradhan <spradhan>
Component: rpcAssignee: santosh pradhan <spradhan>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: mainlineCC: gluster-bugs, saujain, vagarwal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: glusterfs-3.5.2beta1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1102647 Environment:
Last Closed: 2014-07-31 11:43:04 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:
Bug Depends On: 1102647    
Bug Blocks:    

Description santosh pradhan 2014-05-30 07:06:43 UTC
+++ This bug was initially created as a clone of Bug #1102647 +++

Description of problem:
Set values for the options nfs.rpc-auth-allow and nfs.rpc-auth-reject.
Things worked as expected.
Remember, the values are set using the command gluster volume set

Issue happened once the gluster volume reset was used to bring the options back to default.
This time the things didn't work as exepected.


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

How reproducible:
always

Steps to Reproduce:
1. create a volume of 6x2, start it
2. gluster volume set <vol-name> nfs.rpc-auth-allow "host1"
3. gluster volume set <vol-name> nfs.rpc-auth-reject "host2"
4. try mount from host1 and host2
   result ---- host1(PASS) and host2(FAILS) --- as expected
5. gluster volume reset <vol-name>
6. try mount from host1 and host2

Actual results:
host1 the mount is a PASS --- as expected.
host2 the mount is a FAIL ---- for step6 this is unexpected as the options are reset now
result from host2,
[root@konsoul ~]# mount -t nfs -o vers=3 10.70.37.62:/dist-rep /mnt/nfs-test
mount.nfs: access denied by server while mounting 10.70.37.62:/dist-rep

gluster volume info,
[root@nfs2 ~]# gluster volume info
 
Volume Name: dist-rep
Type: Distributed-Replicate
Volume ID: 479f93d9-ed9b-4097-8d95-7a0657ee912f
Status: Started
Snap Volume: no
Number of Bricks: 6 x 2 = 12
Transport-type: tcp
Bricks:
Brick1: 10.70.37.62:/bricks/d1r1
Brick2: 10.70.37.215:/bricks/d1r2
Brick3: 10.70.37.44:/bricks/d2r1
Brick4: 10.70.37.201:/bricks/d2r2
Brick5: 10.70.37.62:/bricks/d3r1
Brick6: 10.70.37.215:/bricks/d3r2
Brick7: 10.70.37.44:/bricks/d4r1
Brick8: 10.70.37.201:/bricks/d4r2
Brick9: 10.70.37.62:/bricks/d5r1
Brick10: 10.70.37.215:/bricks/d5r2
Brick11: 10.70.37.44:/bricks/d6r1
Brick12: 10.70.37.201:/bricks/d6r2
Options Reconfigured:
features.quota: off


Expected results:
step6 mounts should PASS.

Additional info:

--- Additional comment from RHEL Product and Program Management on 2014-05-29 07:29:10 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from santosh pradhan on 2014-05-29 15:28:42 EDT ---



Good catch. 

Could you try with a host3 which was not in allow/reject list?

--- Additional comment from Saurabh on 2014-05-30 01:26:00 EDT ---

yeah the mount works on the host3,

[root@rhsauto009 ~]# showmount -e 10.70.37.62
Export list for 10.70.37.62:
/dist-rep *
[root@rhsauto009 ~]# mkdir /mnt/nfs-test
[root@rhsauto009 ~]# mount -t nfs -o vers=3 10.70.37.62:/dist-rep /mnt/nfs-test
[root@rhsauto009 ~]# ls /mnt/nfs-test
file  file1
[root@rhsauto009 ~]#

Comment 1 Anand Avati 2014-05-30 07:19:52 UTC
REVIEW: http://review.gluster.org/7931 (rpc: Reconfigure() does not work for auth-reject) posted (#1) for review on master by Santosh Pradhan (spradhan)

Comment 2 Anand Avati 2014-06-09 15:21:39 UTC
COMMIT: http://review.gluster.org/7931 committed in master by Anand Avati (avati) 
------
commit 211785f29904995324bfd3c7fa4b35a498bf632a
Author: Santosh Kumar Pradhan <spradhan>
Date:   Fri May 30 12:37:23 2014 +0530

    rpc: Reconfigure() does not work for auth-reject
    
    Problem:
    If volume is set for rpc-auth.addr.<volname>.reject with value
    as "host1", ideally the NFS mount from "host1" should FAIL. It
    works as expected. But when the volume is RESET, then previous
    value set for auth-reject should go off, and further NFS mount
    from "host1" should PASS. But it FAILs because of stale value
    in dict for key "rpc-auth.addr.<volname>.reject".
    
    It does not impact rpc-auth.addr.<volname>.allow key because,
    each time NFS volfile gets generated, allow key ll have "*"
    as default value. But reject key does not have default value.
    
    FIX:
    Delete the OLD value for key irrespective of anything. Add
    NEW value for the key, if and only if that is SET in the
    reconfigured new volfile.
    
    Signed-off-by: Santosh Kumar Pradhan <spradhan>
    
    Change-Id: Ie80bd16cd1f9e32c51f324f2236122f6d118d860
    BUG: 1103050
    Reviewed-on: http://review.gluster.org/7931
    Reviewed-by: Niels de Vos <ndevos>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Rajesh Joseph <rjoseph>
    Reviewed-by: Anand Avati <avati>

Comment 3 Anand Avati 2014-06-10 05:16:26 UTC
REVIEW: http://review.gluster.org/8022 (rpc: Reconfigure() does not work for auth-reject) posted (#1) for review on release-3.5 by Santosh Pradhan (spradhan)

Comment 4 Anand Avati 2014-06-24 16:59:27 UTC
COMMIT: http://review.gluster.org/8022 committed in release-3.5 by Niels de Vos (ndevos) 
------
commit 55880a7168d5b7ef85f6de3b1870634156e6ddfa
Author: Santosh Kumar Pradhan <spradhan>
Date:   Tue Jun 10 10:43:28 2014 +0530

    rpc: Reconfigure() does not work for auth-reject
    
    Problem:
    If volume is set for rpc-auth.addr.<volname>.reject with value
    as "host1", ideally the NFS mount from "host1" should FAIL. It
    works as expected. But when the volume is RESET, then previous
    value set for auth-reject should go off, and further NFS mount
    from "host1" should PASS. But it FAILs because of stale value
    in dict for key "rpc-auth.addr.<volname>.reject".
    
    It does not impact rpc-auth.addr.<volname>.allow key because,
    each time NFS volfile gets generated, allow key ll have "*"
    as default value. But reject key does not have default value.
    
    FIX:
    Delete the OLD value for key irrespective of anything. Add
    NEW value for the key, if and only if that is SET in the
    reconfigured new volfile.
    
    Upstream review:  http://review.gluster.org/7931
    
    Change-Id: I9d1cb37002aad978a3a59e4b45b42d881d0d20e3
    BUG: 1103050
    Signed-off-by: Santosh Kumar Pradhan <spradhan>
    Reviewed-on: http://review.gluster.org/8022
    Reviewed-by: Raghavendra G <rgowdapp>
    Reviewed-by: Niels de Vos <ndevos>
    Tested-by: Gluster Build System <jenkins.com>

Comment 5 Niels de Vos 2014-07-21 15:41:33 UTC
The first (and last?) Beta for GlusterFS 3.5.2 has been released [1]. Please verify if the release solves this bug report for you. In case the glusterfs-3.5.2beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED.

Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution.

[1] http://supercolony.gluster.org/pipermail/gluster-devel/2014-July/041636.html
[2] http://supercolony.gluster.org/pipermail/gluster-users/

Comment 6 Niels de Vos 2014-07-31 11:43:04 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.5.2, please reopen this bug report.

glusterfs-3.5.2 has been announced on the Gluster Users mailinglist [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://supercolony.gluster.org/pipermail/gluster-users/2014-July/041217.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user