[jira] [Created] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
Hari Sekhon created AMBARI-18427:
Summary: Agent 2.4.0.1 start error "cannot import name
split_on_chunks" after upgrade
Key: AMBARI-18427
URL: https://issues.apache.org/jira/browse/AMBARI-18427
Project: Ambari
Issue Type: Bug
Components: ambari-agent
Affects Versions: 2.4.0
Reporter: Hari Sekhon
I hit this issue yesterday after upgrading ambari-agent:
{code}
Verifying Python version compatibility...
Using python /usr/bin/pythonChecking for previously running Ambari Agent...
Starting ambari-agentVerifying ambari-agent process status...
ERROR: ambari-agent start failed. For more details, see
/var/log/ambari-agent/ambari-agent.out:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 41,
in from ambari_agent.ActionQueue import ActionQueue
File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
37, in from ambari_commons.str_utils import split_on_chunks
ImportError: cannot import name split_on_chunks
{code}
I'm not the first person to have encountered it, see:
https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
Considering this is an existing cluster the solution of rm -rf'ing the entire
python2.6 site-packages seems excessive...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Sekhon updated AMBARI-18427:
-
Priority: Critical (was: Major)
> Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
>
>
> Key: AMBARI-18427
> URL: https://issues.apache.org/jira/browse/AMBARI-18427
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
>Reporter: Hari Sekhon
>Priority: Critical
>
> I hit this issue yesterday after upgrading ambari-agent:
> {code}
> Verifying Python version compatibility...
> Using python /usr/bin/pythonChecking for previously running Ambari Agent...
> Starting ambari-agentVerifying ambari-agent process status...
> ERROR: ambari-agent start failed. For more details, see
> /var/log/ambari-agent/ambari-agent.out:
>
> Traceback (most recent call last):
>File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
> 24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
>File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 41, in from ambari_agent.ActionQueue import ActionQueue
>File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
> 37, in from ambari_commons.str_utils import split_on_chunks
> ImportError: cannot import name split_on_chunks
>
> {code}
> I'm not the first person to have encountered it, see:
> https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
> Considering this is an existing cluster the solution of rm -rf'ing the entire
> python2.6 site-packages seems excessive...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Sekhon updated AMBARI-18427:
-
Priority: Blocker (was: Critical)
> Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
>
>
> Key: AMBARI-18427
> URL: https://issues.apache.org/jira/browse/AMBARI-18427
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
>Reporter: Hari Sekhon
>Priority: Blocker
>
> I hit this issue yesterday after upgrading ambari-agent:
> {code}
> Verifying Python version compatibility...
> Using python /usr/bin/pythonChecking for previously running Ambari Agent...
> Starting ambari-agentVerifying ambari-agent process status...
> ERROR: ambari-agent start failed. For more details, see
> /var/log/ambari-agent/ambari-agent.out:
>
> Traceback (most recent call last):
>File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
> 24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
>File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 41, in from ambari_agent.ActionQueue import ActionQueue
>File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
> 37, in from ambari_commons.str_utils import split_on_chunks
> ImportError: cannot import name split_on_chunks
>
> {code}
> I'm not the first person to have encountered it, see:
> https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
> Considering this is an existing cluster the solution of rm -rf'ing the entire
> python2.6 site-packages seems excessive...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Sekhon updated AMBARI-18427:
-
Environment: HDP 2.3
> Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
>
>
> Key: AMBARI-18427
> URL: https://issues.apache.org/jira/browse/AMBARI-18427
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
> Environment: HDP 2.3
>Reporter: Hari Sekhon
>Priority: Blocker
>
> I hit this issue yesterday after upgrading ambari-agent:
> {code}
> Verifying Python version compatibility...
> Using python /usr/bin/pythonChecking for previously running Ambari Agent...
> Starting ambari-agentVerifying ambari-agent process status...
> ERROR: ambari-agent start failed. For more details, see
> /var/log/ambari-agent/ambari-agent.out:
>
> Traceback (most recent call last):
>File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
> 24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
>File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 41, in from ambari_agent.ActionQueue import ActionQueue
>File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
> 37, in from ambari_commons.str_utils import split_on_chunks
> ImportError: cannot import name split_on_chunks
>
> {code}
> I'm not the first person to have encountered it, see:
> https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
> Considering this is an existing cluster the solution of rm -rf'ing the entire
> python2.6 site-packages seems excessive...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Sekhon updated AMBARI-18427:
-
Description:
I hit this issue yesterday after upgrading ambari-agent:
{code}
Verifying Python version compatibility...
Using python /usr/bin/pythonChecking for previously running Ambari Agent...
Starting ambari-agentVerifying ambari-agent process status...
ERROR: ambari-agent start failed. For more details, see
/var/log/ambari-agent/ambari-agent.out:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 41,
in from ambari_agent.ActionQueue import ActionQueue
File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
37, in from ambari_commons.str_utils import split_on_chunks
ImportError: cannot import name split_on_chunks
{code}
I'm not the first person to have encountered it, see:
https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
Considering this is an existing cluster the solution of rm -rf'ing the entire
python2.6 site-packages seems excessive
was:
I hit this issue yesterday after upgrading ambari-agent:
{code}
Verifying Python version compatibility...
Using python /usr/bin/pythonChecking for previously running Ambari Agent...
Starting ambari-agentVerifying ambari-agent process status...
ERROR: ambari-agent start failed. For more details, see
/var/log/ambari-agent/ambari-agent.out:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 41,
in from ambari_agent.ActionQueue import ActionQueue
File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
37, in from ambari_commons.str_utils import split_on_chunks
ImportError: cannot import name split_on_chunks
{code}
I'm not the first person to have encountered it, see:
https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
Considering this is an existing cluster the solution of rm -rf'ing the entire
python2.6 site-packages seems excessive...
> Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
>
>
> Key: AMBARI-18427
> URL: https://issues.apache.org/jira/browse/AMBARI-18427
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
> Environment: HDP 2.3
>Reporter: Hari Sekhon
>Priority: Blocker
>
> I hit this issue yesterday after upgrading ambari-agent:
> {code}
> Verifying Python version compatibility...
> Using python /usr/bin/pythonChecking for previously running Ambari Agent...
> Starting ambari-agentVerifying ambari-agent process status...
> ERROR: ambari-agent start failed. For more details, see
> /var/log/ambari-agent/ambari-agent.out:
>
> Traceback (most recent call last):
>File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
> 24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
>File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 41, in from ambari_agent.ActionQueue import ActionQueue
>File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
> 37, in from ambari_commons.str_utils import split_on_chunks
> ImportError: cannot import name split_on_chunks
>
> {code}
> I'm not the first person to have encountered it, see:
> https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
> Considering this is an existing cluster the solution of rm -rf'ing the entire
> python2.6 site-packages seems excessive
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18427) Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
[
https://issues.apache.org/jira/browse/AMBARI-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Sekhon updated AMBARI-18427:
-
Description:
I hit this issue yesterday after upgrading ambari-agent:
{code}
Verifying Python version compatibility...
Using python /usr/bin/pythonChecking for previously running Ambari Agent...
Starting ambari-agentVerifying ambari-agent process status...
ERROR: ambari-agent start failed. For more details, see
/var/log/ambari-agent/ambari-agent.out:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 41,
in from ambari_agent.ActionQueue import ActionQueue
File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
37, in from ambari_commons.str_utils import split_on_chunks
ImportError: cannot import name split_on_chunks
{code}
I'm not the first person to have encountered it, see:
https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
Considering this is an existing cluster the solution of rm -rf'ing the entire
python2.6 site-packages seems excessive...
was:
I hit this issue yesterday after upgrading ambari-agent:
{code}
Verifying Python version compatibility...
Using python /usr/bin/pythonChecking for previously running Ambari Agent...
Starting ambari-agentVerifying ambari-agent process status...
ERROR: ambari-agent start failed. For more details, see
/var/log/ambari-agent/ambari-agent.out:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line 41,
in from ambari_agent.ActionQueue import ActionQueue
File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
37, in from ambari_commons.str_utils import split_on_chunks
ImportError: cannot import name split_on_chunks
{code}
I'm not the first person to have encountered it, see:
https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
Considering this is an existing cluster the solution of rm -rf'ing the entire
python2.6 site-packages seems excessive
> Agent 2.4.0.1 start error "cannot import name split_on_chunks" after upgrade
>
>
> Key: AMBARI-18427
> URL: https://issues.apache.org/jira/browse/AMBARI-18427
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
> Environment: HDP 2.3
>Reporter: Hari Sekhon
>Priority: Blocker
>
> I hit this issue yesterday after upgrading ambari-agent:
> {code}
> Verifying Python version compatibility...
> Using python /usr/bin/pythonChecking for previously running Ambari Agent...
> Starting ambari-agentVerifying ambari-agent process status...
> ERROR: ambari-agent start failed. For more details, see
> /var/log/ambari-agent/ambari-agent.out:
>
> Traceback (most recent call last):
>File "/usr/lib/python2.6/site-packages/ambari_agent/AmbariAgent.py", line
> 24, in from Controller import AGENT_AUTO_RESTART_EXIT_CODE
>File "/usr/lib/python2.6/site-packages/ambari_agent/Controller.py", line
> 41, in from ambari_agent.ActionQueue import ActionQueue
>File "/usr/lib/python2.6/site-packages/ambari_agent/ActionQueue.py", line
> 37, in from ambari_commons.str_utils import split_on_chunks
> ImportError: cannot import name split_on_chunks
>
> {code}
> I'm not the first person to have encountered it, see:
> https://community.hortonworks.com/questions/55968/ambari-agent-start-failed-2.html
> Considering this is an existing cluster the solution of rm -rf'ing the entire
> python2.6 site-packages seems excessive...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18428) Atlas service check never fails
Andrew Onischuk created AMBARI-18428: Summary: Atlas service check never fails Key: AMBARI-18428 URL: https://issues.apache.org/jira/browse/AMBARI-18428 Project: Ambari Issue Type: Bug Reporter: Andrew Onischuk Assignee: Andrew Onischuk Fix For: 3.0.0 Attachments: AMBARI-18428.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18428) Atlas service check never fails
[ https://issues.apache.org/jira/browse/AMBARI-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-18428: - Attachment: AMBARI-18428.patch > Atlas service check never fails > --- > > Key: AMBARI-18428 > URL: https://issues.apache.org/jira/browse/AMBARI-18428 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-18428.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18428) Atlas service check never fails
[ https://issues.apache.org/jira/browse/AMBARI-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-18428: - Status: Patch Available (was: Open) > Atlas service check never fails > --- > > Key: AMBARI-18428 > URL: https://issues.apache.org/jira/browse/AMBARI-18428 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-18428.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18418) StackServiceDirectory debug messages are logged with placeholders
[
https://issues.apache.org/jira/browse/AMBARI-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18418:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk: commit 159546ad988f5ff3eab26256bcb36cc660d8a839
> StackServiceDirectory debug messages are logged with placeholders
> -
>
> Key: AMBARI-18418
> URL: https://issues.apache.org/jira/browse/AMBARI-18418
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18418_20160919_v1.patch
>
>
> Steps to reproduce:
> 1. Set {code}log4j.rootLogger=DEBUG,file{code} in
> {noformat}/etc/ambari-server/conf/log4j.properties{noformat}
> 2. Start Ambari server (no cluster needed)
> Result: ambari-server.log contains messages from StacksServiceDirectory with
> placeholders not replaced, eg.:
> {noformat}
> 08 Sep 2016 08:25:58,019 DEBUG [main] StackServiceDirectory:89 - Service
> package folder for service %s for stack %s has been resolved to %s
> 08 Sep 2016 08:25:58,019 DEBUG [main] StackServiceDirectory:115 - Service
> upgrades folder %s for service %s for stack %s does not exist.
> 08 Sep 2016 08:25:58,021 DEBUG [main] StackServiceDirectory:97 - Service
> package folder %s for service %s for stack %s does not exist.
> {noformat}
> Relevant code changed by:
> commit f8b427494b36c92f8a36c59d1a7233b5a130f4e7
> Author: Jayush Luniya
> Date: Thu May 19 14:21:22 2016 -0700
> AMBARI-15388 - Upgrade XML should be pushed down as much as possible to
> the services (Tim Thorpe via jluniya)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18419) Allow setting EclipseLink weave log level in build process
[
https://issues.apache.org/jira/browse/AMBARI-18419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18419:
---
Attachment: AMBARI-18419_20160921_v1.patch
Rebased to current trunk
> Allow setting EclipseLink weave log level in build process
> --
>
> Key: AMBARI-18419
> URL: https://issues.apache.org/jira/browse/AMBARI-18419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18419_20160921_v1.patch
>
>
> Ambari Serveri's build process includes eclipselink-staticweave-maven-plugin,
> with logLevel = ALL. This makes Maven output 17808 lines for EclipseLink
> even if running with -q.
> {noformat}
> [INFO] --- eclipselink-staticweave-maven-plugin:1.0.4:weave (default) @
> ambari-server ---
> [EL Finest]: jpa: 2016-09-19
> 16:52:30.507--ServerSession(1739278663)--Thread(Thread[main,5,main])--Begin
> predeploying Persistence Unit ambari-server; session ambari-server; state
> Initial; factoryCount 0
> [EL Finest]: properties: 2016-09-19
> 16:52:30.516--ServerSession(1739278663)--Thread(Thread[main,5,main])--property=eclipselink.weaving.changetracking;
> default value=true
> ...
> {noformat}
> The goal of this change is let developers to suppress EclipseLink log, while
> keeping the current behavior as default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18419) Allow setting EclipseLink weave log level in build process
[
https://issues.apache.org/jira/browse/AMBARI-18419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18419:
---
Attachment: (was: AMBARI-18419_20160919_v1.patch)
> Allow setting EclipseLink weave log level in build process
> --
>
> Key: AMBARI-18419
> URL: https://issues.apache.org/jira/browse/AMBARI-18419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18419_20160921_v1.patch
>
>
> Ambari Serveri's build process includes eclipselink-staticweave-maven-plugin,
> with logLevel = ALL. This makes Maven output 17808 lines for EclipseLink
> even if running with -q.
> {noformat}
> [INFO] --- eclipselink-staticweave-maven-plugin:1.0.4:weave (default) @
> ambari-server ---
> [EL Finest]: jpa: 2016-09-19
> 16:52:30.507--ServerSession(1739278663)--Thread(Thread[main,5,main])--Begin
> predeploying Persistence Unit ambari-server; session ambari-server; state
> Initial; factoryCount 0
> [EL Finest]: properties: 2016-09-19
> 16:52:30.516--ServerSession(1739278663)--Thread(Thread[main,5,main])--property=eclipselink.weaving.changetracking;
> default value=true
> ...
> {noformat}
> The goal of this change is let developers to suppress EclipseLink log, while
> keeping the current behavior as default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18419) Allow setting EclipseLink weave log level in build process
[
https://issues.apache.org/jira/browse/AMBARI-18419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18419:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk: commit 20997630d5be2a0d684a779b0daecb33ec54a4d6
> Allow setting EclipseLink weave log level in build process
> --
>
> Key: AMBARI-18419
> URL: https://issues.apache.org/jira/browse/AMBARI-18419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18419_20160921_v1.patch
>
>
> Ambari Serveri's build process includes eclipselink-staticweave-maven-plugin,
> with logLevel = ALL. This makes Maven output 17808 lines for EclipseLink
> even if running with -q.
> {noformat}
> [INFO] --- eclipselink-staticweave-maven-plugin:1.0.4:weave (default) @
> ambari-server ---
> [EL Finest]: jpa: 2016-09-19
> 16:52:30.507--ServerSession(1739278663)--Thread(Thread[main,5,main])--Begin
> predeploying Persistence Unit ambari-server; session ambari-server; state
> Initial; factoryCount 0
> [EL Finest]: properties: 2016-09-19
> 16:52:30.516--ServerSession(1739278663)--Thread(Thread[main,5,main])--property=eclipselink.weaving.changetracking;
> default value=true
> ...
> {noformat}
> The goal of this change is let developers to suppress EclipseLink log, while
> keeping the current behavior as default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18418) StackServiceDirectory debug messages are logged with placeholders
[
https://issues.apache.org/jira/browse/AMBARI-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509418#comment-15509418
]
Hudson commented on AMBARI-18418:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5702 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5702/])
AMBARI-18418. StackServiceDirectory debug messages are logged with (stoader:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=159546ad988f5ff3eab26256bcb36cc660d8a839])
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/stack/StackServiceDirectory.java
> StackServiceDirectory debug messages are logged with placeholders
> -
>
> Key: AMBARI-18418
> URL: https://issues.apache.org/jira/browse/AMBARI-18418
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18418_20160919_v1.patch
>
>
> Steps to reproduce:
> 1. Set {code}log4j.rootLogger=DEBUG,file{code} in
> {noformat}/etc/ambari-server/conf/log4j.properties{noformat}
> 2. Start Ambari server (no cluster needed)
> Result: ambari-server.log contains messages from StacksServiceDirectory with
> placeholders not replaced, eg.:
> {noformat}
> 08 Sep 2016 08:25:58,019 DEBUG [main] StackServiceDirectory:89 - Service
> package folder for service %s for stack %s has been resolved to %s
> 08 Sep 2016 08:25:58,019 DEBUG [main] StackServiceDirectory:115 - Service
> upgrades folder %s for service %s for stack %s does not exist.
> 08 Sep 2016 08:25:58,021 DEBUG [main] StackServiceDirectory:97 - Service
> package folder %s for service %s for stack %s does not exist.
> {noformat}
> Relevant code changed by:
> commit f8b427494b36c92f8a36c59d1a7233b5a130f4e7
> Author: Jayush Luniya
> Date: Thu May 19 14:21:22 2016 -0700
> AMBARI-15388 - Upgrade XML should be pushed down as much as possible to
> the services (Tim Thorpe via jluniya)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18428) Atlas service check never fails
[
https://issues.apache.org/jira/browse/AMBARI-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509421#comment-15509421
]
Hadoop QA commented on AMBARI-18428:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12829525/AMBARI-18428.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in ambari-server
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8703//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8703//console
This message is automatically generated.
> Atlas service check never fails
> ---
>
> Key: AMBARI-18428
> URL: https://issues.apache.org/jira/browse/AMBARI-18428
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-18428.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18424) Core-site should be provided for every stack advisor call (e.g. when deleting services)
[ https://issues.apache.org/jira/browse/AMBARI-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509513#comment-15509513 ] Andrii Babiichuk commented on AMBARI-18424: --- +1 for the patch > Core-site should be provided for every stack advisor call (e.g. when deleting > services) > --- > > Key: AMBARI-18424 > URL: https://issues.apache.org/jira/browse/AMBARI-18424 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18424.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18424) Core-site should be provided for every stack advisor call (e.g. when deleting services)
[ https://issues.apache.org/jira/browse/AMBARI-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509517#comment-15509517 ] Aleksandr Kovalenko commented on AMBARI-18424: -- committed to trunk > Core-site should be provided for every stack advisor call (e.g. when deleting > services) > --- > > Key: AMBARI-18424 > URL: https://issues.apache.org/jira/browse/AMBARI-18424 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18424.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18424) Core-site should be provided for every stack advisor call (e.g. when deleting services)
[ https://issues.apache.org/jira/browse/AMBARI-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Kovalenko updated AMBARI-18424: - Resolution: Fixed Status: Resolved (was: Patch Available) > Core-site should be provided for every stack advisor call (e.g. when deleting > services) > --- > > Key: AMBARI-18424 > URL: https://issues.apache.org/jira/browse/AMBARI-18424 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18424.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18401) Allow running a subset of Python unit tests
[
https://issues.apache.org/jira/browse/AMBARI-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18401:
---
Attachment: AMBARI-18401_20160921.patch
Rebased to current trunk
> Allow running a subset of Python unit tests
> ---
>
> Key: AMBARI-18401
> URL: https://issues.apache.org/jira/browse/AMBARI-18401
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18401_20160915_v2.patch,
> AMBARI-18401_20160921.patch
>
>
> Running all unit tests several times during development may take too much
> time. The Surefire Maven plugin can run a subset of Java unit tests by
> passing filter expression via the {{test}} property for test class names.
> However, running fewer than all Python unit tests is currently cumbersome, it
> requires renaming the unit test or modifying the {{unitTests.py}} script.
> The goal of this improvement is to implement the Surefire approach for
> filtering Python unit tests to be run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18429) Class typo eclipse PersistenceWweaed instead of PersistenceWeaved
Hari Sekhon created AMBARI-18429:
Summary: Class typo eclipse PersistenceWweaed instead of
PersistenceWeaved
Key: AMBARI-18429
URL: https://issues.apache.org/jira/browse/AMBARI-18429
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.1
Environment: HDP 2.3
Reporter: Hari Sekhon
Priority: Blocker
After upgrading Ambari to 2.4.1 I've just hit the following which appears to be
a class typo bug when running ambari-server upgrade:
{code}
2016-09-21 10:38:02,284 INFO - *** Check database
started ***
2016-09-21 10:38:02,543 ERROR - Unexpected error, database check failed
java.lang.NoClassDefFoundError:
org/eclipse/persistence/internal/weaving/PersistenceWweaed
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetPublicMethods(Class.java:2902)
at java.lang.Class.getMethods(Class.java:1615)
at
com.google.inject.assistedinject.FactoryProvider2.(FactoryProvider2.java:207)
at
com.google.inject.assistedinject.FactoryModuleBuilder$1.configure(FactoryModuleBuilder.java:334)
at com.google.inject.AbstractModule.configure(AbstractModule.java:59)
at
com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223)
at com.google.inject.AbstractModule.install(AbstractModule.java:118)
at
org.apache.ambari.server.controller.ControllerModule.installFactories(ControllerModule.java:456)
at
org.apache.ambari.server.controller.ControllerModule.configure(ControllerModule.java:291)
at
org.apache.ambari.server.checks.DatabaseConsistencyChecker$CheckHelperControllerModule.configure(DatabaseConsistencyChecker.java:66)
at com.google.inject.AbstractModule.configure(AbstractModule.java:59)
at
com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223)
at com.google.inject.spi.Elements.getElements(Elements.java:101)
at
com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:133)
at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:103)
at com.google.inject.Guice.createInjector(Guice.java:95)
at com.google.inject.Guice.createInjector(Guice.java:72)
at com.google.inject.Guice.createInjector(Guice.java:62)
at
org.apache.ambari.server.checks.DatabaseConsistencyChecker.main(DatabaseConsistencyChecker.java:102)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.persistence.internal.weaving.PersistenceWweaed
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 33 more
{code}
I've checked the jar contents and there is
org/eclipse/persistence/internal/weaving/PersistenceWeaved.class in
/usr/lib/ambari-server/eclipselink-2.6.2.jar so it looks like this is a typo in
the class name.
Not sure how this wasn't caught by the compiler, is this specified in some
embedded ini file in the jar and loaded with reflection or something? I grepped
/etc/ambari-server and it's not present in any config file there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18250) Pig View Caching issue causes File does not exist: /user//pig/jobs/job_id/stdout and stderr
[
https://issues.apache.org/jira/browse/AMBARI-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Nagar updated AMBARI-18250:
--
Fix Version/s: (was: trnk)
2.5.0
> Pig View Caching issue causes File does not exist:
> /user//pig/jobs/job_id/stdout and stderr
> ---
>
> Key: AMBARI-18250
> URL: https://issues.apache.org/jira/browse/AMBARI-18250
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: trnk
> Environment: All
>Reporter: JaySenSharma
>Assignee: JaySenSharma
> Labels: patch
> Fix For: 2.5.0
>
> Attachments: AMBARI-18250.patch
>
>
> Sometimes intermittently while runnign a script (like pwd; ) from Pig View
> it fails with the following error. Even though the script gets executed
> successfully and Even if that file exist in the HDFS.
> {code}
> ERROR qtp-ambari-client-27 ServiceFormattedException:92 - File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> ERROR qtp-ambari-client-27 ServiceFormattedException:95 -
> java.io.FileNotFoundException: File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> {code}
> After disabling the browser cache the issue did not occur.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18250) Pig View Caching issue causes File does not exist: /user//pig/jobs/job_id/stdout and stderr
[
https://issues.apache.org/jira/browse/AMBARI-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Nagar updated AMBARI-18250:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Pig View Caching issue causes File does not exist:
> /user//pig/jobs/job_id/stdout and stderr
> ---
>
> Key: AMBARI-18250
> URL: https://issues.apache.org/jira/browse/AMBARI-18250
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: trnk
> Environment: All
>Reporter: JaySenSharma
>Assignee: JaySenSharma
> Labels: patch
> Fix For: 2.5.0
>
> Attachments: AMBARI-18250.patch
>
>
> Sometimes intermittently while runnign a script (like pwd; ) from Pig View
> it fails with the following error. Even though the script gets executed
> successfully and Even if that file exist in the HDFS.
> {code}
> ERROR qtp-ambari-client-27 ServiceFormattedException:92 - File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> ERROR qtp-ambari-client-27 ServiceFormattedException:95 -
> java.io.FileNotFoundException: File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> {code}
> After disabling the browser cache the issue did not occur.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18250) Pig View Caching issue causes File does not exist: /user//pig/jobs/job_id/stdout and stderr
[
https://issues.apache.org/jira/browse/AMBARI-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509600#comment-15509600
]
Gaurav Nagar commented on AMBARI-18250:
---
committed to trunk and branch-2.5
> Pig View Caching issue causes File does not exist:
> /user//pig/jobs/job_id/stdout and stderr
> ---
>
> Key: AMBARI-18250
> URL: https://issues.apache.org/jira/browse/AMBARI-18250
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: trnk
> Environment: All
>Reporter: JaySenSharma
>Assignee: JaySenSharma
> Labels: patch
> Fix For: 2.5.0
>
> Attachments: AMBARI-18250.patch
>
>
> Sometimes intermittently while runnign a script (like pwd; ) from Pig View
> it fails with the following error. Even though the script gets executed
> successfully and Even if that file exist in the HDFS.
> {code}
> ERROR qtp-ambari-client-27 ServiceFormattedException:92 - File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> ERROR qtp-ambari-client-27 ServiceFormattedException:95 -
> java.io.FileNotFoundException: File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> {code}
> After disabling the browser cache the issue did not occur.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18419) Allow setting EclipseLink weave log level in build process
[
https://issues.apache.org/jira/browse/AMBARI-18419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509623#comment-15509623
]
Hudson commented on AMBARI-18419:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5703 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5703/])
AMBARI-18419. Allow setting EclipseLink weave log level in build (stoader:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=20997630d5be2a0d684a779b0daecb33ec54a4d6])
* (edit) ambari-server/pom.xml
> Allow setting EclipseLink weave log level in build process
> --
>
> Key: AMBARI-18419
> URL: https://issues.apache.org/jira/browse/AMBARI-18419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18419_20160921_v1.patch
>
>
> Ambari Serveri's build process includes eclipselink-staticweave-maven-plugin,
> with logLevel = ALL. This makes Maven output 17808 lines for EclipseLink
> even if running with -q.
> {noformat}
> [INFO] --- eclipselink-staticweave-maven-plugin:1.0.4:weave (default) @
> ambari-server ---
> [EL Finest]: jpa: 2016-09-19
> 16:52:30.507--ServerSession(1739278663)--Thread(Thread[main,5,main])--Begin
> predeploying Persistence Unit ambari-server; session ambari-server; state
> Initial; factoryCount 0
> [EL Finest]: properties: 2016-09-19
> 16:52:30.516--ServerSession(1739278663)--Thread(Thread[main,5,main])--property=eclipselink.weaving.changetracking;
> default value=true
> ...
> {noformat}
> The goal of this change is let developers to suppress EclipseLink log, while
> keeping the current behavior as default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-15538) Support service-specific repo for add-on services
[
https://issues.apache.org/jira/browse/AMBARI-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balázs Bence Sári resolved AMBARI-15538.
Resolution: Fixed
Fix committed to 2.4.2
> Support service-specific repo for add-on services
> -
>
> Key: AMBARI-15538
> URL: https://issues.apache.org/jira/browse/AMBARI-15538
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.1.0, 2.2.0, 2.4.0
>Reporter: Jayush Luniya
>Assignee: Balázs Bence Sári
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-15538-custom-repos-patch-branch-24.diff,
> AMBARI-15538-custom-repos-patch6-branch-25.diff,
> AMBARI-15538-custom-repos-patch6-trunk.diff
>
>
> The approach for custom-services to specify their own repo location will be
> to provide a {{/repos/repoinfo.xml}} inside the stack-version they will be
> in. This repo file will be loaded by Ambari during startup into the
> {{/api/v1/stacks/HDP/versions/2.4/repository_versions}} repos. *Service repo
> files have a restriction that their (repo-name, base-url) locations should be
> unique and not conflict*. When conflicts do occur, they will not be loaded
> into the stacks model.
> Now the management-pack will provide such repos/ folder in
> {{mpacks/custom-services/8.0.0/repos}} which will be linked into the stacks/
> folder.
> {{ambari/ambari-server/src/main/resources/stacks/HDP/2.3/services/SERVICE_NAME/repos
> -> mpacks/custom-services/8.0.0/repos}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akhil PB updated AMBARI-18266: -- Attachment: (was: Curl Timing.txt.zip) > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, ambari.properties, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akhil PB updated AMBARI-18266: -- Attachment: (was: ambari.properties) > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18250) Pig View Caching issue causes File does not exist: /user//pig/jobs/job_id/stdout and stderr
[
https://issues.apache.org/jira/browse/AMBARI-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509808#comment-15509808
]
Hudson commented on AMBARI-18250:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #64 (See
[https://builds.apache.org/job/Ambari-branch-2.5/64/])
AMBARI-18250. Pig View Caching issue causes File does not exist: (gnagar:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=66c5c983b133f04d6786444b08a8411b554275b9])
* (edit) contrib/views/pig/src/main/resources/ui/pig-web/app/initialize.js
> Pig View Caching issue causes File does not exist:
> /user//pig/jobs/job_id/stdout and stderr
> ---
>
> Key: AMBARI-18250
> URL: https://issues.apache.org/jira/browse/AMBARI-18250
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: trnk
> Environment: All
>Reporter: JaySenSharma
>Assignee: JaySenSharma
> Labels: patch
> Fix For: 2.5.0
>
> Attachments: AMBARI-18250.patch
>
>
> Sometimes intermittently while runnign a script (like pwd; ) from Pig View
> it fails with the following error. Even though the script gets executed
> successfully and Even if that file exist in the HDFS.
> {code}
> ERROR qtp-ambari-client-27 ServiceFormattedException:92 - File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> ERROR qtp-ambari-client-27 ServiceFormattedException:95 -
> java.io.FileNotFoundException: File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> {code}
> After disabling the browser cache the issue did not occur.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Nagar updated AMBARI-18266: -- Fix Version/s: 2.5.0 > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Fix For: 2.5.0 > > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Nagar updated AMBARI-18266: -- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk and branch-2.5 > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Fix For: 2.5.0 > > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18424) Core-site should be provided for every stack advisor call (e.g. when deleting services)
[ https://issues.apache.org/jira/browse/AMBARI-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509837#comment-15509837 ] Hudson commented on AMBARI-18424: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5704 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5704/]) AMBARI-18424. Core-site should be provided for every stack advisor call (akovalenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=04b4dc2a5d57f9b092ae336c2ba089c259b8a56e]) * (edit) ambari-web/app/utils/blueprint.js * (edit) ambari-web/test/mixins/common/configs/enhanced_configs_test.js * (edit) ambari-web/app/mixins/common/serverValidator.js * (edit) ambari-web/app/mixins/common/configs/enhanced_configs.js * (edit) ambari-web/app/utils/ajax/ajax.js * (edit) ambari-web/app/utils/config.js * (edit) ambari-web/app/controllers/main/admin/highAvailability/resourceManager/step3_controller.js > Core-site should be provided for every stack advisor call (e.g. when deleting > services) > --- > > Key: AMBARI-18424 > URL: https://issues.apache.org/jira/browse/AMBARI-18424 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Aleksandr Kovalenko >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18424.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18250) Pig View Caching issue causes File does not exist: /user//pig/jobs/job_id/stdout and stderr
[
https://issues.apache.org/jira/browse/AMBARI-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509838#comment-15509838
]
Hudson commented on AMBARI-18250:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5704 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5704/])
AMBARI-18250. Pig View Caching issue causes File does not exist: (gnagar:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=0f774139ec6d4dd85075e0227b59c6ded75d262e])
* (edit) contrib/views/pig/src/main/resources/ui/pig-web/app/initialize.js
> Pig View Caching issue causes File does not exist:
> /user//pig/jobs/job_id/stdout and stderr
> ---
>
> Key: AMBARI-18250
> URL: https://issues.apache.org/jira/browse/AMBARI-18250
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: trnk
> Environment: All
>Reporter: JaySenSharma
>Assignee: JaySenSharma
> Labels: patch
> Fix For: 2.5.0
>
> Attachments: AMBARI-18250.patch
>
>
> Sometimes intermittently while runnign a script (like pwd; ) from Pig View
> it fails with the following error. Even though the script gets executed
> successfully and Even if that file exist in the HDFS.
> {code}
> ERROR qtp-ambari-client-27 ServiceFormattedException:92 - File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> ERROR qtp-ambari-client-27 ServiceFormattedException:95 -
> java.io.FileNotFoundException: File
> /user/admin/pig/jobs/test_31-07-2016-23-18-52/stderr not found.
> {code}
> After disabling the browser cache the issue did not occur.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18430) Microsoft-R service should be supported on SLES11
Balázs Bence Sári created AMBARI-18430: -- Summary: Microsoft-R service should be supported on SLES11 Key: AMBARI-18430 URL: https://issues.apache.org/jira/browse/AMBARI-18430 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 2.4.1 Reporter: Balázs Bence Sári Assignee: Balázs Bence Sári Fix For: 2.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18430) Microsoft-R service should be supported on SLES11
[ https://issues.apache.org/jira/browse/AMBARI-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balázs Bence Sári updated AMBARI-18430: --- Description: Ensure that the Microsoft R management pack installs and runs correctly on SLES11. > Microsoft-R service should be supported on SLES11 > - > > Key: AMBARI-18430 > URL: https://issues.apache.org/jira/browse/AMBARI-18430 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Balázs Bence Sári >Assignee: Balázs Bence Sári > Fix For: 2.5.0 > > > Ensure that the Microsoft R management pack installs and runs correctly on > SLES11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18430) Microsoft-R service should be supported on SLES11
[ https://issues.apache.org/jira/browse/AMBARI-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balázs Bence Sári updated AMBARI-18430: --- Attachment: AMBARI-18430-SLES11-trunk-v1.patch Patch with the fix. > Microsoft-R service should be supported on SLES11 > - > > Key: AMBARI-18430 > URL: https://issues.apache.org/jira/browse/AMBARI-18430 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Balázs Bence Sári >Assignee: Balázs Bence Sári > Fix For: 2.5.0 > > Attachments: AMBARI-18430-SLES11-trunk-v1.patch > > > Ensure that the Microsoft R management pack installs and runs correctly on > SLES11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18430) Microsoft-R service should be supported on SLES11
[ https://issues.apache.org/jira/browse/AMBARI-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balázs Bence Sári updated AMBARI-18430: --- Status: Patch Available (was: In Progress) > Microsoft-R service should be supported on SLES11 > - > > Key: AMBARI-18430 > URL: https://issues.apache.org/jira/browse/AMBARI-18430 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Balázs Bence Sári >Assignee: Balázs Bence Sári > Fix For: 2.5.0 > > Attachments: AMBARI-18430-SLES11-trunk-v1.patch > > > Ensure that the Microsoft R management pack installs and runs correctly on > SLES11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510118#comment-15510118 ] Hudson commented on AMBARI-18266: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #65 (See [https://builds.apache.org/job/Ambari-branch-2.5/65/]) AMBARI-18266. Ambari Capacity Scheduler View fails to launch with 'Read (gnagar: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=cde0cb1d9cb6dd6ddae8b35aacbcef7a6a347536]) * (edit) contrib/views/capacity-scheduler/src/main/java/org/apache/ambari/view/capacityscheduler/ConfigurationService.java > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Fix For: 2.5.0 > > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18266) Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error
[ https://issues.apache.org/jira/browse/AMBARI-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510130#comment-15510130 ] Hudson commented on AMBARI-18266: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5705 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5705/]) AMBARI-18266. Ambari Capacity Scheduler View fails to launch with 'Read (gnagar: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=6038e0120989111fff2f8703216abffb96c93136]) * (edit) contrib/views/capacity-scheduler/src/main/java/org/apache/ambari/view/capacityscheduler/ConfigurationService.java > Ambari Capacity Scheduler View fails to launch with 'Read Timeout' error > > > Key: AMBARI-18266 > URL: https://issues.apache.org/jira/browse/AMBARI-18266 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.1 > Environment: Ambari-2.2.1 >Reporter: Akhil PB >Assignee: Akhil PB > Fix For: 2.5.0 > > Attachments: AMBARI-18266_trunk.patch, Capacity Scheduler View Error > Stack .txt, Updated Curl Timing.txt, jstack Ambari.txt > > > Capacity scheduler view fails to load majority of the time with a 'Read > timeout' error. Tried increasing thread count and view timeout values but > issue still persists. This is the only view that customer uses. > Attaching below docs to the EAR: > 1) Error stack from Capacity Scheduler view. > 2) ambari.properties > 3) jstack output of Ambari server PID > 4) timing of curl command prior to launching capacity scheduler view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reopened AMBARI-18406:
---
Reopened to fix a unit test
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: AMBARI-18406_trunk_03.patch
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510178#comment-15510178
]
Robert Levas commented on AMBARI-18406:
---
Reverted {{b4320b5a8d29b812e9fe86da69a219a17d5e4ea7}} from trunk
{noformat}
commit dcf779d28e511b07821e6f54702b918a87b22d02
Author: Robert Levas
Date: Wed Sep 21 10:42:10 2016 -0400
{noformat}
Committed to trunk:
{noformat}
commit 7e08470cfef5b9dd29724c318dd996d789e0414e
Author: Robert Levas
Date: Wed Sep 21 10:48:59 2016 -0400
{noformat}
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510217#comment-15510217
]
Robert Levas commented on AMBARI-18406:
---
Reverted {{14e44bfd240ae4f223fe5152fbede294e78084f9}} from branch-2.5
{noformat}
commit a84abf1493c4be1c0d2dc62e253e40bef1845566
Author: Robert Levas
Date: Wed Sep 21 10:51:22 2016 -0400
{noformat}
Committed to branch-2.5
{noformat}
commit d804387a8061aacec0c9014171c67151cf8fe87f
Author: Robert Levas
Date: Wed Sep 21 11:04:07 2016 -0400
{noformat}
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: AMBARI-18406_branch-2.5_03.patch
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-18406.
---
Resolution: Fixed
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18431) Storm Ambari view - Fixes to DAG, kafka offset info , Misc fixes.
Sriharsha Chintalapani created AMBARI-18431: --- Summary: Storm Ambari view - Fixes to DAG, kafka offset info , Misc fixes. Key: AMBARI-18431 URL: https://issues.apache.org/jira/browse/AMBARI-18431 Project: Ambari Issue Type: Improvement Reporter: Sriharsha Chintalapani Assignee: Sriharsha Chintalapani -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18432) Enable orchestration to use VDF
Nate Cole created AMBARI-18432: -- Summary: Enable orchestration to use VDF Key: AMBARI-18432 URL: https://issues.apache.org/jira/browse/AMBARI-18432 Project: Ambari Issue Type: Bug Components: ambari-server Reporter: Nate Cole Assignee: Nate Cole Fix For: 3.0.0 Re-enable code paths that supply services for RU/EU orchestration. The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Enable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Issue Type: Task (was: Bug) > Enable orchestration to use VDF > --- > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Reenable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Summary: Reenable orchestration to use VDF (was: Enable orchestration to use VDF) > Reenable orchestration to use VDF > - > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18433) Enforce granular role-based access control for custom actions
Robert Levas created AMBARI-18433:
-
Summary: Enforce granular role-based access control for custom
actions
Key: AMBARI-18433
URL: https://issues.apache.org/jira/browse/AMBARI-18433
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Levas
Assignee: Robert Levas
Priority: Critical
Fix For: 2.5.0
Enforce granular role-based access control for custom actions. Such actions
are specified in
{{/var/lib/ambari-server/resources/custom_action_definitions/system_action_definitions.xml}}
For example:
{code}
check_host
SYSTEM
60
General check for host
ANY
HOST.ADD_DELETE_HOSTS
{code}
The "permissions" element that declare the permissions required to run the
action. These permissions must be used to authorize a user to perform the
operation. A user needs to have one of the listed permissions in order to be
authorized.
The relevant API entry points are:
* {{/api/v1/requests}}
* {{/api/v1/requests/clusters/:CLUSTER_NAME/request}}
Example: The user executing the following REST API call must be assigned a
role that has the {{HOST.ADD_DELETE_HOSTS}} authorization for the relevant
cluster
{noformat}
POST /api/v1/requests
{
"RequestInfo": {
"action": "check_host",
"log_output": "false",
"context": "Check host",
"parameters": {
"check_execute_list":
"last_agent_env_check,installed_packages,existing_repos,transparentHugePage",
"jdk_location": "http://host1.example.com:8080/resources/";,
"threshold": "20"
}
},
"Requests/resource_filters": [
{
"hosts": "host1.example.com"
}
]
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18434) Fix upgrade configs for storm-site
Sandor Magyari created AMBARI-18434: --- Summary: Fix upgrade configs for storm-site Key: AMBARI-18434 URL: https://issues.apache.org/jira/browse/AMBARI-18434 Project: Ambari Issue Type: Bug Components: ambari-server Reporter: Sandor Magyari Assignee: Sandor Magyari Priority: Critical Fix upgrade configs for storm-site -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18434) Fix upgrade configs for storm-site
[ https://issues.apache.org/jira/browse/AMBARI-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18434: Fix Version/s: 2.5.0 > Fix upgrade configs for storm-site > -- > > Key: AMBARI-18434 > URL: https://issues.apache.org/jira/browse/AMBARI-18434 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > > Fix upgrade configs for storm-site -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Re-enable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Summary: Re-enable orchestration to use VDF (was: Reenable orchestration to use VDF) > Re-enable orchestration to use VDF > -- > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18435) Provide script to delete an old HDP stack version
[ https://issues.apache.org/jira/browse/AMBARI-18435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-18435: Status: Patch Available (was: Open) > Provide script to delete an old HDP stack version > - > > Key: AMBARI-18435 > URL: https://issues.apache.org/jira/browse/AMBARI-18435 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-18435.patch > > > We need a script or hacky solution internally for base-cluster to be able to > delete old HDP stacks. > This does not need to be a full-blown feature with tons of bells and whistles > and UI support. > Instead, it needs to be a simple script that can be ran on all hosts. > Ideally, it would accept the version of the stack to remove, and perhaps can > go into contrib. > If we want to make it slightly better, than we can figure out how to actually > make it a custom command to remove older versions (value is less than the > CURRENT version). > If done this way, we can add checks to make it more robust, bubble up errors > to the UI task output, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18435) Provide script to delete an old HDP stack version
Dmitry Lysnichenko created AMBARI-18435: --- Summary: Provide script to delete an old HDP stack version Key: AMBARI-18435 URL: https://issues.apache.org/jira/browse/AMBARI-18435 Project: Ambari Issue Type: Task Reporter: Dmitry Lysnichenko Assignee: Dmitry Lysnichenko Attachments: AMBARI-18435.patch We need a script or hacky solution internally for base-cluster to be able to delete old HDP stacks. This does not need to be a full-blown feature with tons of bells and whistles and UI support. Instead, it needs to be a simple script that can be ran on all hosts. Ideally, it would accept the version of the stack to remove, and perhaps can go into contrib. If we want to make it slightly better, than we can figure out how to actually make it a custom command to remove older versions (value is less than the CURRENT version). If done this way, we can add checks to make it more robust, bubble up errors to the UI task output, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18435) Provide script to delete an old HDP stack version
[ https://issues.apache.org/jira/browse/AMBARI-18435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-18435: Component/s: ambari-server > Provide script to delete an old HDP stack version > - > > Key: AMBARI-18435 > URL: https://issues.apache.org/jira/browse/AMBARI-18435 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-18435.patch > > > We need a script or hacky solution internally for base-cluster to be able to > delete old HDP stacks. > This does not need to be a full-blown feature with tons of bells and whistles > and UI support. > Instead, it needs to be a simple script that can be ran on all hosts. > Ideally, it would accept the version of the stack to remove, and perhaps can > go into contrib. > If we want to make it slightly better, than we can figure out how to actually > make it a custom command to remove older versions (value is less than the > CURRENT version). > If done this way, we can add checks to make it more robust, bubble up errors > to the UI task output, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18435) Provide script to delete an old HDP stack version
[ https://issues.apache.org/jira/browse/AMBARI-18435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Lysnichenko updated AMBARI-18435: Attachment: AMBARI-18435.patch > Provide script to delete an old HDP stack version > - > > Key: AMBARI-18435 > URL: https://issues.apache.org/jira/browse/AMBARI-18435 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Dmitry Lysnichenko >Assignee: Dmitry Lysnichenko > Attachments: AMBARI-18435.patch > > > We need a script or hacky solution internally for base-cluster to be able to > delete old HDP stacks. > This does not need to be a full-blown feature with tons of bells and whistles > and UI support. > Instead, it needs to be a simple script that can be ran on all hosts. > Ideally, it would accept the version of the stack to remove, and perhaps can > go into contrib. > If we want to make it slightly better, than we can figure out how to actually > make it a custom command to remove older versions (value is less than the > CURRENT version). > If done this way, we can add checks to make it more robust, bubble up errors > to the UI task output, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18434) Fix upgrade configs for storm-site
[ https://issues.apache.org/jira/browse/AMBARI-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Magyari updated AMBARI-18434: Affects Version/s: 2.4.0 > Fix upgrade configs for storm-site > -- > > Key: AMBARI-18434 > URL: https://issues.apache.org/jira/browse/AMBARI-18434 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Sandor Magyari >Assignee: Sandor Magyari >Priority: Critical > Fix For: 2.5.0 > > > Fix upgrade configs for storm-site -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18434) Fix upgrade configs for storm-site
[
https://issues.apache.org/jira/browse/AMBARI-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Magyari updated AMBARI-18434:
Description:
Upgrade configs in config-upgrade.xml in hdp_2_5_0_0_add_storm_security_configs
definition for HDP 2.3 & HDP 2.4 for storm-site are not correct, since there
are three config properties to be set, but only one of them will be set, the
first which meets the condition:
{code}
storm-site
nimbus.impersonation.authorizer
org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer
storm-site
nimbus.impersonation.acl
"{ {{storm_bare_jaas_principal}} : {hosts: ['*'], groups:
['*']}}"
storm-site
nimbus.admins
"['{{storm_bare_jaas_principal}}',
'{{ambari_bare_jaas_principal}}']"
{code}
was:Fix upgrade configs for storm-site
> Fix upgrade configs for storm-site
> --
>
> Key: AMBARI-18434
> URL: https://issues.apache.org/jira/browse/AMBARI-18434
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.5.0
>
>
> Upgrade configs in config-upgrade.xml in
> hdp_2_5_0_0_add_storm_security_configs definition for HDP 2.3 & HDP 2.4 for
> storm-site are not correct, since there are three config properties to be
> set, but only one of them will be set, the first which meets the condition:
> {code}
>
>
> storm-site
> nimbus.impersonation.authorizer
>
> org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer
>
>
> storm-site
> nimbus.impersonation.acl
> "{ {{storm_bare_jaas_principal}} : {hosts: ['*'],
> groups: ['*']}}"
>
>
> storm-site
> nimbus.admins
> "['{{storm_bare_jaas_principal}}',
> '{{ambari_bare_jaas_principal}}']"
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510442#comment-15510442
]
Hudson commented on AMBARI-18406:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5706 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5706/])
Revert "AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=dcf779d28e511b07821e6f54702b918a87b22d02])
* (edit) ambari-project/pom.xml
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsService.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidator.java
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidatorTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilter.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIndetityServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariEntryPoint.java
* (edit) ambari-server/pom.xml
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelper.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/AbstractPrepareKerberosServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosServerAction.java
* (edit) ambari-server/src/main/resources/webapp/WEB-INF/spring-security.xml
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilterTest.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond w
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510453#comment-15510453
]
Hudson commented on AMBARI-18406:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #66 (See
[https://builds.apache.org/job/Ambari-branch-2.5/66/])
Revert "AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=a84abf1493c4be1c0d2dc62e253e40bef1845566])
* (edit) ambari-project/pom.xml
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelper.java
* (edit) ambari-server/pom.xml
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsService.java
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilterTest.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIndetityServerAction.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilter.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidatorTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/AbstractPrepareKerberosServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariEntryPoint.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidator.java
* (edit) ambari-server/src/main/resources/webapp/WEB-INF/spring-security.xml
* (delete)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the
[jira] [Reopened] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas reopened AMBARI-18406:
---
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch, AMBARI-18406_trunk_03_ammended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: AMBARI-18406_trunk_03_ammended.patch
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch, AMBARI-18406_trunk_03_ammended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: AMBARI-18406_trunk_03_amended.patch
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch, AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: (was: AMBARI-18406_trunk_03_ammended.patch)
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_trunk_01.patch, AMBARI-18406_trunk_02.patch,
> AMBARI-18406_trunk_03.patch, AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Re-enable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Attachment: AMBARI-18432.patch > Re-enable orchestration to use VDF > -- > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > Attachments: AMBARI-18432.patch > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Re-enable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Status: Patch Available (was: Open) > Re-enable orchestration to use VDF > -- > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > Attachments: AMBARI-18432.patch > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18406:
--
Attachment: AMBARI-18406_branch-2.5_03_amended.patch
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-18406.
---
Resolution: Fixed
Committed to amendment trunk
{noformat}
commit 3939afaf6e30d95186e5cce92712b4485c2013bf
Author: Robert Levas
Date: Wed Sep 21 13:07:44 2016 -0400
{noformat}
Committed to amendment to branch-2.5
{noformat}
commit 39b75711bd49bf8c51a01026e65546bd288ab45a
Author: Robert Levas
Date: Wed Sep 21 13:11:17 2016 -0400
{noformat}
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18434) Fix upgrade configs for storm-site
[
https://issues.apache.org/jira/browse/AMBARI-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Magyari updated AMBARI-18434:
Status: Patch Available (was: Open)
> Fix upgrade configs for storm-site
> --
>
> Key: AMBARI-18434
> URL: https://issues.apache.org/jira/browse/AMBARI-18434
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18434.patch
>
>
> Upgrade configs in config-upgrade.xml in
> hdp_2_5_0_0_add_storm_security_configs definition for HDP 2.3 & HDP 2.4 for
> storm-site are not correct, since there are three config properties to be
> set, but only one of them will be set, the first which meets the condition:
> {code}
>
>
> storm-site
> nimbus.impersonation.authorizer
>
> org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer
>
>
> storm-site
> nimbus.impersonation.acl
> "{ {{storm_bare_jaas_principal}} : {hosts: ['*'],
> groups: ['*']}}"
>
>
> storm-site
> nimbus.admins
> "['{{storm_bare_jaas_principal}}',
> '{{ambari_bare_jaas_principal}}']"
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18434) Fix upgrade configs for storm-site
[
https://issues.apache.org/jira/browse/AMBARI-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Magyari updated AMBARI-18434:
Attachment: AMBARI-18434.patch
> Fix upgrade configs for storm-site
> --
>
> Key: AMBARI-18434
> URL: https://issues.apache.org/jira/browse/AMBARI-18434
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sandor Magyari
>Assignee: Sandor Magyari
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18434.patch
>
>
> Upgrade configs in config-upgrade.xml in
> hdp_2_5_0_0_add_storm_security_configs definition for HDP 2.3 & HDP 2.4 for
> storm-site are not correct, since there are three config properties to be
> set, but only one of them will be set, the first which meets the condition:
> {code}
>
>
> storm-site
> nimbus.impersonation.authorizer
>
> org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer
>
>
> storm-site
> nimbus.impersonation.acl
> "{ {{storm_bare_jaas_principal}} : {hosts: ['*'],
> groups: ['*']}}"
>
>
> storm-site
> nimbus.admins
> "['{{storm_bare_jaas_principal}}',
> '{{ambari_bare_jaas_principal}}']"
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510676#comment-15510676
]
Hudson commented on AMBARI-18406:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5707 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5707/])
AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7e08470cfef5b9dd29724c318dd996d789e0414e])
* (edit) ambari-server/pom.xml
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/AbstractPrepareKerberosServerAction.java
* (edit) ambari-server/src/main/resources/webapp/WEB-INF/spring-security.xml
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidator.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIndetityServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelper.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariEntryPoint.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsService.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilterTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosServerAction.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidatorTest.java
* (edit) ambari-project/pom.xml
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilter.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate th
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510678#comment-15510678
]
Hudson commented on AMBARI-18406:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #67 (See
[https://builds.apache.org/job/Ambari-branch-2.5/67/])
AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d804387a8061aacec0c9014171c67151cf8fe87f])
* (add)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilter.java
* (delete)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIndetityServerAction.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelper.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsService.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/CreatePrincipalsServerAction.java
* (edit) ambari-server/pom.xml
* (add)
ambari-server/src/main/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidator.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosTicketValidatorTest.java
* (edit) ambari-server/src/main/resources/webapp/WEB-INF/spring-security.xml
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariKerberosAuthenticationFilterTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/AbstractPrepareKerberosServerAction.java
* (edit) ambari-project/pom.xml
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariEntryPoint.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosServerAction.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token.
[jira] [Updated] (AMBARI-15059) UI for user home directory creation
[ https://issues.apache.org/jira/browse/AMBARI-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Zang updated AMBARI-15059: -- Fix Version/s: (was: 2.4.0) 2.5.0 > UI for user home directory creation > --- > > Key: AMBARI-15059 > URL: https://issues.apache.org/jira/browse/AMBARI-15059 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Richard Zang >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-15059.patch, AMBARI-15059_fix1.patch, > RP-4908-v1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15059) UI for user home directory creation
[ https://issues.apache.org/jira/browse/AMBARI-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Zang updated AMBARI-15059: -- Resolution: Fixed Status: Resolved (was: Patch Available) > UI for user home directory creation > --- > > Key: AMBARI-15059 > URL: https://issues.apache.org/jira/browse/AMBARI-15059 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Richard Zang >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-15059.patch, AMBARI-15059_fix1.patch, > RP-4908-v1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15059) UI for user home directory creation
[ https://issues.apache.org/jira/browse/AMBARI-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510785#comment-15510785 ] Richard Zang commented on AMBARI-15059: --- Committed to trunk and 2.5 e2e8c138649fca25a6c164c51bc439ef19219f43. > UI for user home directory creation > --- > > Key: AMBARI-15059 > URL: https://issues.apache.org/jira/browse/AMBARI-15059 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Aleksandr Kovalenko >Assignee: Richard Zang >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-15059.patch, AMBARI-15059_fix1.patch, > RP-4908-v1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18432) Re-enable orchestration to use VDF
[ https://issues.apache.org/jira/browse/AMBARI-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18432: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Re-enable orchestration to use VDF > -- > > Key: AMBARI-18432 > URL: https://issues.apache.org/jira/browse/AMBARI-18432 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole > Fix For: 3.0.0 > > Attachments: AMBARI-18432.patch > > > Re-enable code paths that supply services for RU/EU orchestration. > The code that was written (and removed) that was working had predated VDF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18436) Add service wizard: Customize service page keeps showing spinner
Jaimin D Jetly created AMBARI-18436: --- Summary: Add service wizard: Customize service page keeps showing spinner Key: AMBARI-18436 URL: https://issues.apache.org/jira/browse/AMBARI-18436 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Jaimin D Jetly Assignee: Jaimin D Jetly Priority: Critical Fix For: 2.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18436) Add service wizard: Customize service page keeps showing spinner
[ https://issues.apache.org/jira/browse/AMBARI-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18436: Description: When there is an installed service that has no config, it results in JS error while navigating to "Customize Services" page *STR:* * Install a blueprint provisioned cluster with a custom service that has one config-type for example: x-site.xml. Keep this site empty with no properties * After cluster installation, try to add Slider service. *Expected Result:* User should be able to add Slider service. *Actual Result:* While navigating to "Customize Services" page, spinner keeps showing. JS error noticed in dev console > Add service wizard: Customize service page keeps showing spinner > > > Key: AMBARI-18436 > URL: https://issues.apache.org/jira/browse/AMBARI-18436 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly >Priority: Critical > Fix For: 2.4.2 > > > When there is an installed service that has no config, it results in JS error > while navigating to > "Customize Services" page > *STR:* > * Install a blueprint provisioned cluster with a custom service that has one > config-type for example: x-site.xml. Keep this site empty with no properties > * After cluster installation, try to add Slider service. > *Expected Result:* User should be able to add Slider service. > *Actual Result:* While navigating to "Customize Services" page, spinner keeps > showing. JS error noticed in dev console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18436) Add service wizard: Customize service page keeps showing spinner
[ https://issues.apache.org/jira/browse/AMBARI-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18436: Attachment: AMBARI-18436.patch > Add service wizard: Customize service page keeps showing spinner > > > Key: AMBARI-18436 > URL: https://issues.apache.org/jira/browse/AMBARI-18436 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly >Priority: Critical > Fix For: 2.4.2 > > Attachments: AMBARI-18436.patch > > > When there is an installed service that has no config, it results in JS error > while navigating to > "Customize Services" page > *STR:* > * Install a blueprint provisioned cluster with a custom service that has one > config-type for example: x-site.xml. Keep this site empty with no properties > * After cluster installation, try to add Slider service. > *Expected Result:* User should be able to add Slider service. > *Actual Result:* While navigating to "Customize Services" page, spinner keeps > showing. JS error noticed in dev console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18436) Add service wizard: Customize service page keeps showing spinner
[ https://issues.apache.org/jira/browse/AMBARI-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18436: Status: Patch Available (was: Open) Tested the patch manually on a cluster Verified that all unit tests passes with the patch: 29243 tests complete (28 seconds) 154 tests pending > Add service wizard: Customize service page keeps showing spinner > > > Key: AMBARI-18436 > URL: https://issues.apache.org/jira/browse/AMBARI-18436 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly >Priority: Critical > Fix For: 2.4.2 > > Attachments: AMBARI-18436.patch > > > When there is an installed service that has no config, it results in JS error > while navigating to > "Customize Services" page > *STR:* > * Install a blueprint provisioned cluster with a custom service that has one > config-type for example: x-site.xml. Keep this site empty with no properties > * After cluster installation, try to add Slider service. > *Expected Result:* User should be able to add Slider service. > *Actual Result:* While navigating to "Customize Services" page, spinner keeps > showing. JS error noticed in dev console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510909#comment-15510909
]
Hudson commented on AMBARI-18406:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #68 (See
[https://builds.apache.org/job/Ambari-branch-2.5/68/])
AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=39b75711bd49bf8c51a01026e65546bd288ab45a])
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
[
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510935#comment-15510935
]
Hudson commented on AMBARI-18406:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5708 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5708/])
AMBARI-18406. Create authentication filter to perform Kerberos (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=3939afaf6e30d95186e5cce92712b4485c2013bf])
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java
> Create authentication filter to perform Kerberos authentication for Ambari
> --
>
> Key: AMBARI-18406
> URL: https://issues.apache.org/jira/browse/AMBARI-18406
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: authentication, kerberos, security
> Fix For: 2.5.0
>
> Attachments: AMBARI-18406_branch-2.5_01.patch,
> AMBARI-18406_branch-2.5_02.patch, AMBARI-18406_branch-2.5_03.patch,
> AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
> AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch,
> AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos
> token using SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism. This
> includes access to the Ambari REST API as well as the Ambari web-based UI.
> The implementation should support the ability to perform the full SPNEGO
> handshake as well as access requests directly providing the appropriate HTTP
> header containing the Kerberos token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including
> the header {{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing
> the authentication header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}})
> when authentication is needed, a _hint_ must be sent along with the request
> indicate to Ambari that Kerberos authentication is desired. If this _hint_
> is received, then Ambari will respond with the appropriate status and header
> to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header
> named "X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos
> token is received by Ambari, Ambari is to parse and validate the token. If a
> failure occurs, Ambari is to respond with the appropriate HTTP status and
> related header(s). Upon success, the user's principal name is retrieved and
> converted into a _local_ user name. The use of an auth-to-local rule set
> processor may be needed to perform this translation. Using this _local_
> username, an appropriate Ambari user account is located and used as the
> authenticated users identity - details, privileges, etc Failure to find
> an appropriate Ambari user account is to result in an authentication failure
> response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18437) Hive view not working on LLAP enabled cluster
DIPAYAN BHOWMICK created AMBARI-18437:
-
Summary: Hive view not working on LLAP enabled cluster
Key: AMBARI-18437
URL: https://issues.apache.org/jira/browse/AMBARI-18437
Project: Ambari
Issue Type: Bug
Components: ambari-views
Affects Versions: 2.4.0
Reporter: DIPAYAN BHOWMICK
Assignee: DIPAYAN BHOWMICK
Hive view shows "java.lang.Exception: Cannot connect to hive" error
{code:java}
20 Sep 2016 08:44:15,298 ERROR
[HiveViewActorSystem-akka.actor.jdbc-connector-dispatcher-5] [HIVE 1.5.0
HiveView123] JdbcConnector:419 - Failed to create a hive connection. {}
org.apache.ambari.view.hive2.internal.ConnectionException: Cannot open a hive
connection with connect string
jdbc:hive2://hn0-4117d3.ambhviewl-am25-ssh.h8.internal.cloudapp.net:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;;hive.server2.proxy.user=admin
at
org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:63)
at
org.apache.ambari.view.hive2.actor.JdbcConnector.connect(JdbcConnector.java:416)
at
org.apache.ambari.view.hive2.actor.JdbcConnector.handleNonLifecycleMessage(JdbcConnector.java:179)
at
org.apache.ambari.view.hive2.actor.JdbcConnector.handleMessage(JdbcConnector.java:171)
at
org.apache.ambari.view.hive2.actor.HiveActor.onReceive(HiveActor.java:38)
at
akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)
at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
at akka.actor.ActorCell.invoke(ActorCell.scala:487)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
at akka.dispatch.Mailbox.run(Mailbox.scala:220)
at
akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: java.sql.SQLException:
org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read HiveServer2
configs from ZooKeeper
at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:134)
at org.apache.hive.jdbc.HiveDriver.connect(HiveDriver.java:107)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at
org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:59)
... 16 more
Caused by: org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read
HiveServer2 configs from ZooKeeper
at
org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:96)
at org.apache.hive.jdbc.Utils.configureConnParams(Utils.java:514)
at org.apache.hive.jdbc.Utils.parseURL(Utils.java:434)
at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:132)
... 20 more
Caused by: org.apache.zookeeper.KeeperException$NoNodeException:
KeeperErrorCode = NoNode for /hiveserver2
at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1590)
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:214)
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:203)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl.pathInForeground(GetChildrenBuilderImpl.java:199)
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:191)
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:38)
at
org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:64)
... 23 more
20 Sep 2016 08:44:15,314 ERROR [ambari-client-thread-2148] [HIVE 1.5.0
HiveView123] DDLDelegatorImpl:200 - Failed to get the table description
20 Sep 2016 08:44:15,319 ERROR [ambari-client-thread-2148] [HIVE 1.5.0
HiveView123] ServiceFormattedException:97 - Cannot connect to hive
20 Sep 2016 08:44:15,319 ERROR [ambari-client-thread-2148] [HIVE 1.5.0
HiveView123] ServiceFormattedException:98 - java.lang.Exception: Cannot connect
to hive
[jira] [Updated] (AMBARI-18437) Hive view not working on LLAP enabled cluster
[
https://issues.apache.org/jira/browse/AMBARI-18437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DIPAYAN BHOWMICK updated AMBARI-18437:
--
Attachment: AMBARI-18437.branch-2.4.patch
> Hive view not working on LLAP enabled cluster
> -
>
> Key: AMBARI-18437
> URL: https://issues.apache.org/jira/browse/AMBARI-18437
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.4.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
> Attachments: AMBARI-18437.branch-2.4.patch
>
>
> Hive view shows "java.lang.Exception: Cannot connect to hive" error
> {code:java}
> 20 Sep 2016 08:44:15,298 ERROR
> [HiveViewActorSystem-akka.actor.jdbc-connector-dispatcher-5] [HIVE 1.5.0
> HiveView123] JdbcConnector:419 - Failed to create a hive connection. {}
> org.apache.ambari.view.hive2.internal.ConnectionException: Cannot open a hive
> connection with connect string
> jdbc:hive2://hn0-4117d3.ambhviewl-am25-ssh.h8.internal.cloudapp.net:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;;hive.server2.proxy.user=admin
> at
> org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:63)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.connect(JdbcConnector.java:416)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.handleNonLifecycleMessage(JdbcConnector.java:179)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.handleMessage(JdbcConnector.java:171)
> at
> org.apache.ambari.view.hive2.actor.HiveActor.onReceive(HiveActor.java:38)
> at
> akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)
> at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
> at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
> at akka.actor.ActorCell.invoke(ActorCell.scala:487)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
> at
> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
> at
> scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> at
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
> at
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> Caused by: java.sql.SQLException:
> org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read HiveServer2
> configs from ZooKeeper
> at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:134)
> at org.apache.hive.jdbc.HiveDriver.connect(HiveDriver.java:107)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at
> org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:59)
> ... 16 more
> Caused by: org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read
> HiveServer2 configs from ZooKeeper
> at
> org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:96)
> at org.apache.hive.jdbc.Utils.configureConnParams(Utils.java:514)
> at org.apache.hive.jdbc.Utils.parseURL(Utils.java:434)
> at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:132)
> ... 20 more
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException:
> KeeperErrorCode = NoNode for /hiveserver2
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1590)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:214)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:203)
> at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.pathInForeground(GetChildrenBuilderImpl.java:199)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:191)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:38)
> at
> org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:64)
> ... 23 more
> 20 Sep 2016 08:44:15,314
[jira] [Created] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
Alejandro Fernandez created AMBARI-18438: Summary: Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users Key: AMBARI-18438 URL: https://issues.apache.org/jira/browse/AMBARI-18438 Project: Ambari Issue Type: Story Components: stacks Affects Versions: 2.5.0 Reporter: Alejandro Fernandez Assignee: Alejandro Fernandez Priority: Critical Fix For: 2.5.0 In order to support sysprepped clusters using Docker containers, we need more granular flags about what steps must be done, e.g., * Copy tarballs to HDFS * Copy Oozie share lib to HDFS * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ * Create users and groups These properties will be stored in cluster-env instead of ambari.properties so they can be changed without requiring a restart of Ambari Server. sysprep_skip_copy_tarballs_hdfs=true|false (default is false) sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) sysprep_create_users_and_groups=true|false (default is true) For existing users that have automated everything on a sysprepped cluster, they should set these flags as true, true, true, false, respectively. These flags are only valid if ambari.properties knows the cluster is sysprepped, i.e., packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18437) Hive view not working on LLAP enabled cluster
[
https://issues.apache.org/jira/browse/AMBARI-18437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DIPAYAN BHOWMICK updated AMBARI-18437:
--
Status: Patch Available (was: Open)
> Hive view not working on LLAP enabled cluster
> -
>
> Key: AMBARI-18437
> URL: https://issues.apache.org/jira/browse/AMBARI-18437
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.4.0
>Reporter: DIPAYAN BHOWMICK
>Assignee: DIPAYAN BHOWMICK
> Attachments: AMBARI-18437.branch-2.4.patch
>
>
> Hive view shows "java.lang.Exception: Cannot connect to hive" error
> {code:java}
> 20 Sep 2016 08:44:15,298 ERROR
> [HiveViewActorSystem-akka.actor.jdbc-connector-dispatcher-5] [HIVE 1.5.0
> HiveView123] JdbcConnector:419 - Failed to create a hive connection. {}
> org.apache.ambari.view.hive2.internal.ConnectionException: Cannot open a hive
> connection with connect string
> jdbc:hive2://hn0-4117d3.ambhviewl-am25-ssh.h8.internal.cloudapp.net:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;;hive.server2.proxy.user=admin
> at
> org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:63)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.connect(JdbcConnector.java:416)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.handleNonLifecycleMessage(JdbcConnector.java:179)
> at
> org.apache.ambari.view.hive2.actor.JdbcConnector.handleMessage(JdbcConnector.java:171)
> at
> org.apache.ambari.view.hive2.actor.HiveActor.onReceive(HiveActor.java:38)
> at
> akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)
> at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
> at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
> at akka.actor.ActorCell.invoke(ActorCell.scala:487)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
> at
> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
> at
> scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> at
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
> at
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> Caused by: java.sql.SQLException:
> org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read HiveServer2
> configs from ZooKeeper
> at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:134)
> at org.apache.hive.jdbc.HiveDriver.connect(HiveDriver.java:107)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at
> org.apache.ambari.view.hive2.internal.HiveConnectionWrapper.connect(HiveConnectionWrapper.java:59)
> ... 16 more
> Caused by: org.apache.hive.jdbc.ZooKeeperHiveClientException: Unable to read
> HiveServer2 configs from ZooKeeper
> at
> org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:96)
> at org.apache.hive.jdbc.Utils.configureConnParams(Utils.java:514)
> at org.apache.hive.jdbc.Utils.parseURL(Utils.java:434)
> at org.apache.hive.jdbc.HiveConnection.(HiveConnection.java:132)
> ... 20 more
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException:
> KeeperErrorCode = NoNode for /hiveserver2
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1590)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:214)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:203)
> at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.pathInForeground(GetChildrenBuilderImpl.java:199)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:191)
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:38)
> at
> org.apache.hive.jdbc.ZooKeeperHiveClientHelper.configureConnParams(ZooKeeperHiveClientHelper.java:64)
> ... 23 more
> 20 Sep 2016 08:44:15,314 ERROR
[jira] [Updated] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
[ https://issues.apache.org/jira/browse/AMBARI-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18438: - Attachment: topology.json install_packages.sh blueprint_fast_install_more_services.json > Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, > fast jar, and create users > > > Key: AMBARI-18438 > URL: https://issues.apache.org/jira/browse/AMBARI-18438 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: blueprint_fast_install_more_services.json, > install_packages.sh, topology.json > > > In order to support sysprepped clusters using Docker containers, we need more > granular flags about what steps must be done, e.g., > * Copy tarballs to HDFS > * Copy Oozie share lib to HDFS > * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ > * Create users and groups > These properties will be stored in cluster-env instead of ambari.properties > so they can be changed without requiring a restart of Ambari Server. > sysprep_skip_copy_tarballs_hdfs=true|false (default is false) > sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) > sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) > sysprep_create_users_and_groups=true|false (default is true) > For existing users that have automated everything on a sysprepped cluster, > they should set these flags as true, true, true, false, respectively. > These flags are only valid if ambari.properties knows the cluster is > sysprepped, i.e., > packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
[ https://issues.apache.org/jira/browse/AMBARI-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1558#comment-1558 ] Alejandro Fernandez commented on AMBARI-18438: -- To test this, I prepared 3 CentOS 6.4 VMs with the following. * Ambari Server on c6401 host (set ambari.properties file with packages.pre.installed=true) * Ambari Agent on all 3 hosts with manual registration (c6401, c6402, c6403) * Setup repo files, ** /etc/yum.repos.d/HDP.repo ** /etc/yum.repos.d/HDP-UTILS.repo * Installed bits by running install_packages.sh * Used blueprint [^blueprint_fast_install_more_services.json] and [^topology.json] > Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, > fast jar, and create users > > > Key: AMBARI-18438 > URL: https://issues.apache.org/jira/browse/AMBARI-18438 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: blueprint_fast_install_more_services.json, > install_packages.sh, topology.json > > > In order to support sysprepped clusters using Docker containers, we need more > granular flags about what steps must be done, e.g., > * Copy tarballs to HDFS > * Copy Oozie share lib to HDFS > * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ > * Create users and groups > These properties will be stored in cluster-env instead of ambari.properties > so they can be changed without requiring a restart of Ambari Server. > sysprep_skip_copy_tarballs_hdfs=true|false (default is false) > sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) > sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) > sysprep_create_users_and_groups=true|false (default is true) > For existing users that have automated everything on a sysprepped cluster, > they should set these flags as true, true, true, false, respectively. > These flags are only valid if ambari.properties knows the cluster is > sysprepped, i.e., > packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
[ https://issues.apache.org/jira/browse/AMBARI-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1558#comment-1558 ] Alejandro Fernandez edited comment on AMBARI-18438 at 9/21/16 8:44 PM: --- To test this, I prepared 3 CentOS 6.4 VMs with the following. * Ambari Server on c6401 host (set ambari.properties file with packages.pre.installed=true) * Ambari Agent on all 3 hosts with manual registration (c6401, c6402, c6403) * Setup repo files, ** /etc/yum.repos.d/HDP.repo ** /etc/yum.repos.d/HDP-UTILS.repo * Installed bits by running [^install_packages.sh] on each host * Used blueprint [^blueprint_fast_install_more_services.json] and [^topology.json] was (Author: afernandez): To test this, I prepared 3 CentOS 6.4 VMs with the following. * Ambari Server on c6401 host (set ambari.properties file with packages.pre.installed=true) * Ambari Agent on all 3 hosts with manual registration (c6401, c6402, c6403) * Setup repo files, ** /etc/yum.repos.d/HDP.repo ** /etc/yum.repos.d/HDP-UTILS.repo * Installed bits by running install_packages.sh * Used blueprint [^blueprint_fast_install_more_services.json] and [^topology.json] > Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, > fast jar, and create users > > > Key: AMBARI-18438 > URL: https://issues.apache.org/jira/browse/AMBARI-18438 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: blueprint_fast_install_more_services.json, > install_packages.sh, topology.json > > > In order to support sysprepped clusters using Docker containers, we need more > granular flags about what steps must be done, e.g., > * Copy tarballs to HDFS > * Copy Oozie share lib to HDFS > * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ > * Create users and groups > These properties will be stored in cluster-env instead of ambari.properties > so they can be changed without requiring a restart of Ambari Server. > sysprep_skip_copy_tarballs_hdfs=true|false (default is false) > sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) > sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) > sysprep_create_users_and_groups=true|false (default is true) > For existing users that have automated everything on a sysprepped cluster, > they should set these flags as true, true, true, false, respectively. > These flags are only valid if ambari.properties knows the cluster is > sysprepped, i.e., > packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
[ https://issues.apache.org/jira/browse/AMBARI-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18438: - Attachment: AMBARI-18438.trunk.patch AMBARI-18438.branch-2.5.patch > Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, > fast jar, and create users > > > Key: AMBARI-18438 > URL: https://issues.apache.org/jira/browse/AMBARI-18438 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18438.branch-2.5.patch, AMBARI-18438.trunk.patch, > blueprint_fast_install_more_services.json, install_packages.sh, topology.json > > > In order to support sysprepped clusters using Docker containers, we need more > granular flags about what steps must be done, e.g., > * Copy tarballs to HDFS > * Copy Oozie share lib to HDFS > * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ > * Create users and groups > These properties will be stored in cluster-env instead of ambari.properties > so they can be changed without requiring a restart of Ambari Server. > sysprep_skip_copy_tarballs_hdfs=true|false (default is false) > sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) > sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) > sysprep_create_users_and_groups=true|false (default is true) > For existing users that have automated everything on a sysprepped cluster, > they should set these flags as true, true, true, false, respectively. > These flags are only valid if ambari.properties knows the cluster is > sysprepped, i.e., > packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18426) Active ambari server check required in ambari server JAR
[ https://issues.apache.org/jira/browse/AMBARI-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nahappan Somasundaram updated AMBARI-18426: --- Attachment: rb52128.patch > Active ambari server check required in ambari server JAR > > > Key: AMBARI-18426 > URL: https://issues.apache.org/jira/browse/AMBARI-18426 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram >Priority: Critical > Attachments: rb52128.patch > > > Sometimes ambari server instances are started directly using the > ambari-server JAR instead of using ambari-server.py script. > The check for detecting if the current instance is the active instance is in > ambari-server.py script (AMBARI-13196) but not in the Java code. In order to > take care of this scenario, the same check is required in the Java code in > AmbariServer.java::main(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18426) Active ambari server check required in ambari server JAR
[ https://issues.apache.org/jira/browse/AMBARI-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nahappan Somasundaram updated AMBARI-18426: --- Status: Patch Available (was: In Progress) > Active ambari server check required in ambari server JAR > > > Key: AMBARI-18426 > URL: https://issues.apache.org/jira/browse/AMBARI-18426 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0 >Reporter: Nahappan Somasundaram >Assignee: Nahappan Somasundaram >Priority: Critical > Attachments: rb52128.patch > > > Sometimes ambari server instances are started directly using the > ambari-server JAR instead of using ambari-server.py script. > The check for detecting if the current instance is the active instance is in > ambari-server.py script (AMBARI-13196) but not in the Java code. In order to > take care of this scenario, the same check is required in the Java code in > AmbariServer.java::main(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18438) Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, fast jar, and create users
[ https://issues.apache.org/jira/browse/AMBARI-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-18438: - Status: Patch Available (was: Open) > Add granular flags for sysprepped clusters to copy tarballs, Oozie share lib, > fast jar, and create users > > > Key: AMBARI-18438 > URL: https://issues.apache.org/jira/browse/AMBARI-18438 > Project: Ambari > Issue Type: Story > Components: stacks >Affects Versions: 2.5.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez >Priority: Critical > Fix For: 2.5.0 > > Attachments: AMBARI-18438.branch-2.5.patch, AMBARI-18438.trunk.patch, > blueprint_fast_install_more_services.json, install_packages.sh, topology.json > > > In order to support sysprepped clusters using Docker containers, we need more > granular flags about what steps must be done, e.g., > * Copy tarballs to HDFS > * Copy Oozie share lib to HDFS > * Copy fast jar (fast-hdfs-resource.jar) to /var/lib/ambari-agent/lib/ > * Create users and groups > These properties will be stored in cluster-env instead of ambari.properties > so they can be changed without requiring a restart of Ambari Server. > sysprep_skip_copy_tarballs_hdfs=true|false (default is false) > sysprep_skip_copy_oozie_share_lib_to_hdfs=true|false (default is false) > sysprep_skip_copy_fast_jar_hdfs=true|false (default is false) > sysprep_create_users_and_groups=true|false (default is true) > For existing users that have automated everything on a sysprepped cluster, > they should set these flags as true, true, true, false, respectively. > These flags are only valid if ambari.properties knows the cluster is > sysprepped, i.e., > packages.pre.installed=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-6275) Add support for "add hosts" with Blueprints API
[ https://issues.apache.org/jira/browse/AMBARI-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511355#comment-15511355 ] Amruta Borkar commented on AMBARI-6275: --- Hi [~jspeidel] is the scenario specified in 'Specify an inlined hostgroup' [to scale a cluster using blueprint that was created using UI] implemented. I couldn't find a sub task for that. > Add support for "add hosts" with Blueprints API > --- > > Key: AMBARI-6275 > URL: https://issues.apache.org/jira/browse/AMBARI-6275 > Project: Ambari > Issue Type: Epic > Components: ambari-server >Affects Versions: 1.7.0 >Reporter: Yusaku Sako >Assignee: John Speidel > Fix For: 2.1.0 > > > Support for "adding hosts" based on *blueprint* style *host_group* via Ambari > REST API. There are two scenarios to consider for this JIRA: > 1) Add hosts based on an existing host in the cluster (and it's *blueprint* > style *host_group* component layout). This enables the user to add hosts with > components similar to existing hosts in the cluster. For example: expand this > cluster with these X hosts and make each of these hosts like Y host > (components + configs) existing in the cluster. > 2) Add hosts based on components + configs. This would be a verbose method > that uses *blueprint* style *host_groups* and *configs* to allow you to add > hosts to a cluster that do not necessarily have a component layout or config > of a similar host existing in the cluster. For example: expand this cluster > with these X hosts and make each of these hosts include Y components with Z > configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18439) [Grafana] Add Kafka-Lag dashboard for Storm
Prajwal Rao created AMBARI-18439: Summary: [Grafana] Add Kafka-Lag dashboard for Storm Key: AMBARI-18439 URL: https://issues.apache.org/jira/browse/AMBARI-18439 Project: Ambari Issue Type: Task Components: ambari-metrics Affects Versions: 2.5.0 Reporter: Prajwal Rao Assignee: Prajwal Rao Fix For: 2.5.0 Add the kafka-lag dashboard for the Storm component to visualize metrics per partition via Grafana -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18436) Add service wizard: Customize service page keeps showing spinner
[ https://issues.apache.org/jira/browse/AMBARI-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaimin D Jetly updated AMBARI-18436: Resolution: Fixed Status: Resolved (was: Patch Available) Received +1 on reviewboard. Patch committed to trunk, branch-2.4 and branch-2.5 > Add service wizard: Customize service page keeps showing spinner > > > Key: AMBARI-18436 > URL: https://issues.apache.org/jira/browse/AMBARI-18436 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Jaimin D Jetly >Assignee: Jaimin D Jetly >Priority: Critical > Fix For: 2.4.2 > > Attachments: AMBARI-18436.patch > > > When there is an installed service that has no config, it results in JS error > while navigating to > "Customize Services" page > *STR:* > * Install a blueprint provisioned cluster with a custom service that has one > config-type for example: x-site.xml. Keep this site empty with no properties > * After cluster installation, try to add Slider service. > *Expected Result:* User should be able to add Slider service. > *Actual Result:* While navigating to "Customize Services" page, spinner keeps > showing. JS error noticed in dev console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18440) Add the option of providing 'aux jars' while creating LLAP package.
Swapan Shridhar created AMBARI-18440: Summary: Add the option of providing 'aux jars' while creating LLAP package. Key: AMBARI-18440 URL: https://issues.apache.org/jira/browse/AMBARI-18440 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Swapan Shridhar Assignee: Swapan Shridhar Fix For: 2.4.2 - This option will help the user to provide auxiliary jars that they want to be included in the LLAP package creation and available for LLAP. - User can provide the path and JAR name as a comma separated list in 'hive-interactive-env' config 'hive_aux_jars'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMBARI-18425) Support PAM as an authentication option for Ranger in Ambari
[ https://issues.apache.org/jira/browse/AMBARI-18425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Wang reassigned AMBARI-18425: - Assignee: Shi Wang > Support PAM as an authentication option for Ranger in Ambari > > > Key: AMBARI-18425 > URL: https://issues.apache.org/jira/browse/AMBARI-18425 > Project: Ambari > Issue Type: Task > Components: ambari-server, ambari-web >Affects Versions: trunk >Reporter: Shi Wang >Assignee: Shi Wang > Labels: security > Fix For: trunk > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18425) Support PAM as an authentication option for Ranger in Ambari
[ https://issues.apache.org/jira/browse/AMBARI-18425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Wang updated AMBARI-18425: -- Description: Ranger-842 has added PAM support for ranger, we need to add this part to ambari, to do automatic setup for ranger to use PAM authentication. > Support PAM as an authentication option for Ranger in Ambari > > > Key: AMBARI-18425 > URL: https://issues.apache.org/jira/browse/AMBARI-18425 > Project: Ambari > Issue Type: Task > Components: ambari-server, ambari-web >Affects Versions: trunk >Reporter: Shi Wang >Assignee: Shi Wang > Labels: security > Fix For: trunk > > > Ranger-842 has added PAM support for ranger, we need to add this part to > ambari, to do automatic setup for ranger to use PAM authentication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18440) Add the option of providing 'aux jars' while creating LLAP package.
[ https://issues.apache.org/jira/browse/AMBARI-18440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-18440: - Status: Patch Available (was: Open) > Add the option of providing 'aux jars' while creating LLAP package. > --- > > Key: AMBARI-18440 > URL: https://issues.apache.org/jira/browse/AMBARI-18440 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.2 > > Attachments: AMBARI-18440.patch > > > - This option will help the user to provide auxiliary jars that they want to > be included in the LLAP package creation and available for LLAP. > - User can provide the path and JAR name as a comma separated list in > 'hive-interactive-env' config 'hive_aux_jars'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
