accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4135) Change Kerberos impersonation configuration keys
Date Sat, 06 Feb 2016 07:57:39 GMT


ASF GitHub Bot commented on ACCUMULO-4135:

Github user ctubbsii commented on the pull request:
    Just looking at the documentation change, it does seem to me that separating into two
configuration options and avoiding the prefix matching to grab configs is a bit more intuitive,
and I'm also in favor of moving the special characters out of configuration keys, even if
it's a simple special character like '/'. I usually prefer my configuration keys to look like
variable identifiers (though, dot-separated is okay). I haven't looked at the implementation,
but the test coverage looks good.
    Do you think you should go ahead and make the old version deprecated, for eventual removal,
since the old way is kind of flawed and we don't really want to have to maintain multiple
ways to configure the same thing?

> Change Kerberos impersonation configuration keys
> ------------------------------------------------
>                 Key: ACCUMULO-4135
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.7.0
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.7.1, 1.8.0
> For the user impersonation support with Kerberos, we need to be able to represent the
> For userA, what other users may userA "act" as and from what host(s) may userA do this
> This was represented as the following in accumulo-site.xml:
> * {{<prefix>.userA.users}}=user1,user2,user3...
> * {{<prefix>.userA.hosts}}=fqdn1,fqdn2,fqdn3...
> Because we're dealing with Kerberos, "userA" is actually something like "primary/instance@REALM".
> I've recently found out that Ambari doesn't like this and apparently it would be prohibitively
difficult to change it there (urlencode, what?). I'll add some new configuration properties
here that change the structure so that there are options for users to configure this through
all deployment mechanisms.

This message was sent by Atlassian JIRA

View raw message