Linux

Linux lo 回环接口与互联网第一条消息 “LO” 的关系

在学习 Linux 网络结构时，几乎每个人都会看到一个特殊的网络接口： lo 它通常对应地址： 127.0.0.1localhost 与此同时，在互联网历史中也存在一个非常著名的记录：1969 年互联网（ARPANET）发送的第一条消息是 “LO”。 由于两者在字母上完全相同，很多人会产生一个疑问： Linux 中的 lo 接口，是否与互联网历史上的 “LO” 有关联？ 结论是： 两者没有任何历史或技术上的关系，仅仅是字母上的巧合。 本文对这两个概念进行简单说明。 一、Linux 中的 lo 接口 在 Linux 网络系统中： lo = loopback interface 即 回环网络接口。 回环接口的作用，是让一台计算机能够在 不经过任何物理网络设备 的情况下，与自身进行网络通信。 常见地址： 127.0.0.1 或主机名： localhost 可以使用以下命令测试： ping 127.0.0.1 数据包不会离开计算机，而是在 操作系统内核的网络协议栈内部循环处理。 回环接口的特点 lo 接口具有几个重要特点： 1 永远存在 无论系统是否连接网络，lo …

Linux

Ubuntu 24.04（ARM / R2S）APT 换源实录：从 ports.ubuntu.com 切换到国内 ubuntu-ports，并关闭 proposed

适用对象：ARM64 设备（如 R2S / 树莓派等）上运行 Ubuntu 24.04（noble），APT 默认指向 ports.ubuntu.com，更新速度慢或链路不稳定。目标：保持“官方仓库内容等价”的前提下，切换到国内镜像加速，并移除不适合生产环境的 -proposed 测试仓库。 1. 背景现象：APT 命中 ports.ubuntu.com 在 ARM64 Ubuntu 上执行 apt update，常见输出类似： 其中 ports.ubuntu.com 是 Ubuntu 官方用于 非 x86 架构（ARM 等） 的主仓库入口。它是“源站”，内容权威，但在亚洲链路上经常出现吞吐偏低的问题。 2. 关键点：ARM 的“国内镜像”必须是 ubuntu-ports 镜像 很多人换源失败，是因为误用只同步 x86 的镜像路径（如普通 ubuntu/），而 ARM 设备应使用 ubuntu-ports。 镜像等价关系如下： 3. 配置现状确认：使用传统 sources.list（而非 ubuntu.sources） Ubuntu 24.04 …

Linux

Linux（R2S/ARM小主机）流量统计与实时监控：vnStat + bmon/nload/iftop 全流程与排障记录

目标：在一台 ARM 小主机（双网口场景常见，如 R2S 一类）上，完成1）长期累计流量统计（按天/月/年）2）终端实时图形化监控（看瞬时带宽、看谁在跑流量）并解决“vnstat 显示 No data/查不到数据”的典型问题。 1. 为什么需要两类工具：累计统计 vs 实时观察 网络监控分两类，作用不同： 1.1 长期累计（趋势、账单、限额） 选型：vnStat优点：轻量、低开销、重启不丢（数据库在本机保存）。 1.2 实时观察（当前状态、排障、抓异常） 选型：bmon / nload / iftop其中： 2. 基础概念：RX / TX 是什么 所有工具里都绕不开： 在转发型节点（隧道/代理）里，经常出现一个明显特征： RX ≈ TX（接收多少就转发多少） 而在普通客户端（浏览网页、下载）上更常见： RX >>> TX 3. 长期累计：vnStat 的正确用法与常见误解 3.1 vnStat 的工作机制（决定了“能不能看历史”） vnStat 不会回溯系统历史流量。它的机制是： 因此： 这也是很多人第一次用 vnStat 时最容易误解的点：看到 “since …

Linux

NanoPi R2S 远程节点 SD 卡灾备方案设计与实践（可启动热备 + 异地配置备份）

摘要 本文记录一次远程边缘节点的灾备体系设计过程。 目标环境为长期运行的 ARM 小型网络节点，其物理设备位于异地，日常仅通过 SSH 远程维护。系统运行在 SD 卡上，一旦存储介质损坏，将导致节点完全离线，因此需要构建一种： 的 SD 卡灾备方案。 本文最终采用： 首次整盘克隆（dd） + 后续文件级同步（rsync） + 异地配置备份 的分层灾备结构。 一、问题背景 边缘节点通常具有以下特点： 一旦 SD 卡损坏，将出现： 因此核心问题变为： 是否可以提前制作一张备用 SD 卡，使其在原卡损坏后直接替换启动？ 二、系统结构特点（R2S 与树莓派的差异） 许多 Raspberry Pi 迁移方案基于如下结构： 系统仅依赖单一 root 分区，因此可以通过 rsync 复制后修改 UUID 启动。 但 NanoPi R2S 采用 Rockchip 启动结构： 关键差异： 因此： 仅复制文件 …

Linux

Arch Linux 系统升级失败：PGP Signature Marginal Trust 问题完整排查记录

一、问题背景 在一次常规的 Arch Linux 系统升级过程中，执行： 升级流程在 checking package integrity 阶段全部通过，但随后出现大量错误： 最终导致： 系统无法完成升级。 值得注意的是： 表面看似软件包损坏，实际上问题完全不同。 二、错误本质 核心关键词： 这并不表示软件包损坏，而是： Pacman 无法确认签名者在本机 PGP 信任链中具备足够信任等级。 Arch Linux 的软件包安全机制依赖： 升级流程为： 当本机 keyring 状态异常时，即使： ✅ 包真实✅ 签名正确✅ 来源官方 Pacman 仍会拒绝安装。 因此出现： 实际上是 信任验证失败。 三、常见触发原因 实践中主要有以下几类原因： 1️⃣ archlinux-keyring 过旧（最常见） 长期未升级系统时： 导致签名无法建立信任路径。 2️⃣ 本地 pacman-key 数据损坏 可能来源： 3️⃣ …

Selfhost

Nextcloud 在系统快照前提下跳过备份升级实践记录

一、背景 在自建 Nextcloud 环境中，官方 Updater 在执行升级时默认会创建程序文件备份。然而，在具备虚拟化平台或文件系统级快照能力的服务器环境中，这一步往往是冗余的。 典型场景包括： 当系统级快照已经覆盖 操作系统、数据库与数据目录整体状态 时，Nextcloud 自带备份的意义会明显降低。 因此，可以采用 跳过 Updater 内部备份 的升级方式。 二、Nextcloud Updater 的备份机制 Nextcloud CLI Updater： 默认流程中包含程序目录备份步骤，其备份内容主要为： 该备份并不包含： 因此，它并不是完整的回滚方案。 三、系统快照与应用备份的区别 项目 Nextcloud Backup 系统快照 程序文件 ✅ ✅ 数据目录 ❌ ✅ 数据库一致性 ❌ ✅ 系统整体状态 ❌ ✅ 回滚速度 较慢 秒级 原子恢复 ❌ ✅ 在具备系统级快照能力时： 应用层备份不再是主要安全保障。 …

Network

Linux 命令行查看 SSL 证书有效期的方法

在服务器运维过程中，经常需要确认 SSL 证书是否即将过期。尤其是在使用 Let’s Encrypt 自动签发证书的环境中，如果未及时发现证书失效，可能导致 HTTPS 服务中断。 本文记录一种 完全基于命令行 的证书有效期检查方法，适用于任何 Linux 系统。 一、证书文件结构 典型的证书目录如下： 说明： 查看证书有效期时，仅需要 fullchain.pem。 二、查看证书生效时间与过期时间 使用 openssl： 示例输出： 字段含义： 字段 含义 notBefore 证书开始生效时间 notAfter 证书过期时间 其中 notAfter 是最需要关注的字段。 三、仅查看证书过期时间（常用） 如果只关心证书何时失效： 输出示例： 适合脚本检测或快速人工确认。 四、查看完整证书信息 当需要排查 HTTPS 或 TLS 问题时，可以查看完整证书内容： 可获得： 该方式常用于反向代理或 TLS 握手问题分析。 五、计算证书剩余有效天数 服务器自动化运维中，通常需要判断证书还剩多少天过期。 可使用： 示例输出： …

Linux

跨地域服务器间 V2Ray 文件迁移实践：SCP 与 Rsync 的行为分析与优化记录

一、背景 在一次跨地域服务器迁移过程中，需要将既有系统中的 V2Ray 运行文件迁移至一台新设备。迁移对象主要包括以下内容： 日志文件不参与迁移，因为目标系统会自动重新生成。 迁移环境具有如下特征： 因此，本次迁移的核心问题并非“如何复制文件”，而是： 如何在跨境高延迟网络下稳定、高效、可恢复地完成文件同步。 二、初始方案：SFTP / SCP 拉取 最初采用的方式为： 该模式存在两个问题： 数据路径实际变为： 这种结构会导致： 实际测速仅达到几十 KB/s。 三、方向调整：改为 Push 模式 随后调整为： 即： 跨地域网络中，一个经验规律是： 让网络质量更好的节点主动发送数据。 方向切换后，传输速率立即提升。 四、引入 Rsync 相比 SCP，Rsync 具备以下关键优势： 1. 差异同步（Delta Transfer） Rsync 不会无条件复制文件，而是： 即使文件体积较大，只要修改较少，传输量也会显著降低。 2. 断点续传能力 跨境链路中断十分常见。 默认 SCP： 而 Rsync 可通过参数实现安全续传。 五、最终使用命令 迁移采用如下形式： 参数说明： 参数 作用 …

Linux

Linux 环境下 FRP 客户端（frpc）长期稳定运行的 systemd 配置实践

一、问题背景 在基于 FRP 的远程连接或内网穿透架构中，客户端通常以 systemd 服务方式长期运行，以确保设备重启后能够自动恢复连接。 在实际部署过程中，经常出现以下现象： 这些问题多数并非 FRP 本身造成，而是 systemd 启动顺序与网络就绪状态之间的不匹配。 二、常见错误配置 部分配置中会出现类似写法： 该参数来源于容器编排系统，并 不属于 systemd 支持的语法。 结果是： 因此必须使用 systemd 原生参数。 三、核心稳定原则 长期运行类网络服务需要满足三个条件： systemd 中对应的关键机制为： 它表示： 四、推荐的标准 systemd 服务模板（脱敏） 以下为经过泛化处理后的通用配置示例： 说明： 项目 含义 Description 服务描述（任意名称） WorkingDirectory 程序工作目录 ExecStart 客户端启动命令 Restart=always 退出后自动重启 RestartSec 重启等待时间 network-online.target 等待网络就绪 五、为什么必须等待 network-online 典型系统启动流程如下： 此时服务会直接退出。 …

Linux

FRP 不同 CPU 架构版本选择指南（ARM / x86 对照总结）

一、问题背景 在部署 FRP（Fast Reverse Proxy） 时，官方 Release 页面通常提供大量二进制版本，例如： linux_amd64linux_armlinux_arm64linux_arm_hflinux_mipslinux_riscv64windows_amd64darwin_arm64… 对于使用单板计算机、软路由或服务器设备的环境，选择错误架构是最常见的启动失败原因之一。 本文对常见 Linux 设备架构与 FRP 版本进行统一对照总结。 二、Linux CPU 架构判定方法 在目标设备执行： uname -m 或： getconf LONG_BIT 即可确定系统架构。 三、FRP 架构对应关系（核心对照表） uname -m 输出 CPU 架构 系统类型 应下载 FRP x86_64 AMD64 / x86_64 PC / 服务器 / VPS linux_amd64 aarch64 ARM64 ✅ ARM 64 …