运维123 - 运维
type: channel
link: https://www.sddts.cn/index.php/category/%E8%BF%90%E7%BB%B4/
items: Kubernetes 节点根分区磁盘占用过高排查复盘
items: SSH 公钥认证失败问题排查
items: 修改GRUB默认启动内核
items: Linux 服务器自动关机问题诊断案例
items: DMG 文件直接写入硬盘导致无法启动的问题分析与解决
items: 在 Linux 上将 macOS 安装文件写入 NVMe 硬盘
items: 服务器集群运维文档
items: Nagios 容器路径配置错误故障复盘
items: 15年单服务器8GB内存服务50万用户——Webminal生存之道
items: Mac Pro GPU 配置问题排查与修复

Kubernetes 节点根分区磁盘占用过高排查复盘
type: item
date: 2026-07-15T01:10:22+00:00
description: Kubernetes 节点根分区磁盘占用过高排查复盘一、事件概述1. 事件背景2026 年 7 月 15 日上午，监控发现 K8s 工作节点 zcyun-k8s-node5（IP：10.10.184.204）根分区使用率持续攀升至 89%，逼近告警阈值，存在磁盘写满导致节点上所有 Pod 业务中断的风险。该节点承载物联网（IoT）数据、规则引擎、设备管理等核心服务。2. 影响范围A. 影响资源节点根分区 /dev/vda1（总容量 40G，已用 34G，剩余 4.5G）B. 风险等级P2 级（尚未触发业务故障，但距离写满仅一步之遥）C. 潜在影响若根分区写满，将导致节点上 28 个容器无法写入日志与临时数据，引发服务大面积异常、数据库连接失败、Pod 被驱逐等连锁问题。3. 处理结果经排查定位并处置后，根分区使用率从 89% 下降至 23%，释放约 25G 空间，节点恢复正常水位。二、排查过程1. 排查思路磁盘使用率过高的问题，按「先排除 inode 耗尽，再定位大文件归属，最后定位到具体文件」的层级化思路推进，整体决策流程如下。graph TD A["df 显示根分区 89%"] --> B{"inode 使用率?"} B -->|"仅 5%"| C["排除碎文件问题 锁定大文件"] C --> D["du 逐层定位 /var 29G"] D --> E["/var/lib/docker 24G overlay2 可写层"] E --> F["docker system df Containers 22.6G"] F --> G["docker ps -s 定位容器"] G --> H["iot-data 11.4G iot-rule 10.9G"] H --> I["进入容器可写层 UpperDir"] I --> J["rocketmq_client.log 10 份 1.1G 归档"] J --> K["根因锁定"]2. 步骤一：确认磁盘与 inode 状态首先通过 df 命令确认磁盘整体情况，并检查 inode 使用率以排除「小文件过多导致 inode 耗尽」的可能。df -h # 根分区 40G，已用 34G，89% df -i # inode 仅使用 5%结论：inode 使用率仅 5%，排除碎文件问题，判定为「少数大文件」占用空间。3. 步骤二：逐层定位大目录使用 du 命令从根目录逐层向下统计，定位空间占用大头。du -hx --max-depth=1 / # /var 29G du -hx --max-depth=1 /var # /var/lib 24G du -hx --max-depth=1 /var/lib # /var/lib/docker 24G结论：/var/lib/docker 占用 24G，其中 overlay2 目录为最大头；镜像本身仅 2.8G，说明问题出在容器运行时数据。4. 步骤三：区分镜像与容器可写层通过 docker system df 区分镜像缓存与容器可写层占用。docker system df关键发现：Containers 项 SIZE 为 22.61GB，但 RECLAIMABLE 为 0。这意味着占用来自「容器运行时写入可写层」的数据，而非镜像缓存，因此常规的 docker prune 清理无效。5. 步骤四：定位到具体容器通过 docker ps -s 查看每个容器可写层大小，按体积排序。docker ps -s --format 'table {{.Size}}\t{{.Names}}\t{{.Image}}'定位到两个异常容器：容器可写层大小镜像xcloud-srv-iot-data11.4Gnew-iot/xcloud-srv-iot-dataxcloud-srv-iot-rule10.9Gnew-iot/xcloud-srv-iot-rule两者合计约 22G，与容器总占用 22.61G 完全吻合。6. 步骤五：进入可写层定位具体文件通过 docker inspect 获取容器可写层路径（UpperDir），直接查看其中写入的大文件。docker inspect <容器名> --format '{{.GraphDriver.Data.UpperDir}}' # /var/lib/docker/overlay2/<hash>/diff在两个容器的 /root/logs/rocketmqlogs/ 目录下，均发现大量 RocketMQ 客户端日志：文件大小rocketmq_client.log.1 ~ rocketmq_client.log.10每份 1.1Grocketmq_client.log（当前写入）191M ~ 653M7. 步骤六：分析日志内容确认根…

SSH 公钥认证失败问题排查
type: item
date: 2026-04-14T10:09:27+00:00
description: SSH 公钥认证失败问题排查一、事件概述1. 事件背景用户尝试通过 SSH 连接到服务器 8.140.218.139，连接建立后认证失败。2. 影响范围A. 影响用户数1 名用户B. 影响时长问题当场解决C. 影响功能SSH 远程登录功能3. 严重程度P3 级问题（个人使用受阻，不影响业务）二、事件时间线1. 问题发现A. 现象描述执行 ssh root@8.140.218.139 后返回 Permission denied 错误B. 初步判断需要详细调试信息才能确定原因2. 诊断过程A. 获取调试信息执行 ssh -vvv root@8.140.218.139 获取详细日志B. 日志分析从调试输出中发现以下关键信息：连接成功建立密钥交换正常完成客户端尝试了两个私钥认证都被拒绝服务器支持的认证方式：publickey、password最后错误：Permission denied (publickey,password)3. 问题定位客户端本地存在两个密钥文件：/home/jacky/.ssh/id_rsa (RSA)/home/jacky/.ssh/id_ed25519 (ED25519)两个密钥都被服务器拒绝，说明服务器端的 authorized_keys 中没有对应的公钥。graph TD A[执行SSH连接] --> B{密钥认证} B --> C[尝试id_rsa] C -->|失败| D[尝试id_ed25519] D -->|失败| E{密码认证} E -->|未尝试| F[认证失败] F --> G[Permission denied]三、问题分析1. 直接原因服务器端的 ~/.ssh/authorized_keys 文件中不存在客户端的公钥2. 根本原因密钥未配置或密钥不匹配3. 深层原因分析首次配置 SSH 密钥认证服务器重装后密钥丢失使用了不同的密钥文件四、解决方案1. 方案一：使用密码登录强制 SSH 使用密码认证而非公钥认证：ssh -o PreferredAuthentications=password root@8.140.218.139优点：快速临时解决缺点：每次都需要输入密码2. 方案二：复制公钥到服务器使用 ssh-copy-id 工具自动配置：ssh-copy-id -i ~/.ssh/id_ed25519.pub root@8.140.218.139或手动复制：cat ~/.ssh/id_ed25519.pub | ssh root@8.140.218.139 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys'优点：配置一次，永久免密登录缺点：首次需要密码登录3. 方案三：检查服务器配置登录服务器后检查 SSH 服务配置：grep Pubkey /etc/ssh/sshd_config确认以下配置正确：PubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keysflowchart TD A[SSH连接问题] --> B{知道密码吗?} B -->|是| C[方案一:密码登录] B -->|否| D[需要其他方式访问] C --> E{想配置密钥吗?} E -->|是| F[方案二:复制公钥] E -->|否| G[继续使用密码] F --> H[检查服务器配置] D --> H五、经验总结1. 排查思路使用 -vvv 参数获取详细调试信息关注 Authentications that can continue 字段检查本地密钥文件是否被尝试2. SSH 认证机制理解SSH 默认按以下顺序尝试认证：公钥认证（尝试所有本地私钥）密码认证（如果服务器允许）如果公钥认证全部失败，且客户端配置为优先公钥，可能不会自动降级到密码认证。3. 最佳实践首次配置服务器时立即设置密钥认证禁用密码登录提高安全性（PermitEmptyPasswords no）定期备份 authorized_keys 文件使用 ssh-copy-id 简化配置过程六、相关知识1. SSH 密钥类型对比密钥类型安全性兼容性推荐度ED25519高现代系统强烈推荐RSA 2048中所有系统兼容性首选RSA 4096中高所有系统安全性首选ECDSA高现代系统可选2. 常用 SSH 调试参数-v：基本调试信息-vv：更详细的调试信息-vvv：最详细的调试信息-o PreferredAuthentications=password：强制使用密码认证参考资料OpenSSH 官方文档SSH 密钥管理最佳实践

修改GRUB默认启动内核
type: item
date: 2026-04-06T08:44:20+00:00
description: 修改GRUB默认启动内核一、概述1. 简介A. 是什么GRUB（Grand Unified Bootloader）是Linux系统中最常用的引导加载程序，负责在系统启动时加载内核。默认情况下，GRUB会启动最新安装的内核版本，但有时我们需要指定特定版本的内核作为默认启动项。B. 为什么需要某些情况下，最新内核可能存在兼容性问题、驱动不支持或性能问题，需要回退到旧版本内核。设置默认内核可以确保系统每次重启都使用稳定的内核版本。C. 学完能做什么查看当前系统的GRUB菜单配置修改GRUB默认启动内核验证配置并生效2. 前置知识A. 必备技能基本Linux命令操作sudo权限管理B. 推荐知识了解Linux内核版本号含义了解GRUB引导流程二、查看当前配置1. 查看已安装内核使用以下命令查看系统中已安装的内核版本：ls /boot/vmlinuz* /boot/initrd* | sort -V输出示例：/boot/initrd.img-6.17.0-14-generic /boot/initrd.img-6.17.0-20-generic /boot/vmlinuz-6.17.0-14-generic /boot/vmlinuz-6.17.0-20-generic2. 查看GRUB菜单结构查看GRUB配置文件中的菜单项：sudo awk '/menuentry.*linux/ {print NR": "$0}' /boot/grub/grub.cfg输出示例：165: menuentry 'Kubuntu, with Linux 6.17.0-20-generic' ... 183: menuentry 'Kubuntu, with Linux 6.17.0-20-generic (recovery mode)' ... 220: menuentry 'Kubuntu, with Linux 6.17.0-14-generic' ... 239: menuentry 'Kubuntu, with Linux 6.17.0-14-generic (recovery mode)' ...3. 查看当前GRUB默认配置cat /etc/default/grub默认配置通常为：GRUB_DEFAULT=0三、GRUB菜单索引规则1. 菜单结构理解graph TD A[GRUB菜单] --> B[条目0: Kubuntu 默认最新内核] A --> C[条目1: Advanced Options 子菜单] C --> D[1>0: 6.17.0-20-generic] C --> E[1>1: 6.17.0-20-generic recovery] C --> F[1>2: 6.17.0-14-generic] C --> G[1>3: 6.17.0-14-generic recovery]2. 索引规则说明条目0：主菜单项，使用最新内核条目1：Advanced Options子菜单1>0：最新版本内核（如6.17.0-20-generic）1>1：最新版本内核恢复模式1>2：次新版本内核（如6.17.0-14-generic）1>3：次新版本内核恢复模式子菜单索引格式为：submenu_index>menu_index，索引从0开始计数。四、修改默认内核1. 备份当前配置修改前务必备份原始配置：sudo cp /etc/default/grub /etc/default/grub.bak2. 修改GRUB_DEFAULT参数使用sed命令或编辑器修改配置：sudo sed -i 's/^GRUB_DEFAULT=0/GRUB_DEFAULT="1>2"/' /etc/default/grub或者使用文本编辑器：sudo nano /etc/default/grub将以下内容：GRUB_DEFAULT=0修改为（以6.17.0-14-generic为例）：GRUB_DEFAULT="1>2"3. 验证修改结果cat /etc/default/grub确认输出包含正确的GRUB_DEFAULT值。五、更新GRUB配置1. 更新GRUB修改配置文件后，需要更新GRUB使配置生效：sudo update-grub输出示例：Sourcing file `/etc/default/grub' Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.17.0-20-generic Found initrd image: /boot/initrd.img-6.17.0-20-generic Found linux image: /boot/vmlinuz-6.17…

Linux 服务器自动关机问题诊断案例
type: item
date: 2026-04-02T21:44:36+00:00
description: Linux 服务器自动关机问题诊断案例一、事件概述1. 事件背景一台运行 Ubuntu 的 Mac Pro 2013 服务器在开机运行一段时间后自动关机，需要诊断根本原因并修复。2. 影响范围A. 影响用户数服务器作为内部节点使用，影响有限B. 影响时长多次发生，系统运行 15 分钟至数小时后崩溃C. 影响功能服务器运行 Kubernetes 节点，崩溃导致容器服务中断3. 严重程度P2 级故障（影响单节点服务）4. 系统信息硬件：Apple MacPro6,1（2013 年款）系统：Ubuntu 5.15.0-119-generic架构：x86_64二、事件时间线1. 问题发现A. 发现途径用户报告服务器频繁自动关机B. 初步观察系统运行一段时间后突然断电，而非正常关机2. 诊断过程（2026-04-03）A. 日志分析检查多次启动日志，发现系统日志突然停止，无关机记录B. 关键发现通过 journalctl 检查发现：GRUB 配置中存在 mce=off 参数内核日志显示 mce 设备初始化失败C. 根因定位确认 MCE（Machine Check Exception）被禁用，导致硬件错误无法被捕获和记录3. 修复措施A. 配置修改备份并修改 /etc/default/grub，移除 mce=off 参数B. 应用更改运行 update-grub 更新启动配置C. 后续计划需要重启系统使更改生效sequenceDiagram participant U as 用户 participant D as 诊断过程 participant J as journalctl participant G as GRUB配置 participant S as 系统 U->>D: 报告自动关机问题 D->>J: 检查系统日志 J-->>D: 日志突然停止 D->>J: 检查内核参数 J-->>D: 发现 mce=off D->>G: 修改GRUB配置 G->>S: 移除mce=off D->>S: 运行update-grub S-->>U: 需要重启生效三、问题分析1. 直接原因GRUB 启动参数中配置了 mce=off，禁用了 CPU 硬件错误检测机制2. 根本原因（5 Whys 分析）A. 为什么系统会突然关机？可能是硬件故障（电源、内存、热保护）导致系统崩溃B. 为什么没有错误日志？MCE 被禁用，硬件错误无法被内核捕获和记录C. 为什么要禁用 MCE？可能是早期为了解决某些兼容性问题而添加的配置，具体原因已不可考D. 硬件问题是什么？当前温度正常（31-43°C），风扇运转正常。系统为 2013 年老款 Mac Pro，可能存在：电源老化导致电压不稳内存硬件故障其他老化的硬件组件E. 深层反思老化硬件需要更完善的监控机制，而非禁用错误检测3. 问题机制说明MCE（Machine Check Exception）是 x86 架构的硬件错误检测机制：graph TD A[硬件错误发生] --> B{MCE 是否启用?} B -->|是| C[内核捕获错误] C --> D[记录详细日志] D --> E[系统优雅处理或重启] B -->|否| F[错误未被捕获] F --> G[系统直接崩溃] G --> H[无日志记录]四、解决方案1. 临时方案A. 实施措施无临时方案，必须通过重启系统启用 MCEB. 效果评估等待重启后验证2. 永久方案A. 已完成措施备份 /etc/default/grub 文件移除 GRUB_CMDLINE_LINUX_DEFAULT 中的 mce=off 参数运行 update-grub 更新配置修改前：GRUB_CMDLINE_LINUX_DEFAULT=" intel_idle.max_cstate=1 mce=off"修改后：GRUB_CMDLINE_LINUX_DEFAULT=" intel_idle.max_cstate=1 "B. 待执行措施重启系统使配置生效3. 预防措施重启后验证 MCE 状态：# 检查 MCE 是否启用 cat /proc/sys/kernel/mce_verbose # 查看硬件错误日志 journalctl -k | grep -i mce dmesg | grep -i mce硬件检查建议：清理机箱灰尘（Mac Pro 2013 容易积灰）检查风扇运转是否正常运行内存测试（memtest86+）监控温度变化：watch -n 5 sensors五、经验总结1. 做得好的地方通过日志分析准确识别问题类型（崩溃而非关机）定位到根本原因（MCE 被禁用）系统化地分析问题而非盲目修复2. 需要改进的地方缺少硬件监控体系，无法提前发现问题老化硬件缺少维护计划3. 关键知识点MCE…

DMG 文件直接写入硬盘导致无法启动的问题分析与解决
type: item
date: 2026-04-02T01:36:42+00:00
description: DMG 文件直接写入硬盘导致无法启动的问题分析与解决一、事件概述1. 事件背景在 Linux 系统中将 macOS 12.7.6 安装文件（DMG 格式）写入 NVMe 硬盘，制作可启动的 macOS 安装盘。2. 影响范围A. 影响操作启动盘制作流程被迫中断，需要重新制作B. 影响时长问题发现耗时约 30 分钟，包括问题定位和重新制作C. 影响功能初次制作的启动盘无法被 Mac 识别3. 严重程度P2 级问题（非生产环境，但浪费时间和精力）二、事件时间线1. 问题发生（时间：初次写入完成后）A. 现象描述使用 dd 命令直接将 InstallOS.dmg 写入 /dev/sdb，写入过程显示成功，耗时约 170 秒，写入约 5GB 数据。B. 初始验证使用 file 命令检查硬盘开头，返回 zlib compressed data，而非预期的分区表格式。2. 问题发现（时间：写入验证阶段）A. 发现途径在重启前验证启动盘制作结果时，使用 file 和 hexdump 命令检查硬盘内容。B. 初步判断硬盘开头为 78 DA（zlib 压缩数据魔数），而非正确的 GPT 引导扇区（00 EE）。说明 DMG 文件的压缩数据被直接写入了硬盘。3. 根因分析（时间：问题发现后）A. 根本原因DMG 是 Apple 的磁盘镜像格式，内部使用 zlib 压缩。直接用 dd 写入只会把压缩数据复制到硬盘，Mac 无法识别正确的分区结构。B. 正确做法必须先使用 dmg2img 工具将 DMG 转换为原始镜像（IMG 格式），再写入设备。4. 解决方案实施（时间：根因确认后）A. 转换 DMG 为 IMGdmg2img /home/lab/Downloads/InstallOS.dmg /home/lab/Downloads/InstallOS.img转换过程耗时约 2 分钟，文件从 4.7GB 扩展到 5.3GB。B. 重新写入硬盘sudo dd if=/home/lab/Downloads/InstallOS.img of=/dev/sdb bs=4M oflag=direct status=progress写入耗时约 125 秒，平均速度 44.7 MB/s。5. 验证结果（时间：重新写入后）A. 分区表验证GPT 分区表正确写入，包含：分区 1：EFI System Partition（200MB vfat）分区 2：Install macOS（4.9GB HFS+）B. 文件系统验证挂载 HFS+ 分区后，确认 InstallOS.pkg 文件存在（约 5GB）。C. 最终结果启动盘制作成功，可在 Mac 上使用 Option 键选择启动。graph LR A[DMG 文件] -->|错误方式: 直接 dd| B[压缩数据写入硬盘] B --> C[Mac 无法识别] A -->|正确方式: dmg2img| D[IMG 镜像] D -->|dd 写入| E[正确分区结构] E --> F[Mac 可识别]三、问题分析1. 直接原因dd 命令按字节复制文件内容，不会处理 DMG 内部的压缩结构。直接写入 DMG 文件相当于把压缩数据块写入硬盘。2. 根本原因（技术分析）A. DMG 文件结构DMG（Disk Image）是 Apple 的磁盘镜像格式，具有以下特点：支持 zlib 压缩（默认）支持 AES 加密支持多种分区格式（GPT、APM 等）包含文件系统和元数据B. 压缩数据特征DMG 文件开头的 78 DA 是 zlib 压缩的标准魔数，表示数据已压缩。00000000 78 da 63 60 18 05 43 18 fc fb ff ff 1d 10 33 02 |x.c`..C.......3.C. GPT 分区表特征正确的 GPT 硬盘开头应该是保护性 MBR：000001c0 ff ff ee fe ff ff 01 00 00 00 f7 52 a7 00 00 00 |................|3. 深层反思A. 文档缺陷网络上关于 DMG 写入的教程多数存在误导，未说明 DMG 需要先转换。B. 工具认知dmg2img 工具在 Linux 生态中不够普及，容易被忽略。C. 验证重要性在重启前验证是非常必要的步骤，避免了使用无效启动盘的麻烦。四、解决方案1. 临时方案（不推荐）如果已经错误写入，需要重新制作：使用 dd 填充零清空硬盘：dd if=/dev/zero of=/dev/sdb bs=1M count=100重新执行正确的制作流程2. 正确方案（推荐）A. 完整制作流程# 1. 转换 DMG 为 IMG dmg2img InstallOS.dmg InstallOS.img # 2. 写入硬…

在 Linux 上将 macOS 安装文件写入 NVMe 硬盘
type: item
date: 2026-04-02T01:30:44+00:00
description: 在 Linux 上将 macOS 安装文件写入 NVMe 硬盘一、概述1. 简介本文介绍如何在 Linux 系统中将 macOS 安装 DMG 文件写入 NVMe 硬盘，创建可启动的 macOS 安装盘。2. 适用场景需要在 Mac 上重新安装 macOS 系统制作 macOS 启动安装盘用于多台机器使用 NVMe 硬盘作为安装介质3. 前置知识A. 必备技能基本 Linux 命令行操作了解磁盘设备和挂载概念B. 注意事项写入操作会完全清除目标硬盘的数据需要 root 权限执行写入命令确保正确识别目标设备，避免误写入系统盘二、环境准备1. 系统要求Linux 操作系统（Ubuntu、Debian、CentOS 等）sudo 权限目标 NVMe 硬盘已连接并识别2. 所需工具Linux 系统自带 dd 工具，无需额外安装。三、操作步骤1. 检测目标硬盘使用 lsblk 命令查看所有磁盘设备：lsblk -d -o NAME,SIZE,MODEL输出示例：NAME SIZE MODEL sda 465.9G APPLE SSD SM0512G sdb 238.5G 256G NVMe KIOXIA确认目标设备名称，本例中为 /dev/sdb。2. 确认 DMG 文件查看 DMG 文件信息：ls -lh InstallOS.dmg输出示例：-rw-rw-r-- 1 lab lab 4.7G 10月 24 2019 InstallOS.dmg3. 写入 DMG 到硬盘使用 dd 命令将 DMG 文件写入目标硬盘：sudo dd if=/path/to/InstallOS.dmg of=/dev/sdb bs=4M oflag=direct status=progress参数说明：if：输入文件（DMG 文件路径）of：输出设备（目标硬盘）bs：块大小，4M 可提高写入速度oflag=direct：绕过系统缓存，直接写入设备status=progress：显示实时进度4. 等待写入完成写入过程会显示实时进度：5007882126 bytes (5.0 GB, 4.7 GiB) copied, 170.37 s, 29.4 MB/s写入时间取决于硬盘速度，通常需要几分钟。四、工作原理1. DMG 文件格式DMG 是 Apple 的磁盘镜像格式，支持压缩和加密。写入时，dd 命令会自动处理解压缩。2. 数据流向graph LR A[DMG 文件] -->|dd 读取| B[解压缩] B -->|直接写入| C[NVMe 硬盘] C -->|可启动| D[macOS 安装盘]3. 写入后硬盘结构硬盘将被格式化为 macOS 可识别的分区结构，包含启动文件和系统镜像。五、验证结果1. 检查写入结果使用 fdisk 查看硬盘分区信息：sudo fdisk -l /dev/sdb应该能看到 macOS 特定的分区类型（如 Apple HFS 或 APFS）。2. 在 Mac 上测试将硬盘连接到 Mac，启动时按住 Option 键，应该能看到安装盘选项。六、常见问题1. 找不到目标设备问题：lsblk 没有显示目标硬盘解决方法：检查硬盘连接是否牢固尝试更换 USB 接口或 SATA 接口运行 sudo partprobe 重新扫描磁盘2. 权限不足问题：dd 命令提示权限 denied解决方法：确保使用 sudo 执行命令检查当前用户是否在 sudo 组中3. 写入速度慢问题：写入速度远低于预期解决方法：确保使用 USB 3.0 或更高版本接口尝试调整 bs 参数（如 8M、16M）检查硬盘是否处于省电模式4. 写入后无法启动问题：硬盘写入成功但 Mac 无法识别解决方法：确认 DMG 文件完整性检查 Mac 是否支持该 macOS 版本尝试重新写入七、技术要点1. 为什么使用 oflag=directoflag=direct 绕过系统页缓存，直接写入设备。这样做的好处：避免缓存占用大量内存确保数据真正写入硬盘提供更准确的进度信息2. 块大小选择块大小（bs）影响写入效率：太小（如 512B）：频繁 I/O，速度慢太大（如 1G）：占用大量内存推荐值：4M-16M 之间3. DMG 压缩比DMG 文件通常经过压缩，实际写入的数据量可能大于文件大小。本例中 4.7GB 的 DMG 解压后写入约 5GB 数据。八、总结在 Linux 上将 macOS 安装文件写入 NVMe 硬盘是一个简单的过程，核心是使用 dd 命令。关键要点：正确识别目标设备，避免误操作使用合适的参数提高写入效率写入完成后验证结果整个过程通常只需要几分钟即可完成。参考资料dd 命令官方文档macOS 恢复模式使用指南

服务器集群运维文档
type: item
date: 2026-04-02T01:01:40+00:00
description: 服务器集群运维文档一、集群概览1. 集群信息A. 节点列表主机名IP 地址角色操作系统内核版本xlab-ecs-node2192.168.86.152Kubernetes 节点Ubuntu 22.04.5 LTS5.15.0-173-genericxlab-ecs-node3192.168.86.153Docker 容器节点Ubuntu 22.04.5 LTS5.15.0-173-genericB. 集群用途xlab-ecs-node2：Kubernetes 集群工作节点xlab-ecs-node3：Docker 容器部署节点二、硬件配置1. CPU 配置A. 处理器规格型号：Intel Xeon E5-2697 v2 @ 2.70GHz核心数：24 核（12 核/单线程 × 2 线程）频率范围：1200 MHz - 3500 MHz架构：x86_64B. 虚拟化支持VT-x：已启用VT-d：已启用2. 内存配置节点总内存可用内存Swapxlab-ecs-node262 GB约 58 GB8 GBxlab-ecs-node347 GB约 40 GB8 GB3. 存储配置A. 磁盘列表节点设备容量类型挂载点用途xlab-ecs-node2sda931.8 GBSSD/系统盘xlab-ecs-node3sda931.8 GBSSD/系统盘xlab-ecs-node3sdb238.5 GB未挂载-预留扩展B. 文件系统类型：ext4主分区：/dev/sda2 挂载于 /4. 网络配置A. 网卡信息网卡 1：enp11s0（Broadcom BCM57762 千兆以太网）网卡 2：enp12s0（Broadcom BCM57762 千兆以太网）无线网卡：wlp13s0（Broadcom BCM4360 802.11ac）B. 网络绑定绑定模式：bond0（Active-Backup）状态：双网卡绑定，高可用C. 网络接口对比节点bond0 MAC 地址容器网络xlab-ecs-node296:fd:b9:44:54:6bflannel.1 + cni0xlab-ecs-node3d2:4f:29:66:e9:dfdocker0 + 多个 bridge5. 显卡配置A. GPU 规格型号：AMD Radeon R7 370 / R9 270X/370X（双卡）芯片：Curacao XT / Trinidad XT数量：每台服务器 2 张三、系统环境1. 操作系统A. 基本信息发行版：Ubuntu 22.04.5 LTS（Jammy Jellyfish）版本 ID：22.04架构：x86_642. 内核配置A. 当前内核版本：5.15.0-173-generic编译时间：2026 年 3 月 6 日B. 启动参数BOOT_IMAGE=/boot/vmlinuz-5.15.0-173-generic root=UUID=<分区-UUID> ro intel_idle.max_cstate=1 mce=offC. 参数说明参数值作用intel_idle.max_cstate1限制 CPU C-State 到 C1，降低延迟mceoff禁用 Machine Check ExceptionD. GRUB 配置默认启动项：0等待时间：5 秒内核参数：intel_idle.max_cstate=1 mce=off3. 时区配置节点时区UTC 偏移xlab-ecs-node2Asia/ShanghaiUTC+8xlab-ecs-node3Etc/UTCUTC+0注意：两台节点时区不一致，建议统一为 Asia/Shanghai。4. 已安装内核当前版本：5.15.0-173-generic旧版本：5.15.0-119-generic（备用）四、容器运行时1. 运行时对比节点容器运行时网络插件xlab-ecs-node2Containerd + KubernetesFlannel + CNIxlab-ecs-node3DockerBridge 模式2. Kubernetes 节点（node2）A. 网络组件flannel.1：Overlay 网络cni0：CNI 网桥veth*：容器虚拟网卡B. Pod 网络MTU：1450网段：由 Flannel 自动分配3. Docker 节点（node3）A. 网络组件docker0：Docker 默认网桥br-*：用户自定义网桥veth*：容器虚拟网卡B. 容器网络MTU：1500模式：Bridge五、监控指标1. 系统资源A. CPU 监控使用率阈值：> 80% 告警负载阈值：1 分钟 > 核心数 × 0.8B. 内存监控使用率阈值：> 85% 告警Swap 使用：> 1 GB 告警C. 磁盘监控使用率阈值：> …

Nagios 容器路径配置错误故障复盘
type: item
date: 2026-04-01T00:54:46+00:00
description: Nagios 容器路径配置错误故障复盘一、事件概述1. 事件背景2025-04-01 在服务器 192.168.86.153 上部署 Nagios 监控系统容器时，容器启动失败，日志显示多处路径无法访问的错误。2. 影响范围A. 影响用户数运维团队无法访问 Nagios 监控界面B. 影响时长约 15 分钟C. 影响功能Nagios 核心服务无法启动，Web 界面无法访问3. 严重程度P2 级故障（监控服务不可用）二、事件时间线1. 故障发生（00:46）A. 现象描述容器启动后立即退出，日志报错：无法打开日志文件 /usr/local/nagios/var/nagios.log无法读取资源文件 /usr/local/nagios/etc/resource.cfg检查结果路径 /usr/local/nagios/var/spool/checkresults 不是有效目录B. 监控告警容器日志显示配置文件处理失败，程序中止2. 问题分析（00:47）A. 发现途径SSH 登录服务器查看容器日志和配置文件B. 初步判断配置文件中的路径与容器实际挂载路径不匹配3. 根因定位（00:48）A. 分析结果Docker Compose 配置将宿主机目录挂载到容器的 /opt/nagios 路径，但 Nagios 配置文件中仍然使用 /usr/local/nagios 路径B. 影响范围nagios.cfg：58 处路径需修改resource.cfg：$USER1$ 宏路径错误cgi.cfg：Web 界面配置路径错误nsca.cfg、commands.cfg：部分路径需修改4. 修复实施（00:48-00:50）A. 处理措施批量替换所有配置文件中的路径前缀B. 验证结果容器成功启动，服务正常运行5. 二次问题发现（00:51）A. 现象描述Web 界面登录后报错：无法打开主配置文件 /usr/local/nagios/etc/nagios.cfgB. 根本原因cgi.cfg 中的 main_config_file 路径未修改C. 解决方案修改 cgi.cfg 并重启容器，问题完全解决sequenceDiagram participant U as 用户 participant D as Docker participant C as 配置文件 participant N as Nagios U->>D: 启动容器 D->>C: 读取 nagios.cfg C-->>D: 路径错误 D->>N: 启动失败 U->>C: 批量替换路径 C->>C: /usr/local -> /opt U->>D: 重启容器 D->>N: 启动成功 U->>N: 访问 Web 界面 N->>C: 读取 cgi.cfg C-->>N: 路径仍错误 U->>C: 修改 cgi.cfg U->>D: 再次重启 N-->>U: 完全正常三、问题分析1. 直接原因配置文件使用硬编码的 /usr/local/nagios 路径，与 Docker 镜像实际工作目录 /opt/nagios 不一致2. 根本原因（5 Whys 分析）A. 为什么出现这个问题？Docker 镜像采用 /opt/nagios 作为工作目录，但配置文件是从传统安装方式复制而来，仍使用默认的 /usr/local/nagios 路径B. 为什么没有及时发现？配置文件未在容器化部署时进行路径适配C. 如何避免？容器化部署时应统一配置文件路径与镜像工作目录3. 深层反思Docker Compose 挂载配置与容器内路径存在不一致，需要在部署前进行路径一致性检查四、解决方案1. 临时方案A. 实施措施使用 sed 批量替换所有配置文件中的路径前缀B. 效果评估快速修复，服务恢复正常2. 永久方案A. 改进措施创建配置模板，使用环境变量定义路径前缀在 entrypoint 脚本中自动适配路径B. 实施计划更新 Docker 镜像构建流程3. 预防措施部署前检查配置文件路径与容器挂载点一致性建立容器化部署 checklist五、经验总结1. 做得好的地方快速定位问题根因批量替换提高修复效率创建配置文件备份2. 需要改进的地方部署前未进行路径一致性检查缺少自动化配置验证脚本3. 流程优化建议在 Docker Compose 启动脚本中添加配置验证步骤，提前发现路径不匹配问题参考资料Nagios 官方文档

15年单服务器8GB内存服务50万用户——Webminal生存之道
type: item
date: 2026-03-31T06:17:31+00:00
description: 15年单服务器8GB内存服务50万用户——Webminal生存之道一、事件概述1. 项目背景Webminal.org 是一个在线 Linux 终端学习平台，让用户通过浏览器直接访问真实的 Linux 终端进行学习。该项目自 2011 年启动，至今已运行 15 年。2. 核心数据A. 规模数据运行时长：15 年（2011-2026）服务用户：500,000 名注册用户服务器配置：单台 CentOS 服务器，8GB RAM命令执行统计：超过 2800 万条命令B. 技术特点无 Kubernetes 集群无微服务架构无自动扩容单服务器运行3. 历史考验该平台经历了多次重大考验：2021 年数据中心火灾（丢失 15 万用户账户）荷兰多次停电2017 年西班牙科技博客涌入 1 万名用户创始人之间从未见过面的远程协作二、系统架构1. 技术栈graph TB subgraph 用户端 A[浏览器] end A -->|WebSocket/AJAX| B[Nginx] B --> C[Flask 0.12.5] C --> D[MySQL数据库] C --> E[Shellinabox终端] E --> F[共享Linux环境] C --> G[UML Root Labs] G -->|独立内核| H[用户虚拟机] H --> I[虚拟块设备 LVM/RAID/fdisk] C --> J[eBPF监控] J --> K[命令实时统计]2. 技术选型组件技术选型版本/说明编程语言Python2.7Web 框架Flask0.12.5终端模拟Shellinabox2005 年发布，2017 年弃用Root 实验室User Mode Linux2001 年技术监控eBPFexecsnoop（唯一现代技术）数据库MySQL存储在火灾中幸存前端纯 HTML + CSS无 React/Vue/npm3. 基础设施迁移历程graph LR A[2011 Linode] --> B[DigitalOcean] B --> C[AWS] C --> D[GCP] D --> E[OVH] E --> F[IBM Cloud] F --> G[2025 Linode] G -->|循环回到起点| A三、核心功能1. 新版更新A. 现代化 UI全新设计的用户界面无 Bootstrap 或 jQuery CDN 依赖自托管字体移动端响应式支持B. Root Lab提供完整 root 权限的系统管理员实践环境，支持：fdisk 磁盘分区LVM 逻辑卷管理RAID 阵列配置mkfs 文件系统创建systemctl 服务管理crontab 定时任务firewalld 防火墙配置SSH 密钥管理awk 与 sed 文本处理C. 实时命令统计首页滚动显示实时命令执行情况基于 eBPF（execsnoop）实时追踪累计执行命令超过 2800 万条2. Shellinabox 终端A. 技术选择团队曾尝试用现代 WebSocket 终端替代 Shellinabox，但生产环境仅运行几小时就出现：空白屏幕问题Firefox 兼容性问题B. 回归原因Shellinabox 虽然来自 2005 年，界面简陋且速度较慢，但具有以下优势：可穿透所有防火墙兼容各种代理服务器支持企业内网环境3. User Mode Linux 架构graph TB subgraph UML虚拟机 A[用户空间内核] B[虚拟块设备 sda-sdd] C[256MB RAM] D[Copy-on-Write] end E[主机系统] -->|资源隔离| A A -->|fdisk/LVM/RAID| B A -->|内存限制| C F[Golden镜像] -->|COW共享| D D --> G[100用户~2GB磁盘] H[poweroff] -->|退出UML| EA. UML vs Docker为什么不使用 Docker？需求DockerUML虚拟块设备不支持支持 4 个虚拟块设备fdisk 练习无法真实执行完全支持内核隔离共享主机内核独立内核实践场景容器化应用系统管理技能B. 资源分配每个 UML 实例获得：完整的 Linux 内核（非容器）4 个虚拟块设备（每个 64MB）256MB RAMCopy-on-Write 写时复制层C. 存储效率Copy-on-Write 机制使得 100 个并发用户仅需约 2GB 磁盘空间，所有用户共享同一个 Golden 镜像。四、协作模式1. 创始团队创始人：来自印度联合创始人 Freston：来自荷兰相识平台：LinuxForums.org（2010 年）2. 沟通方式2010-2015 年期间，两人从未见过面，甚至没有通过 Skype 见过对方的脸。所有协作通过…

Mac Pro GPU 配置问题排查与修复
type: item
date: 2026-03-30T11:31:55+00:00
description: Mac Pro GPU 配置问题排查与修复一、事件概述1. 事件背景在 Mac Pro 垃圾桶（Late 2013）上运行 GPU 配置工具的 auto 模式后重启，系统出现 debugfs 警告信息，且图形界面无法正常显示，停留在 TTY 文本界面。2. 影响范围A. 影响用户数单台开发服务器B. 影响时长约 30 分钟排查与修复时间C. 影响功能图形用户界面无法显示，仅可通过 SSH 远程访问3. 严重程度P2 级问题（单机功能受损，可通过 SSH 维护）二、事件时间线1. 问题发现（19:20）A. 现象描述系统重启后，本地显示器显示 TTY 文本界面，无法进入图形桌面。SSH 可以正常登录。B. 监控告警系统日志中出现大量 debugfs 相关警告信息：debugfs: radeon_ring_uvd already exists in / debugfs: radeon_fence_info already exists in /2. 问题诊断（19:20 - 19:25）A. 发现途径用户通过 SSH 登录系统查看日志B. 初步判断系统运行正常，但图形界面未正确启动。debugfs 警告实际上是双 GPU 系统的正常行为。3. 根因分析（19:25 - 19:30）A. 分析过程检查发现 GNOME Shell 和 Wayland 会话在后台运行，但显示器未显示图形界面。B. 根本原因Wayland 与 radeon 驱动存在兼容性问题，导致图形合成器无法正常输出到显示器。4. 问题解决（19:30）A. 解决方案禁用 GDM 的 Wayland 支持，强制使用 X11B. 验证结果图形界面正常显示，OpenGL 加速工作正常sequenceDiagram participant U as 用户 participant S as 系统 participant G as GDM participant X as X11/Wayland U->>S: 运行 auto 模式 S->>S: 重启系统 S->>G: 启动显示管理器 G->>X: 尝试 Wayland X-->>G: 兼容性问题 U->>S: SSH 诊断 S->>G: 禁用 Wayland G->>X: 使用 X11 X-->>U: 图形界面显示三、问题分析1. 直接原因GDM 默认使用 Wayland 显示服务器，但 Wayland 与 radeon 驱动在 Mac Pro 双 GPU 配置下存在兼容性问题。2. 根本原因（5 Whys 分析）A. 为什么出现这个问题？Wayland 需要驱动支持特定的 KMS（内核模式设置）功能，而 radeon 驱动在双 GPU 场景下的支持不完善。B. 为什么 debugfs 有警告？这是双 GPU 系统的正常行为。第一块 GPU 初始化时创建了 debugfs 调试条目，第二块 GPU 初始化时尝试创建同名条目，导致警告。这些警告不影响功能。C. 为什么 auto 模式没有发现问题？auto 模式主要配置驱动参数和内核命令行，但无法检测 Wayland 兼容性问题。3. 深层反思Linux 桌面环境在老旧硬件和多 GPU 场景下的兼容性仍需改进。auto 模式可以增加图形界面验证步骤。四、解决方案1. 临时方案无需临时方案，问题可立即修复2. 永久方案A. 改进措施创建 GDM 配置文件，禁用 Wayland：mkdir -p /etc/gdm3 cat > /etc/gdm3/custom.conf << 'EOF' [daemon] UnattendedUpdate=true WaylandEnable=false EOF systemctl restart gdm3B. 实施计划立即执行，重启后永久生效3. 预防措施A. 代码层面在 GPU 检测脚本中添加图形界面测试，验证 Wayland/X11 兼容性B. 文档层面在 Mac Pro 配置文档中说明已知问题和解决方案C. 工具层面考虑提供 --force-x11 参数，让用户可以手动选择 X11 模式五、系统状态确认1. 硬件配置组件详情机型Mac Pro Late 2013（垃圾桶）GPU1FirePro D300 (02:00.0), 2048MB VRAMGPU2FirePro D300 (06:00.0), 2048MB VRAM驱动radeon显示器连接到 card0 DisplayPort-9, 1024x6002. 软件配置项目状态操作系统Ubuntu 24.04内核版本6.17.0-19-generic显示管理器GDM3 (X11 模式)桌面环境GNOMEOpenGL直接渲染已启用3. 驱动配置modprobe 配置：options rad…