[JBoss JIRA] (WFCORE-3183) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3183?page=com.atlassian.jira.plugi... ]
Jan Kalina closed WFCORE-3183.
------------------------------
Resolution: Done
> Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
> --------------------------------------------------
>
> Key: WFCORE-3183
> URL: https://issues.jboss.org/browse/WFCORE-3183
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta31
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created.
> In server.log I see
> {code}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993
> 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output:
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> {code}
> In jboss-cli.log I see.
> {code}
> 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS]
> 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3183) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3183?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-3183:
------------------------------------
Closing, will be fixed in ELY-1336 instead.
> Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
> --------------------------------------------------
>
> Key: WFCORE-3183
> URL: https://issues.jboss.org/browse/WFCORE-3183
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta31
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created.
> In server.log I see
> {code}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993
> 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output:
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> {code}
> In jboss-cli.log I see.
> {code}
> 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS]
> 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2211) UUID not serializable
by Chris LastName (JIRA)
[ https://issues.jboss.org/browse/JGRP-2211?page=com.atlassian.jira.plugin.... ]
Chris LastName commented on JGRP-2211:
--------------------------------------
That worked. Thanks!
> UUID not serializable
> ---------------------
>
> Key: JGRP-2211
> URL: https://issues.jboss.org/browse/JGRP-2211
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.5
> Reporter: Chris LastName
> Assignee: Bela Ban
> Priority: Minor
>
> Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.jgroups.util.UUID
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:574)
> at org.jgroups.JChannel.up(JChannel.java:797)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:891)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.getStateFromApplication(STATE_TRANSFER.java:328)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateReq(STATE_TRANSFER.java:313)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:284)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:31)
> at org.jgroups.util.ProcessingQueue.process(ProcessingQueue.java:54)
> at org.jgroups.util.ProcessingQueue.add(ProcessingQueue.java:35)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:132)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:177)
> ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1336) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1336?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-12772 to ELY-1336:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1336 (was: JBEAP-12772)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Authentication Client
(was: Security)
Affects Version/s: 1.1.0.CR6
(was: 7.1.0.ER3)
> Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
> --------------------------------------------------
>
> Key: ELY-1336
> URL: https://issues.jboss.org/browse/ELY-1336
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.CR6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created.
> In server.log I see
> {code}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993
> 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output:
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> {code}
> In jboss-cli.log I see.
> {code}
> 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS]
> 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-1975) JGroups S3_PING should support sub-folders in S3.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1975?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1975.
--------------------------
Resolution: Out of Date
> JGroups S3_PING should support sub-folders in S3.
> -------------------------------------------------
>
> Key: JGRP-1975
> URL: https://issues.jboss.org/browse/JGRP-1975
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Dinesh Wijekoon
>
> As in the code (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> {code}
> if(prefix != null && !prefix.isEmpty()) {
> ListAllMyBucketsResponse bucket_list=conn.listAllMyBuckets(null);
> List buckets=bucket_list.entries;
> if(buckets != null) {
> boolean found=false;
> for(Object tmp: buckets) {
> if(tmp instanceof Bucket) {
> Bucket bucket=(Bucket)tmp;
> if(bucket.name.startsWith(prefix)) {
> location=bucket.name;
> found=true;
> }
> }
> }
> if(!found) {
> location=prefix + "-" + java.util.UUID.randomUUID().toString();
> }
> }
> }
> {code}
> This stop people by pointing s3_ping into a sub folder in s3, and it requires a root bucket. This will make life so much harder for a organisation which users multiple instances running for different clients.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3195) Deprecate the ModelControllerClientConfiguration's setAuthenticationConfigUri method
by James Perkins (JIRA)
James Perkins created WFCORE-3195:
-------------------------------------
Summary: Deprecate the ModelControllerClientConfiguration's setAuthenticationConfigUri method
Key: WFCORE-3195
URL: https://issues.jboss.org/browse/WFCORE-3195
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
Priority: Blocker
The {{ModelControllerClientConfiguration.setAuthenticationConfigUri()}} should be deprecated as we may want this removed in favor of a consumer of the client creating an {{org.wildfly.security.auth.client.AuthenticationContext}} and wrapping the context in a {{org.jboss.as.controller.client.helpers.ContextualModelControllerClient}}.
The ability to set a URI for a {{wildfly-config.xml}} was created to allow the {{wildfly-maven-plugin}} and {{wildfly-arquillian}} to authenticate with a server which has been configured with Elyron for management authentication. However these may be special use cases. It's currently unknown how other consumers of a {{ModelControllerClient}}, e.g. Hawkular, JBoss Tools, etc., would expect authentication to work.
Currently other clients, for example the EJB client, assume the user of the client creates an {{AuthenticationContext}}. This can either be done manually or by using auto-discovery.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3196) Deprecate the ModelControllerClientConfiguration's setAuthenticationConfigUri method
by James Perkins (JIRA)
James Perkins created WFCORE-3196:
-------------------------------------
Summary: Deprecate the ModelControllerClientConfiguration's setAuthenticationConfigUri method
Key: WFCORE-3196
URL: https://issues.jboss.org/browse/WFCORE-3196
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
Priority: Blocker
The {{ModelControllerClientConfiguration.setAuthenticationConfigUri()}} should be deprecated as we may want this removed in favor of a consumer of the client creating an {{org.wildfly.security.auth.client.AuthenticationContext}} and wrapping the context in a {{org.jboss.as.controller.client.helpers.ContextualModelControllerClient}}.
The ability to set a URI for a {{wildfly-config.xml}} was created to allow the {{wildfly-maven-plugin}} and {{wildfly-arquillian}} to authenticate with a server which has been configured with Elyron for management authentication. However these may be special use cases. It's currently unknown how other consumers of a {{ModelControllerClient}}, e.g. Hawkular, JBoss Tools, etc., would expect authentication to work.
Currently other clients, for example the EJB client, assume the user of the client creates an {{AuthenticationContext}}. This can either be done manually or by using auto-discovery.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2061) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2061?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2061:
---------------------------
Fix Version/s: 4.0.6
Seems this one slipped through the cracks, will take a look at it in the scope of 4.0.6
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2061
> URL: https://issues.jboss.org/browse/JGRP-2061
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Fix For: 4.0.6
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {{
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> }}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months