[
https://issues.redhat.com/browse/WFCORE-4827?page=com.atlassian.jira.plug...
]
Brian Stansberry commented on WFCORE-4827:
------------------------------------------
Thanks. So AIUI the issue is that steps that add services result in adding a step the
executes a ServiceVerificationHelper that monitors those particular services. And the
first ServiceVerificationHelper that fails prevents any later ServiceVerificationHelper
steps running, because the first one triggers rollback.
One solution to this is to change this:
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
Instead of immediately calling context.setRollbackOnly, instead add another Stage.VERIFY
step that calls it. That step will be added to the end of the queue for Stage.VERIFY, so
it will execute after all the previously registered ServiceVerificationHelper steps.
Errors Missing on Invalid Configuration
---------------------------------------
Key: WFCORE-4827
URL:
https://issues.redhat.com/browse/WFCORE-4827
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Beta7
Reporter: Darran Lofthouse
Assignee: Richard Opalka
Priority: Critical
Labels: domain-mode
[~ropalka] I believe this is caused by the MSC refactoring.
Steps, in the default host.xml for domain mode.
1. Define the following security realm: -
{noformat}
<security-realms>
<security-realm name="ldap_security_realm">
<server-identities>
<ssl>
<keystore path="generated.keystore"
relative-to="jboss.server.config.dir" keystore-password="password"
alias="server" key-password="password"
generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<ldap connection="testLdap"
base-dn="dc=test,dc=sbc,dc=com" recursive="true">
<username-filter attribute="samaccountname"/>
</ldap>
</authentication>
</security-realm>
{noformat}
2. Define the following outbound connection: -
{noformat}
<outbound-connections>
<ldap name="testLdap" url="ldap://localhost:636"
search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com"
search-credential="passowrd" />
</outbound-connections>
{noformat}
3. Update the management interfaces to: -
{noformat}
<management-interfaces>
<http-interface security-realm="ldap_security_realm">
<http-upgrade enabled="true"/>
<socket interface="management"
port="${jboss.management.http.port:9990}"/>
</http-interface>
</management-interfaces>
{noformat}
The server fails to boot with just the following error: -
{noformat}
[Host Controller] 17:56:40,052 FATAL [org.jboss.as.host.controller] (Controller Boot
Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting.
See previous messages for details.
{noformat}
If the management interface is then updated to reference the ManagementRealm instead the
error is now: -
{noformat}
[Host Controller] 18:01:48,595 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
[Host Controller] ("host" => "master"),
[Host Controller] ("core-service" => "management"),
[Host Controller] ("security-realm" => "ldap_security_realm")
[Host Controller] ]) - failure description: {
[Host Controller] "WFLYCTL0412: Required services that are not installed:"
=> ["jboss.server.path.\"jboss.server.config.dir\""],
[Host Controller] "WFLYCTL0180: Services with missing/unavailable
dependencies" =>
["org.wildfly.core.management.security.realm.ldap_security_realm.key-manager is
missing [jboss.server.path.\"jboss.server.config.dir\"]"]
[Host Controller] }
{noformat}
This error is expected as the realm defined in step 1 referenced an invalid path.
I believe the error reporting should come from this method: -
org.jboss.as.controller.ServiceVerificationHelper.execute(OperationContext, ModelNode)
However something seems to have changes with the MSC migration.
This was recently encountered debugging the bug report in
https://issues.redhat.com/browse/WFCORE-4820, if you see an error "Multiple
CallbackHandlerServices for the same mechanism (PLAIN)" that has been covered by
WFCORE-4820.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)