[jira] [Commented] (AMBARI-25127) ambari-server.log flooded if client not able to authenticate through kerberos
[
https://issues.apache.org/jira/browse/AMBARI-25127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808936#comment-16808936
]
Robert Levas commented on AMBARI-25127:
---
[~seano], Enabling SPNEGO authentication for Ambari, alone, does not seem to
cause the problem you are seeing. Something else must be going on. I assume
KnoxSSO is involved somehow? Or maybe there is some process polling and
failing to authenticate.
> ambari-server.log flooded if client not able to authenticate through kerberos
> -
>
> Key: AMBARI-25127
> URL: https://issues.apache.org/jira/browse/AMBARI-25127
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.3
>Reporter: Sean Roberts
>Assignee: amarnath reddy pappu
>Priority: Major
>
> With SPNEGO enabled for Ambari-Server, ambari-server.log is flooded with
> every auth failure. _(See log output below)_.
> This is making ambari-server.log impossible to review and fills rapidly.
> REQUEST: ambari-server.log should not contain auth failures, especially not
> full traces of them. JWT items should also likely be exluded from
> ambari-server.log.
> More detail:
> - on every unauthenticated page load, Ambari makes the client attempt to auth
> with Kerberos "negotiate".
> - if that fails it falls back to other authentication mechanisms (user/pass
> prompt or knoxsso).
> - however, each of those failed auths results in this huge amount of logs in
> `ambari-server`.log.
> - for a failed or successful auth, the only log should be a single line in
> `ambari-audit.log`
> ambari-server.log: *1 second* from a single client on a new Ambari. Imagine
> this on a busy ambari-server (scroll within the code block to see the big
> kerberos error).
> {code}
> 2019-01-24 04:46:02,749 INFO [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:265 - hadoop-jwt cookie has been found and is
> being processed
> 2019-01-24 04:46:02,749 INFO [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:265 - hadoop-jwt cookie has been found and is
> being processed
> 2019-01-24 04:46:02,750 INFO [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:265 - hadoop-jwt cookie has been found and is
> being processed
> 2019-01-24 04:46:02,750 WARN [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:399 - JWT expiration date validation failed.
> 2019-01-24 04:46:02,750 INFO [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:294 - Expiration validation failed.
> 2019-01-24 04:46:02,750 WARN [ambari-client-thread-260388]
> AmbariJwtAuthenticationFilter:201 - JWT authentication failed - Invalid JWT
> token
> 2019-01-24 04:46:02,750 INFO [ambari-client-thread-260388]
> AmbariAuthenticationEventHandlerImpl:136 - Failed to authenticate an unknown
> user: Invalid JWT token
> 2019-01-24 04:46:02,756 WARN [ambari-client-thread-259406]
> AmbariKerberosAuthenticationFilter:149 - Negotiate Header was invalid:
> Negotiate TlRMTVNTUAABl4II4gAGAbEdDw==
> org.springframework.security.authentication.BadCredentialsException: Kerberos
> validation not successful
> at
> org.springframework.security.kerberos.authentication.sun.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:71)
> at
> org.apache.ambari.server.security.authentication.kerberos.AmbariKerberosTicketValidator.validateTicket(AmbariKerberosTicketValidator.java:85)
> at
> org.apache.ambari.server.security.authentication.kerberos.AmbariKerberosAuthenticationProvider.authenticate(AmbariKerberosAuthenticationProvider.java:73)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:199)
> at
> org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter$AuthenticationManagerDelegator.authenticate(WebSecurityConfigurerAdapter.java:494)
> at
> org.springframework.security.kerberos.web.authentication.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:145)
> at
> org.apache.ambari.server.security.authentication.kerberos.AmbariKerberosAuthenticationFilter.doFilter(AmbariKerberosAuthenticationFilter.java:179)
> at
> org.apache.ambari.server.security.authentication.AmbariDelegatingAuthenticationFilter.doFilter(AmbariDelegatingAuthenticationFilter.java:123)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> at
> org.apache.ambari.server.security.authorization.AmbariUserAuthorizationFilter.doFilter(AmbariUserA
[jira] [Updated] (AMBARI-25154) can't delete Kerberos when user exits step 4 in enabling Kerberos wizard
[ https://issues.apache.org/jira/browse/AMBARI-25154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-25154: -- Summary: can't delete Kerberos when user exits step 4 in enabling Kerberos wizard (was: can't delete kerberos when user exits step 4 in enabling kerbeors wizard) > can't delete Kerberos when user exits step 4 in enabling Kerberos wizard > > > Key: AMBARI-25154 > URL: https://issues.apache.org/jira/browse/AMBARI-25154 > Project: Ambari > Issue Type: Improvement >Affects Versions: 2.8.0, 2.7.4 >Reporter: zhangxiaolu >Assignee: zhangxiaolu >Priority: Minor > Labels: ambari-web > Fix For: trunk > > Attachments: AMBARI-25154.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-25224) Users with Service Administrator roles should be able to create Alerts in ambari
[
https://issues.apache.org/jira/browse/AMBARI-25224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807812#comment-16807812
]
Robert Levas commented on AMBARI-25224:
---
A decision was made somewhere to only allow Cluster Administrators and Ambari
Administrators to create custom alerts. This seems to make sense since the
alert is a cluster-related resources, not a service-related resource. Maybe
with more granular roles, this might be changed.
I will leave this open in the event someone cares to take a look at it and see
if determining the level of alert is feasible before determining the
appropriate permission required.
> Users with Service Administrator roles should be able to create Alerts in
> ambari
>
>
> Key: AMBARI-25224
> URL: https://issues.apache.org/jira/browse/AMBARI-25224
> Project: Ambari
> Issue Type: Bug
> Components: ambari-sever
>Affects Versions: 2.7.3
>Reporter: Shubham
>Priority: Major
>
> Problems Statement : Currently i am having service administrator privilage
> in my cluster. i am trying to create Custom Alert in ambari and its failing
> with above exception :
>
>
> {code:java}
> curl -u TestUser:admin -i -H 'X-Requested-By:ambari' -X POST -d
> @alertsjson.txt http://test1:8080/api/v1/clusters/test1/alert_definitions
> HTTP/1.1 100 Continue
> HTTP/1.1 403 Forbidden
> X-Frame-Options: DENY
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Cache-Control: no-store
> Pragma: no-cache
> Set-Cookie: AMBARISESSIONID=9g1ieqg3rijo1tuclt3dxkedl;Path=/;HttpOnly
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> User: TestUser
> Content-Type: text/plain
> Content-Length: 109
> {
> "status" : 403,
> "message" : "The authenticated user is not authorized to manage
> cluster-level alerts"
> }
> {code}
> But i feel as i am service administrator i should be able to create a alert.
>
> Currently only Ambari Administrator is able to create alert in ambaril
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-25223) ambari kerberos wizard requires ambari host to be registered
[ https://issues.apache.org/jira/browse/AMBARI-25223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-25223: -- Fix Version/s: 2.7.4 > ambari kerberos wizard requires ambari host to be registered > > > Key: AMBARI-25223 > URL: https://issues.apache.org/jira/browse/AMBARI-25223 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.3 >Reporter: Charles Hedrick >Assignee: Gabor Boros >Priority: Major > Fix For: 2.7.4 > > > I'm not sure whether this is a bug, but I think so. > I just Kerberized HDP 3.1, using Ambari 2.7.3. In 2.6.3 I didn't need to > register the Ambari host as a member of the cluster. In 2.7.3 I do. If the > ambari host isn't registered the host check fails claiming "host not found.' > Initially I thought there was a DNS or LDAP issue, but in fact it failed to > find the hostname in Ambari's internal database. The only way I could find to > fix it was to register the host, which meant running at least the metrics > daemon on it. > I don't believe the Ambari host should need to be a cluster member. If it is > necessary, a more explicit error messge would be useful, since "host not > found" sounds more like a problem with /etc/hosts or DNS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-25223) ambari kerberos wizard requires ambari host to be registered
[ https://issues.apache.org/jira/browse/AMBARI-25223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807806#comment-16807806 ] Robert Levas commented on AMBARI-25223: --- [~amagyar], [~gboros] Can you check to see if AMBARI-25088 was ported to version 2.7.4 (branch-2.7)? I do not think it was. If so, maybe it is worth back porting it. > ambari kerberos wizard requires ambari host to be registered > > > Key: AMBARI-25223 > URL: https://issues.apache.org/jira/browse/AMBARI-25223 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.3 >Reporter: Charles Hedrick >Priority: Major > > I'm not sure whether this is a bug, but I think so. > I just Kerberized HDP 3.1, using Ambari 2.7.3. In 2.6.3 I didn't need to > register the Ambari host as a member of the cluster. In 2.7.3 I do. If the > ambari host isn't registered the host check fails claiming "host not found.' > Initially I thought there was a DNS or LDAP issue, but in fact it failed to > find the hostname in Ambari's internal database. The only way I could find to > fix it was to register the host, which meant running at least the metrics > daemon on it. > I don't believe the Ambari host should need to be a cluster member. If it is > necessary, a more explicit error messge would be useful, since "host not > found" sounds more like a problem with /etc/hosts or DNS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-25223) ambari kerberos wizard requires ambari host to be registered
[ https://issues.apache.org/jira/browse/AMBARI-25223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas reassigned AMBARI-25223: - Assignee: Gabor Boros > ambari kerberos wizard requires ambari host to be registered > > > Key: AMBARI-25223 > URL: https://issues.apache.org/jira/browse/AMBARI-25223 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.3 >Reporter: Charles Hedrick >Assignee: Gabor Boros >Priority: Major > > I'm not sure whether this is a bug, but I think so. > I just Kerberized HDP 3.1, using Ambari 2.7.3. In 2.6.3 I didn't need to > register the Ambari host as a member of the cluster. In 2.7.3 I do. If the > ambari host isn't registered the host check fails claiming "host not found.' > Initially I thought there was a DNS or LDAP issue, but in fact it failed to > find the hostname in Ambari's internal database. The only way I could find to > fix it was to register the host, which meant running at least the metrics > daemon on it. > I don't believe the Ambari host should need to be a cluster member. If it is > necessary, a more explicit error messge would be useful, since "host not > found" sounds more like a problem with /etc/hosts or DNS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-25205) hdfs_to_onefs_convert.py script missing HDP3.1 + upgrade logic
[ https://issues.apache.org/jira/browse/AMBARI-25205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798087#comment-16798087 ] Robert Levas commented on AMBARI-25205: --- FYI [~amagyar] > hdfs_to_onefs_convert.py script missing HDP3.1 + upgrade logic > -- > > Key: AMBARI-25205 > URL: https://issues.apache.org/jira/browse/AMBARI-25205 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.3 >Reporter: Kirankumar Bhusanurmath >Priority: Major > Attachments: hdfs to onefs issue.jpg > > > hdfs to onefs convert script used to upgrade HDP2.6.5 to HDP3.0.1 stack is > missing HDP3.1.* stack support. Please add HDP3.1.* support as well make it > generic for all future stacks. > !hdfs to onefs issue.jpg! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-25204) Ambari returns stack trace in HTML doc when an error occurs retrieving details for an Ambari View resource that does not exist
Robert Levas created AMBARI-25204:
-
Summary: Ambari returns stack trace in HTML doc when an error
occurs retrieving details for an Ambari View resource that does not exist
Key: AMBARI-25204
URL: https://issues.apache.org/jira/browse/AMBARI-25204
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.7.3
Reporter: Robert Levas
Assignee: Gabor Boros
Fix For: 2.7.4
Ambari returns stack trace in HTML doc when an error occurs retrieving details
for an *Ambari View* resource that does not exist.
{noformat}
curl -u admin:admin -X GET
http://localhost:8080/api/v1/views/CAPACITY-SCHEDULER/versions/1.0.0/instances/AUTO_CS_INSTANCE/bad_resource
{noformat}
{noformat}
Error 500 Server Error
HTTP ERROR 500
Problem accessing
/api/v1/views/CAPACITY-SCHEDULER/versions/1.0.0/instances/AUTO_CS_INSTANCE/bad_resource.
Reason:
Server ErrorCaused
by:java.lang.IllegalArgumentException: A resource type bad_resource
for view instance CAPACITY-SCHEDULER/AUTO_CS_INSTANCE can not be found.
at
org.apache.ambari.server.api.services.views.ViewInstanceService.getResourceHandler(ViewInstanceService.java:326)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
...
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-25186) Kerberos Client is unnecessarily installed via Blueprints when kerberos-env/kdc-type is none
[
https://issues.apache.org/jira/browse/AMBARI-25186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797197#comment-16797197
]
Robert Levas commented on AMBARI-25186:
---
This also needs to go into trunk.
> Kerberos Client is unnecessarily installed via Blueprints when
> kerberos-env/kdc-type is none
>
>
> Key: AMBARI-25186
> URL: https://issues.apache.org/jira/browse/AMBARI-25186
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.0
>Reporter: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.4
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Kerberos Client component is unnecessarily installed via Blueprints when
> \{{kerberos-env/kdc-type}} is "none".
> The Blueprint TopologyManager should only force the Kerberos client to be
> installed if Kerberos is enabled and {{kerberos_env/kdc_type}} is not "none".
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-25201) Updating a user's password does not validate the administrator's current password.
Robert Levas created AMBARI-25201:
-
Summary: Updating a user's password does not validate the
administrator's current password.
Key: AMBARI-25201
URL: https://issues.apache.org/jira/browse/AMBARI-25201
Project: Ambari
Issue Type: Bug
Components: ambari-server, ambari-web
Affects Versions: 2.7.0
Reporter: Robert Levas
Assignee: Gabor Boros
Fix For: 2.7.4
Attachments: image-2019-03-19-12-18-59-062.png
When updating a user's password as an Ambari Administrator via the UI, the
acting administrator user is prompted for their password...
!image-2019-03-19-12-18-59-062.png!
The password is never validated by the backend to end sure it is correct for
the acting user. Either the text box needs to be removed from the UI, or the
backend should verify the administrator's password before changing the user's
password.
The current implementation does require that if the acting user is not an
Ambari Administrator user, the acting user may only change their own password
and must supply their current password as well as the new password:
Example:
{noformat}
curl -H "X-Requested-By:ambari" -u user_a:hadoop -X PUT -d '{ "Users" : {
"old_password" : "hadoop", "password" : "hadoop_1234" } }'
http://localhost:8080/api/v1/users/user_a
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-25194) Increase the Agent cert validity to 3 years
[ https://issues.apache.org/jira/browse/AMBARI-25194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas resolved AMBARI-25194. --- Resolution: Fixed > Increase the Agent cert validity to 3 years > --- > > Key: AMBARI-25194 > URL: https://issues.apache.org/jira/browse/AMBARI-25194 > Project: Ambari > Issue Type: Improvement >Reporter: amarnath reddy pappu >Assignee: amarnath reddy pappu >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > By Default Ambari generates Agent certificates with 1 year validity. with in > 1 year of Ambari installation these certificates would expire and agent would > stop heart beating. Freshly re-setting issues the certificates would be > tedious task. > so increasing it to 3 years would be ideal as these are internal certs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-25194) Increase the Agent cert validity to 3 years
[
https://issues.apache.org/jira/browse/AMBARI-25194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793203#comment-16793203
]
Robert Levas commented on AMBARI-25194:
---
This can be done by editing {{/var/lib/ambari-server/keys/ca.config}} and
changing the line that reads:
{noformat}
default_days = 365
{noformat}
Do we think that this change is needed in Ambari itself, or would documenting
how to set the validity period suffice?
> Increase the Agent cert validity to 3 years
> ---
>
> Key: AMBARI-25194
> URL: https://issues.apache.org/jira/browse/AMBARI-25194
> Project: Ambari
> Issue Type: Improvement
>Reporter: amarnath reddy pappu
>Assignee: amarnath reddy pappu
>Priority: Major
>
> By Default Ambari generates Agent certificates with 1 year validity. with in
> 1 year of Ambari installation these certificates would expire and agent would
> stop heart beating. Freshly re-setting issues the certificates would be
> tedious task.
> so increasing it to 3 years would be ideal as these are internal certs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-25176) Misconfiguration of jersey log in log4j.properties
[ https://issues.apache.org/jira/browse/AMBARI-25176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas resolved AMBARI-25176. --- Resolution: Fixed > Misconfiguration of jersey log in log4j.properties > -- > > Key: AMBARI-25176 > URL: https://issues.apache.org/jira/browse/AMBARI-25176 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Chen Zhi >Priority: Major > Labels: CI, pull-request-available > Fix For: trunk, 2.7.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > In the [AMBARI-16187|https://issues.apache.org/jira/browse/AMBARI-16187], we > have intercepted log entries and redirected jersey log to server log. To > avoid too many logs from jersey, we also changed the default log level > (default -> WARN) for jersey library. However, the jersey we used in > ambari-server is the older version from Sun, not from the Glassfish, so the > correct logger name should be "com.sun.jersey". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-25187) Kerberos operations are shown in service action dropdown when not needed
Robert Levas created AMBARI-25187: - Summary: Kerberos operations are shown in service action dropdown when not needed Key: AMBARI-25187 URL: https://issues.apache.org/jira/browse/AMBARI-25187 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.6.0 Reporter: Robert Levas Fix For: 2.7.4 Kerberos operations are shown in service action dropdown menus when not needed. Steps to Reproduce: # Install Ambari # Enable Kerberos, selecting KDC type of "none" (user will manually manage the Kerberos identities) ** Or unckeck "Manage identities" to declare the user will manually manage Kerberos identities # Browse to service view # Click to dropdown the Actions menu # See "Regenerate Keytabs" option The "Regenerate Keytabs" option should not be available to the user since Ambari is not managing Kerberos identities. The action doesn't do anything, but the user should not have the option to select it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-25186) Kerberos Client is unnecessarily installed via Blueprints when kerberos-env/kdc-type is none
Robert Levas created AMBARI-25186:
-
Summary: Kerberos Client is unnecessarily installed via Blueprints
when kerberos-env/kdc-type is none
Key: AMBARI-25186
URL: https://issues.apache.org/jira/browse/AMBARI-25186
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.6.0
Reporter: Robert Levas
Fix For: 2.7.4
The Kerberos Client component is unnecessarily installed via Blueprints when
\{{kerberos-env/kdc-type}} is "none".
The Blueprint TopologyManager should only force the Kerberos client to be
installed if Kerberos is enabled and {{kerberos_env/kdc_type}} is not "none".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-25176) Misconfiguration of jersey log in log4j.properties
[ https://issues.apache.org/jira/browse/AMBARI-25176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786041#comment-16786041 ] Robert Levas commented on AMBARI-25176: --- [~coder_chenzhi] correct. > Misconfiguration of jersey log in log4j.properties > -- > > Key: AMBARI-25176 > URL: https://issues.apache.org/jira/browse/AMBARI-25176 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Chen Zhi >Priority: Major > Labels: CI, pull-request-available > Fix For: trunk, 2.7.4 > > Time Spent: 1h > Remaining Estimate: 0h > > In the [AMBARI-16187|https://issues.apache.org/jira/browse/AMBARI-16187], we > have intercepted log entries and redirected jersey log to server log. To > avoid too many logs from jersey, we also changed the default log level > (default -> WARN) for jersey library. However, the jersey we used in > ambari-server is the older version from Sun, not from the Glassfish, so the > correct logger name should be "com.sun.jersey". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-25176) Misconfiguration of jersey log in log4j.properties
[ https://issues.apache.org/jira/browse/AMBARI-25176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785636#comment-16785636 ] Robert Levas commented on AMBARI-25176: --- [~coder_chenzhi], You should also add this to branch-2.7. for the Ambari 2.7.4 release. > Misconfiguration of jersey log in log4j.properties > -- > > Key: AMBARI-25176 > URL: https://issues.apache.org/jira/browse/AMBARI-25176 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Chen Zhi >Priority: Major > Labels: CI, pull-request-available > Fix For: trunk, 2.7.4 > > Time Spent: 50m > Remaining Estimate: 0h > > In the [AMBARI-16187|https://issues.apache.org/jira/browse/AMBARI-16187], we > have intercepted log entries and redirected jersey log to server log. To > avoid too many logs from jersey, we also changed the default log level > (default -> WARN) for jersey library. However, the jersey we used in > ambari-server is the older version from Sun, not from the Glassfish, so the > correct logger name should be "com.sun.jersey". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-25176) Misconfiguration of jersey log in log4j.properties
[ https://issues.apache.org/jira/browse/AMBARI-25176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-25176: -- Fix Version/s: 2.7.4 trunk > Misconfiguration of jersey log in log4j.properties > -- > > Key: AMBARI-25176 > URL: https://issues.apache.org/jira/browse/AMBARI-25176 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Chen Zhi >Priority: Major > Labels: CI, pull-request-available > Fix For: trunk, 2.7.4 > > Time Spent: 50m > Remaining Estimate: 0h > > In the [AMBARI-16187|https://issues.apache.org/jira/browse/AMBARI-16187], we > have intercepted log entries and redirected jersey log to server log. To > avoid too many logs from jersey, we also changed the default log level > (default -> WARN) for jersey library. However, the jersey we used in > ambari-server is the older version from Sun, not from the Glassfish, so the > correct logger name should be "com.sun.jersey". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24961) Ambari is unable to parse {{hostname}} in {hdfs-site/dfs.datanode.address} and is triggering alert for datanode process
[
https://issues.apache.org/jira/browse/AMBARI-24961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761733#comment-16761733
]
Robert Levas commented on AMBARI-24961:
---
[~akhilsnaik]... In order for hostname to resolve to something a
variable needs to be defined in the context named {{hostname}}. This is
typically done in the params.py or params_linux.py file. See
[https://github.com/hortonworks/hdp_ambari_definitions/blob/AMBARI-2.7-maint/src/main/resources/stacks/HDP/3.0/services/HBASE/package/scripts/params_linux.py#L254].
{code:java}
hostname = config['agentLevelParams']['hostname']
{code}
My guess is that there is no {{hostname}} property defined in the relevant
context. However, I do see it in
[https://github.com/hortonworks/hdp_ambari_definitions/blob/AMBARI-2.7-maint/src/main/resources/stacks/HDP/3.0/services/HDFS/package/scripts/params_linux.py#L187.]
So I am not quite sure what is going on.
Maybe this wacky substitution does not work in the alerts mechanism or maybe
params_linux.py is not being executed.
> Ambari is unable to parse {{hostname}} in {hdfs-site/dfs.datanode.address}
> and is triggering alert for datanode process
> ---
>
> Key: AMBARI-24961
> URL: https://issues.apache.org/jira/browse/AMBARI-24961
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: trunk, 2.6.2, 2.7.0
> Environment: ambari-2.6.2
> ambari-2.7.0
> trunk
>Reporter: Akhil S Naik
>Assignee: Akhil S Naik
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ambari is unable to parse \\{\{hostname\}\} in
> {hdfs-site/dfs.datanode.address} and is triggering alert for datanode process
> I changed the value of dfs.datanode.address in Advanced hdfs configuration
> using ambari
> i set value to \\{\{hostname\}\}:50010 ( default value is 0.0.0.0:50010 )
> Now after restart datanode is working fine and but ambari is triggering alert
> on datanode process with error :
> "Connection failed: [Errno -2] Name or service not known to
> \\{\{hostname\}\}:50010"
> expected result : Ambari shouldnt trigger the alert and it should pass
> \\{\{hostname\}\} correctly to localhost
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24152) Ambari Workflow Manager (wfmanager) sends plaintext content over API. JSON is expected.
[
https://issues.apache.org/jira/browse/AMBARI-24152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752292#comment-16752292
]
Robert Levas commented on AMBARI-24152:
---
[~hegand]...
{quote}Hi, could you please give some update about this issue? As i can see,
git pull requests were rejected. Thanks{quote}
I am surprised that I did not comment on what the issue was. Since it was over
7 months ago, I am not sure, but the patch must have broken something and
someone must have asked me to revert it.
> Ambari Workflow Manager (wfmanager) sends plaintext content over API. JSON is
> expected.
> ---
>
> Key: AMBARI-24152
> URL: https://issues.apache.org/jira/browse/AMBARI-24152
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views, contrib
>Affects Versions: 2.6.2, 2.7.0
>Reporter: Sean Roberts
>Assignee: venkat
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The Ambari API is expected to respond with JSON content.
> However the wfmanager's /resources/proxy/getCurrentUserName returns plaintext
> content.
> This is breaking Knox proxying of the UI and is likely to break other
> proxies/clients who expect the API to respond with JSON.
> https://github.com/apache/ambari/blob/trunk/contrib/views/wfmanager/src/main/java/org/apache/oozie/ambari/view/OozieProxyImpersonator.java#L154-L158
> Full API url would be:
> /api/v1/views/WORKFLOW_MANAGER/versions/1.0.0/instances/instance_name/resources/proxy/getCurrentUserName
> How to reproduce:
> # GET
> http://hostname:8080/api/v1/views/WORKFLOW_MANAGER/versions/1.0.0/instances/instance_name/resources/proxy/getCurrentUserName
> # Notice that it responds with a username only which is plaintext not JSON.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMBARI-24420) XSS in Ambari Add Host Wizard
[
https://issues.apache.org/jira/browse/AMBARI-24420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694708#comment-16694708
]
Robert Levas edited comment on AMBARI-24420 at 1/10/19 5:38 PM:
[~juliaw]...
Thanks for the report. Can you email this to
[secur...@apache.org|mailto:secur...@apache.org] and
[priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on
how to reproduce the issue. Do not add these details here since we do not want
such information out in the public until the vulnerability is fixed.
was (Author: rlevas):
[~juliaw]...
Thanks for the report. Can you email this to
[secur...@apache.org|mailto:secur...@apache.org] and
[priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on
how to reproduce the issue. Do not add these details here since we do not want
suck information out in the public until the vulnerability is fixed.
> XSS in Ambari Add Host Wizard
> -
>
> Key: AMBARI-24420
> URL: https://issues.apache.org/jira/browse/AMBARI-24420
> Project: Ambari
> Issue Type: Bug
> Components: ambari-client
>Affects Versions: 2.7.1
>Reporter: Julia
>Assignee: Robert Levas
>Priority: Critical
>
> It is possible for an attacker to steal information or access from users by
> executing malicious JavaScript. This is possible due to the use of a
> javascript "eval()" function when loading the SSH private key. Leveraging
> this any malicious data in any file uploaded, not just private keys, would
> execute. In the case of private keys, malicious script in the metadata of the
> key would execute. An attacker could directly scrap and information on the
> page, modify its appearance, or steal the users sessions information.
>
> Repro:
>
> +{color:#0066cc}[https://x.azurehdinsight.net/#/main/host/add/step1]{color}+
> !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/f65e2526-613e-4af7-910e-7a19a4376a6d?fileName=attachfilehandler.png!
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMBARI-24418) XSS attack in Ambari Alerts
[ https://issues.apache.org/jira/browse/AMBARI-24418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694706#comment-16694706 ] Robert Levas edited comment on AMBARI-24418 at 1/10/19 5:39 PM: [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want such information out in the public until the vulnerability is fixed. was (Author: rlevas): [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want suck information out in the public until the vulnerability is fixed. > XSS attack in Ambari Alerts > --- > > Key: AMBARI-24418 > URL: https://issues.apache.org/jira/browse/AMBARI-24418 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > > It is possible for an attacker to steal information or access from users by > executing malicious javascript. This is possible due to the use of a > javascript "eval()" function when loading the description of alerts. > Leveraging this one user could create a malicious alert to steal access or > information of another user. Upon viewing the maliicous alert the vicitim > would be comprimised by directly scraping any information on the page, modify > its appearence, or having their session information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/8dfe7e85-4c5a-4632-90c8-73696cfe727a?fileName=attachfilehandler%20%282%29.png! > Repro steps > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/6aebfcf6-9d34-45d5-bf88-c2d43431f84f?fileName=attachfilehandler%20%281%29.png! > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMBARI-24419) XSS attack in Ambari Config History
[ https://issues.apache.org/jira/browse/AMBARI-24419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694707#comment-16694707 ] Robert Levas edited comment on AMBARI-24419 at 1/10/19 5:38 PM: [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want such information out in the public until the vulnerability is fixed. was (Author: rlevas): [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want suck information out in the public until the vulnerability is fixed. > XSS attack in Ambari Config History > --- > > Key: AMBARI-24419 > URL: https://issues.apache.org/jira/browse/AMBARI-24419 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > It is possible for an attacker to steal information or access from users by > executing malicious JavaScript. This is possible due to the use of a > javascript "eval()" function when loading the notes from config history > change. Leveraging this one user could create a malicious history entry to > steal access or information of another user. Upon viewing the malicious > historical entry the victim would be comprimised by directly scraping any > information on the page, modify its appearance, or having their session > information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/81b481b3-397c-442e-b0aa-199ff793a05d?fileName=attachfilehandler%20%283%29.png! > > > fg > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-25088) Enable Kerberos fails when Ambari server is not on a registered host
[
https://issues.apache.org/jira/browse/AMBARI-25088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-25088:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Enable Kerberos fails when Ambari server is not on a registered host
>
>
> Key: AMBARI-25088
> URL: https://issues.apache.org/jira/browse/AMBARI-25088
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: amarnath reddy pappu
>Assignee: Robert Levas
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Enable Kerberos fails when Ambari server is not on a registered host.
> The following error is seen in /var/log/ambari-server.log
> {noformat}
> 2019-01-03 15:28:34,238 WARN [Server Action Executor Worker 39]
> ServerActionExecutor:471 - Task #39 failed to complete execution due to
> thrown exception: org.apache.ambari.server.HostNotFoundException:Host not
> found, hostname=c7401.ambari.apache.org
> org.apache.ambari.server.HostNotFoundException: Host not found,
> hostname=c7401.ambari.apache.org
> at
> org.apache.ambari.server.state.cluster.ClustersImpl.getHost(ClustersImpl.java:456)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:190)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:174)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.findConfigurationTagsWithOverrides(AmbariManagementControllerImpl.java:2431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
> at com.sun.proxy.$Proxy134.findConfigurationTagsWithOverrides(Unknown
> Source)
> at
> org.apache.ambari.server.state.ConfigHelper.calculateExistingConfigurations(ConfigHelper.java:2158)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.calculateConfigurations(KerberosHelperImpl.java:1722)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1797)
> at
> org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.calculateServiceIdentities(KerberosServerAction.java:512)
> at
> org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.processIdentities(KerberosServerAction.java:456)
> at
> org.apache.ambari.server.serveraction.kerberos.CreatePrincipalsServerAction.execute(CreatePrincipalsServerAction.java:92)
> at
> org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.execute(ServerActionExecutor.java:550)
> at
> org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.run(ServerActionExecutor.java:466)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is caused when Ambari tried to find the host-specific configuration
> values when processing the Kerberos identities and the host is not registered
> for the relevant cluster. This can happen when the Ambari server Kerberos
> identity is being processed when the Ambari server host is not registered
> with the cluster.
> To solve this, host specific configuration values should not be obtained for
> the non-registered Ambari server host.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-25088) Enable Kerberos fails when Ambari server is not on a registered host
[
https://issues.apache.org/jira/browse/AMBARI-25088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-25088:
--
Status: Patch Available (was: In Progress)
> Enable Kerberos fails when Ambari server is not on a registered host
>
>
> Key: AMBARI-25088
> URL: https://issues.apache.org/jira/browse/AMBARI-25088
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: amarnath reddy pappu
>Assignee: Robert Levas
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Enable Kerberos fails when Ambari server is not on a registered host.
> The following error is seen in /var/log/ambari-server.log
> {noformat}
> 2019-01-03 15:28:34,238 WARN [Server Action Executor Worker 39]
> ServerActionExecutor:471 - Task #39 failed to complete execution due to
> thrown exception: org.apache.ambari.server.HostNotFoundException:Host not
> found, hostname=c7401.ambari.apache.org
> org.apache.ambari.server.HostNotFoundException: Host not found,
> hostname=c7401.ambari.apache.org
> at
> org.apache.ambari.server.state.cluster.ClustersImpl.getHost(ClustersImpl.java:456)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:190)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:174)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.findConfigurationTagsWithOverrides(AmbariManagementControllerImpl.java:2431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
> at com.sun.proxy.$Proxy134.findConfigurationTagsWithOverrides(Unknown
> Source)
> at
> org.apache.ambari.server.state.ConfigHelper.calculateExistingConfigurations(ConfigHelper.java:2158)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.calculateConfigurations(KerberosHelperImpl.java:1722)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1797)
> at
> org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.calculateServiceIdentities(KerberosServerAction.java:512)
> at
> org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.processIdentities(KerberosServerAction.java:456)
> at
> org.apache.ambari.server.serveraction.kerberos.CreatePrincipalsServerAction.execute(CreatePrincipalsServerAction.java:92)
> at
> org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.execute(ServerActionExecutor.java:550)
> at
> org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.run(ServerActionExecutor.java:466)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is caused when Ambari tried to find the host-specific configuration
> values when processing the Kerberos identities and the host is not registered
> for the relevant cluster. This can happen when the Ambari server Kerberos
> identity is being processed when the Ambari server host is not registered
> with the cluster.
> To solve this, host specific configuration values should not be obtained for
> the non-registered Ambari server host.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-25080) Unable to install Hive service
[
https://issues.apache.org/jira/browse/AMBARI-25080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-25080.
---
Resolution: Duplicate
Fix Version/s: 2.8.0
> Unable to install Hive service
> --
>
> Key: AMBARI-25080
> URL: https://issues.apache.org/jira/browse/AMBARI-25080
> Project: Ambari
> Issue Type: Bug
> Components: ambari-sever
>Affects Versions: 2.7.1
>Reporter: amarnath reddy pappu
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.8.0
>
>
> Steps to reproduce the issue:
> 1. Install Ambari 2.7.1 and HDP3.0.1 with basic services
> 2. Enable the Kerberos for cluster.
> 3. Now try to add the Hive service. service installation would fail.
> 4. Finish the wizard and now try to start the service but it fails with below
> exception.
> {noformat}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive_metastore.py",
> line 201, in
> HiveMetastore().execute()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/script/script.py",
> line 351, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive_metastore.py",
> line 55, in start
> refresh_yarn()
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive.py",
> line 402, in refresh_yarn
> Execute(params.yarn_kinit_cmd, user = params.yarn_user)
> File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line
> 166, in __init__
> self.env.run()
> File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py",
> line 263, in action_run
> returns=self.resource.returns)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 72, in inner
> result = function(command, **kwargs)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 102, in checked_call
> tries=tries, try_sleep=try_sleep,
> timeout_kill_strategy=timeout_kill_strategy, returns=returns)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 150, in _call_wrapper
> result = _call(command, **kwargs_copy)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 314, in _call
> raise ExecutionFailed(err_msg, code, out, err)
> resource_management.core.exceptions.ExecutionFailed: Execution of
> '/usr/bin/kinit -kt /etc/security/keytabs/yarn.service.keytab
> yarn/c2111-node3.hdp@hwx.com;' returned 1. kinit: Client
> 'yarn/c2111-node3.hdp@hwx.com' not found in Kerberos database while
> getting initial credentials
> {noformat}
> Basically during the installation stage one of the task fails with below
> exception and because of that it does not complete all the tasks that were
> part of the installation.
> {noformat}
> 2019-01-02 22:36:32,560 INFO [Server Action Executor Worker 102]
> KerberosServerAction:432 - Processing identities...
> 2019-01-02 22:36:32,649 WARN [Server Action Executor Worker 102]
> ServerActionExecutor:471 - Task #102 failed to complete execution due to
> thrown exception: org.apache.ambari.server.HostNotFoundException:Host not
> found, hostname=c2111-node1.hdp.com
> org.apache.ambari.server.HostNotFoundException: Host not found,
> hostname=c2111-node1.hdp.com
> at
> org.apache.ambari.server.state.cluster.ClustersImpl.getHost(ClustersImpl.java:456)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:189)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:173)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.findConfigurationTagsWithOverrides(AmbariManagementControllerImpl.java:2354)
> at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
> at com.sun.proxy.$Proxy131.findConfigurationTagsWithOverrides(Unknown
> Source)
> at
> org.apache.ambari.server.state.ConfigHelper.calculateExistingConfigurations(ConfigHelper.java:2158)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.calculateConfigurations(KerberosHelperImpl.java:1727)
> at
[jira] [Assigned] (AMBARI-25080) Unable to install Hive service
[
https://issues.apache.org/jira/browse/AMBARI-25080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reassigned AMBARI-25080:
-
Assignee: Robert Levas
> Unable to install Hive service
> --
>
> Key: AMBARI-25080
> URL: https://issues.apache.org/jira/browse/AMBARI-25080
> Project: Ambari
> Issue Type: Bug
> Components: ambari-sever
>Affects Versions: 2.7.1
>Reporter: amarnath reddy pappu
>Assignee: Robert Levas
>Priority: Major
>
> Steps to reproduce the issue:
> 1. Install Ambari 2.7.1 and HDP3.0.1 with basic services
> 2. Enable the Kerberos for cluster.
> 3. Now try to add the Hive service. service installation would fail.
> 4. Finish the wizard and now try to start the service but it fails with below
> exception.
> {noformat}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive_metastore.py",
> line 201, in
> HiveMetastore().execute()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/script/script.py",
> line 351, in execute
> method(env)
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive_metastore.py",
> line 55, in start
> refresh_yarn()
> File
> "/var/lib/ambari-agent/cache/stacks/HDP/3.0/services/HIVE/package/scripts/hive.py",
> line 402, in refresh_yarn
> Execute(params.yarn_kinit_cmd, user = params.yarn_user)
> File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line
> 166, in __init__
> self.env.run()
> File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py",
> line 263, in action_run
> returns=self.resource.returns)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 72, in inner
> result = function(command, **kwargs)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 102, in checked_call
> tries=tries, try_sleep=try_sleep,
> timeout_kill_strategy=timeout_kill_strategy, returns=returns)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 150, in _call_wrapper
> result = _call(command, **kwargs_copy)
> File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line
> 314, in _call
> raise ExecutionFailed(err_msg, code, out, err)
> resource_management.core.exceptions.ExecutionFailed: Execution of
> '/usr/bin/kinit -kt /etc/security/keytabs/yarn.service.keytab
> yarn/c2111-node3.hdp@hwx.com;' returned 1. kinit: Client
> 'yarn/c2111-node3.hdp@hwx.com' not found in Kerberos database while
> getting initial credentials
> {noformat}
> Basically during the installation stage one of the task fails with below
> exception and because of that it does not complete all the tasks that were
> part of the installation.
> {noformat}
> 2019-01-02 22:36:32,560 INFO [Server Action Executor Worker 102]
> KerberosServerAction:432 - Processing identities...
> 2019-01-02 22:36:32,649 WARN [Server Action Executor Worker 102]
> ServerActionExecutor:471 - Task #102 failed to complete execution due to
> thrown exception: org.apache.ambari.server.HostNotFoundException:Host not
> found, hostname=c2111-node1.hdp.com
> org.apache.ambari.server.HostNotFoundException: Host not found,
> hostname=c2111-node1.hdp.com
> at
> org.apache.ambari.server.state.cluster.ClustersImpl.getHost(ClustersImpl.java:456)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:189)
> at
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:173)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.findConfigurationTagsWithOverrides(AmbariManagementControllerImpl.java:2354)
> at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
> at com.sun.proxy.$Proxy131.findConfigurationTagsWithOverrides(Unknown
> Source)
> at
> org.apache.ambari.server.state.ConfigHelper.calculateExistingConfigurations(ConfigHelper.java:2158)
> at
> org.apache.ambari.server.controller.KerberosHelperImpl.calculateConfigurations(KerberosHelperImpl.java:1727)
> at
> org.apache.ambari.server.controller.KerberosHelperI
[jira] [Created] (AMBARI-25088) Enable Kerberos fails when Ambari server is not on a registered host
Robert Levas created AMBARI-25088:
-
Summary: Enable Kerberos fails when Ambari server is not on a
registered host
Key: AMBARI-25088
URL: https://issues.apache.org/jira/browse/AMBARI-25088
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.7.1
Reporter: amarnath reddy pappu
Assignee: Robert Levas
Fix For: 2.8.0
Enable Kerberos fails when Ambari server is not on a registered host.
The following error is seen in /var/log/ambari-server.log
{noformat}
2019-01-03 15:28:34,238 WARN [Server Action Executor Worker 39]
ServerActionExecutor:471 - Task #39 failed to complete execution due to thrown
exception: org.apache.ambari.server.HostNotFoundException:Host not found,
hostname=c7401.ambari.apache.org
org.apache.ambari.server.HostNotFoundException: Host not found,
hostname=c7401.ambari.apache.org
at
org.apache.ambari.server.state.cluster.ClustersImpl.getHost(ClustersImpl.java:456)
at
org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:190)
at
org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:174)
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.findConfigurationTagsWithOverrides(AmbariManagementControllerImpl.java:2431)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
at com.sun.proxy.$Proxy134.findConfigurationTagsWithOverrides(Unknown
Source)
at
org.apache.ambari.server.state.ConfigHelper.calculateExistingConfigurations(ConfigHelper.java:2158)
at
org.apache.ambari.server.controller.KerberosHelperImpl.calculateConfigurations(KerberosHelperImpl.java:1722)
at
org.apache.ambari.server.controller.KerberosHelperImpl.getActiveIdentities(KerberosHelperImpl.java:1797)
at
org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.calculateServiceIdentities(KerberosServerAction.java:512)
at
org.apache.ambari.server.serveraction.kerberos.KerberosServerAction.processIdentities(KerberosServerAction.java:456)
at
org.apache.ambari.server.serveraction.kerberos.CreatePrincipalsServerAction.execute(CreatePrincipalsServerAction.java:92)
at
org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.execute(ServerActionExecutor.java:550)
at
org.apache.ambari.server.serveraction.ServerActionExecutor$Worker.run(ServerActionExecutor.java:466)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is caused when Ambari tried to find the host-specific configuration values
when processing the Kerberos identities and the host is not registered for the
relevant cluster. This can happen when the Ambari server Kerberos identity is
being processed when the Ambari server host is not registered with the cluster.
To solve this, host specific configuration values should not be obtained for
the non-registered Ambari server host.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-25062) Optionally execute the post user creation hook on existing users during LDAP sync
[
https://issues.apache.org/jira/browse/AMBARI-25062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-25062:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Optionally execute the post user creation hook on existing users during LDAP
> sync
> -
>
> Key: AMBARI-25062
> URL: https://issues.apache.org/jira/browse/AMBARI-25062
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Optionally execute the post user creation hook on existing users during LDAP
> sync.
> The post user creation hook is executed on users when created or imported
> into Ambari. This hook is executed given the following criteria is met:
> # The post user creation hook is enabled (ambari.properties -
> {{ambari.post.user.creation.hook.enabled = true}}, default: {{false}})
> # The post user creation hook is set and available (ambari.properties -
> {{ambari.post.user.creation.hook = }}, default:
> {{/var/lib/ambari-server/resources/scripts/post-user-creation-hook.sh}})
> # HDFS is installed and running.
> It is possible to have executed the LDAP sync process before all of the
> criteria has been met. Therefore, it would be beneficial to trigger the post
> user creation hook to be executed on these users when the criteria has been
> met.
> To do this, an optional property should be set on the LDAP sync request -
> {{post_process_existing_users}}. The {{post_process_existing_users}}
> property is part of a "spec" object and should be set to either "true" or
> "false", if set at all. If set to "true", the post user creation hook will
> be executed on all user's that come back from the LDAP query that also exist
> in the Ambari database as LDAP users.
> Example REST API calls:
> {noformat:title=Sync All Users and Groups}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "users",
> "sync_type": "all",
> "post_process_existing_users" : "true"
> },
> {
> "principal_type": "groups",
> "sync_type": "all",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> {noformat:title=Sync Specific Users}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "users",
> "sync_type": "specific",
> "names" : "user1, user2, user3",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> {noformat:title=Sync Specific Groups}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "groups",
> "sync_type": "specific",
> "names" : "hadoop_users, hadoop_admins",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> Using the Ambari sync-ldap CLI, an optional argument named
> "--post-process-existing-users" may be added to enable this feature.
> Example CLI calls:
> {noformat:title=Sync All Users and Groups}
> ambari-server sync-ldap --all --post-process-existing-users
> {noformat}
> {noformat:title=Sync Specific Users}
> ambari-server sync-ldap --users users.txt --post-process-existing-users
> {noformat}
> {noformat:title=Sync Specific Groups}
> ambari-server sync-ldap --groups groups.txt --post-process-existing-users
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-25062) Optionally execute the post user creation hook on existing users during LDAP sync
[
https://issues.apache.org/jira/browse/AMBARI-25062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-25062:
--
Status: Patch Available (was: Open)
> Optionally execute the post user creation hook on existing users during LDAP
> sync
> -
>
> Key: AMBARI-25062
> URL: https://issues.apache.org/jira/browse/AMBARI-25062
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Optionally execute the post user creation hook on existing users during LDAP
> sync.
> The post user creation hook is executed on users when created or imported
> into Ambari. This hook is executed given the following criteria is met:
> # The post user creation hook is enabled (ambari.properties -
> {{ambari.post.user.creation.hook.enabled = true}}, default: {{false}})
> # The post user creation hook is set and available (ambari.properties -
> {{ambari.post.user.creation.hook = }}, default:
> {{/var/lib/ambari-server/resources/scripts/post-user-creation-hook.sh}})
> # HDFS is installed and running.
> It is possible to have executed the LDAP sync process before all of the
> criteria has been met. Therefore, it would be beneficial to trigger the post
> user creation hook to be executed on these users when the criteria has been
> met.
> To do this, an optional property should be set on the LDAP sync request -
> {{post_process_existing_users}}. The {{post_process_existing_users}}
> property is part of a "spec" object and should be set to either "true" or
> "false", if set at all. If set to "true", the post user creation hook will
> be executed on all user's that come back from the LDAP query that also exist
> in the Ambari database as LDAP users.
> Example REST API calls:
> {noformat:title=Sync All Users and Groups}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "users",
> "sync_type": "all",
> "post_process_existing_users" : "true"
> },
> {
> "principal_type": "groups",
> "sync_type": "all",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> {noformat:title=Sync Specific Users}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "users",
> "sync_type": "specific",
> "names" : "user1, user2, user3",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> {noformat:title=Sync Specific Groups}
> POST /api/v1/ldap_sync_events
> [
> {
> "Event": {
> "specs": [
> {
> "principal_type": "groups",
> "sync_type": "specific",
> "names" : "hadoop_users, hadoop_admins",
> "post_process_existing_users" : "true"
> }
> ]
> }
> }
> ]
> {noformat}
> Using the Ambari sync-ldap CLI, an optional argument named
> "--post-process-existing-users" may be added to enable this feature.
> Example CLI calls:
> {noformat:title=Sync All Users and Groups}
> ambari-server sync-ldap --all --post-process-existing-users
> {noformat}
> {noformat:title=Sync Specific Users}
> ambari-server sync-ldap --users users.txt --post-process-existing-users
> {noformat}
> {noformat:title=Sync Specific Groups}
> ambari-server sync-ldap --groups groups.txt --post-process-existing-users
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-25062) Optionally execute the post user creation hook on existing users during LDAP sync
Robert Levas created AMBARI-25062:
-
Summary: Optionally execute the post user creation hook on
existing users during LDAP sync
Key: AMBARI-25062
URL: https://issues.apache.org/jira/browse/AMBARI-25062
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.8.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.8.0
Optionally execute the post user creation hook on existing users during LDAP
sync.
The post user creation hook is executed on users when created or imported into
Ambari. This hook is executed given the following criteria is met:
# The post user creation hook is enabled (ambari.properties -
{{ambari.post.user.creation.hook.enabled = true}}, default: {{false}})
# The post user creation hook is set and available (ambari.properties -
{{ambari.post.user.creation.hook = }}, default:
{{/var/lib/ambari-server/resources/scripts/post-user-creation-hook.sh}})
# HDFS is installed and running.
It is possible to have executed the LDAP sync process before all of the
criteria has been met. Therefore, it would be beneficial to trigger the post
user creation hook to be executed on these users when the criteria has been
met.
To do this, an optional property should be set on the LDAP sync request -
{{post_process_existing_users}}. The {{post_process_existing_users}} property
is part of a "spec" object and should be set to either "true" or "false", if
set at all. If set to "true", the post user creation hook will be executed on
all user's that come back from the LDAP query that also exist in the Ambari
database as LDAP users.
Example REST API calls:
{noformat:title=Sync All Users and Groups}
POST /api/v1/ldap_sync_events
[
{
"Event": {
"specs": [
{
"principal_type": "users",
"sync_type": "all",
"post_process_existing_users" : "true"
},
{
"principal_type": "groups",
"sync_type": "all",
"post_process_existing_users" : "true"
}
]
}
}
]
{noformat}
{noformat:title=Sync Specific Users}
POST /api/v1/ldap_sync_events
[
{
"Event": {
"specs": [
{
"principal_type": "users",
"sync_type": "specific",
"names" : "user1, user2, user3",
"post_process_existing_users" : "true"
}
]
}
}
]
{noformat}
{noformat:title=Sync Specific Groups}
POST /api/v1/ldap_sync_events
[
{
"Event": {
"specs": [
{
"principal_type": "groups",
"sync_type": "specific",
"names" : "hadoop_users, hadoop_admins",
"post_process_existing_users" : "true"
}
]
}
}
]
{noformat}
Using the Ambari sync-ldap CLI, an optional argument named
"--post-process-existing-users" may be added to enable this feature.
Example CLI calls:
{noformat:title=Sync All Users and Groups}
ambari-server sync-ldap --all --post-process-existing-users
{noformat}
{noformat:title=Sync Specific Users}
ambari-server sync-ldap --users users.txt --post-process-existing-users
{noformat}
{noformat:title=Sync Specific Groups}
ambari-server sync-ldap --groups groups.txt --post-process-existing-users
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-25013) Ambari should optionally generate auth-to-local rules for the Kerberos identities of all components of installed services
[
https://issues.apache.org/jira/browse/AMBARI-25013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712271#comment-16712271
]
Robert Levas commented on AMBARI-25013:
---
FYI: [~smolnar]
> Ambari should optionally generate auth-to-local rules for the Kerberos
> identities of all components of installed services
> -
>
> Key: AMBARI-25013
> URL: https://issues.apache.org/jira/browse/AMBARI-25013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Rohith Sharma K S
>Assignee: Robert Levas
>Priority: Major
> Labels: kerberos
> Fix For: 2.8.0
>
>
> Ambari should optionally generate auth-to-local rules for the Kerberos
> identities of all components of installed services.
> Currently Ambari will generate auth-to-local rules for the installed
> components of installed services. This is generally the accepted behavior.
> However, there may be cases where identities from remote clusters (using the
> same Kerberos realm) need to be translated to local names.
> A use case may be that some slave component for a service is installed on a
> remote cluster, but that component is not installed on the local cluster.
> However a master component of that service is installed on the local cluster
> and the slave component from the remote cluster needs to communicate with it.
> The solution is to add a new property to {{kerberos-env}}, maybe named
> something like {{include_all_components_in_auth_to_local_rules}}, where the
> default value is {{false}}. If set to {{true}}, when building the
> auth-to-local rules, Ambari should add the rules for all components of
> installed services, not just the installed components (which is what it does
> today).
> The relevant code to change is in
> {{org.apache.ambari.server.controller.KerberosHelperImpl#setAuthToLocalRules}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-25013) Ambari should optionally generate auth-to-local rules for the Kerberos identities of all components of installed services
Robert Levas created AMBARI-25013:
-
Summary: Ambari should optionally generate auth-to-local rules for
the Kerberos identities of all components of installed services
Key: AMBARI-25013
URL: https://issues.apache.org/jira/browse/AMBARI-25013
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.8.0
Reporter: Rohith Sharma K S
Assignee: Robert Levas
Fix For: 2.8.0
Ambari should optionally generate auth-to-local rules for the Kerberos
identities of all components of installed services.
Currently Ambari will generate auth-to-local rules for the installed components
of installed services. This is generally the accepted behavior. However, there
may be cases where identities from remote clusters (using the same Kerberos
realm) need to be translated to local names.
A use case may be that some slave component for a service is installed on a
remote cluster, but that component is not installed on the local cluster.
However a master component of that service is installed on the local cluster
and the slave component from the remote cluster needs to communicate with it.
The solution is to add a new property to {{kerberos-env}}, maybe named
something like {{include_all_components_in_auth_to_local_rules}}, where the
default value is {{false}}. If set to {{true}}, when building the
auth-to-local rules, Ambari should add the rules for all components of
installed services, not just the installed components (which is what it does
today).
The relevant code to change is in
{{org.apache.ambari.server.controller.KerberosHelperImpl#setAuthToLocalRules}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-25003) Starting JPA persistence service sometimes throws IllegalStateException
[
https://issues.apache.org/jira/browse/AMBARI-25003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-25003.
---
Resolution: Fixed
> Starting JPA persistence service sometimes throws IllegalStateException
> ---
>
> Key: AMBARI-25003
> URL: https://issues.apache.org/jira/browse/AMBARI-25003
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Starting JPA persistence service sometimes throws IllegalStateException.
> For example:
> {noformat}
> Exception in thread "main" java.lang.IllegalStateException: Persistence
> service was already initialized.
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:173)
> at
> com.google.inject.persist.jpa.JpaPersistService.start(JpaPersistService.java:104)
> at
> com.google.inject.persist.jpa.AmbariJpaPersistService.start(AmbariJpaPersistService.java:27)
> at
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-25003) Starting JPA persistence service sometimes throws IllegalStateException
Robert Levas created AMBARI-25003:
-
Summary: Starting JPA persistence service sometimes throws
IllegalStateException
Key: AMBARI-25003
URL: https://issues.apache.org/jira/browse/AMBARI-25003
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.8.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.8.0
Starting JPA persistence service sometimes throws IllegalStateException.
For example:
{noformat}
Exception in thread "main" java.lang.IllegalStateException: Persistence service
was already initialized.
at
com.google.common.base.Preconditions.checkState(Preconditions.java:173)
at
com.google.inject.persist.jpa.JpaPersistService.start(JpaPersistService.java:104)
at
com.google.inject.persist.jpa.AmbariJpaPersistService.start(AmbariJpaPersistService.java:27)
at
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24985) Handle requests from a configured trusted proxy to identify a proxied user using Kerberos
[
https://issues.apache.org/jira/browse/AMBARI-24985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24985:
--
Status: Patch Available (was: Open)
> Handle requests from a configured trusted proxy to identify a proxied user
> using Kerberos
> -
>
> Key: AMBARI-24985
> URL: https://issues.apache.org/jira/browse/AMBARI-24985
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, tproxy
> Fix For: 2.8.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Handle requests from a configured trusted proxy to identify a proxied user
> using Kerberos.
> Upon receiving a request where that caller is identified using Kerberos,
> check to see of the request was from a (trusted) proxy. If so, validate the
> trusted proxy and set the authenticated user to the proxied user specified in
> the "{{doAs}}" query parameter.
> After receiving a request where the user is to be authenticated using
> Kerberos, perform the following steps:
> # Determine if a proxied user is specified using a "{{doAs}}" query
> parameter.
> # Using the following Ambari configuration property, determine if a proxied
> user can be specified from the requesting host:
> ** {{ambari.tproxy.proxyuser.$username.hosts}}, where $username is the
> username of the authenticated user (not the user specified in the doAs query
> parameter)
> # Obtain the proxied username from the {{doAs}} query parameter
> # Using the following Ambari configuration property, determine if the proxied
> user can be specified based on the user's username:
> ** {{ambari.tproxy.proxyuser.$username.users}}, where $username is the
> username of the authenticated user
> # Using the following Ambari configuration property, determine if the proxied
> user can be specified based on the groups the proxied user belong to:
> ** {{ambari.tproxy.proxyuser.$username.groups}}, where $username is the
> username of the authenticated user t
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24985) Handle requests from a configured trusted proxy to identify a proxied user using Kerberos
[
https://issues.apache.org/jira/browse/AMBARI-24985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24985:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Handle requests from a configured trusted proxy to identify a proxied user
> using Kerberos
> -
>
> Key: AMBARI-24985
> URL: https://issues.apache.org/jira/browse/AMBARI-24985
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, tproxy
> Fix For: 2.8.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Handle requests from a configured trusted proxy to identify a proxied user
> using Kerberos.
> Upon receiving a request where that caller is identified using Kerberos,
> check to see of the request was from a (trusted) proxy. If so, validate the
> trusted proxy and set the authenticated user to the proxied user specified in
> the "{{doAs}}" query parameter.
> After receiving a request where the user is to be authenticated using
> Kerberos, perform the following steps:
> # Determine if a proxied user is specified using a "{{doAs}}" query
> parameter.
> # Using the following Ambari configuration property, determine if a proxied
> user can be specified from the requesting host:
> ** {{ambari.tproxy.proxyuser.$username.hosts}}, where $username is the
> username of the authenticated user (not the user specified in the doAs query
> parameter)
> # Obtain the proxied username from the {{doAs}} query parameter
> # Using the following Ambari configuration property, determine if the proxied
> user can be specified based on the user's username:
> ** {{ambari.tproxy.proxyuser.$username.users}}, where $username is the
> username of the authenticated user
> # Using the following Ambari configuration property, determine if the proxied
> user can be specified based on the groups the proxied user belong to:
> ** {{ambari.tproxy.proxyuser.$username.groups}}, where $username is the
> username of the authenticated user t
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24986) Use Ambari CLI to enable and disable trusted proxy support in Ambari
[
https://issues.apache.org/jira/browse/AMBARI-24986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24986:
--
Description:
Use Ambari CLI to enable and disable trusted proxy support in Ambari.
Information needed to be collected:
* Enable/Disable trusted proxy support
** {{ambari.tproxy.authentication.enabled}} : "true"|"false"
* Trusted proxy user (the authenticated user allowed to declare a proxied
user) details - One or more may be specified
** hosts from which the proxy user can connect
*** {{ambari.tproxy.proxyuser.PROXY_USER.hosts}} : * or a comma-delimited list
of hostname, ip address, CIDR Notation (intermixed is ok)
** users allowed to be specified as proxied users by the proxy user
*** {{ambari.tproxy.proxyuser.PROXY_USER.users}} : *, or a comma-delimited
list of usernames
** group for which users to be proxied are members
*** {{ambari.tproxy.proxyuser.PROXY_USER.groups}} : *, or a comma-delimited
list of group names
{noformat}
[root@c7402 ~]# ambari-server setup-trusted-proxy
Using python /usr/bin/python
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching Trusted Proxy configuration from DB.
Trusted Proxy support is currently disabled
Do you want to configure Trusted Proxy support [y/n] (y)? y
The proxy user's (local) username? knox
Allowed hosts for knox (*)? knox.ambari.apache.org
Allowed users for knox (*)? *
Allowed groups for knox (*)? users
Add another proxy user [y/n]? y
The proxy user's (local) username? admin
Allowed hosts for admin (*)? 192.168.74.0/24
Allowed users for admin (*)? tom, sam, admin
Allowed groups for admin (*)? admin_users
Add another proxy user [y/n]? n
Save settings [y/n] (y)? y
Saving Trusted Proxy configuration...
Saving Trusted Proxy configuration finished
Ambari Server ' setup-trusted-proxy' completed successfully.
{noformat}
The REST API calls to get and set the trusted proxy configurations are
{noformat:title=GET request}
GET
/api/v1/services/AMBARI/components/AMBARI_SERVER/configurations/tproxy-configuration
{noformat}
{noformat:title=GET example response}
{
"href" :
"http://c7401.ambari.apache.org:8080/api/v1/services/AMBARI/components/AMBARI_SERVER/configurations/tproxy-configuration";,
"Configuration" : {
"category" : "tproxy-configuration",
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"properties" : {
"ambari.tproxy.authentication.enabled" : "true",
"ambari.tproxy.proxyuser.admin.groups" : "admin_users",
"ambari.tproxy.proxyuser.admin.hosts" : "192.168.74.0/24",
"ambari.tproxy.proxyuser.admin.users" : "sam, tom, admin",
"ambari.tproxy.proxyuser.knox.groups" : "users",
"ambari.tproxy.proxyuser.knox.hosts" : "c7401.ambari.apache.org",
"ambari.tproxy.proxyuser.knox.users" : "*"
},
"property_types" : {
"ambari.tproxy.authentication.enabled" : "PLAINTEXT",
"ambari.tproxy.proxyuser.admin.groups" : "PLAINTEXT",
"ambari.tproxy.proxyuser.admin.hosts" : "PLAINTEXT",
"ambari.tproxy.proxyuser.admin.users" : "PLAINTEXT",
"ambari.tproxy.proxyuser.knox.groups" : "PLAINTEXT",
"ambari.tproxy.proxyuser.knox.hosts" : "PLAINTEXT",
"ambari.tproxy.proxyuser.knox.users" : "PLAINTEXT"
}
}
}
{noformat}
{noformat:title=POST request}
POST /api/v1/services/AMBARI/components/AMBARI_SERVER/configurations
{
"Configuration": {
"category" : "tproxy-configuration",
"properties": {
"ambari.tproxy.authentication.enabled" : "true",
"ambari.tproxy.proxyuser.knox.hosts": "c7401.ambari.apache.org",
"ambari.tproxy.proxyuser.knox.users": "*",
"ambari.tproxy.proxyuser.knox.groups": "users",
"ambari.tproxy.proxyuser.admin.hosts": "192.168.74.0/24",
"ambari.tproxy.proxyuser.admin.users": "sam, tom, admin",
"ambari.tproxy.proxyuser.admin.groups": "admin_users"
}
}
}{noformat}
was:
Use Ambari CLI to enable and disable trusted proxy support in Ambari.
Information needed to be collected:
* Enable/Disable trusted proxy support
** {{ambari.tproxy.authentication.enabled}} : "true"|"false"
* Trusted proxy user (the authenticated user allowed to declare a proxied
user) details - One or more may be specified
** hosts from which the proxy user can connect
*** {{ambari.tproxy.proxyuser.PROXY_USER.hosts}} : * or a comma-delimited list
of hostname, ip address, CIDR Notation (intermixed is ok)
** users allowed to be specified as proxied users by the proxy user
*** {{ambari.tproxy.proxyuser.PROXY_USER.users}} : *, or a comma-delimited
list of usernames
** group for which users to be proxied are members
*** {{ambari.tproxy.proxyuser.PROXY_USER.groups}} : *, or a comma-delimited
list of group names
{noformat}
[root@c7402 ~]# ambari-server setup-tproxy
Using python /usr/bin/python
Enter Ambari Admin login: admin
Enter Ambari Admin password:
Fetching Trusted Proxy confi
[jira] [Created] (AMBARI-24985) Handle requests from a configured trusted proxy to identify a proxied user using Kerberos
Robert Levas created AMBARI-24985:
-
Summary: Handle requests from a configured trusted proxy to
identify a proxied user using Kerberos
Key: AMBARI-24985
URL: https://issues.apache.org/jira/browse/AMBARI-24985
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: 2.8.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.8.0
Handle requests from a configured trusted proxy to identify a proxied user
using Kerberos.
Upon receiving a request where that caller is identified using Kerberos, check
to see of the request was from a (trusted) proxy. If so, validate the trusted
proxy and set the authenticated user to the proxied user specified in the
"{{doAs}}" query parameter.
After receiving a request where the user is to be authenticated using Kerberos,
perform the following steps:
# Determine if a proxied user is specified using a "{{doAs}}" query parameter.
# Using the following Ambari configuration property, determine if a proxied
user can be specified from the requesting host:
** {{ambari.tproxy.proxyuser.$username.hosts}}, where $username is the username
of the authenticated user (not the user specified in the doAs query parameter)
# Obtain the proxied username from the {{doAs}} query parameter
# Using the following Ambari configuration property, determine if the proxied
user can be specified based on the user's username:
** {{ambari.tproxy.proxyuser.$username.users}}, where $username is the username
of the authenticated user
# Using the following Ambari configuration property, determine if the proxied
user can be specified based on the groups the proxied user belong to:
** {{ambari.tproxy.proxyuser.$username.groups}}, where $username is the
username of the authenticated user t
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-24955) Create Tproxy configuration provider and supporting infrastructure
[ https://issues.apache.org/jira/browse/AMBARI-24955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas resolved AMBARI-24955. --- Resolution: Fixed > Create Tproxy configuration provider and supporting infrastructure > -- > > Key: AMBARI-24955 > URL: https://issues.apache.org/jira/browse/AMBARI-24955 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.8.0 >Reporter: Robert Levas >Assignee: Robert Levas >Priority: Major > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Create Tproxy configuration provider and supporting infrastructure. > Also create a common configuration provider infrastructure for Ambari Server > Configuration data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-22971) Remove current_mpack_id to mpack_id in stacks table
[ https://issues.apache.org/jira/browse/AMBARI-22971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-22971: -- Affects Version/s: (was: 3.0.0) 2.8.0 > Remove current_mpack_id to mpack_id in stacks table > --- > > Key: AMBARI-22971 > URL: https://issues.apache.org/jira/browse/AMBARI-22971 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.8.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Critical > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-22971) Remove current_mpack_id to mpack_id in stacks table
[ https://issues.apache.org/jira/browse/AMBARI-22971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-22971: -- Fix Version/s: (was: 3.0.0) 2.8.0 > Remove current_mpack_id to mpack_id in stacks table > --- > > Key: AMBARI-22971 > URL: https://issues.apache.org/jira/browse/AMBARI-22971 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.8.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Critical > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24955) Create Tproxy configuration provider and supporting infrastructure
Robert Levas created AMBARI-24955: - Summary: Create Tproxy configuration provider and supporting infrastructure Key: AMBARI-24955 URL: https://issues.apache.org/jira/browse/AMBARI-24955 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 2.8.0 Reporter: Robert Levas Assignee: Robert Levas Fix For: 2.8.0 Create Tproxy configuration provider and supporting infrastructure. Also create a common configuration provider infrastructure for Ambari Server Configuration data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24923) Create tproxy-configuration category in Ambari Configurations data
[
https://issues.apache.org/jira/browse/AMBARI-24923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24923:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Create tproxy-configuration category in Ambari Configurations data
> ---
>
> Key: AMBARI-24923
> URL: https://issues.apache.org/jira/browse/AMBARI-24923
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, tproxy
> Fix For: 2.8.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Create tproxy-configuration category in Ambari Configurations data with the
> following properties:
> * {{ambari.tproxy.authentication.enabled}}
> ** Determines whether to allow trusted proxy authentication when logging into
> Ambari
> ** {{true}} | {{false}}
> * {{ambari.tproxy.proxyuser.$username.hosts}}
> ** List of hosts from which trusted-proxy user ‘$username’ can connect from
> ** {{\*}} | {{c7401.ambari.apache.org}} | {{10.42.80.64,10.42.80.65}} |
> {{10.222.0.0/16,10.113.221.221}}
> * {{ambari.tproxy.proxyuser.$username.users}}
> ** List of users which the trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{user1,user2}}
> * {{ambari.tproxy.proxyuser.$username.groups}}
> ** List of user-groups which trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{group1,group2}}
> Note: {{$username}} is variable, declaring the values for a particular proxy
> user. For example "knox".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24923) Create tproxy-configuration category in Ambari Configurations data
[
https://issues.apache.org/jira/browse/AMBARI-24923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24923:
--
Status: Patch Available (was: Open)
> Create tproxy-configuration category in Ambari Configurations data
> ---
>
> Key: AMBARI-24923
> URL: https://issues.apache.org/jira/browse/AMBARI-24923
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, tproxy
> Fix For: 2.8.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Create tproxy-configuration category in Ambari Configurations data with the
> following properties:
> * {{ambari.tproxy.authentication.enabled}}
> ** Determines whether to allow trusted proxy authentication when logging into
> Ambari
> ** {{true}} | {{false}}
> * {{ambari.tproxy.proxyuser.$username.hosts}}
> ** List of hosts from which trusted-proxy user ‘$username’ can connect from
> ** {{\*}} | {{c7401.ambari.apache.org}} | {{10.42.80.64,10.42.80.65}} |
> {{10.222.0.0/16,10.113.221.221}}
> * {{ambari.tproxy.proxyuser.$username.users}}
> ** List of users which the trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{user1,user2}}
> * {{ambari.tproxy.proxyuser.$username.groups}}
> ** List of user-groups which trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{group1,group2}}
> Note: {{$username}} is variable, declaring the values for a particular proxy
> user. For example "knox".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24420) XSS in Ambari Add Host Wizard
[
https://issues.apache.org/jira/browse/AMBARI-24420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694708#comment-16694708
]
Robert Levas commented on AMBARI-24420:
---
[~juliaw]...
Thanks for the report. Can you email this to
[secur...@apache.org|mailto:secur...@apache.org] and
[priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on
how to reproduce the issue. Do not add these details here since we do not want
suck information out in the public until the vulnerability is fixed.
> XSS in Ambari Add Host Wizard
> -
>
> Key: AMBARI-24420
> URL: https://issues.apache.org/jira/browse/AMBARI-24420
> Project: Ambari
> Issue Type: Bug
> Components: ambari-client
>Affects Versions: 2.7.1
>Reporter: Julia
>Assignee: Robert Levas
>Priority: Critical
>
> It is possible for an attacker to steal information or access from users by
> executing malicious JavaScript. This is possible due to the use of a
> javascript "eval()" function when loading the SSH private key. Leveraging
> this any malicious data in any file uploaded, not just private keys, would
> execute. In the case of private keys, malicious script in the metadata of the
> key would execute. An attacker could directly scrap and information on the
> page, modify its appearance, or steal the users sessions information.
>
> Repro:
>
> +{color:#0066cc}[https://x.azurehdinsight.net/#/main/host/add/step1]{color}+
> !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/f65e2526-613e-4af7-910e-7a19a4376a6d?fileName=attachfilehandler.png!
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24419) XSS attack in Ambari Config History
[ https://issues.apache.org/jira/browse/AMBARI-24419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694707#comment-16694707 ] Robert Levas commented on AMBARI-24419: --- [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want suck information out in the public until the vulnerability is fixed. > XSS attack in Ambari Config History > --- > > Key: AMBARI-24419 > URL: https://issues.apache.org/jira/browse/AMBARI-24419 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > It is possible for an attacker to steal information or access from users by > executing malicious JavaScript. This is possible due to the use of a > javascript "eval()" function when loading the notes from config history > change. Leveraging this one user could create a malicious history entry to > steal access or information of another user. Upon viewing the malicious > historical entry the victim would be comprimised by directly scraping any > information on the page, modify its appearance, or having their session > information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/81b481b3-397c-442e-b0aa-199ff793a05d?fileName=attachfilehandler%20%283%29.png! > > > fg > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-24420) XSS in Ambari Add Host Wizard
[
https://issues.apache.org/jira/browse/AMBARI-24420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reassigned AMBARI-24420:
-
Assignee: Robert Levas
> XSS in Ambari Add Host Wizard
> -
>
> Key: AMBARI-24420
> URL: https://issues.apache.org/jira/browse/AMBARI-24420
> Project: Ambari
> Issue Type: Bug
> Components: ambari-client
>Affects Versions: 2.7.1
>Reporter: Julia
>Assignee: Robert Levas
>Priority: Critical
>
> It is possible for an attacker to steal information or access from users by
> executing malicious JavaScript. This is possible due to the use of a
> javascript "eval()" function when loading the SSH private key. Leveraging
> this any malicious data in any file uploaded, not just private keys, would
> execute. In the case of private keys, malicious script in the metadata of the
> key would execute. An attacker could directly scrap and information on the
> page, modify its appearance, or steal the users sessions information.
>
> Repro:
>
> +{color:#0066cc}[https://x.azurehdinsight.net/#/main/host/add/step1]{color}+
> !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/f65e2526-613e-4af7-910e-7a19a4376a6d?fileName=attachfilehandler.png!
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24418) XSS attack in Ambari Alerts
[ https://issues.apache.org/jira/browse/AMBARI-24418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694706#comment-16694706 ] Robert Levas commented on AMBARI-24418: --- [~juliaw]... Thanks for the report. Can you email this to [secur...@apache.org|mailto:secur...@apache.org] and [priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] with details on how to reproduce the issue. Do not add these details here since we do not want suck information out in the public until the vulnerability is fixed. > XSS attack in Ambari Alerts > --- > > Key: AMBARI-24418 > URL: https://issues.apache.org/jira/browse/AMBARI-24418 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > > It is possible for an attacker to steal information or access from users by > executing malicious javascript. This is possible due to the use of a > javascript "eval()" function when loading the description of alerts. > Leveraging this one user could create a malicious alert to steal access or > information of another user. Upon viewing the maliicous alert the vicitim > would be comprimised by directly scraping any information on the page, modify > its appearence, or having their session information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/8dfe7e85-4c5a-4632-90c8-73696cfe727a?fileName=attachfilehandler%20%282%29.png! > Repro steps > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/6aebfcf6-9d34-45d5-bf88-c2d43431f84f?fileName=attachfilehandler%20%281%29.png! > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-24419) XSS attack in Ambari Config History
[ https://issues.apache.org/jira/browse/AMBARI-24419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas reassigned AMBARI-24419: - Assignee: Robert Levas > XSS attack in Ambari Config History > --- > > Key: AMBARI-24419 > URL: https://issues.apache.org/jira/browse/AMBARI-24419 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > It is possible for an attacker to steal information or access from users by > executing malicious JavaScript. This is possible due to the use of a > javascript "eval()" function when loading the notes from config history > change. Leveraging this one user could create a malicious history entry to > steal access or information of another user. Upon viewing the malicious > historical entry the victim would be comprimised by directly scraping any > information on the page, modify its appearance, or having their session > information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/81b481b3-397c-442e-b0aa-199ff793a05d?fileName=attachfilehandler%20%283%29.png! > > > fg > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-24418) XSS attack in Ambari Alerts
[ https://issues.apache.org/jira/browse/AMBARI-24418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas reassigned AMBARI-24418: - Assignee: Robert Levas > XSS attack in Ambari Alerts > --- > > Key: AMBARI-24418 > URL: https://issues.apache.org/jira/browse/AMBARI-24418 > Project: Ambari > Issue Type: Bug > Components: ambari-client >Affects Versions: 2.7.1 >Reporter: Julia >Assignee: Robert Levas >Priority: Critical > > > It is possible for an attacker to steal information or access from users by > executing malicious javascript. This is possible due to the use of a > javascript "eval()" function when loading the description of alerts. > Leveraging this one user could create a malicious alert to steal access or > information of another user. Upon viewing the maliicous alert the vicitim > would be comprimised by directly scraping any information on the page, modify > its appearence, or having their session information stolen. > > > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/8dfe7e85-4c5a-4632-90c8-73696cfe727a?fileName=attachfilehandler%20%282%29.png! > Repro steps > !https://msdata.visualstudio.com/0cd33d4d-ce7c-416d-ab00-26e15edb66e6/_apis/wit/attachments/6aebfcf6-9d34-45d5-bf88-c2d43431f84f?fileName=attachfilehandler%20%281%29.png! > > > > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24634) Ambari Cross Site Scripting Vulnerability
[
https://issues.apache.org/jira/browse/AMBARI-24634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694702#comment-16694702
]
Robert Levas commented on AMBARI-24634:
---
[~andrzej.jedrzejewski87], Thanks for the report. Can you send this in an
email to [secur...@apache.or|mailto:secur...@apache.or]g and
[priv...@ambari.apache.org|mailto:priv...@ambari.apache.org] and delete this
JIRA. We do not want such details out in the public until the vulnerability is
solved.
> Ambari Cross Site Scripting Vulnerability
> -
>
> Key: AMBARI-24634
> URL: https://issues.apache.org/jira/browse/AMBARI-24634
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.6.2
> Environment: Ambari 2.6.2.2
> HDP 2.6.5.0
>Reporter: Andrzej Jedrzejewski
>Assignee: Robert Levas
>Priority: Major
>
> The attack was done through the Ambari "Files" module. It occurred when
> creating a new folder on the application by clicking on the "New Folder"
> option. From here I named the folder as
> ">.
> Once you save the payload as the new folder the page will refresh and from
> there the application will load the payload and execute the javascript within
> the "onload" attribute.
> Here is the HTTP request used for this attack.
> PUT
> /ambarihost/gateway/ambari/api/v1/views/FILES/versions/1.0.0/instances/AUTO_FILES_INSTANCE/resources/files/fileops/mkdir
> HTTP/1.1
> [Redacted...]
> {"path":"/test\">"}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (AMBARI-24634) Ambari Cross Site Scripting Vulnerability
[
https://issues.apache.org/jira/browse/AMBARI-24634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reassigned AMBARI-24634:
-
Assignee: Robert Levas
> Ambari Cross Site Scripting Vulnerability
> -
>
> Key: AMBARI-24634
> URL: https://issues.apache.org/jira/browse/AMBARI-24634
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.6.2
> Environment: Ambari 2.6.2.2
> HDP 2.6.5.0
>Reporter: Andrzej Jedrzejewski
>Assignee: Robert Levas
>Priority: Major
>
> The attack was done through the Ambari "Files" module. It occurred when
> creating a new folder on the application by clicking on the "New Folder"
> option. From here I named the folder as
> ">.
> Once you save the payload as the new folder the page will refresh and from
> there the application will load the payload and execute the javascript within
> the "onload" attribute.
> Here is the HTTP request used for this attack.
> PUT
> /ambarihost/gateway/ambari/api/v1/views/FILES/versions/1.0.0/instances/AUTO_FILES_INSTANCE/resources/files/fileops/mkdir
> HTTP/1.1
> [Redacted...]
> {"path":"/test\">"}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24923) Create tproxy-configuration category in Ambari Configurations data
[
https://issues.apache.org/jira/browse/AMBARI-24923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24923:
--
Fix Version/s: (was: ambari-2.8)
2.8.0
> Create tproxy-configuration category in Ambari Configurations data
> ---
>
> Key: AMBARI-24923
> URL: https://issues.apache.org/jira/browse/AMBARI-24923
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: tproxy
> Fix For: 2.8.0
>
>
> Create tproxy-configuration category in Ambari Configurations data with the
> following properties:
> * {{ambari.tproxy.authentication.enabled}}
> ** Determines whether to allow trusted proxy authentication when logging into
> Ambari
> ** {{true}} | {{false}}
> * {{ambari.tproxy.proxyuser.$username.hosts}}
> ** List of hosts from which trusted-proxy user ‘$username’ can connect from
> ** {{\*}} | {{c7401.ambari.apache.org}} | {{10.42.80.64,10.42.80.65}} |
> {{10.222.0.0/16,10.113.221.221}}
> * {{ambari.tproxy.proxyuser.$username.users}}
> ** List of users which the trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{user1,user2}}
> * {{ambari.tproxy.proxyuser.$username.groups}}
> ** List of user-groups which trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{group1,group2}}
> Note: {{$username}} is variable, declaring the values for a particular proxy
> user. For example "knox".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24923) Create tproxy-configuration category in Ambari Configurations data
[
https://issues.apache.org/jira/browse/AMBARI-24923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24923:
--
Affects Version/s: (was: ambari-2.8)
2.8.0
> Create tproxy-configuration category in Ambari Configurations data
> ---
>
> Key: AMBARI-24923
> URL: https://issues.apache.org/jira/browse/AMBARI-24923
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: tproxy
> Fix For: 2.8.0
>
>
> Create tproxy-configuration category in Ambari Configurations data with the
> following properties:
> * {{ambari.tproxy.authentication.enabled}}
> ** Determines whether to allow trusted proxy authentication when logging into
> Ambari
> ** {{true}} | {{false}}
> * {{ambari.tproxy.proxyuser.$username.hosts}}
> ** List of hosts from which trusted-proxy user ‘$username’ can connect from
> ** {{\*}} | {{c7401.ambari.apache.org}} | {{10.42.80.64,10.42.80.65}} |
> {{10.222.0.0/16,10.113.221.221}}
> * {{ambari.tproxy.proxyuser.$username.users}}
> ** List of users which the trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{user1,user2}}
> * {{ambari.tproxy.proxyuser.$username.groups}}
> ** List of user-groups which trusted-proxy user ‘$username’ can proxy for
> ** {{\*}} | {{group1,group2}}
> Note: {{$username}} is variable, declaring the values for a particular proxy
> user. For example "knox".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24923) Create tproxy-configuration category in Ambari Configurations data
Robert Levas created AMBARI-24923:
-
Summary: Create tproxy-configuration category in Ambari
Configurations data
Key: AMBARI-24923
URL: https://issues.apache.org/jira/browse/AMBARI-24923
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: ambari-2.8
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: ambari-2.8
Create tproxy-configuration category in Ambari Configurations data with the
following properties:
* {{ambari.tproxy.authentication.enabled}}
** Determines whether to allow trusted proxy authentication when logging into
Ambari
** {{true}} | {{false}}
* {{ambari.tproxy.proxyuser.$username.hosts}}
** List of hosts from which trusted-proxy user ‘$username’ can connect from
** {{\*}} | {{c7401.ambari.apache.org}} | {{10.42.80.64,10.42.80.65}} |
{{10.222.0.0/16,10.113.221.221}}
* {{ambari.tproxy.proxyuser.$username.users}}
** List of users which the trusted-proxy user ‘$username’ can proxy for
** {{\*}} | {{user1,user2}}
* {{ambari.tproxy.proxyuser.$username.groups}}
** List of user-groups which trusted-proxy user ‘$username’ can proxy for
** {{\*}} | {{group1,group2}}
Note: {{$username}} is variable, declaring the values for a particular proxy
user. For example "knox".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-23252) Update service metainfo to declare SSO integration support
[
https://issues.apache.org/jira/browse/AMBARI-23252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-23252:
--
Description:
Update service metainfo to declare SSO integration support. The following tag
may be optionally set in a service's {{metainfo.xml}} file:
{code:java}
true
config-type/sso.enabled.property
{code}
was:
Update service metainfo to declare SSO integration support. The following tag
may be optionally set in a service's \{{metainfo.xml}} file:
{code}
true
config-type/sso.enabled.property
{code}
> Update service metainfo to declare SSO integration support
> --
>
> Key: AMBARI-23252
> URL: https://issues.apache.org/jira/browse/AMBARI-23252
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: pull-request-available, sso
> Fix For: 2.7.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Update service metainfo to declare SSO integration support. The following tag
> may be optionally set in a service's {{metainfo.xml}} file:
> {code:java}
>
> true
> config-type/sso.enabled.property
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24869) Request configurations when needed during server-side actions rather than rely on configuration data from the execution command
[
https://issues.apache.org/jira/browse/AMBARI-24869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679857#comment-16679857
]
Robert Levas commented on AMBARI-24869:
---
The reason for this JIRA is because the patch for AMBARI-24722 breaks enabling
Kerberos.
Since configurations are no longer set in ExecutionCommand at
https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java#L2468,
the kerberos-env command data is not available to the task creation process
starting at
https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java#L4128.
Therefore when the initial Kerberos service check is invoked, the needed data
is not available and the processes fails.
{noformat}
Failed to process the identities, could not properly open the KDC operation
handler: Failed to kinit as the KDC administrator user, admin/admin:
ExitCode: 1
STDOUT:
STDERR: kinit: Server not found in Kerberos database while getting initial
credentials
{noformat}
>From the krb5kdc.log
{noformat}
Nov 07 21:46:39 c7401.ambari.apache.org krb5kdc[14431](info): AS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 192.168.74.101: SERVER_NOT_FOUND:
admin/ad...@example.com for kadmin/n...@example.com, Server not found in
Kerberos database
{noformat}
The {{null}} in {{kadmin/n...@example.com}} is coming from the missing
{{kerberos-env/admin_server_host}} property when running the server-side task
to create the test identity.
> Request configurations when needed during server-side actions rather than
> rely on configuration data from the execution command
> ---
>
> Key: AMBARI-24869
> URL: https://issues.apache.org/jira/browse/AMBARI-24869
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.8.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.8.0
>
>
> Request configurations when needed during server-side actions rather than
> rely on configuration data from the execution command.
> Due to a recent change, which appeared to remove configuration data from the
> execution command JSON document, data needed for Kerberos-related
> service-side actions is missing. This data may be requested when needed from
> the cluster data at the time of execution rather than when setting up the
> stages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24869) Request configurations when needed during server-side actions rather than rely on configuration data from the execution command
Robert Levas created AMBARI-24869: - Summary: Request configurations when needed during server-side actions rather than rely on configuration data from the execution command Key: AMBARI-24869 URL: https://issues.apache.org/jira/browse/AMBARI-24869 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.8.0 Reporter: Robert Levas Assignee: Robert Levas Fix For: 2.8.0 Request configurations when needed during server-side actions rather than rely on configuration data from the execution command. Due to a recent change, which appeared to remove configuration data from the execution command JSON document, data needed for Kerberos-related service-side actions is missing. This data may be requested when needed from the cluster data at the time of execution rather than when setting up the stages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24869) Request configurations when needed during server-side actions rather than rely on configuration data from the execution command
[ https://issues.apache.org/jira/browse/AMBARI-24869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24869: -- Status: Patch Available (was: In Progress) > Request configurations when needed during server-side actions rather than > rely on configuration data from the execution command > --- > > Key: AMBARI-24869 > URL: https://issues.apache.org/jira/browse/AMBARI-24869 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.8.0 >Reporter: Robert Levas >Assignee: Robert Levas >Priority: Major > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Request configurations when needed during server-side actions rather than > rely on configuration data from the execution command. > Due to a recent change, which appeared to remove configuration data from the > execution command JSON document, data needed for Kerberos-related > service-side actions is missing. This data may be requested when needed from > the cluster data at the time of execution rather than when setting up the > stages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24869) Request configurations when needed during server-side actions rather than rely on configuration data from the execution command
[ https://issues.apache.org/jira/browse/AMBARI-24869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24869: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Request configurations when needed during server-side actions rather than > rely on configuration data from the execution command > --- > > Key: AMBARI-24869 > URL: https://issues.apache.org/jira/browse/AMBARI-24869 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.8.0 >Reporter: Robert Levas >Assignee: Robert Levas >Priority: Major > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Request configurations when needed during server-side actions rather than > rely on configuration data from the execution command. > Due to a recent change, which appeared to remove configuration data from the > execution command JSON document, data needed for Kerberos-related > service-side actions is missing. This data may be requested when needed from > the cluster data at the time of execution rather than when setting up the > stages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24827) LDAP users fail to authenticate using LDAPS due to 'No subject alternative DNS name' exception
[
https://issues.apache.org/jira/browse/AMBARI-24827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24827:
--
Summary: LDAP users fail to authenticate using LDAPS due to 'No subject
alternative DNS name' exception (was: LDAP users fail to authenticate using
LDAPS due to `No subject alternative DNS name` exception)
> LDAP users fail to authenticate using LDAPS due to 'No subject alternative
> DNS name' exception
> --
>
> Key: AMBARI-24827
> URL: https://issues.apache.org/jira/browse/AMBARI-24827
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.3
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.3
>
>
> LDAP users fail to authenticate using LDAPS due to `No subject alternative
> DNS name` exception:
> {noformat}
> 2018-10-26 14:49:45,716 WARN [ambari-client-thread-37]
> AmbariLdapAuthenticationProvider:126 - Failed to communicate with the LDAP
> server: simple bind failed: ad.example.com:636; nested exception is
> javax.naming.CommunicationException: simple bind failed: ad.example.com:636
> [Root exception is javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: No subject alternative DNS name
> matching ad.example.com found.]
> {noformat}
> This is the other half of the issue from AMBARI-24533 (which was related to
> the LDAP sync process).
> Note: If LDAP sync is performed before a user attempts to log in, then the
> issue will not be seen since the system property,
> {{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have
> already been set to "true". However, the logic path setting this value is
> not reached for an authentication attempt.
> Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
> {noformat}
> openjdk version "1.8.0_191"
> OpenJDK Runtime Environment (build 1.8.0_191-b12)
> OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
> {noformat}
> This does not occur with Oracle JDK 1.8.0.112
> {noformat}
> java version "1.8.0_112"
> Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24827) LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS name` exception
[
https://issues.apache.org/jira/browse/AMBARI-24827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24827:
--
Description:
LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS
name` exception:
{noformat}
2018-10-26 14:49:45,716 WARN [ambari-client-thread-37]
AmbariLdapAuthenticationProvider:126 - Failed to communicate with the LDAP
server: simple bind failed: ad.example.com:636; nested exception is
javax.naming.CommunicationException: simple bind failed: ad.example.com:636
[Root exception is javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name
matching ad.example.com found.]
{noformat}
This is the other half of the issue from AMBARI-24533 (which was related to the
LDAP sync process).
Note: If LDAP sync is performed before a user attempts to log in, then the
issue will not be seen since the system property,
{{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have already
been set to "true". However, the logic path setting this value is not reached
for an authentication attempt.
Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
{noformat}
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
{noformat}
This does not occur with Oracle JDK 1.8.0.112
{noformat}
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
{noformat}
was:
LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS
name` exception:
{noformat}
25 Oct 2018 18:42:49,817 WARN [ambari-client-thread-37]
AmbariLdapAuthenticationProvider:84 - Failed to communicate with the LDAP
server: simple bind failed: ad.example.com:636; nested exception is
javax.naming.CommunicationException: simple bind failed: ad.example.com:636
[Root exception is javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name
matching ad.example.com found.]
{noformat}
This is the other half of the issue from AMBARI-24533 (which was related to the
LDAP sync process).
Note: If LDAP sync is performed before a user attempts to log in, then the
issue will not be seen since the system property,
{{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have already
been set to "true". However, the logic path setting this value is not reached
for an authentication attempt.
Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
{noformat}
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
{noformat}
This does not occur with Oracle JDK 1.8.0.112
{noformat}
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
{noformat}
> LDAP users fail to authenticate using LDAPS due to `No subject alternative
> DNS name` exception
> --
>
> Key: AMBARI-24827
> URL: https://issues.apache.org/jira/browse/AMBARI-24827
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.3
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.3
>
>
> LDAP users fail to authenticate using LDAPS due to `No subject alternative
> DNS name` exception:
> {noformat}
> 2018-10-26 14:49:45,716 WARN [ambari-client-thread-37]
> AmbariLdapAuthenticationProvider:126 - Failed to communicate with the LDAP
> server: simple bind failed: ad.example.com:636; nested exception is
> javax.naming.CommunicationException: simple bind failed: ad.example.com:636
> [Root exception is javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: No subject alternative DNS name
> matching ad.example.com found.]
> {noformat}
> This is the other half of the issue from AMBARI-24533 (which was related to
> the LDAP sync process).
> Note: If LDAP sync is performed before a user attempts to log in, then the
> issue will not be seen since the system property,
> {{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have
> already been set to "true". However, the logic path setting this value is
> not reached for an authentication attempt.
> Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
> {noformat}
> openjdk version "1.8.0_191"
> OpenJDK Runtime Environment (build 1.8.0_191-b12)
> OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
> {noformat}
> This does not occur with Oracle JDK 1.8.0.112
> {noformat}
> java version
[jira] [Updated] (AMBARI-24827) LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS name` exception
[
https://issues.apache.org/jira/browse/AMBARI-24827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24827:
--
Affects Version/s: (was: 2.6.2)
2.7.3
> LDAP users fail to authenticate using LDAPS due to `No subject alternative
> DNS name` exception
> --
>
> Key: AMBARI-24827
> URL: https://issues.apache.org/jira/browse/AMBARI-24827
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.3
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.3
>
>
> LDAP users fail to authenticate using LDAPS due to `No subject alternative
> DNS name` exception:
> {noformat}
> 2018-10-26 14:49:45,716 WARN [ambari-client-thread-37]
> AmbariLdapAuthenticationProvider:126 - Failed to communicate with the LDAP
> server: simple bind failed: ad.example.com:636; nested exception is
> javax.naming.CommunicationException: simple bind failed: ad.example.com:636
> [Root exception is javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: No subject alternative DNS name
> matching ad.example.com found.]
> {noformat}
> This is the other half of the issue from AMBARI-24533 (which was related to
> the LDAP sync process).
> Note: If LDAP sync is performed before a user attempts to log in, then the
> issue will not be seen since the system property,
> {{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have
> already been set to "true". However, the logic path setting this value is
> not reached for an authentication attempt.
> Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
> {noformat}
> openjdk version "1.8.0_191"
> OpenJDK Runtime Environment (build 1.8.0_191-b12)
> OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
> {noformat}
> This does not occur with Oracle JDK 1.8.0.112
> {noformat}
> java version "1.8.0_112"
> Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24827) LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS name` exception
Robert Levas created AMBARI-24827:
-
Summary: LDAP users fail to authenticate using LDAPS due to `No
subject alternative DNS name` exception
Key: AMBARI-24827
URL: https://issues.apache.org/jira/browse/AMBARI-24827
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.6.2
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.7.3
LDAP users fail to authenticate using LDAPS due to `No subject alternative DNS
name` exception:
{noformat}
25 Oct 2018 18:42:49,817 WARN [ambari-client-thread-37]
AmbariLdapAuthenticationProvider:84 - Failed to communicate with the LDAP
server: simple bind failed: ad.example.com:636; nested exception is
javax.naming.CommunicationException: simple bind failed: ad.example.com:636
[Root exception is javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name
matching ad.example.com found.]
{noformat}
This is the other half of the issue from AMBARI-24533 (which was related to the
LDAP sync process).
Note: If LDAP sync is performed before a user attempts to log in, then the
issue will not be seen since the system property,
{{com.sun.jndi.ldap.object.disableEndpointIdentification}}, would have already
been set to "true". However, the logic path setting this value is not reached
for an authentication attempt.
Note: This occurs with OpenJDK 1.8.0.191 and maybe some earlier versions.
{noformat}
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
{noformat}
This does not occur with Oracle JDK 1.8.0.112
{noformat}
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24779) Move Namenode operation fails as it tries to install and start ZKFailoverController on non-HA cluster
[
https://issues.apache.org/jira/browse/AMBARI-24779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24779:
--
Reporter: Vivek Sharma (was: Ishan Bhatt)
> Move Namenode operation fails as it tries to install and start
> ZKFailoverController on non-HA cluster
> --
>
> Key: AMBARI-24779
> URL: https://issues.apache.org/jira/browse/AMBARI-24779
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Reporter: Vivek Sharma
>Assignee: Ishan Bhatt
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.3
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Error at final screen during Service start for ZKFailoverController. This is
> unexpected as the cluster is non-HA and ZKFailoverController component should
> not be attempted for a start at all on the new NN host
> {code:java}
> 2018-10-11 14:22:52,136 - Execute['ambari-sudo.sh su cstm-hdfs -l -s
> /bin/bash -c 'ulimit -c unlimited ; /usr/hdp/3.0.3.0-74/hadoop/bin/hdfs
> --config /usr/hdp/3.0.3.0-74/hadoop/conf --daemon start zkfc'']
> {'environment': {'HADOOP_LIBEXEC_DIR': '/usr/hdp/3.0.3.0-74/hadoop/libexec'},
> 'not_if': 'ambari-sudo.sh -H -E test -f
> /var/run/hadoop/cstm-hdfs/hadoop-cstm-hdfs-zkfc.pid && ambari-sudo.sh -H -E
> pgrep -F /var/run/hadoop/cstm-hdfs/hadoop-cstm-hdfs-zkfc.pid'}
> 2018-10-11 14:22:54,336 - Execute['find /grid/0/log/hdfs/cstm-hdfs -maxdepth
> 1 -type f -name '*' -exec echo '==> {} <==' \; -exec tail -n 40 {} \;']
> {'logoutput': True, 'ignore_failures': True, 'user': 'cstm-hdfs'}
> Hortonworks #
> This is MOTD message, added for testing in qe infra
> ==>
> /grid/0/log/hdfs/cstm-hdfs/hadoop-cstm-hdfs-zkfc-ctr-e138-1518143905142-517699-01-03.hwx.site.out
> <==
> Exception in thread "main" org.apache.hadoop.HadoopIllegalArgumentException:
> HA is not enabled for this namenode.
> at
> org.apache.hadoop.hdfs.tools.DFSZKFailoverController.create(DFSZKFailoverController.java:134)
> at
> org.apache.hadoop.hdfs.tools.DFSZKFailoverController.main(DFSZKFailoverController.java:192)
> core file size (blocks, -c) unlimited
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24767) Error while starting Timeline v2 Reader during Move operation
[
https://issues.apache.org/jira/browse/AMBARI-24767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24767:
--
Reporter: Vivek Sharma (was: Attila Magyar)
> Error while starting Timeline v2 Reader during Move operation
> -
>
> Key: AMBARI-24767
> URL: https://issues.apache.org/jira/browse/AMBARI-24767
> Project: Ambari
> Issue Type: Task
> Components: ambari-web
>Affects Versions: 2.7.0
>Reporter: Vivek Sharma
>Assignee: Attila Magyar
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> # Deployed HDP-3.0.3 HA cluster with Ambari-2.7.3 (Active RM and Timeline v2
> Reader are on the same host)
> # Under Yarn --> Service Actions - choose to Move Timeline Service V2.0
> Reader. Pick a new host and let the move operation complete
> {code}
> 2018-10-11 13:04:33,887 ERROR reader.TimelineReaderServer
> (TimelineReaderServer.java:startTimelineReaderServer(236)) - Error starting
> TimelineReaderWebServer
> org.apache.hadoop.yarn.exceptions.YarnRuntimeException: Failed to login from
> keytab
> at
> org.apache.hadoop.yarn.server.timelineservice.reader.TimelineReaderServer.serviceInit(TimelineReaderServer.java:88)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:164)
> at
> org.apache.hadoop.yarn.server.timelineservice.reader.TimelineReaderServer.startTimelineReaderServer(TimelineReaderServer.java:233)
> at
> org.apache.hadoop.yarn.server.timelineservice.reader.TimelineReaderServer.main(TimelineReaderServer.java:246)
> Caused by: org.apache.hadoop.security.KerberosAuthException: failure to
> login: for principal:
> yarn/ctr-e138-1518143905142-517945-01-06.hwx.s...@example.com from keytab
> /etc/security/keytabs/yarn.service.keytab
> javax.security.auth.login.LoginException: Unable to obtain password from user
> at
> org.apache.hadoop.security.UserGroupInformation.doSubjectLogin(UserGroupInformation.java:1847)
> at
> org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytabAndReturnUGI(UserGroupInformation.java:1215)
> at
> org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:1008)
> at org.apache.hadoop.security.SecurityUtil.login(SecurityUtil.java:313)
> at
> org.apache.hadoop.yarn.server.timelineservice.reader.TimelineReaderServer.serviceInit(TimelineReaderServer.java:85)
> ... 3 more
> Caused by: javax.security.auth.login.LoginException: Unable to obtain
> password from user
> at
> com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:897)
> at
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
> at
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.hadoop.security.UserGroupInformation$HadoopLoginContext.login(UserGroupInformation.java:1926)
> at
> org.apache.hadoop.security.UserGroupInformation.doSubjectLogin(UserGroupInformation.java:1837)
> ... 7 more
> 2018-10-11 13:04:33,890 INFO util.ExitUtil (ExitUtil.java:terminate(210)) -
> Exiting with status -1: Error starting TimelineReaderWebServer
> 2018-10-11 13:04:33,894 INFO reader.TimelineReaderServer
> (LogAdapter.java:info(51)) - SHUTDOWN_MSG:
> /
> SHUTDOWN_MSG: Shutting down TimelineReaderServer at
> ctr-e138-1518143905142-517945-01-02.hwx.site/172.27.74.4
> /
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24791) Node Managers fail to start after RM is moved to a different host as 'resource-tracker.address' config is not updated
[ https://issues.apache.org/jira/browse/AMBARI-24791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24791: -- Reporter: Vivek Sharma (was: Ishan Bhatt) > Node Managers fail to start after RM is moved to a different host as > 'resource-tracker.address' config is not updated > - > > Key: AMBARI-24791 > URL: https://issues.apache.org/jira/browse/AMBARI-24791 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Reporter: Vivek Sharma >Assignee: Ishan Bhatt >Priority: Major > Labels: pull-request-available > Fix For: 2.7.3 > > Time Spent: 1h > Remaining Estimate: 0h > > # Under Yarn --> Service Actions - choose to Move Resource Manager. Pick a > new host for the active RM node and let the move operation complete > # Observe the state of Node Managers in Ambari UI > *Result* > All Node Managers show as down. > Observed that one of the configs - > 'yarn.resourcemanager.resource-tracker.address.rm2' still points to older RM > node[!Screen Shot 2018-10-11 at 6.20.51 > PM.png?default=false|thumbnail!|https://hortonworks.jira.com/secure/attachment/165347/165347_Screen+Shot+2018-10-11+at+6.20.51+PM.png] > , which may be causing this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24805) not all arguments converted during string formatting
[ https://issues.apache.org/jira/browse/AMBARI-24805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24805: -- Fix Version/s: 2.8.0 > not all arguments converted during string formatting > > > Key: AMBARI-24805 > URL: https://issues.apache.org/jira/browse/AMBARI-24805 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.1 >Reporter: David Tucker >Priority: Minor > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > While running `ambari-server setup`, this error was encountered: > > ERROR: Exiting with exit code 1. > REASON: Downloading or installing JDK failed: 'Fatal exception: Failed to > download JDK: not all arguments converted during string formatting. Please > check that the JDK is available at > http://public-repo-1.hortonworks.com/ARTIFACTS/jdk-8u112-linux-x64.tar.gz. > Also you may specify JDK file location in local filesystem using > --jdk-location command line argument., exit code 1'. Exiting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-24714) User aborted task reported as FAILED in Bgoperations
[
https://issues.apache.org/jira/browse/AMBARI-24714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-24714.
---
Resolution: Fixed
> User aborted task reported as FAILED in Bgoperations
>
>
> Key: AMBARI-24714
> URL: https://issues.apache.org/jira/browse/AMBARI-24714
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 2.8.0
>
> Attachments: abort_bg_operations.py
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> User aborted task reported as FAILED in Bgoperations.
> 1. Install cluster with all services ( Including Druid)
> 2. Click on Stop all services
> 3. When BGoperations window is loaded, click on the abort button for the same
> task
> 4. The operation should be aborted and marked as Aborted with "Aborted by
> user" message in the sub tasks logs
> 5. But instead the operation is marked as failure.
> Failed task is Druid Coordinator Stop
> {code:java}
> "href":
> "https://ctr-e138-1518143905142-466827-01-02.hwx.site:8443/api/v1/clusters/cl1/requests/59/stages/0/tasks/756";,
> "Tasks": {
> "attempt_cnt": 1,
> "cluster_name": "cl1",
> "command": "STOP",
> "command_detail": "DRUID_COORDINATOR STOP",
> "end_time": 1536363316602,
> "error_log": "/var/lib/ambari-agent/data/errors-756.txt",
> "exit_code": 0,
> "host_name": "ctr-e138-1518143905142-466827-01-05.hwx.site",
> "id": 756,
> "ops_display_name": null,
> "output_log": "/var/lib/ambari-agent/data/output-756.txt",
> "request_id": 59,
> "role": "DRUID_COORDINATOR",
> "stage_id": 0,
> "start_time": 1536363307548,
> "status": "FAILED",
> "stderr": "\nCommand aborted. Reason: 'Aborted by user'",
> "stdout": "\nCommand aborted. Reason: 'Aborted by user'\n\nCommand failed
> after 1 tries\n",
> "structured_out": {}
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-24672) Regenerating keytabs for HDFS only does not re-create headless keytabs on all hosts where needed
[ https://issues.apache.org/jira/browse/AMBARI-24672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas resolved AMBARI-24672. --- Resolution: Fixed > Regenerating keytabs for HDFS only does not re-create headless keytabs on > all hosts where needed > - > > Key: AMBARI-24672 > URL: https://issues.apache.org/jira/browse/AMBARI-24672 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Sandor Molnar >Assignee: Sandor Molnar >Priority: Blocker > Labels: pull-request-available > Fix For: 2.8.0 > > Time Spent: 3h > Remaining Estimate: 0h > > +*STR*+ > # install a cluster with HDFS and Tez (+other dependecies) > # Kerberize the cluster > # remove the HDFS client from the host where Tez client is installed > # regenerate keytabs for HDFS > +*Actual results*+ > the headless keytab for HDFS has not been regenerated > +*Expected results*+ > the headless keytab is regenerated where it's necessary -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24562) Protect the ClusterConfig resource so that only authorized users may have read-only access the data
[
https://issues.apache.org/jira/browse/AMBARI-24562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24562:
--
Description:
Protect the ClientConfig resource so that only authorized users may have
read-only access the data.
Users with the following permission should have read-only access:
* {{CLUSTER.VIEW_CONFIGS}}
* {{SERVICE.VIEW_CONFIGS}}
* {{HOST.VIEW_CONFIGS}}
These permissions should be allow for the following roles:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may not view the data.
Example REST API entry point:
{noformat}
GET
/api/v1/clusters/cl1/services/HDFS/components/HDFS_CLIENT?format=client_config_tar
{noformat}
was:
Protect the ClientConfig resource so that only authorized users may have
read-only access the data.
Users with the following permission should have read-only access:
* {{CLUSTER.VIEW_CONFIGS}}
* {{SERVICE.VIEW_CONFIGS}}
* {{HOST.VIEW_CONFIGS}}
These permissions should be allow for the following roles:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may not view the data.
> Protect the ClusterConfig resource so that only authorized users may have
> read-only access the data
> ---
>
> Key: AMBARI-24562
> URL: https://issues.apache.org/jira/browse/AMBARI-24562
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, rbac
> Fix For: 2.7.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Protect the ClientConfig resource so that only authorized users may have
> read-only access the data.
> Users with the following permission should have read-only access:
> * {{CLUSTER.VIEW_CONFIGS}}
> * {{SERVICE.VIEW_CONFIGS}}
> * {{HOST.VIEW_CONFIGS}}
> These permissions should be allow for the following roles:
> * {{AMBARI.ADMINISTRATOR}}
> * {{CLUSTER.ADMINISTRATOR}}
> * {{CLUSTER.OPERATOR}}
> * {{SERVICE.ADMINISTRATOR}}
> * {{SERVICE.OPERATOR}}
> * {{CLUSTER.USER}}
> Users with no role related to the cluster may not view the data.
> Example REST API entry point:
> {noformat}
> GET
> /api/v1/clusters/cl1/services/HDFS/components/HDFS_CLIENT?format=client_config_tar
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-23026) WEB type alerts authentication in Kerberos secured cluster
[ https://issues.apache.org/jira/browse/AMBARI-23026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623616#comment-16623616 ] Robert Levas commented on AMBARI-23026: --- [~smolnar], This should be resolved, correct? > WEB type alerts authentication in Kerberos secured cluster > -- > > Key: AMBARI-23026 > URL: https://issues.apache.org/jira/browse/AMBARI-23026 > Project: Ambari > Issue Type: Bug > Components: alerts >Affects Versions: 2.5.2, trunk, 2.6.2 > Environment: Ambari 2.5.2 > Hortonworks HDP-2.5.3.0-37 >Reporter: David F. Quiroga >Assignee: Sandor Molnar >Priority: Minor > Labels: pull-request-available > Fix For: 2.7.2 > > Time Spent: 1h > Remaining Estimate: 0h > > In a Kerberized cluster some web endpoints (App Timeline Web UI, > ResourceManger Web UI, etc.) require authentication. Any Ambari alerts > checking those endpoints must then be able to authenticate. > This was addressed in AMBARI-9586, however the default principal and keytab > used in the alerts.json is that of the "bare" SPNEGO principal > HTTP/_HOST@REALM. > My understanding is that the HTTP service principal is used to authenticate > users to a service, not used to authenticate to another service. > 1. Since most endpoints involved are Web UI, would it be more appropriate to > use the smokeuser in the alerts? > 2. This was first observed in Ranger Audit, the YARN Ranger Plug-in showed > many access denied from HTTP user. [This > post|https://community.hortonworks.com/content/supportkb/150206/ranger-audit-logs-refers-to-access-denied-for-http.html] > provided some direction as to where those requests were coming from. We have > updated the ResourceManger Web UI alert definition to use > cluster-env/smokeuser_keytab and cluster-env/smokeuser_principal_name and > this has resolved the initial HTTP access denied. > Would it also be advisable to make the change in the other secure Web UI > alert definitions? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-8610) Kerberos add hosts/services CSV required for automating keytab distribution
[
https://issues.apache.org/jira/browse/AMBARI-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-8610.
--
Resolution: Fixed
> Kerberos add hosts/services CSV required for automating keytab distribution
> ---
>
> Key: AMBARI-8610
> URL: https://issues.apache.org/jira/browse/AMBARI-8610
> Project: Ambari
> Issue Type: Improvement
>Affects Versions: 1.6.1
> Environment: HDP 2.1
>Reporter: Hari Sekhon
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.3.0
>
>
> Ambari generates a CSV list of principals for generating keytabs only when
> initially kerberizing a cluster.
> However, when adding nodes to the cluster Ambari provides no such CSV or list
> of principals - leaving the user to figure out the list of required
> principals and keytabs themselves.
> A CSV of new principals and keytabs should be created whenever deploying new
> hosts or new services to an existing kerberized cluster to allow for similar
> automation of extending an existing cluster.
> I use the original CSV as input to a perl program I've written to automate
> kerberos principal creation, keytab exports and distribution to nodes based
> for a FreeIPA realm (standalone MIT KDC as per stock kerberos_setup.sh is
> used more for small VM / PoC setups without LDAP integrated users and groups).
> If anyone else wants to automate FreeIPA Kerberos keytabs for their clusters
> they can use this program on my github:
> {code}
> git clone https://github.com/harisekhon/toolbox
> cd toolbox
> make
> ./ambari_freeipa_kerberos_setup.pl --help
> {code}
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-8610) Kerberos add hosts/services CSV required for automating keytab distribution
[
https://issues.apache.org/jira/browse/AMBARI-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-8610:
-
Fix Version/s: (was: 2.3.0)
2.7.0
> Kerberos add hosts/services CSV required for automating keytab distribution
> ---
>
> Key: AMBARI-8610
> URL: https://issues.apache.org/jira/browse/AMBARI-8610
> Project: Ambari
> Issue Type: Improvement
>Affects Versions: 1.6.1
> Environment: HDP 2.1
>Reporter: Hari Sekhon
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.0
>
>
> Ambari generates a CSV list of principals for generating keytabs only when
> initially kerberizing a cluster.
> However, when adding nodes to the cluster Ambari provides no such CSV or list
> of principals - leaving the user to figure out the list of required
> principals and keytabs themselves.
> A CSV of new principals and keytabs should be created whenever deploying new
> hosts or new services to an existing kerberized cluster to allow for similar
> automation of extending an existing cluster.
> I use the original CSV as input to a perl program I've written to automate
> kerberos principal creation, keytab exports and distribution to nodes based
> for a FreeIPA realm (standalone MIT KDC as per stock kerberos_setup.sh is
> used more for small VM / PoC setups without LDAP integrated users and groups).
> If anyone else wants to automate FreeIPA Kerberos keytabs for their clusters
> they can use this program on my github:
> {code}
> git clone https://github.com/harisekhon/toolbox
> cd toolbox
> make
> ./ambari_freeipa_kerberos_setup.pl --help
> {code}
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-8610) Kerberos add hosts/services CSV required for automating keytab distribution
[
https://issues.apache.org/jira/browse/AMBARI-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16619289#comment-16619289
]
Robert Levas commented on AMBARI-8610:
--
This appears to be working now... I am not sure as-of when, though.
> Kerberos add hosts/services CSV required for automating keytab distribution
> ---
>
> Key: AMBARI-8610
> URL: https://issues.apache.org/jira/browse/AMBARI-8610
> Project: Ambari
> Issue Type: Improvement
>Affects Versions: 1.6.1
> Environment: HDP 2.1
>Reporter: Hari Sekhon
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.0
>
>
> Ambari generates a CSV list of principals for generating keytabs only when
> initially kerberizing a cluster.
> However, when adding nodes to the cluster Ambari provides no such CSV or list
> of principals - leaving the user to figure out the list of required
> principals and keytabs themselves.
> A CSV of new principals and keytabs should be created whenever deploying new
> hosts or new services to an existing kerberized cluster to allow for similar
> automation of extending an existing cluster.
> I use the original CSV as input to a perl program I've written to automate
> kerberos principal creation, keytab exports and distribution to nodes based
> for a FreeIPA realm (standalone MIT KDC as per stock kerberos_setup.sh is
> used more for small VM / PoC setups without LDAP integrated users and groups).
> If anyone else wants to automate FreeIPA Kerberos keytabs for their clusters
> they can use this program on my github:
> {code}
> git clone https://github.com/harisekhon/toolbox
> cd toolbox
> make
> ./ambari_freeipa_kerberos_setup.pl --help
> {code}
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (AMBARI-23151) Ambari agent should trust Ambari server's SSL certificate
[
https://issues.apache.org/jira/browse/AMBARI-23151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reassigned AMBARI-23151:
-
Assignee: Sandor Molnar (was: Robert Levas)
> Ambari agent should trust Ambari server's SSL certificate
> -
>
> Key: AMBARI-23151
> URL: https://issues.apache.org/jira/browse/AMBARI-23151
> Project: Ambari
> Issue Type: Task
> Components: ambari-agent, ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Sandor Molnar
>Priority: Major
> Labels: security, ssl
> Fix For: 3.0.0
>
>
> Ambari agent should trust Ambari server's SSL certificate.
> When using Python 2.7 and above, the agent tends to fail connecting with the
> Ambari server with a {{CERTIFICATE_VERIFY_FAILED}} error.
> To solve this, else tell Python to no verify certificates (which is insecure):
> {noformat:title=/etc/python/cert-verification.cfg}
> [https]
> verify=disable
> {noformat}
> See https://access.redhat.com/articles/2039753
> Or import the Ambari server's SSL cert into the truststore used by Python,
> which is more secure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24616) Disable Kerberos from Ambari UI didn't clean up keytab directories
[
https://issues.apache.org/jira/browse/AMBARI-24616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24616:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Disable Kerberos from Ambari UI didn't clean up keytab directories
> --
>
> Key: AMBARI-24616
> URL: https://issues.apache.org/jira/browse/AMBARI-24616
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Kishor Ramakrishnan
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.2
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Disable Kerberos from Ambari UI didn't clean up keytab directories,
> stderr:
> {code:java}
> 2018-09-08 05:27:19,276 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,298 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,325 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,348 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,465 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,491 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,515 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,539 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,671 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,696 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,723 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,744 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,959 - Failed to remove identity for
> nm/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,987 - Failed to remove identity for
> nm/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,049 - Failed to remove identity for
> nn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,376 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,399 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,420 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,441 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,590 - Failed to remove identity for
> yarn-ats-hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com
> from the Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,617 - Failed to remove ident
[jira] [Resolved] (AMBARI-22949) Kerberos identities are not removed for components that exist in multiple hosts
[
https://issues.apache.org/jira/browse/AMBARI-22949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-22949.
---
Resolution: Duplicate
Fix Version/s: (was: 3.0.0)
2.7.2
See AMBARI-24616
> Kerberos identities are not removed for components that exist in multiple
> hosts
> ---
>
> Key: AMBARI-22949
> URL: https://issues.apache.org/jira/browse/AMBARI-22949
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Fix For: 2.7.2
>
>
> Kerberos identities are not removed for components that exist on multiple
> hosts.
> For example, if {{SERVICEA/COMPONENT1}} is installed on {{HOST1}} and
> {{HOST2}} and its relevant principal is named {{component1/\_HOST@REALM}},
> then the host-specific principal and keytab file will not be removed if
> {{SERVICEA/COMPONENT1}} is removed from {{HOST1}} *_or_* {{HOST2}}. It will
> be removed if {{SERVICEA/COMPONENT1}} is removed from {{HOST1}} *_and_*
> {{HOST2}}.
> This is due to the incorrect principal name comparison when determine whether
> a Kerberos identity is to be removed or not. See
> {{org.apache.ambari.server.controller.utilities.UsedIdentities#contains}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24546) Protect the Request resource so that only authorized users may have read-only access the data
[
https://issues.apache.org/jira/browse/AMBARI-24546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16619216#comment-16619216
]
Robert Levas commented on AMBARI-24546:
---
[~smolnar], Should this be resolved?
> Protect the Request resource so that only authorized users may have read-only
> access the data
> -
>
> Key: AMBARI-24546
> URL: https://issues.apache.org/jira/browse/AMBARI-24546
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Robert Levas
>Assignee: Sandor Molnar
>Priority: Major
> Labels: pull-request-available, rbac
> Fix For: 2.7.2
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Protect the Request resource so that only authorized users may have read-only
> access the data.
> Users with the following roles should have read-only access:
> * {{AMBARI.ADMINISTRATOR}}
> * {{CLUSTER.ADMINISTRATOR}}
> * {{CLUSTER.OPERATOR}}
> * {{SERVICE.ADMINISTRATOR}}
> * {{SERVICE.OPERATOR}}
> * {{CLUSTER.USER}}
> Users with no role related to the cluster may not view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24616) Disable Kerberos from Ambari UI didn't clean up keytab directories
[
https://issues.apache.org/jira/browse/AMBARI-24616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24616:
--
Status: Patch Available (was: In Progress)
> Disable Kerberos from Ambari UI didn't clean up keytab directories
> --
>
> Key: AMBARI-24616
> URL: https://issues.apache.org/jira/browse/AMBARI-24616
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Kishor Ramakrishnan
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Disable Kerberos from Ambari UI didn't clean up keytab directories,
> stderr:
> {code:java}
> 2018-09-08 05:27:19,276 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,298 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,325 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,348 - Failed to remove identity for
> amsmon/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,465 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,491 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,515 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,539 - Failed to remove identity for
> dn/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,671 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,696 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,723 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,744 - Failed to remove identity for
> hbase/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,959 - Failed to remove identity for
> nm/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:19,987 - Failed to remove identity for
> nm/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,049 - Failed to remove identity for
> nn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,376 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,399 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,420 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,441 - Failed to remove identity for
> HTTP/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
> Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,590 - Failed to remove identity for
> yarn-ats-hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com
> from the Ambari database - Object: null is not a known Entity type.
> 2018-09-08 05:27:20,617 - Failed to remove identity for
> yarn-ats-h
[jira] [Created] (AMBARI-24616) Disable Kerberos from Ambari UI didn't clean up keytab directories
Robert Levas created AMBARI-24616:
-
Summary: Disable Kerberos from Ambari UI didn't clean up keytab
directories
Key: AMBARI-24616
URL: https://issues.apache.org/jira/browse/AMBARI-24616
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.7.1
Reporter: Kishor Ramakrishnan
Assignee: Robert Levas
Fix For: 2.7.2
Disable Kerberos from Ambari UI didn't clean up keytab directories,
stderr:
{code:java}
2018-09-08 05:27:19,276 - Failed to remove identity for
amsmon/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,298 - Failed to remove identity for
amsmon/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,325 - Failed to remove identity for
amsmon/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,348 - Failed to remove identity for
amsmon/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,465 - Failed to remove identity for
dn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:19,491 - Failed to remove identity for
dn/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:19,515 - Failed to remove identity for
dn/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:19,539 - Failed to remove identity for
dn/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:19,671 - Failed to remove identity for
hbase/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,696 - Failed to remove identity for
hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,723 - Failed to remove identity for
hbase/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,744 - Failed to remove identity for
hbase/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:19,959 - Failed to remove identity for
nm/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:19,987 - Failed to remove identity for
nm/ctr-e138-1518143905142-467151-01-06.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:20,049 - Failed to remove identity for
nn/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the Ambari
database - Object: null is not a known Entity type.
2018-09-08 05:27:20,376 - Failed to remove identity for
HTTP/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,399 - Failed to remove identity for
HTTP/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,420 - Failed to remove identity for
HTTP/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,441 - Failed to remove identity for
HTTP/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com from the
Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,590 - Failed to remove identity for
yarn-ats-hbase/ctr-e138-1518143905142-467151-01-03.hwx.s...@example.com
from the Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,617 - Failed to remove identity for
yarn-ats-hbase/ctr-e138-1518143905142-467151-01-02.hwx.s...@example.com
from the Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,647 - Failed to remove identity for
yarn-ats-hbase/ctr-e138-1518143905142-467151-01-04.hwx.s...@example.com
from the Ambari database - Object: null is not a known Entity type.
2018-09-08 05:27:20,677 - Failed to remove identity for
yarn-ats-hbase/ctr-e138-1518143905142-467151-01-05.hwx.s...@example.com
from the Ambari database
[jira] [Resolved] (AMBARI-21546) Centralize LDAP Configuration for all services
[
https://issues.apache.org/jira/browse/AMBARI-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-21546.
---
Resolution: Fixed
> Centralize LDAP Configuration for all services
> --
>
> Key: AMBARI-21546
> URL: https://issues.apache.org/jira/browse/AMBARI-21546
> Project: Ambari
> Issue Type: Epic
>Reporter: Balázs Bence Sári
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 3.0.0
>
>
> LDAP configuration is time consuming, and follows a different pattern for
> each of the components below:
> * Ambari
> * Ranger
> * Knox
> * Atlas
> * Hive
> * Zeppelin
> In each case the same information is required, but duplicated across multiple
> components. Information required is:
> * LDAP Host
> * LDAP Port (389|636|*)
> * LDAP Security (LDAP, LDAPS)
> * LDAP anonymous bind support (default to false)
> * LDAP Bind DN (dn: cn=hadoop,ou=services,ou=Users,dc=hortonworks,dc=local)
> * LDAP Bind Password ()
> * LDAP Referrals Handling (follow|ignore)
> * LDAP Search Scope (subtree|base|one)
> * LDAP Server Certificate/CA Certificate (path to cert so it can be trusted
> using appropriate means)
> * User Search Base (cn=Users,dc=hortonworks,dc=local)
> * User Object Class (user)
> * User RDN (cn)
> * Group Search Base (cn=Groups,dc=hortonworks,dc=local
> * Group Object Class (group)
> * Group RDN (cn)
> * Group Membership attribute (member)
> If we can collect all of that information in one go - we can use it to
> configure the components above appropriately. Allowing the user to follow a
> single approach to LDAP enabling the stack. Additionally, this process
> should be optimized for Active Directory as that is in play in 90% of our
> installations.
> --
> How we make this information available to other services is important. In
> some situations a user may need to override the centralized configuration, so
> if we use variables that teams can use by default, but customers can override
> if necessary, that will be best. For example:
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase={{ ldap_group_searchbase }}
> There could be situations where they need to have a separate group searchable
> for Atlas so the user would just customize that property
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase=OU=GROUPS,dc=hortonworks,dc=local
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-23026) WEB type alerts authentication in Kerberos secured cluster
[ https://issues.apache.org/jira/browse/AMBARI-23026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-23026: -- Fix Version/s: (was: 3.0.0) 2.7.2 > WEB type alerts authentication in Kerberos secured cluster > -- > > Key: AMBARI-23026 > URL: https://issues.apache.org/jira/browse/AMBARI-23026 > Project: Ambari > Issue Type: Bug > Components: alerts >Affects Versions: 2.5.2, trunk, 2.6.2 > Environment: Ambari 2.5.2 > Hortonworks HDP-2.5.3.0-37 >Reporter: David F. Quiroga >Assignee: Sandor Molnar >Priority: Minor > Labels: pull-request-available > Fix For: 2.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > In a Kerberized cluster some web endpoints (App Timeline Web UI, > ResourceManger Web UI, etc.) require authentication. Any Ambari alerts > checking those endpoints must then be able to authenticate. > This was addressed in AMBARI-9586, however the default principal and keytab > used in the alerts.json is that of the "bare" SPNEGO principal > HTTP/_HOST@REALM. > My understanding is that the HTTP service principal is used to authenticate > users to a service, not used to authenticate to another service. > 1. Since most endpoints involved are Web UI, would it be more appropriate to > use the smokeuser in the alerts? > 2. This was first observed in Ranger Audit, the YARN Ranger Plug-in showed > many access denied from HTTP user. [This > post|https://community.hortonworks.com/content/supportkb/150206/ranger-audit-logs-refers-to-access-denied-for-http.html] > provided some direction as to where those requests were coming from. We have > updated the ResourceManger Web UI alert definition to use > cluster-env/smokeuser_keytab and cluster-env/smokeuser_principal_name and > this has resolved the initial HTTP access denied. > Would it also be advisable to make the change in the other secure Web UI > alert definitions? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-21659) Remove obsolete security_state data
[ https://issues.apache.org/jira/browse/AMBARI-21659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-21659: -- Affects Version/s: (was: 3.0.0) 2.0.0 > Remove obsolete security_state data > --- > > Key: AMBARI-21659 > URL: https://issues.apache.org/jira/browse/AMBARI-21659 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Fix For: 2.7.0 > > Attachments: AMBARI-21659.patch > > > Remove the outdated security_state information from the Ambari server and the > Ambari database. > The following tables will be affected: > - hostcomponentdesiredstate > - hostcomponentstate > - servicedesiredstate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-21659) Remove obsolete security_state data
[ https://issues.apache.org/jira/browse/AMBARI-21659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-21659: -- Fix Version/s: (was: 3.0.0) 2.7.0 > Remove obsolete security_state data > --- > > Key: AMBARI-21659 > URL: https://issues.apache.org/jira/browse/AMBARI-21659 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Fix For: 2.7.0 > > Attachments: AMBARI-21659.patch > > > Remove the outdated security_state information from the Ambari server and the > Ambari database. > The following tables will be affected: > - hostcomponentdesiredstate > - hostcomponentstate > - servicedesiredstate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-21659) Remove obsolete security_state data
[ https://issues.apache.org/jira/browse/AMBARI-21659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-21659: -- Affects Version/s: (was: 2.0.0) 2.7.0 > Remove obsolete security_state data > --- > > Key: AMBARI-21659 > URL: https://issues.apache.org/jira/browse/AMBARI-21659 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Fix For: 2.7.0 > > Attachments: AMBARI-21659.patch > > > Remove the outdated security_state information from the Ambari server and the > Ambari database. > The following tables will be affected: > - hostcomponentdesiredstate > - hostcomponentstate > - servicedesiredstate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24228) Agent-side command-*.json files should optionally be deleted when no longer needed by the command
[
https://issues.apache.org/jira/browse/AMBARI-24228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24228:
--
Description:
Agent-side _command JSON_ files ({{command-*.json}}, {{status_command.json}})
should optionally be deleted when no longer needed by the command. One reason
for this is to reduce the risk of leaking sensitive data stored at plaintext in
the _command JSON_ files.
Currently the _command JSON_ files are stored on disk in
/var/lib/ambari-agent/data. These files may be cleared out over time, but
there is a need to have them removed as soon as they are no longer needed.
To do this, a retention policy may be defined so that the Ambari agent behaves
accordingly:
* {{keep}}
** No automatic removal is performed
** This is the default behavior
* {{remove}}
** The _command JSON_ file are removed as soon as the command completes
* {{remove_on_success}}
** The _command JSON_ files are removed as soon as the command *successfully*
completes
** The _command JSON_ files are not removed on failure conditions
This value is to be set in the {{ambari-agent.ini}} file, typically found at
{{/etc/ambari-agent/conf/ambari-agent.ini}} using the
*{{command_file_retention_policy}}* property. After setting this property, the
agent needs to be restarted.
was:
Agent-side _command JSON_ files ({{command-*.json}}, {{status_command.json}})
should optionally be deleted when no longer needed by the command. One reason
for this is to reduce the risk of leaking sensitive data stored at plaintext in
the _command JSON_ files.
Currently the _command JSON_ files are stored on disk in
/var/lib/ambari-agent/data. These files may be cleared out over time, but
there is a need to have them removed as soon as they are no longer needed.
To do this, a retention policy may be defined so that the Ambari agent behaves
accordingly:
* {{keep}}
** No automatic removal is performed
** This is the default behavior
* {{remove}}
** The _command JSON_ file are remove as soon as the command completes
* {{remove_on_success}}
** The _command JSON_ files are remove as soon as the command *successfully*
completes
** The _command JSON_ files are not removed on failure conditions
> Agent-side command-*.json files should optionally be deleted when no longer
> needed by the command
> -
>
> Key: AMBARI-24228
> URL: https://issues.apache.org/jira/browse/AMBARI-24228
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.1.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.7.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Agent-side _command JSON_ files ({{command-*.json}}, {{status_command.json}})
> should optionally be deleted when no longer needed by the command. One
> reason for this is to reduce the risk of leaking sensitive data stored at
> plaintext in the _command JSON_ files.
> Currently the _command JSON_ files are stored on disk in
> /var/lib/ambari-agent/data. These files may be cleared out over time, but
> there is a need to have them removed as soon as they are no longer needed.
> To do this, a retention policy may be defined so that the Ambari agent
> behaves accordingly:
> * {{keep}}
> ** No automatic removal is performed
> ** This is the default behavior
> * {{remove}}
> ** The _command JSON_ file are removed as soon as the command completes
> * {{remove_on_success}}
> ** The _command JSON_ files are removed as soon as the command *successfully*
> completes
> ** The _command JSON_ files are not removed on failure conditions
> This value is to be set in the {{ambari-agent.ini}} file, typically found at
> {{/etc/ambari-agent/conf/ambari-agent.ini}} using the
> *{{command_file_retention_policy}}* property. After setting this property,
> the agent needs to be restarted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-24533) Ambari Server Ldap Sync Failed upon subject alternative DNS name check
[
https://issues.apache.org/jira/browse/AMBARI-24533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-24533.
---
Resolution: Fixed
> Ambari Server Ldap Sync Failed upon subject alternative DNS name check
> --
>
> Key: AMBARI-24533
> URL: https://issues.apache.org/jira/browse/AMBARI-24533
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.7.2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> STR:
> 1. Install Ambari
> 2. Get certificate for secure LDAP (LDAPS) connection to your AD server.
> 3. Generate ambari truststore with LDAPS certificate.
> 4. Setup Ambari to use LDAPS with providing truststore.
> {code:java}
> 2018-08-20 18:38:04,763 DEBUG
> com.hw.commonuifrm.impl.commands.CommandExecutorImpl.executeCommand():
> Sending command [(echo "admin" ; echo "admin") | ambari-server sync-ldap
> --users /tmp/users.txt --groups /tmp/groups.txt]
> 2018-08-20 18:38:05,666 DEBUG
> com.hw.commonuifrm.impl.commands.ProcessDataImpl.buildOutputAndErrorStreamData():
> /usr/lib64/python2.7/getpass.py:83: GetPassWarning: Can not control echo on
> the terminal.
> passwd = fallback_getpass(prompt, stream)
> Warning: Password input may be echoed.
> Enter Ambari Admin password:
> 2018-08-20 18:38:07,169 INFO
> com.hw.ambari.ui.util.cluster_managers.LDAPClusterManager.ambariServerSyncLDAPWithAD():
> Result: Using python /usr/bin/python
> Syncing with LDAP...
> Enter Ambari Admin login:
> Fetching LDAP configuration from DB.
> Syncing specified users and groups...ERROR: Exiting with exit code 1.
> REASON: Caught exception running LDAP sync. ***.com:636; nested exception is
> javax.naming.CommunicationException: ***.com:636 [Root exception is
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching ***.com found.]
> 2018-08-20 18:38:07,170 INFO
> com.hw.ambari.ui.tests.console.ldap.TestLDAPSOnAD.test010_AmbariSynchronizeWithADThroughLDAPS():
> AMBARI LDAPS synchronization result: Using python /usr/bin/python
> Syncing with LDAP...
> Enter Ambari Admin login:
> Fetching LDAP configuration from DB.
> Syncing specified users and groups...ERROR: Exiting with exit code 1.
> REASON: Caught exception running LDAP sync. ***.com:636; nested exception is
> javax.naming.CommunicationException: ***.com:636 [Root exception is
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching ***.com found.]{code}
> The issue is that the AD server's certificate contains a section:
> {noformat}
> X509v3 Subject Alternative Name: othername:,
> DNS:***-2.COM{noformat}
> As you can see this is not the same that we use to connect to the AD server
> (***.com:636). Even if this is a certificate issue the connection could be
> open and we should be able to sync LDAP users/groups.
> *Important note*: it's reproducible only with OpenJDK (I used
> openjdk-1.8.0.181-3.b13.el7_5.x86_64); working properly with Oracle's JDK.
> +*Recommended solution*+
> We can disable endpoint identification when the client is negotiating with
> the server during SSL handshake by setting
> _com.sun.jndi.ldap.object.disableEndpointIdentification_ to _true_ (see
> [https://github.com/ojdkbuild/lookaside_java-1.8.0-openjdk/blob/master/jdk/src/share/classes/com/sun/jndi/ldap/Connection.java#L386]).
> By default this should not be the case but end users may set this up when
> configuring LDAP if they face this issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24562) Protect the ClusterConfig resource so that only authorized users may have read-only access the data
[
https://issues.apache.org/jira/browse/AMBARI-24562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24562:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Protect the ClusterConfig resource so that only authorized users may have
> read-only access the data
> ---
>
> Key: AMBARI-24562
> URL: https://issues.apache.org/jira/browse/AMBARI-24562
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, rbac
> Fix For: 2.7.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Protect the ClientConfig resource so that only authorized users may have
> read-only access the data.
> Users with the following permission should have read-only access:
> * {{CLUSTER.VIEW_CONFIGS}}
> * {{SERVICE.VIEW_CONFIGS}}
> * {{HOST.VIEW_CONFIGS}}
> These permissions should be allow for the following roles:
> * {{AMBARI.ADMINISTRATOR}}
> * {{CLUSTER.ADMINISTRATOR}}
> * {{CLUSTER.OPERATOR}}
> * {{SERVICE.ADMINISTRATOR}}
> * {{SERVICE.OPERATOR}}
> * {{CLUSTER.USER}}
> Users with no role related to the cluster may not view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24522) Cannot connect to MIT KDC admin server when port is specified in kerberos-env/admin_server_host
[
https://issues.apache.org/jira/browse/AMBARI-24522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24522:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Cannot connect to MIT KDC admin server when port is specified in
> kerberos-env/admin_server_host
> ---
>
> Key: AMBARI-24522
> URL: https://issues.apache.org/jira/browse/AMBARI-24522
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: kerberos, pull-request-available, regression
> Fix For: 2.7.2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Cannot connect to MIT KDC admin server when port is specified in
> {{kerberos-env/admin_server_host}}. The following error is seen when
> validating the KDC admin credentials:
> {noformat}
> kinit: Server not found in Kerberos database while getting initial credentials
> {noformat}
> The reason for this is due to how the credentials are created for accessing
> the MIT KDC administration server.
> {noformat}
> kinit -c -S kadmin/
> {noformat}
> If a port was added to the {{kerberos-env/admin_server_host}} value then the
> server principal will be generated like {{kadmin/kdc.example.com:4749}}
> rather than {{kadmin/kdc.example.com}}. Therefore the server principal is not
> found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24536) Ambari SPNEGO breaks SSO redirect
[ https://issues.apache.org/jira/browse/AMBARI-24536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24536: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Ambari SPNEGO breaks SSO redirect > - > > Key: AMBARI-24536 > URL: https://issues.apache.org/jira/browse/AMBARI-24536 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.6.0 >Reporter: Sean Roberts >Assignee: Robert Levas >Priority: Major > Labels: kerberos, pull-request-available, security, spnego, sso > Fix For: 2.7.2 > > Time Spent: 1h > Remaining Estimate: 0h > > When SPNEGO is enabled (`ambari-server setup-kerberos`), the SSO > (`ambari-server setup-sso`) redirect no longer works. > How to reproduce: > # Enable SSO `ambari-server setup-sso` > # `ambari-server restart` > # Visit Ambari and notice that you are redirected to the SSO system (i.e. > Knox) > # Enable SPNEGO `ambari-server setup-kerberos` > # `ambari-server restart` > # Visit Ambari and notice that you are *NOT redirected* to the SSO system > (i.e. Knox) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24562) Protect the ClusterConfig resource so that only authorized users may have read-only access the data
[
https://issues.apache.org/jira/browse/AMBARI-24562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24562:
--
Status: Patch Available (was: In Progress)
> Protect the ClusterConfig resource so that only authorized users may have
> read-only access the data
> ---
>
> Key: AMBARI-24562
> URL: https://issues.apache.org/jira/browse/AMBARI-24562
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: pull-request-available, rbac
> Fix For: 2.7.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Protect the ClientConfig resource so that only authorized users may have
> read-only access the data.
> Users with the following permission should have read-only access:
> * {{CLUSTER.VIEW_CONFIGS}}
> * {{SERVICE.VIEW_CONFIGS}}
> * {{HOST.VIEW_CONFIGS}}
> These permissions should be allow for the following roles:
> * {{AMBARI.ADMINISTRATOR}}
> * {{CLUSTER.ADMINISTRATOR}}
> * {{CLUSTER.OPERATOR}}
> * {{SERVICE.ADMINISTRATOR}}
> * {{SERVICE.OPERATOR}}
> * {{CLUSTER.USER}}
> Users with no role related to the cluster may not view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24562) Protect the ClusterConfig resource so that only authorized users may have read-only access the data
Robert Levas created AMBARI-24562:
-
Summary: Protect the ClusterConfig resource so that only
authorized users may have read-only access the data
Key: AMBARI-24562
URL: https://issues.apache.org/jira/browse/AMBARI-24562
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.7.2
Protect the ClientConfig resource so that only authorized users may have
read-only access the data.
Users with the following permission should have read-only access:
* {{CLUSTER.VIEW_CONFIGS}}
* {{SERVICE.VIEW_CONFIGS}}
* {{HOST.VIEW_CONFIGS}}
These permissions should be allow for the following roles:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may not view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24536) Ambari SPNEGO breaks SSO redirect
[ https://issues.apache.org/jira/browse/AMBARI-24536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24536: -- Status: Patch Available (was: In Progress) > Ambari SPNEGO breaks SSO redirect > - > > Key: AMBARI-24536 > URL: https://issues.apache.org/jira/browse/AMBARI-24536 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.6.0 >Reporter: Sean Roberts >Assignee: Robert Levas >Priority: Major > Labels: kerberos, pull-request-available, security, spnego, sso > Fix For: 2.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > When SPNEGO is enabled (`ambari-server setup-kerberos`), the SSO > (`ambari-server setup-sso`) redirect no longer works. > How to reproduce: > # Enable SSO `ambari-server setup-sso` > # `ambari-server restart` > # Visit Ambari and notice that you are redirected to the SSO system (i.e. > Knox) > # Enable SPNEGO `ambari-server setup-kerberos` > # `ambari-server restart` > # Visit Ambari and notice that you are *NOT redirected* to the SSO system > (i.e. Knox) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24536) Ambari SPNEGO breaks SSO redirect
[ https://issues.apache.org/jira/browse/AMBARI-24536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-24536: -- Fix Version/s: 2.7.2 > Ambari SPNEGO breaks SSO redirect > - > > Key: AMBARI-24536 > URL: https://issues.apache.org/jira/browse/AMBARI-24536 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.6.0 >Reporter: Sean Roberts >Assignee: Robert Levas >Priority: Major > Labels: kerberos, security, spnego, sso > Fix For: 2.7.2 > > > When SPNEGO is enabled (`ambari-server setup-kerberos`), the SSO > (`ambari-server setup-sso`) redirect no longer works. > How to reproduce: > # Enable SSO `ambari-server setup-sso` > # `ambari-server restart` > # Visit Ambari and notice that you are redirected to the SSO system (i.e. > Knox) > # Enable SPNEGO `ambari-server setup-kerberos` > # `ambari-server restart` > # Visit Ambari and notice that you are *NOT redirected* to the SSO system > (i.e. Knox) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24546) Protect the Request resource so that only authorized users may have read-only access the data
[
https://issues.apache.org/jira/browse/AMBARI-24546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-24546:
--
Description:
Protect the Request resource so that only authorized users may have read-only
access the data.
Users with the following roles should have read-only access:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may not view the data.
was:
Protect the Request resource so that only authorized users may have read-only
access the data.
Users with the following roles should have read-only access:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may view the data.
> Protect the Request resource so that only authorized users may have read-only
> access the data
> -
>
> Key: AMBARI-24546
> URL: https://issues.apache.org/jira/browse/AMBARI-24546
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Major
> Labels: rbac
> Fix For: 2.7.2
>
>
> Protect the Request resource so that only authorized users may have read-only
> access the data.
> Users with the following roles should have read-only access:
> * {{AMBARI.ADMINISTRATOR}}
> * {{CLUSTER.ADMINISTRATOR}}
> * {{CLUSTER.OPERATOR}}
> * {{SERVICE.ADMINISTRATOR}}
> * {{SERVICE.OPERATOR}}
> * {{CLUSTER.USER}}
> Users with no role related to the cluster may not view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24546) Protect the Request resource so that only authorized users may have read-only access the data
Robert Levas created AMBARI-24546:
-
Summary: Protect the Request resource so that only authorized
users may have read-only access the data
Key: AMBARI-24546
URL: https://issues.apache.org/jira/browse/AMBARI-24546
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.3.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 2.7.2
Protect the Request resource so that only authorized users may have read-only
access the data.
Users with the following roles should have read-only access:
* {{AMBARI.ADMINISTRATOR}}
* {{CLUSTER.ADMINISTRATOR}}
* {{CLUSTER.OPERATOR}}
* {{SERVICE.ADMINISTRATOR}}
* {{SERVICE.OPERATOR}}
* {{CLUSTER.USER}}
Users with no role related to the cluster may view the data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24536) Ambari SPNEGO breaks SSO redirect
[ https://issues.apache.org/jira/browse/AMBARI-24536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591548#comment-16591548 ] Robert Levas commented on AMBARI-24536: --- [~seano], This is an odd scenario - 2 SSO authentication method active for Ambari at the same time. Is there really a use case to support this, or should Ambari proactively disallow this? > Ambari SPNEGO breaks SSO redirect > - > > Key: AMBARI-24536 > URL: https://issues.apache.org/jira/browse/AMBARI-24536 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.6.0 >Reporter: Sean Roberts >Assignee: Robert Levas >Priority: Major > Labels: kerberos, security, spnego, sso > > When SPNEGO is enabled (`ambari-server setup-kerberos`), the SSO > (`ambari-server setup-sso`) redirect no longer works. > How to reproduce: > # Enable SSO `ambari-server setup-sso` > # `ambari-server restart` > # Visit Ambari and notice that you are redirected to the SSO system (i.e. > Knox) > # Enable SPNEGO `ambari-server setup-kerberos` > # `ambari-server restart` > # Visit Ambari and notice that you are *NOT redirected* to the SSO system > (i.e. Knox) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-24536) Ambari SPNEGO breaks SSO redirect
[ https://issues.apache.org/jira/browse/AMBARI-24536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas reassigned AMBARI-24536: - Assignee: Robert Levas > Ambari SPNEGO breaks SSO redirect > - > > Key: AMBARI-24536 > URL: https://issues.apache.org/jira/browse/AMBARI-24536 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.6.0 >Reporter: Sean Roberts >Assignee: Robert Levas >Priority: Major > Labels: kerberos, security, spnego, sso > > When SPNEGO is enabled (`ambari-server setup-kerberos`), the SSO > (`ambari-server setup-sso`) redirect no longer works. > How to reproduce: > # Enable SSO `ambari-server setup-sso` > # `ambari-server restart` > # Visit Ambari and notice that you are redirected to the SSO system (i.e. > Knox) > # Enable SPNEGO `ambari-server setup-kerberos` > # `ambari-server restart` > # Visit Ambari and notice that you are *NOT redirected* to the SSO system > (i.e. Knox) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
