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

Hadoop QA commented on AMBARI-14516:
------------------------------------

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12779971/AMBARI-14516_trunk_01.patch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-server.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/4741//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/4741//console

This message is automatically generated.

> Failed to deploy Kerberized cluster via blueprint with custom principal name
> ----------------------------------------------------------------------------
>
>                 Key: AMBARI-14516
>                 URL: https://issues.apache.org/jira/browse/AMBARI-14516
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.2.1
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Critical
>              Labels: kerberos_descriptor
>             Fix For: 2.2.1
>
>         Attachments: AMBARI-14516_branch-2.2_01.patch, 
> AMBARI-14516_branch-rbac-sso_01.patch, AMBARI-14516_trunk_01.patch
>
>
> Failed to deploy Kerberized cluster via Blueprint with custom principal name 
> set in Kerberos descriptor declared in _Cluster Creation Template_ like 
> {code}
> ...
>   "security": {
>     "type": "KERBEROS",
>     "kerberos_descriptor": {
>       "identities": [
>         {
>           "name": "smokeuser",
>           "principal": {
>             "value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"                
>         
>           }
>         }
>       ]
>     }
>   },
> ...
> {code}
> The following error (shown in ambari-server.log) was encountered while the 
> cluster was being built: 
> {noformat}
> Failed to create keytab for [email protected], 
> missing cached file
> {noformat}
> h3. Cause
> This was caused because the Kerberos descriptor in the _Blueprint_ or 
> _Cluster Creation Template_ did not declare the type property of the 
> principal being updated.  This caused the logic in Ambari to assume the 
> principal was a _service_ principal rather than a _user_ (or headless) 
> principal.  Because of this, when merging the updates to the default Kerberos 
> descriptor (from the stack), the {{smokeuser}} principal type was changed 
> _user_ to _service_.  Thus it was skipped over when the _Blueprints_ process 
> executed the phase to ensure (and cache) headless identities.  
> The bug is in the logic parsing the Kerberos descriptor.  By not specifying a 
> principal type, the logic assumes the principal type is _service_; however in 
> this case, the principal type needs to be {{null}}, so that when the 
> user-specified Kerberos descriptor is merged with the default Kerberos 
> descriptor, the default principal type is not changed. 
> *NOTE:* This is not limited to _Blueprints_, the issue will cause issues if 
> the specified Kerberos descriptor artifact is missing {{principal/type}} 
> properties as well.  See [Set the Kerberos 
> Descriptor|https://cwiki.apache.org/confluence/display/AMBARI/Automated+Kerberizaton#AutomatedKerberizaton-SettheKerberosDescriptor]
> h3. Solution
> Change the logic it the Kerberos descriptor parser to allow for the principal 
> type to be {{null}}. Handle this value being {{null}} by consumers of this 
> data such that {{null}} indicates the default value of {{service}}. This will 
> keep the current behavior consistent, and also allow for the merging facility 
> to properly merge principal updates - like changing the principal name 
> pattern without needing to specify the principal type as well. 
> h3. Workaround
> Explicitly set the {{type}} property of _user_ (or headless) principals in 
> the Kerberos descriptor:
> {code}
> ...
>   "security": {
>     "type": "KERBEROS",
>     "kerberos_descriptor": {
>       "identities": [
>         {
>           "name": "smokeuser",
>           "principal": {
>             "type" : "USER",
>             "value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"                
>         
>           }
>         }
>       ]
>     }
>   },
> ...
> {code}



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

Reply via email to