I’m warning you, this blog will be short, like extra short! Beginning of this year, during our testing of the new xPlore 1.6 (GA release, no patches were available) components, I was following my blog to setup a PrimaryDsearch and an IndexAgent in HTTPS using the ConfigSSL.groovy. As the groovy script is provided with the xPlore components directly, the steps coming from my previous blog also apply to xPlore 1.6 (just need to replace JBoss 7.1.1 with WildFly 9.0.1 in the paths). The script has been updated for WildFly so that’s good but at the end of it when I tried to access the URLs of the PrimaryDsearch and IndexAgent using HTTPS, they weren’t responding at all…

 

When you are testing newly released component, you often face a lot of small issues so I wasn’t really afraid. So then I checked the log files of the xPlore components to see what the issue was:

[xplore@xplore_server_01 ~]$ grep -i ERROR $JBOSS_HOME/server/DctmServer_PrimaryDsearch/log/server.log
2017-02-18 11:17:36,414 UTC ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.server.controller.management.security_realm.sslRealm.key-manager: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.sslRealm.key-manager: WFLYDM0085: The alias specified 'xplore' does not exist in the KeyStore, valid aliases are {ft_alias}
2017-02-18 11:17:55,130 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "dsearchadmin.war")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
2017-02-18 11:17:55,132 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "dsearch.war")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
2017-02-18 11:17:55,133 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "dsearchinfocenter.war")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
2017-02-18 11:17:55,135 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
2017-02-18 11:17:55,136 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
2017-02-18 11:17:55,137 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
2017-02-18 11:17:55,137 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
2017-02-18 11:17:55,138 UTC ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
2017-02-18 11:17:55,292 UTC ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 26241ms - Started 208 of 403 services (12 services failed or missing dependencies, 218 services are lazy, passive or on-demand)
[xplore@xplore_server_01 ~]$

 

The only interesting message here is the first ERROR message. All other messages are a consequence of the first one. When I saw this error, I was a little bit surprised… I was pretty sure I specified properly the “-alias ft_alias” as part of the parameters for the ConfigSSL.groovy script and yet the PrimaryDsearch was trying to use the alias “xplore”… So I checked the standalone.xml file and indeed, the alias used inside it was “xplore” while this wasn’t what I asked the script to configure. So what happened exactly? The only way to understand is to check the content of the groovy script itself. So I opened this file and found the following:

  • On line 48, the variable “$alias” is initialized with a default value of “xplore” => This is OK
  • On line 138, the variable “$alias” is properly set to the value given as parameter (if specified) => This is OK
  • On line 597, 626, 916, 1114 and 1322, the value used for the alias is hardcoded as “xplore” and it’s not using the variable “$alias” defined on line 48 and 138… => This is the issue

 

So yeah basically between xPlore 1.5 and xPlore 1.6, the EMC xPlore Team updated the ConfigSSL.groovy script to handle the WildFly setup but they forgot somehow to use the variables and just put a hardcoded value instead… Too bad. So with that, I just opened a bug with the EMC Support and provided them the explanation above. They confirmed the bug and the solution I provided them and they were planning at this time to fix this issue in the xPlore 1.6 P02 release (end of April). I didn’t check this P02 yet but hopefully this small issue is solved there :).

 

So if you are using xPlore 1.6 P00 or P01, I would suggest you to modify the standalone.xml file manually if the alias you are using inside the keystore isn’t “xplore”. Via command line, this can be done like that for example (just replace ‘ft_alias’ with your alias):

[xplore@xplore_server_01 ~]$ sed -i 's/(.*keystore.*) alias="[^"]*"/1 alias="ft_alias"/' $JBOSS_HOME/server/DctmServer_PrimaryDsearch/configuration/standalone.xml