近期，在升级一台CENTOS7 Linux主机内核到CTYUNOS2.0.1内核的过程中，由于该主机硬件故障，导致LVS备节点Keepalived服务异常，备节点绑定的VIP已经成功切换到主节点（Keepalived是双主双VIP架构）。考虑到负载单节点的风险，并且故障主机硬件修复需要一段时间，我们决定把一台应用主机临时安装为Keepalived备节点，并利用一个空闲IP作为VIP，当主节点异常时，手工快速把应用连接到的VIP切换到新的LVS备节点。复制
在新主机编译安装keepalived时（使用命令“./configure --prefix=/app/public/keepalived）报错如下：”configure: error: OpenSSL libraries are required“。根据以往的实施经验，这种情况下，一般是需要通过yum命令安装“openssl-devel”开发包来解决该错误，而当我们使用“sudo yum install openssl-devel”安装该Package时，系统报了大量错误：
而当我们使用命令“sudo rpm -qa|grep openssl”查看已经安装openssl-delvel包时，发现系统已经安装过该包了。复制
问题陷入了僵局，我们尝试自己编译一个openssl1.1.1f，然后在编译keepalived时指定自己编译的openssl包，结果出现一个警告，系统提示差一个叫“libnl” rpm包，但是考虑到自己编译的openssl包中的*.so库和系统中已存在的库文件冲突，该操作可能导致SSHD服务异常，不敢轻易执行覆盖动作。
无意中，听同事说，这几次升级内核的过程中已经导致几台Linux主机的curl命令不能正常使用，于是我就随手执行了一下命令“curl –v”，结果发现该命令是正常的；但是同事肯定地说他执行同样的命令，系统会报如下图中所示的错误；于是，我就简单的对比了一下，发现我是用root命令执行的，而同事是用普通用户执行的。复制
我进一步分析发现，root用户的curl命令来源路径是”/bin/curl”,而普通用户的是“/usr/bin/curl”，对比两个命令文件的字节数也一致，进一步通过命令”ldd /bin/curl”检查他们的依赖，发现结果也是一致的。隐隐感觉这些是原有操作系统openssl升级导致的，因为本次OS在升级内核前，以前的openssl库也升级过。复制
于是我就翻看以前编写的openssl升级文档，每个步骤都认真分析，最终发现在openssl升级过程中，需要指定openssl库的搜索路径，于是我就打开“/etc/ld.so.conf文件，发现了ctyunos本身的LIB路径和原来cengos7的openssl路径，经过分析，发现这两个版本库存在细微差别，我决定把“/srv/ssl-1.1.1/lib”这行注释掉，让系统使用ctyunos自身的库。
在注释掉上述配置语句后，执行命令“sudo ldconfig”，使得配置搜索路径生效。然后检查普通用户和root用户的curl命令执行情况，发现执行结果都是正确的，同时root的yum指令和普通用户“sudo yum *“指令均可以正常执行了。
最后，测试keepalived源码的编译安装命令，一切均恢复了正常。
