[JBoss JIRA] (WFLY-7374) WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-7374:
--------------------------------------
Summary: WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
Key: WFLY-7374
URL: https://issues.jboss.org/browse/WFLY-7374
Project: WildFly
Issue Type: Bug
Components: Web (Undertow), Server, Security
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Priority: Blocker
When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6.7 there is only glibc 2.12.
As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
\[1\]
{noformat}
11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
11:20:42,476 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:20:42,479 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:20:42,481 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:20:42,494 ERROR [stderr] (MSC service thread 1-3) at java.lang.reflect.Method.invoke(Method.java:498)
11:20:42,495 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL.init(SSL.java:73)
11:20:42,496 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.forName0(Native Method)
11:20:42,498 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.forName(Class.java:348)
11:20:42,499 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
11:20:42,505 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
11:20:42,508 ERROR [stderr] (MSC service thread 1-3) at java.security.AccessController.doPrivileged(Native Method)
11:20:42,516 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
11:20:42,517 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
11:20:42,524 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
11:20:42,525 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
11:20:42,539 ERROR [stderr] (MSC service thread 1-3) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
11:20:42,540 ERROR [stderr] (MSC service thread 1-3) at java.lang.Class.newInstance(Class.java:442)
11:20:42,541 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
11:20:42,543 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
11:20:42,548 ERROR [stderr] (MSC service thread 1-3) at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
11:20:42,550 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
11:20:42,551 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
11:20:42,552 ERROR [stderr] (MSC service thread 1-3) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
11:20:42,553 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
11:20:42,557 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
11:20:42,572 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
11:20:42,581 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
11:20:42,582 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
11:20:42,590 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:20:42,591 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:20:42,593 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745)
11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
11:20:42,596 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader$NativeLibrary.load(Native Method)
11:20:42,597 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
11:20:42,598 ERROR [stderr] (MSC service thread 1-3) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
11:20:42,610 ERROR [stderr] (MSC service thread 1-3) at java.lang.Runtime.loadLibrary0(Runtime.java:870)
11:20:42,611 ERROR [stderr] (MSC service thread 1-3) at java.lang.System.loadLibrary(System.java:1122)
11:20:42,619 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
11:20:42,620 ERROR [stderr] (MSC service thread 1-3) ... 34 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1791:
------------------------------------------
Thanks, Yeray!
The bit I wasn't seeing is that ServerStartTask, which is only run once per server process and isn't re-run in a reload, passes the DomainServerCommunicationServices into the Bootstrap.bootstap method (via the List<ServiceActivator> param, which in turn passes it to ApplicationServerService. That means that when the reload triggers a new start() of ApplicationServerService, DomainServerCommunicationServices.activate gets run again and the new initialOperationId value is used.
I mistakenly thought DomainServerCommunicationServices.activate was only called once in the lifetime of a server process.
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7349) configurable-sasl-server-factory cannot set mechanism information
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7349:
----------------------------------
TODO: Just allow multiple using of SetMechanismInformationSSF.
> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
> Key: WFLY-7349
> URL: https://issues.jboss.org/browse/WFLY-7349
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-676) There isn't possible change value for given alias in Credential Store over CLI.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.sy... ]
Tomaz Cerar commented on ELY-676:
---------------------------------
does
{noformat}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
{noformat}
work?
> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
> Key: ELY-676
> URL: https://issues.jboss.org/browse/ELY-676
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.Beta10
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (DROOLS-1342) IndexOutOfBoundsException when using query with 2 entry points
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1342:
-----------------------------------
Summary: IndexOutOfBoundsException when using query with 2 entry points
Key: DROOLS-1342
URL: https://issues.jboss.org/browse/DROOLS-1342
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Fix For: 7.0.0.Beta3
Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code [2].
[1] http://pastebin.com/BBPsGty9
[2] http://pastebin.com/47y1dh1W
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7369) Elytron Properties realm parses password with "=" incorrectly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7369?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7369:
----------------------------------------
As this issue is within the core Elytron code base I think you can move this issue over into the ELY project directly and we don't need a WFLY issue.
> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
> Key: WFLY-7369
> URL: https://issues.jboss.org/browse/WFLY-7369
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-687) There isn't possible change value for given alias in Credential Store over CLI.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-687:
--------------------------------
Summary: There isn't possible change value for given alias in Credential Store over CLI.
Key: ELY-687
URL: https://issues.jboss.org/browse/ELY-687
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Affects Versions: 1.1.0.Beta10
Reporter: Hynek Švábek
Assignee: Peter Skopek
There isn't possible change value for given alias in Credential Store over CLI.
I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-686) Credential-reference(store=...) should be resolved in time of request.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-686:
--------------------------------
Summary: Credential-reference(store=...) should be resolved in time of request.
Key: ELY-686
URL: https://issues.jboss.org/browse/ELY-686
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Affects Versions: 1.1.0.Beta10
Reporter: Hynek Švábek
Assignee: Peter Skopek
Attachments: firefly.keystore
Credential-reference should be resolved in time of request.
When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("key-store" => "firefly")
]) - failure description: {
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months