[
https://issues.apache.org/jira/browse/AMBARI-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405019#comment-15405019
]
Hadoop QA commented on AMBARI-17993:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12821704/AMBARI-17993_trunk_01.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8257//console
This message is automatically generated.
> Kerberos identity definitions in Kerberos descriptors should explicitly
> declare a reference
> -------------------------------------------------------------------------------------------
>
> Key: AMBARI-17993
> URL: https://issues.apache.org/jira/browse/AMBARI-17993
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.4.0
> Reporter: Robert Levas
> Assignee: Robert Levas
> Priority: Blocker
> Labels: kerberos_descriptor
> Fix For: 2.4.0
>
> Attachments: AMBARI-17993_branch-2.4_01.patch,
> AMBARI-17993_trunk_01.patch
>
>
> Kerberos identity definitions in Kerberos descriptors should explicitly
> declare a reference rather than rely on the identity's _name_ attribute.
> Currently, the set of Kerberos identities declared at a service-level or a
> component-level can contain identities with unique names. For example using:
> {code}
> "identities": [
> {
> "name": "identity",
> "principal": {
> "value": "service/_HOST@${realm}",
> "configuration": "service-site/property1.principal",
> ...
> },
> "keytab": {
> "file": "${keytab_dir}/service.service.keytab",
> "configuration": "service-site/property1.keytab",
> ...
> }
> },
> {
> "name": "identity",
> "principal": {
> "value": "service/_HOST@${realm}",
> "configuration": "service-site/property2.principal",
> ...
> },
> "keytab": {
> "file": "${keytab_dir}/service.service.keytab",
> "configuration": "service-site/property2.keytab",
> ...
> }
> }
> ]
> {code}
> Only the first "identity" principal is realized and the additional one is
> ignored, leaving the configurations {{service-site/property2.principal}} and
> {{service-site/property2.keytab}} untouched when Kerberos is enabled for the
> service.
> To help this, the 2nd instance can be converted to a reference, overriding
> only the attributes the need to be changed - like the configurations.
> {code}
> "identities": [
> {
> "name": "identity",
> "principal": {
> "value": "service/_HOST@${realm}",
> "configuration": "service-site/property1.principal",
> ...
> },
> "keytab": {
> "file": "${keytab_dir}/service.service.keytab",
> "configuration": "service-site/property1.keytab",
> ...
> }
> },
> {
> "name": "/SERVICE/identity",
> "principal": {
> "configuration": "service-site/property2.principal"
> },
> "keytab": {
> "configuration": "service-site/property2.keytab"
> }
> }
> ]
> {code}
> This allows for both identity declarations to be realized, however this is
> limited to only the 2 instances. If a 3rd instance is needed (to set an
> additional configuration), it must look be:
> {code}
> {
> "name": "/SERVICE/identity",
> "principal": {
> "configuration": "service-site/property3.principal"
> },
> "keytab": {
> "configuration": "service-site/property3.keytab"
> }
> }
> {code}
> However since it's name is the same as the 2nd instance, it will be ignored.
> If explicit references are specified, then multiple uniquely-named identity
> blocks will be allowed to reference the same base identity, effectively
> enabling the ability to declare unlimited configurations for the same
> identity definition:
> {code}
> "identities": [
> {
> "name": "identity",
> "principal": {
> "value": "service/_HOST@${realm}",
> "configuration": "service-site/property1.principal",
> ...
> },
> "keytab": {
> "file": "${keytab_dir}/service.service.keytab",
> "configuration": "service-site/property1.keytab",
> ...
> }
> },
> {
> "name": "identitiy_reference1",
> "reference": "/SERVICE/identity",
> "principal": {
> "configuration": "service-site/property2.principal"
> },
> "keytab": {
> "configuration": "service-site/property2.keytab"
> }
> },
> {
> "name": "identitiy_reference2",
> "reference": "/SERVICE/identity",
> "principal": {
> "configuration": "service-site/property3.principal"
> },
> "keytab": {
> "configuration": "service-site/property3.keytab"
> }
> }
> ]
> {code}
> NOTE: Backwards compatibility must be maintained when implementing this as to
> not break existing Kerberos descriptors. So identity block names the look
> like paths are to continue to be treated as references.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
