hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6600) fsck -move fails in secured clusters.
Date Tue, 19 May 2015 20:51:00 GMT

    [ 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

View raw message