Selfhost

在 mailcow 中停用 ClamAV 与 OnlyOffice 的实践记录

一、背景说明 在一套基于 Docker Compose 运行的 mailcow 邮件系统中，随着服务组件逐渐增多，内存占用开始成为需要关注的资源项。系统主要用于低频、自用场景，不存在大规模外部用户或高并发邮件流量。 在对整体容器资源使用情况进行评估后，发现部分组件在当前使用场景下性价比偏低，有进一步精简的空间。 二、资源使用情况初步分析 通过 docker stats 对运行中的容器进行统计，可以观察到以下特点： 基于上述观察，决定对这两个组件进行停用验证。 三、停用 OnlyOffice 的处理结果 OnlyOffice 作为独立服务容器，在停止后： 该结果符合预期，表明 OnlyOffice 与核心邮件链路无强依赖关系，适合在不需要在线文档协作的场景下停用。 四、ClamAV 的停用方式与验证 4.1 配置层面的停用方式 mailcow 并不推荐直接修改 docker-compose.yml 或手动删除 service，而是通过配置变量控制组件启停。 在配置文件中设置： 该变量用于告知 mailcow 在启动阶段跳过 ClamAV 相关逻辑。 4.2 实际运行行为观察 停用后仍可在容器列表中看到 clamd 容器，但其行为发生了明显变化： 这表明： 从功能和资源角度看，ClamAV 已处于“逻辑完全禁用”状态。 五、停用后的整体状态评估 在 ClamAV 与 OnlyOffice …

Network

Asahi 勒索事件与 MFA 安全模型分析

事件背景 近期，日本大型企业 Asahi 集团披露其内部系统遭到勒索软件攻击。多个安全媒体确认，该事件并非简单的自动化攻击，而是一次具备明确目标、持续渗透和横向移动特征的 人工入侵型勒索事件。攻击者被认为与 Qilin 勒索软件组织有关。 从已公开的信息可以确认： 目前并无可靠公开信息披露具体赎金金额，亦无法确认受害方是否支付赎金。 是否会被法律追责 从法律层面看，勒索软件攻击属于严重刑事犯罪；但在现实中，类似 Qilin 的跨国勒索组织 极少真正受到司法追责。主要原因包括： 因此，“违法”与“能否被追责”在现实世界中存在明显落差。 入侵路径分析：SSH 还是 Web？ 截至目前，没有公开证据确认 Asahi 是通过 SSH 还是 Web 服务被直接攻破。但结合企业环境特征与勒索组织的常见攻击模式，可以做出较为可靠的排除与判断。 排除可能性较高的路径 更可能的真实入口 攻击者能够长期稳定地外传大量数据，本身就说明其获得的是 持续、可信的内部访问权限。 MFA（多因素认证）的现实意义 MFA（Multi-Factor Authentication，多因素认证）指登录验证不再只依赖单一密码，而是组合以下至少两类要素： 在现实安全模型中，MFA 的作用并不是“提高一点安全性”，而是 直接切断绝大多数常见入侵路径： 因此，在 VPN、远程管理、邮件系统、云控制台等关键入口未启用 MFA 的情况下，企业几乎处于高风险状态。 一个重要的现实结论 从大量企业勒索案例可以观察到： 攻击者并不依赖“技术上一定能攻破”，而是选择最省成本、最容易得手、最容易横向扩散的入口。 这意味着，安全的核心并不是假设攻击者会被法律阻止，而是： 总结 Asahi 事件并不说明“大企业不懂安全”，而是揭示了现实世界的安全边界： 从工程视角看，多因素认证 + 最小入口原则，依然是对抗现实勒索威胁最有效、性价比最高的防线。

Server

PVE 虚拟机启动失败的一次完整排障记录（内存相关）

主题：Proxmox VE（PVE）中，虚拟机在还原旧备份后仍无法启动，最终定位为**启动阶段可用内存不足（OOM）**的问题。 一、问题背景 在一次正常运行多时的 PVE 环境中，宿主机出现网络异常，随后进行了按电源键关机与强制断电。重启后发现： 这使得初期判断偏向于： 二、初期排查与误导方向 1. PVE 与宿主机层面 2. 虚拟机层面 这些现象说明： 数据本身完好，问题不在磁盘或文件系统层面。 三、关键现象：内核 Panic 与 OOM 在切换 BIOS（OVMF / SeaBIOS）后启动虚拟机，屏幕出现如下典型信息： 进一步查看启动日志，出现大量 OOM（Out Of Memory） 记录： 这明确指向： 虚拟机在 early boot 阶段内存严重不足，启动核心进程被 OOM Killer 反复杀死。 四、关键误区：最大内存 ≠ 启动可用内存 虚拟机的内存配置为： 表面看内存充足，但从 OOM 日志可计算出： 在 无 swap 的情况下，这一内存规模不足以完成： 从而导致 OOM → …

Server

USB 硬盘柜作为 LVM 数据盘的健康检查记录（虚拟化环境）

一、问题背景 在虚拟化宿主机环境中，使用 USB 硬盘柜扩展大容量存储是一种常见方案。这种方案在成本和灵活性上具有优势，但在稳定性层面也存在一些天然短板。 本文记录一次针对 USB 接入的大容量数据盘（LVM 架构） 的系统性检查过程，目标并非“证明一切正常”，而是明确： 二、存储结构概览 数据盘采用典型的单盘 LVM 结构： 逻辑卷已处于激活状态，并被宿主系统正常使用。 三、分区与扇区对齐检查 数据盘特征如下： 分区起始位置采用标准的 1MiB 对齐方式。 结论 四、LVM 状态检查 对 LVM 各层进行检查后，得到以下结论： 结论 LVM 元数据、映射关系及激活状态均正常 至此，可以明确排除 LVM 结构异常 这一方向。 五、关键判断：风险不在分区与 LVM 在分区与 LVM 层面均确认正常后，排查重点需要下移。 在 USB 硬盘柜场景中，问题通常并不来自： 而是集中在以下层面： 六、必须重点关注的实际风险点 1. 内核日志中的 I/O 与 USB 事件 这是判断 USB …

Network

OpenWrt LuCI 是否支持两步验证（2FA）？以及更安全的实践方案

一、问题背景 在使用 OpenWrt 作为家庭或个人网络核心时，一个很自然的问题是： LuCI 管理界面是否支持两步验证（2FA / TOTP）？ 这个问题在“公网 IP + 自建服务 + 长期运行”的场景下尤其常见，因为一旦路由器被入侵，后果往往是灾难性的。 本文将从事实、原因和现实可行的安全实践三个层面，系统回答这个问题。 二、结论先行 结论很明确： OpenWrt 官方的 LuCI 管理界面，并不原生支持两步验证（2FA）。 而且这并不是功能缺失，而是一个有意的设计取舍。 三、为什么 LuCI 没有原生 2FA LuCI 的设计目标与典型的 Web 后台系统完全不同： 技术上，LuCI 的认证模型通常是： 在这个模型下： 因此，官方并没有为 LuCI 设计内建 2FA，也没有计划添加。 四、一个重要认知：LuCI 是否真的“需要”2FA？ 在实际运维中，几乎没有人依赖 LuCI 自身来承担公网安全责任。 原因很简单： 真正的安全，从来不是在“最后一层登录页”加功能，而是从入口设计开始。 对 LuCI 而言，安全的关键问题不是： 而是： 五、更现实、更可靠的安全实践（推荐方案） 以下方案按照安全收益 …

Hardware

内存一定要是 8 / 16 / 32 GB 吗？

关于“非整数内存分配”和虚拟机运行的一个常见误解 在使用电脑或虚拟机的过程中，经常能听到一种说法： “内存一定要是 8GB、16GB、32GB 这种整数倍，不然系统运行会不稳定。” 甚至在虚拟化环境中，也有人会刻意避免给虚拟机分配诸如 7GB、13GB、7.5GB、3.5GB 这样的内存容量，担心会“跑不起来”或者“有隐藏问题”。 结论先说：这是一个误解。 一、系统并不要求内存是“整数倍” 从操作系统和硬件的角度来看： 也就是说： 只要内存容量能被页大小整除，就不存在“不能运行”的问题 而 7GB、7.0125GB、13GB、3.5GB 这种数值： 不存在“不是 2 的倍数就不工作”的硬性限制。 二、虚拟机可以分配 7.0125GB 内存吗？ 可以，而且是完全可以。 在常见虚拟化平台（例如 KVM / PVE / VMware / VirtualBox）中： 因此： 都可以正常启动、运行、长期使用。 虚拟机并不会因为“这个数值看起来不漂亮”而出问题。 三、那为什么大家都用 8 / 16 / 32 GB？ 这其实是历史和工程习惯导致的，而不是技术强制要求。 主要原因有三点： 1️⃣ 硬件组合与市场规格 2️⃣ 双通道 / 多通道“更容易凑” 3️⃣ …

Storage

一次 LVM + ext4 + 容器运行时 场景下的系统卡死排障记录

关键词：LVM、ext4、容器运行时、、、、hung task 这篇文章记录了一次典型但很容易被误判的 Linux 系统故障排查过程。问题表面看起来是 / 容器运行时 / 接连报错，但根因其实在底层存储与文件系统一致性。 如果你使用的是： 那么这篇记录大概率对你有参考价值。 一、问题现象 系统启动或运行过程中，内核和 日志大量刷屏，主要包括： 伴随的实际表现包括： 这类状态非常迷惑，很容易让人误以为是： 实际上都不是。 二、关键信息：hung task 真正重要的只有一条日志： 这不是 容器运行时 的逻辑错误，而是 Linux 内核的 hung task 检测，含义是： 某个进程（这里是 ）长期处于不可中断状态（D state），通常是在等待 I/O。 一旦出现 hung task： 三、环境确认 进一步确认系统结构： 通过命令确认： 得到结果： 关键信息： 出问题的 ext4 文件系统，正是当前已经挂载为 / 的根分区。 四、为什么 / / 容器运行时 全部出问题 …

Linux

Ubuntu 22.04 升级到 24.04 LTS 记录

本文记录一次 Ubuntu 22.04 LTS → Ubuntu 24.04 LTS 的原地升级过程，适用于已经长期运行、承载多项服务的系统。供后续参考。 一、升级背景与原则 这台系统最早安装于 Ubuntu 16.04，随后经历了 18.04 → 20.04 → 22.04 的多次大版本升级。系统上运行着多个长期服务，因此本次升级遵循以下原则： 升级目标版本为： 二、升级前准备（关键） 1. 确认当前系统版本 确认输出为： 2. 将 22.04 更新到“绝对干净状态” 必须确保在一个完全更新、无残留错误的 22.04 系统上升级。 3. 检查 LTS 升级策略 编辑升级策略文件： 确认内容为： 4. 数据与系统备份（不可省略） 至少满足以下任一条件： 示例（脱敏）： ⚠️ 大版本升级不可逆，备份是底线。 三、正式升级流程 使用官方升级工具（推荐） 若提示： 可使用： 对 LTS 来说，-d …

Linux

Ubuntu 启动时出现 overlayfs 提示的原因与处理

背景 在一次正常启动 Ubuntu 22.04 LTS 系统时，在 TTY 登录界面看到如下内核提示信息： 该提示出现在系统启动过程中或 TTY 登录前，看起来像是一个错误信息，容易让人误以为系统存在异常或潜在故障。本文记录该提示的含义、产生原因以及是否需要处理，供后续排查和参考。 提示信息解析 该信息来自 Linux 内核，逐词解释如下： 需要强调的是： 这是一条 warning（提示），不是 error（错误）。 出现该提示的常见原因 结合实际使用场景，出现该提示通常与以下情况有关： 1. 使用或安装过容器相关组件 例如： 这些组件在启动或初始化时会尝试使用 overlayfs，部分情况下会探测 idmapped 功能，从而触发内核提示。 2. 系统或服务发生过异常重启 例如： 在重新初始化 overlayfs 时，内核会输出该提示。 是否严重？是否需要处理？ 结论明确： 不严重，不需要处理。 具体影响如下表所示： 项目 影响 系统登录 无影响 系统稳定性 无影响 Docker/容器运行 正常 数据安全 不受影响 性能 无明显影响 …

Linux

Rocket.Chat 升级过程中 Docker Compose 拉取失败的原因分析与解决

背景 在对 Rocket.Chat 从 7.9 升级至 7.10.x 的过程中，修改了 docker-compose.yml 中 Rocket.Chat 镜像版本号，随后执行： 结果出现拉取失败，错误信息指向 MongoDB 镜像，而非 Rocket.Chat 本身。 错误现象 执行 docker compose pull 时出现如下关键报错： 同时，Rocket.Chat 镜像拉取被中断： 初步排查结论 因此问题并非配置写错或版本不兼容。 根本原因分析 问题的根源在于 Bitnami MongoDB 镜像的 tag 已在远端 registry 中不存在： Docker 在执行 docker compose pull 时，会对 compose 文件中所有服务镜像执行拉取操作： 一旦 registry 中不存在该 tag，就会直接报错并中断整个 pull 流程。 …