善意提醒

如果您打开本站很慢,布局排版混乱,并且看不到图片,那么可能是因为您还没有掌握用科学的方法上网的本领。

2024-09-29

信创踩坑笔记

图片来自网络

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来正式调整显示分辨率了,不是吗?

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镜像里面,这部分的工作成果总算是被固化了下来。

没有评论:

发表评论