简介在统信UOS的批量部署中激活授权管理常令运维人员耗费大量时间面向需要批量激活系统的技术人员这份脚本可根据机器MAC地址或硬盘序列号自动匹配对应激活码省去逐台手工录入与比对的繁琐过程尤其适用于企业机房、学校实验室等需统一激活多台设备的场景。脚本需以root权限在联网环境下运行使用前在脚本中填写设备MAC地址与正版激活码的映射关系即可映射表结构清晰支持按需增删记录读取当前硬件信息后能自动找到对应激活码实现一键式批量激活无需额外安装依赖包。资源包为ZIP压缩格式共包含1个sh脚本文件压缩包整体仅496B体积小巧脚本文件为纯文本形式解压后即可用任意文本编辑器打开直接查看和修改内容。目前已有7815人学习下载脚本逻辑清晰既可直接编辑使用也可作为批量运维脚本的参考模板帮助理解通过硬件信息自动匹配激活码的实现思路对于初始化运维环境、教学演示等场景都能直接套用。需要再次提醒的是使用前务必确认持有正版激活码并将设备信息正确填入后再执行整个过程依靠合法授权完成不涉及任何绕过验证的手段符合软件正版化要求。1. 统信UOS批量装机和配置这个标题背后是几百台终端的交付效率统信UOS的批量操作脚本解决的是政企、金融、教育行业国产化终端交付里最磨人的环节系统装好了机器摆在桌上剩下主机名、IP、软件、安全基线、打印机驱动这些逐台配置一台手工折腾二十分钟一百台就是一个星期。这个标题指向的正是把这段重复劳动变成可重跑的脚本一次编写、批量下发、全部生效把交付周期从按天算压到按小时算。适合集成商项目经理、单位IT运维和产线预装人员读尤其适合正在做统信UOS桌面系统安装部署但还没建立起批量工具链的团队。写脚本本身不难难的是你猜不到UOS桌面上哪一步会跟脚本抢权限、哪一步会因为桌面环境的状态差异中途翻车。这篇从环境准备讲到高频场景再落到避坑和可复用执行器全程按一线实操的路径走。2. 批量操作的前置条件统一命令通道与最小可用shell2.1 先分清UOS桌面版与服务器版在“批量”上的差异统信UOS至少分成桌面版与服务器版两条产品线。桌面版默认面向普通用户图形界面是主要交互方式预装的终端模拟器叫“终端”服务器版在字符界面部署SSH服务默认可用。而桌面版的sshd默认不启动——这是很多运维第一次踩坑的地方ssh连不上以为是目标机IP不通查了半天发现是sshd没装。批量操作脚本要能在被管机器上跑第一步是保证有一条可控的远程通道。桌面版需要先安装并开启openssh-server服务器版则要确认ssh正在监听、目标机的管理网IP能通。对于已经装了桌面版的机器开启SSH的命令要放在U盘脚本或本地手工执行一次对目标机全部执行完之后后续脚本才谈得上批量。这一步不要偷懒批量脚本依赖的命令通道如果不可靠后面所有环节都会被拖累。2.2 建立目标机器清单一个文件管理所有变量批量脚本最重要的设计决策是“清单驱动”。不要为每台机器写不同脚本而是维护一份包含IP、主机名、掩码、网关、DNS的清单文件脚本循环读取。UOS批量操作的目标机器往往几十上百台如果把变量硬编码进脚本换一个网段就要改一遍脚本维护成本直线上升。一个典型的目标机器清单长这样# targets.txt # 格式IP 主机名 掩码 网关 DNS 192.168.10.11 pc-011 255.255.255.0 192.168.10.1 192.168.10.1 192.168.10.12 pc-012 255.255.255.0 192.168.10.1 192.168.10.1 192.168.10.13 pc-013 255.255.255.0 192.168.10.1 192.168.10.1脚本里用while read循环读取空格分隔字段。这样后面换IP段、加机器、调整网关只需要改这个文本文件脚本一行不用动。同时在文件头部用注释写明网络规划IP段范围、网关、DNS、对应台账文件路径三个月后再看这批脚本清单本身就是交接文档。我一般会在这个文件里多留一列“备注”标注机器用途或负责人排查故障时能快速定位。2.3 一个最小可用脚本的骨架不管后面写多复杂批量操作脚本永远从一段骨架开始。这段骨架做的事情是读取清单、跳过注释行和空行、逐台调用操作函数、把错误信息落到日志文件。#!/bin/bash # batch_skeleton.sh批量脚本通用骨架 set -euo pipefail HOST_LIST/root/targets.txt LOG_DIR/var/log/uos_batch mkdir -p $LOG_DIR exec 2$LOG_DIR/batch.err # 这里定义实际要执行的操作函数 do_config() { local IP$1 HOST$2 echo [$HOST] 开始处理 $(date %F %T) ssh -o ConnectTimeout5 uos$IP sudo hostname $HOST } while read -r IP HOST _; do # 跳过空行和注释行 [[ $IP ~ ^#.*$ || -z $IP ]] continue do_config $IP $HOST done $HOST_LIST代码逻辑说明set -euo pipefail的含义是脚本遇到未定义变量、命令返回非零、管道中任一环节失败时立即退出避免脚本“假装成功”继续向下跑。exec 2把脚本本身的错误输出一并追加到日志文件方便事后回溯尤其是半夜跑批失败时不用靠猜。do_config是操作函数的占位实际部署时替换成具体的配置逻辑。参数上HOST_LIST是清单文件路径LOG_DIR是日志目录这两个变量放在脚本头部便于统一修改。注意set -e对批量脚本是双刃剑某台机器失败会中断整批执行所以生产脚本里通常会把do_config放进子shell失败只记录不中断主循环。2.4 密码与免密批量执行前先解决“谁来授权”UOS默认root账户是锁定的日常操作由普通用户通过sudo提权。这在图形界面没什么可在非交互脚本里就成了第一个拦路虎——sudo要密码脚本没法坐下来输。常见做法是一次性打开SSH免密后续脚本全程“无感”对不支持公钥的环境用expect做交互临时过渡。我一般会先用sshpass或expect把公钥推上去然后从清单逐台做免密验证。这里有个分寸问题不要为了省事把目标机的sudo权限放开成NOPASSWD除非是测试环境。生产环境里批量脚本应尽量用标准用户加受控的sudo命令白名单否则一台机器被攻破整批机器都等于裸奔。批量脚本是提高效率不是降低安全基线这条红线不要碰。3. 高频批量场景的脚本写法改主机名、配IP、装软件与统一配置3.1 批量改主机名两个文件必须一起动UOS改主机名除了/etc/hostname还要同步/etc/hosts否则会出现用新主机名解析到旧IP的怪问题。现象是ssh连机器时主机名对不上日志里间歇性出现解析慢的错误排查半天发现是hosts文件没改。批量脚本里把两个文件一起处理一次改到位#!/bin/bash # remote_rename.sh远程改主机名 # 用法./remote_rename.sh IP 新主机名 IP$1 NEW_HOST$2 SSH_OPTS-o StrictHostKeyCheckingno -o ConnectTimeout5 ssh $SSH_OPTS uos$IP echo $NEW_HOST | sudo tee /etc/hostname /dev/null sudo sed -i \s/^127.0.1.1.*/127.0.1.1 $NEW_HOST/\ /etc/hosts sudo hostnamectl set-hostname $NEW_HOST 代码逻辑说明先用tee把新主机名写入/etc/hostname再用sed把/etc/hosts里以127.0.1.1开头的那行替换成新主机名最后hostnamectl应用配置。为什么两个文件一起改因为部分服务解析本机名时优先查hosts文件hosts没同步就会出现新主机名解析不到本机的间歇性故障。参数说明tee配合sudo是因为普通用户没有写/etc/hostname的权限sed只替换127.0.1.1那行这是Debian系约定俗成的本机IP映射位置UOS沿用了这个约定。3.2 批量配置静态IP统一用nmcli而不是改interfacesUOS桌面版网络管理默认走NetworkManager。直接修改/etc/network/interfaces这种老Debian路子经常出现“配置文件明明改了就是不生效”的情况。原因在于连接配置是由NetworkManager管理的interfaces文件的改动会被NM忽略或覆盖。推荐用nmcli操作#!/bin/bash # remote_ip.sh远程配置静态IP # 用法./remote_ip.sh 目标机IP 新IP 掩码 网关 DNS IP$1; NIP$2; MASK$3; GW$4; DNS$5 SSH_OPTS-o StrictHostKeyCheckingno -o ConnectTimeout5 ssh $SSH_OPTS uos$IP CONN\$(nmcli -t -f NAME connection show --active | head -n1) sudo nmcli connection modify \\$CONN\ \\ ipv4.method manual \\ ipv4.addresses \$NIP/$MASK\ \\ ipv4.gateway \$GW\ \\ ipv4.dns \$DNS\ sudo nmcli connection up \\$CONN\ 代码逻辑说明第一行命令取出当前活动连接名而不是猜网卡名字。UOS桌面版对有线连接默认命名可能是“有线连接 1”带空格所以变量要加引号。ipv4.method manual表示关闭DHCP改用静态ipv4.addresses支持CIDR写法建议直接写192.168.10.11/24改完必须执行connection up才会让配置加载。参数说明MASK参数传24或255.255.255.0都可以nmcli两种都认但建议统一用CIDR格式脚本里解析更省事。这台机器改完IP后ssh连接会断因为IP变了批量脚本里要注意先记录新IP到清单等网络通了再继续下一轮操作。3.3 批量安装deb包处理依赖是重头戏统信UOS分发的软件包不少是.deb格式。直接dpkg -i *.deb遇到缺依赖就半途报错而且dpkg不解决依赖问题。常见做法是先把deb拷到目标机再用apt安装让apt自动解析依赖关系#!/bin/bash # remote_install_deb.sh批量推送并安装deb包 # 用法./remote_install_deb.sh 目标机IP deb目录 IP$1 DEB_DIR$2 # 推送所有deb包到目标机临时目录 scp $DEB_DIR/*.deb uos$IP:/tmp/uos_pkgs/ # 远程执行安装 ssh uos$IP sudo mkdir -p /tmp/uos_pkgs sudo apt-get update sudo apt-get install -y /tmp/uos_pkgs/*.deb 代码逻辑说明先把本地的deb包scp到目标机的/tmp/uos_pkgs/目录然后用apt-get install直接安装本地路径下的deb文件。apt会自动解析并安装这些deb的依赖比裸dpkg -i稳得多。如果在离线内网需要在目标机上提前把apt源指向本地镜像源这段逻辑不变。参数说明apt-get update是必须的因为即使离线环境镜像源的包索引也可能更新过install -y跳过确认提示适合批量场景。注意安装完成后/tmp/uos_pkgs里的包会残留建议在安装命令后再加一句清理避免临时文件堆积。3.4 批量执行自定义操作函数同构任务的统一入口很多批量任务不是安装或改配置而是执行一段相同的运维检查比如查内核版本、查磁盘序列、查系统服务状态。这种任务写法最简单用ssh远程执行一段bash#!/bin/bash # remote_exec.sh向多台机器并发执行同一段命令 # 用法./remote_exec.sh 要执行的命令 CMD$1 while read -r IP HOST _; do [[ $IP ~ ^#.*$ || -z $IP ]] continue echo $HOST ssh -o ConnectTimeout5 uos$IP bash -c $CMD done targets.txt wait并行度靠shell的控制wait等所有后台任务结束。这里最需要注意的坑CMD里不能出现单引号否则bash -c的拼接就错位了命令会被截断。如果命令复杂更稳的做法是把命令写到临时脚本文件scp过去再执行。参数说明ConnectTimeout5让连接超时为5秒避免某台机器网络不通时长时间卡住wait放在循环外确保所有后台任务都结束脚本才退出不然脚本提前结束后台ssh进程会被丢弃。3.5 批量替换配置文件机房统一配置的标准做法批量操作里大量需求是“把同一份配置文件放到所有机器”比如sudoers、apt源配置、打印机驱动配置、安全基线加固脚本。标准做法是scp分发加校验#!/bin/bash # remote_push_conf.sh批量推送配置文件并校验 # 用法./remote_push_conf.sh 本地文件路径 目标机路径 LOCAL_FILE$1 REMOTE_PATH$2 BASE_NAME$(basename $LOCAL_FILE) while read -r IP HOST _; do [[ $IP ~ ^#.*$ || -z $IP ]] continue scp $LOCAL_FILE uos$IP:/tmp/$BASE_NAME # 先备份原文件再替换 ssh uos$IP sudo cp $REMOTE_PATH $REMOTE_PATH.bak 2/dev/null || true sudo mv /tmp/$BASE_NAME $REMOTE_PATH sudo chmod $(stat -c %a $LOCAL_FILE) $REMOTE_PATH echo [$HOST] 配置已更新 done targets.txt代码逻辑说明先把本地文件scp到目标机/tmp/登录后先备份目标机原有配置备份成.bak后缀再把新文件mv到位。chmod那行取本地文件的权限位应用到目标机文件上避免scp覆盖后权限变成默认值导致服务起不来。参数说明备份环节的2/dev/null || true是为了忽略“文件不存在”的报错true保证即使备份失败也不中断主流程。这个手法在批量推送配置文件时非常实用——万一新配置有问题每台机器都有.bak备份可以做回滚等于留了后悔药。4. UOS批量脚本常见的6个坑现象、原因与解法4.1 apt安装报“无法获得锁 /var/lib/dpkg/lock-frontend”现象批量安装deb包时部分机器报dpkg锁冲突apt install直接中断后续机器全部失败。原因UOS桌面版的软件商店和系统更新服务如unattended-upgrades在后台自动刷新软件源和脚本同时抢dpkg锁。图形界面用户刚登录时商店进程更容易启动锁冲突的概率更高。解决批量执行前先让目标机避开自动更新时段或在脚本里前置处理。检查是否已有进程占用dpkg锁并停掉自动更新服务sudo systemctl stop unattended-upgrades 2/dev/null || true sudo pkill -f uos-store 2/dev/null || true sudo fuser -k /var/lib/dpkg/lock-frontend 2/dev/null || true顺序是先停系统服务再杀商店进程最后强制释放锁。fuser -k这步要谨慎确认没有正在进行的安装操作再执行否则会把别人的安装任务打断。4.2 批量改IP后部分机器连不上原来是有线与无线连接同时活跃现象改了静态IP后有几台机器断连ssh重试失败。重启NetworkManager又恢复但配置丢失。原因nmcli修改时用connection show --active | head -n1取连接名如果机器同时活跃着有线连接和无线连接head -n1取到的可能是有线也可能是无线。改错了连接对象静态IP配置没落到实际使用的那条链路上。解决不要用head -n1而是精确匹配有线连接类型CONN$(nmcli -t -f NAME,TYPE connection show --active | grep ethernet | cut -d: -f1 | head -n1)同时修改后立即up并确认IP生效再继续后续操作。无线连接如果也活跃最好在批量脚本里先down掉无线避免配置被无线回连覆盖。4.3 sudo密码的交互在脚本里“失灵”expect卡死或超时现象expect脚本在某些机器上执行sudo命令时卡住甚至直接超时手工执行没问题。原因UOS的sudo在PAM高安全模式下对tty有特殊要求或者密码含特殊字符expect里转义不当匹配串永远匹配不上。解决远程执行时用ssh -tt强制分配伪终端让sudo能够读取密码expect EOF set timeout 30 spawn ssh -tt uos$IP sudo whoami expect { password { send $SUDO_PASS\r; exp_continue } eof } EOF参数说明-tt是强制分配tty的关键不加它sudo会因为没有终端而拒绝执行密码用环境变量传入expect脚本避免特殊字符的转义问题。expect的exp_continue让脚本在密码提示后继续等待其他交互直到命令执行完成。4.4 远程下发文件后机器行为不一致缺了校验环节现象把同一个配置包scp到100台机器结果有十几台运行结果和别的机器不一样排查发现文件内容不完整。原因scp在传输大文件时偶发丢包或中断而脚本没有校验文件完整性直接把损坏配置应用到了系统。解决在推送脚本里加md5校验两边校验一致才应用否则跳过并记录LOCAL_MD5$(md5sum $LOCAL_FILE | cut -d -f1) REMOTE_MD5$(ssh uos$IP md5sum /tmp/$BASE_NAME | cut -d -f1) if [[ $LOCAL_MD5 $REMOTE_MD5 ]]; then echo [$HOST] 校验通过应用配置 ssh uos$IP sudo mv /tmp/$BASE_NAME $REMOTE_PATH else echo [$HOST] 校验失败跳过 batch_fail.log fi逻辑说明先在本地算出源文件的md5scp后再去目标机算一次比对一致才应用。这步在多轮批量操作中能省下大量排查时间——我见过一次因为校验缺失十几台机器装了损坏的安全客户端重装花了整整一天。参数说明cut -d -f1取md5输出的第一列因为md5sum的单行输出是“哈希值 文件名”。4.5 无人值守批量执行时机器自动锁屏挂起脚本中断现象批量脚本运行到一半部分机器卡住手动一碰鼠标键盘任务又继续跑了。原因UOS桌面版默认电源策略会在无人操作时挂起系统锁屏后某些系统调用如dpkg配置、nmcli重连会等待显示器唤醒导致脚本假死。解决在目标机上用systemd-inhibit临时阻止挂起sudo systemd-inhibit --whatsleep:idle --modeblock --whybatch task sleep 3600这条命令的意思是在接下来的一小时内阻止系统进入睡眠和空闲状态任务跑完后这个inhibit进程退出电源策略恢复。批量脚本的开头先启动这个抑制结尾再杀掉就能避免这个问题。参数说明--whatsleep:idle指定阻止睡眠和空闲挂起--modeblock是阻塞模式sleep 3600给一个最大时长防止抑制进程残留。4.6 脚本“明明执行了却没生效”重复执行把配置搞乱现象同一脚本执行两遍第二遍改了主机名、配了重复路由配置和预期不符。原因脚本没有做幂等处理。比如重复执行nmcli connection modify时NM里会叠加多个地址条目sed重复执行也会对配置产生副作用。解决所有配置动作先做检测再设置已满足条件就跳过CURRENT_HOST$(ssh uos$IP hostname) if [[ $CURRENT_HOST ! $EXPECT_HOST ]]; then echo 主机名不一致执行修改 ssh uos$IP sudo hostnamectl set-hostname $EXPECT_HOST else echo 主机名已一致跳过 fi这版脚本可以反复执行第二次跑时检测到状态已满足直接跳过不会产生副作用。批量操作脚本的每个动作都应该写成这种“检查再执行”的模式而不是无脑执行命令。5. 从单台脚本到批量执行器免密初始化、并发控制与断点续跑5.1 免密初始化批量操作的地基批量执行的前提是ssh公钥免密。一次性把本机公钥批量推送到目标机关键是ssh-copy-id的自动化#!/bin/bash # setup_sshkey.sh一键批量下发SSH公钥 # 用法./setup_sshkey.sh SSH密码 SSH_USERuos SSH_PASS$1 HOST_LISTtargets.txt # 如果没有本地密钥对先生成 if [[ ! -f $HOME/.ssh/id_rsa.pub ]]; then ssh-keygen -t rsa -b 2048 -N -f $HOME/.ssh/id_rsa fi while read -r IP HOST _; do [[ $IP ~ ^#.*$ || -z $IP ]] continue echo $HOST sshpass -p $SSH_PASS ssh-copy-id -o StrictHostKeyCheckingno $SSH_USER$IP done $HOST_LIST代码逻辑说明前半段保证本机有公钥没有就现场生成后半段把公钥安装到目标机的authorized_keys文件里。sshpass只是工具明文密码只在脚本执行期间存在执行完可以清掉shell历史记录。参数说明-N 表示生成的密钥对没有口令适合无人值守场景如果安全要求高可以给密钥加口令但批量脚本就无法全自动执行了需要配合ssh-agent缓存密码。5.2 并发执行器一个可复用的完整模板把所有批量操作统一到一个执行器里便于重试、过滤和日志追溯。这是我认为最值得抄作业的部分一个通用的并发执行器#!/bin/bash # batch_runner.sh批量执行器 # 用法./batch_runner.sh 任务脚本路径 [并发数] [目标清单] TASK$1 THREADS${2:-5} HOST_FILE${3:-targets.txt} SUCCESS_LOG$HOME/batch_success_$(date %F).log FAIL_LOG$HOME/batch_fail_$(date %F).log : $FAIL_LOG run_task() { local IP$1 HOST$2 if ssh -o ConnectTimeout5 -o BatchModeyes uos$IP bash -s $TASK; then echo [$HOST] OK echo $IP $SUCCESS_LOG else echo [$HOST] FAIL echo $IP $FAIL_LOG fi } while read -r IP HOST _; do [[ $IP ~ ^#.*$ || -z $IP ]] continue # 已经成功过的机器跳过实现断点续跑 if grep -q ^$IP$ $SUCCESS_LOG 2/dev/null; then echo [$HOST] 上次已成功跳过 continue fi run_task $IP $HOST # 控制并发数 while (( $(jobs -r | wc -l) THREADS )); do sleep 1 done done $HOST_FILE wait echo 完成。失败机器列表 cat $FAIL_LOG代码逻辑说明任务脚本通过标准输入喂给远程bashbash -s从stdin读取脚本内容好处是本地可以直接写带语法高亮的脚本文件远程执行不需要每次scp脚本更新也只需要改本地一份。每次任务成功后把IP写入SUCCESS_LOG失败写入FAIL_LOG下次重跑时自动跳过已经成功的机器实现断点续跑。并发数控制用jobs -r统计正在运行的后台任务数达到上限就sleep 1等待这个简单逻辑比复杂的信号量控制可靠得多。参数说明BatchModeyes是免密模式的标志如果某台机器没配好免密这里会直接失败而不是卡在密码交互适合批量无人值守。5.3 任务脚本的编写规范避免远程执行时的环境差异执行器的任务脚本有几个必须遵守的规范不然容易产生环境差异导致的坑。第一脚本开头要写#!/bin/bash虽然远程是用bash -s调用但写上更保险第二不要依赖目标机上不存在的环境变量比如桌面版和服务器版的HOME路径不同第三脚本内所有临时文件写到/tmp下不要写相对路径第四执行器不会传递本地变量到远端脚本内部自行定义所有变量。一个合规的任务脚本示例#!/bin/bash # task_set_hostname.sh批量设置主机名由batch_runner调用 EXPECT_HOSTpc-0${HOST_TAIL:-011} # 从清单传入的变量需要提前定义 CURRENT_HOST$(hostname) if [[ $CURRENT_HOST ! $EXPECT_HOST ]]; then echo $EXPECT_HOST | sudo tee /etc/hostname /dev/null sudo hostnamectl set-hostname $EXPECT_HOST echo 主机名已修改为 $EXPECT_HOST else echo 主机名已是 $EXPECT_HOST跳过 fi这个脚本里的HOST_TAIL需要调用方提前传入否则就取默认值。在batch_runner里可以通过环境变量传递HOST_TAIL$HOST后面加上让脚本动态适应当前机器。注意sudo在脚本里是否可用取决于目标机sudo配置是否允许当前用户无密码执行或者是执行器里已经通过expect预先把sudo密码缓存了。5.4 失败重跑与回滚批量操作的最后一层保险批量脚本跑完一轮总会有几台机器失败。网络闪断、ssh连接超时、目标机磁盘满原因千奇百怪。重跑机制我一般分两层第一层是batch_runner自带的断点续跑跳过成功的机器第二层是应用层回滚如果新配置导致服务异常用备份文件恢复。配置类操作的回滚脚本示例#!/bin/bash # rollback_conf.sh从备份恢复配置文件 # 用法./rollback_conf.sh 目标机IP 配置文件路径 IP$1 CONF_PATH$2 ssh uos$IP if [[ -f ${CONF_PATH}.bak ]]; then sudo cp ${CONF_PATH}.bak $CONF_PATH echo 已从备份恢复 else echo 没有找到备份文件无法回滚 exit 1 fi 逻辑说明批量推送配置时每台机器都留了.bak备份回滚脚本把备份文件复制回原位置。这个动作要放在项目交付文档里写上不然三个月后没人记得有.bak文件存在真出故障时只能干瞪眼。6. 让脚本可交付从“能跑”到“可验收”的最后一公里批量脚本写完了跑通了剩下的问题是怎么证明这批操作真的成功光靠执行日志里的OK和FAIL还不够因为有些操作即使命令返回成功配置可能没生效。我的习惯是每个批量任务都配一个校验脚本任务跑完后自动在目标机执行一遍校验把结果汇总成一份可交付的报告。校验脚本的核心逻辑是“配置项预期值与实际值对比”比如检查主机名、IP、关键软件包版本#!/bin/bash # verify_client.sh目标机配置自检 EXPECT_HOSTpc-011 EXPECT_IP192.168.10.11 EXPECT_PKGuos-browser actual_host$(hostname) actual_ip$(ip -4 addr show | awk /inet / !/127.0.0.1/ {print $2} | cut -d/ -f1) pkg_status$(dpkg -l $EXPECT_PKG 2/dev/null | grep ^ii | awk {print $2}) pass_count0 fail_count0 # 检查主机名 if [[ $actual_host $EXPECT_HOST ]]; then echo PASS: 主机名 $actual_host ((pass_count)) else echo FAIL: 主机名 期望$EXPECT_HOST 实际$actual_host ((fail_count)) fi # 检查IP if [[ $actual_ip $EXPECT_IP ]]; then echo PASS: IP $actual_ip ((pass_count)) else echo FAIL: IP 期望$EXPECT_IP 实际$actual_ip ((fail_count)) fi # 检查软件包 if [[ $pkg_status $EXPECT_PKG ]]; then echo PASS: 软件包 $EXPECT_PKG 已安装 ((pass_count)) else echo FAIL: 软件包 $EXPECT_PKG 未安装 ((fail_count)) fi echo 结果统计PASS$pass_count FAIL$fail_count [[ $fail_count -eq 0 ]] exit 0 || exit 1把校验脚本放到batch_runner里作为任务脚本的最后一步每一台机器跑完配置后立即自检自检不过的机器直接进FAIL名单这样交付时拿到的不是“脚本执行成功”的空话而是一份量化通过率。甲方问“你确认所有机器都改好了”直接把FAIL名单为空的结果贴出来这就是最硬的交付证据。最后说一个个人教训。我之前在180台机器上一次性跑完批量配置脚本中间因为一台机器的sudo配置和别家不一样脚本中途报错但因为set -e没处理好整体进度直接卡住后来排查加回滚花了比写脚本更多的时间。那次之后我给自己定了个规矩批量脚本再急也要先拿两台机器试跑一台全新系统、一台运行了几周的存量系统两边结果一致再铺开。批量脚本是省时间的不是赌运气的——希望帮到你。本文还有配套的精品资源点击获取