Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.1.0
Description
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.
Attachments
Attachments
Issue Links
- links to
