简介一份面向统信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_DIRlogs/$(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 ConnectTimeout10 -o StrictHostKeyCheckingno \ $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配合本地文件重定向是让远程机器执行本地脚本最干净的方式不需要把脚本先拷过去。ConnectTimeout10防止某台机器网络不通时卡死整个队列StrictHostKeyCheckingno跳过首次连接的主机密钥确认否则第一次批量会在交互提示上卡住。三个参数值得记一下-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] DescriptionUOS batch init from USB ConditionPathExists/mnt/batch/.start [Service] Typeoneshot ExecStart/bin/bash /mnt/batch/run.sh ExecStartPost/bin/rm -f /mnt/batch/.start [Install] WantedBymulti-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. 高频操作脚本化激活、重置密码、装字体、清盘、装 Docker3.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:-Uos2024} 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 21; 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 donechpasswd从标准输入读取用户名:密码并批量写入 shadow 文件这是非交互式改密码最稳定的方式比passwd管道输入可靠得多。faillock --user 用户名 --reset清空/var/run/faillock下的失败计数文件。如果没有 faillock 命令说明libpam-modules没装或路径不同直接删文件同样有效。ROOT_LOCK_RESET1这个开关要慎重。统信 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 21 echo chinese font count: $(fc-list :langzh | wc -l)cp只拷贝.ttf和.ttc两种常见格式临时文件放到/data/fonts。fc-cache -f强制刷新字体缓存不刷的话图形应用不认新字体。fc-list :langzh | wc -l输出中文字体数量用来验证是否生效。统信系统盘满了是另一个高频现场问题尤其是家庭版 21.3 出现登录界面循环、进不了系统的案例里根分区被占满是最常见元凶。systemd 的 journal 日志默认能长到很大apt 缓存也是隐藏大户。一键清理# task_disk_clean.sh 根分区超过 85% 时触发清理 if [ $(df -h / | awk NR2{print $5} | tr -d %) -gt 85 ]; then journalctl --vacuum-size200M journalctl --vacuum-time7d apt clean find /tmp /var/tmp -type f -atime 7 -delete 2/dev/null echo cleaned, usage now: $(df -h / | awk NR2{print $5}) fijournalctl --vacuum-size200M把日志总量压到 200M 以内--vacuum-time7d只保留最近七天两个参数可以同时生效。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 21 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 21 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_VENDORx86_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-grubos-prober扫描磁盘里其他操作系统update-grub重新生成引导菜单。跑完这两条重启后 grub 菜单里应该能看到 Windows 引导项。如果现场不允许拆机操作提前备份/boot/grub/grub.cfg是对的重装 grub 或调整分区布局后能手动恢复。双系统安装完之后引导项丢失的问题几乎每次都和 grub 覆盖绑定批量任务尤其要在交付清单里标记清楚哪些机器是双系统。5. 把一次性脚本升级成可复用批次配置、快照、日志与 dry-run5.1 配置抽离hosts 表加上账号、端口、并发数批量脚本跑了几轮之后你会发现每批机器的密码、端口、并发数都不一样。把这些东西写死在脚本里等于每次改代码。常见做法是抽一个配置文件和 hosts 表出来# batch.conf SSH_PORT22 SSH_TIMEOUT10 MAX_PARALLEL10 LOG_BASElogshosts 表按结构化格式维护每行包含 IP、端口、用户名、密码、标签# hosts.tsv 192.168.1.10 22 uos Uos2024 交付组A 192.168.1.11 22 uos Uos2024 交付组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 21 || 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 doneresult.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:Uos2024 | chpasswd echo [DRY-RUN] 将执行: faillock --user uos --reset else echo uos:Uos2024 | chpasswd faillock --user uos --reset fiDRY_RUN环境变量设为 1 时只打印将要执行的动作实际命令一行都不跑。批量任务里所有写操作包括激活、重置密码、清理日志、改 daemon.json都应该走这个模式。上了几十台机器才发现脚本里有路径写错痛苦远大于多花五分钟做一次 dry-run。这个习惯带给我最直接的好处是新脚本第一次进批次队列时我会先用DRY_RUN1 ./batch_run.sh hosts.txt task.sh跑一遍检查每台机器输出的 dry-run 日志是否和预期一致确认无误后再正式执行。这里省下的时间远大于多跑一趟的成本。6. 用三招确认批量结果验证、回查与下一批批量任务跑完脚本退出码是 0 不代表业务成功。真正的验证要点是激活状态是否统一、密码是否能登录、磁盘有没有被清理到位。我一般分三步做确认。第一招聚合激活状态。批量激活脚本如果每台机器都输出了already activated或activate ok说明这一批授权基本到位。从日志里汇总grep -l already activated\|activate ok logs/*/outgrep -l罗列出成功的文件列表再数一下数量就知道哪台没激活。第二招验证密码与锁定状态。干巴巴地看chpasswd成功输出不靠谱要真实登录一次sshpass -p Uos2024 ssh -o ConnectTimeout5 uos192.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 存档随交付清单一起交出去。半年后售后电话打过来翻出这份文件就能在两分钟内定位是哪台机器、当时的系统状态是什么不用重新跑现场。这个习惯帮我在后续维护里省了大量重复排查的时间比任何一个脚本本身都值得保留。希望帮到你。本文还有配套的精品资源点击获取