[
https://issues.apache.org/jira/browse/HDFS-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212844#comment-14212844
]
Yongjun Zhang commented on HDFS-7146:
-------------------------------------
HI [~brandonli],
Thanks a lot for the review and comments!
I have a few questions to clarify:
{quote}
1. it doesn’t seem to be necessary to introduce defaultStaticIdMappingFile
{quote}
The defaulyStaticIdMappingFile was introduced in the HADOOP-11195, and I
actually have removed it in rev 004. Would you please indicate the place you
were looking at?
{quote}
2. Do we need checkSupportedPlatform()? We don’t have to limit the platform
with only linux and mac. Some other UNIX flavors might also be able to run the
NFS server. We could do the follow:
if (Shell.Mac)
{ // mac command }
else
{ // linux command for everything else }
{quote}
About checkSupportedPlatform, I simply followed the existing implementation ({{
if (!OS.startsWith("Linux") && !OS.startsWith("Mac"))}}), which says only mac
and linux are supported. Relaxing the platform support is a different issue to
solve and it seems deserving a separate jira, what do you think?
{quote}
3. do we still need constructFullMapAtInit since it’s always false?
{quote}
I introduced this for testing purpose. If you look at the new test I
introduced, it's first called with "true" to create a reference (refIdMapping).
That's why I tagged constructor with @VisibleForTesting. Does this sound ok to
you?
Thanks again!
> NFS ID/Group lookup requires SSSD enumeration on the server
> -----------------------------------------------------------
>
> Key: HDFS-7146
> URL: https://issues.apache.org/jira/browse/HDFS-7146
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: nfs
> Affects Versions: 2.6.0
> Reporter: Yongjun Zhang
> Assignee: Yongjun Zhang
> Attachments: HDFS-7146.001.patch, HDFS-7146.002.allIncremental.patch,
> HDFS-7146.003.patch, HDFS-7146.004.patch
>
>
> The current implementation of the NFS UID and GID lookup works by running
> 'getent passwd' with an assumption that it will return the entire list of
> users available on the OS, local and remote (AD/etc.).
> This behaviour of the command is advised to be and is prevented by
> administrators in most secure setups to avoid excessive load to the ADs
> involved, as the # of users to be listed may be too large, and the repeated
> requests of ALL users not present in the cache would be too much for the AD
> infrastructure to bear.
> The NFS server should likely do lookups based on a specific UID request, via
> 'getent passwd <UID>', if the UID does not match a cached value. This reduces
> load on the LDAP backed infrastructure.
> Thanks [~qwertymaniac] for reporting the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
