April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2715) principal and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2715?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-2715: --------------------------------- Description: To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. It is similar issue as WFCORE-2396. was: To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. It is similar issue as JBEAP-8979. > principal and authentication-context in Elytron dir-context should be mutually exclusive > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2715 > URL: https://issues.jboss.org/browse/WFCORE-2715 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. > It is similar issue as WFCORE-2396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plug... ] Hayk Hovsepyan commented on HAWKULARQE-1: ----------------------------------------- Domain mode immutability failed: https://bugzilla.redhat.com/show_bug.cgi?id=1439600 > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-1) [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-1?page=com.atlassian.jira.plug... ] Hayk Hovsepyan commented on HAWKULARQE-1: ----------------------------------------- General blocker issue on immutability https://bugzilla.redhat.com/show_bug.cgi?id=1443881 > [QE] - JMAN4-111 - Immutability of JBoss Middleware services running in containers > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-1 > URL: https://issues.jboss.org/browse/HAWKULARQE-1 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8630) Tests broken as part of WildFly Core 3.0.0.Beta16

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8630?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8630: ----------------------------------- Comment: was deleted (was: It's *possible* these can be corrected via a change in full tomorrow. Two of the 4 (SwitchIdentityTestCase) had edits in the ladybird PR, so maybe something needs tweaking. And the CLISecurityTestCase is checking the CLI can't authenticate, and it can't, which is good. But the output from the CLI is different than the assert. That may or may not be a meaningful issue. SlaveHostControllerElytronAuthenticationTestCase is failing in a test of using PLAIN auth. So of course we want that fixed but I don't know whether it's critical enough to delay the DR or cram in a new core release.) > Tests broken as part of WildFly Core 3.0.0.Beta16 > ------------------------------------------------- > > Key: WFLY-8630 > URL: https://issues.jboss.org/browse/WFLY-8630 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > > Tests shown here are going to be ignored or otherwise modified in order to get the core 3.0.0.Beta16 release integrated. > org.jboss.as.test.integration.domain.elytron.SlaveHostControllerElytronAuthenticationTestCase.testSlaveRegistration > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.security.perimeter.CLISecurityTestCase.testConnect > Failure examples: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=113878&buildTy... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1606: ------------------------------------- Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta17 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta17 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1560: ------------------------------------- Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh > -------------------------------------------------------------------------------- > > Key: WFCORE-1560 > URL: https://issues.jboss.org/browse/WFCORE-1560 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.8.Final > Environment: OS: CentOS 7.2 > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Wildfly-10.0.0-Final > Reporter: Michael Noack > Assignee: Ken Wills > Priority: Critical > Fix For: 3.0.0.Beta17 > > Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log > > > When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am): > [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)" > Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out > I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue. > Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta17 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta17 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2068: ------------------------------------- Fix Version/s: 3.0.0.Beta17 (was: 3.0.0.Beta16) > HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2068 > URL: https://issues.jboss.org/browse/WFCORE-2068 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta17 > > > The listed test case is failing during clean up with the following error: - > {noformat} > java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80) > {noformat} > The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017