--- title: Kylin V10 上的 libssl 依赖问题-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 Kylin V10 上的 libssl 依赖问题相关的常见问题和使用技巧，帮助您快速解决 Kylin V10 上的 libssl 依赖问题的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # Kylin V10 上的 libssl 依赖问题 更新时间：2026-05-07 08:31 适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot 本文介绍 OceanBase 数据库当前在麒麟 Kylin V10 上 libssl 依赖的相关问题和解决方法。 ## 适用版本 OceanBase 数据库 V2.x 和 V3.x 版本 ## 错误现象 OceanBase 数据库当前在麒麟 Kylin V10 上 libssl 依赖问题出现较多，具体表现在几个方面。 1. 某些旧版本 ODP 以及旧 OceanBase 数据库（如 V2.2.30）版本安装时会报错显示没有对应版本的 libssl 文件，导致 ODP RPM 安装失败。此问题通过以下方式跳过，安装后观测平时可以正常工作。 ```shell rpm -ivh --nodeps ``` 2. ODP 启动时由于 libssl 不适配，导致启动失败。譬如：Kylin Linux V10 Tercel + ODP 1.8.10-20210729103745.e17。 3. ocp_agent 的 python 脚本显示 libssl 报错，导致无法继续相关逻辑操作，python 脚本报错后退出。(OCP 相关操作也会终止) ```shell ImportError: /usr/lib64/python2.7/lib-dynload/_ssl.so: symbol SSLv3_method version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference " ``` ## 错误原因 在这些问题里，主要分为两部分。 ### 问题一：RPM 安装由于 libssl 失败 在通过 rpm/yum 安装软件包时，rpm 会检测 rpm 包的相关信息，这些信息可以通过以下命令获得。 ```shell # 找不到ODP相关信息 rpm -qR tsar-2.1.66-1.5923e46.el7.x86_64.rpm config(tsar) = 2.1.66-1.5923e46.el7 libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.7)(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) ``` 在输出中除去 rpmlib 和 sh 的信息，可以看到此 rpm 包需要 libc.so.6、libdl.so.2、libm.so.6 的依赖，如果这些依赖未解决，则安装有类似报错。 ```shell #这里专门换了个 rpm 包 rpm -ivh tsar-2.1.66-1.5923e46.el7.aarch64.rpm error: Failed dependencies: libdl.so.2(GLIBC_2.17)(64bit) is needed by tsar-2.1.66-1.5923e46.el7.aarch64 ``` ### 问题二：程序运行时 libssl 依赖问题 这里的程序指两个方面，二进制文件和脚本（如 python 脚本）。它们的报错本质上都是一样的，都是在运行调用时发现现有的 `libssl.so.*` 文件不能满足程序运行的要求。这个问题分为两个细节：1. 调用何处 `libssl.so` 文件，2. 此文件符不符合程序要求。 #### 如何判断使用何处 `libssl.so.*` 文件 在运行下有几个关键操作系统变量和文件将影响这个问题。 - LD_LIBRARY_PATH / LIBPATH / SHLIB_PATH - PYTHONPATH - /etc/ld.so.conf 这些信息最终主要决定 lib 库在调用时候在操作系统层面何处去寻找相关的 lib 文件。目前，OceanBase 相关产品有两个地方寻找 libssl：一个是操作系统默认路径 `/usr/lib64`，第二个是在 `/home/admin/ocp_agent/site-packages/mysql-vendor` 里。其中第二个主要 python 使用，定义在如下。 ```shell # /home/admin/ocp_agent/init.d/ocp-agent export LD_LIBRARY_PATH=/usr/lib64:/usr/lib:/lib64:/lib:/usr/local/lib64:/usr/local/lib:$OCP_AGENT_HOME/libs && export PYTHONPATH=/home/admin/ocp_agent/site-packages && cd /home/admin/ocp_agent && ./ocp_agentd.py start ``` 所以，综上所述，二进制文件运行时主要根据操作系统 LD_LIBRARY_PATH 决定，如果 LD_LIBRARY_PATH 为 NULL，则默认在 `/etc/ld.so.conf` 文件中查询相关信息，如果还没有，则以 `/usr/lib*` 为准 (应该和编译以及操作系统默认配置有关)。而 python 则和启动时 python 运行引入的环境变量有关。 此外，部分程序中并未指定具体版本文件，所以会先查找 `libssl.so` 文件，而不是去找 `libssl.so.*` 文件。这也是对 `libssl.so` 做软连接的原因。 #### 如何判断是否符合调用要求 二进制文件里会通过以下命令显示其所需要的动态库依赖。 ```shell ldd obproxy linux-vdso.so.1 => (0x00007fff0e3b5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f11e9826000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f11e9622000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f11e93af000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f11e8f4c000) librt.so.1 => /lib64/librt.so.1 (0x00007f11e8d44000) libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f11e8aee000) libidn.so.11 => /lib64/libidn.so.11 (0x00007f11e88bb000) libssl3.so => /lib64/libssl3.so (0x00007f11e8663000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f11e8453000) ``` 而在之前讨论的这个报错里显示： ``` 以上反应了依赖的两个问题点： - Lib 的版本需求。这个信息实际上对应在 `libssl.so` 后缀里(但是修改文件名不解决实际版本问题)，所以这里 python 需要的是 `libssl.so.1.1` 文件。 - Lib 的方法调用需求。譬如 python 需要 SSLv3_method 方法。 所以如果存在 `libssl.so.1.1*` 文件，则需要判断是否存在 SSLv3_method 方法。 ```shell readelf -a libssl.so.1.1 | grep -i SSLv3_method ``` 如果显示类似的信息 `SSLv3_method@@OPENSSL_1_1_0`，说明满足了以上两点。 - 对应版本：OPENSSL_1_1_0 - 对应方法：SSLv3_method ## 解决方法 ### 问题一解决方案 这个报错是由于 rpm 将相关安装的信息存储在其相关 rpmdb 中。所以，如果在安装过程中出现依赖问题，调整、拷贝、删除、软连接任何 `libssl*` 文件都无助于问题解决。要么使用 `rpm --nodeps` 跳过依赖检查，要么就需要在 rpmdb 中创建相关的 libssl 信息(包括版本)。 ### 问题二解决方案 所以，对应于第二类问题，有几个实际的解决场景： 1. 调用的 libssl 文件不对，那么让程序选择正确的 lib 文件譬如当前 OCP 在升级 OceanBase 数据库时会选择一台 OBServer 运行 python 脚本做 pre-check task，这时 ocp_agent 的 python 脚本调用 MySQL 相关操作时和自身保存在 `/home/admin/ocp_agent/site-packages/mysql-vendor` 的 `libssl.so`、`libcrypto.so` 不兼容，导致运行失败。此问题，应该是 ocp_agent 的一个 bug。修复方式为移除相关 `libssl.so.*`、`libcrypto.so` 文件，让 python 直接使用操作系统默认的 lib 文件，待任务完成后恢复即可。 ```shell mv /home/admin/ocp_agent/site-packages/mysql-vendor/lib* /tmp/ ``` 2. 调用的 libssl 文件无对应版本，或者无相关 method，其实还是文件不对，但是要先找到有相关 method 的文件，再做调整。此类主要常见于 obproxy，或者也见于 python 脚本运行过程中。主要通过替换相关 `libssl.so.*/libidn.so.*/libcrypto.so.*` 文件来实现。程序在判断 libssl 时，先在 LD_LIBRARY_PATH 找到对应路径，再查找对应名称 `libssl.so` 文件。所以通过给 `libssl.so` 等相关文件做软连接，可以调整 libssl 使用的版本。 ```shell # 譬如通过拷贝ocp docker来解决部分问题 ln -s libssl.so.10 libssl.so ln -s libidn.so.11 libidn.so ln -s libcrypto.so.10 libcrypto.so ``` ## 更多信息 `/usr/lib*` 下无论软连接修改还是添加新的 lib 库，都有一定的风险，主要在于 `/usr/lib*` 下的 lib 库主要使用者是全操作系统的所有程序。修改和调整这些文件有破坏整体操作系统的风险，此外 libssl(openssl) 和 ssh 等重要进程有依赖关系，安装更新卸载都要有充分的准备。调整最好在设置 LD_LIBRARY_PATH 层面。通过调整 LD_LIBRARY_PATH 可以避免影响整个操作系统的 lib 环境。 ```shell export LD_LIBRARY_PATH = $LD_LIBRARY_PATH: ``` `/home/admin/ocp_agent/site-packages/mysql-vendor` 的 lib 库为 ocp_agent 的 python 脚本自身使用，调整风险相对来说较少。 Previous [安装 OceanBase rpm 包报错 libcrypto.so.10 is needed](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000210125) Next [麒麟操作系统安装 OceanBase 数据库报错 Failed Dependencies: libcrypto.so.10 libssl.so.10](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000008222) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线