[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 4:38 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remote add wildfly <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 4:37 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 4:36 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 4:35 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 4:34 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wilfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFLY-5227:
---------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly normally
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem'
(2) wildfly-core
- git checkout -b security-manager
- git remove add <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wilfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1898) Defining protocol of ssl config in security realm to incorrect value results in broken https
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1898:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1898
> URL: https://issues.jboss.org/browse/WFCORE-1898
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: 3.0.0.Alpha10
> Reporter: Radim Hatlapatka
> Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFCORE-13:
-----------------------------
Fix Version/s: 3.0.0.Alpha14
(was: 3.0.0.Alpha13)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha14
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-311:
------------------------------
Fix Version/s: 3.0.0.Alpha14
(was: 3.0.0.Alpha13)
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-311
> URL: https://issues.jboss.org/browse/WFCORE-311
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha14
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-363:
------------------------------
Fix Version/s: 3.0.0.Alpha14
(was: 3.0.0.Alpha13)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha14
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months