简介这是一份面向统信UOS系统批量部署场景的自动化激活脚本用于解决企业或机构在多台机器上逐一手动输入激活码效率低下的问题。脚本会读取本机MAC地址或硬盘序列号自动匹配预设的机器与激活码映射关系完成系统激活操作运行依赖root权限及联网环境使用前须持有正规授权激活码并在脚本中提前配置好对应信息。包体为单个sh脚本压缩后仅496B结构极简适合已有批量激活需求的运维人员直接修改使用。目前已有7813人学习下载可见该场景在信创运维群体中有较高关注度。对于需要维护数十乃至上百台统信设备的运维人员来说这份脚本能显著缩短重复性激活操作耗时降低人工填写与核对错误的风险同时保留了对具体型号、串号信息的灵活配置能力是一款务实的小型自动化工具。1. uos/统信系统批量操作脚本先想清楚批量这一下值不值单位刚上了一批统信UOS机器机房管理员最头疼的不是系统本身而是同一件事要对着几十台机器重复几十遍建账号、重置密码、装USB转串口驱动、清微信的wine缓存、校时钟。鼠标点一遍一个下午就没了还容易漏台。很多人第一反应是上运维平台但实际交付和运维场景里最省事、最容易留痕、也最容易回滚的往往是一组用 bash 写的 uos/统信系统批量操作脚本。它能解决的是“重复运维动作的规模化”适合企业内网、学校机房、以及做统信系统交付和后期维护的工程师。比平台轻、比手工快而且一旦写顺手换到银河麒麟、ubuntu 这类 Debian 系系统也能复用大半。2. 批量脚本的骨架按什么维度批量决定了脚本怎么写2.1 三种批量模式多主机并行、单机多任务、离线文件包拿到需求先别急着写循环先想清楚批量的维度。我见过不少翻车案例都是因为把三种模式混在一起最后脚本在控制端跑得欢目标机器上根本没生效。第一种是多主机并行。控制端一台机器通过网络 ssh 到每一台统信UOS上执行命令。适合机器在同一内网、网络互通、运维账号能登录的场景这是最常见的做法。第二种是单机多任务。内网物理隔离或者机器分散在不同网段控制端连不上目标机那就把脚本放到每台机器本地在一台机器上按顺序执行多个维护任务。这种模式适合“跑现场”的工程师U盘里放一个 tar 包解压后一条命令跑完所有维护项。第三种是离线文件包。目标机器没有软件源装驱动、装 deb 包都得靠离线包。这时候不是远程执行命令而是先把包分发到每台机器再在本地安装。批量动作主要在“分发”上做文章。这三种模式不冲突同一个项目里经常混用。我的判断标准是能远程就远程远程不了就本地脚本本地脚本也跑不了就做离线包加手工介入。模式适用场景前置条件主要风险多主机 ssh 并行内网连通、统一管理ssh 免密、运维账号单台卡死拖慢整体单机本地脚本网络隔离、跑现场U盘或共享目录版本漂移、漏执行离线文件包无软件源、驱动/依赖难装依赖收集完整依赖缺失、架构不匹配选型理由也很直白统信UOS桌面版的部署环境经常没有规范的 DNS 和主机名hostname 五花八门反而 IP 列表最可靠。所以我的骨架脚本一律以 IP 清单为输入不依赖解析。2.2 最小可用的批量执行器ssh 免密 循环 日志无论批量做什么底层都需要一个能“逐台执行、逐台留痕”的执行器。我不建议一上来就上 Ansible统信UOS桌面版通常没预装内网源也不一定有。先用 bash 写一个最小的循环执行器足够覆盖 50 台以内的场景。#!/bin/bash # 批量执行器从 hosts.txt 读取 IP逐台执行传入的命令 # 用法: ./run_all.sh hosts.txt uptime HOSTS_FILE${1:-hosts.txt} REMOTE_CMD${2:-uptime} LOG_DIR./run_logs mkdir -p $LOG_DIR : $LOG_DIR/summary.log while read -r ip; do # 跳过空行和注释行 [ -z $ip ] continue case $ip in \#*) continue ;; esac echo $ip # ConnectTimeout 防止单台不可达把整个循环拖死 ssh -o ConnectTimeout15 -o StrictHostKeyCheckingno \ uosadmin$ip $REMOTE_CMD \ $LOG_DIR/${ip}.log 21 \ echo [OK] $ip $LOG_DIR/summary.log \ || echo [FAIL] $ip $LOG_DIR/summary.log done $HOSTS_FILE echo done. see $LOG_DIR/summary.log这个脚本的逻辑是逐行读 IP对每个 IP 执行一次 ssh 命令stdout 和 stderr 全部重定向到单台日志最终结果汇总到 summary.log。这样哪台成功、哪台失败一眼就能看到不用在一堆终端窗口里翻。参数说明ConnectTimeout15表示连接超时 15 秒避免主机离线时 ssh 一直等StrictHostKeyCheckingno跳过首次连接的主机指纹确认脚本才能无人值守跑下去代价是安全级别降低内网运维场景可接受。默认登录用户是uosadmin这是统信UOS安装时创建的常规管理用户root 默认没有启用。ssh 免密要提前配置否则脚本会卡在密码输入。在控制端执行# 批量分发公钥依赖 sshpass 仅限内网测试环境 while read -r ip; do sshpass -p 初始密码 ssh-copy-id -o StrictHostKeyCheckingno uosadmin$ip done hosts.txt生产环境不建议把密码写在命令行里sshpass 只适合首次初始化。更稳妥的方式是装机时统一注入公钥或者用 sudo 权限配合批量改密后手动收尾。2.3 为什么不用 ansible 非要自己写规模与依赖的匹配经常有人问我统信UOS批量操作为什么不用 Ansible。答案很简单如果你的内网软件源里连 ansible 都没有装它本身就要先解决批量问题。而且 ansible 对 Python 版本、依赖包、被控端开启的 Python 环境都有要求统信UOS桌面版默认自带 Python 3但 ansible 本体、selinux 相关模块在精简安装里经常缺。bash 脚本的好处是零依赖。控制端只要有 ssh 客户端目标机只要有 sshd脚本就能跑。统信UOS、银河麒麟、ubuntu server 都是 Debian 体系命令层几乎通用把用户名和包管理器的差异处理好一份脚本可以吃三套系统。这里说的包管理器差异主要指统信商店的 linglong 格式和系统 apt 源的 dpkg 包后面会单独讲。规模阈值我一般这样卡50 台以内ssh 循环脚本是最优解50 到 200 台可以考虑 Ansible 或自带代理的运维平台200 台以上批量的瓶颈已经不在脚本而在网络带宽、软件源并发和审计要求那时候才需要正经的配置管理工具。一上来就搭平台往往是给三五十台机器配了一台 K8s 的既视感维护成本比特么手工点鼠标还高。3. 统信UOS高频批量任务密码、wine缓存与软件安装3.1 批量重置和同步用户密码passwd、chpasswd 与 chage批量重置密码是出现频率最高的需求尤其是“某个员工走了他的机器要交给下一个人”或者“华为统信UOS系统忘记开机密码需要整机重置”。这时候别用passwd交互式改脚本里没法处理交互输入要用chpasswd配合管道。#!/bin/bash # 批量重置用户密码并强制下次登录修改 # 用法: ./reset_passwd.sh hosts.txt while read -r ip; do [ -z $ip ] continue ssh -o ConnectTimeout10 uosadmin$ip \ echo uosadmin:NewPass2025 | sudo chpasswd \ sudo chage -d 0 uosadmin echo changed done $1逻辑说明chpasswd从标准输入读取用户名:密码格式直接批量改密不产生交互chage -d 0把密码最后修改日期设为 0强制用户下次登录时修改密码这样运维设置的初始密码不会长期有效。脚本执行后如果输出changed说明这台机器改成功了。参数说明密码里的特殊字符要注意如果包含$、|、空格在 ssh 命令里要转义否则会被本地 shell 先解释掉。建议密码只用大小写字母、数字和有限的符号避免踩这种坑。另外统信UOS有密码复杂度策略过于简单的密码会被 PAM 拒绝chpasswd也会失败这种情况要看/var/log/auth.log。批量新建用户同理用useradd加chpasswd组合# 从 users.txt 逐行读取用户名批量创建账号并设初始密码 while read -r user; do [ -z $user ] continue ssh -o ConnectTimeout10 uosadmin$ip \ sudo useradd -m -s /bin/bash $user \ echo $user:Init2025 | sudo chpasswd done users.txt这里-m表示创建家目录-s /bin/bash指定登录 shell。统信UOS桌面版默认 shell 就是 bash但有些模板镜像里被改成 nologin批量创建用户后对方登录不了排查半天才发现是 shell 的问题。还有一个坑统信UOS里uosadmin在 sudo 组但 sudo 默认要密码。脚本里如果不加 NOPASSWD 配置ssh 执行sudo chpasswd时会卡在密码输入。要么在 sudoers 里给运维账号配NOPASSWD要么用echo 密码 | sudo -S后者会把密码暴露在命令行和日志里我不推荐。3.2 批量清理 wine 容器软件缓存先找缓存再动手统信UOS 上跑微信、QQ、WPS 这类 Windows 应用走的是 deepin-wine 容器。用久了之后~/.deepinwine目录会膨胀尤其那个“uos系统wine容器软件缓存清理”的话题基本每个运维都遇到过。清理前必须先搞清楚容器结构千万别整个目录删掉。#!/bin/bash # 清理指定用户的 wine 容器缓存保留容器本体 # 用法: ./clean_wine_cache.sh /home/uosadmin USER_HOME${1:-/home/uosadmin} for wine_dir in $USER_HOME/.deepinwine/*/; do [ -d $wine_dir ] || continue size$(du -sh $wine_dir 2/dev/null | cut -f1) echo before: $wine_dir ($size) # 只清理 cache 和 tmp 子目录不碰 drives_c、user.reg 等配置 find $wine_dir -type d -name cache -prune -exec rm -rf {} 2/dev/null find $wine_dir -type d -name tmp -prune -exec rm -rf {} 2/dev/null done echo done逻辑说明find加上-prune是为了在删除目录的同时不继续向下遍历-exec rm -rf {} 把匹配到的所有 cache/tmp 目录批量删除。只删这两个目录容器里的用户数据、登录态配置、聊天记录存放目录都保留。参数说明USER_HOME默认是/home/uosadmin如果批量清理多台机器上多个用户的 wine 目录外层再加一层对 IP 的循环即可。清理前要看有没有 wine 进程在跑应用运行时缓存文件被删可能导致进程崩溃。稳妥的做法是先pkill -f deepin-wine再清理清理后第一次启动应用会比较慢因为要重新建立缓存这不是故障。清出多少空间不固定微信的图片和文件缓存可能占几百 MB 到几个 G。建议脚本里顺带输出清理前后的大小记录方便写进运维报告别光删了不统计。3.3 软件安装的批量差异apt、dpkg 与 linglong 并存统信UOS的软件安装有三个通道系统源的apt、离线 deb 包的dpkg、以及统信商店的 linglong玲珑格式。批量装软件最容易出问题的点就是分不清目标机器上这个应用到底走哪个通道。离线 deb 包批量安装是内网常态#!/bin/bash # 批量安装离线 deb 包自动修复依赖 for ip in $(cat hosts.txt); do # 把本地 deb 包传到目标机临时目录 scp -o ConnectTimeout10 ./pkgs/*.deb uosadmin$ip:/tmp/pkgs/ ssh -o ConnectTimeout10 uosadmin$ip \ cd /tmp/pkgs sudo dpkg -i *.deb || sudo apt-get -f install -y done逻辑说明dpkg -i直接安装本地 deb 包不处理依赖如果因依赖缺失安装失败后面的apt-get -f install -y会自动从源里补齐依赖并完成安装。这个组合是离线装包的通用补救手段。注意apt-get -f需要网络源可用纯离线环境必须先准备好依赖 deb 包。linglong 应用走的是ll-cli命令它不经过 dpkg 数据库装完在/opt/apps或~/.linglong下。批量安装 linglong 包# 逐台安装 linglong 格式应用 while read -r ip; do scp ./apps/*.uab uosadmin$ip:/tmp/ ssh -o ConnectTimeout10 uosadmin$ip \ sudo ll-cli install /tmp/*.uab done hosts.txt参数说明uab 是 linglong 的离线包后缀ll-cli install安装后应用会出现在启动器里。与 dpkg 包不同的是linglong 包的卸载和升级都用ll-cli用dpkg -l查不到别混在一起管理。像 Photoshop 这类通过统信商店 Wine 通道分发的 Windows 应用也是 linglong 体系命令行里直接用 dpkg 装不上这是一个很容易误导人的差异点。字体这类资源类的包也常用 apt 装比如apt-get install fonts-wqy-microhei。但统信商店里很多字体是商业版权内网批量部署前要确认授权脚本能解决安装解决不了合规问题。4. 把驱动、时钟和双系统也纳入批量ch38x、ntpdate 与时间同步4.1 ch38x 驱动批量安装DKMS 与内核升级后的重建统信UOS接 USB 转串口设备最常见的是 ch38x 芯片设备插上后不识别lsusb能看到设备但/dev/ttyUSB0不出来基本就是缺驱动。批量装机时这台机器装一次驱动就够了但麻烦在于内核升级后驱动模块会丢。#!/bin/bash # 批量安装 ch38x 驱动 deb 包并加载内核模块 for ip in $(cat hosts.txt); do scp ch38x-dkms_*.deb uosadmin$ip:/tmp/ ssh -o ConnectTimeout10 uosadmin$ip \ sudo dpkg -i /tmp/ch38x-dkms_*.deb \ sudo modprobe ch38x \ lsmod | grep ch38x echo driver ok on $ip done逻辑说明dpkg -i安装 DKMS 驱动包DKMS 会在当前内核上编译并注册模块modprobe ch38x立即加载模块不需要重启lsmod | grep ch38x验证模块是否真的加载成功。参数说明为什么一定要装 DKMS 版本而不是手动make install手动编译的模块挂在当前内核目录下统信UOS一升级内核模块就找不到了设备又变砖。DKMS 包每次内核更新时自动重新编译这是血泪经验换来的结论。装完驱动后验证设备节点用ls /dev/ttyUSB*看到 ttyUSB0 才算真正可用。如果目标机器是 UOS 专业版 ARM 版ch38x 的源码包要重新交叉编译deb 包不能跨架构通用。批量安装前先确认 CPU 架构uname -m先扫一遍所有机器比装完发现一半失败再回头排查高效得多。4.2 内网批量校时ntpdate 与 timedatectl 的正确用法很多人习惯叫“统信系统 yum install ntpdate”其实统信是 Debian 系包名虽然还叫 ntpdate但安装命令是apt-get install ntpdate。内网机器时间漂移是个很隐蔽的问题日志对不上、证书校验失败、计划任务乱跑根子往往是时钟。#!/bin/bash # 批量对内网时间服务器校时并关闭 systemd-timesyncd 避免冲突 NTP_SERVER${1:-192.168.10.10} for ip in $(cat hosts.txt); do ssh -o ConnectTimeout10 uosadmin$ip \ sudo timedatectl set-ntp false \ sudo ntpdate -u $NTP_SERVER \ sudo hwclock --systohc done逻辑说明先关timedatectl set-ntp false停掉 systemd-timesyncd否则它和 ntpdate 同时跑会互相打架时间越对越乱。ntpdate -u使用非特权端口发起 NTP 请求很多内网防火墙默认挡 123 端口-u参数能绕开这个限制。最后hwclock --systohc把系统时间写回硬件时钟保证重启后时间不反弹。批量校时后还要让机器定期对时否则漂移是持续发生的。建议在控制端生成一个 crontab 片段批量推下去# 写入每 6 小时校时一次的计划任务 echo 0 */6 * * * /usr/sbin/ntpdate -u 192.168.10.10 /dev/null 21 | \ ssh uosadmin$ip sudo tee /etc/cron.d/ntp_sync参数说明crontab 文件放在/etc/cron.d/下而不是直接改用户的 crontab这样不依赖用户是否登录系统级计划任务到点就跑。注意ntpdate命令的绝对路径cron 环境下 PATH 很短写相对路径经常静默失败。4.3 双系统与虚拟机场景的时钟UTC、localtime 和 VMware 工具统信系统再装 Win10 双系统的机器时间差 8 小时是经典问题。原因是 Windows 把硬件时钟当本地时间Linux 默认把硬件时钟当 UTC两套系统各写各的来回切换就乱。批量处理这种机器要让统信UOS去迁就 Windows# 让统信系统把硬件时钟当作本地时间和 Windows 对齐 sudo timedatectl set-local-rtc 1 sudo hwclock --systohc --localtime逻辑说明set-local-rtc 1把 RTC硬件时钟的解释方式改为本地时间hwclock --systohc --localtime把当前系统时间按本地时间写回硬件时钟。这样 Windows 读硬件时钟、Linux 也读硬件时钟两边一致不再差 8 小时。参数说明这个设置只建议用在双系统桌面机。纯统信服务器或者跑虚拟化宿主机千万别开set-local-rtc 1服务器应该用 UTC 标准开了反而会和 NTP 对时逻辑冲突。运维脚本里最好按机器角色区分别一套配置推到全部机器上。虚拟机场景是另一个坑。统信UOS 装 VMware 虚拟机宿主机开了时间同步后虚拟机里的timedatectl status会显示 NTP 同步但时间依然偶尔跳变。原因通常是 VMware Tools 的 time sync 和虚拟机内部的 systemd-timesyncd 重复调校。批量部署虚拟机时建议统一策略要么信宿主机关掉内部 NTP要么信内部 NTP关掉 VMware 时间同步。两头都开就是来回拉扯的玄学现象。5. 批量操作脚本避坑记录现象、原因、解决一条条讲透5.1 批量执行层的三个常见翻车点坑一脚本第一次跑全部卡在主机指纹确认。现象批量脚本执行到第一台机器就停住屏幕上显示 “Are you sure you want to continue connecting (yes/no)”后面所有机器全部排队等待。原因ssh 首次连接陌生主机时默认策略是询问确认脚本里没有输入通道直接挂死。解决执行参数里加-o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null或者提前用ssh-keyscan把目标机指纹批量写入 known_hosts。前者适合一次性运维环境后者适合长期管理环境。我在骨架脚本里直接加了这两个参数省得每台机器都手工确认一次。坑二sudo 命令要求密码脚本中途停一半。现象前面的命令执行正常跑到sudo dpkg -i时终端停在密码提示后续命令全部不执行脚本没有报错也没有失败日志。原因统信UOS桌面版的 sudo 默认要验证密码。非交互式 ssh 会话里没有终端输入密码脚本就被挂住了。解决给运维专用账号配置 NOPASSWD。在 sudoers 里加一行# 允许 uosadmin 免密执行所有 sudo 命令仅用于受控运维账号 uosadmin ALL(ALL) NOPASSWD: ALL参数说明这条配置要写在/etc/sudoers.d/下的独立文件里不要直接改/etc/sudoers主文件升级系统时不容易被覆盖。注意 NOPASSWD 会让该账号拥有无口令 sudo 权限脚本安全靠的是密钥文件和受控网络别在普通用户账号上开这个权限。坑三一台机器不可达整个循环被拖死。现象hosts.txt 里混入一台已下线的机器脚本跑十几分钟才跳过去最后一看就这一台失败但整体耗时长到不可接受。原因ssh 默认连接超时很长尤其目标 IP 不可达时TCP 握手要等系统超时。解决加ConnectTimeout10甚至5脚本里严格区分连接失败和执行失败。连接失败直接记 FAIL 继续下一台不要把整个批次卡住。还可以改成后台并行执行每台机器跑最后统一wait几十台机器的批量任务能压缩到几分钟。5.2 统信系统本身的三个特性坑坑四清理 wine 缓存后应用登录态全丢。现象批量清理~/.deepinwine下的缓存目录第二天用户反馈微信要重新扫码登录聊天记录里的图片打不开QQ 群文件离线。原因脚本里 find 匹配范围写大了把整个 wine 容器目录或者drive_c用户数据目录一并删掉。另外清理时微信/QQ 进程还在运行正在写入的缓存文件被删数据目录元数据损坏。解决严格限定只删cache和tmp两个子目录清理前先pkill -f deepinwine。如果已经误删找备份恢复。这提醒我批量脚本里的 rm 命令路径匹配一定要先打印出来人工看一眼尤其是通配符场景。坑五时间偏差太大ntpdate 同步失败。现象内网机器时间差半小时以上执行ntpdate报错 “no server suitable for synchronization found”但时间服务器本身正常。原因ntpdate 默认的同步方式是 slewing渐进调整时间偏差超过阈值时拒绝直接跳变以免影响系统日志的连续性。解决先timedatectl set-ntp false再用ntpdate -b -u 时间服务器强制步进。-b参数让时间直接跳变适合开机初始化或长时间断网后的场景。批量脚本里我一般先date记录原时间同步后再date对比把差值写进日志方便确认每台机器到底偏了多少。坑六批量 dpkg 安装把系统依赖搞乱。现象批量装了一批旧版 deb 包部分机器提示依赖冲突继续跑apt-get -f install后系统里的核心库版本被改掉桌面环境异常。原因手动装 deb 包时dpkg 不检查版本全局一致性apt-get -f修复依赖时可能引入更高或更低版本和统信仓库里的其他包产生版本漂移。解决批量装 deb 包前先apt-get update装完对关键包执行apt-mark hold固定版本防止后续升级破坏兼容性。排查时看/var/log/dpkg.log里的安装顺序和版本记录比在终端里瞎猜要准。6. 给批量脚本补上校验与回滚幂等、日志和后悔药6.1 操作前的备份与操作后的校验批量操作最怕的不是出错是出错后不知道错在哪、也没法回头。我给脚本定的规矩是改配置文件前先备份执行完必须验证验证不通过就记 FAIL 并保留现场。# 执行前备份关键配置执行后验证结果 ssh uosadmin$ip \ sudo cp /etc/ntp.conf /etc/ntp.conf.bak.\$(date %F) \ sudo ntpdate -u 192.168.10.10 \ date \ timedatectl status | head -n 3逻辑说明备份文件带日期后缀不怕多次执行互相覆盖date显示当前系统时间timedatectl status显示 NTP 状态两个输出能直接判断校时是否生效。验证不通过时备份文件就是后悔药直接cp回去就能恢复。6.2 让脚本可重跑幂等写法与失败重试重复执行不搞坏系统是批量脚本的基本素质。比如批量创建用户先检查用户是否存在存在就跳过批量装驱动先lsmod | grep ch38x已加载就不再装。这样脚本即使跑两遍结果也是确定性的。我的习惯是每个脚本都留--check和--apply两档。--check只打印将要执行的操作和当前状态不实际改动确认影响面没问题再跑--apply。这个习惯救过我很多次尤其面对几百台机器时--check能把脚本里的低级错误挡在动手之前。日志只留最近的、带日期目录重试时只对 FAIL 列表里的机器重跑不把整个批次重新来一遍。批量脚本这行当写的时候多花半小时做校验和回滚跑的时候就能少熬一次夜。希望帮到你。本文还有配套的精品资源点击获取