Bug 1029928 - Settings of security domain disappear after reload
Settings of security domain disappear after reload
Status: NEW
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: EAP 6.4.0
Assigned To: Darran Lofthouse
Martin Simka
: 1265492 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-11-13 09:45 EST by Ondrej Lukas
Modified: 2017-10-09 20:18 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ondrej Lukas 2013-11-13 09:45:00 EST
Adding security domain element (authentication, authorization, acl, audit, identity-trust or mapping) turns server to reload-required, but reload causes element disappear. It happens only if you reload server before any next setting of added element.

Steps to reproduce:
1. run standalone server:
cd EAP_HOME/bin

2. run CLI:
cd EAP_HOME/bin
./jboss-cli.sh -c

3. execute commands in CLI:
3.1. add security domain:

3.2. add element for authentication:

you gain:
"outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"

3.3. reload server:

3.4. add authentication settings:
/subsystem=security/security-domain=JBossTestDomain/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required, module-options=[("usersProperties"=>"/home/user/testing/users.properties"), ("rolesProperties"=>"/home/user/testing/roles.properties")])

Result of command is "outcome" => "failed", because authentication element disappeared after server reload.

If you run command from 3.4. before command from 3.3. then setting of security domain is added right.
Comment 1 Brian Stansberry 2013-11-13 09:54:22 EST
Too late for 6.2.

I expect the issue is the xml marshaller does not persist an empty authentication element.

Workaround is to finish all necessary configuration before reloading.

Recommended practice in any multi-step configuration exercise is to use a CLI batch to group related operations into a single unit of work.
Comment 2 Darran Lofthouse 2013-11-13 10:09:14 EST
I would not be surprised if the empty element is not allowed according to the schema.
Comment 3 Brian Stansberry 2013-11-13 10:13:33 EST
In that case there's a missing Stage.MODEL validation step in the add handler to confirm presence of required children. I expect there are more than a few cases of that kind of thing scattered about.

The downside to adding the validation step is the user is forced to use a batch, so I'm not sure adding them in 6.x is the right thing to do.
Comment 4 Darran Lofthouse 2013-11-13 10:18:41 EST
+1 I think loosing an intermediate change is going to be better than mandating they make the change in one step even though doing it as one is the right thing to do.

Loosing the intermediate change does not break existing scripts or cause a review of all documentation and quick starts that may have ever described how to add a domain.
Comment 5 Josef Cacek 2013-11-13 10:33:33 EST
The question from my PoV is, if the "reload-required" response is really necessary here. 

The user experience is not good now. 
E.g. A user wants to add a security domain with one login-module. So he'll create a new domain, then add the authentication=classic element, but then the server responses "I need a reload". And the user beliefs the server and makes :reload. Then he try to add his login-module, but the operation fails, because authentication node is missing. FAIL.
Comment 9 Darran Lofthouse 2014-10-28 13:53:23 EDT
One additional point in relation to https://bugzilla.redhat.com/show_bug.cgi?id=1029928#c5

Administrators SHOULD NEVER be executing :reload solely because the server says a reload is required - they SHOULD execute reload at the point where they want the change they have made to be activated.  In the sequence of steps described here the administrator has not reached the point where they have changes that are ready to be activated as they have not completed the security domain definition.
Comment 10 Chao Wang 2015-09-23 03:48:32 EDT
*** Bug 1265492 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.