[
https://issues.apache.org/jira/browse/HBASE-14580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14952241#comment-14952241
]
Nicolas Liochon commented on HBASE-14580:
-----------------------------------------
> I think it's just a log spam issue – see HADOOP-12450.
Oh, yeah. Thanks for the pointer.
> Instead of hard-coding the config values, can you use
> User.isHBaseSecurityEnabled(c)?
Yes, you're right. I updated the patch.
> The username suffixes were fed into the data dirs used by each DN/RS's for a
> "distributed" minicluster setup
> So, as I understand it, that would not be an issue here are Kerberos would
> only be supported with a single node setup?
I'm not sure here: I don't see why the user name is needed in the data dirs.
But in any case, this patch does not break anything, as the suffix approach
clashes with the kerberos realm...
> As Gary said, this is harmless unless you're test depends on a valid group
> membership.
Thanks.
Thanks for the reviews, all. I will commit the v2 if hadoop-qa passes with the
v2.
> Make the HBaseMiniCluster compliant with Kerberos
> -------------------------------------------------
>
> Key: HBASE-14580
> URL: https://issues.apache.org/jira/browse/HBASE-14580
> Project: HBase
> Issue Type: Improvement
> Components: security, test
> Affects Versions: 2.0.0
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Fix For: 2.0.0
>
> Attachments: patch-14580.v1.patch
>
>
> Whne using MiniKDC and the minicluster in a unit test, there is a conflict
> causeed by HBaseTestingUtility:
> {code}
> public static User getDifferentUser(final Configuration c,
> final String differentiatingSuffix)
> throws IOException {
> // snip
> String username = User.getCurrent().getName() +
> differentiatingSuffix; <==================== problem here
> User user = User.createUserForTesting(c, username,
> new String[]{"supergroup"});
> return user;
> }
> {code}
> This creates users like securedUser/localh...@example.com.hfs.0, and this
> does not work.
> My fix is to return the current user when Kerberos is set. I don't think that
> there is another option (any other opinion?). However this user is not in a
> group so we have logs like 'WARN [IPC Server handler 9 on 61366]
> security.UserGroupInformation (UserGroupInformation.java:getGroupNames(1521))
> - No groups available for user securedUser' I'm not sure of its impact.
> [~apurtell], what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
