[jira] [Created] (AMBARI-22829) Services depending on HDFS do not start up properly (behind a proxy)
Alberto created AMBARI-22829: Summary: Services depending on HDFS do not start up properly (behind a proxy) Key: AMBARI-22829 URL: https://issues.apache.org/jira/browse/AMBARI-22829 Project: Ambari Issue Type: Bug Components: ambari-agent Affects Versions: 2.6.1 Reporter: Alberto Services that depend on HDFS (HBase, Hive...) fail to start when the calls to the HDFS API (http://:50070/webhdfs...> are redirected through a corporate proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-22828) Ambari agent registration passes even though the hostnames do not match
Srikanth Janardhan created AMBARI-22828:
---
Summary: Ambari agent registration passes even though the
hostnames do not match
Key: AMBARI-22828
URL: https://issues.apache.org/jira/browse/AMBARI-22828
Project: Ambari
Issue Type: Bug
Components: ambari-agent
Affects Versions: 2.6.2
Reporter: Srikanth Janardhan
Fix For: 2.6.2
h6. Test Steps
# # Setup Ambari and start it
# Start Deployment of HDP till Install Options page
# Enter different hostnames in Target Hosts field (for e.g. ambari-host.1 and
ambari-host.2)
# Change the hostnames for other hosts in the cluster in /etc/hosts in Ambari
Server machine to match the above 2 host names (e.g. x.x.x.x abc.example.com to
x.x.x.x ambari-host.1)
# At this point, other machines in the cluster have different host names from
what is provided in the server.
# Add the SSH keys in Install Options page and click "Register and Confirm"
h6. Expected
# The ambari agent registration fails in Ambari UI
# A Warning message appears in the agent logs: {quote}Ambari agent machine
hostname (ctr-e137-1514896590304-32888-01-05.hwx.site.) does not match
expected ambari server hostname (ambari.host-1). Aborting registration. Please
check hostname, hostname -f and /etc/hosts file to confirm your hostname is
setup correctly{quote}
h6. Actual
# Ambari agent registration passes successfully !Screen Shot 2018-01-23 at
12.34.06 PM.png|thumbnail!
# The warning message does not appear in agent logs.
Whereas attempting a restart of the agent with incorrect hostname does not
succeed:
{code:bash}
[root@ctr-e137-1514896590304-32888-01-03 ~]# /usr/sbin/ambari-agent restart
--expected-hostname=ambari.host-2
Restarting ambari-agent
Verifying Python version compatibility...
Using python /usr/bin/python
Found ambari-agent PID: 28192
Stopping ambari-agent
Removing PID file at /run/ambari-agent/ambari-agent.pid
ambari-agent successfully stopped
Verifying Python version compatibility...
Using python /usr/bin/python
Checking for previously running Ambari Agent...
Checking ambari-common dir...
Starting ambari-agent
Killed
===
INFO 2018-01-23 07:03:36,654 DataCleaner.py:120 - Data cleanup started
INFO 2018-01-23 07:03:36,655 hostname.py:67 - agent:hostname_script
configuration not defined thus read hostname
'ctr-e137-1514896590304-32888-01-03.hwx.site' using socket.getfqdn().
ERROR 2018-01-23 07:03:36,656 main.py:244 - Ambari agent machine hostname
(ctr-e137-1514896590304-32888-01-03.hwx.site) does not match expected
ambari server hostname (ambari.host-2). Aborting registration. Please check
hostname, hostname -f and /etc/hosts file to confirm your hostname is setup
correctly
INFO 2018-01-23 07:03:36,657 ExitHelper.py:56 - Performing cleanup before
exiting...
===
{code}
Ambari build: 2.6.2.0-32.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMBARI-22580) Streaming Analytics Manager (SAM) not working with PostgreSQL
[
https://issues.apache.org/jira/browse/AMBARI-22580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326180#comment-16326180
]
Ruslan Fialkovsky edited comment on AMBARI-22580 at 1/23/18 6:26 AM:
-
Hi. I have similar problem. After upgrade Ambari to 2.6.0.0 and have installed
hdf-ambari-mpack-3.0.2.0-76
Of course i have configured jdbc-driver
{code:java}
ambari-server setup --jdbc-db=postgres
--jdbc-driver=/usr/lib/ambari-server/postgresql-42.0.0.jar{code}
But i can't restart or run self check from SAM
{code:java}
Traceback (most recent call last):
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/service_check.py",
line 84, in
ServiceCheck().execute()
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 367, in execute
method(env)
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/service_check.py",
line 33, in service_check
import params
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/params.py",
line 211, in
connector_curl_source = format("{jdk_location}/{jdbc_driver_jar}")
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
line 95, in format
return ConfigurationFormatter().format(format_string, args, **result)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
line 59, in format
result_protected = self.vformat(format_string, args, all_params)
File "/usr/lib64/python2.7/string.py", line 549, in vformat
result = self._vformat(format_string, args, kwargs, used_args, 2)
File "/usr/lib64/python2.7/string.py", line 571, in _vformat
obj, arg_used = self.get_field(field_name, args, kwargs)
File "/usr/lib64/python2.7/string.py", line 632, in get_field
obj = self.get_value(first, args, kwargs)
File "/usr/lib64/python2.7/string.py", line 591, in get_value
return kwargs[key]
File "/usr/lib/python2.6/site-packages/resource_management/core/utils.py",
line 63, in __getitem__
return self._convert_value(self._dict[name])
KeyError: 'jdbc_driver_jar'
stdout: /var/lib/ambari-agent/data/output-6292.txt
2018-01-15 12:07:52,054 - Stack Feature Version Info: Cluster Stack=2.6,
Command Stack=None, Command Version=2.6.3.0-235 -> 2.6.3.0-235
Command failed after 1 tries
{code}
was (Author: fialkovsky):
Hi. I have similar problem. After upgrade Ambari to 2.6.0.0 and have installed
hdf-ambari-mpack-3.0.2.0-76
Of course i have configured jdbc-driver
{code:java}
ambari-server setup --jdbc-db=postgres
--jdbc-driver=/usr/lib/ambari-server/postgresql-42.0.0.jar{code}
But i can't reboot or run self check from SAM
{code:java}
Traceback (most recent call last):
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/service_check.py",
line 84, in
ServiceCheck().execute()
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 367, in execute
method(env)
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/service_check.py",
line 33, in service_check
import params
File
"/var/lib/ambari-agent/cache/common-services/STREAMLINE/0.5.0/package/scripts/params.py",
line 211, in
connector_curl_source = format("{jdk_location}/{jdbc_driver_jar}")
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
line 95, in format
return ConfigurationFormatter().format(format_string, args, **result)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/functions/format.py",
line 59, in format
result_protected = self.vformat(format_string, args, all_params)
File "/usr/lib64/python2.7/string.py", line 549, in vformat
result = self._vformat(format_string, args, kwargs, used_args, 2)
File "/usr/lib64/python2.7/string.py", line 571, in _vformat
obj, arg_used = self.get_field(field_name, args, kwargs)
File "/usr/lib64/python2.7/string.py", line 632, in get_field
obj = self.get_value(first, args, kwargs)
File "/usr/lib64/python2.7/string.py", line 591, in get_value
return kwargs[key]
File "/usr/lib/python2.6/site-packages/resource_management/core/utils.py",
line 63, in __getitem__
return self._convert_value(self._dict[name])
KeyError: 'jdbc_driver_jar'
stdout: /var/lib/ambari-agent/data/output-6292.txt
2018-01-15 12:07:52,054 - Stack Feature Version Info: Cluster Stack=2.6,
Command Stack=None, Command Version=2.6.3.0-235 -> 2.6.3.0-235
Command failed after 1 tries
{code}
> Streaming Analytics Manager (SAM) not working with PostgreSQL
> -
>
> Key: AMBARI-22580
> URL: https://issues.apache.org/jira/browse/AM
[jira] [Created] (AMBARI-22827) db-purge-history operation fails with large DB size in postgres.
JaySenSharma created AMBARI-22827:
-
Summary: db-purge-history operation fails with large DB size in
postgres.
Key: AMBARI-22827
URL: https://issues.apache.org/jira/browse/AMBARI-22827
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: trunk, 2.5.2
Reporter: JaySenSharma
When the ambari DB size is too large (around 1+ GB) then the db-purge-history
may fail with the postgres error Tried to send an out-of-range integer as a
2-byte value
Following error trace is from Ambari 2.5.2 however the same might cause in
higher version as well.
{code}
Internal Exception: org.postgresql.util.PSQLException: An I/O error occurred
while sending to the backend.
Error Code: 0
Call: SELECT DISTINCT host_task_id FROM topology_logical_task WHERE
(physical_task_id IN
(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
.
..
?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?))
Query:
ReportQuery(name="TopologyLogicalTaskEntity.findHostTaskIdsByPhysicalTaskIds"
referenceClass=TopologyLogicalTaskEntity sql="SELECT DISTINCT host_task_id FROM
topology_logical_task WHERE (physical_task_id IN ?)")
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1620)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:676)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:560)
at
org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:2055)
at
org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
at
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
at
org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2740)
at
org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2677)
at
org.eclipse.persistence.queries.ReportQuery.executeDatabaseQuery(ReportQuery.java:852)
at
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:904)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1134)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:460)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1222)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2896)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1857)
at
org.eclipse.persistence.internal.sessions.AbstractSession.retryQuery(AbstractSession.java:1927)
at
org.eclipse.persistence.sessions.server.ClientSession.retryQuery(ClientSession.java:694)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.retryQuery(UnitOfWorkImpl.java:5536)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1893)
at
org.eclipse.persistence.internal.sessions.AbstractSession.retryQuery(AbstractSession.java:1927)
at
org.eclipse.persistence.sessions.server.ClientSession.retryQuery(ClientSession.java:694)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.retryQuery(UnitOfWorkImpl.java:5536)
at
org.eclipse.persistence.internal.sessions.AbstractSession.execut
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[ https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335122#comment-16335122 ] Lars Francke commented on AMBARI-20545: --- Thanks for working on this! What about TLS 1.0? Jonathan mentioned that TLS 1.1 is the lowest supported one. The PCI DSS Guidelines for example have deprecated TLS 1.0 as well [https://de.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss] Again: This is something that can be changed by the user if needed but I'd rather have secure defaults. > Remove the use of legacy SSL and TLS protocol versions > -- > > Key: AMBARI-20545 > URL: https://issues.apache.org/jira/browse/AMBARI-20545 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.4.2 >Reporter: Andy LoPresto >Assignee: Robert Levas >Priority: Major > Labels: security, ssl, tls > Fix For: trunk > > > I notice that the explicit enabling of various protocols still includes > SSLv2Hello and SSLv3, which are severely broken protocols with numerous known > vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and > TLSv1.1 have been [discouraged since February > 2014|https://community.qualys.com/thread/12421], when all modern browsers > supported TLSv1.2. Is there any reason Ambari still needs to enable support > for these legacy protocols, and are there any other mitigating controls put > in place to prevent downgrade, brute force, padding oracle, and weak > parameter attacks against these protocols? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22696) Whitelist execute latency from Storm Ambari metrics
[ https://issues.apache.org/jira/browse/AMBARI-22696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334985#comment-16334985 ] Hudson commented on AMBARI-22696: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8630 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8630/]) AMBARI-22696 Whitelist execute latency from Storm Ambari metrics (swagle: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=b275722355c7e67af918a18a8b90c684e5837af0]) * (edit) ambari-server/src/main/resources/common-services/STORM/1.0.1.3.0/configuration/storm-site.xml * (edit) ambari-server/src/main/resources/common-services/STORM/1.0.1.3.0/service_advisor.py * (edit) ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py * (edit) ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-site.xml * (edit) ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py > Whitelist execute latency from Storm Ambari metrics > --- > > Key: AMBARI-22696 > URL: https://issues.apache.org/jira/browse/AMBARI-22696 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk, 2.6.2 >Reporter: Arun Mahadevan >Assignee: Jungtaek Lim >Priority: Major > Attachments: AMBARI-22696-branch-2.6.patch, AMBARI-22696.patch > > > Whitelist execute latency from Storm Ambari metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22696) Whitelist execute latency from Storm Ambari metrics
[ https://issues.apache.org/jira/browse/AMBARI-22696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334975#comment-16334975 ] Hudson commented on AMBARI-22696: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.6 #580 (See [https://builds.apache.org/job/Ambari-branch-2.6/580/]) AMBARI-22696 Whitelist execute latency from Storm Ambari metrics (swagle: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=3730c03f5c0ae3a9ac510baf53a5c2666e16012e]) * (edit) ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py * (edit) ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py * (edit) ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-site.xml > Whitelist execute latency from Storm Ambari metrics > --- > > Key: AMBARI-22696 > URL: https://issues.apache.org/jira/browse/AMBARI-22696 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk, 2.6.2 >Reporter: Arun Mahadevan >Assignee: Jungtaek Lim >Priority: Major > Attachments: AMBARI-22696-branch-2.6.patch, AMBARI-22696.patch > > > Whitelist execute latency from Storm Ambari metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22696) Whitelist execute latency from Storm Ambari metrics
[ https://issues.apache.org/jira/browse/AMBARI-22696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334869#comment-16334869 ] Jungtaek Lim commented on AMBARI-22696: --- [~swagle] Sure! [https://github.com/apache/ambari/pull/169] for trunk [https://github.com/apache/ambari/pull/170] for branch-2.6 > Whitelist execute latency from Storm Ambari metrics > --- > > Key: AMBARI-22696 > URL: https://issues.apache.org/jira/browse/AMBARI-22696 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk, 2.6.2 >Reporter: Arun Mahadevan >Assignee: Jungtaek Lim >Priority: Major > Attachments: AMBARI-22696-branch-2.6.patch, AMBARI-22696.patch > > > Whitelist execute latency from Storm Ambari metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-22826) Mpack related changes to Add Hosts Page
Ishan Bhatt created AMBARI-22826: Summary: Mpack related changes to Add Hosts Page Key: AMBARI-22826 URL: https://issues.apache.org/jira/browse/AMBARI-22826 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 3.0.0 Reporter: Ishan Bhatt Assignee: Ishan Bhatt Fix For: 3.0.0 Changes to be made for the Add Hosts Page including changes to the manual registration of hosts, registration using ssh and table display for the pre-registered hosts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[ https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334723#comment-16334723 ] Robert Levas commented on AMBARI-20545: --- If we go this route, should be update the summary and description of this Jira or create a new one that is a subset of this? > Remove the use of legacy SSL and TLS protocol versions > -- > > Key: AMBARI-20545 > URL: https://issues.apache.org/jira/browse/AMBARI-20545 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.4.2 >Reporter: Andy LoPresto >Assignee: Robert Levas >Priority: Major > Labels: security, ssl, tls > Fix For: trunk > > > I notice that the explicit enabling of various protocols still includes > SSLv2Hello and SSLv3, which are severely broken protocols with numerous known > vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and > TLSv1.1 have been [discouraged since February > 2014|https://community.qualys.com/thread/12421], when all modern browsers > supported TLSv1.2. Is there any reason Ambari still needs to enable support > for these legacy protocols, and are there any other mitigating controls put > in place to prevent downgrade, brute force, padding oracle, and weak > parameter attacks against these protocols? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[
https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334649#comment-16334649
]
Robert Levas edited comment on AMBARI-20545 at 1/22/18 6:37 PM:
[~lars_francke], [~jonathan.hurley]...
So we should set the following by default in the ambari.properties file:
{code:java}
security.server.disabled.protocols=SSL|SSLv2|SSLv3
{code}
This should take care of the issue at hand. If we agree, I can test to make
sure this actually works (I am about -99.9-100% positive it should) and create
the patch.
UPDATE: I just tested it. After allowing SSL via the {{java.security}} file, I
was able to turn on and off the SSL* protocols via
{{security.server.disabled.protocols}} in the {{ambari.properties}}.
was (Author: rlevas):
[~lars_francke], [~jonathan.hurley]...
So we should set the following by default in the ambari.properties file:
{code:java}
security.server.disabled.protocols=SSL|SSLv2|SSLv3
{code}
This should take care of the issue at hand. If we agree, I can test to make
sure this actually works (I am about 99.9% positive it should) and create the
patch.
> Remove the use of legacy SSL and TLS protocol versions
> --
>
> Key: AMBARI-20545
> URL: https://issues.apache.org/jira/browse/AMBARI-20545
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server, security
>Affects Versions: 2.4.2
>Reporter: Andy LoPresto
>Assignee: Robert Levas
>Priority: Major
> Labels: security, ssl, tls
> Fix For: trunk
>
>
> I notice that the explicit enabling of various protocols still includes
> SSLv2Hello and SSLv3, which are severely broken protocols with numerous known
> vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and
> TLSv1.1 have been [discouraged since February
> 2014|https://community.qualys.com/thread/12421], when all modern browsers
> supported TLSv1.2. Is there any reason Ambari still needs to enable support
> for these legacy protocols, and are there any other mitigating controls put
> in place to prevent downgrade, brute force, padding oracle, and weak
> parameter attacks against these protocols? Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-22696) Whitelist execute latency from Storm Ambari metrics
[ https://issues.apache.org/jira/browse/AMBARI-22696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334693#comment-16334693 ] Siddharth Wagle commented on AMBARI-22696: -- [~kabhwan] Would you be able to submit a pull request for this? I can approve and merge them quickly since the patches are already reviewed. > Whitelist execute latency from Storm Ambari metrics > --- > > Key: AMBARI-22696 > URL: https://issues.apache.org/jira/browse/AMBARI-22696 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk, 2.6.2 >Reporter: Arun Mahadevan >Assignee: Jungtaek Lim >Priority: Major > Attachments: AMBARI-22696-branch-2.6.patch, AMBARI-22696.patch > > > Whitelist execute latency from Storm Ambari metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[
https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334649#comment-16334649
]
Robert Levas commented on AMBARI-20545:
---
[~lars_francke], [~jonathan.hurley]...
So we should set the following by default in the ambari.properties file:
{code:java}
security.server.disabled.protocols=SSL|SSLv2|SSLv3
{code}
This should take care of the issue at hand. If we agree, I can test to make
sure this actually works (I am about 99.9% positive it should) and create the
patch.
> Remove the use of legacy SSL and TLS protocol versions
> --
>
> Key: AMBARI-20545
> URL: https://issues.apache.org/jira/browse/AMBARI-20545
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server, security
>Affects Versions: 2.4.2
>Reporter: Andy LoPresto
>Assignee: Robert Levas
>Priority: Major
> Labels: security, ssl, tls
> Fix For: trunk
>
>
> I notice that the explicit enabling of various protocols still includes
> SSLv2Hello and SSLv3, which are severely broken protocols with numerous known
> vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and
> TLSv1.1 have been [discouraged since February
> 2014|https://community.qualys.com/thread/12421], when all modern browsers
> supported TLSv1.2. Is there any reason Ambari still needs to enable support
> for these legacy protocols, and are there any other mitigating controls put
> in place to prevent downgrade, brute force, padding oracle, and weak
> parameter attacks against these protocols? Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[ https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334639#comment-16334639 ] Lars Francke commented on AMBARI-20545: --- Sorry, yeah that was my assumption as well (without explicitly saying so): I think we should disable insecure things by default if at all possible. This would be one instance. People can just change the property if they want to enable older protocols again. > Remove the use of legacy SSL and TLS protocol versions > -- > > Key: AMBARI-20545 > URL: https://issues.apache.org/jira/browse/AMBARI-20545 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.4.2 >Reporter: Andy LoPresto >Assignee: Robert Levas >Priority: Major > Labels: security, ssl, tls > Fix For: trunk > > > I notice that the explicit enabling of various protocols still includes > SSLv2Hello and SSLv3, which are severely broken protocols with numerous known > vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and > TLSv1.1 have been [discouraged since February > 2014|https://community.qualys.com/thread/12421], when all modern browsers > supported TLSv1.2. Is there any reason Ambari still needs to enable support > for these legacy protocols, and are there any other mitigating controls put > in place to prevent downgrade, brute force, padding oracle, and weak > parameter attacks against these protocols? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-22753) Fix existing unit tests after STOMP protocol implementation
[ https://issues.apache.org/jira/browse/AMBARI-22753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myroslav Papirkovskyi resolved AMBARI-22753. Resolution: Fixed Pushed to branch-3.0-perf > Fix existing unit tests after STOMP protocol implementation > --- > > Key: AMBARI-22753 > URL: https://issues.apache.org/jira/browse/AMBARI-22753 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Myroslav Papirkovskyi >Assignee: Myroslav Papirkovskyi >Priority: Critical > Labels: pull-request-available > Fix For: 3.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Fix failing unit tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-22817) Update backend code to handle new versioning schema
[
https://issues.apache.org/jira/browse/AMBARI-22817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaly Brodetskyi updated AMBARI-22817:
---
Attachment: AMBARI-22817_part2.patch
> Update backend code to handle new versioning schema
> ---
>
> Key: AMBARI-22817
> URL: https://issues.apache.org/jira/browse/AMBARI-22817
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Attachments: AMBARI-22817.patch, AMBARI-22817_part2.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new module and mpack meta rpms will have be versioned as follows
> *Mpack Versioning*
> {code}
> ..-b
> ..-h-b
> {code}
> *Examples*
> {code}
> hdpcore 3.0.0-b123
> hdpcore 3.0.0-h7-b111
> edw 1.0.0-b234
> edw 1.0.0-h15-b7
> {code}
> *Module Versioning*
> {code}
> ...-b
> ...-h-b
> {code}
> *Examples*
> {code}
> hdfs 3.0.0.1-b123
> hdfs 3.0.1.0-h77-b11
> zookeeper 3.5.1.0-b111
> zookeeper 3.5.1.1-h21-b10
> {code}
> We need the BE code (java, python) to handle this versioning schema while
> comparing versions, formatting versions etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-22811) Rewrite tests for alert types on branch-3.0-perf
[ https://issues.apache.org/jira/browse/AMBARI-22811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-22811: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to branch-3.0-perf > Rewrite tests for alert types on branch-3.0-perf > > > Key: AMBARI-22811 > URL: https://issues.apache.org/jira/browse/AMBARI-22811 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk >Priority: Major > Fix For: 3.0.0 > > Attachments: AMBARI-22811.patch > > > Configuration synching as well as some other config aspects changes in alerts > in scope of branch-3.0-perf. The tests are currently failing. Have to reflect > the changes in UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[ https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334421#comment-16334421 ] Jonathan Hurley commented on AMBARI-20545: -- I am fine with disabling SSL by default, but I believe we still must keep the lesser-secure TLS protocols. > Remove the use of legacy SSL and TLS protocol versions > -- > > Key: AMBARI-20545 > URL: https://issues.apache.org/jira/browse/AMBARI-20545 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.4.2 >Reporter: Andy LoPresto >Assignee: Robert Levas >Priority: Major > Labels: security, ssl, tls > Fix For: trunk > > > I notice that the explicit enabling of various protocols still includes > SSLv2Hello and SSLv3, which are severely broken protocols with numerous known > vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and > TLSv1.1 have been [discouraged since February > 2014|https://community.qualys.com/thread/12421], when all modern browsers > supported TLSv1.2. Is there any reason Ambari still needs to enable support > for these legacy protocols, and are there any other mitigating controls put > in place to prevent downgrade, brute force, padding oracle, and weak > parameter attacks against these protocols? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[
https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334417#comment-16334417
]
Robert Levas commented on AMBARI-20545:
---
[~lars_francke], though time is an issue.. that is not _*the*_ issue here. It
seems like, according to [~jonathan.hurley], we should keep support for TLS but
remove SSL protocols. Do we still think that this is ok?
If, as a community, we think that permanently disabling the SSL* protocols is
ok, then I will see if can work on it. However, AMBARI-18910 allows for such
protocols to be disabled (or enabled) via Ambari's configuration (since Ambari
2.4.2). For example:
{code}
security.server.disabled.protocols=SSL|SSLv2|SSLv3
{code}
However, by default it appears that this is not set in the
\{{ambari.properties}} file.
> Remove the use of legacy SSL and TLS protocol versions
> --
>
> Key: AMBARI-20545
> URL: https://issues.apache.org/jira/browse/AMBARI-20545
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server, security
>Affects Versions: 2.4.2
>Reporter: Andy LoPresto
>Assignee: Robert Levas
>Priority: Major
> Labels: security, ssl, tls
> Fix For: trunk
>
>
> I notice that the explicit enabling of various protocols still includes
> SSLv2Hello and SSLv3, which are severely broken protocols with numerous known
> vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and
> TLSv1.1 have been [discouraged since February
> 2014|https://community.qualys.com/thread/12421], when all modern browsers
> supported TLSv1.2. Is there any reason Ambari still needs to enable support
> for these legacy protocols, and are there any other mitigating controls put
> in place to prevent downgrade, brute force, padding oracle, and weak
> parameter attacks against these protocols? Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-22773) Ambari repository version is set to 2.6.3.0-235 irrespective of HDP version installed on cluster
[ https://issues.apache.org/jira/browse/AMBARI-22773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334287#comment-16334287 ] Nate Cole commented on AMBARI-22773: You would have to check the View code. That is contributed separately from Ambari proper. > Ambari repository version is set to 2.6.3.0-235 irrespective of HDP version > installed on cluster > > > Key: AMBARI-22773 > URL: https://issues.apache.org/jira/browse/AMBARI-22773 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Sonia Garudi >Priority: Major > Attachments: screenshot1.JPG, screenshot2.JPG > > > I have installed HDP-2.6.2.0 on my cluster. In the admin view, the version > installed on the cluster is shown as 2.6.3.0-235.(Attached screenshot1.jpg) > The version is same irrespective of which version is actually installed on > the cluster at step1(installer flow). > However, while registering a new version through the admin view, the version > is set to appropriate value.(Attached screenshot2.jpg) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-22825) Log Search UI: add different options of field name display
Istvan Tobias created AMBARI-22825: -- Summary: Log Search UI: add different options of field name display Key: AMBARI-22825 URL: https://issues.apache.org/jira/browse/AMBARI-22825 Project: Ambari Issue Type: Task Components: ambari-logsearch Affects Versions: 3.0.0 Reporter: Istvan Tobias Assignee: Istvan Tobias Fix For: 3.0.0 Display more user friendly column/field names on the service and audit logs screen. Eg.: Instead of showing 'line_number' we should display 'Line Number'. Use fallback when it is not available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-22813) Add different options of component name display
[ https://issues.apache.org/jira/browse/AMBARI-22813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Tobias resolved AMBARI-22813. Resolution: Duplicate > Add different options of component name display > --- > > Key: AMBARI-22813 > URL: https://issues.apache.org/jira/browse/AMBARI-22813 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: 3.0.0 >Reporter: Istvan Tobias >Assignee: Istvan Tobias >Priority: Major > Fix For: 3.0.0 > > Original Estimate: 168h > Remaining Estimate: 168h > > The ams_collector should show up as “AMS: Metrics Collector”, and > hdfs_namenode should show up as “HDFS: NameNode” - the mapping should be > mutable, but we should show it everywhere, and we should have a long name > “Service: Component” and a short name “Component” > Example: > Log Feeder: hdfs_namenode > Long Name: HDFS: NameNode > Short Name: NameNode > Abbreviation: NN -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22773) Ambari repository version is set to 2.6.3.0-235 irrespective of HDP version installed on cluster
[ https://issues.apache.org/jira/browse/AMBARI-22773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334209#comment-16334209 ] Sonia Garudi commented on AMBARI-22773: --- [~ncole] is there any possible solution to fix this issue? > Ambari repository version is set to 2.6.3.0-235 irrespective of HDP version > installed on cluster > > > Key: AMBARI-22773 > URL: https://issues.apache.org/jira/browse/AMBARI-22773 > Project: Ambari > Issue Type: Bug >Affects Versions: trunk >Reporter: Sonia Garudi >Priority: Major > Attachments: screenshot1.JPG, screenshot2.JPG > > > I have installed HDP-2.6.2.0 on my cluster. In the admin view, the version > installed on the cluster is shown as 2.6.3.0-235.(Attached screenshot1.jpg) > The version is same irrespective of which version is actually installed on > the cluster at step1(installer flow). > However, while registering a new version through the admin view, the version > is set to appropriate value.(Attached screenshot2.jpg) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-22790) Hosts Tab Not showing any results when ambari is opened via know gateway
[ https://issues.apache.org/jira/browse/AMBARI-22790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JaySenSharma resolved AMBARI-22790. --- Resolution: Not A Problem Not able to reproduce with correct knox topology configuration. > Hosts Tab Not showing any results when ambari is opened via know gateway > > > Key: AMBARI-22790 > URL: https://issues.apache.org/jira/browse/AMBARI-22790 > Project: Ambari > Issue Type: Bug > Environment: Ambari server 2.6.2 , accessed with know gateway >Reporter: Akhil S Naik >Assignee: JaySenSharma >Priority: Major > Attachments: Screen Shot 2018-01-16 at 1.09.47 PM.png, > no_host_issue.png > > > As per KNOX-673 , Knox is supporting ambari ui , > but when login via knox gateway to ambari-ui ,the hosts tab is not showing > any results. > Please see attachment, (no_host_issue.png) > and the error from server is (Screen Shot 2018-01-16 at 1.09.47 PM.png) > > Root Cause : > ambari using custom header X-Http-Method-Override :GET in this particular API > . > Actually this API is supposed to be a called as* GET* method but ambari WEB > client is calling *this API in post Way* with this custom header due to which > ambari-server is not getting correct call from web client. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22790) Hosts Tab Not showing any results when ambari is opened via know gateway
[ https://issues.apache.org/jira/browse/AMBARI-22790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334166#comment-16334166 ] JaySenSharma commented on AMBARI-22790: --- Tested locally on my cluster, this is not an issue from Ambari side. Knox topology configuration needs to be checked. If the topology is incorrect then this issue can be observed. > Hosts Tab Not showing any results when ambari is opened via know gateway > > > Key: AMBARI-22790 > URL: https://issues.apache.org/jira/browse/AMBARI-22790 > Project: Ambari > Issue Type: Bug > Environment: Ambari server 2.6.2 , accessed with know gateway >Reporter: Akhil S Naik >Assignee: JaySenSharma >Priority: Major > Attachments: Screen Shot 2018-01-16 at 1.09.47 PM.png, > no_host_issue.png > > > As per KNOX-673 , Knox is supporting ambari ui , > but when login via knox gateway to ambari-ui ,the hosts tab is not showing > any results. > Please see attachment, (no_host_issue.png) > and the error from server is (Screen Shot 2018-01-16 at 1.09.47 PM.png) > > Root Cause : > ambari using custom header X-Http-Method-Override :GET in this particular API > . > Actually this API is supposed to be a called as* GET* method but ambari WEB > client is calling *this API in post Way* with this custom header due to which > ambari-server is not getting correct call from web client. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMBARI-22790) Hosts Tab Not showing any results when ambari is opened via know gateway
[ https://issues.apache.org/jira/browse/AMBARI-22790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JaySenSharma reassigned AMBARI-22790: - Assignee: JaySenSharma > Hosts Tab Not showing any results when ambari is opened via know gateway > > > Key: AMBARI-22790 > URL: https://issues.apache.org/jira/browse/AMBARI-22790 > Project: Ambari > Issue Type: Bug > Environment: Ambari server 2.6.2 , accessed with know gateway >Reporter: Akhil S Naik >Assignee: JaySenSharma >Priority: Major > Attachments: Screen Shot 2018-01-16 at 1.09.47 PM.png, > no_host_issue.png > > > As per KNOX-673 , Knox is supporting ambari ui , > but when login via knox gateway to ambari-ui ,the hosts tab is not showing > any results. > Please see attachment, (no_host_issue.png) > and the error from server is (Screen Shot 2018-01-16 at 1.09.47 PM.png) > > Root Cause : > ambari using custom header X-Http-Method-Override :GET in this particular API > . > Actually this API is supposed to be a called as* GET* method but ambari WEB > client is calling *this API in post Way* with this custom header due to which > ambari-server is not getting correct call from web client. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-20545) Remove the use of legacy SSL and TLS protocol versions
[ https://issues.apache.org/jira/browse/AMBARI-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334102#comment-16334102 ] Lars Francke commented on AMBARI-20545: --- [~rlevas] What's the status here? Will you have time to work on it? If not I could put it on my list and try to get a patch done. > Remove the use of legacy SSL and TLS protocol versions > -- > > Key: AMBARI-20545 > URL: https://issues.apache.org/jira/browse/AMBARI-20545 > Project: Ambari > Issue Type: Bug > Components: ambari-server, security >Affects Versions: 2.4.2 >Reporter: Andy LoPresto >Assignee: Robert Levas >Priority: Major > Labels: security, ssl, tls > Fix For: trunk > > > I notice that the explicit enabling of various protocols still includes > SSLv2Hello and SSLv3, which are severely broken protocols with numerous known > vulnerabilities and not necessary for legacy compatibility. Even TLSv1 and > TLSv1.1 have been [discouraged since February > 2014|https://community.qualys.com/thread/12421], when all modern browsers > supported TLSv1.2. Is there any reason Ambari still needs to enable support > for these legacy protocols, and are there any other mitigating controls put > in place to prevent downgrade, brute force, padding oracle, and weak > parameter attacks against these protocols? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-22824) Yarn/MR2 should handle a customized Zookeeper service principal name
Sandor Molnar created AMBARI-22824:
--
Summary: Yarn/MR2 should handle a customized Zookeeper service
principal name
Key: AMBARI-22824
URL: https://issues.apache.org/jira/browse/AMBARI-22824
Project: Ambari
Issue Type: Improvement
Components: ambari-server
Affects Versions: 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 3.0.0
Yarn and MapReduce2 should handle a customized Zookeeper service principal name.
Currently this is not supported due to hardcoded and implicit values expecting
the Zookeeper service principal name to be {{zookeeper/_HOST}} as opposed to
something like {{zookeeper-mycluster/_HOST}}.
The following changes need to be made:
* common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py must be
changed to not hardcode the Zookeeper principal name in
{code:java}
m_security_opts = format('-Dzookeeper.sasl.client=true
-Dzookeeper.sasl.client.username=zookeeper
-Djava.security.auth.login.config={yarn_jaas_file}
-Dzookeeper.sasl.clientconfig=Client')
{code}
* {{-Dzookeeper.sasl.client.username=}} should be
added to {{YARN_OPTS}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (AMBARI-21546) Centralize LDAP Configuration for all services
[
https://issues.apache.org/jira/browse/AMBARI-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar reassigned AMBARI-21546:
--
Assignee: Robert Levas (was: Sandor Molnar)
> Centralize LDAP Configuration for all services
> --
>
> Key: AMBARI-21546
> URL: https://issues.apache.org/jira/browse/AMBARI-21546
> Project: Ambari
> Issue Type: Epic
>Reporter: Balázs Bence Sári
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 3.0.0
>
>
> LDAP configuration is time consuming, and follows a different pattern for
> each of the components below:
> * Ambari
> * Ranger
> * Knox
> * Atlas
> * Hive
> * Zeppelin
> In each case the same information is required, but duplicated across multiple
> components. Information required is:
> * LDAP Host
> * LDAP Port (389|636|*)
> * LDAP Security (LDAP, LDAPS)
> * LDAP anonymous bind support (default to false)
> * LDAP Bind DN (dn: cn=hadoop,ou=services,ou=Users,dc=hortonworks,dc=local)
> * LDAP Bind Password ()
> * LDAP Referrals Handling (follow|ignore)
> * LDAP Search Scope (subtree|base|one)
> * LDAP Server Certificate/CA Certificate (path to cert so it can be trusted
> using appropriate means)
> * User Search Base (cn=Users,dc=hortonworks,dc=local)
> * User Object Class (user)
> * User RDN (cn)
> * Group Search Base (cn=Groups,dc=hortonworks,dc=local
> * Group Object Class (group)
> * Group RDN (cn)
> * Group Membership attribute (member)
> If we can collect all of that information in one go - we can use it to
> configure the components above appropriately. Allowing the user to follow a
> single approach to LDAP enabling the stack. Additionally, this process
> should be optimized for Active Directory as that is in play in 90% of our
> installations.
> --
> How we make this information available to other services is important. In
> some situations a user may need to override the centralized configuration, so
> if we use variables that teams can use by default, but customers can override
> if necessary, that will be best. For example:
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase={{ ldap_group_searchbase }}
> There could be situations where they need to have a separate group searchable
> for Atlas so the user would just customize that property
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase=OU=GROUPS,dc=hortonworks,dc=local
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-21546) Centralize LDAP Configuration for all services
[
https://issues.apache.org/jira/browse/AMBARI-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334055#comment-16334055
]
Sandor Molnar commented on AMBARI-21546:
[~rlevas]
This one is for you.
> Centralize LDAP Configuration for all services
> --
>
> Key: AMBARI-21546
> URL: https://issues.apache.org/jira/browse/AMBARI-21546
> Project: Ambari
> Issue Type: Epic
>Reporter: Balázs Bence Sári
>Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 3.0.0
>
>
> LDAP configuration is time consuming, and follows a different pattern for
> each of the components below:
> * Ambari
> * Ranger
> * Knox
> * Atlas
> * Hive
> * Zeppelin
> In each case the same information is required, but duplicated across multiple
> components. Information required is:
> * LDAP Host
> * LDAP Port (389|636|*)
> * LDAP Security (LDAP, LDAPS)
> * LDAP anonymous bind support (default to false)
> * LDAP Bind DN (dn: cn=hadoop,ou=services,ou=Users,dc=hortonworks,dc=local)
> * LDAP Bind Password ()
> * LDAP Referrals Handling (follow|ignore)
> * LDAP Search Scope (subtree|base|one)
> * LDAP Server Certificate/CA Certificate (path to cert so it can be trusted
> using appropriate means)
> * User Search Base (cn=Users,dc=hortonworks,dc=local)
> * User Object Class (user)
> * User RDN (cn)
> * Group Search Base (cn=Groups,dc=hortonworks,dc=local
> * Group Object Class (group)
> * Group RDN (cn)
> * Group Membership attribute (member)
> If we can collect all of that information in one go - we can use it to
> configure the components above appropriately. Allowing the user to follow a
> single approach to LDAP enabling the stack. Additionally, this process
> should be optimized for Active Directory as that is in play in 90% of our
> installations.
> --
> How we make this information available to other services is important. In
> some situations a user may need to override the centralized configuration, so
> if we use variables that teams can use by default, but customers can override
> if necessary, that will be best. For example:
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase={{ ldap_group_searchbase }}
> There could be situations where they need to have a separate group searchable
> for Atlas so the user would just customize that property
> * atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
> * atlas.ldap.group.searchbase=OU=GROUPS,dc=hortonworks,dc=local
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-22698) Custom zeppelin interpreter properties are getting removed after moving zeppelin to a different host
[ https://issues.apache.org/jira/browse/AMBARI-22698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334032#comment-16334032 ] Hudson commented on AMBARI-22698: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8629 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8629/]) AMBARI-22698: Custom zeppelin interpreter properties are getting removed (prabhjyotsingh: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=e1ff339b8d76cf67c742f07ac1fa536929fcba33]) * (edit) ambari-server/src/main/resources/common-services/ZEPPELIN/0.7.0/package/scripts/master.py > Custom zeppelin interpreter properties are getting removed after moving > zeppelin to a different host > > > Key: AMBARI-22698 > URL: https://issues.apache.org/jira/browse/AMBARI-22698 > Project: Ambari > Issue Type: Bug > Components: ambari-sever >Affects Versions: 2.6.1 > Environment: ambari-server --version 2.6.1.0-136 > HDP-2.6.4.0-85 >Reporter: Supreeth Sharma >Assignee: Prabhjyot Singh >Priority: Blocker > Attachments: AMBARI-22698_trunk_v1.patch > > > Custom zeppelin interpreter properties are getting lost after moving zeppelin > to a different host > Live Cluster : https://172.27.12.130:8443 > Steps to reproduce : > 1) Modify interpreter settings > a) Add new custom properties > b) Modify existing properties > Changes are getting saved in HDFS path /user/zeppelin/conf/interpreter.json > and they are getting synced to local path /etc/zeppelin/conf/interpreter.json > after zeppelin restart. > 2) Delete zeppelin server > 3) Install zeppelin server on a different host > 4) Modifications done in step 1 are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22806) Unable to delete files from HDFS using Ambari File View when Ambari Views is accessed via Knox
[ https://issues.apache.org/jira/browse/AMBARI-22806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334031#comment-16334031 ] Hudson commented on AMBARI-22806: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8629 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8629/]) AMBARI-22806.Unable to delete files from HDFS using Ambari File View (venkatasairam.lanka: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=505dd217aecb1c761ebdb97b87cc82403e3dce20]) * (edit) contrib/views/commons/src/main/java/org/apache/ambari/view/commons/hdfs/FileOperationService.java * (edit) contrib/views/files/src/main/resources/ui/app/services/file-operation.js > Unable to delete files from HDFS using Ambari File View when Ambari Views is > accessed via Knox > -- > > Key: AMBARI-22806 > URL: https://issues.apache.org/jira/browse/AMBARI-22806 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 3.0.0, 2.5.0, 2.6.0 > Environment: Unable to delete files from HDFS using Ambari File View > when Ambari Views is accessed via Knox >Reporter: venkat >Assignee: venkat >Priority: Blocker > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22698) Custom zeppelin interpreter properties are getting removed after moving zeppelin to a different host
[ https://issues.apache.org/jira/browse/AMBARI-22698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334023#comment-16334023 ] Hudson commented on AMBARI-22698: - FAILURE: Integrated in Jenkins build Ambari-branch-2.6 #579 (See [https://builds.apache.org/job/Ambari-branch-2.6/579/]) AMBARI-22698: Custom zeppelin interpreter properties are getting removed (prabhjyotsingh: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=97f19051ea8deb911c1724b0214c779096232c2a]) * (edit) ambari-server/src/main/resources/common-services/ZEPPELIN/0.7.0/package/scripts/master.py > Custom zeppelin interpreter properties are getting removed after moving > zeppelin to a different host > > > Key: AMBARI-22698 > URL: https://issues.apache.org/jira/browse/AMBARI-22698 > Project: Ambari > Issue Type: Bug > Components: ambari-sever >Affects Versions: 2.6.1 > Environment: ambari-server --version 2.6.1.0-136 > HDP-2.6.4.0-85 >Reporter: Supreeth Sharma >Assignee: Prabhjyot Singh >Priority: Blocker > Attachments: AMBARI-22698_trunk_v1.patch > > > Custom zeppelin interpreter properties are getting lost after moving zeppelin > to a different host > Live Cluster : https://172.27.12.130:8443 > Steps to reproduce : > 1) Modify interpreter settings > a) Add new custom properties > b) Modify existing properties > Changes are getting saved in HDFS path /user/zeppelin/conf/interpreter.json > and they are getting synced to local path /etc/zeppelin/conf/interpreter.json > after zeppelin restart. > 2) Delete zeppelin server > 3) Install zeppelin server on a different host > 4) Modifications done in step 1 are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22716) zeppelin.livy.url is not getting updated after moving livy to a new host
[ https://issues.apache.org/jira/browse/AMBARI-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16333986#comment-16333986 ] Hudson commented on AMBARI-22716: - SUCCESS: Integrated in Jenkins build Ambari-branch-2.6 #578 (See [https://builds.apache.org/job/Ambari-branch-2.6/578/]) AMBARI-22716: zeppelin.livy.url is not getting updated after moving livy (prabhjyotsingh: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=f42a1eca0ab95d11bd5065b76323924d79a52aa0]) * (edit) ambari-server/src/main/resources/common-services/ZEPPELIN/0.7.0/package/scripts/master.py > zeppelin.livy.url is not getting updated after moving livy to a new host > > > Key: AMBARI-22716 > URL: https://issues.apache.org/jira/browse/AMBARI-22716 > Project: Ambari > Issue Type: Bug > Components: ambari-sever >Affects Versions: 2.6.1 > Environment: ambari-server --version 2.6.1.0-137 > HDP-2.6.4.0-86 >Reporter: Supreeth Sharma >Assignee: Prabhjyot Singh >Priority: Critical > Fix For: 2.6.1 > > Attachments: 0AMBARI-22716_branch-2.6_v1.patch, > 0AMBARI-22716_trunk_v1.patch > > > zeppelin.livy.url is not getting updated after moving livy to a new host > Steps to reproduce : > 1) Create a cluster with both Spark and Spark2 component > 2) Delete livy component from current host. > 3) Add the livy component on a new host > 4) Restart zeppelin server. > 5) Now check the zeppelin interpreter settings. zeppelin.livy.url is still > referring to older livy host. > Its not reflecting the new livy server address. > Note 1 : If I restart zeppelin server after step1 (ie after deleting the livy > host) before performing rest of the steps, then changes are getting reflected > properly. System test was mistakenly doing this step so didn't fail during > nightly run > Note 2 : Issue is happening only when both Spark and Spark2 are installed. If > cluster contains only Spark2, this feature works as expected. > Issue is coming if I add Spark(version 1) to it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-22716) zeppelin.livy.url is not getting updated after moving livy to a new host
[ https://issues.apache.org/jira/browse/AMBARI-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16333982#comment-16333982 ] Hudson commented on AMBARI-22716: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #8628 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8628/]) AMBARI-22716: zeppelin.livy.url is not getting updated after moving livy (prabhjyotsingh: [https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=c70de92823baa5504c80763148b91142b70105d9]) * (edit) ambari-server/src/test/python/stacks/2.6/ZEPPELIN/test_zeppelin_070.py * (edit) ambari-server/src/main/resources/common-services/ZEPPELIN/0.7.0/package/scripts/master.py > zeppelin.livy.url is not getting updated after moving livy to a new host > > > Key: AMBARI-22716 > URL: https://issues.apache.org/jira/browse/AMBARI-22716 > Project: Ambari > Issue Type: Bug > Components: ambari-sever >Affects Versions: 2.6.1 > Environment: ambari-server --version 2.6.1.0-137 > HDP-2.6.4.0-86 >Reporter: Supreeth Sharma >Assignee: Prabhjyot Singh >Priority: Critical > Fix For: 2.6.1 > > Attachments: 0AMBARI-22716_branch-2.6_v1.patch, > 0AMBARI-22716_trunk_v1.patch > > > zeppelin.livy.url is not getting updated after moving livy to a new host > Steps to reproduce : > 1) Create a cluster with both Spark and Spark2 component > 2) Delete livy component from current host. > 3) Add the livy component on a new host > 4) Restart zeppelin server. > 5) Now check the zeppelin interpreter settings. zeppelin.livy.url is still > referring to older livy host. > Its not reflecting the new livy server address. > Note 1 : If I restart zeppelin server after step1 (ie after deleting the livy > host) before performing rest of the steps, then changes are getting reflected > properly. System test was mistakenly doing this step so didn't fail during > nightly run > Note 2 : Issue is happening only when both Spark and Spark2 are installed. If > cluster contains only Spark2, this feature works as expected. > Issue is coming if I add Spark(version 1) to it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
