Arch

Arch Linux 上苹果硬件风扇控制与温度监控记录：从高温降频风险到 mbpfan 接管

摘要 一台运行 Arch Linux 的苹果硬件设备，在重任务后出现 CPU 温度接近高温上限的情况。排查发现，系统中已经加载 applesmc，并且存在 fan1_input、fan1_min、fan1_max 等 Apple SMC 风扇接口。这说明该设备的风扇控制并不适合优先使用通用 fancontrol，而更适合使用面向苹果硬件的 mbpfan。 最终处理方案是： 实施后，风扇不再长期停留在最低转速附近，而是可以随温度上升自动提高转速，温度控制状态明显改善。 一、问题背景 设备在重任务后曾出现 CPU 温度接近高温上限的情况。虽然温度随后下降，但该现象说明系统默认风扇策略可能偏保守，在 Linux 下没有及时把风扇转速拉高。 初始观察到的状态大致如下： 这种情况的风险在于： 因此，本次目标不是追求极限性能，而是让风扇更早介入，避免 CPU 在重任务下反复冲到高温边缘。 二、确认风扇控制接口 首先确认系统是否加载了苹果硬件相关模块： 如果输出中存在： 说明系统已经具备读取 Apple SMC 与 CPU 温度的基础条件。 然后确认风扇接口： 如果可以看到类似文件： 说明风扇是通过 Apple SMC 暴露出来的。 典型读数可能类似： 这些数值应以本机实际读取结果为准。 三、为什么选择 mbpfan 而不是 fancontrol fancontrol …

Desktop

Arch Linux KDE Plasma 高 DPI 缩放排查：从 SDDM 登录界面文字过小到全局缩放统一

背景 某台 Arch Linux 桌面系统使用 KDE Plasma 6，显示会话为 X11，登录管理器为 SDDM，桌面缩放设置为 150%。系统使用 Breeze 主题，光标、图标、颜色主题也都保持 Breeze 系列，以保证视觉风格一致。 问题出现在开机后的 SDDM 登录界面：登录前的界面没有按照预期进行缩放，文字显得很小，但鼠标指针又显得偏大。进入 KDE 桌面之后，应用界面和字体整体看起来正常，但经过进一步观察发现，桌面里的鼠标指针反而偏小。也就是说，问题并不是单纯的“SDDM 没有缩放”，而是登录界面、桌面会话、光标大小、字体 DPI 之间没有完全统一。 本次排查的目标是： 一、现象描述 系统设置中，KDE Plasma 桌面缩放比例为 150%。进入桌面后，大部分 Qt/KDE 应用显示正常。 但是开机后的 SDDM 登录界面出现以下现象： 最初容易误判为 SDDM 完全没有继承 KDE 的 150% 缩放。但后续检查发现，问题更细：SDDM 的底层 X11 DPI 已经是 144，也就是 150%，只是 SDDM greeter 没有完整吃到 …

Email

两台内部服务器 Postfix 发信配置整理记录：在不破坏中继功能的前提下统一身份与地址改写

背景 某内部环境中有两台 Debian 系服务器，分别承担虚拟化管理与备份服务。两台机器都不是实际的公网邮件服务器，也不直接对外投递邮件，而是作为本机系统邮件的提交端使用 Postfix。 整体结构如下： 其中： 代表真正负责对外收发和中继的邮件服务器。 两台内部主机上的 Postfix 只负责把本机系统邮件、告警邮件、root 邮件等提交给该邮件服务器。两台机器各自对应一个真实存在的邮件账户： 这两个账户在邮件系统中是独立账户，均可正常收发邮件。 原始状态 两台机器的对外发信功能已经长期正常运行，说明核心 SMTP 中继链路本身没有问题。 关键配置大致如下： 这些项目是邮件能否成功提交到外部邮件服务器的核心配置，因此整理过程中没有改动。 真正需要检查的是一些非核心但影响一致性和邮件头表现的项目： 发现的问题 检查后发现两台机器的核心中继配置一致，但 Postfix 自身身份和地址改写规则并不完全一致。 主要差异包括： 同时，系统层面的主机名解析也进行了确认： 整理后，两台机器的系统层面主机名保持简单结构： 这里的 host-a.lan、host-b.lan 只作为内部局域网身份使用，不等同于公网管理入口，也不等同于实际邮件服务器。 generic 是什么 generic 指的是 Postfix 的出站地址改写表，对应配置项是： 它不负责连接 SMTP 服务器，不负责 TLS，不负责 SASL 登录，也不负责端口配置。 它的作用是：在邮件交给外部邮件服务器之前，把本机生成的发件人地址改写成真实存在的邮箱账户。 例如： 在主机 A 上统一改写为： 在主机 B 上统一改写为： …

Arch

一次 KDE 用户级服务过早启动问题排查：OpenClaw、systemd 与 KWallet 的启动顺序

背景 在 Arch Linux + KDE Plasma 桌面环境中，OpenClaw Gateway 作为用户级 systemd 服务运行。为了避免在配置文件中保存明文密钥，Gateway 的认证信息通过 KDE Wallet 读取。这个设计本身是合理的：密钥交给桌面会话的钱包管理，服务启动时再通过本地 secret provider 取出。 问题出现在一次系统或应用更新之后。原本已经调整过的用户级 systemd 启动关系，被重新生成了一个 default.target.wants 下的链接，导致 OpenClaw Gateway 再次过早启动。由于启动时间早于 KDE 图形会话完全就绪，也早于 KWallet 通过 PAM 完成解锁，Gateway 无法读取钱包中的 secret，最终启动失败。 这个问题表面上像是 KWallet 崩溃、Qt 插件缺失，甚至 KDE 环境异常；但实际根因是：用户级 systemd 服务被错误地挂回了 default.target，启动顺序早于图形会话和钱包解锁。 现象 系统启动后，OpenClaw Gateway 没有稳定进入可用状态。日志中可以看到类似信息： 同时，KWallet 相关日志中还可能出现： …

AI

将 Nextcloud Talk 接入 OpenClaw：一次自托管 AI 控制室的部署记录

OpenClaw 除了可以通过终端、Web UI、LINE、Telegram 等入口使用，也可以接入 Nextcloud Talk。相比依赖外部聊天平台，Nextcloud Talk 更适合成为自托管环境中的私人 AI 控制室：聊天入口、项目文件、任务协作和服务器工作流可以统一放在自己的 Nextcloud 体系中。 这次部署的目标，是在已经运行的 OpenClaw Gateway 基础上，新增一个 Nextcloud Talk 房间，让 Talk 中的机器人能够接收消息、转发给 OpenClaw，并把 OpenClaw 的回复写回 Talk 房间。 整个链路大致如下： 看起来只是“添加一个聊天入口”，实际排查中涉及 Nextcloud、Talk Bot、OpenClaw 通道、反代、防火墙、房间权限和回写 API 等多个环节。 一、Nextcloud Talk Bot 与普通 Webhook 应用不是一回事 Nextcloud 中有一些通用 webhook 相关应用，用于在文件上传、修改、删除等事件发生时通知外部系统。但 OpenClaw 接入 Nextcloud Talk 并不依赖这类通用 webhook 应用。 …

AI

OpenClaw 远程聊天入口迁移记录：从 LINE 配额限制到 Telegram 通道

在本地运行 AI 代理时，远程聊天入口是一个非常实用的功能。平时可以通过本机终端或网页后台操作，外出时则可以通过手机聊天软件临时发送指令，让 AI 代理执行查询、检查服务状态、处理项目任务，甚至进行一定程度的自动化操作。 不过，聊天软件本身并不是完全透明的通道。不同平台对机器人消息、官方账号、Webhook、API 调用方式都有不同限制。一次 OpenClaw 更新后的排查，正好暴露了 LINE 通道和 Telegram 通道之间的差异。 一、现象：后台能看到回复，但手机 LINE 收不到 OpenClaw 更新后，LINE 聊天通道出现了一个看起来比较奇怪的现象： 用户从 LINE 发送消息后，OpenClaw 能收到消息；网页管理后台也能看到 OpenClaw 生成了回复；但是手机 LINE 端却看不到回复内容。 从表面上看，这很容易让人怀疑是 OpenClaw 更新导致 LINE 插件异常，或者 Gateway、Webhook、认证密钥、KWallet、systemd 服务出了问题。尤其是在更新软件之后出现问题，人会自然地把故障和更新动作联系起来。 但进一步排查后，情况并不是这样。 OpenClaw 的通道状态显示，LINE 通道仍然处于 enabled、configured、running、works 等状态，说明通道本身并没有完全离线。问题集中在外发投递队列中：最近几条外发消息卡在 delivery queue，状态为 pending 或 failed，错误类似 partial delivery failure。也就是说，OpenClaw 内部已经完成了消息处理，但真正发送到 LINE …

AI

OpenClaw 接入 Nextcloud Talk 与 Telegram 的通信机制对比

在给 OpenClaw 配置外部聊天通道时，一个很关键的问题是：消息到底是由 OpenClaw 主动拉取，还是由外部平台反向推送到 OpenClaw Gateway。这个区别会直接影响部署方式、网络要求、安全边界和维护复杂度。 本文以 Nextcloud Talk 与 Telegram 为例，整理两种典型通信模式的差异。 1. OpenClaw 是否支持 Nextcloud Talk OpenClaw 支持 Nextcloud Talk 通道。它属于官方集成的聊天通道之一，工作方式是通过 Nextcloud Talk bot 与 OpenClaw Gateway 之间的 webhook 通信完成消息收发。 也就是说，Nextcloud Talk 端收到用户消息后，会把消息通过 webhook 请求发送到 OpenClaw Gateway；OpenClaw 处理完成后，再把回复返回到对应的 Talk 会话中。 因此，Nextcloud Talk 的关键不只是“OpenClaw 能不能访问 Nextcloud”，还包括“Nextcloud 服务器能不能反向访问 OpenClaw Gateway …

AI

从 Codex 到 DeepSeek：AI 代理后端模型选择与本地自动化实验思路

一、AI 代理的重点已经不只是“聊天” 普通大语言模型更多是在对话框中回答问题，而 AI 代理的使用方式明显不同。代理不仅要理解自然语言，还要调用工具、读取文件、执行命令、操作浏览器、控制桌面环境，甚至连接本地服务或外部软件。 在这种场景下，后端模型的角色已经从“聊天模型”变成了“行动系统的大脑”。它需要完成的不只是解释问题，而是持续推进任务： 因此，选择 AI 代理后端模型时，不能只看聊天效果，也不能只看价格。真正重要的是：模型是否适合作为代理的大脑，是否能够稳定地与工具、终端、脚本、接口和真实系统配合。 二、Codex 的价值：强的不只是模型，而是一整套代理体验 Codex 类模型之所以适合 AI 代理，并不是因为它只会写代码，而是因为它比较适合真实操作环境。 在实际使用中，AI 代理经常会遇到这些情况： 普通聊天模型在这种场景中容易出现两个问题：一是给出看似合理、实际不可执行的建议；二是任务一长就丢失上下文，开始偏离目标。 Codex 类模型的优势在于，它更擅长在“边执行、边观察、边修正”的过程中工作。它不只是回答“应该怎么做”，而是更接近于真正帮助完成任务。 这也是为什么在 OpenClaw 这类代理工具中，Codex 往往能给人一种“真的能干活”的感觉。 三、为什么需要寻找 Codex 的替代或补充模型 虽然 Codex 类模型很好用，但 AI 代理的 Token 消耗非常大。 普通聊天中，一次问答可能只消耗少量上下文；但代理任务不同。代理需要不断读取环境信息、工具结果、命令输出、文件内容和错误日志。每一次观察、计划、执行和修正都会消耗 Token。 尤其是下面这些任务，消耗会非常明显： 因此，如果完全依赖高价或有限额度的模型，长期使用成本会比较高。这就引出了一个现实问题： 是否存在更便宜、可以接入 OpenClaw、又能在一定程度上接近 Codex 的模型？ 围绕这个问题，可以重点关注 DeepSeek、Qwen、GLM、MiniMax、Kimi 等模型或平台。 四、便宜模型和 Codex 级模型不是一回事 在选择模型时，需要先区分两个概念： 这两个概念不能混在一起。 …

AI

OpenClaw 升级后无法打开可见浏览器的排查与修复

问题现象 在一台 Arch Linux + KDE 桌面环境中，OpenClaw 升级后出现了一个问题：终端中的 OpenClaw TUI 可以正常连接 Gateway，Agent 状态也显示为 connected / idle，但执行“打开浏览器”之类的任务时失败。 报错大意如下： 这说明 OpenClaw Gateway 本身并没有崩溃，WebSocket 连接、Agent 会话和后端服务都还在运行。问题集中在一个地方：Gateway 进程无法访问当前 KDE 图形会话，因此不能启动可见浏览器窗口。 初步判断 Linux 桌面环境中，GUI 程序通常依赖一些图形会话环境变量，例如： 在 KDE 终端里执行检查时，当前 shell 环境是正常的： 可以看到类似结果： 但是进一步检查 OpenClaw Gateway 进程环境： 结果只包含： 缺少关键的： 这就确认了问题：OpenClaw Gateway 作为 systemd user service 启动时，没有继承 KDE …

AI

OpenClaw 配置文件明文密码迁移记录

背景 在一次 OpenClaw 日常检查中，执行了如下命令： 检查结果显示 OpenClaw 本体运行正常，Skills 与 Plugins 均无明显异常： Memory search 处于明确关闭状态： 这不是故障，而是配置选择。 真正需要关注的是 Security 部分的两个提醒： 其中第二项表示 Gateway 监听 0.0.0.0，允许局域网访问。对于需要从局域网其他设备访问 OpenClaw 的场景，这属于有意配置，不是错误。 第一项则更值得处理：gateway.auth.password 以明文形式保存在 openclaw.json 中。虽然这不代表密码已经泄露，但如果本地 agent、插件或 workspace 工具可以读取配置文件，就有机会看到该明文密码。因此，本次处理重点是将该字段迁移到 SecretRef，也就是改为从环境变量读取。 当前状态判断 初始检查结果说明： 因此，本次处理目标不是“修复坏掉的服务”，而是“收紧安全配置”。 修改前备份配置文件 在修改配置文件前，应先备份当前配置： 备份完成后，再进行 SecretRef 迁移操作。 配置 Secret Provider 执行： 进入交互式配置后，首先添加 Secret Provider。 界面提示： 选择： Provider source …