欢迎来到我的博客！
本文对比 Tabby 与 Termius 在 SSH 使用场景下的设计理念、安全模型与长期可维护性。文章不涉及具体个人环境细节，聚焦工具本身的结构性差异。 一、问题背景 在多主机运维、个人服务器或实验环境中，SSH 客户端往往会逐渐从“工具”演变为“基础设施的一部分”。 这时，一个关键问题会浮现： SSH 客户端应当只是 OpenSSH 的外壳，还是一个自成体系的连接管理平台？ Tabby 与 Termius，正好代表了这两种截然不同的路线。 二、核心设计理念对比 Tabby：OpenSSH 的 UI 外壳 Tabby 的核心定位非常克制： 换句话说： Tabby 不试图“接管 SSH”，而是选择“服从 SSH”。 Termius：自包含的 SSH 平台 Termius 的设计目标明显不同： 在 Termius 中： SSH 不再是系统能力，而是应用能力。 三、安全模型差异 Tabby 的安全边界 Tabby 的安全边界在操作系统层： Tabby 本身： 这意味着： Tabby 的安全性 …
背景 在现代 Linux 系统中，SSH 公钥认证已成为远程登录与自动化运维的基础设施之一。随着密码学实践的演进，Ed25519 已成为 OpenSSH 官方推荐的默认算法。本文记录在 Linux 环境下生成 Ed25519 SSH key 的最小且安全做法，并澄清若干常见误解，重点面向： 全文仅涉及事实与机制，不包含个人偏好或架构建议。 一、推荐的算法选择 当前时间节点（2025–2026 年前后），在 OpenSSH 环境中： 因此，以下示例均以 Ed25519 为前提。 二、生成 Ed25519 SSH Key 的标准命令 在 Linux 命令行下，生成一把偏安全取向的 Ed25519 key： 参数说明 执行后将生成： 三、关于 passphrase 生成过程中会提示输入 passphrase： 是否设置 passphrase 不影响 key 的数学有效性，但会影响私钥泄露后的风险等级。 四、公钥最后的“名字”是什么？ 典型的 Ed25519 公钥内容如下： 其结构为： 其中： …
目标：在 Android 平台上选择一个 长期可用、离线、可控 的 SSH 登录方案，避免云绑定、避免停更风险，并与桌面端使用习惯保持一致。 一、问题背景 在 Android 上寻找 SSH 客户端时，常见诉求包括： 部分流行客户端在实际使用中暴露出以下问题： 因此需要重新评估 Android 上 SSH 客户端的长期可行性。 二、评估维度 本文主要从以下维度进行筛选： 其中，前 3 条为硬条件。 三、常见方案分析 1. 商业型一体化客户端 特点： 问题： 结论： 不适合作为长期、可控的基础设施工具。 2. 已停止维护的 Android SSH 客户端 特点： 问题： 结论： 停更即不可用，应直接排除。 3. 终端型方案（如完整 Linux 用户态环境） 特点： 问题： 结论： 适合重度用户或统一桌面/移动端工作流，但不符合“轻量点击登录”的需求。 四、最终选择：轻量、离线、长期可用的 SSH …
随着大模型能力的提升，将语言模型部署到本地服务器（self-hosted）已成为追求数据自治、隐私保护与长期可控性用户的一种现实选择。本文以 Qwen 7B 为例，记录了一种在中低配置服务器上，通过 Docker + Web UI + 公网反向代理 的方式，构建“类似 ChatGPT 的网页使用体验”的完整方案。全文不包含任何真实路径、端口或域名等敏感信息，仅保留通用架构与可复现的工程思路。 一、为什么选择本地部署 Qwen 7B 选择本地部署而非完全依赖云端模型，主要基于以下考虑： 需要明确的是，本地 7B 级模型并非用来“对标”云端超大模型，而是作为一个稳定、可控、随时可用的本地认知工具。 二、硬件与资源需求（现实可行范围） 本文方案基于一台低功耗小型服务器，而非专业 GPU 服务器。 推荐最低配置（CPU-only） 虚拟化场景下的资源分配 在虚拟化环境中（如 PVE / KVM）： 该资源条件下，可长期运行： 三、整体架构设计（不暴露 AI 节点） 核心设计原则 逻辑拓扑（文字描述） 四、容器化部署思路（Docker） 组件拆分 两者均通过 Docker 容器运行，数据通过 volume 持久化。 设计要点 五、公网访问的安全策略 反向代理职责 反向代理服务器承担所有“对外风险”： 必须具备的安全措施 通过该方式，即使域名被扫描，攻击面也仅限于反代层。 六、实际使用体验与定位 …
适用对象：使用常见集成型以太网控制器的 Proxmox VE 虚拟化宿主机 问题特征：宿主网络随机掉线、时间不固定；重启 networking 后宿主恢复，但虚拟机仍需 stop/start 才能恢复；虚拟机内部 reboot 无效 结论摘要：关闭网卡 offload + 关闭 EEE（Energy Efficient Ethernet），并进行 systemd 永久化，是当前该问题族成功率最高、代价最低、可复现性最强的解决方案之一。 1. 问题现象（行为级描述） 在长期运行的虚拟化环境中，宿主机会出现随机网络中断，具有如下共同特征： 这些现象往往容易被误判为虚拟机、应用或网络配置问题，但多次验证表明：真正进入异常状态的是宿主机网络路径本身。 2. 架构与关键前提 该问题通常出现在如下环境组合中： 与台式机或服务器上常见的独立 PCIe 网卡不同，集成型以太网控制器在电源管理（EEE / ASPM / C-state）与 CPU之间存在更强的耦合，这一差异是问题产生的重要边界条件。 3. 关键认知纠偏 3.1 虚拟机并非问题源头 当宿主网络路径进入异常中间态时，虚拟机只是最先感知失败的一层。 3.2 为什么重启 networking 只能救宿主 networking 服务的重启会： 但它不会销毁或重建已经存在的： 因此，虚拟机仍然绑定在失效的中间层网络对象上。 3.3 为什么必须 …
一、问题背景 在基于 PVE（Proxmox VE）的单节点虚拟化环境中，宿主机偶发网络异常，表现为： 该现象在家用硬件、非 HA、bridge 网络架构中具有一定普遍性。 二、初始假设与验证路径 1. 虚拟机网卡模型假设 最初怀疑为 VirtIO 在宿主机网络异常时放大问题，因此进行了如下验证： 2. 验证结果 结论： 问题不在虚拟机网卡模型层面 三、systemd + bridge + KVM 的一致性边界 在异常场景下，宿主机通常通过： 恢复网络。 该操作在 systemd + bridge 环境中会导致： 此时虚拟机网络栈处于： 逻辑上未崩溃，但状态不可预测 这是虚拟化架构本身的边界问题，而非配置错误。 四、关键工程结论 经过多轮实测，可得出以下结论： 最终结论： 当宿主机发生网络中断时，最可靠的策略是直接重启宿主机 因为宿主机重启可以同时完成： 五、设计目标的转变 设计目标从： “尽量让虚拟机自己恢复网络” 转变为： “一旦检测到宿主机网络中断，直接重启宿主机，保证整体收敛” 这是典型的工程止损决策，而非妥协。 六、最终方案：宿主机网络监控 + 自动重启 方案原则 七、宿主机网络重启 Watchdog …
摘要 在 Raspberry Pi 等长期运行设备中，SD 卡依然是最常见、也是最不可靠的存储介质之一。异常断电、磨损老化或 silent corruption 往往在系统仍可运行时悄然发生，一旦彻底失效，恢复成本极高。 本文记录了一套 与设备物理位置无关的 Raspberry Pi 灾备方案：通过公网 SSH，以 备份机主动拉取（pull） 的方式，对远端树莓派的根文件系统进行 持续增量备份，在不影响系统运行的前提下，确保随时具备完整恢复能力。 设计目标 总体设计思路 1. 连接模型：Pull 而非 Push 备份由 备份机主动发起： 该模型符合最小权限原则，也更适合嵌入式设备长期运行。 2. 标识方式：域名而非 IP 使用域名作为唯一入口： 只要 SSH 可达，系统即可被完整拉取。 3. 备份粒度：文件级增量镜像 放弃块级复制（dd），采用 rsync： 核心实现 rsync 参数选择 关键参数说明： 参数 作用 -a 保留权限、时间戳、符号链接 -A 保留 ACL -X …
背景 在使用 FRP（Fast Reverse Proxy）进行内网穿透时，FRPS（服务器端）的通信端口配置直接影响系统的稳定性、安全性以及后续的运维复杂度。 随着 FRP 新版本引入基于 QUIC 的传输方式，配置项中新增了 QUIC 相关监听参数，这使得服务器端可能同时存在多种控制通道实现方式，有必要对其协议属性与实际影响进行明确分析。 QUIC 监听端口的协议属性 结论明确： FRPS 中用于 QUIC 的监听端口基于 UDP 协议 原因在于： 协议层级关系如下： 因此： 传统控制端口与 QUIC 控制端口的差异 FRPS 提供两种功能等价的控制通道实现方式： 项目 传统控制通道 QUIC 控制通道 底层协议 TCP UDP 连接可靠性 由 TCP 提供 由 QUIC 协议实现 网络兼容性 高 依赖 UDP 质量 运维复杂度 较低 …
问题描述 在 Nextcloud 管理后台的 Security & setup warnings 中出现如下提示： The PHP module “imagick” in this instance has no SVG support. 具体表现为： 环境背景（概述） 初步判断 系统层 ImageMagick 验证 通过系统命令确认： 结论： 系统层 ImageMagick 支持 SVG PHP imagick 状态验证 查询 PHP imagick 模块信息，发现： 进一步使用 PHP 接口查询 SVG 支持情况，返回结果为空。 结论： PHP imagick 实际并不支持 SVG 关键分歧点：动态库不一致 …
背景 在长期运行的 Docker 服务器环境中，常见两类资产同时存在： 如果仅依据“容器是否在运行”来判断镜像是否可删除，极易误删冷备镜像，给后续恢复带来额外成本。因此，有必要建立一套以服务栈（stack）为核心的镜像与容器管理方法。 本文记录一次完整的排查与整理过程，目标不是“尽可能删除”，而是确保不误删任何未来仍需使用的镜像。 一、基础原则 在该环境中采用如下原则： 二、列出所有镜像（事实基线） 使用带 digest 的镜像列表作为“真实库存”： 该输出用于确认： 三、列出所有容器（不区分运行/停止） 容器列表是“镜像引用关系”的唯一事实来源： 在该环境中，当前不存在 exited 容器，所有服务均处于运行状态。但这并不改变后续判断逻辑。 四、用“栈（Compose Project）视角”理解容器结构 相比单个容器视角，“栈”更符合真实服务结构。通过 com.docker.compose.project 标签，可将容器按栈分组。 栈视图生成命令 五、当前运行中的服务栈清单（严格脱敏） 为避免暴露具体应用指纹，本节仅以抽象栈类别记录容器结构与数量，不出现任何可被直接识别的服务名称、镜像名或项目名。 该视图仅用于说明“以栈为单位进行管理”的方法论，而非展示具体部署细节。