Linux 系统中多蓝牙控制器的管理与默认控制器切换

在 Linux(基于 BlueZ 的系统)中,如果同时存在多个蓝牙控制器(例如主板内置蓝牙与 USB 蓝牙适配器),系统通常会根据内核枚举顺序自动指定默认控制器。这种自动分配并不总是符合用户期望,例如希望使用信号更稳定、性能更好的 USB 蓝牙适配器,而非内置蓝牙模块。 控制器的显示与默认情况 通过 bluetoothctl list 命令,可以查看当前系统检测到的蓝牙控制器。例如输出如下: Controller XX:XX:XX:XX:XX:XX Hostname #2 [default]Controller YY:YY:YY:YY:YY:YY Hostname 其中 [default] 表示系统当前使用的默认蓝牙控制器。如果有多个控制器,编号自动按检测顺序排列,内置控制器通常会优先编号并被设为默认。 修改 /etc/bluetooth/main.conf 在 /etc/bluetooth/main.conf 配置文件中,有如下可选参数: #ControllerMode = dual#DefaultAdapter = XX:XX:XX:XX:XX:XX 其中 DefaultAdapter 理论上用于指定默认控制器的 MAC 地址。然而,在大多数 Linux 桌面发行版中,这个参数实际上并不会生效。内核与 BlueZ 会根据硬件探测顺序优先指定第一个控制器,而忽略 DefaultAdapter 配置。 手动切换默认控制器 若希望使用指定的控制器,可以通过 bluetoothctl 工具手动切换: select XX:XX:XX:XX:XX:XX …

Linux 蓝牙多控制器切换与手写板自动断开调试笔记

在 Linux 系统上,如果同时存在内置蓝牙控制器和 USB 蓝牙控制器,蓝牙设备管理会变得复杂,尤其在涉及自动断开设备、切换控制器等需求时,常会遇到意想不到的情况。此文记录一次针对蓝牙手写板的调试过程,作为参考。 背景 需要使用脚本自动断开蓝牙设备(例如手写板),脚本中使用 bluetoothctl info 命令配合 expect 自动化交互流程。然而,在接入 USB 蓝牙控制器后,系统默认仍然使用内置控制器,导致脚本无法正常识别目标设备。 初步现象 执行 bluetoothctl info 时,输出的设备信息中,Device 行并不包含 (random) 或 (public) 标记。例如: Device AA:BB:CC:DD:EE:FF Generic Pen TabletName: Generic Pen TabletConnected: yes 脚本中原本使用的正则表达式如下: regexp {Device ([A-F0-9:]+) \(random\)} $output match mac 由于缺少括号标记,这条正则无法成功提取 MAC 地址。 修改正则 修订后的正则表达式改为不依赖括号标记,仅提取 MAC 地址: regexp {Device …

Linux 平台安装与配置 WeChat Universal(bwrap 沙盒版)指南

随着国内外越来越多用户在 Linux 平台使用微信,社区提供了多个解决方案,其中基于 Bubblewrap 沙盒的 wechat-universal-bwrap 版本受到广泛欢迎。该版本通过 UOS 微信(或腾讯官方微信)重新打包,同时借助 bwrap 隔离容器化运行,提升安全性与系统兼容性。 🌟 安装方式 在 Arch Linux 及衍生系统(如 Manjaro、EndeavourOS 等)上,可以通过 AUR 安装: yay -S wechat-universal-bwrap 编译过程中,会自动构建必要的共享库(如 libuosdevicea.so),并安装所有依赖项(包括字体、图标、Wine 环境等)。安装后,应用体积大约 700 MiB。 在编译日志中会看到 libuosdevicea.so 的编译、打包、清理等详细步骤,最终生成并安装到系统中。 🛡️ 沙盒机制(bwrap) 该版本默认使用 Bubblewrap(bwrap)进行容器化隔离,微信进程只会访问宿主机中显式绑定的文件和目录。默认情况下,仅暴露用户主目录下的特定数据目录,如 ~/Documents/WeChat_Data,其他宿主目录不会被暴露。 ⚙️ 配置自定义数据目录 默认数据目录为: ~/Documents/WeChat_Data 如需修改,可使用环境变量 WECHAT_DATA_DIR 来指定新目录。例如,想使用 ~/.local/share/WeChat_Data,可通过如下命令启动微信: env WECHAT_DATA_DIR=”$HOME/.local/share/WeChat_Data” wechat-universal 💻 修改桌面文件 …

Apple 设备无法访问主域名及路径问题排查与解决

近期遇到一种情况:主域名(例如 https://example.net/)及其附加路径(如 /path1/, /path2/ 等)在苹果手机(iOS Safari)上无法访问,但子域名(如 mail.example.net, chat.example.net)可以正常访问。此问题在非苹果浏览器(如 Windows Chrome 或 Android 浏览器)中不会出现,表现为白屏、无响应或直接连接失败。 经过详细排查,总结出原因及解决方案如下。 🟢 初步排查方向 🔥 根本原因分析 在配置文件中发现,主域名使用了以下配置: proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection “upgrade”; 这两行配置用于 WebSocket 或需要协议升级的后端(如即时通讯服务),但普通 Web 服务或静态资源并不需要。如果后端(如 Apache)返回了 Upgrade: h2,h2c header,Nginx 会将此 header 透传给前端浏览器。苹果 Safari 对该 header 十分敏感,如果出现多余或错误的 Upgrade header,会直接拒绝连接,导致无法访问。 ✅ 解决方案 1️⃣ 注释多余的 header 将主域名配置中的以下两行注释: # proxy_set_header …

WordPress 开启两步验证后,移动端登录提示「用户名或密码错误」的解决方案

在 WordPress 中启用两步验证(Two-Factor Authentication,2FA)可以显著提高后台安全性。但不少用户在开启后,会发现无法通过手机 app 或其他外部客户端(例如 XML-RPC 接口)登录,提示「用户名或密码错误」。 出现该情况的根本原因在于,移动端或 API 并不支持输入动态验证码,只能使用静态密码。这时需要通过「应用密码(Application Password)」功能进行登录授权。 常见现象 产生原因 开启两步验证后,网站登录流程需要两步: 而 WordPress 手机 app 或 XML-RPC 不支持验证码输入,因此仅凭原始密码无法完成验证。 解决思路:使用「应用密码」 多数支持两步验证的插件(如 Two Factor、WP 2FA、Wordfence 等)都提供了「应用密码」功能,专门用于第三方应用登录。 Two Factor 插件的操作流程 以下以 Two Factor 插件为例,介绍具体步骤。 1️⃣ 登录网站后台 通过浏览器正常登录 WordPress 后台。 2️⃣ 进入「个人资料」页面 后台菜单中选择「用户」 → 「所有用户」 → 需要设置的用户 → 「编辑」,或直接点击右上角用户名进入「个人资料」页面。 3️⃣ …

Web 应用文件夹权限配置建议(WordPress、数据库管理面板等)

在部署 WordPress、数据库管理面板(如 phpMyAdmin)或其他 Web 应用时,正确设置文件夹和文件权限,对安全性和正常运行都至关重要。以下整理了通用的权限配置思路与方法,供参考。 📁 管理面板类目录(如数据库管理工具) 推荐权限 设置思路 示例命令 chmod -R 750 /path/to/admin-panelchown -R www-data:www-data /path/to/admin-panelchmod 640 /path/to/admin-panel/config-file.php 这样可有效防止其他用户查看目录或配置文件,降低敏感信息泄露的风险。 📁 WordPress 等常见内容管理系统 官方推荐权限 设置思路 示例命令 find /path/to/cms/ -type d -exec chmod 755 {} \;find /path/to/cms/ -type f -exec chmod 644 {} \; 如果对安全要求更高,可只允许需要写入的目录(例如上传目录)设置为可写,其他目录和文件都只读。 ⚠️ 更高安全性做法 ✅ 总结 场景 目录权限 …

WordPress 博客迁移后无法正常访问的原因与解决方案

在对 WordPress 博客进行迁移或备份还原(例如更换服务器、切换域名或调整目录)后,常见一个问题:网站无法正常访问,或被错误重定向到旧域名。即便后台设置的「WordPress 地址(URL)」和「站点地址(URL)」看似正确,访问时仍然会出现异常。 常见问题表现 根本原因 WordPress 会在数据库中保存站点 URL 信息,主要在 wp_options 表中的 siteurl 和 home 字段。此外,部分主题或插件也会保存绝对路径(包含域名)配置,导致后台虽已修改 URL,前端依旧引用旧地址。 如果在迁移或还原时没有正确替换数据库中所有相关域名,或者存在序列化数据(序列化字符串中嵌入了旧地址),就会导致加载异常和重定向错误。 推荐的临时解决方法(立即生效) 在 WordPress 根目录的 wp-config.php 文件中,直接添加以下两行: define(‘WP_HOME’, ‘https://新域名/新目录’);define(‘WP_SITEURL’, ‘https://新域名/新目录’); 这样做的优势: 后续彻底修复(推荐) 在通过 wp-config.php 成功进入后台后,可使用数据库字符串替换工具(例如 Better Search Replace、WP-CLI search-replace 等),将所有旧域名字符串彻底替换为新域名。这一步能够解决数据库中所有遗留引用,包括序列化数据、插件配置、媒体链接等。 替换完成后,即可从 wp-config.php 中移除 define(‘WP_HOME’, …) 和 define(‘WP_SITEURL’, …),恢复后台管理自由设置 URL。此时,即便不在配置文件中预设域名,网站也可以正常访问和运行。 实际效果 通过先在 wp-config.php 添加定义,网站能立即恢复访问,快速排查和修复问题。再配合后续的数据库全局替换,可彻底解决根本问题,实现长期稳定运行。 …

VPS 上使用 Duplicator 迁移 WordPress 及 MariaDB 常见 Collation 问题解析

在一台 VPS 上完成了 WordPress 的迁移与重建,使用 Duplicator 插件导出完整安装包,结合 Apache、MariaDB 及 Certbot SSL 配置,整理了完整的安装步骤与遇到的常见错误及解决方案,供参考。 ✅ 基础环境准备 服务器环境基于 Ubuntu。需要安装以下软件包: sudo apt updatesudo apt upgrade -ysudo apt install apache2 mariadb-server php php-mysql libapache2-mod-php php-zip unzip -ysudo systemctl enable apache2 mariadbsudo systemctl start apache2 mariadb ✅ MariaDB 配置 MariaDB 默认使用 unix_socket 插件进行身份验证,如果需要使用密码进行外部连接,可通过以下 SQL 修改 root …

Linux LVM 根分区在线扩容实践记录

在生产或测试环境中,经常会遇到虚拟机磁盘空间不足,需要进行在线扩容。下面整理一次典型的 Linux 虚拟机磁盘扩容并扩展 LVM 根分区 的完整流程,供参考。 📌 场景简介 🧰 检查当前分区及 LVM 状态 使用以下命令查看磁盘、物理卷(PV)、卷组(VG)及逻辑卷(LV)情况: fdisk -lpvsvgslvsdf -h 结果显示 /dev/sda3 为 LVM 使用的主分区,原容量约 11.5G,扩容后磁盘有大量未使用空间。 🔧 调整 GPT 分区表 执行以下命令查看并修复 GPT 分区表(如有提示 GPT PMBR size mismatch 或 backup GPT table is not at the end of the device): parted /dev/sda printparted /dev/sda(parted) resizepart …

服务器 WordPress 出现旧域名跳转的排查与解决(Apache 配置篇)

在日常维护 WordPress 网站时,常见到一种情况:即使直接访问服务器的 内网 IP 地址,依然会被自动跳转到某个已废弃或更换的旧域名,并且即使清空浏览器缓存也无法解决。这种现象常被误认为是 Apache 配置问题,实际上通常与文件内容、数据库以及历史遗留设置相关。以下是一份完整的排查与解决记录。 💡 现象 🗂️ Apache 配置排查 首先确认 Apache 是否仍然引用了旧域名。 🔎 搜索所有 Apache 配置文件 grep -Ri “example-old-domain.com” /etc/apache2/ 如果只在已禁用的配置文件(如某些 SSL 配置)中出现,且执行了 a2dissite 禁用操作,理论上不会影响实际访问。 ✅ 确认虚拟主机状态 apachectl -S 查看输出的 VirtualHost 列表,确认没有多余的域名绑定,并且 DocumentRoot 正确指向当前 WordPress 文件目录。 🗂️ 浏览器与 DNS 缓存确认 除了浏览器缓存,还需要清理操作系统的 DNS 缓存: sudo dscacheutil -flushcache; …