Bug 915153

Summary: auth.allow fails to resolve hostname
Product: [Community] GlusterFS Reporter: vpshastry <vshastry>
Component: coreAssignee: Nagaprasad Sathyanarayana <nsathyan>
Status: CLOSED EOL QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: mainlineCC: admin, gluster-bugs, jdarcy, nsathyan, poelstra, rhinduja, rhs-bugs, smohan, spandura, ssampat, vbellur, wdh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 861932 Environment:
Last Closed: 2015-10-22 15:46:38 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: 861932    
Bug Blocks:    

Description vpshastry 2013-02-25 05:38:51 UTC
Description of problem:
---------------------------------------
When value of auth.allow is set to hostname of the client, mount fails. If auth.allow value is set to the IP address of the client, mount succeeds.

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

How reproducible:
Always reproducible

Steps to Reproduce:
1. Create a gluster volume
2. gluster volume set <vol_name> auth.allow <client-hostname>
3. Try to mount from the client, mount fails.
4. gluster volume set <vol_name> auth.allow <client-IP>
5. Try to mount from the client, mount succeeds.

The following is seen in the client logs - 
---------------------------------------
[2012-10-01 04:39:59.893031] I [client-handshake.c:1614:select_server_supported_programs] 0-automation-volume-distribute-client-1: Using Program GlusterFS 3.3.0rhs, Num (1298437), Version (330)
[2012-10-01 04:39:59.893589] W [client-handshake.c:1320:client_setvolume_cbk] 0-automation-volume-distribute-client-1: failed to set the volume (Permission denied)
[2012-10-01 04:39:59.893626] W [client-handshake.c:1346:client_setvolume_cbk] 0-automation-volume-distribute-client-1: failed to get 'process-uuid' from reply dict
[2012-10-01 04:39:59.893638] E [client-handshake.c:1352:client_setvolume_cbk] 0-automation-volume-distribute-client-1: SETVOLUME on remote-host failed: Authentication failed
[2012-10-01 04:39:59.893650] I [client-handshake.c:1437:client_setvolume_cbk] 0-automation-volume-distribute-client-1: sending AUTH_FAILED event
[2012-10-01 04:39:59.893668] E [fuse-bridge.c:4287:notify] 0-fuse: Server authenication failed. Shutting down.


The following is seen in the server logs - 
---------------------------------------

[2012-10-01 11:11:00.202623] E [authenticate.c:236:gf_authenticate] 0-auth: no authentication module is interested in accepting remote-client (null)
[2012-10-01 11:11:00.202642] E [server-handshake.c:582:server_setvolume] 0-automation-volume-distribute-server: Cannot authenticate client from rhs-client26.lab.eng.blr.redhat.com-18762-2012/10/01-09:47:04:593877-automation-volume-distribute-client-0-0 3.3.0rhsvirt1


Actual results:
Mount fails when auth.allow is set to hostname of client.

Expected results:
Mount should succeed when auth.allow is set to hostname of client.

Additional info:

--- Additional comment from csb sysadmin on 2013-01-16 00:22:22 EST ---

I would also request that you allow hostname wildcards in auth.allow as is allowed in /etc/exports for nfs, e.g. *.foo.baz.edu in auth.allow would do a reverse lookup on an incoming client ip and if it matches the hostname wildcard, e.g. if it happens to be bar.foo.baz.edu then it would be given access. This would seem to be a superset of this bug, so if you implement this functionality a static hostname would be easy.

--- Additional comment from vpshastry on 2013-02-08 01:49:08 EST ---

CHANGE http://review.gluster.com/4482 is on review. Also addressed above comment, wildcards for hostnames.

Comment 1 Anand Avati 2013-12-30 06:03:06 UTC
REVIEW: http://review.gluster.org/4482 (protocol/auth: Make server xlator consider hostnames for authentication) posted (#8) for review on master by Varun Shastry (vshastry)

Comment 4 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.