[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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 months
[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-396:
----------------------------------
[~bstansberry] Great, thanks for the clarification. I'll add a note on that indicating that when I send up the PR.
> Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-396
> URL: https://issues.jboss.org/browse/WFCORE-396
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.)
> But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1459) Starting server that has port clash with existing running server returns 'Success', then fails
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1459?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1459:
------------------------------------------
We expose any startup failures via the management API.
WFCORE-307 will cause boot to fail for non-embedded servers if some form of remote management isn't able to come up.
I'd like some sort of config option that would cause the process to exit in the presence of any boot failure. There's a separate JIRA for that somewhere.
I'm not sure though that, assuming said config option isn't set and there is some non-fatal error in boot, we want to change the state from "started". Bears some discussion though.
> Starting server that has port clash with existing running server returns 'Success', then fails
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1459
> URL: https://issues.jboss.org/browse/WFCORE-1459
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> The reproducer is: given a vanilla wildfly, add server-test with port-offset=0. Use CLI to start, it reports result" => "STARTED", but the server fails with "BindException: Address already in use"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-380) Operations to read content from the content repository
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-380?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-380:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Ken Wills)
I'm reassigning this one as it relates to the exploded deployment work Emmanuel is doing[1], so it's better to keep those things associated with one person.
[1] See https://developer.jboss.org/docs/DOC-55497
> Operations to read content from the content repository
> ------------------------------------------------------
>
> Key: WFCORE-380
> URL: https://issues.jboss.org/browse/WFCORE-380
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays.
> Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-379) Give option to make the content repository browsable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-379?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-379:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Ken Wills)
I'm reassigning this one as it relates to the exploded deployment work Emmanuel is doing. See https://developer.jboss.org/docs/DOC-55497
The description somewhat implies some server setting that would cause all uploaded content to be stored exploded. I don't know if we'll do that. We won't in the initial work discussed in the above doc. The managed exploded content support we envision will let users upload archives though, and then explode them via a management operation.
> Give option to make the content repository browsable
> ----------------------------------------------------
>
> Key: WFCORE-379
> URL: https://issues.jboss.org/browse/WFCORE-379
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Schofield
> Assignee: ehsavoie Hugonnet
>
> JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory. When using the new API to install applications the contents of applications are not easily browsable or searchable.
> Would like to have a setting that enables all content to be stored in exploded format in the content repository.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1675) Embedded server started non-modular use only first --jboss-home for FS paths
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1675?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-1675:
------------------------------
Description:
First --jboss-home value passed is always used to FS paths resolution. The issue affects embed-server started using jboss-cli-client.jar.
*reproduce*
start embed server using wf1, stop it, start another embed server using wf2
{noformat}
/home/workspace3
├── wf1
│ └── wildfly-10.0
└── wf2
└── wildfly-10.0
$ pwd ; java -jar jboss-cli-client.jar
[disconnected /] embed-server --jboss-home=~/workspace3/wf1/wildfly-10.0
[standalone@embedded /] stop-embedded-server
[disconnected /] embed-server --jboss-home=~/workspace3/wf2/wildfly-10.0
{noformat}
*actual*
_wf1_ is used
{noformat}
...
"name" => "jboss.server.config.dir",
"path" => "/home/workspace3/wf1/wildfly-10.0/standalone/configuration",
...
{noformat}
was:
First --jboss-home value passed is always used to FS paths resolution. The issue affects embed-server started using jboss-cli-client.jar.
*reproduce*
start embed server using eap1, stop it, start another embed server using eap2
{noformat}
/home/pkremens/workspace3
├── eap1
│ └── jboss-eap-7.1
└── eap2
└── jboss-eap-7.1
[pkremens@dhcp-10-40-5-78 client]$ pwd ; java -jar jboss-cli-client.jar
/home/pkremens/workspace3/eap1/jboss-eap-7.1/bin/client
[disconnected /] embed-server --jboss-home=~/workspace3/eap1/jboss-eap-7.1
[standalone@embedded /] stop-embedded-server
[disconnected /] embed-server --jboss-home=~/workspace3/eap2/jboss-eap-7.1
{noformat}
*actual*
_eap1_ is used
{noformat}
...
"name" => "jboss.server.config.dir",
"path" => "/home/pkremens/workspace3/eap1/jboss-eap-7.1/standalone/configuration",
...
{noformat}
[Full output|http://pastebin.test.redhat.com/395395] - only jboss.home.dir reflects a new jboss-home
*expected (7.0.0 behaviour)*
_eap2_ is used
{noformat}
...
"name" => "jboss.server.config.dir",
"path" => "/home/pkremens/workspace3/eap2/jboss-eap-7.1/standalone/configuration",
...
{noformat}
Setting priority to Blocker since this is a regression against 7.0.0
> Embedded server started non-modular use only first --jboss-home for FS paths
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1675
> URL: https://issues.jboss.org/browse/WFCORE-1675
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Blocker
>
> First --jboss-home value passed is always used to FS paths resolution. The issue affects embed-server started using jboss-cli-client.jar.
> *reproduce*
> start embed server using wf1, stop it, start another embed server using wf2
> {noformat}
> /home/workspace3
> ├── wf1
> │ └── wildfly-10.0
> └── wf2
> └── wildfly-10.0
> $ pwd ; java -jar jboss-cli-client.jar
> [disconnected /] embed-server --jboss-home=~/workspace3/wf1/wildfly-10.0
> [standalone@embedded /] stop-embedded-server
> [disconnected /] embed-server --jboss-home=~/workspace3/wf2/wildfly-10.0
> {noformat}
> *actual*
> _wf1_ is used
> {noformat}
> ...
> "name" => "jboss.server.config.dir",
> "path" => "/home/workspace3/wf1/wildfly-10.0/standalone/configuration",
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1675) Embedded server started non-modular use only first --jboss-home for FS paths
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1675?page=com.atlassian.jira.plugi... ]
Ken Wills moved JBEAP-5414 to WFCORE-1675:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1675 (was: JBEAP-5414)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
Affects Version/s: (was: 7.1.0.DR1)
Affects Testing: (was: Regression)
> Embedded server started non-modular use only first --jboss-home for FS paths
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1675
> URL: https://issues.jboss.org/browse/WFCORE-1675
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Blocker
>
> First --jboss-home value passed is always used to FS paths resolution. The issue affects embed-server started using jboss-cli-client.jar.
> *reproduce*
> start embed server using eap1, stop it, start another embed server using eap2
> {noformat}
> /home/pkremens/workspace3
> ├── eap1
> │ └── jboss-eap-7.1
> └── eap2
> └── jboss-eap-7.1
> [pkremens@dhcp-10-40-5-78 client]$ pwd ; java -jar jboss-cli-client.jar
> /home/pkremens/workspace3/eap1/jboss-eap-7.1/bin/client
> [disconnected /] embed-server --jboss-home=~/workspace3/eap1/jboss-eap-7.1
> [standalone@embedded /] stop-embedded-server
> [disconnected /] embed-server --jboss-home=~/workspace3/eap2/jboss-eap-7.1
> {noformat}
> *actual*
> _eap1_ is used
> {noformat}
> ...
> "name" => "jboss.server.config.dir",
> "path" => "/home/pkremens/workspace3/eap1/jboss-eap-7.1/standalone/configuration",
> ...
> {noformat}
> [Full output|http://pastebin.test.redhat.com/395395] - only jboss.home.dir reflects a new jboss-home
> *expected (7.0.0 behaviour)*
> _eap2_ is used
> {noformat}
> ...
> "name" => "jboss.server.config.dir",
> "path" => "/home/pkremens/workspace3/eap2/jboss-eap-7.1/standalone/configuration",
> ...
> {noformat}
> Setting priority to Blocker since this is a regression against 7.0.0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months