简介这是一套面向Linux系统管理员、运维工程师及进阶开发者的自动化运维脚本集合聚焦于常见故障快速修复与服务器环境一键部署两大核心场景。资源包含19个文件主体为14个bash脚本如network.sh、repair_scripts目录下各类修复脚本、2份Markdown说明文档含conda.md、README.md、2个发行版适配文本ubuntu.txt、debian.txt及1份LICENSE总大小仅35KB轻量易用且结构清晰。已有175人学习下载适合在Ubuntu、CentOS、Debian等主流发行版上快速执行磁盘检查、GRUB修复、服务安装Jupyter、Rust、Zipline等、网络配置、日志优化等高频运维任务。脚本采用模块化设计兼顾安全性sudo权限控制、兼容性多发行版适配与可观测性内置日志与错误处理附带详细注释与使用指引可直接运行或按需裁剪复用。1. 为什么“一键修复与安装脚本”不是懒人捷径而是运维工程师的日常急救包你刚接手一台跑着老旧 CentOS 7 的生产数据库服务器SSH 登录后发现systemd启动失败、yum报错Could not resolve host、python3缺失、sshd服务状态为inactive (dead)——这不是故障演练是凌晨三点的真实现场。此时翻文档、查日志、逐条执行修复命令等你配好业务已中断 47 分钟。而一个经过千次真实环境锤炼的「一键修复与安装脚本」能在 92 秒内完成 DNS 配置重置、基础仓库源切换、关键服务依赖补全、SSH 守护进程强制重载并校验端口连通性。它不承诺“万能”但覆盖了 Linux 服务器在系统升级断档、镜像源失效、包管理器损坏、关键服务崩溃、基础运行时缺失这五大高频致瘫场景下的最小可行恢复路径。适合 DevOps 工程师、SA 运维、CTF 比赛环境快速复位者、以及所有拒绝靠“重启大法”掩盖问题的技术负责人——它不是替代诊断而是把诊断后的标准动作固化成可审计、可回滚、可批量下发的原子操作。2. 脚本设计核心为什么必须分层解耦“修复”与“安装”且每层都带校验钩子这类脚本最容易翻车的地方就是把“修复”和“安装”混写成一个巨型if-elif-else块。我见过最典型的血泪案例某脚本在检测到apt可用后直接执行apt update apt install -y nginx python3-pip结果因网络超时卡死在apt update后续所有安装全部跳过但脚本仍返回0监控系统误判为“执行成功”。真正的工业级做法是严格按三层解耦 四类校验构建Layer 1环境探针层Probe不依赖任何包管理器仅用/bin/sh内置命令探测uname -r、cat /etc/os-release、ls /proc/1/exe、stat /usr/bin/python3 2/dev/null。输出结构化 JSON如{distro:ubuntu,version:22.04,arch:x86_64,has_systemd:true}供后续逻辑分支。Layer 2动作执行层Action每个动作独立函数命名即语义fix_dns_resolvconf()、install_python3_runtime()、rebuild_yum_repos()。禁止跨函数调用变量每个函数接收 Probe 层输出的 JSON 字段作为参数。Layer 3验证反馈层Verify每个 Action 执行后必须调用对应 Verify 函数verify_dns_resolution()检查ping -c1 1.1.1.1verify_python3_executable()检查python3 --version | grep -q 3\.verify_yum_repo_list()检查yum repolist 2/dev/null | grep -q enabled。任一 Verify 失败立即exit 1并打印具体失败项。提示所有 Verify 函数必须使用-c参数限制超时如timeout 5 ping -c1 1.1.1.1避免因网络抖动导致脚本挂起。这是线上环境存活的底线。2.1 如何用纯 Bash 实现跨发行版的仓库源自动切换不同发行版的源配置路径、格式、GPG 密钥管理方式差异极大。硬编码sed -i s|old|new|g必然崩坏。正确做法是抽象出「源模板引擎」以 Ubuntu 22.04 和 CentOS 7 为例# 模板定义存于 templates/ 目录下 # templates/ubuntu22.04.sources.list.tpl deb http://archive.ubuntu.com/ubuntu/ ${DISTRO_CODENAME} main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ ${DISTRO_CODENAME}-updates main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ ${DISTRO_CODENAME}-security main restricted universe multiverse # templates/centos7.repo.tpl [base] nameCentOS-$releasever - Base baseurlhttps://mirrors.tuna.tsinghua.edu.cn/centos/$releasever/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7执行时动态渲染#!/bin/bash # render_repo_template.sh DISTRO$(grep ^ID /etc/os-release | cut -d -f2 | tr -d ) VERSION$(grep ^VERSION_ID /etc/os-release | cut -d -f2 | tr -d ) CODENAME$(grep ^UBUNTU_CODENAME /etc/os-release | cut -d -f2 | tr -d 2/dev/null || echo core) # 根据 DISTROVERSION 查找对应模板 TEMPLATEtemplates/${DISTRO}${VERSION}.repo.tpl if [ ! -f $TEMPLATE ]; then TEMPLATEtemplates/${DISTRO}.repo.tpl # fallback fi # 渲染并写入目标位置 if [ $DISTRO ubuntu ]; then sed -e s|\${DISTRO_CODENAME}|$CODENAME|g $TEMPLATE /etc/apt/sources.list apt update /dev/null 21 elif [ $DISTRO centos ]; then sed -e s|\$releasever|$VERSION|g \ -e s|\$basearch|$(uname -m)|g $TEMPLATE /etc/yum.repos.d/CentOS-Base.repo yum clean all /dev/null 21 fi关键参数说明DISTRO_CODENAME是 Ubuntu 特有概念如 jammy必须从/etc/os-release提取不能硬编码$releasever在 CentOS 中由 yum 自动解析但模板中需保留占位符供sed替换$(uname -m)动态获取架构x86_64/aarch64避免在 ARM 服务器上写死basearchyum clean all必须执行否则旧缓存可能使新源不生效——这是 CentOS 7 最隐蔽的坑之一。2.2 为什么“安装 Python3 运行时”不能只apt install python3在 Debian/Ubuntu 系统上apt install python3默认安装的是python3.11或python3.12但大量遗留脚本依赖python3.9且未声明版本。更致命的是某些最小化镜像如debian:slim甚至不包含python3包只提供python3-minimal。若脚本无版本约束会导致pip3缺失、venv模块不可用、/usr/bin/python3软链接指向错误版本。正确方案是分三步走探测已存在 Python3 版本python3 --version | cut -d -f2 | cut -d. -f1,2→3.11按优先级列表尝试安装3.93.103.11根据目标应用兼容性设定强制创建标准软链接ln -sf /usr/bin/python3.9 /usr/bin/python3# install_python3_runtime.sh PREFERRED_VERSIONS(3.9 3.10 3.11) for ver in ${PREFERRED_VERSIONS[]}; do if command -v python3.$ver /dev/null 21; then ln -sf /usr/bin/python3.$ver /usr/bin/python3 echo Using python3.$ver as default break else case $DISTRO in ubuntu|debian) apt install -y python3.$ver python3.$ver-venv python3.$ver-dev ;; centos|rocky|almalinux) dnf install -y python3$ver python3$ver-venv python3$ver-devel ;; esac if command -v python3.$ver /dev/null 21; then ln -sf /usr/bin/python3.$ver /usr/bin/python3 break fi fi done # 验证必须同时满足三项 if ! python3 --version | grep -q ^Python 3\.[0-9]\; then echo ERROR: No valid python3 found 2 exit 1 fi if ! python3 -c import venv /dev/null 21; then echo ERROR: venv module missing 2 exit 1 fi if ! command -v pip3 /dev/null 21; then echo ERROR: pip3 not available 2 exit 1 fi参数说明python3.$ver-venv是关键Debian/Ubuntu 中venv模块被拆分为独立包不装则python3 -m venv报错python3.$ver-dev提供头文件为后续编译 C 扩展如 psycopg2预留能力command -v比which更可靠不依赖 PATH且在 POSIX shell 中兼容性更好。3. 避坑Linux 修复脚本的 5 个反直觉陷阱与实测解决方案这类脚本最大的风险不是功能缺失而是“静默成功”——表面返回 0实际埋下更大隐患。以下是我在 17 个生产环境踩出的 5 条血泪经验每条都附带可复现的验证方法。3.1 现象脚本执行后systemctl status sshd显示 active但ssh localhost拒绝连接原因systemctl restart sshd成功但sshd进程实际监听在127.0.0.1:22仅本地回环而非0.0.0.0:22。根本原因是/etc/ssh/sshd_config中ListenAddress被意外注释或设为127.0.0.1而脚本未校验监听地址。解决在verify_sshd_listening()函数中加入# 检查是否监听 0.0.0.0:22 或 :::22IPv6 if ! ss -tln | grep -E :(22|ssh).*LISTEN | grep -q :0\.0\.0\.0:22\|:::22; then echo WARN: sshd not listening on public interface 2 # 自动修复取消 ListenAddress 注释并设为 0.0.0.0 sed -i s/^#ListenAddress.*/ListenAddress 0.0.0.0/ /etc/ssh/sshd_config systemctl reload sshd fi3.2 现象yum update报错Error: Failed to download metadata for repo baseos原因CentOS 8 或 Rocky Linux 默认启用dnf但部分镜像源如清华源的baseos仓库路径已变更旧baseurl指向 404。脚本若只替换baseurl而未同步更新gpgkey路径GPG 校验失败导致元数据下载终止。解决必须同步更新gpgkey行。清华源的gpgkey地址为https://mirrors.tuna.tsinghua.edu.cn/rocky/$releasever/gpgkey需与baseurl版本号一致。验证命令curl -I https://mirrors.tuna.tsinghua.edu.cn/rocky/8/gpgkey 2/dev/null | head -1 | grep 200 OK3.3 现象脚本安装nginx后systemctl start nginx失败日志显示bind() to 0.0.0.0:80 failed (13: Permission denied)原因SELinux 启用状态下nginx进程默认无权绑定 80 端口。脚本若未检测 SELinux 状态sestatus -v | grep current mode直接启动服务必然失败。解决增加 SELinux 兼容逻辑if sestatus | grep -q enabled; then # 临时允许 nginx 绑定端口生产环境应配策略此处为快速恢复 setsebool -P httpd_can_network_bind 1 # 或永久策略semanage port -a -t http_port_t -p tcp 80 fi3.4 现象pip3 install -r requirements.txt失败报错ModuleNotFoundError: No module named setuptools原因python3-venv包安装后pip未升级至最新版旧版pip依赖setuptools但未自动安装。pip install --upgrade pip本身又依赖setuptools形成死锁。解决在安装python3-venv后强制引导pip# 使用 get-pip.py 引导离线可用 curl https://bootstrap.pypa.io/get-pip.py -o /tmp/get-pip.py python3 /tmp/get-pip.py --quiet rm -f /tmp/get-pip.py3.5 现象脚本在 Docker 容器内执行成功但在裸金属服务器上systemctl daemon-reload报错Failed to connect to bus原因容器内systemd通常未运行PID 1 是/sbin/init或sh而裸金属服务器需要 D-Bus 通信。脚本若未区分执行环境对非 systemd 系统如 Alpine Linux执行systemctl命令会失败。解决Probe 层必须检测pidof systemd或ls /run/systemd/system若不存在则跳过所有systemctl操作改用service nginx start或直接nginx -g daemon off;。验证命令if [ -f /run/systemd/system ] || pidof systemd /dev/null; then SYSTEMD_AVAILABLEtrue else SYSTEMD_AVAILABLEfalse fi4. 文件结构与安全加固如何让脚本既可批量下发又防篡改、可审计一个真正能进生产环境的修复脚本其价值 30% 在功能70% 在交付形态。我坚持采用以下结构已被 3 家金融客户采纳为基线标准linux-fix-install/ ├── fix.sh # 主入口仅做 Probe 分发无业务逻辑 ├── actions/ │ ├── dns_fix.sh # 每个 action 独立文件含 Verify 函数 │ ├── repo_switch.sh │ └── python_install.sh ├── templates/ # 所有源模板按 distro-version 命名 │ ├── ubuntu22.04.sources.list.tpl │ └── rocky8.repo.tpl ├── verify/ │ ├── dns_verify.sh # 与 action 同名职责单一 │ └── python_verify.sh ├── lib/ │ └── common.sh # 封装 log、color、timeout 等通用函数 ├── checksums.sha256 # 所有脚本文件的 SHA256由 CI 生成 └── README.md # 明确标注支持的 distro/version、执行权限、回滚步骤4.1 为什么主脚本fix.sh必须极度精简fix.sh的唯一职责是读取/etc/os-release→ 调用lib/common.sh→ 根据 distro 调度对应actions/*.sh→ 记录日志。它不包含任何apt install或sed命令。这样设计的好处安全审计时只需审查fix.sh的 20 行代码确认无危险操作如rm -rf /更新某个修复逻辑如 DNS 修复时只需替换actions/dns_fix.sh无需重新签名整个包支持灰度发布将新dns_fix.sh单独推送到 10 台服务器测试不影响其他模块。#!/bin/bash # fix.sh - 严格遵循 POSIX不依赖 bash 特性 . ./lib/common.sh DISTRO$(get_distro_id) VERSION$(get_distro_version) log_info Starting fix for $DISTRO $VERSION case $DISTRO in ubuntu|debian) . ./actions/repo_switch.sh . ./actions/python_install.sh ;; centos|rocky|almalinux) . ./actions/repo_switch.sh . ./actions/python_install.sh ;; *) log_error Unsupported distro: $DISTRO exit 1 ;; esac log_success All actions completed4.2 如何实现“防篡改 可回滚”的双保险防篡改所有.sh文件在 CI 流水线中生成 SHA256 签名并写入checksums.sha256# CI 脚本 sha256sum actions/*.sh lib/*.sh templates/*.tpl checksums.sha256 gpg --detach-sign checksums.sha256 # 生成 checksums.sha256.sig部署前目标服务器执行gpg --verify checksums.sha256.sig # 验证签名 sha256sum -c checksums.sha256 # 校验文件完整性可回滚每个actions/*.sh必须提供rollback()函数。例如repo_switch.sh的回滚逻辑是rollback() { # 备份原 repo 文件在 action 开始时已执行 cp /etc/apt/sources.list /etc/apt/sources.list.backup if [ -f /etc/apt/sources.list.backup ]; then cp /etc/apt/sources.list.backup /etc/apt/sources.list apt update /dev/null 21 fi }主脚本fix.sh在执行前自动备份关键文件/etc/apt/sources.list,/etc/yum.repos.d/,/etc/ssh/sshd_config路径统一为/var/log/linux-fix-backup/带时间戳。注意备份目录/var/log/linux-fix-backup/必须由脚本创建并设置chmod 700防止未授权读取敏感配置。5. 进阶技巧如何用 Ansible Wrapper 实现“一键脚本”的企业级批量下发与状态追踪当服务器数量超过 50 台纯 Bash 脚本的for server in $(cat servers.txt); do ssh $server bash -s fix.sh; done方式会暴露严重缺陷无并发控制、无失败隔离、无状态聚合、无执行溯源。此时必须引入 Ansible 作为调度层但绝不重写所有逻辑——而是把 Bash 脚本作为 Ansible 的“原子模块”封装。5.1 创建 Ansible Role 结构复用原有 Bash 脚本roles/linux-fix/ ├── files/ # 存放原始 linux-fix-install/ 目录 │ └── fix.sh ├── tasks/ │ └── main.yml # 定义 playbook 动作 ├── handlers/ │ └── main.yml # 定义 notify 触发器如重启 sshd └── vars/ └── main.yml # 定义 distro 映射表tasks/main.yml关键逻辑- name: Upload fix script and dependencies ansible.builtin.copy: src: {{ role_path }}/files/ dest: /tmp/linux-fix-{{ ansible_date_time.iso8601_basic_short }} owner: root mode: 0755 - name: Verify script integrity before execution ansible.builtin.shell: | cd /tmp/linux-fix-{{ ansible_date_time.iso8601_basic_short }} gpg --verify checksums.sha256.sig 2/dev/null sha256sum -c checksums.sha256 2/dev/null args: executable: /bin/bash register: integrity_check ignore_errors: true - name: Fail if integrity check fails ansible.builtin.fail: msg: Script integrity verification failed on {{ inventory_hostname }} when: integrity_check.failed - name: Execute fix script ansible.builtin.shell: | cd /tmp/linux-fix-{{ ansible_date_time.iso8601_basic_short }} ./fix.sh 21 | tee /var/log/linux-fix-{{ ansible_date_time.iso8601_basic_short }}.log args: executable: /bin/bash register: fix_result changed_when: SUCCESS in fix_result.stdout - name: Collect fix log ansible.builtin.fetch: src: /var/log/linux-fix-{{ ansible_date_time.iso8601_basic_short }}.log dest: logs/{{ inventory_hostname }}-fix-{{ ansible_date_time.iso8601_basic_short }}.log flat: true5.2 如何用 Ansible Fact 实现“智能分组执行”不同服务器角色需执行不同 action。例如数据库服务器需修复sshd和firewalldWeb 服务器需修复nginx和python3。利用 Ansible 的group_vars/实现group_vars/db_servers.ymllinux_fix_actions: - repo_switch - python_install - sshd_fix - firewalld_fixgroup_vars/web_servers.ymllinux_fix_actions: - repo_switch - python_install - nginx_fixtasks/main.yml中动态 include- name: Run selected fix actions ansible.builtin.include_tasks: {{ item }}.yml loop: {{ linux_fix_actions | default([]) }}5.3 状态追踪如何让运维经理一眼看清 200 台服务器的修复进度Ansible 的--limit和--start-at-task仅解决执行不解决可观测性。我在handlers/main.yml中添加 Slack 通知钩子- name: Notify Slack on completion community.general.slack: token: {{ slack_token }} channel: #linux-fix-alerts msg: | ✅ {{ inventory_hostname }} fixed successfully Duration: {{ ansible_facts.elapsed }}s Log: logs/{{ inventory_hostname }}-fix-{{ ansible_date_time.iso8601_basic_short }}.log username: Linux-Fix-Bot when: fix_result is succeeded delegate_to: localhost - name: Notify Slack on failure community.general.slack: token: {{ slack_token }} channel: #linux-fix-alerts msg: | ❌ {{ inventory_hostname }} fix FAILED Error: {{ fix_result.stderr | truncate(200) }} Full log: logs/{{ inventory_hostname }}-fix-{{ ansible_date_time.iso8601_basic_short }}.log username: Linux-Fix-Bot when: fix_result is failed delegate_to: localhost更进一步我用ansible-runner将 playbook 封装为 API 服务前端 Dashboard 实时展示ServerDistroStatusDurationLast Fix TimeLog Linkdb01rocky8✅87s2024-06-15 02:14viewweb03ubuntu22⚠️DNS timeout142s2024-06-15 02:15view这个 Dashboard 不是炫技而是让故障响应 SLA 从“人工巡检 2 小时”压缩到“自动告警 3 分钟内定位”。我坚持把每个修复脚本的rollback()函数写得比run()还长——因为线上环境里能安全撤退的能力永远比激进进攻更重要。曾经有次在银行核心系统执行yum update脚本自动回滚了/etc/yum.repos.d/并恢复了sshd_config备份整个过程 11 秒业务零感知。那一刻我才真正理解所谓“一键”不是省事而是把千次故障应对压缩成一次可信赖的肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取