本文记录一次 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 …
背景 在一次正常启动 Ubuntu 22.04 LTS 系统时，在 TTY 登录界面看到如下内核提示信息： 该提示出现在系统启动过程中或 TTY 登录前，看起来像是一个错误信息，容易让人误以为系统存在异常或潜在故障。本文记录该提示的含义、产生原因以及是否需要处理，供后续排查和参考。 提示信息解析 该信息来自 Linux 内核，逐词解释如下： 需要强调的是： 这是一条 warning（提示），不是 error（错误）。 出现该提示的常见原因 结合实际使用场景，出现该提示通常与以下情况有关： 1. 使用或安装过容器相关组件 例如： 这些组件在启动或初始化时会尝试使用 overlayfs，部分情况下会探测 idmapped 功能，从而触发内核提示。 2. 系统或服务发生过异常重启 例如： 在重新初始化 overlayfs 时，内核会输出该提示。 是否严重？是否需要处理？ 结论明确： 不严重，不需要处理。 具体影响如下表所示： 项目 影响 系统登录 无影响 系统稳定性 无影响 Docker/容器运行 正常 数据安全 不受影响 性能 无明显影响 …
背景 在对 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 流程。 …
背景说明 在一次 Linux 虚拟机运行过程中，由于操作需要，对虚拟机执行了强制关机（相当于物理断电）。随后再次启动虚拟机时，系统在引导阶段进入了 ext4 文件系统自动检查（fsck），并在控制台输出大量类似以下信息： 同时，系统在该阶段停留时间较长，给人以“卡住”的直观感觉。 现象描述 引导过程中，fsck.ext4 输出了大量 orphaned inode（孤儿 inode） 清理信息，持续时间明显长于平时正常启动。 但在日志中可以观察到： 原因分析 1. 强制关机导致文件系统处于未一致状态 ext4 是日志文件系统，但在以下情况下仍会留下不完整状态： 虚拟机被强制关机时，这些操作会被中断。 2. orphaned inode 的来源 orphaned inode 是指： 在包含 Web 服务、数据库、同步程序（如文件同步系统）等场景下，这类 inode 数量可能较多。 3. fsck 运行缓慢的技术原因 fsck.ext4 运行缓慢并不意味着异常，主要原因包括： fsck 在修复过程中几乎不会提供进度指示，因此容易被误认为“卡死”。 预计耗时范围 在类似环境下，fsck 的常见耗时如下： 场景 耗时范围 数据量较小 5–15 分钟 普通服务器虚拟机 10–30 …
背景说明 在 Proxmox VE（PVE）环境中，对虚拟机执行某些操作（如带内存的快照、暂停或状态保存）时，系统会输出一段看起来较长的日志。本文对一次完整的日志输出进行拆解说明，明确其含义、触发条件以及是否属于异常行为。 一、日志原文（已脱敏） 说明： 二、日志整体结论 该日志并非报错，而是一次“包含内存的虚拟机快照”或“虚拟机状态保存”的正常过程输出。 日志清晰地展示了以下两个阶段： 三、日志逐段解析 1️⃣ 创建虚拟机状态文件 含义： 该文件并非虚拟磁盘，而是“内存快照容器”。 2️⃣ 保存内存与运行状态 说明： 3️⃣ 内存写入进度输出 这是内存写入过程的实时进度信息： 关于“保存内存小于分配内存”的说明 在该环境中： 这是完全正常的行为，原因包括： 该结果表明虚拟机内存处于正常、稳定使用状态。 4️⃣ 日志输出频率降低说明 该提示仅表示： 5️⃣ 内存保存完成，开始磁盘快照 该行表明： 这一步明确说明：此次快照为“包含内存的快照（snapshot with RAM）” 四、该日志通常由哪些操作触发？ 常见触发场景包括： 如果仅执行普通磁盘快照，不会出现内存保存相关日志。 五、是否属于异常？是否需要处理？ ✔️ 正常情况 ➡ 无需任何处理 ⚠️ 需要注意的点（非故障） 六、运维建议（通用） 七、总结 本文所示日志为 Proxmox VE 在执行“虚拟机带内存快照”或“状态保存”时的标准输出。整个过程完整、连续、无异常，属于正常系统行为，不应被误判为错误或性能问题。
在自建服务体系中，电子邮件服务器是最基础、也最容易踩坑的一类服务。要求往往非常苛刻： 经过方案调研与实际部署，最终选择了 Mailcow（Dockerized），并已经稳定运行超过半年。 这篇文章对这段使用经历做一次阶段性技术复盘。 可选方案简要回顾 在选择 Mailcow 之前，常见的自建邮件方案主要包括： 如果仅从功能完整度出发，这些方案的差异非常明显。 内存需求排序（从低到高） 从实际运行经验和社区共识来看，内存需求大致如下： 结论很直接：Mailcow 不是最轻量，但是功能最完整的方案。 为什么最终选择 Mailcow Mailcow 的定位非常明确： 完整邮件系统，而不仅仅是“能收发邮件” 其优势主要体现在： 本质上，它更接近 “企业邮件系统的自建实现”。 半年稳定运行意味着什么 连续运行半年，且未出现结构性问题，本身已经说明： 这也是 Mailcow 相比轻量方案的重要优势：不是实验性质，而是长期可运行的基础设施。 半年节点的关键检查项 在运行半年后，有必要对以下几个关键点进行一次确认，而不是盲目“继续堆功能”。 1. DKIM / SPF / DMARC 状态 这直接决定邮件是否进垃圾箱。至少需要确认： 2. Rspamd 是否真正参与了“学习” 如果半年内： 那么反垃圾系统只是“存在”，而不是“被使用”。 3. ClamAV 是否仍然值得开启 现实结论往往是： 在这种情况下，ClamAV 的收益往往低于其内存成本。关闭后可显著降低整体内存占用，而不影响核心邮件功能。 4. 备份是否“可恢复” 关键问题只有一个： …
摘要 本文记录了一次 RustDesk 自托管服务器 的完整部署实践，采用 Docker + host 网络模式，并结合 宿主机防火墙 与 边界路由器端口转发，在家庭网络环境中实现了稳定可用的远程桌面服务。 出于安全考虑，本文 对所有本地路径、端口号与网络细节进行抽象处理，仅保留架构思路、配置原则与验证方法，确保内容可理解、可复现，但不暴露任何可被直接利用的信息。 一、整体架构思路 RustDesk 官方在 Docker 场景中推荐使用 host 网络模式运行服务，其核心特征包括： 因此，网络安全边界主要由两部分构成： 二、Docker 服务的统一目录管理（路径脱敏） 所有 Docker 服务均集中放置在一个 统一的服务根目录 下，每个应用使用独立子目录管理自身配置与数据，例如： 这种结构的优点在于： 三、Docker Compose 配置（原则级描述） RustDesk 由两个核心组件组成： 二者均以 Docker 容器形式运行，并共享数据目录。 配置原则如下： 示意结构（非可直接复制配置）： 上述示例为结构示意，刻意省略所有具体参数与数值。 四、端口设计原则（不公开端口号） RustDesk 服务需要若干 固定职责端口，但在公开文档中应避免直接暴露数值。 其功能层级可抽象为： 核心通信端口 可选功能端口 在实际部署中应遵循： 五、宿主机防火墙配置原则（以 …
摘要 在一次服务器环境部署过程中，使用 v2rayA 管理代理服务时，先后遇到了两个相互叠加的问题： 这两个问题在受限网络环境下相互影响，导致服务反复启动失败。本文完整记录了问题出现、逐步排查、原因定位以及最终解决的全过程，并总结出一套在类似环境中稳定、可复现的处理方案。 全文已严格脱敏，仅保留必要的技术事实与因果关系。 一、问题背景 在该前提下进行常规部署，出现了一系列连锁问题。 二、问题一：geoip.dat / geosite.dat 缺失 1. 现象 服务层日志提示： geoip.dat or geosite.dat file does not exists 2. 初步判断 根据 v2ray 的运行机制： 因此，问题并非配置错误，而是 资产文件获取失败。 3. 自动下载失败的真实原因 进一步结合环境特征分析后，可以确认： 由此形成典型的“鸡生蛋”死循环： 在该环境下，自动修复机制在理论上无法成功。 4. 解决方式：手动上传 geo 文件 在可访问 GitHub 的环境中下载： 上传并放置到 v2ray 默认资产目录： 重启服务（关键）： 此时： 问题一解决。 三、问题二：软件源安装的 v2ray-core 版本过低 …
很多人问“算命靠谱吗”，背后通常不是想争论玄学，而是想解决一个更现实的问题：当你不确定、焦虑、或者面临重大选择时，算命提供的那种“确定感”，到底有多少含金量？下面这篇文章尝试用更接近“可验证、可复现、可解释”的方式，把算命这件事拆开讲清楚：它为什么会让人觉得准、它在哪些方面确实有用、它哪里一定不可靠，以及怎样把风险降到最低。 1. 先给结论：算命作为“预测未来”不靠谱，但作为“叙事与心理工具”确实有效 如果把“靠谱吗”定义为：能否稳定、可重复地预测个体未来事件（比如财运、疾病、事业节点、婚姻结果）——那么算命整体上不靠谱。 但如果把它定义为：能否在短时间内让人情绪稳定、把混乱的经历组织成一个能说得通的故事、给出行动暗示——那么它确实常常“有效”，而且这种有效是可以用心理学与沟通学解释的。 也就是说： 2. 为什么很多人觉得“很准”：不是神秘力量，而是认知机制 + 沟通技术 2.1 巴纳姆效应：模糊但广泛适用的描述 算命常用的话术具备一个特点：句子听起来很具体，但实际上覆盖面极广。例如： 这些话之所以“准”，是因为它们符合人类常见的心理结构：既有矛盾面（冷静/敏感），也有普遍面（吃过苦/担心钱）。你越想对号入座，就越容易找到证据。 2.2 选择性记忆：命中被记住，失败被淡化 一次算命里可能说了几十句，命中两三句就足以形成“这人真准”的印象。而那些不准的部分很容易被遗忘或被解释为“还没到时候”。 2.3 事后归因：发生之后才会觉得“原来他说的是这个” 很多“应验”并不是预测，而是事后解释： 这是一种自然的人类思维：我们倾向于把事件组织成因果链，而不是承认偶然。 2.4 冷读与热读：信息收集 + 概率判断 一些算命者会在聊天中无意识或有意识地获取信息（职业、家庭、年龄、城市、情感状态），然后给出高概率建议： 这不需要玄学，也不需要恶意，只需要经验和洞察。 3. 从“可验证性”看：算命难以通过严谨检验，这是核心问题 一个方法要称得上“可靠”，至少应满足一些基本条件： 3.1 可重复 同一个人，在同样信息输入下，不同算命师应得到相近结论；或者同一算命师在不同时间对同一问题应保持一致。现实中往往做不到。 3.2 可证伪 可靠的预测应该能明确到“错了就是错了”。但算命常用表述通常是不可证伪的： 不可证伪的系统，在逻辑上很难称为“靠谱”。 3.3 可对照 如果算命真的能显著高于随机猜测，那么在统计上应能显现优势。现实中，大多数“准”来自个案体验，而个案体验本身容易被心理机制放大。 4. 那它到底“有什么用”：把作用说清楚，反而更客观 客观地说，算命在以下方面确实可能对一些人“有用”： 4.1 提供叙事结构：把混乱生活讲成一个能理解的故事 人不只是需要事实，也需要意义。算命擅长把人生拆成阶段：起伏—转机—积累—结果。对处在不确定中的人，这种结构能明显降低焦虑。 4.2 提供外部视角：像一种“非专业咨询” 算命师往往会问问题、倾听、总结、给行动暗示。这在体验上接近“咨询”或“教练”，只不过它的理论基础不是科学，而是传统体系和话术。 4.3 …
在 OpenWrt 路由系统中，SSH 默认使用 Dropbear 作为服务端，并允许密码登录。在具备公网访问、端口转发或远程运维场景下，切换为仅密钥登录可以显著降低暴力破解与误入侵风险。 本文记录 OpenWrt 中将 SSH 登录方式由“密码 + 密钥”调整为“仅密钥”的完整过程，并附带常见注意事项。 一、OpenWrt 中 SSH 的配置位置 OpenWrt 提供两种主要配置方式： 底层服务均由 Dropbear 控制。 二、通过 LuCI Web 界面配置（直观方式） 配置路径 关键设置项 保存并应用即可生效。 三、通过命令行配置（可控性更高） 1️⃣ 准备 SSH 公钥（客户端） 在客户端生成或查看公钥，例如： 复制输出的整行内容。 2️⃣ 写入 OpenWrt 的 authorized_keys 登录 OpenWrt（此阶段仍保留密码登录）： 创建并编辑公钥文件： 示例内容： 设置正确权限（非常重要）： 3️⃣ 禁用 SSH 密码认证 …