简介这是一套面向运维人员、系统管理员和 Linux 初学者的一键修复与安装脚本专门解决各类 Linux 系统故障修复和服务器环境搭建问题。脚本支持 Ubuntu、CentOS、Debian 等主流发行版通过一条命令即可自动完成系统环境检测、软件包管理器修复、引导加载器重置、系统文件恢复以及 Web 或数据库服务器等环境的安装与配置大幅减少手动操作带来的失误。资源包共 24 个文件核心为 17 个 Shell 脚本同时包含 2 个 YAML 配置、2 个 TXT 说明、2 个 Markdown 文档和 1 个 License 文件压缩包整体仅 44KB非常轻量便于下载和备份。目前已有 153 人学习/浏览。其中既有可直接运行的修复/安装脚本也有可读的配置说明与文档能帮助读者快速定位并处理系统异常也可作为自动化运维脚本编写思路的参考。1. 一键修复与安装脚本运维手里最该留的一套 Linux 自救工具遇到服务器起不来、日志把磁盘塞满、系统源坏掉这些事最烦的不是问题本身而是每个发行版修法还不一样。这套一键修复与安装脚本就是把常见 Linux 故障处理和服务器环境安装整理成一条命令的开源仓库。运维、系统管理员、刚入手 Linux 的新手都能用它按 repair_scripts 和 install_scripts 两条线组织一边修系统修网络修启动一边装文件管理、流量监控、开发环境这类服务。Bash 写成覆盖 Ubuntu、Debian 等主流发行版执行前先检测系统类型再按分支处理整体不做任何假设拿过来就能在当前机器上跑。下面从仓库结构、修复模块、安装模块、踩坑和改造几个角度把它拆开你照着跑一遍就知道这套东西到底值不值得留在工具箱里。2. 仓库结构与核心模块先搞清楚脚本在修什么、装什么2.1 目录划分repair_scripts 与 install_scripts 的分工逻辑打开仓库根目录最显眼的就是 repair_scripts 和 install_scripts 两个文件夹这个划分本身就是整套脚本的设计核心。它把两类完全不同的操作分开修复是解决已有问题安装是从零搭环境。这两者的风险等级完全不同修复操作可能需要删文件、改内核参数、重配网络一旦出错系统可能直接失联安装操作是新增东西最多是装坏了再卸风险相对可控。作者把两类脚本物理隔离等于在提示使用者先判断你现在的状态是「坏了要修」还是「新的要装」别混着跑。repair_scripts 里放着的 unlimit.sh、check_sudo.sh、modify_time.sh、network.sh、resize_journal.sh、package.sh几乎全是针对 Linux 系统日常故障的。unlimit.sh 调整系统文件描述符和进程数上限check_sudo.sh 判断当前用户有没有 sudo 权限modify_time.sh 处理系统时间和时区同步network.sh 重配网络或修复网络服务resize_journal.sh 压缩 systemd-journald 日志占用package.sh 修复包管理器状态。这些脚本操作的层次各不相同有的是用户态配置有的是 systemd 服务有的直接动文件系统但它们共享一套执行风格先检测、后执行、再输出结果。这种风格保证了脚本即使跑在预期之外的系统上也能安全退出而不是硬碰硬出错。install_scripts 则完全不同它面向的是「装东西」。filebrowser.sh 装文件浏览器网盘vnstat.sh 装流量监控dlm.sh 看名字是 download manager 或某类下载工具cplusplus.sh 装 C 编译链jupyter.sh 装 Jupyter 环境R.sh 装 R 语言zipline.sh 装回测框架rust.sh 装 Rust 工具链fossbilling.sh 和 FOSSBilling-compose.yml 配合装 FOSSBilling 商业运营系统toubuntu22.sh 和 todebian11.sh 是把系统迁移到特定大版本。一眼扫过去这套东西的定位非常清晰给一台刚从云厂商面板开出来的裸机快速变成能干活的环境。它不需要你先手动装这个装那个脚本全程处理这也是它名字里 one-click 的底气所在。2.2 公共依赖检查check_sudo.sh 和 package.sh 的定位我一般会先看 check_sudo.sh它在整套脚本里承担「入场检查」的职责。Bash 脚本如果直接用 root 跑一切好说但如果你用普通用户执行安装类脚本apt 和 yum 都会直接报权限错误。check_sudo.sh 的常见做法是先跑 id -u 看用户 ID等于 0 就直接放行不等于 0 就检查 sudo -n true 是否能免密通过不行就提示你切换到 root 或输入密码。逻辑不复杂但这层检查能避免脚本跑了一半才发现没有权限非常关键。很多运维事故就是从这里开始的——脚本下载了、执行了装到一半报错你以为失败了要重来结果系统已经被改了一半留下一个中间状态比没装更麻烦。package.sh 我理解是包管理器修复脚本。Debian 系常见的问题就是 apt 的 dpkg 状态锁住了或者缺少依赖、broken package 残留。package.sh 的处理路径很典型检查 dpkg 锁文件 /var/lib/dpkg/lock-frontend删掉残留锁执行 dpkg --configure -a、apt --fix-broken install、apt update、apt upgrade 一条龙。这不是什么高深操作但执行顺序非常讲究——如果你不先解除 lock 和修复 broken package直接跑 upgrade 会因为依赖关系直接卡住。很多新手遇到 apt 报错第一反应是 rm -rf 锁文件这其实很危险因为如果确实有一个 apt 进程在跑删锁会导致两个进程同时操作包数据库直接把 dpkg 状态搞坏。package.sh 里一定先检查进程再删锁这个细节是合格脚本的标配。2.3 系统检测逻辑脚本如何知道你跑在什么发行版上这套脚本里要同时兼容 Ubuntu 和 Debian有时候还要面对 CentOS 转过来的机器发行版判断全靠 /etc/os-release。几乎所有合格脚本都会优先读这个文件因为它是现代 Linux 发行版的标准接口里面有 ID、VERSION_ID、PRETTY_NAME 等字段。像 toubuntu22.sh 和 todebian11.sh 这种迁移类脚本开头的逻辑一定是先抓当前系统版本然后对比目标版本决定能不能迁、迁的时候 apt 源要不要换。常见的检测写法是if [ -f /etc/os-release ]; then . /etc/os-release echo 当前发行版: $ID $VERSION_ID else echo 无法识别系统: /etc/os-release 不存在 exit 1 fi这里. /etc/os-release是把文件当作 shell 片段 source 进来ID、VERSION_ID 这些变量当前 shell 直接就能用。之后脚本往下执行时无论是选 apt 还是 yum还是判断要不要用 systemctl都靠这两个变量分流。它不依赖 lsb_release 命令是因为很多精简版系统没装 lsb-release 包但 /etc/os-release 是 base-files 的一部分几乎所有发行版都有。这是跨发行版兼容最稳的做法比 uname -a 抓内核版本可靠得多——uname 只能告诉你内核版本不能告诉你这是 Ubuntu 还是 Debian而很多操作偏偏就取决于发行版身份。另一个值得说的是脚本对 exit 1 的处理方式。如果系统无法识别脚本直接退出而不是默认按 Debian 或 Ubuntu 继续跑这是正确选择。发行版识别不了意味着后续源配置、包管理器调用、服务管理方式全都可能是错的硬跑下去只会制造更多故障。2.4 仓库里那几个非脚本文件debian.txt、ubuntu.txt、conda.md 的作用仓库里除了 .sh 脚本之外还有 debian.txt、ubuntu.txt、conda.md、README.md 这些非脚本文件很多人会忽略它们但它们在落地过程中其实有重要作用。debian.txt 和 ubuntu.txt 大概率是对应发行版的 apt 源模板里面记录的是经过验证可用的源地址列表。国内服务器经常遇到官方源连接超时的问题这两个文件里很可能就提供了备选方案。conda.md 应该是 conda 的安装备忘或使用说明。conda 是 Python 环境管理工具在数据科学领域用得非常多但它在服务器上是出了名的「装了之后 PATH 就乱」。conda.md 这类文档的价值在于把安装步骤和注意事项写清楚它不需要执行而是让你手动照着操作。README.md 则是整个仓库的使用说明书一般会写明每个脚本的用途、适用发行版、执行前提。在跑任何脚本之前先读一遍 README这是最基本的习惯能避免大多数低级错误。3. 修复类脚本逐个拆常见故障场景下的实际用法3.1 network.sh网络配置错了恢复比重装省事network.sh 这个脚本我盯着看了很久在 Linux 服务器故障里网络配置损坏是高频事件。常见场景有两种改错 /etc/network/interfaces 或 netplan 配置导致重启后失联或者 NetworkManager 和 systemd-networkd 两个服务打架导致网卡起不来。这个脚本的恢复逻辑我一般会把它分三层来看。第一层是检测读当前网卡名和连接状态判断是静态 IP 还是 DHCP看路由表是不是指向了正确的网关DNS 配置是不是被人改过。第二层是恢复根据发行版分支调用对应工具。Ubuntu 18.04 之后用 netplanDebian 还是 /etc/network/interfaces 老一套脚本里应该都有分支处理。第三层是验证ping 网关和公共 DNS 确认网络真正通了再退出。因为脚本本身是修复型的所以它在写网络配置之前通常会先备份原文件这也是「有后悔药」的设计思路。如果你要手动排查网络问题推荐顺序是ip addr看网卡状态ip route看网关cat /etc/resolv.conf看 DNS然后逐层修。network.sh 实际上是把这个排查过程脚本化了。我特别想强调一点很多人遇到网络问题第一反应是重启网络服务systemctl restart networking或systemctl restart NetworkManager。但如果网卡配置本身就是错的重启服务只会让服务起不来甚至直接失联。正确做法是先检查配置再决定是否重启这也是 network.sh 把检测放在恢复前面的原因。3.2 resize_journal.sh日志暴涨占满根分区时怎么救journald 日志占满磁盘是运维里最容易翻车的场景。默认的 journald 配置是只按大小限制不按时间清理如果系统跑了一两年没动过/var/log/journal 能吃掉几十 GB。我见过最夸张的一次日志把根分区塞了 98%MySQL 直接崩掉那台机器全是 IO 等待。resize_journal.sh 就是干这个的——它在 journald 日志变得不可控之前帮你把上限卡住。它的处理逻辑大概是先看 journald 当前占用用journalctl --disk-usage查看然后通过修改 /etc/systemd/journald.conf 里的 SystemMaxUse 参数控制上限比如设置成 500M最后执行journalctl --vacuum-size500M立即回收空间。关键是 SystemMaxUse 这个参数设多少要根据业务来日志量大的服务可以给 2G一般业务撑死 500M 就够给太少的话日志被频繁截断排障时反而找不到历史记录。修改 SystemMaxUse 后需要重启 journald 服务命令是systemctl restart systemd-journald但注意重启不会清日志只是让新配置生效。如果想立即看到效果得先 vacuum 再重启。生产环境建议顺序是先journalctl --vacuum-size500M清理到安全水位再重启 journald 让配置生效。顺序如果反了重启瞬间 journald 重新读取配置尝试分配新大小而磁盘已经满了可能导致服务启动失败。还有一个细节journald 的持久化日志在 /var/log/journal 目录如果系统压根没建这个目录journald 只会把日志放内存里重启就没了。这种情况你磁盘不会被吃满但也意味着你丢失了历史日志排障时很被动。脚本应该也会检查这个目录是否存在不存在则创建并设置权限为 root:systemd-journal。3.3 unlimit.sh 与 modify_time.sh系统参数修正的两件小事unlimit.sh 处理的是 ulimit 类限制。Linux 默认的 nofile 文件描述符上限一般是 1024高并发服务跑到几百个连接就卡住MySQL 和 Redis 都容易受这个影响。脚本要做的就是把 nofile 和 nproc 调到合理值比如 nofile 65535、nproc 无限制。修改位置是 /etc/security/limits.conf标准格式是用户名 类型 项目 值比如* soft nofile 65535和* hard nofile 65535soft 是软限制hard 是硬限制应用进程可以自己把软限制往上调但不能超过硬限制。注意一点修改 limits.conf 只对重新登录的会话生效已运行的服务进程不会自动感知。你改完文件之后要么重启服务要么重新登录。我在实战中遇到过一次改完 ulimit 之后 Redis 还是报 too many open files原因就是配置改了但 Redis 进程没重启进程还是带着旧的 1024 限制在跑。如果有服务是在 systemd 里跑的还需要在 service 文件里加LimitNOFILE65535普通 limits.conf 对它没用因为 systemd 管理的进程不读 limits.conf,它有自己的资源限制参数体系。unlimit.sh 如果检测到 systemd 服务应该也会处理这个分支。modify_time.sh 处理时间同步。服务器时间不准会导致日志时间轴混乱、HTTPS 证书验证失败、定时任务错乱——cron 在时间错乱时可能根本不会触发或触发多次。脚本一般做三件事安装或启用 chrony 或 ntpdate从 ntp.aliyun.com 这类国内源同步一次然后写定时任务定期校准。为什么不用老 ntp 服务因为 chrony 在云服务器和容器环境里同步速度更快而且 systemd 时代很多发行版默认就是 chrony。脚本里如果检测到 systemd-timesyncd 已启用那连 chrony 都不用装直接timedatectl set-ntp true就完事。值得留意的是时区问题时间同步通常只解决「偏移」不解决「时区」。你在阿里云开一台香港地域的服务器默认时区可能是 UTC需要额外执行timedatectl set-timezone Asia/Shanghai改成本地时区modify_time.sh 是否包含这个逻辑取决于脚本作者的选择。3.4 发行版迁移辅助toubuntu22.sh 和 todebian11.sh 在做什么这两个脚本名字很直白升级到 Ubuntu 22.04、迁移到 Debian 11。它们处理的不是简单的apt upgrade而是跨大版本升级的完整链路。跨大版本升级和日常apt upgrade有本质区别后者只是把你当前版本内的软件包更新到最新内核和系统库版本不变前者会替换整个基础系统包括内核、libc、systemd这个过程如果中断系统可能直接无法启动。跨版本升级有几个必须做的事先把所有 sources.list 里的源换成目标版本代号执行apt update和apt full-upgrade处理被 hold 的包最后重启验证内核。fossbilling-compose.yml 和 fossbilling.sh 这两个脚本放在 install_scripts 目录下负责的是 FOSSBilling 业务的安装——前者是 Docker Compose 编排文件后者可能是独立安装路径两者并存说明作者同时考虑了容器化和非容器化两种部署方式。我要提醒的是跨版本升级脚本是所有脚本里风险最高的它不是修复类脚本那种「改了能恢复」的性质。升级过程中断网、断电、内核不兼容都会造成系统无法启动。我一般会把它们用在测试环境验证生产环境至少打一个快照再考虑执行。这两个脚本的价值在于把 do-release-upgrade 之前的手动步骤自动化了特别是源更换和旧包清理这两个环节人工操作非常容易出错。源写错一个字母apt update 就全红然后你又要花半小时排查。脚本至少能保证源格式和版本号是对的。4. 安装类脚本实战从文件管理到科学计算环境的搭建4.1 filebrowser.sh一条命令拉起个人网盘filebrowser 是一个基于 Go 的单二进制文件浏览器程序通过浏览器管理服务器上的文件上传下载都很方便特别适合给不会 SSH 的同事用。filebrowser.sh 干的事情就是下载二进制、创建 systemd 服务、配置开机自启这三步。安装路径通常选 /usr/local/bin配置文件和数据文件放在 /etc/filebrowser 或 /var/lib/filebrowser 下端口默认是 8080但要留意防火墙有没有放行——云服务器安全组规则和本地 iptables 都可能拦截这个端口脚本里应该包含放行逻辑。我通常这样手动装 filebrowser先从 GitHub Releases 下载对应架构的二进制解压到 /usr/local/bin然后用 systemd 写一个 unit 文件指向它。脚本化的好处是这些步骤全自动。关键参数有这些--address绑定监听地址默认 0.0.0.0 监听所有网卡不要只绑定 127.0.0.1否则远程访问不到--port监听端口建议改一个不常用的高位端口减少扫描攻击风险--root是文件管理器的根目录根据需要设置成 /mnt/data 或 /home不要直接用 /否则整个文件系统都暴露在 Web 端一旦账号泄露后果不可控。装好后浏览器访问http://服务器IP:8080第一次进去会让你创建管理员账号。filebrowser 默认数据目录在当前用户目录下为了让多个用户共用可以在启动参数里指定--database和--config的路径。另外 filebrowser 的权限模型是「数据库文件权限 目录权限」双重校验root 用户能看啥不能看啥由数据库控制普通用户又受系统目录权限限制。想给同事开一个「只能看 /data 目录」的账号创建用户时把 scope 限定在 /data 即可这个设计比裸跑 Nginx 文件索引要安全得多。4.2 vnstat.sh流量监控装好后怎么读数据vnstat 是 Linux 下传统且好用的流量统计工具基于网卡采集数据不依赖第三方服务数据存在本地 sqlite 数据库里。vnstat.sh 应该就是做安装、初始化数据库、启服务这三件事。装好之后核心命令有这几个vnstat -d查看某一天的流量vnstat -m按月统计vnstat -l实时看带宽使用vnstat -q看数据库整体状态。如果你发现 vnstat 显示的流量和云厂商控制台对不上多半是因为云厂商按虚拟网卡统计vnstat 按物理网卡统计名称不一样——常见的是 eth0 和 ens3 的区别。解决办法是确认脚本统计的是哪个网卡vnstat --show查看当前启用的接口列表如果默认统计的 ens3 不是你要的 eth0用vnstat -i eth0手动指定或者在 /etc/vnstat.conf 里改 Interface 参数然后重启 vnstatd 服务。vnstat 的数据采集依赖 vnstatd 后台进程装完不启动服务是不会有数据的。服务启动后要等几分钟才有记录它是定时轮询不是实时事件采集所以新手跑完脚本发现没有数据输出就以为失败了其实是采集周期没到。建议每跑完一个脚本就用systemctl status vnstatd确认服务是 active 状态而不是只看安装命令执行结果。还有一个点是 vnstat 不会自动监控新插入的网卡比如你后来加了个 eth1需要手动vnstat -i eth1 -u初始化数据库。4.3 jupyter.sh 与 R.sh数据科学工作台的一次性部署jupyter.sh 在服务器上装 Jupyter 是个高频需求不少数据工程师拿到一台 Linux 服务器第一件事就是装 Jupyter。脚本的逻辑一般是安装 Python3 和 pip然后用 pip 安装 jupyterlab最后生成配置文件并启动服务。这里有一个选型问题你是用 pip 直接装 jupyter还是用 Anaconda/Miniconda 装由于仓库里有 conda.md大概率作者也关注到了 conda 方案。conda 的好处是 Python 环境自带不会和系统 Python 冲突特别适合在纯净服务器上部署数据科学环境坏处是安装包大、启动慢、PATH 容易乱。Jupyter 装好后有个安全问题必须处理默认配置只监听 localhost远程访问必须改成监听 0.0.0.0同时要设置 access password不然任何人都能访问你的服务器相当于把执行权拱手让人。Jupyter 的密码不是明文存在配置文件里的它是用jupyter notebook password生成哈希字符串存在 jupyter_notebook_config.json 里。脚本如果有交互环节会提示你输入密码并写入这个文件。如果你不设密码Jupyter 默认会生成一个随机的 token 打印在启动日志里那个 token 就是你的钥匙——问题是很多人重启服务后忘了去翻日志然后死活连不上。R.sh 装的 R 语言环境核心是 r-base 包但你直接apt install r-base装出来的版本通常不是最新的。R 官方推荐的装法是加 CRAN 源然后导入签名密钥。CRAN 的 Debian/Ubuntu 源配置在 /etc/apt/sources.list.d/ 下单独文件里标准写法是deb https://cloud.r-project.org/bin/linux/ubuntu jammy-cran40/。如果脚本里加了 R 源需要注意国内访问 CRAN 可能很慢建议换成清华 TUNA 镜像。R 装完之后还要考虑 RStudio Server 的问题那是另一个包脚本如果只装了 R 内核没有装 RStudio Server你需要自己额外搞定。4.4 rust.sh 和 cplusplus.sh开发环境脚本的选型细节rust.sh 大概率是装 rustup。Rust 官方推荐的方式不是直接apt install cargo而是通过 rustup 安装因为 rustup 可以自由切换 stable/beta/nightly 工具链而且 apt 里的 Rust 版本通常偏旧。rustup 安装脚本的标准喂法是从 sh.rustup.rs 下载然后管道给 sh 执行装完会往 ~/.cargo/bin 写环境变量同时修改 ~/.bashrc 让它自动加载。脚本化的意义就在于这条高危命令很多人不敢执行——从远端 curl 管道到 sh 确实有安全隐患因为你看不到管道里到底跑的是什么。仓库脚本至少会把 rustup 的安装包下载下来再执行有些实现会先检查下载文件的校验值这样安全性会好很多。rust 装完之后还有几个要手动确认的rustup 默认安装在用户目录root 跑脚本和普通用户跑脚本装的位置不一样如果你用 sudo 跑了 rustup 安装脚本它会把工具链装在 /root/.cargo 下普通用户登录后却找不到 cargo这也是一键脚本最常见的坑之一。cplusplus.sh 装的应该是编译工具链gcc、g、make、cmake。Debian/Ubuntu 上装 C 环境其实不用那么麻烦apt install build-essential一个包全搞定。如果脚本还装了 CMake 和特定版本的 gcc那大概率是面向项目开发的不是基础编译环境。要注意的是 Ubuntu 22.04 默认 GCC 是 11.x有些老项目要求 GCC 9 或 10脚本如果直接装最新版不做版本管理反而会坑到这些人。值得考虑的做法是同时安装gcc-10 g-10然后用update-alternatives切换默认版本这样老项目和新项目都能编译两不耽误。5. 避坑与常见问题排查这些脚本跑不动大多是这个原因5.1 现象脚本提示无权限或卡在 sudo 检查执行脚本报sudo: a terminal is required to read the password或者一直提示你没有权限脚本卡在第一个交互点不往下走。原因脚本在非 root 用户下执行但脚本内部没有处理交互输入 sudo 密码的情况。你用sh script.sh跑脚本sudo 无法从非终端环境读取密码输入。解决先su -切到 root 再执行或者确保脚本是以 root 身份调用的。如果必须用非 root 用户可以先用sudo -v预认证 sudo 缓存再跑脚本这样后续 sudo 不需要重新输入密码。注意 sudo 缓存默认只有 15 分钟有效期跑超过 15 分钟的长任务前最好再确认一次权限是否还有效。5.2 现象Debian 下执行 Ubuntu 专用脚本报错脚本里用了apt-add-repository命令但 Debian 系统提示command not found,或者源文件路径不对apt update 直接报错说 source 列表格式不正确。原因apt-add-repository是 Ubuntu 的 software-properties-common 包提供的命令Debian 默认没装而且 Debian 的源列表格式和 Ubuntu 不完全一样。把 Ubuntu 的源直接写进 Debian 的 sources.listapt update 时就会报错。解决在脚本执行前手动检查 /etc/os-release 的 ID确认当前是 debian 还是 ubuntu。缺少命令就先apt install software-properties-common补上。我常用的做法是先跑脚本里的检测函数看到输出确认当前系统分支再决定要不要继续。如果脚本里确实没有 Debian 分支那就不要硬跑手动照着 Ubuntu 版本文档在 Debian 上操作把源地址和包名换成 Debian 对应的。5.3 现象安装一半断网导致包管理器源状态损坏执行 apt 安装过程被中断之后每次 apt update 都报could not get lock /var/lib/dpkg/lock-frontendapt 和 dpkg 全部无法使用。原因apt 被强制终止后锁文件残留dpkg 状态处于不一致状态后续包操作无法继续。解决先ps aux | grep apt确认没有 apt 进程在跑然后删除锁文件加修复sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock sudo dpkg --configure -a sudo apt --fix-broken install sudo apt update删除锁文件前必须确认没有 apt-get 或 dpkg 进程活着否则删完锁文件两个进程同时操作包数据库会污染状态。按这个顺序跑完绝大多数 dpkg 锁问题都能恢复。这个操作的价值在于防止脚本因中断留下半安装状态。5.4 现象systemd vs init旧版本系统的隐藏差异脚本里用了 systemctl 重启服务但你在老 CentOS 6 或 Debian 7 机器上跑提示systemctl command not found服务没起来日志也看不到。原因这些老系统用的是 SysV init 体系不支持 systemd 命令。脚本只检测了发行版没有检测 init 系统类型跑在旧系统上就翻了。解决在脚本执行前读 /proc/1/comm 看 PID 1 是 systemd 还是 init。如果是 init就用service命令替代 systemctl。如果你不想改脚本那就预判一下目标系统的主版本Ubuntu 14.04 及以前、Debian 7 及以前都不支持 systemd。现在拿到一台机器第一步就是确认系统版本和 init 类型这个信息决定后面所有操作的基础比任何脚本都重要。5.5 现象conda.md 和 debian.txt 这类文档文件怎么配合使用仓库里打包的 conda.md、debian.txt、ubuntu.txt 是纯文本或 Markdown 文件有人拿它们当脚本执行或者以为它们会自动生效结果什么都没发生。原因这些是文档或配置模板不是可执行脚本。debian.txt 和 ubuntu.txt 是源列表模板conda.md 是 conda 的安装说明备忘需要手动打开阅读按里面的命令逐步操作。解决把 debian.txt 的内容和 /etc/apt/sources.list 对比把模板里的地址替换成你本地可用的镜像源再保存。conda.md 直接用编辑器打开看它写的安装命令和使用技巧。文档文件的作用是给你参考不是给系统跑的。6. 落地进阶把一键脚本改造成自己的运维工具箱6.1 改造一脚本参数化和日志输出拿到这套脚本后第一步不是直接用而是把每条命令的执行结果落到日志里。常见做法是给脚本加一个 LOG_DIR 变量用 exec 重定向 stderr 到日志文件LOG_DIR/var/log/ops-scripts mkdir -p $LOG_DIR LOG_FILE$LOG_DIR/$(date %Y%m%d-%H%M%S)-$(basename $0).log exec (tee -a $LOG_FILE) 21这段代码把脚本的标准输出和错误输出同时送到屏幕和日志文件等于给脚本全程录了像。后面排查问题直接翻日志文件的最后几十行不用重新跑一遍脚本才能复现报错。建议把这个片段放在脚本顶部的检测函数之前保证从第一行命令开始就有日志记录。第二个改造点是参数化。脚本如果写死了网卡名 eth0你可以改成动态检测或者用一个环境变量传入NIC_NAME${NIC_NAME:-eth0}这样换到 ens3 的机器上可以NIC_NAMEens3 ./network.sh指定网卡不用打开文件改代码。这个改动成本极低维护价值很高。6.2 改造二与 cron 或 CI/CD 结合把脚本加入定时任务可以解决巡检类问题resize_journal.sh 每周跑一次防止日志悄悄涨满磁盘modify_time.sh 每天跑一次防止云主机时间自动漂移。cron 写法如下0 3 * * * /root/scripts/repair_scripts/resize_journal.sh --vacuum-size500M /var/log/journal-clean.log 21这里特别注意cron 环境变量和交互 shell 不一样。PATH 可能没包含 /usr/local/bin 或 /sbin脚本里用到的外部命令要在脚本开头显式export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。否则 cron 里脚本跑起来报的错多半是「command not found」不是脚本逻辑问题。我在排查定时任务时踩过最多坑的就是这里。6.3 验证方法用最小化虚拟机跑一遍脚本脚本改完之后拿生产机器直接跑太冒险。我一般先开一台同版本最小化安装的虚拟机把脚本放进去跑一遍验证三个点第一脚本有没有未捕获的非零退出码第二执行完服务是否正常启动第三是否存在重启后失效的临时配置。最小化系统能暴露脚本对基础依赖的假设——比如假设 curl 或 wget 已经装好了但最小化系统里根本找不到这些命令这类问题在生产机器上可能不明显因为生产环境装的东西多依赖凑巧都在。跑完脚本后重启虚拟机再验证服务状态。这个动作花十分钟能避免脚本在生产环境跑出意外。从那以后我每次部署新脚本都强制走一遍「最小化虚拟机全流程验证」这个流程确认脚本在干净环境下也能跑通才允许进生产。这套脚本跑通之后你会发现它最大的价值不只是省时间而是把容易记错、写错、忘记做的琐碎步骤固化成一条命令让每一次操作都可复现、可回溯。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 19:49:01 · 阅读 1.2k 运维自救：Linux一键修复与安装脚本全解析
简介这是一套面向运维人员、系统管理员和 Linux 初学者的一键修复与安装脚本专门解决各类 Linux 系统故障修复和服务器环境搭建问题。脚本支持 Ubuntu、CentOS、Debian 等主流发行版通过一条命令即可自动完成系统环境检测、软件包管理器修复、引导加载器重置、系统文件恢复以及 Web 或数据库服务器等环境的安装与配置大幅减少手动操作带来的失误。资源包共 24 个文件核心为 17 个 Shell 脚本同时包含 2 个 YAML 配置、2 个 TXT 说明、2 个 Markdown 文档和 1 个 License 文件压缩包整体仅 44KB非常轻量便于下载和备份。目前已有 153 人学习/浏览。其中既有可直接运行的修复/安装脚本也有可读的配置说明与文档能帮助读者快速定位并处理系统异常也可作为自动化运维脚本编写思路的参考。1. 一键修复与安装脚本运维手里最该留的一套 Linux 自救工具遇到服务器起不来、日志把磁盘塞满、系统源坏掉这些事最烦的不是问题本身而是每个发行版修法还不一样。这套一键修复与安装脚本就是把常见 Linux 故障处理和服务器环境安装整理成一条命令的开源仓库。运维、系统管理员、刚入手 Linux 的新手都能用它按 repair_scripts 和 install_scripts 两条线组织一边修系统修网络修启动一边装文件管理、流量监控、开发环境这类服务。Bash 写成覆盖 Ubuntu、Debian 等主流发行版执行前先检测系统类型再按分支处理整体不做任何假设拿过来就能在当前机器上跑。下面从仓库结构、修复模块、安装模块、踩坑和改造几个角度把它拆开你照着跑一遍就知道这套东西到底值不值得留在工具箱里。2. 仓库结构与核心模块先搞清楚脚本在修什么、装什么2.1 目录划分repair_scripts 与 install_scripts 的分工逻辑打开仓库根目录最显眼的就是 repair_scripts 和 install_scripts 两个文件夹这个划分本身就是整套脚本的设计核心。它把两类完全不同的操作分开修复是解决已有问题安装是从零搭环境。这两者的风险等级完全不同修复操作可能需要删文件、改内核参数、重配网络一旦出错系统可能直接失联安装操作是新增东西最多是装坏了再卸风险相对可控。作者把两类脚本物理隔离等于在提示使用者先判断你现在的状态是「坏了要修」还是「新的要装」别混着跑。repair_scripts 里放着的 unlimit.sh、check_sudo.sh、modify_time.sh、network.sh、resize_journal.sh、package.sh几乎全是针对 Linux 系统日常故障的。unlimit.sh 调整系统文件描述符和进程数上限check_sudo.sh 判断当前用户有没有 sudo 权限modify_time.sh 处理系统时间和时区同步network.sh 重配网络或修复网络服务resize_journal.sh 压缩 systemd-journald 日志占用package.sh 修复包管理器状态。这些脚本操作的层次各不相同有的是用户态配置有的是 systemd 服务有的直接动文件系统但它们共享一套执行风格先检测、后执行、再输出结果。这种风格保证了脚本即使跑在预期之外的系统上也能安全退出而不是硬碰硬出错。install_scripts 则完全不同它面向的是「装东西」。filebrowser.sh 装文件浏览器网盘vnstat.sh 装流量监控dlm.sh 看名字是 download manager 或某类下载工具cplusplus.sh 装 C 编译链jupyter.sh 装 Jupyter 环境R.sh 装 R 语言zipline.sh 装回测框架rust.sh 装 Rust 工具链fossbilling.sh 和 FOSSBilling-compose.yml 配合装 FOSSBilling 商业运营系统toubuntu22.sh 和 todebian11.sh 是把系统迁移到特定大版本。一眼扫过去这套东西的定位非常清晰给一台刚从云厂商面板开出来的裸机快速变成能干活的环境。它不需要你先手动装这个装那个脚本全程处理这也是它名字里 one-click 的底气所在。2.2 公共依赖检查check_sudo.sh 和 package.sh 的定位我一般会先看 check_sudo.sh它在整套脚本里承担「入场检查」的职责。Bash 脚本如果直接用 root 跑一切好说但如果你用普通用户执行安装类脚本apt 和 yum 都会直接报权限错误。check_sudo.sh 的常见做法是先跑 id -u 看用户 ID等于 0 就直接放行不等于 0 就检查 sudo -n true 是否能免密通过不行就提示你切换到 root 或输入密码。逻辑不复杂但这层检查能避免脚本跑了一半才发现没有权限非常关键。很多运维事故就是从这里开始的——脚本下载了、执行了装到一半报错你以为失败了要重来结果系统已经被改了一半留下一个中间状态比没装更麻烦。package.sh 我理解是包管理器修复脚本。Debian 系常见的问题就是 apt 的 dpkg 状态锁住了或者缺少依赖、broken package 残留。package.sh 的处理路径很典型检查 dpkg 锁文件 /var/lib/dpkg/lock-frontend删掉残留锁执行 dpkg --configure -a、apt --fix-broken install、apt update、apt upgrade 一条龙。这不是什么高深操作但执行顺序非常讲究——如果你不先解除 lock 和修复 broken package直接跑 upgrade 会因为依赖关系直接卡住。很多新手遇到 apt 报错第一反应是 rm -rf 锁文件这其实很危险因为如果确实有一个 apt 进程在跑删锁会导致两个进程同时操作包数据库直接把 dpkg 状态搞坏。package.sh 里一定先检查进程再删锁这个细节是合格脚本的标配。2.3 系统检测逻辑脚本如何知道你跑在什么发行版上这套脚本里要同时兼容 Ubuntu 和 Debian有时候还要面对 CentOS 转过来的机器发行版判断全靠 /etc/os-release。几乎所有合格脚本都会优先读这个文件因为它是现代 Linux 发行版的标准接口里面有 ID、VERSION_ID、PRETTY_NAME 等字段。像 toubuntu22.sh 和 todebian11.sh 这种迁移类脚本开头的逻辑一定是先抓当前系统版本然后对比目标版本决定能不能迁、迁的时候 apt 源要不要换。常见的检测写法是if [ -f /etc/os-release ]; then . /etc/os-release echo 当前发行版: $ID $VERSION_ID else echo 无法识别系统: /etc/os-release 不存在 exit 1 fi这里. /etc/os-release是把文件当作 shell 片段 source 进来ID、VERSION_ID 这些变量当前 shell 直接就能用。之后脚本往下执行时无论是选 apt 还是 yum还是判断要不要用 systemctl都靠这两个变量分流。它不依赖 lsb_release 命令是因为很多精简版系统没装 lsb-release 包但 /etc/os-release 是 base-files 的一部分几乎所有发行版都有。这是跨发行版兼容最稳的做法比 uname -a 抓内核版本可靠得多——uname 只能告诉你内核版本不能告诉你这是 Ubuntu 还是 Debian而很多操作偏偏就取决于发行版身份。另一个值得说的是脚本对 exit 1 的处理方式。如果系统无法识别脚本直接退出而不是默认按 Debian 或 Ubuntu 继续跑这是正确选择。发行版识别不了意味着后续源配置、包管理器调用、服务管理方式全都可能是错的硬跑下去只会制造更多故障。2.4 仓库里那几个非脚本文件debian.txt、ubuntu.txt、conda.md 的作用仓库里除了 .sh 脚本之外还有 debian.txt、ubuntu.txt、conda.md、README.md 这些非脚本文件很多人会忽略它们但它们在落地过程中其实有重要作用。debian.txt 和 ubuntu.txt 大概率是对应发行版的 apt 源模板里面记录的是经过验证可用的源地址列表。国内服务器经常遇到官方源连接超时的问题这两个文件里很可能就提供了备选方案。conda.md 应该是 conda 的安装备忘或使用说明。conda 是 Python 环境管理工具在数据科学领域用得非常多但它在服务器上是出了名的「装了之后 PATH 就乱」。conda.md 这类文档的价值在于把安装步骤和注意事项写清楚它不需要执行而是让你手动照着操作。README.md 则是整个仓库的使用说明书一般会写明每个脚本的用途、适用发行版、执行前提。在跑任何脚本之前先读一遍 README这是最基本的习惯能避免大多数低级错误。3. 修复类脚本逐个拆常见故障场景下的实际用法3.1 network.sh网络配置错了恢复比重装省事network.sh 这个脚本我盯着看了很久在 Linux 服务器故障里网络配置损坏是高频事件。常见场景有两种改错 /etc/network/interfaces 或 netplan 配置导致重启后失联或者 NetworkManager 和 systemd-networkd 两个服务打架导致网卡起不来。这个脚本的恢复逻辑我一般会把它分三层来看。第一层是检测读当前网卡名和连接状态判断是静态 IP 还是 DHCP看路由表是不是指向了正确的网关DNS 配置是不是被人改过。第二层是恢复根据发行版分支调用对应工具。Ubuntu 18.04 之后用 netplanDebian 还是 /etc/network/interfaces 老一套脚本里应该都有分支处理。第三层是验证ping 网关和公共 DNS 确认网络真正通了再退出。因为脚本本身是修复型的所以它在写网络配置之前通常会先备份原文件这也是「有后悔药」的设计思路。如果你要手动排查网络问题推荐顺序是ip addr看网卡状态ip route看网关cat /etc/resolv.conf看 DNS然后逐层修。network.sh 实际上是把这个排查过程脚本化了。我特别想强调一点很多人遇到网络问题第一反应是重启网络服务systemctl restart networking或systemctl restart NetworkManager。但如果网卡配置本身就是错的重启服务只会让服务起不来甚至直接失联。正确做法是先检查配置再决定是否重启这也是 network.sh 把检测放在恢复前面的原因。3.2 resize_journal.sh日志暴涨占满根分区时怎么救journald 日志占满磁盘是运维里最容易翻车的场景。默认的 journald 配置是只按大小限制不按时间清理如果系统跑了一两年没动过/var/log/journal 能吃掉几十 GB。我见过最夸张的一次日志把根分区塞了 98%MySQL 直接崩掉那台机器全是 IO 等待。resize_journal.sh 就是干这个的——它在 journald 日志变得不可控之前帮你把上限卡住。它的处理逻辑大概是先看 journald 当前占用用journalctl --disk-usage查看然后通过修改 /etc/systemd/journald.conf 里的 SystemMaxUse 参数控制上限比如设置成 500M最后执行journalctl --vacuum-size500M立即回收空间。关键是 SystemMaxUse 这个参数设多少要根据业务来日志量大的服务可以给 2G一般业务撑死 500M 就够给太少的话日志被频繁截断排障时反而找不到历史记录。修改 SystemMaxUse 后需要重启 journald 服务命令是systemctl restart systemd-journald但注意重启不会清日志只是让新配置生效。如果想立即看到效果得先 vacuum 再重启。生产环境建议顺序是先journalctl --vacuum-size500M清理到安全水位再重启 journald 让配置生效。顺序如果反了重启瞬间 journald 重新读取配置尝试分配新大小而磁盘已经满了可能导致服务启动失败。还有一个细节journald 的持久化日志在 /var/log/journal 目录如果系统压根没建这个目录journald 只会把日志放内存里重启就没了。这种情况你磁盘不会被吃满但也意味着你丢失了历史日志排障时很被动。脚本应该也会检查这个目录是否存在不存在则创建并设置权限为 root:systemd-journal。3.3 unlimit.sh 与 modify_time.sh系统参数修正的两件小事unlimit.sh 处理的是 ulimit 类限制。Linux 默认的 nofile 文件描述符上限一般是 1024高并发服务跑到几百个连接就卡住MySQL 和 Redis 都容易受这个影响。脚本要做的就是把 nofile 和 nproc 调到合理值比如 nofile 65535、nproc 无限制。修改位置是 /etc/security/limits.conf标准格式是用户名 类型 项目 值比如* soft nofile 65535和* hard nofile 65535soft 是软限制hard 是硬限制应用进程可以自己把软限制往上调但不能超过硬限制。注意一点修改 limits.conf 只对重新登录的会话生效已运行的服务进程不会自动感知。你改完文件之后要么重启服务要么重新登录。我在实战中遇到过一次改完 ulimit 之后 Redis 还是报 too many open files原因就是配置改了但 Redis 进程没重启进程还是带着旧的 1024 限制在跑。如果有服务是在 systemd 里跑的还需要在 service 文件里加LimitNOFILE65535普通 limits.conf 对它没用因为 systemd 管理的进程不读 limits.conf,它有自己的资源限制参数体系。unlimit.sh 如果检测到 systemd 服务应该也会处理这个分支。modify_time.sh 处理时间同步。服务器时间不准会导致日志时间轴混乱、HTTPS 证书验证失败、定时任务错乱——cron 在时间错乱时可能根本不会触发或触发多次。脚本一般做三件事安装或启用 chrony 或 ntpdate从 ntp.aliyun.com 这类国内源同步一次然后写定时任务定期校准。为什么不用老 ntp 服务因为 chrony 在云服务器和容器环境里同步速度更快而且 systemd 时代很多发行版默认就是 chrony。脚本里如果检测到 systemd-timesyncd 已启用那连 chrony 都不用装直接timedatectl set-ntp true就完事。值得留意的是时区问题时间同步通常只解决「偏移」不解决「时区」。你在阿里云开一台香港地域的服务器默认时区可能是 UTC需要额外执行timedatectl set-timezone Asia/Shanghai改成本地时区modify_time.sh 是否包含这个逻辑取决于脚本作者的选择。3.4 发行版迁移辅助toubuntu22.sh 和 todebian11.sh 在做什么这两个脚本名字很直白升级到 Ubuntu 22.04、迁移到 Debian 11。它们处理的不是简单的apt upgrade而是跨大版本升级的完整链路。跨大版本升级和日常apt upgrade有本质区别后者只是把你当前版本内的软件包更新到最新内核和系统库版本不变前者会替换整个基础系统包括内核、libc、systemd这个过程如果中断系统可能直接无法启动。跨版本升级有几个必须做的事先把所有 sources.list 里的源换成目标版本代号执行apt update和apt full-upgrade处理被 hold 的包最后重启验证内核。fossbilling-compose.yml 和 fossbilling.sh 这两个脚本放在 install_scripts 目录下负责的是 FOSSBilling 业务的安装——前者是 Docker Compose 编排文件后者可能是独立安装路径两者并存说明作者同时考虑了容器化和非容器化两种部署方式。我要提醒的是跨版本升级脚本是所有脚本里风险最高的它不是修复类脚本那种「改了能恢复」的性质。升级过程中断网、断电、内核不兼容都会造成系统无法启动。我一般会把它们用在测试环境验证生产环境至少打一个快照再考虑执行。这两个脚本的价值在于把 do-release-upgrade 之前的手动步骤自动化了特别是源更换和旧包清理这两个环节人工操作非常容易出错。源写错一个字母apt update 就全红然后你又要花半小时排查。脚本至少能保证源格式和版本号是对的。4. 安装类脚本实战从文件管理到科学计算环境的搭建4.1 filebrowser.sh一条命令拉起个人网盘filebrowser 是一个基于 Go 的单二进制文件浏览器程序通过浏览器管理服务器上的文件上传下载都很方便特别适合给不会 SSH 的同事用。filebrowser.sh 干的事情就是下载二进制、创建 systemd 服务、配置开机自启这三步。安装路径通常选 /usr/local/bin配置文件和数据文件放在 /etc/filebrowser 或 /var/lib/filebrowser 下端口默认是 8080但要留意防火墙有没有放行——云服务器安全组规则和本地 iptables 都可能拦截这个端口脚本里应该包含放行逻辑。我通常这样手动装 filebrowser先从 GitHub Releases 下载对应架构的二进制解压到 /usr/local/bin然后用 systemd 写一个 unit 文件指向它。脚本化的好处是这些步骤全自动。关键参数有这些--address绑定监听地址默认 0.0.0.0 监听所有网卡不要只绑定 127.0.0.1否则远程访问不到--port监听端口建议改一个不常用的高位端口减少扫描攻击风险--root是文件管理器的根目录根据需要设置成 /mnt/data 或 /home不要直接用 /否则整个文件系统都暴露在 Web 端一旦账号泄露后果不可控。装好后浏览器访问http://服务器IP:8080第一次进去会让你创建管理员账号。filebrowser 默认数据目录在当前用户目录下为了让多个用户共用可以在启动参数里指定--database和--config的路径。另外 filebrowser 的权限模型是「数据库文件权限 目录权限」双重校验root 用户能看啥不能看啥由数据库控制普通用户又受系统目录权限限制。想给同事开一个「只能看 /data 目录」的账号创建用户时把 scope 限定在 /data 即可这个设计比裸跑 Nginx 文件索引要安全得多。4.2 vnstat.sh流量监控装好后怎么读数据vnstat 是 Linux 下传统且好用的流量统计工具基于网卡采集数据不依赖第三方服务数据存在本地 sqlite 数据库里。vnstat.sh 应该就是做安装、初始化数据库、启服务这三件事。装好之后核心命令有这几个vnstat -d查看某一天的流量vnstat -m按月统计vnstat -l实时看带宽使用vnstat -q看数据库整体状态。如果你发现 vnstat 显示的流量和云厂商控制台对不上多半是因为云厂商按虚拟网卡统计vnstat 按物理网卡统计名称不一样——常见的是 eth0 和 ens3 的区别。解决办法是确认脚本统计的是哪个网卡vnstat --show查看当前启用的接口列表如果默认统计的 ens3 不是你要的 eth0用vnstat -i eth0手动指定或者在 /etc/vnstat.conf 里改 Interface 参数然后重启 vnstatd 服务。vnstat 的数据采集依赖 vnstatd 后台进程装完不启动服务是不会有数据的。服务启动后要等几分钟才有记录它是定时轮询不是实时事件采集所以新手跑完脚本发现没有数据输出就以为失败了其实是采集周期没到。建议每跑完一个脚本就用systemctl status vnstatd确认服务是 active 状态而不是只看安装命令执行结果。还有一个点是 vnstat 不会自动监控新插入的网卡比如你后来加了个 eth1需要手动vnstat -i eth1 -u初始化数据库。4.3 jupyter.sh 与 R.sh数据科学工作台的一次性部署jupyter.sh 在服务器上装 Jupyter 是个高频需求不少数据工程师拿到一台 Linux 服务器第一件事就是装 Jupyter。脚本的逻辑一般是安装 Python3 和 pip然后用 pip 安装 jupyterlab最后生成配置文件并启动服务。这里有一个选型问题你是用 pip 直接装 jupyter还是用 Anaconda/Miniconda 装由于仓库里有 conda.md大概率作者也关注到了 conda 方案。conda 的好处是 Python 环境自带不会和系统 Python 冲突特别适合在纯净服务器上部署数据科学环境坏处是安装包大、启动慢、PATH 容易乱。Jupyter 装好后有个安全问题必须处理默认配置只监听 localhost远程访问必须改成监听 0.0.0.0同时要设置 access password不然任何人都能访问你的服务器相当于把执行权拱手让人。Jupyter 的密码不是明文存在配置文件里的它是用jupyter notebook password生成哈希字符串存在 jupyter_notebook_config.json 里。脚本如果有交互环节会提示你输入密码并写入这个文件。如果你不设密码Jupyter 默认会生成一个随机的 token 打印在启动日志里那个 token 就是你的钥匙——问题是很多人重启服务后忘了去翻日志然后死活连不上。R.sh 装的 R 语言环境核心是 r-base 包但你直接apt install r-base装出来的版本通常不是最新的。R 官方推荐的装法是加 CRAN 源然后导入签名密钥。CRAN 的 Debian/Ubuntu 源配置在 /etc/apt/sources.list.d/ 下单独文件里标准写法是deb https://cloud.r-project.org/bin/linux/ubuntu jammy-cran40/。如果脚本里加了 R 源需要注意国内访问 CRAN 可能很慢建议换成清华 TUNA 镜像。R 装完之后还要考虑 RStudio Server 的问题那是另一个包脚本如果只装了 R 内核没有装 RStudio Server你需要自己额外搞定。4.4 rust.sh 和 cplusplus.sh开发环境脚本的选型细节rust.sh 大概率是装 rustup。Rust 官方推荐的方式不是直接apt install cargo而是通过 rustup 安装因为 rustup 可以自由切换 stable/beta/nightly 工具链而且 apt 里的 Rust 版本通常偏旧。rustup 安装脚本的标准喂法是从 sh.rustup.rs 下载然后管道给 sh 执行装完会往 ~/.cargo/bin 写环境变量同时修改 ~/.bashrc 让它自动加载。脚本化的意义就在于这条高危命令很多人不敢执行——从远端 curl 管道到 sh 确实有安全隐患因为你看不到管道里到底跑的是什么。仓库脚本至少会把 rustup 的安装包下载下来再执行有些实现会先检查下载文件的校验值这样安全性会好很多。rust 装完之后还有几个要手动确认的rustup 默认安装在用户目录root 跑脚本和普通用户跑脚本装的位置不一样如果你用 sudo 跑了 rustup 安装脚本它会把工具链装在 /root/.cargo 下普通用户登录后却找不到 cargo这也是一键脚本最常见的坑之一。cplusplus.sh 装的应该是编译工具链gcc、g、make、cmake。Debian/Ubuntu 上装 C 环境其实不用那么麻烦apt install build-essential一个包全搞定。如果脚本还装了 CMake 和特定版本的 gcc那大概率是面向项目开发的不是基础编译环境。要注意的是 Ubuntu 22.04 默认 GCC 是 11.x有些老项目要求 GCC 9 或 10脚本如果直接装最新版不做版本管理反而会坑到这些人。值得考虑的做法是同时安装gcc-10 g-10然后用update-alternatives切换默认版本这样老项目和新项目都能编译两不耽误。5. 避坑与常见问题排查这些脚本跑不动大多是这个原因5.1 现象脚本提示无权限或卡在 sudo 检查执行脚本报sudo: a terminal is required to read the password或者一直提示你没有权限脚本卡在第一个交互点不往下走。原因脚本在非 root 用户下执行但脚本内部没有处理交互输入 sudo 密码的情况。你用sh script.sh跑脚本sudo 无法从非终端环境读取密码输入。解决先su -切到 root 再执行或者确保脚本是以 root 身份调用的。如果必须用非 root 用户可以先用sudo -v预认证 sudo 缓存再跑脚本这样后续 sudo 不需要重新输入密码。注意 sudo 缓存默认只有 15 分钟有效期跑超过 15 分钟的长任务前最好再确认一次权限是否还有效。5.2 现象Debian 下执行 Ubuntu 专用脚本报错脚本里用了apt-add-repository命令但 Debian 系统提示command not found,或者源文件路径不对apt update 直接报错说 source 列表格式不正确。原因apt-add-repository是 Ubuntu 的 software-properties-common 包提供的命令Debian 默认没装而且 Debian 的源列表格式和 Ubuntu 不完全一样。把 Ubuntu 的源直接写进 Debian 的 sources.listapt update 时就会报错。解决在脚本执行前手动检查 /etc/os-release 的 ID确认当前是 debian 还是 ubuntu。缺少命令就先apt install software-properties-common补上。我常用的做法是先跑脚本里的检测函数看到输出确认当前系统分支再决定要不要继续。如果脚本里确实没有 Debian 分支那就不要硬跑手动照着 Ubuntu 版本文档在 Debian 上操作把源地址和包名换成 Debian 对应的。5.3 现象安装一半断网导致包管理器源状态损坏执行 apt 安装过程被中断之后每次 apt update 都报could not get lock /var/lib/dpkg/lock-frontendapt 和 dpkg 全部无法使用。原因apt 被强制终止后锁文件残留dpkg 状态处于不一致状态后续包操作无法继续。解决先ps aux | grep apt确认没有 apt 进程在跑然后删除锁文件加修复sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock sudo dpkg --configure -a sudo apt --fix-broken install sudo apt update删除锁文件前必须确认没有 apt-get 或 dpkg 进程活着否则删完锁文件两个进程同时操作包数据库会污染状态。按这个顺序跑完绝大多数 dpkg 锁问题都能恢复。这个操作的价值在于防止脚本因中断留下半安装状态。5.4 现象systemd vs init旧版本系统的隐藏差异脚本里用了 systemctl 重启服务但你在老 CentOS 6 或 Debian 7 机器上跑提示systemctl command not found服务没起来日志也看不到。原因这些老系统用的是 SysV init 体系不支持 systemd 命令。脚本只检测了发行版没有检测 init 系统类型跑在旧系统上就翻了。解决在脚本执行前读 /proc/1/comm 看 PID 1 是 systemd 还是 init。如果是 init就用service命令替代 systemctl。如果你不想改脚本那就预判一下目标系统的主版本Ubuntu 14.04 及以前、Debian 7 及以前都不支持 systemd。现在拿到一台机器第一步就是确认系统版本和 init 类型这个信息决定后面所有操作的基础比任何脚本都重要。5.5 现象conda.md 和 debian.txt 这类文档文件怎么配合使用仓库里打包的 conda.md、debian.txt、ubuntu.txt 是纯文本或 Markdown 文件有人拿它们当脚本执行或者以为它们会自动生效结果什么都没发生。原因这些是文档或配置模板不是可执行脚本。debian.txt 和 ubuntu.txt 是源列表模板conda.md 是 conda 的安装说明备忘需要手动打开阅读按里面的命令逐步操作。解决把 debian.txt 的内容和 /etc/apt/sources.list 对比把模板里的地址替换成你本地可用的镜像源再保存。conda.md 直接用编辑器打开看它写的安装命令和使用技巧。文档文件的作用是给你参考不是给系统跑的。6. 落地进阶把一键脚本改造成自己的运维工具箱6.1 改造一脚本参数化和日志输出拿到这套脚本后第一步不是直接用而是把每条命令的执行结果落到日志里。常见做法是给脚本加一个 LOG_DIR 变量用 exec 重定向 stderr 到日志文件LOG_DIR/var/log/ops-scripts mkdir -p $LOG_DIR LOG_FILE$LOG_DIR/$(date %Y%m%d-%H%M%S)-$(basename $0).log exec (tee -a $LOG_FILE) 21这段代码把脚本的标准输出和错误输出同时送到屏幕和日志文件等于给脚本全程录了像。后面排查问题直接翻日志文件的最后几十行不用重新跑一遍脚本才能复现报错。建议把这个片段放在脚本顶部的检测函数之前保证从第一行命令开始就有日志记录。第二个改造点是参数化。脚本如果写死了网卡名 eth0你可以改成动态检测或者用一个环境变量传入NIC_NAME${NIC_NAME:-eth0}这样换到 ens3 的机器上可以NIC_NAMEens3 ./network.sh指定网卡不用打开文件改代码。这个改动成本极低维护价值很高。6.2 改造二与 cron 或 CI/CD 结合把脚本加入定时任务可以解决巡检类问题resize_journal.sh 每周跑一次防止日志悄悄涨满磁盘modify_time.sh 每天跑一次防止云主机时间自动漂移。cron 写法如下0 3 * * * /root/scripts/repair_scripts/resize_journal.sh --vacuum-size500M /var/log/journal-clean.log 21这里特别注意cron 环境变量和交互 shell 不一样。PATH 可能没包含 /usr/local/bin 或 /sbin脚本里用到的外部命令要在脚本开头显式export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。否则 cron 里脚本跑起来报的错多半是「command not found」不是脚本逻辑问题。我在排查定时任务时踩过最多坑的就是这里。6.3 验证方法用最小化虚拟机跑一遍脚本脚本改完之后拿生产机器直接跑太冒险。我一般先开一台同版本最小化安装的虚拟机把脚本放进去跑一遍验证三个点第一脚本有没有未捕获的非零退出码第二执行完服务是否正常启动第三是否存在重启后失效的临时配置。最小化系统能暴露脚本对基础依赖的假设——比如假设 curl 或 wget 已经装好了但最小化系统里根本找不到这些命令这类问题在生产机器上可能不明显因为生产环境装的东西多依赖凑巧都在。跑完脚本后重启虚拟机再验证服务状态。这个动作花十分钟能避免脚本在生产环境跑出意外。从那以后我每次部署新脚本都强制走一遍「最小化虚拟机全流程验证」这个流程确认脚本在干净环境下也能跑通才允许进生产。这套脚本跑通之后你会发现它最大的价值不只是省时间而是把容易记错、写错、忘记做的琐碎步骤固化成一条命令让每一次操作都可复现、可回溯。希望帮到你。本文还有配套的精品资源点击获取