Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 23 Jul 2014 21:52:39 +0000 (UTC)
From: "Brandon Li (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12728726.1405982534863.32862.1406152359192@arcas>
In-Reply-To: <JIRA.12728726.1405982534863@arcas>
References: <JIRA.12728726.1405982534863@arcas>
Subject: [jira] [Commented] (HDFS-6717) Jira HDFS-5804 breaks default
 nfs-gateway behavior for unsecured config
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072422#comment-14072422 ] 

Brandon Li commented on HDFS-6717:
----------------------------------

With the fix in HDFS-5804, users don't have to use the same use to start NFS gateway and HDFS.

One should always specify the following two properties regardless the HDFS cluster is secure or not: hadoop.proxyuser.nfsserver.groups and hadoop.proxyuser.nfsserver.hosts. As pointed out in the user guide, "nfsserver" should be replace by the user who starts NFS gateway.

For secure HDFS cluster, it doesn't matter who starts NFS gateway. It's all about the user account in the keytab. In the above two properties, "nfsserver" should be replaced by the user in the keytab.

Uploaded a patch, which also fixed the rmax and wmax related descriptions. Also uploaded the generated html file for easy review.

> Jira HDFS-5804 breaks default nfs-gateway behavior for unsecured config
> -----------------------------------------------------------------------
>
>                 Key: HDFS-6717
>                 URL: https://issues.apache.org/jira/browse/HDFS-6717
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: nfs
>    Affects Versions: 2.4.0
>            Reporter: Jeff Hansen
>            Priority: Minor
>         Attachments: HDFS-6717.001.patch, HdfsNfsGateway.html
>
>
> I believe this is just a matter of needing to update documentation. As a result of https://issues.apache.org/jira/browse/HDFS-5804, the secure and unsecure code paths appear to have been merged -- this is great because it means less code to test. However, it means that the default unsecure behavior requires additional configuration that needs to be documented. 
> I'm not the first to have trouble following the instructions documented in http://hadoop.apache.org/docs/r2.4.0/hadoop-project-dist/hadoop-hdfs/HdfsNfsGateway.html
> I kept hitting a RemoteException with the message that hdfs user cannot impersonate root -- apparently under the old code, there was no impersonation going on, so the nfs3 service could and should be run under the same user id that runs hadoop (I assumed this meant the user id "hdfs"). However, with the new unified code path, that would require hdfs to be able to impersonate root (because root is always the local user that mounts a drive). The comments in jira hdfs-5804 seem to indicate nobody has a problem with requiring the nfsserver user to impersonate root -- if that means it's necessary for the configuration to include root as a user nfsserver can impersonate, that should be included in the setup instructions.
> More to the point, it appears to be absolutely necessary now to provision a user named "nfsserver" in order to be able to give that nfsserver ability to impersonate other users. Alternatively I think we'd need to configure hdfs to be able to proxy other users. I'm not really sure what the best practice should be, but it should be documented since it wasn't needed in the past.


--
This message was sent by Atlassian JIRA
(v6.2#6252)