[JBoss JIRA] (WFLY-8445) Non file-based keystores used in ssl configuration don't allow to set key alias
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8445:
---------------------------------
Summary: Non file-based keystores used in ssl configuration don't allow to set key alias
Key: WFLY-8445
URL: https://issues.jboss.org/browse/WFLY-8445
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Reporter: Josef Cacek
Assignee: Brian Stansberry
Priority: Critical
Management model for SSL in security realms allows to configure alias to be used for the keystore. Neverhteless this configuration doesn't work for non-file-based keystores.
E.g.
{code:xml}
<ssl>
<keystore provider="custodia-cli"
alias="server-ssl" keystore-password="thepassword" />
</ssl>
{code}
The problem is probably in {{ProviderKeyManagerService}} class which has no evidence about the alias.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1494) Problems with parallel agenda
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1494?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1494:
-------------------------------------
The reason why AdvOperators3ExpertBenchmark and RetractFactsFromWmExpertBenchmark are falling back to the single threaded agenda is because, while it's true that there are multiple partitions, each OTN has only one single partition below it. I corrected this behaviour and allowed parallel evaluation with this pull request: https://github.com/kiegroup/drools/pull/1163 However I ran some preliminary benchmark and found that in those case the parallel engine is slower than the sequential one, so I'd keep the fallback and drop that pull request.
[~tzimanyi] please also give a run at my pull request and let me know if you'll also find same results. In case you believe that the parallel engine is faster also in that case (I don't think so) feel free to merge my pull request.
Regarding the other 2 benchmarks that show no gain when running in parallel I believe we have a quite similar situation. There each OTN only has only 2 partitions below it (e.g. for constraints firstName == null and firstName != null) and then it is not able to fully leverage the 8-core cpu.
> Problems with parallel agenda
> -----------------------------
>
> Key: DROOLS-1494
> URL: https://issues.jboss.org/browse/DROOLS-1494
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta7
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Labels: reported-by-qe
>
> From doc [1] there can be seen that four benchmarks show problems when run with parallel agenda enabled.
> Benchmarks _AdvOperators3ExpertBenchmark_ and _RetractFactsFromWmExpertBenchmark_
> falled back to single threaded agenda although they doesn't use features that aren't supported with parallel agenda (e.g. like salience).
> Benchmarks StartsStartedbyFusionBenchmark and UpdateFactsInWmExpertBenchmark shows no gain when using parallel agenda although they contain more partitions.
> I created runners for debugging here [2], so the benchmarks can be debugged outside of JMH. They are part of master branch in kie-benchmarks, so just pull of new changes is sufficient to get them.
> [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1hp5lLcmox_NFEUsqNSNZ...
> [2] https://github.com/kiegroup/kie-benchmarks/commit/887f758931b02d096f1e870...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2283:
----------------------------------------------
[~brian.stansberry]
something that is missing in a filtering only approach is the ability to easily (without having to go to help) answer the question: Do all the required attributes have been set?
If we complement the approach with a "Double Tab" of something like 500ms, we could expose all the remaining arguments annotated with relationships/attributes. ('*', <optional>, ...)
It seems that required, requires and alternatives would be doable with the filtering approach:
- Alternatives should be hidden as soon as a choice has been made.
- Partly typed argument name should be completed if it exists and all its dependencies are resolved, being required or not.
- Argument that depends on the presence of other arguments should be hidden until all the dependencies are present. That is in line with the way Commands are exposing options.
- Requires relationship overrides the required attribute. Any attribute is exposed as soon as all its dependencies (if any) are resolved.
In your example, let's imagine that:
D - not required, requires A and C.
E - required
As soon as A and C are present, D is exposed along E although D is not required.
Seems that users wouldn't have to think too much. They press Tab, and choose the argument they want to set. If lost, they press Tab twice and decode the exposed relationships. If that is not enough, they go to help.
Going to help requires to clear the current line and type help <my operation>, then type again the operation (generally Paste again the operation that would have been previously copied). This is very inefficient and requires too much context switching.
An inline help could be designed...more thinking needed there... Double tab, could be a first step toward it.
JF
> Make 'required' attributes clearer when using tab completion within CLI
> -----------------------------------------------------------------------
>
> Key: WFCORE-2283
> URL: https://issues.jboss.org/browse/WFCORE-2283
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> The following is some example output pressing tab to reveal the parameters of 'add': -
> {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
> ! alias-filter credential-reference path provider-name providers relative-to required type }}
> From this is it not clear which are actually required.
> Suggestions to make it clearer: -
> * Show required / optional in different colours.
> * Add something to the required attributes e.g. '*'
> * Add something to the optional requirements e.g. {optional_arg}
> Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
> Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugi... ]
Martin Simka reassigned WFCORE-2534:
------------------------------------
Assignee: (was: Brian Stansberry)
> SlaveReconnectTestCase fails with security manager in WF core
> -------------------------------------------------------------
>
> Key: WFCORE-2534
> URL: https://issues.jboss.org/browse/WFCORE-2534
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Jan Tymel
>
> *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments*
> *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays*
> {{cd testsuite/domain/}}
> {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}}
> {code}
> [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0]
> [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0]
> [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0]
> [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader")
> [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1]
> [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1]
> [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0]
> [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64)
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugi... ]
Martin Simka reassigned WFCORE-2534:
------------------------------------
Assignee: Brian Stansberry (was: Martin Simka)
> SlaveReconnectTestCase fails with security manager in WF core
> -------------------------------------------------------------
>
> Key: WFCORE-2534
> URL: https://issues.jboss.org/browse/WFCORE-2534
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
>
> *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments*
> *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays*
> {{cd testsuite/domain/}}
> {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}}
> {code}
> [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0]
> [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0]
> [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0]
> [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader")
> [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1]
> [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1]
> [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0]
> [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64)
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> [Server:server-affected] ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved WFCORE-644.
-------------------------------------
Resolution: Out of Date
The JBoss CLI now uses WildFly Elytron authentication client based configuration.
> 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.Beta11
>
>
> 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