[JBoss JIRA] (WFWIP-96) MP Health - security enabled, no user yed added, user get info about adding user to access web console
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-96?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda updated WFWIP-96:
-----------------------------------
Priority: Critical (was: Minor)
Increasing priority after chatting about this with Jeff and checking return code ... which is 200 when the redirect is followed :(
{code}
[10:57 AM] Jeff Mesnil: ok, it's a 307 or a 302, so that's fine
[10:57 AM] Jeff Mesnil: ah no, with -L, it's a 200 OK :(
[10:59 AM] Rostislav Svoboda: maybe 500 ?
[10:59 AM] Jeff Mesnil: +1
[10:59 AM] Rostislav Svoboda: so it's not minor anymore
[11:00 AM] Rostislav Svoboda: will bump it
{code}
{code}
[10:56 AM] Rostislav Svoboda:
curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< Connection: keep-alive
< Location: /error
< Content-Length: 0
< Date: Fri, 10 Aug 2018 08:56:06 GMT
<
* Connection #0 to host 127.0.0.1 left intact
{code}
{code}
[10:56 AM] Rostislav Svoboda: with -L:
curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< Connection: keep-alive
< Location: /error
< Content-Length: 0
< Date: Fri, 10 Aug 2018 08:56:33 GMT
<
* Connection #0 to host 127.0.0.1 left intact
* Issue another request to this URL: 'http://127.0.0.1:9990/error'
* Found bundle for host 127.0.0.1: 0x7fb212719940 [can pipeline]
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /error HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< Location: /error/index.html
< Content-Length: 0
< Date: Fri, 10 Aug 2018 08:56:33 GMT
<
* Connection #0 to host 127.0.0.1 left intact
* Issue another request to this URL: 'http://127.0.0.1:9990/error/index.html'
* Found bundle for host 127.0.0.1: 0x7fb212719940 [can pipeline]
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /error/index.html HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Last-Modified: Fri, 10 Aug 2018 05:21:49 GMT
< X-Frame-Options: SAMEORIGIN
< Content-Length: 2318
< Content-Type: text/html
< Accept-Ranges: bytes
< Date: Fri, 10 Aug 2018 08:56:33 GMT
< html page bla blabla
{code}
> MP Health - security enabled, no user yed added, user get info about adding user to access web console
> ------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-96
> URL: https://issues.jboss.org/browse/WFWIP-96
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> I marked this as minor bug.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-18) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-18?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak edited comment on WFWIP-18 at 8/10/18 5:03 AM:
--------------------------------------------------------------
Marking as resolved as related ENMQMGR jira is done. See comment [1]
[1] https://issues.jboss.org/browse/ENTMQBR-1619?focusedCommentId=13604794&pa...
was (Author: mnovak):
Marking as resolved as related ENMQMGR jira is done.
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFWIP-18
> URL: https://issues.jboss.org/browse/WFWIP-18
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-18) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-18?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak resolved WFWIP-18.
---------------------------------
Resolution: Done
Marking as resolved as related ENMQMGR jira is done.
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFWIP-18
> URL: https://issues.jboss.org/browse/WFWIP-18
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-96) MP Health - security enabled, no user yed added, user get info about adding user to access web console
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-96?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda updated WFWIP-96:
-----------------------------------
Description:
I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
Note: I didn't add user via {{bin/add-user.sh}}
When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
{code}
<h3>Your WildFly Application Server is running.</h3>
<p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
to access the admin console.</p>
<p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
your WildFly installation and enter the requested information.</p>
{code}
Can /health endpoint get customized response in case no mgmt user is defined on server side ?
Current response can be little confusing if user is not yet so familiar with WildFly.
I marked this as minor bug.
was:
I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
Note: I didn't add user via {{bin/add-user.sh}}
When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
{code}
<h3>Your WildFly Application Server is running.</h3>
<p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
to access the admin console.</p>
<p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
your WildFly installation and enter the requested information.</p>
{code}
Can /health endpoint get customized response in case no mgmt user is defined on server side ?
Current response can be little confusing is user is not yet so familiar with WildFly.
I marked this as minor bug.
> MP Health - security enabled, no user yed added, user get info about adding user to access web console
> ------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-96
> URL: https://issues.jboss.org/browse/WFWIP-96
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Minor
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> I marked this as minor bug.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-99) /health endpoint still available after /subsystem=microprofile-health-smallrye:remove
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFWIP-99:
--------------------------------------
Summary: /health endpoint still available after /subsystem=microprofile-health-smallrye:remove
Key: WFWIP-99
URL: https://issues.jboss.org/browse/WFWIP-99
Project: WildFly WIP
Issue Type: Bug
Components: MP Health
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
Priority: Critical
/health endpoint still available after /subsystem=microprofile-health-smallrye:remove
{code}
[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:remove
{"outcome" => "success"}
{code}
I see 2 ways to go:
A) reload required should be reported
B) /health endpoint gets removed
CLI says
{code}
[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:check
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0216: Management resource '[(\"subsystem\" => \"microprofile-health-smallrye\")]' not found",
"rolled-back" => true
}
{code}
But curl is still happy:
{code}
curl -v http://127th.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 157
< Date: Fri, 10 Aug 2018 08:47:02 GMT
<
* Connection #0 to host 127.0.0.1 left intact
{"outcome":"UP","checks":[{"name":"AppHealth","state":"UP","data":{"application":"available"}},{"name":"CountHealthCheck","state":"UP","data":{"count":20}}]}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-17) [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-17?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak resolved WFWIP-17.
---------------------------------
Resolution: Done
Marking as resolved as based on information from [1][2] this issue is fixed.
[1] https://issues.jboss.org/browse/ENTMQBR-1181?focusedCommentId=13614362&pa...
[2] https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-... - passed
> [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-17
> URL: https://issues.jboss.org/browse/WFWIP-17
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: server1-trace.log, server1.log, server2-trace.log, server2.log
>
>
> Across all replicated HA tests I often see an issue that initial synchronization between Live and Backup was not triggered.
> *Scenario*
> # There are two Wildfly servers configured as replicated Live-Backup pair.
> # Live server is killed/shutdown
> *Expectation:* Backup server becomes active.
> *Reality:* Backup server does not become active, because initial synchronization with Live server was not triggered.
> *Users impact:* Replicated HA feature doesn't work properly.
> *Blocker* priority was set because this is regression against previous Wildfly releases.
> *Detail description of the issue*
> In the trace log there is last message from the {{SharedNothingBackupActivation}} which says that it is waiting on cluster connection. It is interested that JGroups subsystem is booting after this message was logged. However I am not sure if this could cause the issue.
> {code}
> 13:42:06,489 DEBUG [org.apache.activemq.artemis.core.client.impl.Topology] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Topology@6a834ff0[owner=ServerLocatorImpl [initialConnectors=[],
> discoveryGroupConfiguration=DiscoveryGroupConfiguration{name='dg-group1', refreshTimeout=10000, discoveryInitialWaitTimeout=10000}]] is sending topology to org.apache.activemq.artemis.core.server.impl.NamedLiveN
> odeLocatorForReplication@38150570
> 13:42:06,489 TRACE [org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Waiting on cluster connection
> 13:42:06,502 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel ejb
> 13:42:06,503 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
> 13:42:06,504 INFO [org.infinispan.CLUSTER] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,510 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb
> 13:42:06,510 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,516 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,529 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,551 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-7) ISPN000128: Infinispan version: Infinispan 'Gaina' 9.2.0.Final
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1634) LDAPS referrals broken
by Philippe Marschall (JIRA)
Philippe Marschall created ELY-1634:
---------------------------------------
Summary: LDAPS referrals broken
Key: ELY-1634
URL: https://issues.jboss.org/browse/ELY-1634
Project: WildFly Elytron
Issue Type: Bug
Reporter: Philippe Marschall
Assignee: Darran Lofthouse
We are having trouble getting LDAPS referrals working with an Elytron LDAP realm. The issue is the following stack trace.
{code}
javax.security.sasl.SaslException: ELY05012: Authentication mechanism server-side authentication failed [Caused by org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]]
at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:121)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]
at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:104)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:609)
at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.verifyEvidence(AggregateSecurityRealm.java:155)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:117)
... 12 more
Caused by: javax.naming.CommunicationException: ldap.acme.com:636 [Root exception is java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:226)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1615)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2699)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2673)
at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2669)
at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.reconnect(DelegatingLdapContext.java:181)
at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:97)
... 22 more
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at com.sun.jndi.ldap.VersionHelper12.loadClass(VersionHelper12.java:72)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:281)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
... 30 more
{code}
As you can see the Sun/Oracle LDAP classes try to load the class {{org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory}} using the TCCL which is the {{org.wildfly.extension.io}} module loader. This will not work as ThreadLocalSSLSocketFactor is in the module {{org.wildfy.security.elytron-private}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-96) MP Health - security enabled, no user yed added, user get info about adding user to access web console
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFWIP-96?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFWIP-96:
---------------------------------------
For management requests we actually send that error as a management response, I wonder if for health something similar can be implemented.
> MP Health - security enabled, no user yed added, user get info about adding user to access web console
> ------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-96
> URL: https://issues.jboss.org/browse/WFWIP-96
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Minor
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing is user is not yet so familiar with WildFly.
> I marked this as minor bug.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months