[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher updated WFCORE-1673:
-----------------------------------------
Description:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
# <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting://
# <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
# no protocol specified in <default-controller> → use <default-protocol>
was:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
> Testsuite: tests for CLI controller aliases
> -------------------------------------------
>
> Key: WFCORE-1673
> URL: https://issues.jboss.org/browse/WFCORE-1673
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: Martin Schvarcbacher
> Assignee: Martin Schvarcbacher
> Priority: Minor
>
> Added integration tests for server aliases defined in jboss-cli.xml
> Usage in bin/jboss-cli.xml:
> {code:xml}
> <controllers>
> <controller name="ServerOne">
> <protocol>http-remoting</protocol>
> <host>localhost</host>
> <port>9990</port>
> </controller>
> </controllers>
> {code}
> {code:bash}
> ./bin/jboss-cli.sh --controller=ServerOne --connect
> {code}
> +*TEST PLAN*+
> # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
> # connect to controller alias with all options (protocol, hostname, port) specified
> # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
> # <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting://
> # <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
> # no protocol specified in <default-controller> → use <default-protocol>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2062:
--------------------------------
OK, so I added a check if the String contains only ASCII chars (< 128) and use TYPE_STRING if that's the case. If not, I use TYPE_UTF_STRING (newly added) and use write/readUTF() instead.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> 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....
> {code:java}
> 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();
> {code}
> 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
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6881) User with password which contains chinese chars isn't able to log in to AD (on Windows).
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-6881:
----------------------------------
Summary: User with password which contains chinese chars isn't able to log in to AD (on Windows).
Key: WFLY-6881
URL: https://issues.jboss.org/browse/WFLY-6881
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Minor
We have a problem log in to AD on Windows. When user has password with chinese chars he cannot log in.
My observations:
I found out this: If I create AD entries from linux and update testsuite for using this entries (not creating own) then it is ok.
I wasn't able to find out where is the exact problem. In my opinion there is some problem with creating AD user password on windows.
Workaround:
Creating AD data in other way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1671:
----------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1704
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1671
> URL: https://issues.jboss.org/browse/WFCORE-1671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Derek Horton
> Assignee: Lin Gao
>
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following:
> <security-realm name="ManagementRealm">
> <authentication>
> <jaas name="jmx-console"/>
> </authentication>
> <authorization map-groups-to-roles="false">
> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="RealmUsersRoles" flag="required">
> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> The following error is logged during the authentication attempt:
> 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
> at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
> at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ]
Lin Gao commented on WFCORE-1671:
---------------------------------
The result of above PR to full is green, so I opened the PR: https://github.com/wildfly/wildfly-core/pull/1704 for this to add the dependency back in core.
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1671
> URL: https://issues.jboss.org/browse/WFCORE-1671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Derek Horton
> Assignee: Lin Gao
>
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following:
> <security-realm name="ManagementRealm">
> <authentication>
> <jaas name="jmx-console"/>
> </authentication>
> <authorization map-groups-to-roles="false">
> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="RealmUsersRoles" flag="required">
> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> The following error is logged during the authentication attempt:
> 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
> at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
> at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1238) Domain Controller hung when deployment from CLI is interrupted.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1238?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1238.
--------------------------------------
Resolution: Out of Date
If this still occurs with WildFly 10 or later, please reopen with details or file a new JIRA. Thanks!
> Domain Controller hung when deployment from CLI is interrupted.
> ---------------------------------------------------------------
>
> Key: WFCORE-1238
> URL: https://issues.jboss.org/browse/WFCORE-1238
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: Wildfly version 8.2.0
> Reporter: Rahul Jain
> Assignee: Brian Stansberry
>
> We are running the widlfly in Domain mode with the following configuration:
> 1) Host A running the domain controller
> 2) Host B running Host controller with one app server
> 3) Host C running Host controller with one app server
> When we deloy war using jboss-cli and due to some unforscene issue the jboss-cli client dies before the deployment is completed. But after this the Domain Controller didn't respond to any communication either via cli or console. We need to restart the domain controller to get it working.
> -----------------------------------------------------------------------------------------------------
> LOGS from Wildfly server (DC)
> This node IS Domain Controller.
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/wildfly
> JAVA: /usr/java/default/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 18:33:57,144 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
> 18:33:57,298 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 18:33:57,917 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
> [Host Controller] 18:33:58,120 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final
> [Host Controller] 18:33:58,187 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: WildFly 8.2.0.Final "Tweek" starting
> [Host Controller] 18:33:58,975 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.0.Final
> [Host Controller] 18:33:59,003 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 18:33:59,015 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.0.Final
> [Host Controller] 18:33:59,123 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.6.Final
> [Host Controller] 18:33:59,162 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 192.168.1.203:9999
> [Host Controller] 18:34:01,237 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://192.168.1.203:9990/management
> [Host Controller] 18:34:01,237 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://192.168.1.203:9990
> [Host Controller] 18:34:01,238 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" (Host Controller) started in 3853ms - Started 44 of 46 services (13 services are lazy, passive or on-demand)
> [Host Controller] 18:34:09,845 INFO [org.jboss.as.domain] (Host Controller Service Threads - 25) JBAS010918: Registered remote slave host "192.168.1.200", WildFly 8.2.0.Final "Tweek"
> [Host Controller] 18:34:26,326 WARN [org.jboss.as.domain] (Remoting "cloudify-a2:MANAGEMENT" I/O-1) JBAS010929: Connection to remote host "192.168.1.200" closed unexpectedly
> [Host Controller] 18:34:26,328 INFO [org.jboss.as.domain] (Remoting "cloudify-a2:MANAGEMENT" I/O-1) JBAS010925: Unregistered remote slave host "192.168.1.200"
> [Host Controller] 18:34:55,859 INFO [org.jboss.as.domain] (Host Controller Service Threads - 26) JBAS010918: Registered remote slave host "192.168.1.200", WildFly 8.2.0.Final "Tweek"
> [Host Controller] 18:35:30,297 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /opt/wildfly/domain/data/content/cf/6a68fb1bc9d5f1a1a00228243ef94f23d5a370/content
> [Host Controller] 18:35:47,437 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /opt/wildfly/domain/data/content/43/8ab1e9f1b69ad7bce0628b3d771eadffa09703/content
> [Host Controller] 18:35:55,915 ERROR [org.jboss.as.domain.deployment] (management-handler-thread - 1) JBAS010809: ConcurrentUpdateTask caught InterruptedException waiting for task ConcurrentServerGroupUpdateTask{server-group=A}; returning
> [Host Controller] 18:35:55,924 WARN [org.jboss.as.host.controller] (management-handler-thread - 1) JBAS010802: Interrupted awaiting final response from server 192.168.1.200-0 on host 192.168.1.200
> [Host Controller] 18:35:55,942 WARN [org.jboss.as.domain] (Remoting "cloudify-a2:MANAGEMENT" task-2) JBAS010929: Connection to remote host "192.168.1.200" closed unexpectedly
> [Host Controller] 18:35:55,942 INFO [org.jboss.as.domain] (Remoting "cloudify-a2:MANAGEMENT" task-2) JBAS010925: Unregistered remote slave host "192.168.1.200"
> ----------------------------------------------------------------------------------------
> If you need anyother information, please let us know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-335) Convert deployment's content to a child resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-335?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-335.
-------------------------------------
Resolution: Won't Fix
The deployment resource requires content, and modeling that kind of thing with a child resource isn't something I want to do.
It's a LIST because of a long ago never pursued idea of doing something like deployment overlays and/or exploded managed deployments via allowing multiple pieces of content.
For EAP 8 we should change it to a non-list.
> Convert deployment's content to a child resource
> ------------------------------------------------
>
> Key: WFCORE-335
> URL: https://issues.jboss.org/browse/WFCORE-335
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
>
> At the moment this is a complex attribute.
> Not saying this MUST happen, just opening this to see what Brian & co think. I never really understood why it is a list either.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months