March 2017 - jboss-jira - Jboss List Archives

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-887: ------------------------------ Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > "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.Beta10 > > > 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 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-644: ------------------------------ Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta10 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1944: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once migrated to Remoting 5

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1897: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Follow up WFCORE-296 once migrated to Remoting 5 > ------------------------------------------------ > > Key: WFCORE-1897 > URL: https://issues.jboss.org/browse/WFCORE-1897 > Project: WildFly Core > Issue Type: Task > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta10 > > > WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1960: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta10 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1649: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 3.0.0.Beta10 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1606: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > 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.Beta10 > > > 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 month

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1560: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > 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: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta10 > > 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 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2100: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2071) Properly handle unknown roles instead of throwing exception

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2071: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Properly handle unknown roles instead of throwing exception > ----------------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > When mapping roles directly from the identity: > {code} > <access-control provider="rbac" use-identity-roles="true"/> > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017