[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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-396:
-----------------------------------------
[~luck3y] I'm pretty sure I named it that deliberately. Granted the name is questionable since "domain" can imply the entire domain not just a host, but I don't think I did ti by mistake. I basically came up with two op names, one for a single process request (resolve-expression) and this one for requests that will get rolled out to multiple domain processes.
> 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1671:
------------------------------------------
[~gaol] I think it should be ok. The one concern I have is there is some ServiceLoader stuff that looks like leftover cruft in full's security module. I don't believe it's needed, but I'm concerned that if we bring this module dependency back it may end up interfering somehow. So I've sent up a PR to remove it and will see if that breaks CI in some way:
https://github.com/wildfly/wildfly/pull/9067
If it's ok then I'll merge it and that change should be part of any backport of this to EAP.
> 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