## 我做了什么
### 1. 修复了 Docker 的持久启动链
这台机器不是普通 Linux 根盘,而是 `RAM root`。很多运行时文件重启后会丢,所以不能把修复写在 `/tmp` 或 `/usr` 的 RAM 层,必须写到持久层。
我把最小修复落在:
```text
/etc/log/naixi/compat/
boot.sh```
作用是:
- 开机时把 `/etc/log` 挂成 Docker 的持久工作盘映射
- 自动补 `/docker` 和 `/usr/sbin/docker`
- 如果系统恢复了原来的 `docker_server`,就走原链路
- 如果重启后只恢复了 `docker-bin`、没恢复 `docker` 脚本包,就直接用 `dockerd` fallback 起引擎
## 2. 清掉了高风险包和自恢复链
已删除并持续阻断的对象包括:
- `pmd`
- `cre`
- `ik_rc_client`
- `ik_host`
- `shell`
- `pre_cdn_stats`
- `ikaudit`
- `
monitor_process.sh`
对应的持久包、运行目录、入口文件和 RAM root 自恢复脚本都已经清理,并写进了开机清理逻辑。
## 3. 封死了高风险云拉取 / 外联链
现场最危险的链路是:
```text
update_hosts.sh -> 从
302.ikuai8.com 获取主机列表
-> submit.lua 拉取 submit3
-> 本地直接执行
```
这条链现在的处理方式是:
- 开机强杀 `
update_hosts.sh` / `submit.lua` / `async.lua`
- 删除 `/tmp/iktmp/ik_hosts` 和 `/tmp/iktmp/submit`
- 把 `/usr/ikuai/script/utils/
update_hosts.sh` 改写成 no-op
- 把 `/usr/ikuai/script/utils/submit.lua` 改写成空壳
同时保留 `Naixi cloud level 2` 的原有阻断:
- `/etc/hosts` 将一批 `
ikuai8.com` 云域名 sinkhole 到 `127.0.0.1`
- `iptables OUTPUT` 对多个 `iKuai` 云 IP 做 `DROP`
## 4. 现场验证结果
本次整改后,我已经做过两次 reboot 后现场复核,确认以下结论成立:
- `Docker` 第二次 reboot 后已能自动起来
- `docker info` 正常
- 高风险的 `
update_hosts.sh` / `submit.lua` / `async.lua` 没有复活
- `pmd/cre/ik_rc_client/ik_audit/monitor_process` 相关进程没有复活
- `/tmp/iktmp/ik_hosts` 和 `/tmp/iktmp/submit` 没有复活
- `netstat -anp | grep ESTABLISHED` 现场未看到新的云端已建立连接