[
https://issues.apache.org/jira/browse/HDFS-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551195#comment-14551195
]
Chris Nauroth commented on HDFS-6600:
-------------------------------------
Hello [~krish.dey]. Thank you for taking up this long-standing issue.
I'm curious if this can work by using
{{UserGroupInformation.getLoginUser().doAs(...)}} without re-login from the
keytab. The process was already logged in as the NameNode principal during
NameNode startup, so I'd expect this to work. Have you tried testing with the
{{SecurityUtil#login}} line removed?
This patch is significantly larger because of reformatting changes. Thank you
for cleaning up the code, but could you please omit reformatting changes from
this patch? That helps reviewers focus on the logic changes. If you'd still
like to contribute clean-up work, then that would be welcome on a separate jira.
Longer term, I really wonder if fsck would benefit from having a private API
that simply reassociates blocks to a new path/inode. This would be something
like {{concat}}, except instead of working on a source file path/inode, it
would work on a source set of blocks. It would be a pure metadata operation,
so we wouldn't pay the network bandwidth cost of copying file content.
> fsck -move fails in secured clusters.
> -------------------------------------
>
> Key: HDFS-6600
> URL: https://issues.apache.org/jira/browse/HDFS-6600
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security, tools
> Affects Versions: 3.0.0, 2.4.0
> Reporter: Chris Nauroth
> Assignee: Krish Dey
> Labels: BB2015-05-TBR
> Attachments: HDFS-6600.1.PATCH
>
>
> In a secured cluster, running hdfs fsck -move fails. When trying to move the
> recovered blocks to lost+found, fsck tries to start using a DFSClient, but it
> doesn't have the credentials to authenticate that client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
