[
https://issues.apache.org/jira/browse/HADOOP-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187403#comment-14187403
]
Colin Patrick McCabe commented on HADOOP-11216:
-----------------------------------------------
I thought about this a little bit more. How openssl is named varies a lot from
platform to platform. It's not much of an exaggeration to say that it's a
nightmare for packagers. Adding to this problem, a lot of the OSes we support
(like RHEL6.4) have versions of openssl installed by default that are too old
for Hadoop. So we're going to have to ask people to install a newer version
manually in any case. I think depending on a specific name suffix is going to
create more problems than it solves, at least in the short term. So I think we
should just search for the no-suffix form, and error out if it's not found.
bq. 1. Existing openssl.prefix, openssl.lib, openssl.include will let people to
specify custom openssl location, they will become -L and -I when doing compile
using gcc. Yes, I agree people can set CMAKE_LIBRARY_PATH and
CMAKE_INCLUDE_PATH. But snappy is in this way, should we make them consistent
(keep openssl.**, or remove snappy.**)?
This is another thing I need to think about more. If we're going to have
custom installations of openssl, then maybe these variables need to exist.
However, we also need a way of finding this stuff at runtime, as you pointed
out. I think we can use the same trick we used earlier where we add an RPATH
to libhadoop.so that causes it to find the libcrypto in its own directory, if
one exists. Then the sysadmin can create a symlink inside the libhadoop.so
directory to the hadoop-specific version of libcrypto.so.
> Improve Openssl library finding
> -------------------------------
>
> Key: HADOOP-11216
> URL: https://issues.apache.org/jira/browse/HADOOP-11216
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 2.6.0
> Reporter: Yi Liu
> Assignee: Colin Patrick McCabe
> Attachments: HADOOP-11216.003.patch
>
>
> When we compile Openssl 1.0.0\(x\) or 1.0.1\(x\) using default options, there
> will be {{libcrypto.so.1.0.0}} in output lib dir, so we expect this version
> suffix in cmake build file
> {code}
> SET(STORED_CMAKE_FIND_LIBRARY_SUFFIXES CMAKE_FIND_LIBRARY_SUFFIXES)
> set_find_shared_library_version("1.0.0")
> SET(OPENSSL_NAME "crypto")
> ....
> {code}
> If we don't bundle the crypto shared library in Hadoop distribution, then
> Hadoop will try to find crypto library in system path when running.
> But in real linux distribution, there may be no {{libcrypto.so.1.0.0}} or
> {{libcrypto.so}} even the system embedded openssl is 1.0.1\(x\). Then we
> need to make symbolic link.
> This JIRA is to improve the Openssl library finding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
