[
https://issues.apache.org/jira/browse/AMBARI-13425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959572#comment-14959572
]
Hudson commented on AMBARI-13425:
---------------------------------
FAILURE: Integrated in Ambari-trunk-Commit #3653 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/3653/])
AMBARI-13425. Ambari 1.7 to 2.1.x upgrade with existing Kerberos, keytab
(rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5c800d27bc81e589a338269c07e6435ec0334dd4])
*
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerImplTest.java
> Ambari 1.7 to 2.1.x upgrade with existing Kerberos, keytab files fail to be
> distributed to some hosts
> -----------------------------------------------------------------------------------------------------
>
> Key: AMBARI-13425
> URL: https://issues.apache.org/jira/browse/AMBARI-13425
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.1.0
> Reporter: Robert Levas
> Assignee: Robert Levas
> Labels: kerberos, upgrade
> Fix For: 2.1.3
>
> Attachments: AMBARI-13425_branch-2.1_01.patch,
> AMBARI-13425_trunk_01.patch
>
>
> When upgrading from Ambari 1.7 to 2.1.x, where the source cluster has been
> Kerberized, keytab files fail to distribute to some hosts.
> *Steps to reproduce*
> # Create cluster with Ambari 1.7.0 (multiple nodes, required)
> # Enable Kerberos (manually)
> # Upgrade to Ambari 2.1.2
> # Enable Kerberos (automated)
> # Not all hosts will receive keytab files
> *Cause*
> This is due to the way Ambari keeps track of which components (on each host)
> are properly Kerberized. So if Kerberos was enabled before the upgrade to
> 2.x, at some point the agents will report back to Ambari that its components
> are secured with Kerberos. Ambari will then use this data to determine which
> hosts need to be processed when enabling Kerberos. If some of the hosts have
> reported back before the determination of which hosts need to be process,
> those hosts will most-likely be skipped and thus, the new keytab files will
> not be distributed to them.
> *Solution*
> The solution is to remove outdated code previously used to determine how to
> handle scenarios where new services are added to a Kerberized cluster. This
> code compared the existing services' security state with some desired
> security state. If they matched, then no work needed to be done. The state
> in particular is {{SECURED_KERBEROS}} and can be seen in the
> {{security_state}} column of the {{hostcomponentstate}} table.
> The code in question is outdated since new services being added to a
> Kerberized cluster no longer requires the invocation of the
> {{KerberosHelper.toggleKerberos}} method. The current implementing invokes
> more granular code to configure the relevant service(s) and generate the
> Kerberos identities in a more granular fashion during state changes rather
> then after the fact.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
