企业官网建设流程全解析

简介：一份面向统信UOS系统批量激活场景的shell脚本资源，主要解决企业、学校等在多台机器上需要逐一录入激活码的繁琐问题。脚本运行于root权限并需联网，通过读取本机mac地址或硬盘序列号，与脚本内置的对应关系自动匹配并执行激活，适合有一定Linux基础的系统运维人员或批量部署负责人使用。相比逐台手动操作，该脚本能显著减少重复劳动，同时降低人工误填导致激活失败的风险，尤其适合政企、教育等大规模国产化替代场景；包体为zip压缩包，内含1个sh脚本文件，整体大小仅496B，结构精简，便于直接拖入现有部署流程或按需二次修改。目前已有7814人学习下载，说明该场景在国产化推进中具有较高需求；使用时需预先在脚本中填写各机器的mac地址与正版激活码，前提是合法持有授权。需要提醒的是，脚本仅提供批量匹配与激活的自动化能力，不包含任何破解或非法激活功能。

1. 统信批量操作脚本，到底在批什么

拿到 50 台预装统信 UOS 的台式机，你要做的事往往出奇一致：开机、激活、重置密码、装字体、清一遍日志、再预装个 Docker 运行时。这些动作单独一台做不复杂，但乘以 50 就很要命——一个人一台台点界面，一天基本就交代了，还容易漏。统信批量操作脚本要解决的，就是把这套高频交付动作收拢成一条命令，让机器自己跑。

统信 UOS 桌面版和服务器版都是 Debian 系改造的，所以 bash 脚本、systemd、dpkg、apt 这一整条技术栈可以直接复用。真正和普通 Debian 不一样的地方，集中在几个点上：root 账户默认锁定、PAM 层 faillock 能把账号锁 1440 分钟、授权文件区分 CPU 架构、桌面版默认没开 sshd。这些坑不摸清楚，照搬 Ubuntu 的批量脚本一定会翻车。

这篇笔记适合三类人：集成商交付工程师、单位内部运维、做政企项目现场实施的朋友。下面按我实际跑批量任务的顺序讲：先把批量通道铺好，再逐个写高频操作脚本，最后把踩过的坑和验证手段交代清楚。跟着走完，你手上的统信机器应该能从一个一个点鼠标，变成一条命令跑全批。

2. 先铺批量通道：SSH 远程与 U 盘自启两条路

2.1 用 sshpass 跑通批量任务队列：batch_run.sh 与三个参数

批量脚本的第一步不是写业务逻辑，而是解决“怎么把脚本送进每台机器并收结果”。常见做法是管理机通过 SSH 远程执行，目标机只要开放 22 端口就行。这里有个前提要先说清楚：统信桌面版默认没装 openssh-server，很多现场拿到机器第一步连不上就是这原因。批量之前先解决它，后面会专门讲这个坑。

管理机上需要装 sshpass，用来在脚本里传密码。Debian 系装法就是一条命令：

apt install sshpass -y

然后写一个最朴素的批量执行器，我一般叫它batch_run.sh：

#!/bin/bash # batch_run.sh 用法: ./batch_run.sh hosts.txt ./task.sh HOSTS_FILE="$1" TASK="$2" LOG_DIR="logs/$(date +%Y%m%d_%H%M%S)" mkdir -p "$LOG_DIR" : > "$LOG_DIR/fail.list" cat "$HOSTS_FILE" | xargs -P 10 -I {} bash -c ' ip=$(echo "{}" | awk "{print \$1}") user=$(echo "{}" | awk "{print \$2}") pass=$(echo "{}" | awk "{print \$3}") if sshpass -p "$pass" ssh -p 22 -o ConnectTimeout=10 -o StrictHostKeyChecking=no \ "$user@$ip" "bash -s" < "$TASK" > "$LOG_DIR/$ip.out" 2> "$LOG_DIR/$ip.err"; then echo "[OK] $ip" else echo "$ip" >> "$LOG_DIR/fail.list" echo "[FAIL] $ip 见 $LOG_DIR/$ip.err" fi '

hosts.txt的格式每行三列，用空格或 Tab 分隔：IP、用户名、密码。xargs -P 10控制并发数是 10，这个数字对绝大多数内网环境够用，并发太高容易把管理机的 SSH 进程和网络栈拖垮。bash -s配合本地文件重定向，是让远程机器执行本地脚本最干净的方式，不需要把脚本先拷过去。ConnectTimeout=10防止某台机器网络不通时卡死整个队列，StrictHostKeyChecking=no跳过首次连接的主机密钥确认，否则第一次批量会在交互提示上卡住。

三个参数值得记一下：-P管并发，ConnectTimeout管单机超时，LOG_DIR按时间戳区分每一批任务。跑完一批，每台机器的标准输出在logs/时间戳/IP.out，错误在.err，失败的 IP 汇总在fail.list。有了这个壳子，后面每个业务脚本都可以直接往里丢。

2.2 内网隔离时用 systemd oneshot 驱动 U 盘脚本

不是所有统信机器都能走 SSH。有些内网物理隔离，不允许开放远程端口；有些机器连网络都没配，属于“裸机交付”。这种场景常见做法是 U 盘脚本：把任务脚本放到 U 盘，插上机器，开机自动跑一次，跑完留日志、拔盘走人。

U 盘插上后先手动挂载到固定路径，避免系统自动挂载到/media/admin/U 盘名这类带空格和中文的路径。一般这么处理：

lsblk mount /dev/sdb1 /mnt/batch

然后在/mnt/batch下放一个run.sh，里面写你要批量执行的业务逻辑。再写一个 systemd 服务来触发它：

# /etc/systemd/system/batch-init.service [Unit] Description=UOS batch init from USB ConditionPathExists=/mnt/batch/.start [Service] Type=oneshot ExecStart=/bin/bash /mnt/batch/run.sh ExecStartPost=/bin/rm -f /mnt/batch/.start [Install] WantedBy=multi-user.target

执行两步让它生效：

systemctl enable batch-init systemctl start batch-init

这里的关键是ConditionPathExists=/mnt/batch/.start。脚本正常结束后，ExecStartPost会删掉 U 盘里的.start标记文件，下次开机条件不满足，服务直接跳过。如果run.sh执行失败，.start保留下来，下次开机还会重跑，方便你插着 U 盘反复调试。这个“失败重跑、成功停跑”的设计，比在脚本里自己判断标记文件要稳得多。

这种模式在统信 UOS 桌面系统安装部署场景里特别实用：新机器第一次开机，插 U 盘、通电、等日志、拔盘，一台机器三五分钟，人只需要做插拔动作。家庭版 21.3 那种进不去登录界面的机器，也可以用这套系统进命令行模式清理磁盘、重置 faillock 状态，不用重装系统。

2.3 要不要上 Ansible：我的取舍

很多朋友一上来就问，批量操作为什么不用 Ansible。我的判断是：如果你已经有一批统信机器要跑，而且管理机上 Python 3 环境齐全，Ansible 完全能用，尤其是规模超过一百台、任务清单经常变的时候。但有几个现实问题：

第一，统信桌面版自带的 Python 未必和 Ansible 控制端版本完全匹配，ansible 的模块在目标机上要调 Python 解释器，版本不一致容易报模块缺失。第二，内网很多机器没有外网，Ansible 控制端装好了，目标机侧的 Python 依赖一样要离线分发。第三，你如果只是跑shell模块，Ansible 和 bash 脚本的差别被压缩得很小。

Ansible 也有它的优势，ad-hoc 模式可以临时跑命令：

ansible -i hosts uos_hosts -m shell -a 'bash /tmp/task.sh' -f 20 -o

-f 20控制并发，-o让每台机器一行输出，看结果比 bash 脚本清爽。但 hosts 文件里要给每台机器写ansible_user、ansible_python_interpreter，还要处理提权方式。五十台以内、任务稳定、要快速交付，我更愿意用 2.1 那个 bash 版本的执行器，依赖少、排错直观。超过一百台或者任务清单经常变，再切 Ansible 不迟。批量脚本的核心从来不是工具多高级，而是能不能在一批机器上稳定复现同一个结果。

3. 高频操作脚本化：激活、重置密码、装字体、清盘、装 Docker

3.1 批量激活统信系统：先查状态，再导授权文件

统信 UOS 的授权机制分两种：在线激活码和离线授权文件。批量交付场景里，离线授权文件更常见，采购时拿到的是.license或.key结尾的文件，每个文件绑定 CPU 架构和产品类型。命令行激活工具在不同版本里叫法略有差异，常见的是uos-activator。先查状态再决定要不要激活，避免重复导入：

#!/bin/bash # task_activate.sh 通过 batch_run.sh 推送到目标机执行 LIC="$(find /data -name '*.license' -o -name '*.key' 2>/dev/null | head -n 1)" STATUS="$(uos-activator -g 2>/dev/null | grep -E '激活|Status' | head -n 1)" case "$STATUS" in *激活*|*activated*) echo "already activated" exit 0 ;; esac if [ -n "$LIC" ]; then uos-activator -l "$LIC" && echo "activate ok" || echo "activate failed" else echo "no license file found" fi

逻辑上先跑uos-activator -g查激活状态，输出里能拿到当前状态和版本信息。case匹配“已激活”或“activated”两套关键词，统信中文版输出和英文版都能覆盖。授权文件扫描/data目录，现场交付时把授权文件统一放在这个目录。找不到授权文件时明确报错，而不是静默通过。

这里的坑在于授权文件的架构绑定。同样是统信 UOS，兆芯处理器是 x86_64 架构，飞腾、鲲鹏是 ARM64 架构，授权文件往往不通用。脚本里应该在激活前加一道架构校验，把uname -m的结果和授权文件信息比对，不匹配就跳过并记录。这个事看起来小，但现场最容易出幺蛾子，后面专门展开。

3.2 批量重置密码与解除“锁定 1440 分钟”的 faillock

统信交付时经常要求重置默认密码，或者用户忘了密码需要批量重置。操作上不能只改密码，还要处理 faillock 的锁定状态，否则会出现“密码明明改对了，系统还是提示锁定 1440 分钟”的诡异现象。常见的处理脚本长这样：

#!/bin/bash # task_passwd.sh 通过 batch_run.sh 推送到各目标机执行 TARGET_USER="${TARGET_USER:-uos}" NEW_PASS="${NEW_PASS:-Uos@2024}" ROOT_LOCK_RESET="${ROOT_LOCK_RESET:-0}" echo "$TARGET_USER:$NEW_PASS" | chpasswd && echo "user password reset" # 清理 faillock 计数，解除 1440 分钟锁 if command -v faillock >/dev/null 2>&1; then faillock --user "$TARGET_USER" --reset else rm -f "/var/run/faillock/$TARGET_USER" 2>/dev/null fi # root 账户默认无密码且锁定，只有明确要求才动 if [ "$ROOT_LOCK_RESET" = "1" ]; then echo "root:$NEW_PASS" | chpasswd passwd -u root fi echo "unlock done"

chpasswd从标准输入读取用户名:密码并批量写入 shadow 文件，这是非交互式改密码最稳定的方式，比passwd管道输入可靠得多。faillock --user 用户名 --reset清空/var/run/faillock下的失败计数文件。如果没有 faillock 命令，说明libpam-modules没装或路径不同，直接删文件同样有效。

ROOT_LOCK_RESET=1这个开关要慎重。统信 UOS 的 root 账户默认锁定、没有密码，是安全基线的一部分。政企项目里如果要放开 root，脚本里先chpasswd给 root 设密码，再passwd -u root解锁，顺序不能反——先解锁一个无密码账户等于把门敞开。批量任务里我一般默认不开这个开关，除非项目明确要求用 root 运维。

3.3 批量装字体与“系统盘满了”的一次性清理

统信系统下载字体是个高频需求，政企办公环境经常要补办公字体和中文字体。批量装字体其实就三步：拷文件、刷缓存、验证。但有个细节，字体要放到/usr/local/share/fonts而不是/usr/share/fonts，后者在系统升级时容易被覆盖。脚本如下：

#!/bin/bash # task_fonts.sh 安装中文字体并验证 mkdir -p /usr/local/share/fonts/chinese cp /data/fonts/*.tt[fc] /usr/local/share/fonts/chinese/ 2>/dev/null fc-cache -f >/dev/null 2>&1 echo "chinese font count: $(fc-list :lang=zh | wc -l)"

cp只拷贝.ttf和.ttc两种常见格式，临时文件放到/data/fonts。fc-cache -f强制刷新字体缓存，不刷的话图形应用不认新字体。fc-list :lang=zh | wc -l输出中文字体数量，用来验证是否生效。

统信系统盘满了是另一个高频现场问题，尤其是家庭版 21.3 出现登录界面循环、进不了系统的案例里，根分区被占满是最常见元凶。systemd 的 journal 日志默认能长到很大，apt 缓存也是隐藏大户。一键清理：

# task_disk_clean.sh 根分区超过 85% 时触发清理 if [ "$(df -h / | awk 'NR==2{print $5}' | tr -d '%')" -gt 85 ]; then journalctl --vacuum-size=200M journalctl --vacuum-time=7d apt clean find /tmp /var/tmp -type f -atime +7 -delete 2>/dev/null echo "cleaned, usage now: $(df -h / | awk 'NR==2{print $5}')" fi

journalctl --vacuum-size=200M把日志总量压到 200M 以内，--vacuum-time=7d只保留最近七天，两个参数可以同时生效。apt clean清空/var/cache/apt/archives下的下载缓存。清理/tmp时要加-atime +7，只删七天前的旧文件，避免误伤正在运行的临时文件。先看根分区使用率再决定要不要清理，这个判断很重要——批量任务不要去每台机器做无用功。

3.4 批量预装 Docker：离线 deb 包与>#!/bin/bash # task_docker.sh 离线安装 docker 并设置数据目录 if ! command -v docker >/dev/null; then # /data/packages 下放 containerd.io、runc、docker-ce-cli、docker-ce 四个 deb 包 dpkg -i /data/packages/*.deb >/dev/null 2>&1 fi command -v docker >/dev/null || { echo "docker install failed, dependencies missing"; exit 1; } mkdir -p /data/docker-root cat > /etc/docker/daemon.json <<'EOF' { "data-root": "/data/docker-root", "log-driver": "json-file", "log-opts": {"max-size": "50m", "max-file": "3"} } EOF systemctl enable docker >/dev/null 2>&1 systemctl restart docker docker info 2>/dev/null | grep "Docker Root Dir"

>echo "root:${NEW_PASS}" | chpasswd passwd -u root

改完可以用passwd -S root查看状态，第二列是L表示锁定、P表示可用密码登录。我一般在脚本里把这个状态输出到日志，方便事后审计。

4.2 密码改对了还是锁 1440 分钟：faillock 状态文件在作怪

现象：密码重置完成后，用新密码登录统信桌面系统，界面仍提示“账户已锁定”或“请等待 1440 分钟后重试”，看起来像密码没改成功。 原因：改密码只改了 shadow 文件，而锁定状态是 PAM 层pam_faillock模块记录的，状态文件存在/var/run/faillock/用户名。只要失败登录次数达到阈值，faillock 就会锁定该账户，这个锁定和密码本身无关，改密码不会清除它。 解决：用faillock --user 用户名 --reset清空计数，或者直接删状态文件：

faillock --user uos --reset rm -f /var/run/faillock/uos

批量重置密码的脚本里必须把 faillock 清理和chpasswd放在一起，否则就会出现“改完密码仍然登录不了”的现场事故。有一个容易忽略的点：/var/run/faillock是 tmpfs，重启会清空，但如果脚本只改密码不重启，锁就一直在。

4.3 目标机是桌面版却连不上 SSH：先补 openssh-server 再入队

现象：batch_run.sh跑到桌面版机器上，报Connection refused或No route to host，所有机器全军覆没或是零星几台失败。 原因：统信桌面版默认不安装 openssh-server，只有服务器版默认开启 SSH 服务。批量脚本写好才发现连不上，是最常见的开场白。 解决：把 openssh-server 装到系统里。离线环境先准备 deb 包，在线环境直接：

apt install openssh-server -y systemctl enable --now ssh

装完确认一下 22 端口监听。如果是刚接手的存量机器，可以用 U 盘脚本走 2.2 的 systemd oneshot 模式补装，装完再进批量队列。这条经验说穿了不值钱，但每批统信桌面机交付都有人栽在这里。

4.4 CPU 架构不一致：兆芯 x86、飞腾与鲲鹏 ARM 的授权与依赖

现象：同一份统信授权文件，在兆芯处理器的机器上激活正常，推到飞腾或鲲鹏机器上报激活失败；或者同一个 deb 包在这批机器安装成功，那批机器报架构不匹配。 原因：统信 UOS 授权文件与 CPU 架构绑定，x86_64 的授权文件不能用于 ARM64 机器。软件包同理，dpkg安装时会校验包架构，错误架构直接拒绝。 解决：批量脚本开头记录每台机器的架构和 CPU 厂商信息，然后按架构分发对应的授权文件和安装包：

ARCH="$(uname -m)" CPU_VENDOR="$(lscpu | grep '厂商\|Vendor ID' | awk '{print $NF}')" echo "arch=$ARCH vendor=$CPU_VENDOR"

x86_64 且 vendor 是兆芯的机器，走兆芯授权包；ARM64 的走 ARM 授权包。批量任务里我一般会在 hosts 表里加一列“架构标签”，每台机器入队时先校验标签，不符合的就跳过并记录，避免一台错带动整批乱。这个校验看起来多余，但批量规模一上去，架构混用是必然遇到的。

4.5 双系统 grub 被脚本覆盖：os-prober 找回 Windows 引导项

现象：批量部署统信系统后，机器重启直接进 UOS，原来安装的 Win10 引导项消失，用户投诉系统丢了一个。 原因：统信安装器或批处理脚本重写了 grub 引导，没有保留原有 Windows Boot Manager 的引导项。双系统装机场景下，grub 配置被覆盖是批量脚本最容易被忽略的副作用。 解决：批量脚本里主动加一步探测和修复：

apt install os-prober -y os-prober update-grub

os-prober扫描磁盘里其他操作系统，update-grub重新生成引导菜单。跑完这两条，重启后 grub 菜单里应该能看到 Windows 引导项。如果现场不允许拆机操作，提前备份/boot/grub/grub.cfg是对的，重装 grub 或调整分区布局后能手动恢复。双系统安装完之后，引导项丢失的问题几乎每次都和 grub 覆盖绑定，批量任务尤其要在交付清单里标记清楚哪些机器是双系统。

5. 把一次性脚本升级成可复用批次：配置、快照、日志与 dry-run

5.1 配置抽离：hosts 表加上账号、端口、并发数

批量脚本跑了几轮之后，你会发现每批机器的密码、端口、并发数都不一样。把这些东西写死在脚本里等于每次改代码。常见做法是抽一个配置文件和 hosts 表出来：

# batch.conf SSH_PORT=22 SSH_TIMEOUT=10 MAX_PARALLEL=10 LOG_BASE=logs

hosts 表按结构化格式维护，每行包含 IP、端口、用户名、密码、标签：

# hosts.tsv 192.168.1.10 22 uos Uos@2024 交付组A 192.168.1.11 22 uos Uos@2024 交付组B

然后在batch_run.sh里 source 配置文件：

source ./batch.conf cat "$HOSTS_FILE" | xargs -P "$MAX_PARALLEL" -I {} bash -c '...'

source让所有参数在一个地方改，xargs -P读取并发数而不是写死。hosts 表用 Tab 分隔而不是空格，因为密码里可能带空格。IP 和端口拆成两列，避免改端口时批量脚本还得跟着改-p参数。这个抽离动作不复杂，但能让你从“跑一批改一次脚本”里解脱出来。

5.2 操作前快照：给密码、激活状态留一份“后悔药”

批量操作最怕的是把某台机器搞坏了，又不知道改之前是什么状态。密码文件、激活状态、磁盘分区这些信息，操作前留一份快照，出了问题能对比回滚。目标机上执行快照脚本：

#!/bin/bash # task_snapshot.sh 在目标机上生成快照 SNAP_DIR="/data/snapshot-$(date +%Y%m%d%H%M%S)" mkdir -p "$SNAP_DIR" cp -a /etc/passwd /etc/shadow "$SNAP_DIR/" uos-activator -g > "$SNAP_DIR/activation.txt" 2>&1 || true df -h > "$SNAP_DIR/disk.txt" tar czf "${SNAP_DIR}.tgz" -C /data "$(basename "$SNAP_DIR")"

快照文件生成后，通过批量执行器拉回管理机存档：

scp -P "$SSH_PORT" "$user@$ip:/data/snapshot-*.tgz" "$LOG_DIR/snapshots/"

cp -a保留文件属性，passwd 和 shadow 的原始权限不能被破坏。uos-activator -g的输出是激活状态快照，命令不存在时|| true保证快照脚本不会因为这一行失败而中断。快照是“后悔药”，不一定要回滚，但出问题时能省掉一大半排查时间。

5.3 批量脚本必须有三份输出：out、err 与 fail.list

批量任务跑完，第一件事不是看结果，而是看失败列表。我在 2.1 的脚本里设计了三个输出，这里展开说为什么是三个而不是一个：

标准输出进.out，错误输出进.err，失败的 IP 单独汇总到fail.list。.out用于核对成功机器的业务结果，比如激活状态、字体数量；.err是定位错误的第一手材料；fail.list是重新入队的依据。缺了任何一份，排查都要从头再跑一遍。

在日志目录里再生成一份结果摘要，方便横向对比：

# 在 batch_run.sh 末尾追加 echo -e "IP\t状态\t错误摘要" > "$LOG_DIR/result.tsv" for f in "$LOG_DIR"/*.err; do ip="$(basename "$f" .err)" if [ -s "$f" ]; then err="$(grep -m1 -o 'Permission denied\|Connection timed out\|No route to host' "$f" || echo other)" echo -e "$ip\tFAIL\t$err" >> "$LOG_DIR/result.tsv" else echo -e "$ip\tOK\t-" >> "$LOG_DIR/result.tsv" fi done

result.tsv把每台机器的结果压缩成一行，用表格方式打开或grep都能快速看到整体态势。-m1 -o只提取错误信息里第一个特征关键词，避免一长段报错撑爆表格单元格。批量操作脚本没有日志等于没有证据，这套三件套是底线。

5.4 dry-run 模式：只打印要执行的动作，不真改

新脚本上量之前，先跑一遍 dry-run 检查逻辑，是成本最低的验证手段。在脚本里加一个开关，所有写操作前面判断一下：

DRY_RUN="${DRY_RUN:-0}" if [ "$DRY_RUN" = "1" ]; then echo "[DRY-RUN] 将执行: echo 'uos:Uos@2024' | chpasswd" echo "[DRY-RUN] 将执行: faillock --user uos --reset" else echo "uos:Uos@2024" | chpasswd faillock --user uos --reset fi

DRY_RUN环境变量设为 1 时，只打印将要执行的动作，实际命令一行都不跑。批量任务里所有写操作，包括激活、重置密码、清理日志、改 daemon.json，都应该走这个模式。上了几十台机器才发现脚本里有路径写错，痛苦远大于多花五分钟做一次 dry-run。

这个习惯带给我最直接的好处是：新脚本第一次进批次队列时，我会先用DRY_RUN=1 ./batch_run.sh hosts.txt task.sh跑一遍，检查每台机器输出的 dry-run 日志是否和预期一致，确认无误后再正式执行。这里省下的时间，远大于多跑一趟的成本。

6. 用三招确认批量结果：验证、回查与下一批

批量任务跑完，脚本退出码是 0 不代表业务成功。真正的验证要点是：激活状态是否统一、密码是否能登录、磁盘有没有被清理到位。我一般分三步做确认。

第一招，聚合激活状态。批量激活脚本如果每台机器都输出了already activated或activate ok，说明这一批授权基本到位。从日志里汇总：

grep -l "already activated\|activate ok" logs/*/out

grep -l罗列出成功的文件列表，再数一下数量就知道哪台没激活。第二招，验证密码与锁定状态。干巴巴地看chpasswd成功输出不靠谱，要真实登录一次：

sshpass -p 'Uos@2024' ssh -o ConnectTimeout=5 uos@192.168.1.10 'echo login ok'

这条命令同时验证了密码正确性和 faillock 状态——如果 faillock 仍锁着，这里会直接报Permission denied。每台机器轮询一遍，比看日志更接近用户真实感受。第三招，回查错误日志定位半成功任务。很多失败不是整台机器挂了，而是脚本里某一步踩坑，比如授权文件架构不匹配、磁盘清理权限不足、docker 依赖缺失：

for f in logs/*/*.err; do ip="$(basename "$(dirname "$f")")" errline="$(grep -m1 'Permission denied\|faillock\|No space left\|架构\|architecture' "$f" || true)" [ -n "$errline" ] && echo "$ip -> $errline" done

从.err里提取每台机器的首条根因，按 IP 归类，就能把“哪些机器需要重新入队”和“哪些机器需要人工介入”分得清清楚楚。把失败机器修好或重新推送后，再跑一遍batch_run.sh只针对fail.list里的 IP 重试，不需要全量重跑。

我个人的习惯是，每次批量交付后把每台机器的序列号、网卡 MAC、激活状态、根分区使用率整理成一个 CSV 存档，随交付清单一起交出去。半年后售后电话打过来，翻出这份文件就能在两分钟内定位是哪台机器、当时的系统状态是什么，不用重新跑现场。这个习惯帮我在后续维护里省了大量重复排查的时间，比任何一个脚本本身都值得保留。希望帮到你。

本文还有配套的精品资源，点击获取