Bug 1575983 - Erratic behavior while using nfs.rpc-auth-allow(reject) options with hostname
Summary: Erratic behavior while using nfs.rpc-auth-allow(reject) options with hostname
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gluster-nfs
Version: rhgs-3.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Niels de Vos
QA Contact: Manisha Saini
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 13:31 UTC by Vinayak Papnoi
Modified: 2018-05-18 08:42 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-18 08:42:57 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Vinayak Papnoi 2018-05-08 13:31:19 UTC
Description of problem:
=======================

With a fresh setup, setting the volume option "nfs.rpc-auth-allow" or "nfs.rpc-auth-reject" with hostname is behaving erratically.

The behavior in my observation was as follows:

1. nfs.rpc-auth-allow "hostname" : rejects the client in the hostname from mounting via nfs.

2. nfs.rpc-auth.reject "hostname" : allows the client in the hostname to mount via nfs.

3. After enabling nfs.addr-namelookup (off by default):
    nfs.rpc-auth-allow "hostname" : allows the client in the hostname to mount via nfs.
    nfs.rpc-auth-reject "hostname" : rejects the client in the hostname from mounting via nfs.

4. After resetting nfs.addr-namelookup (off by default):
    behavior is the same as in #3 whereas it should be same as #1 and #2

5. A restart of nfs server on all nodes also yields the same outcome as #4


Version-Release number of selected component (if applicable):
=============================================================

glusterfs-3.12.2-8.el7rhgs.x86_64


How reproducible:
=================

Always


Steps to Reproduce:
===================

1. Set the volume option "nfs.rpc-auth-allow" and/or "nfs.rpc-auth-reject" with the hostname
2. Try mounting the volume on the client whose hostname is provided in the auth options
3. Set the nfs.addr-namelookup option to "on"
4. Repeat step 2
5. Reset the nfs.addr-namelookup option
6. Repeat step 1


Actual results:
===============

As explained in the description.


Expected results:
=================

With the nfs.addr-namelookup option off, nfs auth options do not work as intended. But with nfs.addr-namelookup option on, nfs auth options should work as expected. Although nfs.addr-namelookup option was set "on", after resetting that option, the nfs auth options should go back to not work as intended.


Additional info:
================

Providing a hostname which is different than what is used after setting the option nfs.addr-namelookup "on" and then resetting it also seems to resolve the new hostname.

Comment 2 Sunil Kumar Acharya 2018-05-11 09:52:11 UTC
Please share the RHGS-3.4.0 triage results.

Comment 3 Niels de Vos 2018-05-11 10:06:46 UTC
(In reply to Sunil Kumar Acharya from comment #2)
> Please share the RHGS-3.4.0 triage results.

I guess this has been triaged as part of the NFS-team? Maybe Jiffin can comment on it.


Note You need to log in before you can comment on or make changes to this bug.