In a previous blog (see this one), I described how to setup a WildFly instance in HTTPS and I quickly mentioned something related to the CPS. When I wrote this previous blog, I was already aware of one specific issue that prevented the CPS to be usable but I didn’t want to mention it to stay focus on the WildFly specific steps for the HTTPS setup which are common between the JMS and the CPS.

 

In this blog, I will NOT talk about the Java cacerts because the commands are exactly the same as in the previous blog and they aren’t dependent on the JBoss/WildFly version. As described in the previous blog, the setup of the CPS in HTTPS isn’t described in the official EMC/OTX Documentation (yet). Because of that, I worked with EMC on defining the minimal steps that are required to get one up&running.

 

So in this blog and just to compare with the previous blog, I will start with setting up a JBoss 7.1.1 in SSL (without the Java cacerts stuff) without using the ConfigSSL.groovy since it’s not able to handle the CPS setup. So as before, I’m starting with defining some environment variables (I’m using the same CPS name) and then stopping the CPS:

[xplore@full_text_server_01 ~]$ cd /tmp/certs/
[xplore@full_text_server_01 certs]$ read -s -p "  ----> Please enter the JKS password: " jks_pw
[xplore@full_text_server_01 certs]$ 
[xplore@full_text_server_01 certs]$ export server_name="Node2_CPS1"
[xplore@full_text_server_01 certs]$ $JBOSS_HOME/server/stop${server_name}.sh
[xplore@full_text_server_01 certs]$ 
[xplore@full_text_server_01 certs]$ mv /tmp/certs/full_text_server_01.jks $JBOSS_HOME/server/DctmServer_${server_name}/configuration/my.keystore
[xplore@full_text_server_01 certs]$ chmod 600 $JBOSS_HOME/server/DctmServer_${server_name}/configuration/my.keystore

 

In this case with JBoss 7.1.1, the $JBOSS_HOME used above is “$XPLORE_HOME/jboss7.1.1”. So now the commands to configure a JBoss 7.1.1 in HTTPS are the following ones:

[xplore@full_text_server_01 certs]$ cd $JBOSS_HOME/server/DctmServer_${server_name}/configuration/
[xplore@full_text_server_01 configuration]$ cp standalone.xml standalone.xml_bck_$(date +%Y%m%d)
[xplore@full_text_server_01 configuration]$ 
[xplore@full_text_server_01 configuration]$ sed -i 's/inet-address value="${jboss.bind.address.management:[^}]*}/inet-address value="${jboss.bind.address.management:127.0.0.1}/' standalone.xml
[xplore@full_text_server_01 configuration]$ sed -i '/<subsystem .*/a             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">n                <ssl name="https" password="'${jks_pw}'" certificate-key-file="'$JBOSS_HOME'/server/DctmServer_'${server_name}'/configuration/my.keystore" cipher-suite="PUT_HERE_SSL_CIPHERS"/>n            </connector>' standalone.xml

 

And that’s all. As you can see, it’s even easier to setup a JBoss 7.1.1 in SSL that it was with a WildFly 9.0.1. This is a small description of these commands:

  • Line 2: Backup of the standalone.xml file
  • Line 4: Changing the default IP on which WildFly is listening for the Management Interface (by default 0.0.0.0 which means no restriction) to 127.0.0.1 so it’s only accessible locally
  • Line 5: Adding a new connector specific to https and which defines the keystore path, password as well as the SSL Ciphers to be used. Just replace “PUT_HERE_SSL_CIPHERS” with a comma separated list of SSL Ciphers that you want to enable

 

With the above commands, both HTTP and HTTPS will be enabled. If you want to disable all HTTP communications (which I recommend), then you can just remove the http connector:

[xplore@full_text_server_01 configuration]$ sed -i '/<connector .*name="http" .*socket-binding="http"/d' standalone.xml

 

Alright so now JBoss 7.1.1 is setup & enabled in HTTPS only as we did for the WildFly setup. At this point, if you start the CPS again and then access the URL in HTTPS, it will work. Then what is the purpose of this blog? Well the URL will work but the issue I faced is that this CPS is actually unusable.

 

When you install a remote CPS, you then need to register it to the PrimaryDsearch so it can be used. If you do not register it, then it just won’t do much so it’s kind of useless. Usually when you install a remote CPS, you will want to register it in HTTP directly in the PrimaryDsearch. This is done in the following way (I’m considering a PrimaryDsearch on the same host with port 9302 in HTTPS):

  1. Open the dsearchadmin (E.g.: https://full_text_server_01:9302/dsearchadmin) and login with the JBoss admin account
  2. Navigate to “Home > Services > Content Processing Service”
  3. Click on the “Add” button
  4. Select the “remote” checkbox
  5. Set the URL to: http://full_text_server_01:9400/cps/ContentProcessingService?wsdl
  6. Set the Instance & Usage according to your needs
  7. Click on the “OK” button

 

If you are using a CPS in HTTP as in the URL mentioned (step 5 – the port might change depending on what you configured), then you will see a pop-up showing that the PrimaryDsearch was able to connect to the CPS and the CPS is now registered. As a side note, for the CPS to be fully usable, you will need to restart the PrimaryDsearch so the status can be changed to green (INITIALIZED).

 

So what’s the difference when using a CPS in HTTPS-only? Well when you are at the step 5, you will need to use the HTTPS URL of the CPS which is therefore: https://full_text_server_01:9402/cps/ContentProcessingService?wsdl. When you click on the “OK” button at the last step (7), you will not get a pop-up saying that the PrimaryDsearch was able to connect to the CPS but instead you will see a failure message. The exact error message from the pop-up is:

Fail to connect the remote CPS at https://full_text_server_01:9402/cps/ContentProcessingService?wsdl

 

On this failure pop-up, there is only a OK button and when you click on it, you can see that the CPS hasn’t been registered at all. On the CPS logs, there are absolutely no information related to this issue and on the Dsearch logs, it’s not really much better: the only message that is printed is an INFO message with the following information:

2017-05-01 10:59:02,951 UTC INFO [RMI TCP Connection(5)-147.167.175.209] c.e.d.core.fulltext.indexserver.cps.CPSSubmitter - Begin to connect to CPS at (https://full_text_server_01:9402/cps/ContentProcessingService?wsdl)  with connection 16

 

That’s all, no errors, nothing. Of course you can enable some debug. For example you can add the “-Djavax.net.debug=ssl” inside the JAVA_OPTIONS of the PrimaryDsearch and the remote CPS, restart them both and then try again. You should be able (if you followed this blog properly) to see that the Dsearch and the CPS are exchanging properly the Hello requests but then the CPS is still not registered.

 

To solve this issue, there is actually just one small thing that need to be done and that’s updating the web.xml file for the CPS. You just need to add a security-constraint tag inside this file to specify that all pages are now using HTTPS:

[xplore@full_text_server_01 configuration]$ sed -i '/</web-app>/i \n    <security-constraint>n        <web-resource-collection>n            <web-resource-name>secured pages</web-resource-name>n            <url-pattern>/*</url-pattern>n        </web-resource-collection>n        <user-data-constraint>n            <transport-guarantee>CONFIDENTIAL</transport-guarantee>n        </user-data-constraint>n    </security-constraint>' ../deployments/cps.war/WEB-INF/web.xml

 

When this has been added, the web.xml file for the CPS should look like that:

[xplore@full_text_server_01 configuration]$ cat ../deployments/cps.war/WEB-INF/web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"  xmlns_xsi="http://www.w3.org/2001/XMLSchema-instance" xsi_schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
        <listener>
        <listener-class>com.emc.cma.cps.management.CPSContextListener</listener-class>
    </listener>
        <listener>
        <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
    </listener>
    <servlet>
        <servlet-name>AgentService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>ContextRegistryService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>ContentProcessingService</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>ContentProcessingService</servlet-name>
        <url-pattern>/ContentProcessingService</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>ContextRegistryService</servlet-name>
        <url-pattern>/runtime/ContextRegistryService</url-pattern>
    </servlet-mapping>

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>secured pages</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
</web-app>
[xplore@full_text_server_01 configuration]$

 

Then simply start/restart the remote CPS and this time, when you register it inside the PrimaryDsearch, you will get the success message!

 

Post Views: 403
Thumbnail [60x60]
by
Morgan Patou