Hello 👋

1. 背景 一开始部署了 Nextchat 作为我日常的 AI 问答网页应用，原因很简单： 该项目启动早，社区很活跃 网页应用结合 PWA 使用起来也很方便 支持模型供应商全面 但是使用了一段时间之后接触到了更为全面和强大的 lobe-chat，lobe-chat 发展迅速，社区更为活跃，社区版支持子部署，且没有功能限制，公司级的开源项目，产品 UI 设计很现代，社区 Roadmap 还计划支持更多的功能，如文生视频，助手自主学习等功能（无恰饭，纯使用感受）。 起初仅通过 docker-compose 部署了纯前端版本的 lobe-chat，这个版本由于是纯前端，没有多端同步的功能，同一份配置需要在家里电脑、公司电脑和手机上重复配置，相当麻烦，所以还是部署数据库版本的完全体 lobe-chat 更为合适。 2. 官方脚本部署 2.1 脚本部署 说干就干，目前版本是 v1.49.12，使用官方 docker-compose 部署脚本部署： bash <(curl -fsSL https://lobe.li/setup.sh) -l zh_CN 支持 3 种模式部署： 本地模式（默认）：仅能在本地访问，不支持局域网 / 公网访问，适用于初次体验； 端口模式：支持局域网 / 公网的 http 访问，适用于无域名或内部办公场景使用； 域名模式：支持局域网 / 公网在使用反向代理下的 http/https 访问，适用于个人或团队日常使用； 第一种模式纯自身访问，无法从其他设备访问，局限性很大；第二种模式在局域网中访问可行，但是 IP 端口访问的方式在局域网环境中我并不推崇，一是需要记忆特定的 IP 端口，而是 http 的方式无法安装 PWA 应用，仅适用于初次体验，而我自身用于家庭服务器，并且部署了一个自签名证书的 Nginx，完全可以试用该证书部署 https 的服务，而不用担心暴露公网，通过 VPN 即可在任何地方访问家庭服务也很方便，关于自签名证书和我的服务器拓扑 VPN 配置等信息我在 这篇文章 以及 这篇文章 中有详细介绍，这里不再赘述。...

1. 起因 我的 ttrss 容器一直部署在我的 HomeLab 服务器中，我的 HomeLab 配置在 这篇文章 的背景章节有提到，这里再列一下： 类别 项目 价格 CPU i5-10400 – 主板 华擎 B-460M 钢铁传奇 – 内存 酷兽 8G * 4 = 32G – SSD 三星 980 1TB – SSD 爱国者 128GB – HDD 希捷酷狼 4TB * 2 – 机箱 先马趣造 – 散热 九州风神 – 电源 先马 500W – 这套配置是 4 年前入手的全新硬件，入手之后一直当作 HomeLab 服务器 24 小时开机使用，但毕竟不是服务器级别的硬件，终于，我的主板还是在 8 月份倒下了，于是我立马着手更换硬件，但是 B460 的芯片组主板早就停产了，加上我的虚拟机系统是 Pve，所以我还是倾向于购买相同的硬件，这样配置都不用改了，于是我打开了拼多多。 1.1 PDD 买电子产品还是得小心 拼多多我也用的并不多，以往我的电子产品大多都是京东入手，但是这次京东并没有全新硬件，都是二手，想着也差不多就在拼多多购买了一块华擎的 B460Pro4，没办法，钢铁传奇这个主板估计是当时出货太少，导致二手货也没多少，只能入手相同品牌的 Pro4，好在收到主板后修改的配置也不是很多，拿到货修改 bois 配置后通过 pve 安装 u 盘进入恢复模式，将网卡配置改一改就好了，所有虚拟机和 CT 完美运行。可高兴了没几天这块主板就坏了，毫无疑问翻车了，主板寄回去修了之后还是老样子，商家卖了一块有暗病的主板给我，无奈只能继续维修。...

This message is used to verify that this feed (feedId:67828528348518400) belongs to me (userId:57584596535944192). Join me in enjoying the next generation information browser https://follow.is.

1. 背景 起因是我的 ttrss 容器需要订阅一个自部署的微信公众号订阅服务 wewe-rss ，在 web 页面添加订阅一个订阅源 http://192.168.5.128:8109/feeds/MP_WXS_3925660753.atom，添加之后 ttrss 报错 无法从指定的网址下载:cURL error 7: Failed to connect to 192.168.5.128 port 80 after 0 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://192.168.5.128/feeds/MP_WXS_3925660753.atom 但是仔细看报错日志，我的服务端口明明是 8109 但是 ttrss 却访问了 80，暂时不知是不是 ttrss 的 BUG，所以我便换了一个 nginx 代理的本地服务来反代 wewe-rss 的服务，由于我 nginx 配置了一个自签名的证书，客户端信任这个证书之后可以开启一些自部署服务只能 https 才能开启的功能，比如密码管理器 vaultwarden 。扯远了，回到正题，现在我已经配置好了反代的服务，新的订阅服务链接为：https://wewe.linkzz.hm/feeds/MP_WXS_3925660753.atom，但是直接在 ttrss 中配置还是会报错证书无法信任，所以这就来解决这个问题。 2. 信任证书 以下的操作是基于 Ubuntu 2204 版本，其他发行版没测试过。 2.1 确认证书类型 我是使用的 mkcert 生成的 CA 证书，证书包含 rootCA.crt 和 rootCA.pem 文件，crt 是二进制文件，只包含证书内容，在 windows 环境下可以直接安装，而 pem 是 base64 编码的文本文件，它包含了证书内容、证书链等信息，在 Ubuntu 中信任证书需要 pem 文件。...

1. 背景 我的 qBittorrent 下载器是部署在 Docker 容器中的，而这个 Docker 的宿主机是一个 pve 的容器，他有一个独立的 IP,这个 IP 的网关指向了一个透明网关以实现大陆网络优化（国内特色），关于我的网络拓扑可以查看我以前的这篇 文章 但是下载器的流量经过 clash 之后需要单独对 BT 流量命中规则，我用的是 clash-meta 的核心，支持逻辑规则，于是我是这样写的： # bt下载全直连 - AND,((SRC-IP-CIDR,192.168.5.128/32),(NOT,((DST-PORT,443)))),DIRECT 以上规则解释就是：来自 192.168.5.128IP 的目标端口非 443 的连接全直连，比较简单粗暴一刀切，但是这个规则还是会误杀一部分的流量，但至少可以避免大部分的 BT 流量了。 虽然问题是暂时解决了，但这个方案并不是最优，存在以下坑： 如果 Docker 的宿主机 IP 换了规则得更新 目标端口 80 的流量也应该继续下面的规则匹配 (当然这是因为懒没加到规则里面) 会误杀掉一部分的流量 2. 迁移 为了解决上面提到的问题，也为了把 qbittorrent 版本升级一下，我决定单独给他一个创建一个 lxd 容器，这样可以将网络直接指向上级网关，不必走透明网关。 2.1 创建容器 通过 pve 的内置 pct 命令创建容器： pct create 117 \ ugreen:vztmpl/archlinux-base_20230608-1_amd64.tar.zst \ --cores 6 \ --memory 512 \ --hostname qbit \ --net0 name=eth0,bridge=vmbr0 \ --features mount="nfs;cifs" \ --swap 512 \ --rootfs volume=local-lvm:8 2....

1. 前言 因为国内工作一直是用 微信 或者 钉钉，所以我一直不怎么使用邮件客户端来收发和管理邮件，就是收验证码的时候打开网页临时用一下，这就导致了我的邮件长期以来未读 99+ ，这其中大部分是 Twitter、Nintendo、Steam 的推送，还好我不是一个强迫症，所以就还好。但是最近我还是决定用一个邮件客户端来统一管理电子邮件，不是因为换了要用电子邮件办公的公司，而是收验证码的时候一个个邮件账号要切换，光是谷歌邮箱就有 3 个，是在是麻烦。还有一个重要的点，有时候绑定的账号用了一个不常用的邮箱，比如 Steam 小号，当小号异地登录（被盗）的时候发送的邮件我收不到提醒，可想而知小号就危险了。 2. 客户端选择 所以我需要一个邮件客户端来同意管理我的所有邮箱账号，由于我使用的系统为Windows，客户端的选择也并不多，我对邮件客户端的要求有： 免费 颜值高，简洁 内存占用尽量少，要常驻后台 方便集成常用的邮箱 QQ、Google、Outlook 等 不想用国产 基于以上选择我选了几个客户端来尝试一下，先放个比较图表： 客户端 优点 缺点 适用性 Outlook For Windows 微软官方支持，界面一致 字体渲染差，阅读体验不佳 适合微软生态用户 邮件 (UWP) 简洁，内存占用小 功能有限，UI 设计一般 适合简单邮件收发 Thunderbird 开源，功能丰富，支持扩展 UI 略显紧凑 适合需要高级功能的用户 2.1 Outlook For Windows 微软专门推出的邮件客户端，功能界面和 Web 版 outlook 一致，支持 Google、QQ、outlook 等常用邮箱，界面简洁，缺点就是在 Windows 下字体渲染巨差，在我使用了 MacType 替换了字体之后还是没有丝毫优化，阅读体验为负分，所以 Pass 。 2.2 邮件（UWP） 微软原装 UWP 应用，可以方便的添加 outlook 邮箱，布局简洁，内存可忽略不计，如果只使用 收验证码 这个朴素的任务的化是完全可以胜任的，但是对我来说还是功能太少，而且 UI 对我实在不是很有眼缘，所以 Pass 。...

1. 为什么要迁移 当初项目创建之际正处于 vite 早期，不敢冒险尝试，现在 vite 版本更新到了 5.x ，而且有着比 vue-cli-service（基于 webpack）好得多的性能，构建速度更快，热更新支持更完善，所以有什么理由不迁移呢。 2. 迁移 2.1 移除 vue-cli-service 相关依赖 现有 package.json 内容如下： { "name": "sfarm-front-vue", "version": "1.0.0", "private": true, "scripts": { "serve": "vue-cli-service --mode development serve", "build": "vue-cli-service build", "build:test": "vue-cli-service --mode development build", "lint": "vue-cli-service lint", "start": "yarn serve", "start:local": "vue-cli-service --mode local serve", "start:prod": "vue-cli-service --mode production serve", "prepare": "husky install" }, "dependencies": { "@element-plus/icons-vue": "^1.1.4", "axios": "^0.24.0", "core-js": "^3.6.5", "echarts": "^5....

1. 背景 有的时候我们需要修改虚拟机的文件，但是此时虚拟机却因为某些原因无法启动了，比如说虚拟机黑苹果修改了 EFI 导致启动不了，这时我们有什么办法呢，有人说我们添加一个可以启动的 EFI 启动设备再来修改原来 ESP 分区 (即原 EFI 文件系统) 不就好了，诚然，这是一个办法，但我们今天要介绍的是另一个办法，直接在宿主机挂载虚拟机的磁盘分区，就拿黑苹果 EFI 分区为例。 2. Raw raw 格式的磁盘镜像文件可以使用 losetup 虚拟成一个块设备。再使用 kpartx 读取分区表英创建设备映射，从而可以从设备挂载到宿主机： 2.1 挂载 安装 kpartx apt install kpartx 下面以虚拟机编号为 108 的 disk1 为例子 虚拟块设备 losetup /dev/loop0 /dev/mapper/pve-vm--108--disk--1 读取设备的分区表并创建设备分区映射 kpartx -av /dev/loop0 查看分区映射 ➜ ~ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1G 0 loop └─loop0p1 253:23 0 1024M 0 part sda 8:0 1 14.6G 0 disk ├─sda1 8:1 1 11....

1. 起因 最近看到很多 Linux 平铺窗口管理器的视频，总觉得很炫酷，体内的折腾之心在沸腾，于是就打起了体验（折腾）平铺窗口的想法，看到这里各位看官肯定要说：这和 Moonlight 串流有啥关系，标题党！辣鸡！ 哈哈，各位别急，且听我慢慢道来。 首先，我主力的生产系统是 Windows ，我不想在 Windows 下开发，所以 Windows 平铺窗口就 pass 掉了，只能转向 Linux，正好公司一台 Exsi 主机还剩很多资源，并且还有一块 GTX 1060 的显卡可以用来直通加速，那不正好创建一个带显卡的虚拟机，运行 Linux 桌面，然后我再远程串流这台虚拟机不就行了吗，那串流体验最好的自然是 Moonlight 了， 诶，你看，这不就关联大了吗！ 2. 环境 好吧，废话少说，我描述一下我的环境，我要远程串流的是一台 Exsi 创建的虚拟机，参数如下： 项目 值 备注 系统 Arch Linux CPU 8 vCPU 宿主机 CPU 为 AMD Ryzen Threadripper 1950X RAM 8GB GPU NVIDIA GeForce GTX 1060 6GB 显卡直通 显示器 无 远程串流服务 Sunshine v0.21.0 显示服务 X11 窗口管理器 awesome Windows 客户端 Moonlight-qt 2....

1. 前言 我的 这篇文章 中介绍了在 pve 环境中安装 Android-x86 实现 x86 架构的云手机，可惜 Android-x86 的版本停留在了 Android 9.0 ，这个版本的 Android 无法实现音频的串流，scrcpy 的音频串流最低支持到 Android 10 ，无法听到音频的云手机是不完美的，今天我们就来试下另一个 Android-x86 的项目 - BlissOS ，看它是否可解决以上问题，成为真正可用的云手机。 2. 安装 2.1 ROM 选择 简单介绍一下 BlissOS ，它是基于 AOSP 优化定制，集成了很多专为 PC 优化的功能，比 如 Dock，Desktop 模式，兼容 arm 应用，也就是说他的 ROM 定制得更像一个平板系统，而不是原生 AOSP 那样，AOSP 如果作为远程使用，没有触摸屏的情况下还是有很多操作上的不便，但是它定制的版本则很好的解决了鼠标操作的问题，因为它目标就是专为Chromebook、桌面PC、平板等设备优化。 目前官方提供了两个稳定的分支，BlissOS 14 基于 安卓 11 ，另一个 BlissOS 15 基于 Android 12L ，我这里选择了 BlissOS 14。 BlissOS 14 提供了几个 ROM，我们下载带谷歌框架的这个版本： 2.2 显卡加速 Bliss OS 由开源技术构建，内核基于 Linux 所以支持大部分显卡加速，然而由于 Nvidia 专用驱动对很多开源软件的支持问题，BlissOS 仅支持极少的 Nvidia 显卡，我的上篇文章中使用了 VirtualGL 为 Android-x86 提供显卡加速，那个方案是可行的，而且性能也足够，但缺点时没有物理输出，今天我们换个方案，参照 这篇文章 中提取出的核显 vbios ，就能实现核显直通并具有物理输出，我们不仅可以用来当作云手机，甚至可以外接显示器作为 HDPC 使用。...