善意提醒

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

2026-07-24

Nube.sh 日本机房与 Vultr LA 之间的 MTU 踩坑与修复小记

昨天偶然之中发现,自己在 Nube.sh 的 Tokyo 可用区购买的 VPS,无法正常访问在 Vultr 上的一台 LA 的 VPS。具体表现为 SSH 端口能通,然而真连接过去的时候,一些操作会中断,无法继续。例如:

  • ls 一个文件多一点的目录,显示到一半就卡住了。
  • vim 编辑文件,必定黑屏,也是卡住,必须关掉 SSH 会话。

我是在 SecureCRT 中通过在 Firewall 中 Select Session 设置了转发,也就是说 SSH 隧道过去的。不清楚直接在命令行上 SSH 过去会如何,但无论如何这个现象都不正常。

这个问题只在这两台 VPS 之间存在,方向倒过来的情况我没试过。感觉跟两者之间的网络状况有一些关系。现在排查这类问题也算简单:直接问 AI,比我自己想要快,也可能更靠谱,至少能得到一些方向性指引。果然,AI 的回答直指问题的核心——MTU。

我的确是在 Nube.sh 的客服群里面见到过有人在反映日本的 VPS 有问题。回头搜了一下(奇怪 Telegram 的搜索功能我记得不太好用来着?),发现今年五月份的时候就有人回答说是 MTU 不够。老板也认可了这个结论,不过后续当客户催促修正时,老板那边没了下文。Nube.sh 的规矩一向是「只认工单」,我估计那个客户没发工单,所以这个事情直到现在应该都还是这个状况。

仅仅是 MTU 的问题的话,是可以自己动手搞定的。AI 同时也提供了方案:

  1. 调整网卡设置,临时或永久地修正。
  2. 调整 iptables 设置,针对性修正。

因为我并没有广泛测试,说不定还有哪些机器和 Nube.sh 日本这台 VPS 之间也有类似问题,所以我就选了方案一,直接改网卡设置了。一劳永逸,至少在我或牛肉老板重置 / 还原 VPS 网络设置前都能有效。

我的操作系统是 Debian 13,修改 /etc/network/interfaces 即可。Nube.sh 在 dhcp 后面加了一句post-up,在它前面再加上一句就行了:

post-up ip link set dev eth0 mtu 1400

实际能正常发送的包的大小,我用 ping 测试了一下,应该是 1448:

ping -c 4 -M do -s 1448 <IP Address>

那也就是说实际上的 MTU 应该是 1448 + 28 = 1476,不过 AI 建议我多留点余量。考虑到也没有太大的副作用,我就按它说的直接设到 1400 了。重启之后查看网卡设置:

ip link show eth0

OK,现在的 MTU 是 1400 了。SSH 恢复正常。完结,撒花。

2026-01-13

Internet 好像也没有那么危险嘛

图片由 Google Gemini 3 Pro + Nano Banana Pro 生成

周日晚上,突然接到公司同事的电话,说我手上有一台服务器「被人攻击」,所以机房要把外网 IP 给黑洞 24 小时。

挂了电话之后,想想不对,那台服务器并非生产环境,平时都是内部自己用,要被攻击也轮不到它。

这台服务器,主要都是运维同事在用,我自己了解不多。去年年中,运维同事辞职,我更是早已不负责相关业务。这台服务器有点「三不管」的感觉:登记簿上还挂在我名下,最近没什么空去推进蛮复杂的交接工作,所以还没轮到它;实际管理者没什么能力进行管理,主观意愿上也不想去管;它暂时也没什么多大用处,几乎算是「闲置」状态。

然而,我总觉得自己对它还有「责任」,于是走跳板机从内网连上去又看了看。这一看就让我冒冷汗了。上面居然有个 squid,而且貌似是「向全世界开放」的状态。让 Google Gemini 帮忙统计了一下 access.log,发现晚上出事前一分钟就产生了 3GB 的流量,峰值可能确实把机房设定的阈值给顶破了。所以这应该就是直接原因了。

可是,我不记得自己有在这台机器上搭过 squid,也不记得运维同事搭过。他是个谨慎的人,应该不至于干出这种事情。那是谁干的?

再仔细看,简直大汗淋漓了。还有一个未能投入工作的 OpenVPN,以及一个名叫 proxy 的账号,gid 是 0。完了。什么时候被黑的?!

这个 proxy 账号看起来是 2021 年创建的。日志已经灭失了一大半。我只能根据仅有的一点线索,去拼凑还原当时的情况。

「黑客」看来轻车熟路,一上来就登录了 root 账号,随后创建 proxy,设置 sudo,然后就去安装 squid。

但接下来的情况让我迷惑不解。他光是开防火墙 3128 端口就折腾了半天,安装 squid 时也一时输错成了 apt-get(这台服务器是 CentOS)。装完 squid 设了 allowed_ips,但 conf 中却大手一挥设成 allow all 就走了,OpenVPN 也是安装了一半就放弃了。前面半截太过顺利,后面半截却画风一转,这不对劲。

我们用的密码都是 64 位随机字符串,SSH 端口也开在非标准端口上。如果这台服务器这么容易被攻破,那么我们剩下的服务器也是凶多吉少。剩下的时间,我都在审查和反省所有可能的入侵路径。还是想不明白,当时到底什么情况?最后凌晨两点钟,实在熬不住,洗澡睡觉去了。


第二天到了公司,我按计划去翻邮件,看看有没有可能出事前是弱密码,后来才改成的强密码。结果这一翻,就发现了「真凶」,也算是一场乌龙。

2021 年的时候,当时老板找我要了一台服务器的 root 权限,说是他儿子要用。
他儿子当时参与了我们的一些项目,也算是「实习」吧,后来去英国读书去了。要这台服务器,是说方便参与维护,当时公司里面还真没人来维护那些东西,所以我也就把这台不太重要的服务器给他了。看起来,当天他儿子拿到 root 密码,接着就动手了。

大学生嘛,做事情没顾那么多,也是可以理解的。谁还不知道自己大一的时候是个什么样子呢?估计他当时折腾完以后用过一阵子,然后就把这事给忘了。现在他早已毕业,无论是在当地工作或回国发展,总之应该也用不上这个东西了。这代理就这样一直开放在 Internet 上,不知道有没有人发现,估计没有。虽然日志有限,但看起来 2025 年一整年都没人用过,直到这个周日。大概总算被什么人给扫描到了吧。

这事说起来就是个内部管理问题。这种事情,就算放在现在,我感觉也没法拒绝。老板自己也大概把这事给忘了。只能是吃一堑长一智吧,以后「出借」的东西要加强审计。以及不要认为别人都会好好善后。哪怕他真的会,但有时候也会偷懒啊。

话说回来,貌似 Internet 好像也没有那么危险嘛?一个完全开放的 HTTP 代理,3128 端口也是知名端口,居然存在了快五年才被人第一次发现。或许现在 ProxyHunter 已经没人用了,但是我国政府的扫描器不是一直在巡天么?GFW 果真对外不对内?所以啊,世界还真的是一个大草台班子吗?

2025-08-16

Debian 升级 trixie 踩坑记

图片来自网络

Debian 前不久刚刚发布了 Debian 13,也就是代号为 trixie 的版本。本周一上班后,从 Repo 的变更看到了这个消息,我就进行了升级。

之前已经把我的所有 Debian 环境统一到 bookworm 了,也是不久前的事情。当时 Stretch 和 Buster 已经停止维护了,Bulleyes 还是 oldstable 状态。我只有两个环境是 bookworm,于是一咬牙把所有的环境都升级到了 bookworm,也踩了一些坑,下面合在一起说。这次确实没想到来 trixie 得这么快,也这么巧,趁上次坑里的屎还是热乎的,也就再咬一回牙了,反正我的牙也不是自己的。

简化的正常升级流程

首先强调一点,升级不要跳版本,从低往高一级一级地升。每次升级解决这一次的问题,然后再往下走。我这次是从 bookworm 往 trixie 升,只需要升级一次。如果是 jessie,那么就要 stretch -> buster -> bulleyes -> bookworm -> trixie,以此类推。
历史版本代码参见官方说法,最好是看 英文版,更新最及时。

升级过程完整的指引,最好参见 Debian官方文档(有 中文版,但翻译得很不好,很多没翻。还是看英文版吧,Google 翻译或喂 AI 都行。拜托了,都 2025 年了)。但如果要简单说的话,要点只有以下这些:

  1. 先把当前版本升级到没法再升。
  2. apt update
    apt upgrade
    
  3. 去 /etc/apt/sources.list 里面,把版本代号改掉。去 /etc/apt/sources.list.d 下面,把文件里面的版本代号都改掉。
    这一步原则上可以用 shell 命令来做,但其实还有 non-free-firmware 之类的小点,依赖别人的脚本并不是好事情,所以我也就不贴了。我觉得还是讲个原则,手动操作吧。必要的时候去参考已有的新版 OS。
  4. 正式开始升级:
  5. apt update
    apt full-upgrade
    
  6. 对选项作出反应:
    1. 升级过程中要不要重启服务,可以选 yes。
    2. 要不要覆盖旧版配置文件,自己看吧。如果不记得以前改了哪些就建议选N了(特别是针对 sshd),建议还是自己「合并」看看。
  7. 如果升级顺利,重启。
  8. reboot
    
  9. 清掉不再需要的包。
  10. apt autoremove
    

坑一:升级过程中 ssh 连接中断了

是我自己的锅。正在升级的时候,来了同事问我问题,作了一番长篇演说以后,忘记了这事,去忙别的了。回头想起来时,发现 ssh 已经断了。

ssh 断之前应该是在 apt full-upgrade 的过程中,等我回答某个配置文件如何处置。赶紧再连上,apt full-upgrade 继续,发现被锁。
遵照提示:

dpkg --configure -a

得以继续。
随后提醒自己下次记得集中注意力。

坑二:sysctl

升级完后发现有些不对,检查了一下,发现 /etc/sysctl.conf 配置文件被 dpkg 给备份起来了,后缀是 dpkg-bak。

改名回来后 sysctl -p,以为解决问题。重启之后发现 BBR 还是没能启用。翻找资料,发现是 机制改了。现在得把这些配置写到 /etc/sysctl.d/ 下面去,自己建 conf 文件。

当然,这样也有好处。现在可以把不同的内容分别写在不同的配置文件里面,不用像以前那样全部放在 sysctl.conf 里面,找起来比较麻烦了。

另外,记得用 sysctl --system 而不是 sysctl -p 来进行参数的临时加载。机制不一样了。

坑三:haproxy 启动不起来

算是一个小坑,因为报错信息在日志中写明白了。
我的 haproxy 是早期版本安装的,需要在 haproxy.cfg 中把 ulimit-n 设为 524288。

global
        ulimit-n  524288

坑四:其它软件还没提供 trixie 源

我周一把 Debian 升级到 trixie 的时候,顺手把 Nginx / PHP / Redis 在 /etc/apt/sources.list.d 下面的 Repo 也给改了。然后就发现 PHP 已经有了 trixie 源,但 Nginx 还是 404,Redis 是 403。

截止本文首次刊发的时候,Nginx 已经 OK 了 ,Redis 还没好。后来直到过完十一长假,我发现redis 有更新,再去看,才发现也提供 trixie 源了。

还有一个问题是 simple-obfs 在 trixie 官方源中没有提供,而 bookworm 是提供的。git 然后源代码编译是一个解决方法。如果还是想从 apt 直接安装省些事情,请在 bookworm 的时期先完成 simple-obfs 的安装,或者临时改成 bookworm 的源。

坑五:GFW 捣什么乱

这个就坑我大发了,几乎可以专门写一篇。不过我还没完全弄明白,以后搞清楚了再说吧。

我家里的网络访问 Debian 官方源不算快(应该说很慢),我又不想改源,于是用了 SS 代理来「加速」。
apt update 的时候发现,Debian 源没问题,但 Nginx 和 PHP 一直连接超时。区别就在于,Debian 源是 http,后二者是 https。
用 curl -x -I 简单试了一下,https 还真是走不了 SS 代理。http 就可以。

如果答案是「GFW 检测并干扰了 TLS over SS」,那我没话说。我知道它有这能力,TLS 的确特征明显,尤其是握手时。这可能也是最合理的一种解释了。
但我 HTPC 上有一台 VM 使用自己的 ss-local 是 OK 的。如何解释?同样的 OS 版本,同样的 SS 版本,同样的网络环境、节点、线路、协议、密钥、插件,同样的 payload 和访问特征,连 TTL 和 MTU 我都看了,实在是想不明白。

有问题的 VM 只是说 TLS 握手出问题的概率很高,但并非 100%。我开了 Verbose 猫在两端看了一下,发现有问题的时候貌似有 replay attack。我拿不准,但看起来像。两端的节点都换过,没有什么差别,该 replay 还 replay。

在公司没问题,在家里有两台都有问题,可见应该跟家里接入的上海电信宽带有关。然而家里 HTPC 上从 Windows 去用那两台上的 ss-local / privoxy 作代理都没有问题,在我遇到问题的时候,儿子还在欢看 YouTube 呢,线路没被封。SS 是 AEAD 版本,cipher 不对时的反应是 No Data Transfer,GFW 肯定拿不准。

那台没问题的 VM 就是不会引发,100% 地 OK,让我始终想不通的终归还是这一点。在 SS 上面再叠一层 tor,也是 OK 的。最后不得已,我让 apt 走了 tor。没去试 SS over FRP 的方式。先这样吧,也没慢多少就是了。

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

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

2024-09-14

Linux 下修改 ulimit 不能完全生效的问题

前言:本文只打算作为「技术笔记」来写,对关键的要点进行一下点拨就完事,没想写成教程。或许能让熟手解决麻烦,如果是新手的话,最好是先有相关的基础知识和经验。当然,直接喂给AI,让它嚼过再给你慢慢解释,可能也是一个办法。

这些天还是在折腾信创的事情。安装了银河麒麟 V10 SP2 的一个默认设置的版本,带了可视化界面,准备用于安装「达梦」。
达梦的安装手册写得有一些问题,缺了一些要点,不过对于有一定经验的人而言,还算能解决。手册中有一个要求,就是要把 ulimit 里面的 open files 数量调大。原始的 1024,看起来不太够用。

图片来自网络

对 Linux 特别是 CentOS7 熟悉的人,应该反应过来了。不要直接改 ulimit,应该去改 /etc/security/limits.conf:

* soft nofile 65535
* hard nofile 65535

改完之后,重新登录的账号就已经是新的 open files 上限了。简单重启一下就应该万事 OK 了。

可是,不,没有那么简单!(莫名其妙的英式中文)


在我看来,改完重启以后,对于非 root 用户似乎完全没有效果。
root 账号好像真的是 OK 了。但达梦的安装手册提到需要创建专用的 dmdba 账号用于 DBMS 的安装。我在可视化界面登录 dmdba 账号后,打开「终端」窗口,ulimit 还是 1024。

测试下来,发现:

  • ssh 上来的 session 有效果;
  • su 切换过去的账号有效果。

这说明对 /etc/security/limits.conf 的修改还是有效果的,只是不知道为什么在某些场合下不能生效。
百思不得其解。最后找到这篇 Blog,是博客园的。标题起得有点不好找:《systemd service 设置 limit,不生效问题》。它引用的原文的 URL 已经失效了,所以我还是得把要点直接再说一下。简单来说就是:

  1. 要修改用 systemctl 启动的服务的 ulimit,需要修改 /etc/systemd/system.conf
  2. 要修改从可视化界面登录的用户的 ulimit,需要修改 /etc/systemd/user.conf

实际上的情况比这个要复杂一些。第二点不是原文中的描述,是我自己试出来的。我目前也无意去成为一个 Linux 或银河麒麟方面的专家,所以就暂时不作更多的探索了。

另外,修改了 /etc/systemd/system.conf 以后,需要先重启 systemd:

systemctl daemon-reexec

然后用 systemctl 启动/重新启动的服务,才能用上新的 ulimit 设置。
毕竟咱们改的是 systemd 的配置文件,对吧。

2024-09-09

编译自己的 CentOS7 OpenSSL 1.0.2u 动态链接库

图片由 Google Gemini 生成

因为老板想从「信创」分一杯羹,于是我们现在需要把一个 CentOS7 上面跑着的系统,移植到「银河麒麟」上去运行。

对于「国产」操作系统了解不多,不敢妄自确定方案。先去 下载 了银河麒麟的数个版本,主要都是服务器操作系统 V10,包括 SP2 的「CentOS 兼容版」,海光版,以及 SP3 2303 以及 2403 的海光版本。考虑到海光 CPU 也是 x86 架构,理论上应该可以跑在普通的 Intel / AMD CPU 的机器上,实际测试下来也是如此。

不得不说,我一开始对于情况设想得比现状要严峻一些。实在是没有想到银河麒麟 V10 对于 CentOS 抄得如此彻底,怪我太高看了国人的本领。无论是「CentOS 兼容版」还是海光版,我们在 CentOS7 上编译的东西,基本上拿上去就可以直接跑。
当然,从好处想,这样做的确提升了这些「国产」操作系统的兼容性,极大拓展了生态链。一定程度上也算是利国利民的好事情。除了钱以外的事情,我也就不吐槽了。

之所以说是「基本上」可以直接跑,是因为银河麒麟 V10 大概是从 CentOS8 开始「魔改」的,所以上面搭载的 OpenSSL 是 1.1.1 版本。有一些是 1.1.1c,有一些是 1.1.1f,总之不是 CentOS7 的 1.0.2。用 yum list 看了一下,源里面也只有 1.1.1 的版本可供安装。

我们的程序是在 CentOS7 上编译出来的,用了 so 版本的 OpenSSL 1.0.2,所以缺了这个东西还没法运行。尽管我们可以把自己的代码改成去链接 OpenSSL 1.1.1,或者索性静态链接进去,但还有些第三方厂商提供的库也是基于 OpenSSL 1.0.2 的,而且不算少。总之这个问题是绕不开的,只能迎头而上去解决它。
另外,我们发现那个「CentOS 兼容版」的默认安装会在 /lib64 下面形成 OpenSSL 1.0.2o 的库。yum list 里面还是没有,说明应该是某个软件包自行装上的。既然那个软件包可以这样做,我们也可以。把自己编译的 OpenSSL 1.0.2 的库放进系统里面去,然后 ldconfig 就好。

以上交代了背景,接下来就说说看具体怎么做,以及介绍一下踩过的坑。


编译 OpenSSL 很简单,从 OpenSSL官网 上下载 1.0.2u的tar.gz包(最后一个版本,1.0.2 已经停止维护了),解压以后编译:

wget https://openssl.org/source/old/1.0.2/openssl-1.0.2u.tar.gz
tar -xvzf openssl-1.0.2u.tar.gz
cd openssl-1.0.2u
./config --prefix=/usr/local/openssl-1.0.2u --openssldir=/usr/local/openssl-1.0.2u shared
make
make install

以上的操作,随处都可以搜到,AI 也能提供。不过编译出来的 openssl 动态链接库,有两个问题:

  1. 拿这两个编译出来的 so 库去用,会报「no version information available」。事实上 ldd 的时候就会报这个错。
  2. 编译出来的文件名是 libcrypto.so.1.0.0 和 libssl.so.1.0.0,而不是我想要的 libcrypto.so.1.0.2u 和 libssl.so.1.0.2u。

前者问题大一些,后者往小了说只是自己看着顺不顺眼的问题。一个一个解决吧。

问题1

拿着「no version information available」去搜,得到的信息不太具有参考价值。问 AI 也一样。
大多数的回答是说错用了别的操作系统编译的 OpenSSL 库,可能很多人遇到的情况也的确是这个,但显然我们遇到的情况并不是。

唯一找到 一篇相关文章,跟着评论找到了知乎上的 一篇文章。作者是想自己编译 1.0.2u 的库,替换掉 CentOS7 上的 1.0.2k 的版本。
顺带说一句:以前 CentOS7 还在维护,即使是 1.0.2k 的库,CentOS 也会补上安全漏洞。现在 CentOS7 不维护了,或许将有必要这样去做。但 1.0.2u 也已经是 2019 年发布的版本,换句话说,OpenSSL 1.0.2 在更早的时间就停止维护了。所以原文作者这样去做可能也没有什么意义。

该文作者的思路和实际操作都没有什么问题,尊重他人的劳动成果,我就不原样贴一遍了。需要的朋友可以根据上面的链接自己去看。虽然原文不知道为什么贴了 Markdown 的内容,在知乎上看不出样式,至少 PC Web 版上看不出,但内容总归能看懂。
我遇到的坑是:按照该文操作的「1.4」步骤得到的函数名称中有「@库名」的内容,例如:

sk_find@libcrypto.so.10;
sk_set@libcrypto.so.10;
asn1_add_error@libcrypto.so.10;
……

对于 Version Script,这是不可接受的写法。我的处理方法是把这里面的「@libcrypto.so.10」直接删掉了。原文假设所有的函数都是「@@」形式的默认导出,而不是「@」一个符号,这个假设是不对的。
这里是我从 CentOS7 中的 OpenSSL 1.0.2k 提取出来的 Version Script,既然 CentOS7 和 OpenSSL 1.0.2u 都已经停止维护,那这个文件应该算是 Stable 了。可以 点此下载

把下载得到的 version.map 放在解压生成的 openssl-1.0.2u 目录下。随后,./config 的时候换成下面这句:

./config --prefix=/usr/local/openssl-1.0.2 --openssldir=/usr/local/openssl-1.0.2 shared -Wl,--version-script=/root/openssl-1.0.2u/version.map -Wl,-Bsymbolic-functions zlib-dynamic

最重要的参数就是 -Wl,--version-script=version.map 这句。再编译生成的 so 库就不会被报「no version information available」了。而且这里似乎必须得写绝对路径。

问题2

直接改文件名是不行的。因为文件里面有 SONAME。做符号链接以及 ldconfig 的时候都会原形毕露。我们需要把文件内部的 SONAME 也一起改掉才行。

据说在编译前手动调整一些文件也可以解决这个问题。不过我是选择在编译之后用 patchelf 来解决这个问题的。为此当然首先要安装 patchelf:

yum -y install patchelf

然后就开始改文件了:

patchelf --set-soname libssl.so.1.0.2u libssl.so.1.0.0
patchelf --set-soname libcrypto.so.1.0.2u libcrypto.so.1.0.0
mv libssl.so.1.0.0 libssl.so.1.0.2u
mv libcrypto.so.1.0.0 libcrypto.so.1.0.2u
patchelf --replace-needed libcrypto.so.1.0.0 libcrypto.so.1.0.2u libssl.so.1.0.2u

最后一句也是必须的,因为 libssl.so 会引用 libcrypto.so。

2024-06-18

Proxmox VE 更新出了问题

图片来自网络

在公司用 Proxmox VE 搭了一个「超融合」环境,开了一些 VPS 给同事用。因为没打算花钱,所以一直用的 未订阅方式 进行更新。

今天跑 apt dist-upgrade 的时候,遇到一大串内容:

root@pve:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  proxmox-kernel-6.8.4-3-pve-signed
Use 'apt autoremove' to remove it.
The following packages will be REMOVED:
  proxmox-ve pve-manager
The following packages have been kept back:
  pve-container
The following packages will be upgraded:
  libpve-cluster-api-perl libpve-cluster-perl libpve-notify-perl libpve-rs-perl
4 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.

我也没有细看,一个回车按下去,报了一些错:

Do you want to continue? [Y/n] y
W: (pve-apt-hook) !! WARNING !!
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
W: (pve-apt-hook) 
W: (pve-apt-hook) If you really want to permanently remove 'proxmox-ve' from your system, run the following command
W: (pve-apt-hook)    touch '/please-remove-proxmox-ve'
W: (pve-apt-hook) run apt purge proxmox-ve to remove the meta-package
W: (pve-apt-hook) and repeat your apt invocation.
W: (pve-apt-hook) 
W: (pve-apt-hook) If you are unsure why 'proxmox-ve' would be removed, please verify
W: (pve-apt-hook)    - your APT repository settings
W: (pve-apt-hook)    - that you are using 'apt full-upgrade' to upgrade your system
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running script /usr/share/proxmox-ve/pve-apt-hook

我这个笨蛋还是没有细想,按照提示操作了,随后重启了这台宿主机。
然后上面的 VPS 就启动不起来了。既没有自动启动,也无法打开 Web 控制台进行操作。netstat 一看,HTTP 端口监听没有了。

心里慌了,连忙上网搜,才发现 好多人都在叫唤。只不过我是其中心比较大,真的操作了的那个白痴。更多人是在报错那步停下来了。

这下怎么办呢?翻了下日志,看到 proxmox-ve 和 pve-manager 被 remove 了。我想把 proxmox-ve 给装回来,又有报错,看来不行:

root@pve:~# apt install proxmox-ve
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstablebr distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  pve-container : Depends: proxmox-backup-client (>= 3.2.5-1) but 3.2.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.

还好,讨论帖 里面有人给出了抢救措施:

apt install pve-manager=8.2.3

操作以后,Web 控制台出现了。我进去启动了 VPS,用起来没有什么问题。
先这样吧,接下来就是等官方消息了。
我们应该都是没花钱的用户,也许官方不一定会有修正?

-- 更新于 2024.06.19:

官方已经为未订阅 apt 源 修正了这个问题

2017-12-27

Linux 关机权限的特殊情况

很多 Linux 教程都说 shutdown / reboot 需要 root 权限。其实这不是完全正确的。

正常想来没错:shutdown / reboot 如果可以不用 root 权限那还了得?然而其实至少在 RHEL 7.2 上并不绝对是这样子。当出现以下的特殊情况时:
  1. 是当前唯一登录的用户;
  2. 直接调用 reboot,或 shutdown 带了 now 参数;
  3. 登录会话来自本地物理终端。
同时满足以上所有条件的话,就可以无需 root 权限以任何用户的身份关机或重启服务器。

我用 RHEL 7.2 默认安装的「基础设施服务器」进行的测试。Debian 9 没有这个问题。我想这样的做法大概思路是:「如果你都摸到物理服务器边上,急着要马上关机,并且我认为这不会影响到其他人,那么当然可以让你关机,因为就算不让你关机你也可以拔电源线对吧?」

当然,这种想法应该没有考虑到服务器上运行爬虫之类的情况。我没有做更多测试,也许如果有一个别人的 daemon 进程就会使得结果不一样。不过我想这个事情可以提醒我们的是:Linux 的事情不要想当然,也不要网上说什么都信。不要把一切都交给系统默认安全性设置,对于普通用户还是乖乖地把权限控制严格点比较好。

2007-06-23

玩不起 Linux 了

想玩玩 RedHat Linux FC5,家里做好的虚拟机没有带,于是自己用带的盘重新安装了一个。装好了才发现该死的腾讯把 eva 给屏蔽了。正在不爽中,安装内核源代码在编译的时候居然告诉我硬盘用光了。我可是一咬牙给的 8GB 硬盘啊!玩不起玩不起!删了,留着下一台电脑装双操用吧。

算了,只能自己装台 7.3 练练开发了。

2006-12-16

日记2006.12.15

Chapter One

查 Google 解决了 FC5 源码的问题,其实还是小问题,但是确实不是我造成的。

于是,把 QQ 和 HTTP 的任务都移到了 Linux 下,从而检查出来了我的 Blog 在 FireFox 上有问题的地方。看来就算是 utf-8,在不同平台上也是有区别的。

Chapter Two

讲 WAP 开发的那本书基本看完了。内容比较旧,不过就是旧,才有参考价值,毕竟新旧手机的 WAP 能力差别很大的,而新机的文档或实验环境都很容易找到。

打算用扫描仪把其中有保留价值的一部分页面扫进电脑保存,然后尽快去还掉借下一本。书和资金都一样,周转快点有好处。安装了 Acrobat,用黑白色扫描,一页才只用 20KB 左右,比我想象的还省。

Chapter Three

火箭又输了,尽管姚拿下了不错的数据,还命中一个貌似关键球。但他紧接着就又投失了一个,然后被小胖投中一记三分绝杀。

中国男篮又赢了,不过打得真是恶心。

2006-12-15

日记2006.12.14

Chapter One

档案总算到重庆了。

要去把托管合同拿回来,接下来就是上社保,然后把这三年的钱给补上。

Chapter Two

狠狠地「洗心革面」了一下。洗了头,刮了胡子。拿洗面奶好好洗了把脸——死皮和黑头又多起来,重庆的环境真是不行。家里水压不行,这一点真是头疼。

吹干了头,抹上啫喱水,嘿嘿,形象还是不错的嘛。……我闪先!

Chapter Three

下午加晚上都在 VMWare 上安装 RedHat Linux FC5。在 Linux 下搞了近两年的开发,然而对于 GNOME 和 KDE 这些图形操作界面来说,我还是菜鸟。

装了第一次,发现 FC5 没有带内核源码。安装第二次的时候,发现安装选项中根本没有它。查了资料发现真的没有带,安装盘上就没有。第一次用了 GNOME 做桌面,第二次换了 KDE,不过安装之后重启时字体读取出错。相比之下我还是喜欢 KDE,于是又安装了第三次。

本来想用 LumaQQ,但因为需要 GTK,于是找了个 KDE 下的 QQ 客户端——EVA。不错,模拟得挺像的,考虑以后桌面换在 Linux 上了。

Chapter Four

从 FTP 上下了 FC6,明天有时间的话来试试。VMWare 就是折腾起来好用,嘿嘿。

2006-12-14

日记2006.12.13

Chapter One

意料之外,又意料之中。都怪周公!四次啊!

Chapter Two

和爸妈一起去图书馆。他们把我的卡都借了他们的书。今天还掉了,我又去找了三本。一本 WAP,一本讲 S60 开发的,一本讲 Linux 下的开发,都是我比较感兴趣又比较需要找本书系统看看的内容。

图书馆要搬迁了,据说春节之后就只还不借了,倒正好应了我的日程。

Chapter Three

把 Linux 开发的书快速翻了一遍,大致知道了讲的内容。

新书到手,老是想一口气看完。即使是不可能那么快啃完的专业书,也力争要在第一时间观其大略。这是我从小以来养成的习惯。起码,到期要还书的时候,不会因为还没看过而空留遗憾。

讲的内容大致我都需要,但又都讲得不够深入,看来真的是「师傅领进门,修行靠个人」了。或许对某些章节看过之后,应该再去借新的了。

Chapter Four

火箭输给了湖人,还好早上没有起来看 PPMate 的直播,不然会更郁闷。

2006-08-24

Linux 上 FTP 客户端实现自动登录

这是在制作服务器虚拟主机自动备份脚本的时候遇到的一个小插曲。

原本想使用输入重定向简单实现 FTP 客户端自动登录的,因此制作了一个文本文件进行实验:

a.txt

open www.某某.com
aaa
bbb
ls
exit

其中,aaa 和 bbb 分别是 FTP 的用户名和密码。没想到在 ftp < a.txt 的时候,仍然让我输密码。看来输入密码的地方无法使用输入重定向来实现,得考虑另外的办法了。

翻阅 ftp 命令的在线帮助,发现它有 auto-login 功能。办法是在本用户(本例中是 root)的用户根目录(如本例中 root 用户就是 /root)下建立一个名为 .netrc 的文件,注意这个.可不能省。然后,在它里面存放一张 FTP 帐户列表,简单格式如:

machine www.某某.com login aaa password bbb
……(可以多行)

然后再直接 ftp www.某某.com,就会发现 ftp 客户端直接以 .netrc 中设定的 aaa 用户名和 bbb 密码进行登录了。当然,系统在使用这张自动登录列表的时候,会根据 FTP 站点的名称进行核对的。如果没有发现指定的站点名,那么也不会应用这个自动登录功能的。

服务器虚拟主机自动备份功能

自己写了个脚本,来实现对我服务器上 PHP + MySQL 虚拟主机的自动备份。虽然目前只有我一个人在使用,但是即使这样,我也不希望数据因为意外事故损坏掉。

备份的原理,就是把 Apache 和 MySQL 先停掉,然后用 tar 打包 HTML 目录和 MySQL 的数据库目录,恢复 MySQL 和 Apache 服务之后,再慢慢通过 FTP 客户端传到我的一台远程FTP服务器上(其实是我在网上买的一个虚拟主机空间)。

备份周期完全由自己决定,我目前把它丢在 /etc/cron.weekly 下面让它每周运行一次。备份的文件会以备份日期自动命名。以后等我有了比较大的FTP空间之后,我就设置为按日备份。再在自己工作站上做一个按周归档,那就万无一失了。

脚本文件如下(隐去部分敏感信息):

#!/bin/sh
HOME=/root
# Stop the services
/etc/init.d/httpd stop
/etc/init.d/mysqld stop
# Tar the html bag
cd /var/www
tar -czf /tmp/html.tar.gz html
# Tar the mysql/data bag
cd /usr/local/mysql
tar -czf /tmp/mysql_data.tar.gz data
# Start the services
/etc/init.d/mysqld start
/etc/init.d/httpd start
# Build the ftp script
DATESTRING=$(date +%Y%m%d)
echo "open www.某某.com" > /tmp/ftp_$DATESTRING.txt
echo "put /tmp/html.tar.gz /wwwroot/vhostdatabackup/html_$DATESTRING.tar.gz" >> /tmp/ftp_$DATESTRING.txt
echo "put /tmp/mysql_data.tar.gz /wwwroot/vhostdatabackup/mysql_data_$DATESTRING.tar.gz" >> /tmp/ftp_$DATESTRING.txt
echo "exit" >> /tmp/ftp_$DATESTRING.txt
# Connect the backup FTP site and upload these files
ftp < /tmp/ftp_$DATESTRING.txt
# Clean temp files
rm -f /tmp/ftp_$DATESTRING.txt
rm -f /tmp/html.tar.gz
rm -f /tmp/mysql_data.tar.gz

增补于 2006-09-10

如果想在 cron 中运行,在脚本中 FTP 登录之前还要加上 HOME=/root,否则无法实现自动登录。原因……是 crond 运行脚本时的环境变量太过「干净」了。

2006-07-30

站点再次转移

这是一条很旧的 Blog,导入自以前的 Drupal5 站点,讲述的事情与现在 Blogger 上的站点无关。

之前将博客站点的操作系统升级到 Red Hat Enterprise Linux AS 4.0 Update 3,冒着使用盗版的风险不说(好像还没过 30 天的评估期,嘿嘿),带来了什么好处?没有明显地感觉到,却因为 2.6 的内核导致了系统时钟不准,还自己写了个校时工具来辅助。系统的运行空间也涨到了接近 3 个 G。在这次橙色警报下作备份时,就明显感到了不方便。

因此启用了以前装好的一台备用的 Red Hat Linux 7.3 的服务器,升级了 libpng 和 PHP,并装上了 Zend Optimizer,配好了 Sendmail 服务,然后把博客站点转移到了这个服务器上。同时还意外地发现以前的服务器上 Sendmail 早就出问题了,因此有一封 xset 的注册邮件迟迟没有发出去。我手动发送了注册邮件,希望他能够收到,从日志看应该发送成功了。

现在的系统减肥 1G,做全备方便多了。我打算以后每周至少做一次数据库和 Web 的备份,这样一旦挂掉损失也不会太大。根据目前的状况,这两个内容备一次的损耗应该在 10M 以内,如果我把 drupal 里面那些没有用上的主题给删掉,应该还会小不少。

2006-07-19

RedHat Linux 7.3 下编译 libxml2 2.6.24 遇到的问题和解决方法

单位的测试服务器是很早以前装的 RedHat Linux 7.3。说是「测试服务器」,但由于种种原因,在上面已经跑了很多应用,再也离不开了,所以也没有办法把操作系统更新成比较新的版本。

大概是昨天或今天早上的某个时候,这台机器被人重启了(或者是自己重启了),然后就死在了启动过程中。下午有人找我报告,才发现这个情况。再次重启之后,机器是没有问题了,但是又再一次体验了那满屏幕的问号。——老毛病了,每次自动启动的时候 Apache + PHP 的应用访问 Oracle 得到的多字节字符编码总是不对,重启一次 Apache 就好了。一直不知道是什么原因。
心念一动,正好趁这个机会把这台服务器上的 Apache + PHP + MySQL,以及周边的那些,如 OpenSSL、libpng、libiconv 等等,给重新整理一遍,应用上最新(或者说可用的最新)版本。

OpenSSL、libiconv + gettext、libjpeg、libpng……,都很顺利。原本以为这些版本很新的东西会在不完全符合 ANSI C++ 规范的 2.96 版 GCC 编译器上出问题,没想到居然一路绿灯。不过,好景不长,在 libxml2-2.6.24 上卡住了。
错误信息包含下面几句:

……
xmlIO.c: In function `xmlCheckFilename':
xmlIO.c:619: syntax error before `struct'
xmlIO.c:621: `stat_buffer' undeclared (first use in this function)
……

这种语法错误,不像是编译器版本的问题。我先试着跳过这一步,继续下面的安装。不过在编译 PHP 5.1.4 的时候,configure 报告说需要 libxml2 的 2.6.11 以上版本,而我这台机器上以前的 libxml2 的版本只是 2.6.7。显然,这个问题是无法回避了。

拿错误信息去查,只有 FreeBSD 的技术支持站点上有一条 bug 报告的记录。不过可喜的是,报告中也附上了修正方法。经测试,该方法对于我的 RedHat Linux 7.3 也同样有效。
以下转自该文:

Fix:
*** xmlIO.c.DIST Sat Apr 29 09:44:16 2006
--- xmlIO.c Sat Apr 29 09:44:35 2006
***************
*** 616,621 ****
--- 616,622 ----
}
#else
#ifdef HAVE_STAT
+ {
struct stat stat_buffer;
if (stat(path, &stat_buffer) == -1)
***************
*** 625,630 ****
--- 626,632 ----
if (S_ISDIR(stat_buffer.st_mode))
return 2;
#endif /* S_ISDIR */
+ }
#endif /* HAVE_STAT *
#endif /* WIN32 */

想要修复这个错误的朋友,若看不懂上面的意思,就注意那两行标了加号的地方。原来的 xmlIO.c,是没有这两行的,找到它们的位置后把它们补上,就可以通过编译了。行号人家也标出来了,在原 xmlIO.c 文件的 616~621 行附近。
若看到这里还不明白,那就只好委屈了……

2006-06-30

不同版本 GCC 编译器的差异真是让人吃惊

做了一个程序,测试用的,在一台 RHEL AS 4.0 的机器上做编译。编译完之后瞄了一眼文件大小,1837684。吓了一跳,因为我记得以前类似程序都在 2M 以上的,怎么这次小了这么多?难道我漏了几个模块?

去正式服务器上找程序一对,果然,大小差了不少。正式服务器上的程序是在一台 RH 7.3 的机器上编译的。为了验证到底是源代码有不同还是编译器的差别,我把刚才编译的代码上传了一份到 RH 7.3 的机器上,用同一个 Makefile 编译,编译完的大小是 2617012。

对比了一下两边编译器的版本,RH 7.3 这一台是 2.96,RHEL AS 4.0 那台是 3.4.3。版本差别的确比较大,但编译的结果差别也真的不小。除开链接的库,单单看这个程序的 .o 文件,大小竟然差了一倍多。以前没有在这方面比较过,确实有点惊人。

我又去找来了 upx,2.00 for linux i386 版本。用默认选项压缩的结果,更令我吃了一惊。RHEL AS 4.0 这台上,压缩之后的大小是 535802,而 RH 7.3 那台上的较大的那个执行程序,压缩之后只有 384610,反而拥有较大的压缩比和较小的压缩后尺寸。

不好解释了,也许是 2.96 的编译器生成的代码中,垃圾比较多,而有用的部分反而比较少吧。和内核的系统调用也许也有关系吧?两台机器的内核差别也挺大的,一个是 2.4 一个是 2.6。

记录下这个情况,以供参考。

2006-04-21

日记2006.04.21

终于捱到了盼望已久的周五,正常了大半天,却在快下班的时候一下子忙了起来。

策划人员提交了一份业务需求,还要求说 28 日 24 时前必须开发完成。她一贯这语气,我也就不计较了,反正时间也还充裕。不过,文档里面漏洞一大堆,我只好把她叫过来,几乎是耳提面命了。改过之后的文档还是漏洞一大堆。无奈已经到了下班时间,我连她的影子都没有抓得到,只好放在周一再教训了。

电信在网站上发了一则公告。我们的 SMGP 3.0 升级测试安排在 5 月 12 日下午进行。14:30 至 17:30,只有短短的三个小时。不用说,事先肯定得自己测试好了。又是还好,还有差不多两周多的时间。和同事合计合计,完成升级测试应该是没有太大的问题。

整备服务器遇到了一定的困难。Oracle 死都装不上,关键性的文件被我丢在家里了,利用现有的资源无论如何也搞不定,只有等下周带盘过来了。我心一横,干脆趁这个机会把整个数据库系统升级了,反正目前也没有应用系统用到它。眼下最新、最合适的版本,是 Oracle 10g Release 2 for Linux x86-64,好像只有它能更好的发挥支持 EM64T 的新 XEON 的性能吧。可惜 Oracle 的网站在公司访问起来非常慢,一直到了快走的时候,才勉强注册好帐号。至于操作系统,我也打算升级到 Red Hat Enterprise Linux AS 4.0 Update 3 x86-64 的版本,来全面发挥硬件的性能。这个盘倒是很顺利就在 TLF 网站上找到了 BT 的下载种子。5CD,不小啊!传回家里的服务器上,开始下载。

晚上干姐打来电话,又叫我过去吃晚饭。昨天就在她家吃的,可把我撑坏了。好大一碗稀饭啊——她只会煮稀饭。最后还害我半夜起来上厕所。原来今天姐夫说好要回来吃,但是又临时出差去了,于是拖我过去消饭菜。想想还是算了,肯定有我不爱吃的荤菜。不过明天早上还得陪她抱小 BB 去打预防针。555,懒觉又睡不成了。

回家,看着电视中关于世界杯连篇累牍的报道和专题,突然想起还有那个该死的 WAP 网站还没做。上网搜了一下,没有找到什么好的 WAP 建站系统。得,自己做一个吧。反正我 PHP 的开发库也积累到了一定程度,做一个应付世界杯的建站系统应该不是难事。就怕五月份还生出什么难以预料的事端来,那可就有点措手不及了。

该死的 blogcn.com,据反映,访问速度还不及我在自己台式机上架设的测试 blog 站点。看来要加快点替换的进度了。

2006-04-20

服务器整备手记(二)

装好了操作系统之后,接下来就是安装各种应用系统了。按照计划,这台服务器的主要工作任务,是作为 Oracle 中心数据库服务器,以及 Web / WAP / 流媒体服务器。中心数据库目前可能还用不上,因为必须要周围的应用系统也要进行相应的修改才能使用它,所以前期的主要用途就落在做Web服务器了。

Linux 下架设 Web 服务器,Apache 肯定是不二之选了。数据库除了以后要安装的 Oracle,MySQL 也要装上。按照计划,一些轻量级的、独立的应用,将用 MySQL 来作数据库,以便与主数据库隔离开,也方便今后这些系统和主营系统进行分离。至于服务器端脚本,计划支持 Perl CGI / PHP / JSP,先以我最熟悉的 PHP 进行安装吧。

PHP要支持的功能,包括:iconv、XML、MySQL 5 Client(废话)、GD(PNG/JPEG)、ZLIB、Oracle。其中,XML 和 ZLIB 是自带的,Oracle 功能依靠以后安装的 Oracle 客户端。其他功能都需要相应库文件的支持。因此,先要把以下的库安装或升级好:

  1. libiconv-1.9.2.tar.gz(PHP 需要它来提供 iconv 功能,以进行各种字符编码的转换。Linux AS 3.0 只带了动态链接库)
  2. gettext-0.14.5.tar.gz(它有用到 libiconv,因此放在第二位)
  3. openssl-0.9.8a.tar.gz(Linux AS 3.0 有自带,不过是 0.9.7a 版本的)
  4. jpegsrc.v6b.tar.gz(让 PHP 的 GD 功能能够对 JPEG 图片进行操作)
  5. libpng-1.2.2-25.src.rpm(让 PHP 的 GD 功能能够对 PNG 图片进行操作。Linux AS 3.0 有自带,不过是 1.2.2-16 版本的)

其中要注意的是,除了 openssl 可以装在 /usr/local/openssl,其它的几个库都最好设置 --prefix=/usr。这样以后编译 PHP 的时候可以省点心。特别是 libiconv,如果按默认设置装在 /usr/local 下面,那启动 Apache 都不行的。原因?ldconfig 默认的配置不包含 /usr/local/lib。

另外,libpng 是一个 src.rpm 包,安装步骤如下:

rpm –ivh libpng-1.2.2-25.src.rpm
cd /usr/src/redhat
rpmbuild –bb SPECS/libpng.spec
rpm –Uvh RPMS/i386/libpng-devel-1.2.2-25.i386.rpm

尤其要注意的是这最后一步。选项用 U 而不用 i,是因为系统内已经有了 1.2.2-16 的版本了,若用i则会提示有文件冲突。而且,一定要安装这个 devel 版本的包。若安装 libpng-1.2.2-25.i386.rpm,将会发现静态链接库不会出现。

好了,现在一切就绪,可以开始 APM 的安装了。MySQL 无论何时装都可以,我就先装了。根据 INSTALL-BINARY 文件内的提示,可以很容易地搞定。最后把 support-files/my-medium.cnf 复制为 /etc/my.cnf,并把 support-files/mysql.server 复制为 /etc/init.d/mysqld。然后 chkconfig –add mysqld,添加其为系统服务,运行 setup 打开它的启动选项。reboot 测试,OK。

  • 编译 Apache,编译选项是:--prefix=/usr/local/apache2 --enable-so --enable-ssl --with-ssl=/usr/local/openssl --enable-rewrite
  • 编译 PHP,编译选项是:--with-apxs2=/usr/local/apache2/bin/apxs --enable-inline-optimization --with-xml --with-iconv=/usr --with-gd --with-zlib-dir=/usr/lib --with-mysql=/usr/local/mysql --with-jpeg-dir=/usr --with-png-dir=/usr/lib

由于以前已经在不同的机器上配置测试过多次,选项都已经很固定了,因此安装过程非常顺利,乏善可陈,按下不表。

2006-04-19

服务器整备手记(一)

新申请的服务器到位了。尽管申请了三台磨蹭了很久只批了一台,不过也总比没有强。IBM x336,双至强 3.0G 的 CPU,2G 的内存,146G SCSI U320 的万转硬盘做成 RAID1。现在手头总算有台像样一点的中心服务器了。昨天让系统集成部的同事配好了 RAID,今天马上开始折腾。

首先安装操作系统。为了和已有的两台服务器保持一致,选用了 RedHat Enterprise Linux AS 3.0。这同时也是该服务器的网卡驱动所宣称支持的最高版本的 Linux。昨天晚上因为 CD 盘片损坏,安装失败。今天特地从家里带来了经过测试的安装盘。

只是要装上使用,是很容易的。然而,我还想利用这个机会,摸索出最适合的安装包搭配。为了求保险而选择完全安装,这不是我的风格。第一次安装,我选择了最小安装,没有选中任何可选包。这次的安装大小只有 608M。然而,装好系统之后,一敲 GCC,就知道这不是我要的系统。当然,这也完全在我的意料之中。

第二次,我选中了 Developement Tools。这次编译器是都上去了,开发所需要的库也都上去了。配好 IP 地址,我准备回到办公室用 SecureCRT 慢慢做余下的工作,结果却发现怎么也连不上。到服务器上 ifconfig 一下,嗬,连 eth0 这设备都没出现。把笔记本抱过去检查了一下网线,是好的。两块网卡换着插,也不行。翻翻说明书,基本上可以确定是网卡驱动没有安装的缘故了。

说来也奇怪,昨天去客户那边安装的是一台 IBM x346,2U 的机器。相近的型号,那台就不需要安装网卡驱动。不知道是不是主板型号不一样的缘故?不管怎么说,翻出服务器的附件包,找出网卡驱动盘。还真专门做了一张盘来放网卡驱动。仔细阅读了 README 中的说明之后,我选择了 SRC.RPM 包的方式进行安装,却在编译时发现需要内核源码。看来安装时必须选择 Kernel Developement Tools 了。重新安装了系统之后,编译驱动成功,手动载入 module,网络确实可以使用了,不过 reboot 之后又不行了。编辑了 /etc/module.conf,把 eth0 和 eth1 都设置成了网卡驱动的别名。这次总算可以了。