Hardware

用命令行在 Linux 下启用并查看 USB 摄像头画面

在 Linux 桌面环境之外，直接用命令行控制和查看 USB 摄像头是一种非常高效、可控且可自动化的方式。无论是用于测试硬件、搭建服务器视频流、远程监控，还是排查驱动问题，V4L2 + FFmpeg 体系都是最稳定可靠的方案之一。 本文将完整介绍如何在 Linux 下，用命令行列出摄像头、识别正确设备，并以最佳参数输出画面。 一、Linux 摄像头的基本结构 Linux 中所有视频采集设备都通过 V4L2（Video4Linux2） 暴露为： 一个物理摄像头通常会暴露 两个或多个 video 节点： 如果选错节点，画面可能会黑屏、只有低分辨率，或者无法打开。 二、列出系统中所有摄像头 首先查看当前存在的 video 设备： 然后用 V4L2 查询设备归属： 示例输出结构如下： 同一组下面的两个 /dev/videoX 就属于同一个物理摄像头，其中 第一个通常是主视频流。 三、查看摄像头支持的格式和分辨率 确定主设备后（例如 /dev/video5），查询它的能力： 通常可以看到类似： 这里可以看出一个关键事实： MJPG 才是高分辨率高帧率的正确模式YUYV 在高分辨率下通常帧率极低 四、用 ffplay 直接显示画面 推荐使用 FFmpeg 自带的 ffplay： 2K（2560×1440 …

Backup

在 ext4 损坏后将 Raspberry Pi 系统从 64GB SD 卡无损迁移到 8GB SD 卡

摘要 在 Raspberry Pi 上运行 Ubuntu 或 Raspberry Pi OS 时，如果发生异常断电或 SD 卡老化，常会导致 ext4 文件系统元数据损坏，表现为启动进入 initramfs、fsck 报错、甚至出现异常输出（如大量负数刷屏）。当系统仍可启动时，最佳做法不是继续在原卡上修复，而是将当前系统整体迁移到一张健康的新存储介质。 本文记录了一次真实的灾难恢复流程：在原 64GB SD 卡发生 ext4 元数据错误后，将系统无重装迁移到一张 8GB 新 SD 卡，并保证系统可以从新卡稳定启动。 问题背景 系统在一次强制断电后启动失败，进入 initramfs，并提示： 执行 fsck 后虽然可以重新启动，但内核日志中出现： 这类错误并非单纯 journal 未回放，而是 ext4 从底层存储读到了不一致的数据，说明原 SD 卡已经出现 silent corruption（隐性数据损坏）。 此时继续在原卡上使用会导致未来随机文件损坏，因此必须迁移系统。 目标 环境 1. 对新 SD 卡重新分区 在 …

IoT

基于 VPS + MQTT 的广域网远程控制方案（ESP8266/ESP32 舵机按键器）

随着物联网设备的普及，越来越多的智能场景开始从本地局域网扩展到广域网。对于一些需要远程触发的物理设备，例如按键机器人、舵机驱动机构等，完全依赖商业云平台并非唯一选择。通过自建基础设施，可以获得更高的隐私性、稳定性与可控性。 本文提供一套完整的、可在任意 VPS 上部署的广域网远程控制方案，实现： 该方案适用于智能按键器、远程机械执行器、低成本自动化场景等。 方案整体架构 系统由三个核心部分组成： 远程控制流程如下： 整个过程安全、轻量且易扩展。 一、VPS 部署 MQTT Broker（Mosquitto） 以下示例基于 Debian / Ubuntu 服务器，可根据实际环境调整。 1. 安装 Mosquitto 2. 使用 TLS 证书 如果服务器已有 ACME/Certbot 证书，可直接复用： 3. 创建 MQTT 用户 4. 编写配置文件 文件：/etc/mosquitto/conf.d/iot.conf 5. 重启服务 6. 防火墙放行端口 二、客户端验证 MQTT 服务 订阅监控全部消息 发布测试消息 若能在订阅端收到消息，则服务器配置成功。 三、硬件接线（ESP + 舵机） 以 SG90 …

Ubuntu

Ubuntu Server（Raspberry Pi）配置与关闭无线网络自动连接指南

在使用 Ubuntu Server（特别是安装在 Raspberry Pi 等设备上的版本）时，很多人希望无线网络在开机后不要自动连接，以便在特定场景下进行手动控制。本文介绍了从启用 Wi-Fi 到关闭自动联网的完整流程，适用于 Ubuntu Server 20.04–24.04 版本。 一、确认无线网卡状态 系统中无线网卡的识别名称通常为 wlan0。可通过以下命令确认： 若输出类似： 说明无线网卡已被系统识别，只是未启用。此时可手动激活： 二、编辑 Netplan 配置文件 Ubuntu Server 采用 Netplan 管理网络，配置文件一般位于： 使用编辑器打开（以 vim 为例）： 默认内容通常如下： 这段配置仅启用了有线网络 eth0，需要手动添加 Wi-Fi 配置。 三、添加 Wi-Fi 并启用自动连接（可选） 若希望无线网络在开机时自动连接，可在文件中追加以下内容： 保存后应用： 此时系统会自动通过 DHCP 获取 IP 地址，若成功连接，可通过以下命令查看： 出现 inet 192.168.x.x/24 即表示连接成功。 四、关闭无线网络的自动连接 如果希望设备在启动时不自动连接 Wi-Fi，可以通过修改 …

Troubleshooting

Certbot 在阿里云环境中出现 “Server: Beaver / 403” 报错的排查与解决

适用范围：阿里云 ECS 主机已备案，域名解析正常，但 Certbot 在执行 HTTP-01 验证时仍返回 403 Forbidden。目标：在保持现有架构不变的前提下，成功签发一张同时覆盖多个子域名的 Let’s Encrypt 证书。说明：文中域名均为示例（如 example.com、sub1.example.com 等），与真实业务无关。 一、问题现象 执行命令： 输出提示： 人工测试： 结果： 二、原因分析 1. “Server: Beaver” 的含义 2. 与备案无直接关系 三、验证思路 四、解决方案（按稳定性排序） 方案 是否改动架构 是否依赖 80 端口 难度 特点 A. DNS-01 手动 TXT ❌ 否 ❌ 否 ★☆☆ 最安全稳妥，适用于所有环境 B. DNS-01 自动化（AliDNS API） ❌ …

Tunneling

使用 FRP 与反向代理实现安全内网穿透与真实访客 IP 识别

在自建服务器或家庭网络场景中，常需要让局域网服务能够被公网安全访问。FRP（Fast Reverse Proxy）是一款流行的内网穿透工具，可以帮助实现这一目标。当系统采用 HTTPS 与反向代理架构时，正确获取真实访客 IP 需要额外配置。本文介绍一种基于 FRP + Nginx + Proxy Protocol v2 的通用解决方案。 一、系统结构概览 整个体系由三部分组成： 逻辑关系如下： 这种架构可同时实现多服务转发、端口复用与 TLS 加密通信。 二、FRPS 配置（公网端） FRPS 作为核心入口，建议启用加密、认证和端口白名单。 要点说明： 三、FRPC 配置（内网端） FRPC 运行在内网，负责建立安全连接并转发本地主机服务。 配置说明： 四、Nginx 反向代理配置（内网） 反向代理用于终止 TLS 并将请求转发到后端应用。要让其识别 Proxy Protocol 头部，需要显式启用相关指令。 ⚠️ 注意启用 proxy_protocol 后，若直接在本机访问该端口（未通过 FRP），连接会因缺少协议头而失败。若需调试，可额外开放一个仅本地使用的不带 proxy_protocol 的监听端口。 五、验证与测试 六、安全建议 七、总结 通过 …

WordPress

WordPress 博客访客记录方案与实践

在个人独立博客的运维中，了解网站的访问情况是一项基础但常被忽视的工作。即使是访问量极低的私有博客，适度的访问日志也能在安全、防护、统计等层面提供有用信息。以下内容总结了在 WordPress 环境下记录访客访问数据的几种方案与实践经验，兼顾可控性、稳定性与系统负担。 一、明确访客记录的目标 在启用访客记录功能之前，应首先明确想要“记录”的范围。常见数据包括： 不同的目标对应不同的实现方式： 二、使用服务器日志（最基础方案） 无论使用 Nginx 还是 Apache，Web 服务器默认都会记录访问日志。在 Nginx 环境中，日志路径通常为： 每条日志记录包含 IP、时间、请求路径、状态码等信息。示例： 这种方式不依赖 WordPress，即使站点崩溃也能记录访问。结合 goaccess 或 awstats 等工具，可快速生成统计报表。 优点： 稳定、轻量、无插件、数据完整。缺点： 不在 WordPress 后台显示，需要登录服务器查看。 三、使用 WP Statistics 插件（推荐方案） 在 WordPress 体系内，WP Statistics 是最平衡的选择。它能记录访客 IP、来源、页面访问量等基本信息，并以图表形式展示。 基本设置建议 数据导出与备份 插件提供导出功能，可将访客数据以 CSV 形式保存，便于归档或分析。 若网站使用反向代理 若站点通过 Cloudflare 或其他代理访问，WP Statistics 可能显示代理 IP。可在 wp-config.php …

Troubleshooting

一次 TLS 证书过期导致的服务故障排查记录

概要 某云服务器上的加密代理服务，在运行稳定数月后，于某日突然出现所有客户端无法连接的情况。网站访问正常，但加密代理完全失效。本文记录了从初步检测到最终定位问题的全过程。 一、问题现象 在问题出现前，所有客户端均能正常连接。某日夜间起，连接全部失败，日志中出现大量类似以下信息： 此错误表明 TLS 握手阶段证书验证失败，但当时并不清楚是客户端、服务端、还是中间环节的问题。 二、初步判断：排除外部因素 首先确认网络层和基础设施： 故障范围仅限于代理服务端口，指向服务自身配置问题。 三、证书与握手检测 通过 openssl s_client 对两个服务端口进行 TLS 测试。 网站端口（正常服务）： 代理端口（故障服务）： 对比结果表明： 即同一主机上存在两份不同的证书链，代理服务仍在使用旧版。 四、定位原因 进一步检查配置文件，代理服务的 TLS 设置如下： 路径正确，指向 live 目录的符号链接；但查看系统日志后发现，该进程已连续运行超过一周，而新证书的签发时间正是数天前。 说明该进程在新证书生成后从未重启过。由于此类服务不会自动重新加载证书文件，进程一直在使用内存中的旧证书。直到旧证书过期后，客户端才全部无法建立 TLS 握手。 五、解决与验证 重启服务后，再次检测： 握手恢复正常，客户端均可重新连接。 为防止同类问题再次发生，添加了自动重载机制。 六、预防措施 1. 在 Certbot 续期后自动重启相关服务 在 /etc/letsencrypt/renewal-hooks/deploy/ 下创建脚本： 每次证书续期成功后将自动重启代理服务。 2. 或使用 systemd.path 监控证书文件变化 当证书文件更新时自动触发 systemctl …

Tunneling

使用 systemd 管理 FRP 多实例与定期自动重启（兼容 Certbot 证书更新）

前言 在自建网络穿透体系中，FRP（Fast Reverse Proxy） 是一款非常高效、稳定的工具。搭建了一个小型但完整的结构： 由于使用 Certbot 为 FRPS 生成 HTTPS / TLS 证书，这些证书会在 90 天内自动续期。为了让 FRPS 与 FRPC 在证书替换后自动加载新证书、避免手动重启，设计了一个每两个月执行一次的自动重启计划。这既保证证书长期有效，也保持隧道连接的稳定性。 一、架构概览 角色 实例 主机类型 功能说明 FRPC frpc1、frpc2、（frpc3 预留） 局域网穿透节点 为内网设备提供公网访问 FRPS frps-main、frps-backup 公网 VPS 接收客户端连接，终止 TLS 二、服务文件结构 FRPC（客户端） /etc/systemd/system/frpc1.service： 第二个实例仅需复制并修改文件名与配置路径： FRPS（服务端） /etc/systemd/system/frps.service： 三、自动重启机制的设计思路 Certbot 证书默认有效期 90 天，但 FRPS / FRPC …

Security

使用 RKHunter 保护 Ubuntu 系统：安装、配置与误报处理完整指南

在 Linux 系统中，Rootkit 是一种隐藏型恶意软件，它会潜伏在系统中，绕过普通检测手段，甚至获取 root 权限。为了确保系统安全，我们可以使用 RKHunter（Rootkit Hunter） 来扫描系统潜在威胁。本文将详细介绍 Ubuntu 系统上安装、配置 RKHunter，并解决常见误报的完整流程。 1️⃣ 安装 RKHunter 首先，使用 apt 安装 RKHunter 以及 curl（用于联网更新镜像）： 安装完成后，可以检查版本： RKHunter 默认包含大量检测规则，包括系统文件完整性、隐藏文件、网络端口异常等。 2️⃣ 配置 RKHunter RKHunter 的配置主要涉及 定期扫描 和 网络更新。我们先修改默认参数： 2.1 /etc/default/rkhunter 编辑此文件以启用每日 cron 任务，并设置报告邮箱： 修改内容： 保存并退出。 2.2 /etc/rkhunter.conf 主要配置项如下： 保存并退出。 3️⃣ 更新系统文件属性基线 第一次安装 RKHunter 后，需要建立系统文件属性基线： 输出示例： 这里记录了关键系统文件的当前状态（大小、权限、校验和），方便后续扫描发现异常变更。 …