You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had various problems with using a JRE tarball (jre-8u181-linux-x64.tar.gz) in place of a JDK one for the Java environment.
It seems that the cause of the problem is that the esg-node script has various references to the subdirectory jre/lib/security/ under $JAVA_HOME. This is correct for JDK, but in JRE it is just lib/security. The consequence of this was that the attempt to create jssecacerts failed because the directory path was wrong, so tomcat fell back to using the distribution truststore (cacerts), which did not contain the ESGF certificates. This led to certificate validation errors when trying to talk to a server which has an ESGF certificate for the web container instead of a commercial one.
The problem can be avoided by using the JDK instead of JRE, but if we want to support JRE in future, then I believe that we should do the following:
replace all the occurrences of ${JAVA_HOME}/jre/lib/security/ (or ${java_install_dir}/jre/lib/security) in esg-node with a shell variable
set this variable by testing to see which of ${java_install_dir}/jre/lib/security and ${java_install_dir}/lib/security exists
The text was updated successfully, but these errors were encountered:
I had various problems with using a JRE tarball (
jre-8u181-linux-x64.tar.gz
) in place of a JDK one for the Java environment.It seems that the cause of the problem is that the esg-node script has various references to the subdirectory
jre/lib/security/
under$JAVA_HOME
. This is correct for JDK, but in JRE it is justlib/security
. The consequence of this was that the attempt to createjssecacerts
failed because the directory path was wrong, so tomcat fell back to using the distribution truststore (cacerts
), which did not contain the ESGF certificates. This led to certificate validation errors when trying to talk to a server which has an ESGF certificate for the web container instead of a commercial one.The problem can be avoided by using the JDK instead of JRE, but if we want to support JRE in future, then I believe that we should do the following:
${JAVA_HOME}/jre/lib/security/
(or${java_install_dir}/jre/lib/security
) inesg-node
with a shell variable${java_install_dir}/jre/lib/security
and${java_install_dir}/lib/security
existsThe text was updated successfully, but these errors were encountered: