[ 
https://issues.apache.org/jira/browse/ACCUMULO-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135669#comment-15135669
 ] 

ASF GitHub Bot commented on ACCUMULO-4135:
------------------------------------------

Github user ctubbsii commented on the pull request:

    https://github.com/apache/accumulo/pull/67#issuecomment-180716575
  
    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: https://issues.apache.org/jira/browse/ACCUMULO-4135
>             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 following:
> For userA, what other users may userA "act" as and from what host(s) may 
> userA do this from.
> 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
(v6.3.4#6332)

Reply via email to