Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Verified Answer
  • Replies replies
    5
  • Subscribers subscribers
    15
  • Views views
    596
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Filr Content Editor 2 - Container crashing when connecting to Filr 5.0.0.2

Adrijan Furlanic

We have a Filr CE v1 that we want to replace with the new Filr CE v2.

When we test the connection from Filr admin console to CE the test is successful. But when we try to add the Filr DNS hostname on CE administration portal (port:9443)  we get the following error:

After some digging we've found that the "content-editor-container" in CE v2 appliance crashes when we enter and submit the Filr DNS hostname.

In the logs it shows the following when i click submit:

[ loolwsd ] INF WSD initialization complete: setting log-level to [warning] as configured.| wsd/LOOLWSD.cpp:4232
[ loolwsd ] WRN Prisoner connection disconnected but without valid socket.| wsd/LOOLWSD.cpp:2256
[ loolwsd ] ERR Failed to unmount [/opt/lool/child-roots/gugspBM3utR1XNQX/lo].| common/JailUtil.cpp:68
[ loolwsd ] ERR Failed to unmount [/opt/lool/child-roots/gugspBM3utR1XNQX].| common/JailUtil.cpp:68
[ loolwsd ] WRN Jails root directory [/opt/lool/child-roots/gugspBM3utR1XNQX] is not empty. Will not remove it.| common/JailUtil.cpp:181
[ loolwsd ] ERR Failed to unmount [/opt/lool/child-roots/lool_test_mount].| common/JailUtil.cpp:68
[ loolwsd ] ERR Failed to unmount [/opt/lool/child-roots/hutYd9xdl7iNLYxv/lo].| common/JailUtil.cpp:68
[ loolwsd ] ERR Failed to unmount [/opt/lool/child-roots/hutYd9xdl7iNLYxv].| common/JailUtil.cpp:68
[ loolwsd ] WRN Jails root directory [/opt/lool/child-roots/] is not empty. Will not remove it.| common/JailUtil.cpp:181

We've tried/checked that:

 - Recreated the "content-editor-container" so it has the Filr IP and hostname in its hosts file inside the container.

 - Filr and Filr CE can resolve and see each others.

 - exported the certificates from the old v1 CE and import them into v2 CE.

 - Turn on/off proxy (should be off but just in case).

Does anyone know why this would happen and maybe how to fix it ? 

  • 0

    Hi, Adrijan

    Can you check the datamodel log for errors when the Filr hostname added in CE fails?
    /var/opt/novell/datamodel-service/logs/datamodel.stderrout.out


    Can you raise a CPE, so that it is easier to track?

  • 0  

    It doesn't look like it is the case here but maybe check that the docker ip address range and your network range do not overlap.  That sometimes causes issues.

    ip a

  • 0 in reply to   

    I checked it and it was not the case but thanks anyways since I forgot about this possibility.

  • Verified Answer

    +1 in reply to 

    I didn't since I didn't find this logs before but after I set the logging to debug and observed more I saw that there was a problem with the path to the certificate:

    INFO ContentEditorSettingsServiceImpl - Validating host url: filr.acme.org:8443/.../a
    ERROR ContentEditorSettingsServiceImpl - Connection failed: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    Only then I realized that the certificate is in the wrong key store. I put my certificate in key store: "Web applications certificates" as the MicroFocus/OpenText support and training video shows ( video link: https://www.youtube.com/watch?v=fZJqjINVwrs ).
    After I put the certificate into the keystore: "JVM Certificates" it connected and started to work (Content Editor with Filr as it should work).
    TL;DR
    You need to put your certificate into the "JVM Certificates". After that it connects normally.
  • 0 in reply to 

    Just as a small note on the "why" and the YouTube info.
    The "JVM certificates" is the keystore used by the JDK/JRE on the machine, usually/manually reached by "keytool -list -cacerts" and residing in /usr/lib64/jvm/java-11-openjdk-11/lib/security/cacerts. The Web Application Certificates are the ones used by e.g. jetty to provide TLS-secured communication, and they are in /opt/novell/common-services/etc/keystore (both locations found as of now, tested on my own CE appliance ;) ).

    When checking the connection to Filr/TeamWorks, only the JVM certificates are used, so if you do not run a publicly trusted cert on Filr, this will fail until you include the intermediate and possibly root certificate of your Filr's certificate's chain. The Filr server cert itself should only be imported if it is self-signed.

    In the YouTube video, Robin adds the private/public key pair to the WA-Certs and then adds the necessary intermediate cert also because it was not in the PKCS12 container with the keys/cert itself - the system needs to be able to build its own cert path, too - Java is secure, and thus, it even does not trust itself when not configured properly. It would have been enough, though, to add the intermediate to the JVM certificates to make them known to the PKIX path builder..
    In the video, Robin probably did not need to add the cert of Filr to the JVM certs because his Filr hat a "proper" certificate already.

    TL;DR: So as a rule: to have a java based service connect to another machine, all necessary root and intermediate certs must be in the JVM certs; to provide a TLS service, the key pair and its own/server certificate must be available in the Web Application certificates, their intermediates can be in either as long as they are in one.

    HTH for the future :)

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.