[JBoss JIRA] (WFCORE-3408) Error on startup when multiple FIPS Credential Stores are configured
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3408?page=com.atlassian.jira.plugi... ]
Tomas Hofman commented on WFCORE-3408:
--------------------------------------
[~bmaxwell] OK, I created JBEAP-13736 targeting 7.1.1.
> Error on startup when multiple FIPS Credential Stores are configured
> --------------------------------------------------------------------
>
> Key: WFCORE-3408
> URL: https://issues.jboss.org/browse/WFCORE-3408
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 4.0.0.Alpha2
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Critical
>
> In case there is multiple external PKCS11 credential stores configured, intermittently it happens on startup exception occurs. Seems more CS are configured, it is bigger chance to hit error. If only one CS is configured error does not occur.
> We have automatic tests with 3 CS and so far we have not hit this issue. With 5 CS from reproducer it happens nearly with each restart. I hit this during discussing analysis of advanced keystore features [1] with Farah.
> Multiple CS can be expected by users, when they want to logically separate CS files for some reason. However technically everything can be stored in one CS.
> That is analogy of https://issues.jboss.org/browse/JBEAP-11693 for PKCS11 credential store. Fix for that issue was proper synchronization of PKCS11 keystore loading. I assume something similar will be needed here.
> If there is missing synchronization of PKCS11 keystore in Credential store implementation, that can in theory occur in combination of 1 CS and multiple PKCS11 keystores as well. However this scenario is tested for and such problem haven't occurred yet.
> [~bmaxwell] Is GSS is ok with this being critical since a workaround exists?
> External Credential Store is new feature of Elytron tracked by EAP7-277.
> {code:title=KeyStoreException: invalid KeyStore state: found N secret keys sharing CKA_LABEL [my-key]}
> 09:56:15,574 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "MyStore")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.MyStore" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: java.security.KeyStoreException: expected but could not find secret key
> Caused by: java.security.KeyStoreException: expected but could not find secret key"}}
> 09:56:15,575 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "MyStore4")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.MyStore4" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: java.security.KeyStoreException: invalid KeyStore state: found 2 secret keys sharing CKA_LABEL [my-key]
> Caused by: java.security.KeyStoreException: invalid KeyStore state: found 2 secret keys sharing CKA_LABEL [my-key]"}}
> 09:56:15,576 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "MyStore5")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.MyStore5" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: java.security.KeyStoreException: invalid KeyStore state: found 3 secret keys sharing CKA_LABEL [my-key]
> Caused by: java.security.KeyStoreException: invalid KeyStore state: found 3 secret keys sharing CKA_LABEL [my-key]"}}
> {code}
> [1] https://developer.jboss.org/wiki/AnalysisDesign-AdvancedElytronKey-storeM...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on WFLY-9488:
---------------------------------------
[~mkouba] Wicket-CDI injects all classes managed by Wicket. These are Wicket components, not CDI beans. You can find the code that performs the injection here: https://github.com/apache/wicket/blob/master/wicket-cdi-1.1/src/main/java... . We've reproduced this issue with Wicket classes deployed in a war inside an ear. The faulty ResourceLoader tries to lookup the class in the classloader of the ear, where it should have been searching inside the war.
With regard to this report, it seems clear that the code in {{org.jboss.as/weld.deployment.WeldDeployment}} is wrong. The constructor of {{BeanDeploymentArchiveImpl}} explicitly registers a {{ResourceLoader}} at [line 81|https://github.com/weld/as7-weld-subsystem/blob/master/subsystem/src/m...] which is overridden directly thereafter by WeldDeployment at [line 183|https://github.com/weld/as7-weld-subsystem/blob/master/subsystem/src/...] by the {{ResourceLoader}} setup at [line 103|https://github.com/weld/as7-weld-subsystem/blob/master/subsystem/src/...].
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3406) find-non-progressing-operation doesn't return the blocking operation
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3406?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-3406:
-----------------------------------
Another example https://github.com/soul2zimate/quickstart/tree/WFCORE-3406/helloworld proves {{find-non-progressing-operation}} *works* as expected. It adds 50 seconds sleep in servlet destroy to simulate blocked undeploy operation.
Steps to reproduce:
1. Start WildFly in Standalone.
2. From CLI, deploy attached helloworld.war:
{code}
[standalone@localhost:9990 /] deploy ~/path/to/helloworld.war
{code}
Or use wildfly-maven-plugin in helloworld source folder.
{code}
mvn clean install wildfly:deploy
{code}
3. Visit http://localhost:8080/helloworld/HelloWorld to activate servlet.
4. From CLI, undeploy attached helloworld.war:
{code}
[standalone@localhost:9990 /] undeploy helloworld.war
{code}
Or use wildfly-maven-plugin
{code}
mvn clean install wildfly:undeploy
{code}
On server side, there is sleep message from destroy():
{code}
15:06:37,792 INFO [stdout] (ServerService Thread Pool -- 70) calling destroy method to wait
{code}
5. Open a new CLI terminal to test operations after 15 seconds (default stability timeout):
{code}
[standalone@localhost:9990 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-1125201532"
}
{code}
result shows find-non-progressing-operation returns the blocked operation with id.
{code}
[standalone@localhost:9990 /] /core-service=management/service=management-operations:cancel-non-progressing-operation
{
"outcome" => "success",
"result" => "-1125201532"
}
{code}
result shows cancel-non-progressing-operation tries to cancel the same operation.
Due to the cancellation, there is error message on server side:
{code}
15:07:27,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0008: Undeploy of deployment "helloworld.war" was rolled back with no failure message
15:07:27,810 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0027: Operation was interrupted before service container stability could be reached. Process should be restarted. Step that first updated the service container was 'undeploy' at address '[("deployment" => "helloworld.war")]'
{code}
At CLI terminal where it executes the undeploy command returns {code}Undeploy failed: WFLYCTL0271: Operation cancelled{code}
At last, the servlet page is still available to visit.
The previous observed problem comes from customized BlockerExtension. {{find-non-progressing-operation}} needs to compare {{exclusive-running-time}} in [ActiveOperationResource.getModel() L2604 - L2607 |https://github.com/wildfly/wildfly-core/blob/4.0.0.Alpha2/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L2604]
In case of {{ProcessType.STANDALONE_SERVER}}, it doesn't explicitly call [context.readResourceForUpdate|https://github.com/wildfly/wildfly-core/blo...] which takes exclusive lock to update {{exclusiveStartTime}} as domain mode. Therefore, {{exclusiveStartTime}} is always -1 as default. On the contrary, in the servlet example, it did compare with correct {{exclusiveStartTime}}.
> find-non-progressing-operation doesn't return the blocking operation
> --------------------------------------------------------------------
>
> Key: WFCORE-3406
> URL: https://issues.jboss.org/browse/WFCORE-3406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Chao Wang
> Attachments: helloworld.war
>
>
> The find-non-progressing-operation operation of /core-service=management/service=management-operations doesn't return the operation id of a blocking operation on standalone. It works on domain mode.
> To simulate the blocking operation, install the BlockingExtension from testsuite and call
> {code}
> /subsystem=blocker-test:block(block-point=MODEL,block-time=50000}
> {code}
> Open another jboss-cli.sh and call
> {code}
> /core-service=management/service=management-operations:find-non-progressing-operation
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3406) find-non-progressing-operation doesn't return the blocking operation
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3406?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFCORE-3406:
------------------------------
Attachment: helloworld.war
> find-non-progressing-operation doesn't return the blocking operation
> --------------------------------------------------------------------
>
> Key: WFCORE-3406
> URL: https://issues.jboss.org/browse/WFCORE-3406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Chao Wang
> Attachments: helloworld.war
>
>
> The find-non-progressing-operation operation of /core-service=management/service=management-operations doesn't return the operation id of a blocking operation on standalone. It works on domain mode.
> To simulate the blocking operation, install the BlockingExtension from testsuite and call
> {code}
> /subsystem=blocker-test:block(block-point=MODEL,block-time=50000}
> {code}
> Open another jboss-cli.sh and call
> {code}
> /core-service=management/service=management-operations:find-non-progressing-operation
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-9488:
------------------------------------
[~klaasjanb] Hm, it seems only _additional_ bean deployment archives are affected, i.e. the bean class does not come from any bean archive and was probably added by an extension. It would be great if you could provide some more info about the packaging and deployment structure, e.g. where does the problematic {{AnnotatedType}} come from?
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months