简介这套一键修复与安装脚本面向Linux运维人员、系统管理员及初中级学习者用于应对Ubuntu、CentOS、Debian等发行版在系统修复、软件包管理、启动引导等方面常见问题也可覆盖服务器环境初始化、故障重建与日常维护等典型场景。资源包共24个文件以17个Shell脚本为主体搭配YAML编排、Markdown笔记、说明文档和License压缩后仅44KB体积虽小但覆盖场景较广。脚本包括系统检测、包管理器修复、引导加载器重置、网络配置与日志清理等核心逻辑并提供Web面板、数据库、R语言、Rust、Jupyter等常用服务环境的一键安装入口其中针对Ubuntu 22和Debian 11的适配脚本加上解除系统限制、检查sudo权限、调整时间等辅助工具可用于快速完成服务器初始化。目前已有一百余人学习使用。读者可直接修改脚本参数用于自有环境也能从分段函数、错误处理、发行版差异性适配中掌握跨平台自动化脚本的设计方法降低手工操作带来的误配置风险。1. 一键修复与安装脚本把环境操作从「敲命令」变成「锁死流程」干过几年服务器维护的人都有过这种体验手敲几十条命令装好一套环境一台机器花掉半天过两个月另一台机器再装却因为内核版本差了一个小版本某条依赖编译不过去一查又是俩小时。所谓一键修复与安装脚本(One-click)本质是把「系统修复」和「服务器环境安装」这两类高频且重复的操作压缩成一段可保存、可复查、可复用的代码。它解决的不是少敲几条命令的省事问题而是让每次操作的结果一致。适合运维、DevOps也包括在自己电脑上反复折腾环境构建的开发。这篇笔记讲的就是这个方向怎么写、参数怎么定、坑在哪。2. 脚本骨架先行修复与安装两条腿不能混着走写一键脚本最忌讳的是把「修机器」和「装环境」当成一回事。修复脚本面对的是已经坏掉的系统软件源失效、引导分区损坏、磁盘只读操作前必须先探测、再动刀。安装脚本面对的是半新或全新的系统依赖缺失、编译选项不一致、服务起不来操作逻辑是顺序编排、逐项校验。两者目标不同但共用一套「发行版识别 架构检测」的底座。这个底座没搭好后面任何分支都是空中楼阁。2.1 两类脚本的分工修机器和装环境为什么不能是同一个入口我见过不少翻车案例典型表现是一个install.sh里又改源又装依赖又顺手重挂/boot跑完一个环节失败后面所有逻辑跟着乱套。修复脚本和环境安装脚本应该拆成两个独立入口或者至少用一个显式的参数分发case $1 in repair) run_repair ;; install) run_install ;; detect) detect_platform ;; *) echo Usage: $0 {repair|install|detect} exit 1 ;; esac这样做的好处很实际修复动作通常需要在紧急情况下执行安装动作则要能反复跑。入口分开后两者的日志文件、备份目录、回滚策略都可以各自独立不会互相覆盖。我一般会在项目里约定repair.sh只负责系统级维修install.sh只负责服务环境搭建二者共享同一个common.sh公共函数库。2.2 通用外壳发行版与架构检测整个脚本的立足点是detect_platform函数。它必须能在主流发行版和常见的国产化系统上吐出「发行版 版本 架构」三元组后续所有分支都靠它路由。下面是简化版实现#!/bin/bash detect_platform() { local distrounknown version_idunknown arch if [ -r /etc/os-release ]; then # shellcheck disableSC1091 . /etc/os-release distro${ID:-unknown} version_id${VERSION_ID:-unknown} elif [ -r /etc/redhat-release ]; then distrocentos version_id$(sed -n s/.*release \([0-9][0-9]*\).*/\1/p /etc/redhat-release) fi arch$(uname -m) case $arch in x86_64|aarch64) : ;; i386|i686) archx86 ;; *) arch$arch ;; esac echo $distro $version_id $arch } if [ $(detect_platform) unknown unknown x86_64 ]; then echo unsupported platform 2 exit 1 fi这段逻辑有几个关键点。第一/etc/os-release是 systemd 时代的标准发布信息文件绝大多数发行版都会带上包括麒麟、统信等国产系统的发行版也能正常读取到ID字段。第二CentOS 7 及更早版本没有标准的os-release回退到/etc/redhat-release解析大版本号是常见做法。第三uname -m拿到的架构名在 Debian 系和 RedHat 系之间有差异统一映射成x86_64、aarch64、x86三类即可。这个函数是所有一键脚本的地基。检测失败时宁可退出也不要硬着头皮继续跑因为后续apt、dnf、zypper的调用全是发行版强相关的猜错一个就整段崩掉。脚本开头加一句set -euo pipefail也是常见做法让未定义变量和管道失败尽早暴露。2.3 包管理器差异是最大的隐藏陷阱同一条命令在不同发行版上的包管理器可能完全不同。下面是快速对照发行版包管理器源配置文件Debian / Ubuntuapt/etc/apt/sources.listCentOS 7yum/etc/yum.repos.d/*.repoRocky / AlmaLinux 8dnf/etc/yum.repos.d/*.repoopenSUSEzypper/etc/zypp/repos.d/*.repoFedoradnf/etc/yum.repos.d/*.repo很多一键脚本在 CentOS 7 上执行了dnf install直接报错因为 CentOS 7 默认只有 yum。反向的坑也有在 Debian 系统上执行yum。所以脚本里凡是涉及安装依赖的地方都应该用command -v探测包管理器存在性再走对应分支。检测完发行版之后先安装一组基础工具链curl、wget、tar、gcc、make 等再进入主逻辑这样能避免后面每走一步都要重复判断。3. 系统修复脚本的核心实现从更新软件源到修复引导系统修复脚本要处理的问题按我遇到的频率排序大概是软件源失效、引导损坏、磁盘挂载异常、关键服务起不来。这一章拆开讲前两大块因为它们的操作风险最高也最需要脚本化。任何修复动作都要有「先备份、再操作、可回滚」的自觉哪怕目标是自动化也要给操作者留后悔药。3.1 软件源故障修复先探测、再备份、后替换软件源问题在服务器环境里最常见的是这些情况系统安装时间太久源里的地址已经失效内网环境需要切换到私有镜像或者/etc/apt/sources.list被不知名的工具改坏。修复脚本要做的事是把当前源文件备份再写入一套可用的配置。switch_mirror() { local distro version arch read -r distro version arch $(detect_platform) local mirror${1:?mirror url is required} local bak/etc/apt/sources.list.bak.$(date %F) case $distro in debian|ubuntu) cp /etc/apt/sources.list $bak cat /etc/apt/sources.list EOF deb ${mirror}/ubuntu/ ${version}/ main restricted universe multiverse deb ${mirror}/ubuntu/ ${version}-updates main restricted universe multiverse EOF apt-get update ;; centos|rocky|almalinux) cp -r /etc/yum.repos.d /etc/yum.repos.d.bak.$(date %F) cat /etc/yum.repos.d/base.repo EOF [base] namebase baseurl${mirror}/\$releasever/BaseOS/\$basearch/os/ enabled1 gpgcheck0 EOF dnf makecache ;; esac }这里的核心细节是${1:?mirror url is required}它保证调用者必须传一个镜像地址参数空参数直接报错退出而不是带着空字符串去拼 URL 然后把源文件写坏。另外注意两点备份文件名带了日期这样同一个脚本跑多次时不会互相覆盖旧备份写入源文件后立刻执行一次apt-get update或dnf makecache验证配置是否可用——如果更新失败脚本应该立刻从备份恢复而不是继续往下走。实际项目中切换软件源还有一个隐藏点Debian 的 VERSION_ID 是12这样的数字但 apt 源需要的是代号bookworm。这里我通常会用lsb_release -cs拿代号或者在脚本里维护一张「版本号到代号」的映射表否则写出来的源根本解析不了那才是真正的黑匣子。3.2 磁盘与引导分区检查避免修复完起不来引导修复是一键修复脚本里风险最高的操作。很多人直接在没确认 root 分区位置的情况下执行grub-install /dev/sda结果重启后卡在grub提示符。一个合格的修复脚本需要在执行引导安装前完成三件事确认目标磁盘、确认/boot是否是独立分区、确认当前 root 分区设备。repair_grub() { local target_disk${1:?target disk is required, e.g. /dev/sda} local boot_part root_part root_part$(findmnt -n -o SOURCE /) if findmnt -n /boot /dev/null 21; then boot_part$(findmnt -n -o SOURCE /boot) echo boot is a separate partition: $boot_part grub-install --boot-directory/boot $target_disk else echo boot is inside root partition: $root_part grub-install --boot-directory$root_part/boot $target_disk fi if command -v update-grub /dev/null; then update-grub elif command -v grub2-mkconfig /dev/null; then grub2-mkconfig -o /boot/grub2/grub.cfg else grub-mkconfig -o /boot/grub/grub.cfg fi }findmnt -n -o SOURCE /这条命令比df -h /更精确它直接输出根文件系统对应的设备节点不经过列宽格式化方便脚本里接着用。而判断/boot是否是独立分区决定了--boot-directory参数应该指向哪里——这个参数指向错了grub 装了也白装重启照样进不了系统。安装完引导之后还有一道update-grub或者grub2-mkconfig用来重新扫描内核列表。这里三选一的分支也是发行版差异的典型体现Debian 系叫update-grubRHEL 系叫grub2-mkconfig有些精简系统两个都没有得直接调grub-mkconfig。遇到修复完依然进不去系统的情况就得手动进grub交互行执行ls看一下分区表再用set root手动指定内核分区——这部分没法全自动得靠人工兜底。3.3 幂等性设计同一个脚本能跑两遍才配叫一键修复脚本最大的敌人是「跑第二次时把第一次修好的东西再坏一遍」。幂等性设计的核心原则是任何操作在重复执行时都应该被安全跳过或者被安全覆盖。比如备份文件时用bak.$(date %F)而不是固定名字这样同一周内重复跑老备份不会被覆盖。另外在修复动作前加状态判断if [ -x /boot/vmlinuz-* ] grep -q menuentry /boot/grub/grub.cfg 2/dev/null; then echo grub.cfg looks fine, skip mkconfig else update-grub fi这种「先检查再操作」的模式能避免脚本在用户已经手工修复一半的系统上强行重做节省时间也降低风险。另一个重要设计是修复脚本里绝不使用未经二次确认的rm -rf尤其是对路径变量的展开不加保护时一条rm -rf $TMPDIR/*在变量为空时等于rm -rf /*这是能直接把系统干翻的毁灭性操作。后面避坑章节会再展开讲。4. 服务器环境安装脚本LNMP 的函数化编排与参数固化环境安装脚本是另一个方向。它面对的是从零到能跑的状态核心诉求是「按固定参数安装一套环境中并且装完能自检」。这里我选 LNMPNginx PHP MySQL/MariaDB作为例子因为这是服务器环境安装脚本最典型的需求之一覆盖面广编译参数也多适合讲清楚编排思路。4.1 安装过程的模块化函数设计把每个组件的安装拆成独立函数是让脚本可维护的第一个关键。每个函数只干一件事函数入口做幂等判断安装逻辑集中在一个文件里install_nginx() { local prefix/usr/local/nginx if [ -x $prefix/sbin/nginx ]; then echo nginx already installed, skip return 0 fi apt-get install -y libpcre3-dev zlib1g-dev libssl-dev cd /tmp curl -LO https://nginx.org/download/nginx-1.24.0.tar.gz tar xf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure \ --prefix$prefix \ --with-http_ssl_module \ --with-pcre make -j$(nproc) make install }函数里先检查$prefix/sbin/nginx是否存在存在就直接返回这是上一章说的幂等原则的延续。编译参数里的--with-http_ssl_module是 HTTPS 必需项很多人用发行版自带的 nginx 不用编译但源码安装时最容易漏掉的就是这个模块等要用 HTTPS 了才发现编译时没带上。make -j$(nproc)会让编译用满所有 CPU 核心但如果服务器内存只有 1G开 8 个编译线程很容易内存耗尽触发 OOM。这里我一般会加一层保护NPROC$(nproc) [ $NPROC -gt 4 ] NPROC4 make -j$NPROC编译类安装脚本还有一个常见问题源码包下载地址写死了一个具体版本号过两年这个版本在官方站点被清理脚本就彻底失效。常见做法是把版本号提升为脚本顶部的变量方便在不用改逻辑的前提下快速切换版本。4.2 依赖预检没有源码谁也装不上编译安装脚本翻车最多的环节不是编译本身而是编译前的依赖缺失。Nginx 需要 PCRE 和 OpenSSL 的开发头文件PHP 需要 libxml2、sqlite3 等一堆依赖少一个 configure 就会中途报错。与其让用户等 configure 跑完才发现缺东西不如在脚本开头做一次集中预检check_deps() { local deps(curl wget gcc make libpcre3-dev zlib1g-dev libssl-dev) local missing() for d in ${deps[]}; do if ! dpkg -s $d /dev/null 21; then missing($d) fi done if [ ${#missing[]} -gt 0 ]; then echo missing packages: ${missing[*]} apt-get install -y ${missing[]} fi }这段代码用dpkg -s做包存在性检查比which更可靠因为有些库是头文件包没有可执行文件。检测到缺失的包一次性装齐而不是每装一个组件就装一次依赖既省时间又减少重复测探。RHEL 系对应的检查命令应该是rpm -q这个分支要按发行版区分。依赖预检做完之后configure 阶段的报错率会大幅下降脚本的成功率也因此明显提升。4.3 安装后的自检与日志固化脚本跑完不等于环境装好了。装完不自检的一键脚本等于没有测试的交付物跑完显示 success实际页面打不开最后用户还得自己一行行查。我通常在每个组件安装后加一个自检函数并把安装全程的屏幕输出固化到日志文件里exec (tee -a /var/log/oneclick_install.log) 21 check_service() { local svc$1 systemctl enable $svc /dev/null 21 systemctl restart $svc sleep 2 if systemctl is-active $svc /dev/null 21; then echo [OK] $svc is running else echo [FAIL] $svc failed to start journalctl -u $svc -n 30 --no-pager exit 1 fi }exec (tee ...)这一行的作用是脚本里所有输出都同时打到终端和日志文件相当于给黑匣子开了条数据通道。遇到服务起不来的情况脚本自动把最近 30 行日志打出来操作者不用再手动敲journalctl。sleep 2是给 systemd 留出启动缓冲如果不加一些启动稍慢的服务在刚 restart 完立刻检查时会被误判为启动失败。这是典型的「参数要留给时间」的案例等两秒的成本比误报之后的排查成本低得多。PHP-FPM、MySQL 这类服务启动本来就慢建议单独把 sleep 拉长到 5 秒。4.4 配置文件下发的统一入口环境安装的最后一个环节是配置下发。装好的服务如果配置文件没有按预期写入整个环境等于白装。我一般会把每个组件的配置模板放在脚本同级的conf/目录下安装完成后用install -m 0644统一拷贝到对应位置。这样用户修改配置只需要改模板文件不需要改脚本本体。配置模板和脚本分离也是让一键脚本在团队里可以被非运维人员安全使用的重要原因——写配置的人不需要碰脚本逻辑改脚本逻辑的人不需要懂业务配置。5. 避坑记录一键脚本最常见的 5 个翻车点这一章把前面埋的雷集中引爆按「现象 → 原因 → 解决」逐条写每条都是我实际踩过的或者其他项目里见过的真实案例。5.1 CentOS 7 上执行了 dnf脚本直接退出现象脚本在 CentOS 7 上跑走到安装依赖时报dnf: command not found整个脚本中断。原因CentOS 7 的默认包管理器是 yumdnf 直到 CentOS 8 才成为默认。脚本里没有按照发行版版本区分包管理器而是直接写死了dnf install。解决脚本里用command -v dnf || command -v yum动态选择包管理器。更稳妥的方式是在detect_platform拿到版本号之后用 case 分支指定 CentOS 7 走 yumCentOS/Rocky 8 走 dnf。同一类问题还会出现在apt-get和apt混用上Debian 系统上两者都可以用但在精简容器里可能只有其中一个建议统一只用apt-get。5.2 grub 修完重启卡在 grub 提示符现象在/boot是独立分区的服务器上执行grub-install /dev/sda重启后进不了系统停在 grub 交互界面。原因--boot-directory参数没有指向/boot分区的挂载点grub 的核心文件被装到了根分区下的目录而 BIOS 根本不知道去那里找。解决执行 grub-install 前用findmnt -n /boot确认/boot是否为独立分区。是独立分区时--boot-directory/boot指向挂载点是根分区的一部分时--boot-directory/boot和挂载在根下的路径一致但也要确认根分区已经挂载好。另外修复完不要急着重启先用grep menuentry /boot/grub/grub.cfg确认内核条目已经生成再安排重启。5.3 源码安装的 PHP-FPM 启动后立刻退出现象安装脚本显示 PHP 编译安装成功但运行systemctl start php-fpm后服务立即 inactive日志里也没有明显报错。原因源码安装的 PHP 默认不会自动生成 systemd 的 unit 文件脚本里只是手动启动了进程并没有注册成服务更隐蔽的情况是 php-fpm 的listen配置指向的 socket 目录不存在导致进程启动后无法创建 socket 而退出。解决源码安装后必须手动生成 systemd unit 文件常见做法是写一个/etc/systemd/system/php-fpm.service内容包含ExecStart指向编译产物的绝对路径。同时配置里的listen /run/php/php-fpm.sock需要确保/run/php目录存在通常用 unit 文件里的RuntimeDirectoryphp声明systemd 会在启动前自动创建。5.4 更换 HTTPS 镜像源后apt update 报证书校验失败现象更换国内知名镜像站之后执行apt-get update报出Certificate verification failed之类的错误。原因系统的 ca-certificates 包没有安装或者证书库太旧无法信任镜像站的 SSL 证书。解决在换源之前先执行apt-get install -y ca-certificates确保系统有完整的根证书库。这条顺序细节特别容易忽略因为大多数系统的证书库是自带的但精简 Docker 镜像和最小化安装的服务器上经常缺失。换源后再遇到证书错误先检查/etc/ssl/certs是否为空再怀疑源的问题。5.5 清理缓存时 rm -rf 变量为空系统文件被删现象脚本执行到清理缓存步骤时系统崩溃重启后大量基础命令丢失无法正常进入系统。原因清理函数里写了rm -rf $TMPDIR/*但TMPDIR在非交互式 bash 里通常为空变量展开后变成了rm -rf /*。这是所有一键脚本里最致命的一个错误。解决清理类操作必须用${VAR:?}做防御性展开rm -rf ${TMPDIR:?}/*在变量为空时会直接报错而不执行删除。同时脚本开头加set -u让任何未定义变量的使用立即中断执行。删除操作前打印即将删除的路径给操作者最后一次中途停下的机会也是值得保留的习惯。这种事故一旦发生基本只能靠快照或备份恢复没有后悔药。6. 收尾技巧在容器里预演脚本再上真实服务器调试一键脚本的最终技巧是在真实服务器上执行之前先在干净容器里完整预演一遍。不要只在环境一致的机器上测试最值得测的是「从零开始」的路径——容器就是全新的系统没有任何历史包袱。docker run --rm -it \ -v $PWD:/work \ -w /work \ ubuntu:22.04 \ bash -x ./repair.sh detectbash -x会把每一行命令展开后的实际执行结果打印出来是最直观的追踪工具。第一次跑还不放心的话可以先跑bash -n ./repair.sh做静态语法检查能过滤掉一半的低级错误比如 if 忘写 then、大括号没闭合。还有shellcheck这个静态分析工具装了之后扫一遍能提前发现变量未加引号之类的隐患。在容器里预演时要重点观察几件事脚本是否区分了容器环境和实体机环境——比如容器里执行systemctl会提示不可用修复脚本要在这种环境下优雅跳过而不是直接报错终止。我自己的习惯是凡是给生产用的安装脚本必须附带一条「干净环境验证记录」哪怕就是一行命令加一段输出也证明这个脚本在某个时间点从零跑通过。这条记录能省掉后面接手的人大量的重复验证时间也逼着自己不在未验证的情况下把脚本丢出去。容器里跑完一遍之后还要做一次「重复执行验证」同一个脚本连续跑两遍第二遍应该安全跳过已安装的组件不产生任何破坏性操作。这一步能检验脚本的幂等性设计是否真的生效。再进一步可以在容器里故意制造故障来测试修复脚本——删掉一个源文件、改坏/etc/fstab再跑修复脚本验证它确实能恢复而不是只会输出日志。我最后想分享的一个教训是别在脚本里写「自适应」逻辑来掩盖对系统理解不足。早期我为了让脚本能在任意发行版上跑写了一大堆模糊匹配的兼容分支结果在某个版本上匹配错了路径直接把配置写到了错误的位置。后来改成「探测不明确就退出」让用户明确指定发行版或选择跳过某项操作反而更可靠。一键脚本的意义不是把复杂逻辑藏进黑匣子而是把稳定操作固化下来让每次执行结果可预期。希望这篇笔记帮到你少踩几个我踩过的坑。本文还有配套的精品资源点击获取