Server

从混乱云镜像到极简稳定 VPS：一次 Ubuntu 服务器瘦身与修复实战

在云服务器环境中，Ubuntu 官方 Cloud Image 往往为了“通用性”而内置了大量面向物理机、桌面或开发环境的组件。这些组件在 VPS 上不仅没有意义，还会带来磁盘浪费、升级风险以及依赖混乱。 本文记录了一次真实的 Ubuntu 24.04（noble）云主机修复与极简化过程，从发现磁盘异常、定位无用组件，到修复 APT 依赖与源混乱，最终将系统恢复为一个干净、稳定、适合长期运行网络服务的 VPS 系统。 一、问题的起点：异常臃肿的 /usr/lib 通过分析 /usr/lib 目录发现系统体积远大于典型 VPS： 其中包含大量不应出现在 VPS 上的组件： 这些都是典型“桌面 / 物理机 / 开发环境”遗留物。 二、发现根因：APT 源跨区域导致版本漂移 进一步排查发现系统使用了： 在 Ubuntu 24.04 的 .sources 格式下，这种跨站点组合极易导致： 表现为： 这是典型的仓库不一致导致的依赖破坏。 三、正确做法：统一为日本官方仓库 Ubuntu 24.04 采用 /etc/apt/sources.list.d/ubuntu.sources，必须修改该文件，而不是传统 sources.list。 统一切换到日本官方镜像（JAIST）： 然后清空索引并重建： 验证 systemd 依赖已恢复： …

Server

用一份脚本给 VPS 做“体检”：vps_healthcheck.sh 深度解析

在迁移 VPS、排查服务器不稳定、评估主机质量时，仅凭“感觉卡”是远远不够的。真正有价值的，是一份能够在某个时间点完整记录服务器运行状态的“体检报告”。 本文介绍并解析一个实用的 Bash 脚本 —— vps_healthcheck.sh，它的作用是：在几秒钟内抓取 VPS 的 CPU、内存、磁盘、IO、网络、内核状态，并保存为可追溯的日志文件。 这类脚本广泛用于运维取证、迁移前后对比、主机质量评估等场景。 一、完整脚本（脱敏版） 二、脚本的核心定位 该脚本并不尝试修复系统，也不对服务器进行任何修改。它的唯一目标是： 在某一时刻，对 VPS 进行一次完整、可留存的健康快照。 这份快照可以用于： 三、为什么这个日志设计很专业 脚本使用： 意味着： 所有输出 → 屏幕 + 文件 同步写入 这样可以： 这是标准运维“取证型日志”设计方式。 四、采集了哪些关键指标 1. CPU 与虚拟化环境 通过 lscpu 可判断： 用于识别 VPS 是否存在严重超售。 2. 内存与 OOM 风险 free -h + /proc/meminfo 可以看到： 这是判断系统是否会因内存压力杀进程的核心依据。 3. …

Backup

使用 SFTP 迁移文件时，如何正确保留时间与权限

在服务器迁移、VPS 更换、或跨主机复制文件时，一个常见需求是：既要保证文件内容一致，也要尽量保留原始的时间戳和权限设置。 很多人会选择 SFTP 作为传输工具，但对它的“属性保留能力”存在误解。本文将从协议能力、客户端行为和实际使用方式三个层面进行说明。 SFTP 是否支持文件属性传输？ 是的。SFTP 协议在设计时就包含了“文件属性”的字段，除了文件内容以外，还可以携带： 也就是说，SFTP 并不是一个“只传字节流”的协议，它天生就支持基本元数据的同步。 关键在于：客户端是否开启 preserve 虽然协议支持，但很多 SFTP 客户端默认不会保留这些属性。以 OpenSSH 自带的 sftp 为例，必须显式启用 -p 参数。 -p 表示：preserve（保留属性） 开启后，这个会话中所有的文件传输都会自动携带属性信息。 使用 sftp -p 后会保留什么？ 在 OpenSSH 的实现中，-p 实际保留的是： 属性 是否保留 文件权限（rwx / mode） ✅ 修改时间（mtime） ✅ 访问时间（atime） 多数实现支持 所有者（uid / gid） ❌ ACL ❌ xattr …

Server

在云服务器上识别并精简运行中的 systemd 服务：一次 VPS 体检与迁移前准备

在进行 VPS 迁移或系统重构之前，对当前服务器中正在运行的服务进行一次系统级审计是非常必要的。这不仅可以避免迁移过程中出现端口占用、服务冲突，还可以发现隐藏的云厂商组件与多余的后台服务，从而为构建一个“干净、可控的中继节点”打下基础。 本文记录了一次对云服务器 systemd 服务的完整盘点、来源识别以及迁移前停机处理的全过程。 一、列出正在运行的服务 在 Linux VPS 上，可以通过 systemd 查询当前所有处于 running 状态的服务： 这一步可以看到当前系统里有哪些 daemon 正在常驻运行，例如网络服务、日志系统、安全组件以及第三方业务服务。 二、识别服务来源（系统 vs 用户 vs 云厂商） 仅仅看到服务名是不够的，关键在于知道它们是： 最重要的信息是每个 service unit 的 FragmentPath，即它的 .service 文件位于哪里： 经验规律： 路径 含义 /lib/systemd/system/ 系统包提供 /usr/lib/systemd/system/ 系统或第三方包 /etc/systemd/system/ 用户或云厂商手动放入 这一步可以精确区分哪些服务是系统必须的，哪些是后期被引入的。 三、识别“真正的业务服务” 通过 unit 路径与已手动安装的软件包列表（apt-mark showmanual）对照，可以清晰分离出真正用于公网通信与远程访问的核心服务： 类型 作用 代理服务 提供对外的网络代理入口 …

Mac

使用 hdparm 和 hd-idle 管理 iMac 内置硬盘的待机状态

很多用户在给 iMac 安装 Linux 后，会选择把系统和数据放在 USB 外接 SSD 或硬盘上，而让内部的 NVMe 与 3.5 寸机械盘“闲置”。但一个非常重要的事实经常被忽略： 即便没有分区、没有挂载、完全不使用，内置机械盘也会在通电状态下持续旋转。 这不仅会造成不必要的功耗，还会持续消耗机械寿命并产生热量。 本文介绍一种工程级的解决方案，使 iMac 内部的 1TB 机械盘在 Linux 下真正成为“冷备用盘”。 一、机械硬盘“没用也在转” 在 Linux 中，使用： 可以查看机械盘的当前状态。 典型输出： 这表示： 即便磁盘没有任何分区或文件系统，这个状态也不会改变。 对一块 3.5″ 7200RPM 的桌面级 HDD（如 Apple 定制的 ST1000DM003）来说，这意味着 持续 5–8W 的功耗和持续机械磨损。 二、将内置 HDD 手动送入真正的 Standby Linux 允许直接向 SATA 设备发送停转命令： 再检查状态： …

Server

在 Ubuntu 服务器上精确识别「用户自己安装的 systemd 服务」

在运维 Linux 服务器时，经常会遇到这样的问题：系统里注册了大量 systemd 服务，但其中绝大多数属于操作系统自带组件，而真正由管理员后期安装、配置过的服务却被淹没在其中。如果无法区分这两类服务，就很难判断哪些服务是业务依赖，哪些是历史遗留或冗余组件。 本文以一台 Ubuntu 服务器为例，系统性地展示如何识别「用户自行安装的服务」，包括正在运行和已经停用但仍然存在的部分。 一、为什么 running 列表不够用 很多人会使用： 来查看系统当前运行的服务。这个命令只能回答一个问题： “现在有哪些服务在跑？” 但它完全无法反映以下信息： 因此，仅依赖 running 视图会得出错误结论，例如误以为系统“只有 Apache 和 MySQL”。 二、真正的总清单：所有已注册的服务 systemd 中，所有服务的定义都存放在 unit files 中，可以通过： 获得完整列表。这个列表显示： 在示例服务器中，共列出了 249 个 unit 文件。 但其中绝大多数是 Linux 与 Ubuntu 自带组件（systemd、udev、networkd、fsck、plymouth 等），需要进一步过滤。 三、用服务内容反推系统画像 通过分析 unit 文件，可以反推出这台服务器的历史和用途： 1. Web 与数据库业务 这是一套典型的 LAMP Web 服务器栈。 …

Server

树莓派 SD 卡健康状态检测与判定实录

在树莓派系统中，SD 卡既承担启动分区，又承担根文件系统与日志写入，是整个系统中最容易损耗、却最关键的部件。当树莓派被用作服务器、运行 Docker、执行大量 rsync 或系统迁移时，SD 卡的寿命与稳定性就变得尤为重要。 本文记录了一次完整、工程化的 SD 卡健康检测过程，并给出明确的技术结论。 一、存储设备基本信息 首先确认树莓派当前使用的存储设备： 输出显示： 说明系统使用的是一张 8GB 级别的 SDHC 卡（约 7.48GiB 可用容量），设备型号显示为 NCard，属于无品牌或低端 SD 卡类别。 二、eMMC 寿命寄存器检测 尝试读取 eMMC 的寿命寄存器（EXT_CSD）： 返回： 这是正常现象。 EXT_CSD 只存在于 eMMC 设备中，而普通 SD 卡物理上并不支持这一寄存器，因此无法读取。这一结果并不表示故障，而是说明该存储介质是标准 SD 卡。 三、文件系统一致性检查 对根分区执行只读检查： 结果： 这代表： 如果 SD 卡出现物理退化或闪存错误，这里通常会出现 I/O 错误或结构损坏提示。 四、内核 I/O 错误检查 查看内核是否记录了存储层异常： …

Network

一次典型的 Postfix 邮件堆积事故：从 DNS 错误到 SMTPUTF8 协议不匹配

摘要 某台运行 Postfix 的 Linux 服务器在连续多天内无法向自建 Mailcow 邮件服务器发送系统告警邮件，邮件队列持续增长。表面错误为 DNS 解析失败（4.4.3 Host not found），在 DNS 修复后仍存在投递异常。最终发现是 SMTPUTF8 协议能力不匹配导致部分邮件被永久拒绝（5.6.7）。 本文完整记录该事故的诊断路径与修复策略。 1. 事故现象 Postfix 日志中持续出现： 邮件队列中积压多封系统邮件（root → admin），时间跨度超过 5 天。 2. 第一层问题：DNS 故障导致长期队列堆积 检查发现系统的 /etc/resolv.conf 曾指向错误的网关地址（例如 192.168.0.1 而不是实际使用的 192.168.1.1），导致 Postfix 在那段时间无法解析 mail.example.net。 DNS 修复后： 均返回正确 IPv4 地址，说明系统 DNS 已恢复。 但邮件仍不断失败，是因为 Postfix 会对 4.x.x …

Medicine

一份体检报告背后的真相

年轻人“代谢型糖尿病”的可逆窗口期 一、这不是“几个异常指标”，而是一个系统性代谢问题 在一份常规体检中，如果同时出现以下情况： 这并不是几个独立的问题，而是同一个代谢系统异常在不同器官的投射： 内脏脂肪堆积 → 肝脏脂肪化 → 胰岛素抵抗 → 血糖上升 → 血脂上升 → 肝细胞损伤 医学上将这一整套状态称为：代谢综合征伴早期 2 型糖尿病与非酒精性脂肪肝（NAFLD） 二、空腹血糖 129 mg/dL 代表什么 空腹血糖的国际标准： 空腹血糖 含义 <100 mg/dL 正常 100–125 糖尿病前期 ≥126 糖尿病 129 mg/dL 已经超过诊断线，因此属于：新发 2 型糖尿病（early type 2 diabetes） 但这与“终身胰岛素”“不可逆慢病”并不等同。 三、为什么这种类型是“可逆的” 这种情况的本质不是胰腺损坏，而是： 肝脏与肌肉被脂肪填满，无法再对胰岛素做出反应 结果是： 这叫：脂肪阻塞型胰岛素抵抗 只要把肝脏和内脏脂肪“清空”，代谢通道就会重新打开。 大量临床研究显示： 在新发 2 …

Titration

盐分滴定中铬酸银的稳定性与健康风险

一、盐分滴定与铬酸银的由来 在食品、环境、水质等检测中，氯离子（盐分）常用**莫尔法（Mohr 法）测定。该方法以硝酸银（AgNO₃）为滴定剂，以铬酸钾（K₂CrO₄）**为指示剂。 当溶液中的氯离子被完全消耗后，多余的银离子与铬酸根结合，生成砖红色的铬酸银（Ag₂CrO₄）沉淀。这一颜色变化被用作滴定终点的判据。 二、铬酸银的稳定性 1. 化学稳定性 铬酸银在中性至弱碱性环境下具有良好的短期稳定性，能够在滴定过程中保持颜色与沉淀形态，因此被选作莫尔法的终点物质。其稳定性高于多数有机银盐，但略低于氯化银。 2. 光与热影响 铬酸银对强光具有一定敏感性，长时间光照可能导致颜色变暗；在高温条件下也会逐渐分解。因此不适合加热或长期保存，但在常规室温滴定条件下是稳定的。 3. 在水中的行为 铬酸银为难溶性物质，主要以湿态沉淀存在，迁移性有限。 三、危险性来源 铬酸银的危险性主要来自其所含的六价铬（Cr(VI)）。 六价铬的特点包括： 需要强调的是，这种风险与暴露方式、剂量和持续时间密切相关。 四、不同暴露途径的风险差异 1. 高风险途径 2. 低风险途径 在皮肤完整、无破损、未形成粉尘、未吸入或吞咽的情况下，六价铬通过皮肤的有效吸收极低。 五、关于常见健康担忧的科学结论 1. 是否会致癌？ 六价铬的致癌风险主要与长期吸入型职业暴露相关。偶然、短时的皮肤接触不构成致癌路径。 2. 是否会在体内富集？ 六价铬进入体内后会迅速被还原为三价铬，并通过尿液排出，不属于生物富集型重金属。 3. 是否影响智力或大脑功能？ 目前没有医学证据表明六价铬通过低剂量皮肤接触会影响成人智力或认知功能。 六、操作层面的真正风险 在多数实际场景中，风险并非来自一次接触，而来自不规范的操作习惯，例如： 这些属于流程与管理风险，而非立即的健康风险。 七、推荐的安全操作原则 八、检测与医学评估的理性边界 在仅存在偶然手部接触、无症状、已停止暴露的情况下： 真正需要医学评估的是： 结论 铬酸银在盐分滴定中具有足够的分析稳定性，但因含六价铬，具有明确的毒性和环境危害属性。其风险主要体现在不当操作和长期暴露，而非规范分析条件下的偶然接触。 在科学认知与规范流程下，该风险是可识别、可控制、可避免的。