You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Robert Levas <rl...@hortonworks.com> on 2015/12/30 13:27:42 UTC

Review Request 41796: Failed to deploy Kerberized cluster via blueprint with custom principal name

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41796/
-----------------------------------------------------------

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

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: PENDING


Thanks,

Robert Levas


Re: Review Request 41796: Failed to deploy Kerberized cluster via blueprint with custom principal name

Posted by Sandor Magyari <sm...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41796/#review112580
-----------------------------------------------------------

Ship it!


Ship It!

- Sandor Magyari


On Dec. 30, 2015, 6:03 p.m., Robert Levas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41796/
> -----------------------------------------------------------
> 
> (Updated Dec. 30, 2015, 6: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 smokeuser9jJevBQAYGQWnRkuapSEp@EXAMPLE.COM, 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
> -------
> 
> 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
> 
>


Re: Review Request 41796: Failed to deploy Kerberized cluster via blueprint with custom principal name

Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
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 smokeuser9jJevBQAYGQWnRkuapSEp@EXAMPLE.COM, 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