Linux

内网自部署存储迁移到自部署的 S3 1. 存储的烦恼 我日常会使用一些自部署的服务，如写作的 Affine、代码服务 Gitea、备忘录记录服务 memos 记录自己的碎碎念。自部署这些服务的时候通常会涉及一些资源的存储，比如 Affine 中上传的图片资源、Gitea 的 package 制品、memos 中上传的图片等都需要消耗自身的存储空间。而我部署的平台是 PVE 的 Docker LXD 容器，这个容器里面使用 Docker 部署了一堆服务，存储已经扩了一遍又一遍了，然而主机上的存储也见底了。 正好家里还有一台绿联的 NAS，里面有一个闲置的存储池，正好用来建一个 S3 存储给以上这些服务使用。这样一方面可以在同一个地方管理上传的对象，另一方面也可以利用存储池 Raid 做一些备份。 2. 部署 Rustfs 要说开源 S3 实现就不得不提大名鼎鼎的 Minio 了，然而其因为商业化已经停止了仓库的维护。况且我的 NAS 也仅是 4C8G 的配置，所以资源能省则省，基于 Rust 开发的 Rustfs 就是最好的选择——部署简单，资源占用低，性能还高，简直是居家旅行、自部署常备。 NAS 上的 Docker 不能命令行，只能图形界面操作，就略过部署过程了。 部署好了之后打开 console 端口 9001 即可进行存储桶操作。 2.1 使用 AWS CLI 测试访问 创建一个访问密钥，使用 AWS CLI 来测试访问。在 ~/.aws/credentials 中配置好访问密钥，~/.aws/config 中配置 endpoint 信息： [default] region=us-east-1 endpoint_url=http://192.168.5.103:9000 region 随便填一个值就可，测试访问：...

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. 背景 有的时候我们需要修改虚拟机的文件，但是此时虚拟机却因为某些原因无法启动了，比如说虚拟机黑苹果修改了 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. 前言 之前体验过 intel 的 vGPU 解决方案 Intel GVT-g ，我的古早处理器 i5-10400 还是 intel 很老的gpu架构的 UHD630 分配到一个 Win10 虚拟机使用，哪怕是只分配一个 vm 的情况下性能依然不够看，使用 parsec 1080P H264 串流的情况下帧数无法保证60，这时视频播放就更不用说了，直接GPU占用100%，更不用谈 2k、4k 等高分辨率串流了。早就了解到 Nvidia 的 vGPU方案支持 kvm 平台，而且支持 Windows 和 Linux 客户操作系统，性能较 intel 核显好得多，于是我弄来了这块小小的 Tesla P4。 2. 硬件 这块 Tesla P4 是个单槽半高卡，刚好我的 pve 宿主机剩下一个 x16 的 PCIE 插槽，虽然只有 X4 的速度，但咋对性能没有极致的追求，所以损失一点性能还能接受（主要是穷换不起主板），而且这块显卡最高功耗仅为 75W 无需外接供电，实测无负载的时候功耗仅十几瓦，最惊讶的还是他的价格，仅仅只需300块，这简直就是“年轻人的第一台特斯拉”呀，哈哈。缺点就是其是为了数据中心设计的，没有主动散热，所以我们需要外接一个小小的风扇为其降温，就是图中这个，我多花了50从PDD购入。 拆机安装 内部紧凑的空间，一番折腾终于装上了，这台主机的配置可以在这篇文章中找到。 安装的过程中还有2的小插曲： 我的手在拆机的时候碰到散热器挂彩了（所以一定是要祭点什么吗）。 安装之后开机系统识别不了我的 2 块 PCIE 的 M.2 固态，还以为是这块主板的接口有屏蔽关系，最后发现是因为我打开了 GSM，需要关闭 GSM 才能正确识别 M.2 硬盘。 3....

1. 前言 我的一篇 文章 中有提到过云安卓手机的项目-redroid，该 项目 基于容器技术，构建一个安卓的运行时，同时通过Linux的内核模块，支持调用宿主机的硬件资源，同时其可运行于 x86 架构之上，通过转译来运行仅支持 arm 架构的安卓应用，用来跑app测试可以一试，正好甲骨文的arm主机资源没有好好利用，今天就来折腾一下这个玩法。 2. 加载内核模块 ashmem_linux、binder_linux 2.1 基于 Ubuntu 20.04 以上发行版 这两个模块是容器运行必须的内核模块，按照官方文档，在 Ubuntu 20.04 以上版本中，这两个模块已经编译到内核里了，可以直接 modprobe 命令加载，所以如果你的 arm服务器 正好是Ubuntu 20.04 以上版本，按照一下命令即可运行： # 安装额外内核模块 apt install linux-modules-extra-`uname -r` # 加载内核模块 modprobe binder_linux devices="binder,hwbinder,vndbinder" modprobe ashmem_linux # 运行容器 docker run -itd --rm --privileged \ --pull always \ -v ~/data:/data \ -p 5555:5555 \ redroid/redroid:11.0.0-latest \ androidboot.redroid_gpu_mode=guest 2.2 Oracle Linux 8 否则如果你像我一样开主机的时候选了 Oracle Linux 8 的话，很遗憾，官方没有该系统的运行文档，以上两个内核模块也并没有编译，奈何我对该发行版不熟，升级了官方内核到 5....

甲骨文的免费Arm主机开始申请的时候没注意选了 Oracle Linux 8 系统而没选自己更熟悉的Ubuntu ，导致各种折腾的时候发现资料有点少，今天折腾一个云安卓 redroid 系统的时候发现需要编译一些内核模块，而默认的 5.4 内核一直编译失败，于是想到升级内核试试，一路搜索找不到很符合的文章，于是自己摸索了一下，记录于此。 1. 查看已经安装的内核包 ➜ client yum list installed | grep kernel kernel-headers.aarch64 4.18.0-477.13.1.el8_8 @ol8_baseos_latest kernel-tools.aarch64 4.18.0-477.13.1.el8_8 @ol8_baseos_latest kernel-tools-libs.aarch64 4.18.0-477.13.1.el8_8 @ol8_baseos_latest kernel-uek.aarch64 5.4.17-2136.307.3.1.el8uek @ol8_baseos_latest kernel-uek.aarch64 5.4.17-2136.309.4.el8uek @ol8_baseos_latest kernel-uek.aarch64 5.4.17-2136.320.7.1.el8uek @ol8_baseos_latest kernel-uek-devel.aarch64 5.4.17-2136.307.3.1.el8uek @ol8_baseos_latest kernel-uek-devel.aarch64 5.4.17-2136.309.4.el8uek @ol8_baseos_latest kernel-uek-devel.aarch64 5.4.17-2136.320.7.1.el8uek @ol8_baseos_latest 可以看到我们的内核都是baseos仓库安装的内核，该仓库内核版本比较老，查看 官网仓库 列表，内核仓库有了更新的包。 内核版本为 5.15.0 2. 安装内核 先看下已有的 yum 库 ➜ sudo yum repolist repo id repo name docker-ce-nightly Docker CE Nightly - aarch64 docker-ce-stable Docker CE Stable - aarch64 docker-ce-test Docker CE Test - aarch64 epel Extra Packages for Enterprise Linux 8 - aarch64 nginx-stable nginx stable repo ol8_MySQL80 MySQL 8....

1. 起因 工作中我一直使用wireguard搭建公司 -> 家的桥梁，用于随时随地访问家中内网的各种服务，如gogs代码仓库、nextcloud同步工作文件，抑或是远程连接windows虚拟机用来摸鱼，然而尽管拥有公网ip，家里和公司之间只有区区10ms的网络时延，却还是因为运营商对UDPl的QOS而影响远程服务的传输体验。于是我就搭建了一套phantun服务用来将UDP流量转换为TCP流量而避过运营商的QOS，建好之后确实体验提升明显，远程的moonlight能稳定跑满30M上传带宽，然而当时搭建的时候的iptables规则未保存，今天的一次重启让我的phantun死活连不上，于是就有了今天的文章。 2. 排查 2.1 报错日志 由于是客户端重启之后连不上的，排除服务端错误的情况，从客户端查起，查看phantun报错： sudo systemctl status phantun.service Nov 8 10:22:11 new-business-dev-001 phantun_client[5517]: ERROR client > Unable to connect to remote {my-home-ip}:25379 Nov 8 10:22:14 new-business-dev-001 phantun_client[5517]: ERROR client > Unable to connect to remote {my-home-ip}:25379 客户端一直报错连不上服务端，25379端口是phantun_server的监听端口，之前连接是好的，不可能有问题。 2.2 抓包分析 遇到网络相关的问题，抓包分析是最为直观的解决方案，我们查看往来服务端的流量信息: sudo tcpdump -i any host {my-home-ip} 10:28:48.652090 IP 192.168.200.2.61048 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0 10:28:49.653239 IP 192....

idea在ubuntu下的字体表现 idea这么强大的ide相信大家都有目共睹，但是最近在ubuntu下安装idea之后却发现字体表现还不如windows，要知道windows的字体渲染可是不如linux的，在高分屏下window的字体会出现明显锯齿，而linux就很平滑，虽然这个和idea没关系，因为idea是用java开发的，字体渲染不是用的系统的字体渲染引擎。查阅资料也发现对于idea的字体渲染问题，intelliJ是有优化过的，然而我ubuntu下的idea看起来却是这样的： idea环境 我的ubuntu是18.04LTS，屏幕是23寸1920*1080，idea设置如下： 主题方面选择了idea内部提供的暗色主题Darcula编辑界面主题是在idea主题样式网站下载的： 英文字体是Adobe开源的source code pro,在github仓库中提供下载。中文字体是开源字体文泉驿微米黑 更换系统主题 字体看起来发虚只是在暗色主题中才会发生，所以我们采取曲线救国策略，换用itelliJ亮色主题，然后结合一张暗色背景图来实现暗色主题的效果。 主题选择intellJ 选择一张背景图设置透明度 编辑界面主题选择一张亮色的主题，字体不变 成果 完成以上设置之后来看看成果 字体看起来平滑多了，好了，安心编码吧 :)