[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, 9 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, 9 months
[JBoss JIRA] (SECURITY-946) AdvancedLdapLoginModule with rolesCtxDN="" can lead to authentication failure
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-946?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-946.
---------------------------------------
Resolution: Done
> AdvancedLdapLoginModule with rolesCtxDN="" can lead to authentication failure
> -----------------------------------------------------------------------------
>
> Key: SECURITY-946
> URL: https://issues.jboss.org/browse/SECURITY-946
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Tomas Hofman
> Fix For: Negotiation_3_0_3_CR1
>
>
> In case when AdvancedLdapLoginModule is correctly configured for authentication and its attribute rolesCtxDN="", then authentication can fail. This happens when any role is found in LDAP by role search. It is caused by {{canonicalize}} method which returns string which ends with comma for empty rolesCtxDN which is invalid name for searching LDAP.
> In correct behavior authentication should pass and found roles should be assigned to user.
> In case when no role is found, then authentication succeed which is correct behavior.
> Thrown exception:
> {code}
> javax.naming.InvalidNameException: cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org,: [LDAP: error code 34 - Invalid root Dn given : cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org, (0x63 0x6E 0x3D 0x45 0x63 0x68 0x6F 0x2C 0x6F 0x75 0x3D 0x52 0x6F 0x6C 0x65 0x73 0x32 0x2C 0x6F 0x3D 0x41 0x64 0x76 0x61 0x6E 0x63 0x65 0x64 0x4C 0x64 0x61 0x70 0x4C 0x4D 0x45 0x6D 0x70 0x74 0x79 0x52 0x6F 0x6C 0x65 0x73 0x43 0x74 0x78 0x44 0x6E 0x4F 0x70 0x74 0x69 0x6F 0x6E 0x54 0x65 0x73 0x74 0x43 0x61 0x73 0x65 0x65 0x37 0x62 0x36 0x62 0x32 0x39 0x64 0x2C 0x6F 0x3D 0x70 0x72 0x69 0x6D 0x61 0x72 0x79 0x2C 0x64 0x63 0x3D 0x6A 0x62 0x6F 0x73 0x73 0x2C 0x64 0x63 0x3D 0x6F 0x72 0x67 0x2C ) is invalid]; remaining name 'cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org,'
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3074)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
> javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
> javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.obtainRole(AdvancedLdapLoginModule.java:801)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.rolesSearch(AdvancedLdapLoginModule.java:737)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:403)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (SECURITY-944) AdvancedLdapLoginModule with rolesCtxDN=null leads to authentication failure
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-944?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-944.
---------------------------------------
Resolution: Done
> AdvancedLdapLoginModule with rolesCtxDN=null leads to authentication failure
> ----------------------------------------------------------------------------
>
> Key: SECURITY-944
> URL: https://issues.jboss.org/browse/SECURITY-944
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Tomas Hofman
> Fix For: Negotiation_3_0_3_CR1
>
>
> In case when AdvancedLdapLoginModule is correctly configured for authentication, but its attribute rolesCtxDN is not set (i.e. is null), then authentication with correct username and password fails. It is caused be internal NPE for searching roles.
> Expected behavior is that user should be authenticated but no roles should be assigned to them.
> Internal NPE:
> {code}
> java.lang.NullPointerException:
> at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
> at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
> at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at org.jboss.security.negotiation.AdvancedLdapLoginModule.rolesSearch(AdvancedLdapLoginModule.java:720)
> at org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:403)
> at org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:967)
> at org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:326)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (SECURITY-946) AdvancedLdapLoginModule with rolesCtxDN="" can lead to authentication failure
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-946?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-946:
--------------------------------------
Fix Version/s: Negotiation_3_0_3_CR1
> AdvancedLdapLoginModule with rolesCtxDN="" can lead to authentication failure
> -----------------------------------------------------------------------------
>
> Key: SECURITY-946
> URL: https://issues.jboss.org/browse/SECURITY-946
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Tomas Hofman
> Fix For: Negotiation_3_0_3_CR1
>
>
> In case when AdvancedLdapLoginModule is correctly configured for authentication and its attribute rolesCtxDN="", then authentication can fail. This happens when any role is found in LDAP by role search. It is caused by {{canonicalize}} method which returns string which ends with comma for empty rolesCtxDN which is invalid name for searching LDAP.
> In correct behavior authentication should pass and found roles should be assigned to user.
> In case when no role is found, then authentication succeed which is correct behavior.
> Thrown exception:
> {code}
> javax.naming.InvalidNameException: cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org,: [LDAP: error code 34 - Invalid root Dn given : cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org, (0x63 0x6E 0x3D 0x45 0x63 0x68 0x6F 0x2C 0x6F 0x75 0x3D 0x52 0x6F 0x6C 0x65 0x73 0x32 0x2C 0x6F 0x3D 0x41 0x64 0x76 0x61 0x6E 0x63 0x65 0x64 0x4C 0x64 0x61 0x70 0x4C 0x4D 0x45 0x6D 0x70 0x74 0x79 0x52 0x6F 0x6C 0x65 0x73 0x43 0x74 0x78 0x44 0x6E 0x4F 0x70 0x74 0x69 0x6F 0x6E 0x54 0x65 0x73 0x74 0x43 0x61 0x73 0x65 0x65 0x37 0x62 0x36 0x62 0x32 0x39 0x64 0x2C 0x6F 0x3D 0x70 0x72 0x69 0x6D 0x61 0x72 0x79 0x2C 0x64 0x63 0x3D 0x6A 0x62 0x6F 0x73 0x73 0x2C 0x64 0x63 0x3D 0x6F 0x72 0x67 0x2C ) is invalid]; remaining name 'cn=Echo,ou=Roles2,o=AdvancedLdapLMEmptyRolesCtxDnOptionTestCasee7b6b29d,o=primary,dc=jboss,dc=org,'
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3074)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
> javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
> javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.obtainRole(AdvancedLdapLoginModule.java:801)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.rolesSearch(AdvancedLdapLoginModule.java:737)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:403)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-615) Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/ELY-615?page=com.atlassian.jira.plugin.sy... ]
Tomaz Cerar commented on ELY-615:
---------------------------------
Better than using file.mkdirs() would be to use Files#createDirectories as it properly throws exceptions
> Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
> --------------------------------------------------------------------------
>
> Key: ELY-615
> URL: https://issues.jboss.org/browse/ELY-615
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There is method {{tempPath()}} in org.wildfly.security.auth.realm.FileSystemSecurityRealm.Identity which uses {{file.mkdirs()}} without checking its return value. It is bad practice to ignore return value of this method (since false means that file has not been created and it can result to any unexpected and confusing failure later).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6728) JDBC persistence-store for Artemis
by Daniel Fröhlich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6728?page=com.atlassian.jira.plugin.... ]
Daniel Fröhlich commented on WFLY-6728:
---------------------------------------
No, it is not the same thing as with EAP6. With EAP6, the use AMQ6 embedded, not via RA. So the AMQ broker is running inside the same jvm as EAP does. They do so because they want a very high likelihood that the PUT of a message does succeed. And if Sender and Broker a within the same JVM, that is the case. In the RAR approach with an external running Broker (maybe on the same host, but different jvm process), there is a chance that the broker might be offline (not yet started, killed by kernel oom killer, whatever). That approach follows good HA principles to reduce the number of components in your design. So again, a perfectly good architectural decision.
And again that makes it important that we support JDBC persistence not only in AMQ via RAR, but also embedded in EAP.
They have a standing rule in place to never ever go into production with "x.0.0" numbers ;-)
They will start the migration from EAP5/7 to EAP7 next year with go live target in 2018. So there should be enough time for us to implement and stabilize the functionality.
> JDBC persistence-store for Artemis
> ----------------------------------
>
> Key: WFLY-6728
> URL: https://issues.jboss.org/browse/WFLY-6728
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jochen Cordes
> Assignee: Jeff Mesnil
>
> Apache ActiveMQ had the capability to store messages into a database via JDBC. In Apache ActiveMQ Artemis this has gone.
> For a consistent backup data of various (co-located) systems participating in transactions should reside at the same datastore as otherwise this needs to be achieved through application software design (i.e. idempotent consumers etc.).
> As in Apache ActiveMQ Artemis a JDBC Persistence-Store is about to be introduced we should also offer this capability on WildFly / EAP.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-615) Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-615?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-615:
-----------------------------
Fix Version/s: 1.1.0.Beta8
> Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
> --------------------------------------------------------------------------
>
> Key: ELY-615
> URL: https://issues.jboss.org/browse/ELY-615
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There is method {{tempPath()}} in org.wildfly.security.auth.realm.FileSystemSecurityRealm.Identity which uses {{file.mkdirs()}} without checking its return value. It is bad practice to ignore return value of this method (since false means that file has not been created and it can result to any unexpected and confusing failure later).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months