[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-1680:
--------------------------------------
Summary: Tab completion for echo-dmr command is broken
Key: WFCORE-1680
URL: https://issues.jboss.org/browse/WFCORE-1680
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Petr Kremensky
Assignee: Alexey Loubyansky
Tab completion for echo-dmr command doesn't work.
To reproduce, start the standalone server and connect with CLI
*actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
{noformat}
[standalone@localhost:9990 /] echo-dmr /sub[TAB]
core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
[standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
{noformat}
*expected*
{noformat}
[standalone@localhost:9990 /] echo-dmr /sub[TAB]
[standalone@localhost:9990 /] echo-dmr /subsystem=
[standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
[standalone@localhost:9990 /] echo-dmr /subsystem=logging
{noformat}
The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (ELY-438) There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-438?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-438:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.CR1)
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK
> -------------------------------------------------------------------------------
>
> Key: ELY-438
> URL: https://issues.jboss.org/browse/ELY-438
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta8, 1.0.3.CR1
>
>
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
> Interchange TLS prefix to SSL and vice versa is not supported.
> Here is list of standard JSSE Cipher Suite Names
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
> In my opinion this file is mapping file for our purpose. It is?
> https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> For IBM JDK are different JSSE Cipher Suite Names (different prefix).
> Most items from this list are missing in MechanismDatabase.properties mentioned above.
> http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
> For example:
> JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
> It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
> If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
> {code}
> 16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (SECURITY-943) AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-943?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-943:
--------------------------------------
Fix Version/s: Negotiation_3_0_4_CR1
(was: Negotiation_3_0_3_Final)
> AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
> -------------------------------------------------------------------------------------
>
> Key: SECURITY-943
> URL: https://issues.jboss.org/browse/SECURITY-943
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: Negotiation_3_0_4_CR1
>
>
> In case when part of DN is placed in LDAP URL instead of baseCtxDN then authentication fails (see [1] for details about this URL) in AdvancedLdapLoginModule. Authentication is provided by binding with user DN and password, but in this case user DN does not include DN part from LDAP URL which leads to fail.
> Thrown exception:
> {code}
> javax.naming.AuthenticationException: LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=jduke,ou=People
> com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3135)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883)
> com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797)
> com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> javax.naming.InitialContext.init(InitialContext.java:244)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:486)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.authenticate(AdvancedLdapLoginModule.java:669)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:397)
> org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:967)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:326)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> {code}
> [1] https://tools.ietf.org/html/rfc2255
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Artur Kowalczyk (JIRA)
Artur Kowalczyk created WFLY-6895:
-------------------------------------
Summary: TimerService problem(duplicated resource)
Key: WFLY-6895
URL: https://issues.jboss.org/browse/WFLY-6895
Project: WildFly
Issue Type: Feature Request
Affects Versions: 10.0.0.Final
Environment: Two standalone instances connected into a cluster.
*Master WildFly*
{code}
standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
{code}
*Slave WildFly*
{code}
standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
{code}
Both instances has the same singleton policy defined in singleton-full-ha.xml:
{code}
<singleton-policy name="scada-singleton" cache-container="server">
<simple-election-policy>
<name-preferences>master</name-preferences>
</simple-election-policy>
</singleton-policy>
{code}
Reporter: Artur Kowalczyk
Assignee: Jason Greene
I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
*Test Case*
# Start master node, the app is also started - OK
# Start slave node, the app is deployed but bot stared - OK
# Stop master node, the app is started on slave - OK
# Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
# Stop master node, the app should be started again on slave but an exception occur. - ERROR
{code}
09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
... 6 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Artur Kowalczyk (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
Artur Kowalczyk commented on WFLY-6895:
---------------------------------------
The minimal application required to reproduce this problem is available on [github|https://github.com/arturkowalczyk/wildfly10-timerservice-problem].
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Feature Request
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Jason Greene
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (SECURITY-934) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-934?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-934:
--------------------------------------
Fix Version/s: Negotiation_3_0_3_CR1
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: SECURITY-934
> URL: https://issues.jboss.org/browse/SECURITY-934
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Hynek Švábek
> Assignee: Romain Pelisse
> Fix For: Negotiation_3_0_3_CR1
>
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> https://issues.jboss.org/browse/SECURITY-891
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months