ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-14516) Failed to deploy Kerberized cluster via blueprint with custom principal name
Date Tue, 05 Jan 2016 03:51:39 GMT

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

Hudson commented on AMBARI-14516:
---------------------------------

SUCCESS: Integrated in Ambari-branch-2.2 #137 (See [https://builds.apache.org/job/Ambari-branch-2.2/137/])
AMBARI-14516. Failed to deploy Kerberized cluster via blueprint with (rlevas: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=bcfec2d814f739c2e7dffb60c3b56df329ec7fb4])
* ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalType.java
* ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostKerberosIdentityResourceProvider.java
* ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalDescriptor.java
* ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalDescriptorTest.java


> 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 smokeuser9jJevBQAYGQWnRkuapSEp@EXAMPLE.COM, 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)

Mime
View raw message