You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@falcon.apache.org by "Balu Vellanki (JIRA)" <ji...@apache.org> on 2016/04/22 01:51:12 UTC

[jira] [Resolved] (FALCON-1916) Allow RM principal to be specified in Cluster entity

     [ https://issues.apache.org/jira/browse/FALCON-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Balu Vellanki resolved FALCON-1916.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: trunk

Issue resolved by pull request 111
[https://github.com/apache/falcon/pull/111]

> Allow RM principal to be specified in Cluster entity 
> -----------------------------------------------------
>
>                 Key: FALCON-1916
>                 URL: https://issues.apache.org/jira/browse/FALCON-1916
>             Project: Falcon
>          Issue Type: Bug
>          Components: common
>         Environment: secure cluster
>            Reporter: Venkat Ranganathan
>            Assignee: Venkat Ranganathan
>             Fix For: trunk
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When we define cluster entities where clusters are in different kerberos realms with cross-realm trust setup (or the auth to local rules for RM varies in different clusters),  we need to explicitly define the RM principal (like NN principal) so that the cluster entity can be validated and used.
> For example, if Falcon server is  in a cluster using REALM A and the RM being accessed is in REALM B, the Falcon server will try to use the principal for the RM as rm/_HOST@A instead of rm/_HOST@B which is the valid realm, which can result in exceptions like below
> {quote}
> 2016-04-01 11:01:16,870 WARN - .... POST//entities/submit/cluster ~ Exception encountered while connecting to the server : (Client:680)
> java.lang.IllegalArgumentException: Server has invalid Kerberos principal: rm/host@realm
> at org.apache.hadoop.security.SaslRpcClient.getServerPrincipal(SaslRpcClient.java:334)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)