[JBoss JIRA] (WFLY-11669) iiop-openjdk ignores cipher-suite-filter with openssl provider
by David Everly (Jira)
[ https://issues.jboss.org/browse/WFLY-11669?page=com.atlassian.jira.plugin... ]
David Everly updated WFLY-11669:
--------------------------------
Description:
When using the "openssl" provider, the cipher-suite-filter is respected by undertow, but ignored by iiop-openjdk (modified standalone-full.xml):
{noformat}
<server-ssl-contexts>
<server-ssl-context name="openssl-serversslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" key-manager="wildfly-keymanager" providers="openssl"/>
</server-ssl-contexts>
<client-ssl-contexts>
<client-ssl-context name="iiop-clientsslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" trust-manager="jvm-trustmanager"/>
</client-ssl-contexts>
</tls>
</subsystem>
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.1">
<orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
<initializers security="identity" transactions="spec"/>
<security support-ssl="true" server-ssl-context="openssl-serversslcontext" client-ssl-context="iiop-clientsslcontext" server-requires-ssl="true" client-requires-ssl="false"/>
<interop iona="true"/>
</subsystem>
{noformat}
See also:
* https://developer.jboss.org/message/987804#987804
* http://wildfly.org/news/2017/10/06/OpenSSL-Support-In-Wildfly/
* https://github.com/mozilla/cipherscan.git
was:
When using the "openssl" provider, the cipher-suite-filter is respected by undertow, but ignored by iiop-openjdk (modified standalone-full.xml):
{noformat}
<server-ssl-contexts>
<server-ssl-context name="openssl-serversslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" key-manager="wildfly-keymanager" providers="openssl"/>
</server-ssl-contexts>
<client-ssl-contexts>
<client-ssl-context name="iiop-clientsslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" trust-manager="jvm-trustmanager"/>
</client-ssl-contexts>
</tls>
</subsystem>
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.1">
<orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
<initializers security="identity" transactions="spec"/>
<security support-ssl="true" server-ssl-context="openssl-serversslcontext" client-ssl-context="iiop-clientsslcontext" server-requires-ssl="true" client-requires-ssl="false"/>
<interop iona="true"/>
</subsystem>
{noformat}
See also:
* https://developer.jboss.org/message/987804#987804
* https://github.com/mozilla/cipherscan.git
> iiop-openjdk ignores cipher-suite-filter with openssl provider
> --------------------------------------------------------------
>
> Key: WFLY-11669
> URL: https://issues.jboss.org/browse/WFLY-11669
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 15.0.0.Final, 15.0.1.Final
> Reporter: David Everly
> Assignee: Tomasz Adamski
> Priority: Major
>
> When using the "openssl" provider, the cipher-suite-filter is respected by undertow, but ignored by iiop-openjdk (modified standalone-full.xml):
> {noformat}
> <server-ssl-contexts>
> <server-ssl-context name="openssl-serversslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" key-manager="wildfly-keymanager" providers="openssl"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="iiop-clientsslcontext" cipher-suite-filter="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256" protocols="TLSv1.2" trust-manager="jvm-trustmanager"/>
> </client-ssl-contexts>
> </tls>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.1">
> <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
> <initializers security="identity" transactions="spec"/>
> <security support-ssl="true" server-ssl-context="openssl-serversslcontext" client-ssl-context="iiop-clientsslcontext" server-requires-ssl="true" client-requires-ssl="false"/>
> <interop iona="true"/>
> </subsystem>
> {noformat}
> See also:
> * https://developer.jboss.org/message/987804#987804
> * http://wildfly.org/news/2017/10/06/OpenSSL-Support-In-Wildfly/
> * https://github.com/mozilla/cipherscan.git
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2293:
------------------------------------
[~belaban] yeah, the {{.0}} was a typo and I removed it. The command line is exactly the one I used.
Not sure about the non-loopback requirement, the test hard-codes the TCP bind address to {{127.0.0.1}}, but doesn't set any property on MPING, meaning it will use [default mcast address 230.5.6.7|https://github.com/belaban/JGroups/blob/de91ff4e222011d287016a7...] and bind to [system property {{jgroups.bind_addr}}=localhost|https://github.com/belaban/JGroups/blob/e103fabd73ff783a456036f3071ab9011ce87da4/build.properties.template#L6]
I've enabled trace logs and both the passing IDE run and the failing Maven run report the same addresses:
{noformat}
mvn: 14:41:47,971 DEBUG (main:[]) [MPING] bind_addr=/127.0.0.1, mcast_addr=/230.5.6.7, mcast_port=7555
ide: 14:39:50,826 DEBUG (main:[]) [MPING] bind_addr=/127.0.0.1, mcast_addr=/230.5.6.7, mcast_port=7555
{noformat}
Unfortunately there isn't anything else interesting in the logs. I did get one of the test methods to fail in the IDE, but I think the problem is in the test. You may want to get rid of the streams, it looks pretty tough to debug as is:
{noformat}
FAIL: [1] org.jgroups.tests.LeaveTest.testCoordLeave()
java.lang.AssertionError
at org.jgroups.tests.LeaveTest.testCoordLeave(LeaveTest.java:71)
{noformat}
> Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2293
> URL: https://issues.jboss.org/browse/JGRP-2293
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.17
>
> Attachments: IMG_20190123_124154.jpg
>
>
> JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle.
> A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on JGRP-2293 at 2/6/19 7:06 AM:
------------------------------------------------------------
[~belaban] I ran our test suite a few times without reproducing the failure. Then I got the idea to repeat the offending test 100 times, and I got it to fail both with JGroups 4.0.15.Final and with 4.0.17-SNAPSHOT. Finally I analyzed the logs and I think it is a problem with the test itself, so the fix is good for me.
I still haven't managed to run {{LeaveTest}} successfully from the command line though, the nodes never form a cluster because they don't see each other's MPING requests. If I run without {{<jvmarg value="-Djava.net.preferIPv4Stack=true"/>}} I get a sendto error (see below), but with it I get no error message, the nodes just don't see each other. I'd say it's a problem with my environment, but the same test using the same mcast address (230.5.6.7) passes when run from the IDE.
{noformat}
12:55:16,177 ERROR (main:[]) [MPING] JGRP000200: failed sending discovery request
java.io.IOException: Invalid argument (sendto failed)
at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_171]
at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_171]
at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:306) [classes/:?]
at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?]
at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?]
{noformat}
was (Author: dan.berindei):
[~belaban] I ran our test suite a few times without reproducing the failure. Then I got the idea to repeat the offending test 100 times, and I got it to fail both with JGroups 4.0.15.Final and with 4.0.17-SNAPSHOT. Finally I analyzed the logs and I think it is a problem with the test itself, so the fix is good for me.
I still haven't managed to run {{LeaveTest}} successfully from the command line though, the nodes never form a cluster because they don't see each other's MPING requests. If I run without {{<jvmarg value="-Djava.net.preferIPv4Stack=true"/>}} I get a sendto error (see below), but with it I get no error message, the nodes just don't see each other. I'd say it's a problem with my environment, but the same test using the same mcast address (230.0.5.6.7) passes when run from the IDE.
{noformat}
12:55:16,177 ERROR (main:[]) [MPING] JGRP000200: failed sending discovery request
java.io.IOException: Invalid argument (sendto failed)
at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_171]
at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_171]
at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:306) [classes/:?]
at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?]
at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?]
{noformat}
> Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2293
> URL: https://issues.jboss.org/browse/JGRP-2293
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.17
>
> Attachments: IMG_20190123_124154.jpg
>
>
> JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle.
> A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (SWSQE-504) Automate - Applications List Error Rate field
by Sunil kondkar (Jira)
[ https://issues.jboss.org/browse/SWSQE-504?page=com.atlassian.jira.plugin.... ]
Sunil kondkar closed SWSQE-504.
-------------------------------
Resolution: Done
Closing as the issue is not valid anymore:
Reference: https://issues.jboss.org/browse/KIALI-2074
> Automate - Applications List Error Rate field
> ---------------------------------------------
>
> Key: SWSQE-504
> URL: https://issues.jboss.org/browse/SWSQE-504
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Major
>
> The startign point here is :kiali_qe.tests.test_applications_page.test_all_applications test,
> which calls kiali_qe.tests.__init__.ApplicationsPageTest.assert_all_items method,
> which itself reads Applications from UI by calling "kiali_qe.components.__init__.ListViewApplications.items" and from REST by calling "kiali_qe.rest.kiali_api.KialiExtendedClient.application_list".
> Then compares UI and REST results. So if there is new field added in UI, we need to read that in UI, and in REST API, set it in the Object, then add this field in Object's is_equal method. This will work alongside to other fields we have.
> What is required to do:
> In "kiali_qe.entities.applications.Application" class add a new field "requests" with this type "kiali_qe.entities.__init__.Requests",
> In method "kiali_qe.components.__init__.ListViewApplications.items" here is TODO for that, add a new method and a call to it to read "Error Rate" field's value. Like it is done for "_get_item_health" method. Set it to field "requests" of "kiali_qe.entities.applications.Application"
> In "kiali_qe.rest.kiali_api.KialiExtendedClient.application_list" add new line to read and set field "requests" of "kiali_qe.entities.applications.Application"
> Modify "kiali_qe.entities.applications.Application.is_equal" and add comparison of "requests" field as well.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11676) Provide ability to list modules which are on deployment's classpath
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11676?page=com.atlassian.jira.plugin... ]
Yeray Borges moved WFCORE-4312 to WFLY-11676:
---------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-11676 (was: WFCORE-4312)
Component/s: Documentation
(was: Server)
> Provide ability to list modules which are on deployment's classpath
> -------------------------------------------------------------------
>
> Key: WFLY-11676
> URL: https://issues.jboss.org/browse/WFLY-11676
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> Provide ability to list modules which are on deployment's classpath.
> Expose that via mgmt run-time model, so it gets available in CLI.
> Current possibilities:
> Currently only debugging of application server can reveal this information and user must have good knowledge about management internals.
> Use cases:
> When optimizing footprint of an application user can use this list to identify unneeded implicit dependencies and exclude them.
> This feature can be used to identify duplicated dependencies delivered via deployed application.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFCORE-4312) Provide ability to list modules which are on deployment's classpath
by Yeray Borges (Jira)
Yeray Borges created WFCORE-4312:
------------------------------------
Summary: Provide ability to list modules which are on deployment's classpath
Key: WFCORE-4312
URL: https://issues.jboss.org/browse/WFCORE-4312
Project: WildFly Core
Issue Type: Feature Request
Components: Server
Reporter: Yeray Borges
Assignee: Yeray Borges
Provide ability to list modules which are on deployment's classpath.
Expose that via mgmt run-time model, so it gets available in CLI.
Current possibilities:
Currently only debugging of application server can reveal this information and user must have good knowledge about management internals.
Use cases:
When optimizing footprint of an application user can use this list to identify unneeded implicit dependencies and exclude them.
This feature can be used to identify duplicated dependencies delivered via deployed application.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2293:
------------------------------------
[~belaban] I ran our test suite a few times without reproducing the failure. Then I got the idea to repeat the offending test 100 times, and I got it to fail both with JGroups 4.0.15.Final and with 4.0.17-SNAPSHOT. Finally I analyzed the logs and I think it is a problem with the test itself, so the fix is good for me.
I still haven't managed to run {{LeaveTest}} successfully from the command line though, the nodes never form a cluster because they don't see each other's MPING requests. If I run without {{<jvmarg value="-Djava.net.preferIPv4Stack=true"/>}} I get a sendto error (see below), but with it I get no error message, the nodes just don't see each other. I'd say it's a problem with my environment, but the same test using the same mcast address (230.0.5.6.7) passes when run from the IDE.
{noformat}
12:55:16,177 ERROR (main:[]) [MPING] JGRP000200: failed sending discovery request
java.io.IOException: Invalid argument (sendto failed)
at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_171]
at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_171]
at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:306) [classes/:?]
at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?]
at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?]
{noformat}
> Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2293
> URL: https://issues.jboss.org/browse/JGRP-2293
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.17
>
> Attachments: IMG_20190123_124154.jpg
>
>
> JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle.
> A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months