[
https://issues.apache.org/jira/browse/HDFS-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875330#comment-13875330
]
Brandon Li commented on HDFS-5767:
----------------------------------
[~yzhangal], thanks for bringing up this question, and sorry for the late reply.
It's possible that the name-id mappings are inconsistent in multiple database
locations, local operating system files(e.g. /etc/passwd), DNS, NIS and LDAP.
The Name Service Switch (NSS) is supposed to be configured to resolve most of
the conflicts.
For example, suppose we have user "hadoop" with id 123 in "/etc/passwd" but a
different id 456 in LDAP. Usually the administrator configures NSS to have a
searching order (e.g., search LDAP first and then local files), and let NSS
return the first found match.
NFS gateway currently uses shell command (e.g., "getent passwd | cut -d: -f1,3"
in IdUserGroup.java) to get the mapping. The shell command internally invokes
NSS service to get the name-id mapping.
As we noticed in the field, it's possible to see non-unique mappings as you
mentioned. Therefore, we print the comments to make it easier for the users to
understand the issue and remove the non-unique mapping. The non-unique mapping
is usually a problem for UNIX systems and should be fixed anyway.
> Nfs implementation assumes userName userId mapping to be unique, which is not
> true sometimes
> --------------------------------------------------------------------------------------------
>
> Key: HDFS-5767
> URL: https://issues.apache.org/jira/browse/HDFS-5767
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: nfs
> Affects Versions: 2.3.0
> Environment: With LDAP enabled
> Reporter: Yongjun Zhang
>
> I'm seeing that the nfs implementation assumes unique <userName, userId> pair
> to be returned by command "getent paswd". That is, for a given userName,
> there should be a single userId, and for a given userId, there should be a
> single userName. The reason is explained in the following message:
> private static final String DUPLICATE_NAME_ID_DEBUG_INFO = "NFS gateway
> can't start with duplicate name or id on the host system.\n"
> + "This is because HDFS (non-kerberos cluster) uses name as the only
> way to identify a user or group.\n"
> + "The host system with duplicated user/group name or id might work
> fine most of the time by itself.\n"
> + "However when NFS gateway talks to HDFS, HDFS accepts only user and
> group name.\n"
> + "Therefore, same name means the same user or same group. To find the
> duplicated names/ids, one can do:\n"
> + "<getent passwd | cut -d: -f1,3> and <getent group | cut -d: -f1,3>
> on Linux systms,\n"
> + "<dscl . -list /Users UniqueID> and <dscl . -list /Groups
> PrimaryGroupID> on MacOS.";
> This requirement can not be met sometimes (e.g. because of the use of LDAP)
> Let's do some examination:
> What exist in /etc/passwd:
> $ more /etc/passwd | grep ^bin
> bin:x:2:2:bin:/bin:/bin/sh
> $ more /etc/passwd | grep ^daemon
> daemon:x:1:1:daemon:/usr/sbin:/bin/sh
> The above result says userName "bin" has userId "2", and "daemon" has userId
> "1".
>
> What we can see with "getent passwd" command due to LDAP:
> $ getent passwd | grep ^bin
> bin:x:2:2:bin:/bin:/bin/sh
> bin:x:1:1:bin:/bin:/sbin/nologin
> $ getent passwd | grep ^daemon
> daemon:x:1:1:daemon:/usr/sbin:/bin/sh
> daemon:x:2:2:daemon:/sbin:/sbin/nologin
> We can see that there are multiple entries for the same userName with
> different userIds, and the same userId could be associated with different
> userNames.
> So the assumption stated in the above DEBUG_INFO message can not be met here.
> The DEBUG_INFO also stated that HDFS uses name as the only way to identify
> user/group. I'm filing this JIRA for a solution.
> Hi [~brandonli], since you implemented most of the nfs feature, would you
> please comment?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
