|
| 图片来自网络 |
1. 银河麒麟（Kylin V10）
银河麒麟算是好的，毕竟高仿 CentOS。看它的文档，似乎 V4 的时候还是 Ubuntu / Debian 系的，现在的 V10 已经转到 RedHat / CentOS 派系下了。
我们的程序基本都是静态链接，所以就还好。唯一动态链接的是 OpenSSL，这个在《编译自己的 CentOS7 OpenSSL 1.0.2u 动态链接库》这篇 Blog 中已经介绍过了。
1.1. ldconfig
说起来算个坑的，就是它的 SP2 版本的 ldconfig 无法正确读取被 patchelf 改过 SONAME 的库，说什么「已被截断」。搜了一下，说是属于 ldconfig 的 Bug。patchelf 改过 soname 的 so 库，里面的段顺序会变。但规范里面并没写顺序是有保障的，ldconfig 不应该自行假设顺序一定是那个样子。
有人说这是上游供应链（glibc）的 Bug。的确无论 SP3 的哪个版本都是好的。但我看 SP2 和 SP3 的 glibc 的版本也没看出来有什么变化，这里先存疑一下吧。
我的应对方案就是 SP2 下就不改 SONAME 了，难看就难看一些。
1.2. VMware
接下来这一个实际上应该放在最前面，不过只是因为我用了 VMware 来安装这些而已。不见得所有人都会遇到。
银河麒麟 V10 安装在 VMware 上的时候，显示分辨率默认是 800×600。在这种情况下，无法调整显示分辨率，因为「保存」按钮被挡在屏幕外面了。
解决方法是用 xrandr，例如：
xrandr -s 1440x900_60
最后一个参数是刷新率（60Hz）。有些 Blog 上说这里只能用 xrandr 列出来的选项，但其实未必，只要显示器支持就行。
另外，有些 Blog 上说这种方式只能临时调整，重启后效果就没了。的确如此，可是现在屏幕大了，你就可以用 UI 来正式调整显示分辨率了，不是吗？
1.3. 9090 端口
我们有个服务，默认启动在 9090 端口上。结果等产品要上线到生产环境的时候，运维人员去启动的时候得到了报错，一看才发现 端口被人占了。
问题是我自己之前搭环境测试的时候，没有遇到这种情况。估计因为我的银河麒麟 V10 是「最小化安装」，而客户那边生产环境则没有这样做吧。
2. 达梦（DM8）
总的来说，在 Windows 上安装达梦 8 的过程要顺畅很多，没遇到什么问题。Linux 下就开始有坑。
2.1 ulimit
准备阶段的第一个坑是 ulimit 的问题，之前已经先写了 Blog，这里就只给出链接了《Linux 下修改 ulimit 不能完全生效的问题》。这个坑严格来说不算麒麟也不算达梦的问题，而且不见得所有人都会遇上。
2.2. cdrom
第二个坑是挂载光驱。挂上来之后没有 x 权限，但不知道怎么回事，用 -o exec 也挂不出来 x 权限。最后只好用命令行强制运行解决：
bash DMInstall.bin
接下来的安装倒是没出多大问题。我在 Linux 上安装达梦的目的只是为了抠出里面的 bin、include 和 drivers 目录来，用来制作 Python 和 PHP 的运行环境而已。所以后续运维的踩坑经验我就无法提供提供了。
2.3. Python
我们的 Python 运行环境是用 Conda 搭的，有 2.7 和 3.5 两个版本。按照达梦官方文档的说法（那文档写得不好，链接恕我不放了，自己搜吧），需要安装达梦客户端，然后再编译驱动。照着操作就可以，没什么大坑。
2.3.1. ldconfig
我是从一台安装了达梦客户端的 Linux 机器上把 bin、include、drivers 这三个目录抠了出来，设了一下 LD_LIBRARY_PATH，然后去 Conda 环境里面编译驱动。这样做是没问题。
但是当我把目录放 /etc/ld.conf.d 里面之后，一跑 ldconfig，sshd 直接挂掉了。数个 SSH 会话同时被踢，吓了我一大跳，还以为被黑客入侵了。
好在 tty 登录没有问题，看起来是 OpenSSL 导致了 OpenSSH 不能用了。一看达梦的 bin 目录，libcrypto.so 和 libssl.so 就这样裸躺在里面，服了。最后还是只能用回 LD_LIBRARY_PATH 方案。
2.3.2. 多线程
接下来我们尝试在 Python 环境中登录达梦数据库。有一个小坑：达梦的 dmPython.connect 会开子线程来进行登录。我们的 Python 环境在 Python 解释器跑起来后把 nproc 改成了 0，结果就 CoreDump 了。看过 CoreDump 里面的 CallStack 才明白原因。看起来 C 代码里面的异常捕获，dmPython 完全没有做嘛。抛个 Python 异常也好啊。
2.4. PHP
达梦的文档在这一部分有比较大的问题。
首先，有点语无伦次。无论是 yum 还是源代码编译，都是指的 PHP 的安装方式，但达梦的部分应该都是一样的。然而文档中却说得好像不一样。
其次，版本混乱。安装代码中同时有 7 和 5 的库，显然是更新文档的时候没有更新完整。
最后，其交代的技术细节存在着问题，至少与事实不符。我按照其中列出的 DPI 库准备的环境，PHP 的 PDO_DM 库完全加载不起来。
我想办法得到了一份正确的 so 依赖列表，比达梦文档中给出的要多，多了不少。主要是因为 libdmcalc.so 和 libdmdta.so 导致的。我觉得我直接给出我的 so 库列表并不是一个好主意，毕竟 DM8 的版本肯定也在不时地变化。更有用的是介绍我的方法。
我的方法也很简单：找个编辑器打开达梦的两个 PDO 的 so 库，然后就搜「.so」。ldd 中看得见的，这样能搜到。看不见的，那种用 dl_open 打开的，这样也能搜到。然后顺藤摸瓜就行。貌似 DPI 的那些 so 库都还不会用 dl_open。
当然，将来达梦如果对 so 的内容进行混淆或加密，那我就不敢说这样能行了。希望它不会犯这个蠢。
后面就还好了。我一度担心 OpenSSL 又惹事，但大概是我们的 PHP 环境比较简单，没惹出什么麻烦。我直接把它们塞进了一个 docker 镜像里面，这部分的工作成果总算是被固化了下来。
没有评论:
发表评论