-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41796/
-----------------------------------------------------------
(Updated Dec. 30, 2015, 1:03 p.m.)
Review request for Ambari, Robert Nettleton and Sandor Magyari.
Bugs: AMBARI-14516
https://issues.apache.org/jira/browse/AMBARI-14516
Repository: ambari
Description
-------
Failed to deploy Kerberized cluster via Blueprint with custom principal name
set in Kerberos descriptor declared in _Cluster Creation Template_ like
```
...
"security": {
"type": "KERBEROS",
"kerberos_descriptor": {
"identities": [
{
"name": "smokeuser",
"principal": {
"value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"
}
}
]
}
},
...
```
The following error (shown in ambari-server.log) was encountered while the
cluster was being built:
```
Failed to create keytab for [email protected], missing
cached file
```
# 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]
# 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.
# Workaround
Explicitly set the `type` property of _user_ (or headless) principals in the
Kerberos descriptor:
```
...
"security": {
"type": "KERBEROS",
"kerberos_descriptor": {
"identities": [
{
"name": "smokeuser",
"principal": {
"type" : "USER",
"value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"
}
}
]
}
},
...
```
Diffs
-----
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
ef9cab6
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/HostKerberosIdentityResourceProvider.java
c76ae6c
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalDescriptor.java
09f6872
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalType.java
e192be0
ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosPrincipalDescriptorTest.java
9a4a042
Diff: https://reviews.apache.org/r/41796/diff/
Testing (updated)
-------
Manually tested
# Local test results:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:00:52.786s
[INFO] Finished at: Wed Dec 30 06:23:51 EST 2015
[INFO] Final Memory: 69M/1754M
[INFO] ------------------------------------------------------------------------
# Jenkins test results:
INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:29 h
[INFO] Finished at: 2015-12-30T17:00:07+00:00
[INFO] Final Memory: 132M/588M
[INFO] ------------------------------------------------------------------------
Thanks,
Robert Levas
