Linux on Linkzz's Blog

简单记录一下 Docker 容器中信任一个自签名证书的案例

Wed, 10 Apr 2024 00:00:00 +0000

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 文件。

2.2 宿主机信任证书

因为可能不止一个容器需要信任证书，所以选择先在宿主机信任证书，然后映射宿主机的证书文件夹到容器，这样宿主机和容器都能达到信任证书的效果。

拷贝证书文件

cp your_pem.pem /usr/local/share/ca-certificates/rootCA.crt

注意后缀名需要重命名为 crt

更新证书

# 如果没安装 ca-certificates 需要先安装 ca-certificates
# apt install ca-certificates
update-ca-certificates

如果提示 command not found 安装 ca-certificates 软件包即可

Updating certificates in /etc/ssl/certs…
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d…
done.

上面日志没有报错提示添加了1个证书，表示添加信任证书成功。

运行 curl 验证一下：

curl -v https://wewe.linkzz.hm/feeds/MP_WXS_3925660753.atom

*   Trying 192.168.5.120:443…
* TCP_NODELAY set
* Connected to wewe.linkzz.hm (192.168.5.120) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: O=mkcert development certificate; OU=LINKZZ-LAPTOP\linkzz@linkzz-laptop (linkzz)
*  start date: Dec 18 01:59:08 2023 GMT
*  expire date: Mar 18 01:59:08 2026 GMT
*  subjectAltName: host "wewe.linkzz.hm" matched cert's "*.linkzz.hm"
*  issuer: O=mkcert development CA; OU=LINKZZ-LAPTOP\linkzz@linkzz-laptop (linkzz); CN=mkcert LINKZZ-LAPTOP\linkzz@linkzz-laptop (linkzz)
*  SSL certificate verify ok.
> GET /feeds/MP_WXS_3925660753.atom HTTP/1.1
> Host: wewe.linkzz.hm
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Wed, 10 Apr 2024 09:14:46 GMT
< Content-Type: application/atom+xml; charset=utf-8
< Content-Length: 3944
< Connection: keep-alive
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: authorization
< ETag: W/"f68-vmfb7ZvVPKMACdW27xekYBF0xLA"
<
<?xml version="1.0" encoding="utf-8"?>

可以看到已经正常响应了。

2.3 映射到容器证书目录

下面更新 ttrss 的容器映射，将宿主机的 /etc/ssl/certs 文件夹映射到容器相同目录 /etc/ssl/certs 即可，我的是 compose 运行的，更新 docker compsoe 文件：

version: "3"
services:
  service.rss:
    image: wangqiru/ttrss:latest
    container_name: ttrss
    ports:
      - 181:80
    environment:
      - SELF_URL_PATH=https://ttrss.linkzz.hm:443/ # please change to your own domain
      - DB_PASS=ttrss_bac # use the same password defined in `database.postgres`
      - PUID=1000
      - PGID=1000
    volumes:
      - feed-icons:/var/www/feed-icons/
      - /etc/ssl/certs:/etc/ssl/certs
    networks:
      - public_access
      - service_only
      - database_only
    stdin_open: true
    tty: true
    restart: always

  service.mercury: # set Mercury Parser API endpoint to `service.mercury:3000` on TTRSS plugin setting page
    image: wangqiru/mercury-parser-api:latest
    container_name: mercury
    networks:
      - public_access
      - service_only
    restart: always

  service.opencc: # set OpenCC API endpoint to `service.opencc:3000` on TTRSS plugin setting page
    image: wangqiru/opencc-api-server:latest
    container_name: opencc
    environment:
      - NODE_ENV=production
    networks:
      - service_only
    restart: always

  database.postgres:
    image: postgres:13-alpine
    container_name: postgres
    environment:
      - POSTGRES_PASSWORD=ttrss_bac # feel free to change the password
    volumes:
      - ~/postgres/data/:/var/lib/postgresql/data # persist postgres data to ~/postgres/data/ on the host
    networks:
      - database_only
    restart: always

  # utility.watchtower:
  #   container_name: watchtower
  #   image: containrrr/watchtower:latest
  #   volumes:
  #     - /var/run/docker.sock:/var/run/docker.sock
  #   environment:
  #     - WATCHTOWER_CLEANUP=true
  #     - WATCHTOWER_POLL_INTERVAL=86400
  #   restart: always

volumes:
  feed-icons:

networks:
  public_access: # Provide the access for ttrss UI
  service_only: # Provide the communication network between services only
    internal: true
  database_only: # Provide the communication between ttrss and database only
    internal: true

重启容器即可生效。

正常订阅的截图：

3. 总结

自签名证书对于有很多自部署在 nas 或者内部服务器，不方便公用服务申请证书的服务是很方便的，今天更新了容器中添加自信任证书的方法，总结就是先宿主机信任自签名证书，然后将 curl 等命令需要用到的证书文件夹 /etc/ssl/certs/ 文件夹直接映射到容器中国即可。

Docker 环境下的 qBittorrent 容器迁移至 lxc 保留配置

Tue, 09 Apr 2024 00:00:00 +0000

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.2 设置容器

这样就创建好了一个基于 archlinux 的 ct 容器，接下来启动进入容器简单设置一下：

启动容器：

pct start 117

进入容器：

pct enter 117

修改网络开启 dhcp 自动获取 IP

vi /etc/systemd/network/eth0.network

[Match]
Name = eth0

[Network]
Description = Interface eth0 autoconfigured by PVE
DHCP = yes
IPv6AcceptRA = false

将 DHCP 改为 yes, 重启网络服务

systemctl restart systemd-networkd

以上内容均可以通过 pve 的 webui 界面完成。

2.3 迁移配置 qbittorrent-nox

在 headless 无头环境下运行 qbittorrent 我们需要下载 qbittorrent-nox，nox -> no X server，没有 X 服务，外国人还是会起名。

archlinux 下直接通过包管理器安装即可，版本也是当下最新的 4.6.4 版本

pacman -S qbittorrent-nox

启动 qbittorrent-nox

systemctl enable qbittorrent-nox && systemctl start qbittorrent-nox

将 Docker 容器中的 qbittorrent 配置文件迁移到 ~/.config/qBittorrent/qBittorrent.conf 中，我的是 v4.4.3.1 迁移到 v4.6.4，迁移比较平滑，我所有的配置都继承了下来，如果是更低版本就不好说了，可以选择性的迁移。

2.4 下载数据迁移

原来的下载数据种子文件保留在 BT_backup 文件夹中，在 Docker 容器和新的配置文件下载路径一致的情况下可以平滑迁移，qbittorrent 不会报文件丢失，当然如果不需要迁移的话直接忽略掉就好了。

将 BT_backup 文件夹内容复制到新的 qbittorrent 数据文件夹下相应的位置即可。

3. 结语

此次迁移过程还是很顺利的，毕竟版本的变化也没那么大，由此我们可以学习下优质开源项目的向下兼容，破坏性的变化引入应该是很谨慎的。

看下迁移后的截图，新的 UI 界面图标太丑了🤣

pve 宿主机挂载虚拟机磁盘镜像

Tue, 16 Jan 2024 00:00:00 +0000

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.8G  0 part
├─sda2                         8:2    1    16M  0 part
├─sda3                         8:3    1   2.7G  0 part
├─sda4                         8:4    1    16M  0 part
├─sda5                         8:5    1     2M  0 part
├─sda6                         8:6    1   512B  0 part
├─sda7                         8:7    1   512B  0 part
├─sda8                         8:8    1    16M  0 part
├─sda9                         8:9    1   512B  0 part
├─sda10                        8:10   1   512B  0 part
├─sda11                        8:11   1     8M  0 part
└─sda12                        8:12   1    32M  0 part
nvme1n1                      259:0    0 238.5G  0 disk
├─nvme1n1p1                  259:1    0 238.5G  0 part
└─nvme1n1p9                  259:2    0     8M  0 part

可以看到 loop0 下有一个分区

挂载分区

mkdir pve-efi
mount /dev/mapper/loop0p1 pve-efi

查看分区文件

➜  ~ ls -al pve-efi
total 11
drwxr-xr-x  6 root root  512 Jan  1  1970 .
drwx------ 18 root root 4096 Jan 16 14:09 ..
-rwxr-xr-x  1 root root 4096 Dec 29 07:12 ._EFI
drwxr-xr-x  4 root root  512 Dec 29 07:12 EFI
drwxr-xr-x  2 root root  512 Jan 13 09:48 .fseventsd
drwxr-xr-x  3 root root  512 Dec 29 07:12 .Spotlight-V100
drwxr-xr-x  3 root root  512 Dec 29 07:12 .Trashes

2.2 卸载

按照挂载的顺序反向卸载

# 文件系统
umount pve-efi
# 设备分区
kpartx -d /dev/loop0
# 块设备虚拟
losetup -d /dev/loop0

3. Qcow2

3.1 挂载

Qcow2 镜像需要通过 nbd 模块挂载

检查 nbd 模块是否加载

lsmod | grep nbd

若没有输出结果则加载 nbd

modprobe nbd max_part=8

挂载镜像，下面以编号 103 的虚拟机磁盘 2 文件为例

qemu-nbd --connect=/dev/nbd0 /var/lib/vz-b/images/113/vm-113-disk-1.qcow2

查看分区

➜  ~ fdisk -l /dev/nbd0
Disk /dev/nbd0: 32 GiB, 34359738368 bytes, 67108864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DACC591B-A767-EA4F-8028-9757172F0505

Device          Start      End  Sectors  Size Type
/dev/nbd0p1  11472896 67108815 55635920 26.5G Linux filesystem
/dev/nbd0p2     20480    53247    32768   16M ChromeOS kernel
/dev/nbd0p3   5894144 11472895  5578752  2.7G ChromeOS root fs
/dev/nbd0p4     53248    86015    32768   16M ChromeOS kernel
/dev/nbd0p5    315392  5894143  5578752  2.7G ChromeOS root fs
/dev/nbd0p6     16448    16448        1  512B ChromeOS kernel
/dev/nbd0p7     16449    16449        1  512B ChromeOS root fs
/dev/nbd0p8     86016   118783    32768   16M Linux filesystem
/dev/nbd0p9     16450    16450        1  512B ChromeOS reserved
/dev/nbd0p10    16451    16451        1  512B ChromeOS reserved
/dev/nbd0p11       64    16447    16384    8M unknown
/dev/nbd0p12   249856   315391    65536   32M EFI System

可以看到我挂载的是一个 FydeOS 虚拟机的镜像文件，是基于 Chromium OS 的操作系统，所以看到了文件系统有 ChromeOS kernel 等，下面挂载下 linux filesystem 分区。

挂载分区

mkdir chromeos-file
mount /dev/nbd0p1 chromeos-file

查看分区文件

➜  ~ cd chromeos-file
➜  chromeos-file ll
total 275992
drwxr-xr-x   9 root root       4096 Nov 26 15:04 .
drwx------  18 root root       4096 Jan 16 16:19 ..
drwxr-xr-x. 17 root root       4096 Nov 14 10:59 dev_image
drwxrwxr-x.  2 root root       4096 Nov 26 15:04 encrypted
-rw-------.  1 root root 8357232640 Nov 26 16:26 encrypted.block
-rw-------.  1 root root         48 Nov 26 15:04 encrypted.key
drwxr-xr-x.  3 root root       4096 Nov 26 15:04 etc
drwxr-xr-x.  6 root root       4096 Nov 26 15:04 home
drwx------   2 root root      16384 Nov 26 14:55 lost+found
drwxr-xr-x. 13 root root       4096 Nov 26 15:04 unencrypted
drwx--x--x.  5 root root       4096 Nov 26 15:04 var_overlay

这样就挂载好了一个分区，可以进行编辑了，编辑好了之后卸载回到客户机即可看到改动了。

3.2 卸载

卸载还是反向操作

umount chromeos-file
qemu-nbd --disconnect /dev/nbd0

卸载 nbd 模块 (可选)

modprobe -r nbd

4. 结语

至此就完成了 pve 常用的 2 种格式的镜像文件的挂载操作，该用法的需求是我在折腾黑苹果 EFI 开不了机的时候爬帖子学到的，其他格式的文件挂载可以查看 foxi 的这篇文章

记一次 Moonlight 10054 错误的解决经历

Fri, 29 Dec 2023 00:00:00 +0000

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 串流设置

按照官网headless系统设置的指引，我安装好了 nvidia 的专有驱动，驱动能成功识别显卡，设置好了一个虚拟显示器并且成功运行了 Xorg ，

3. 排查

x11vnc 可以访问桌面，并且 awesome 工作正常，rustdesk 可以访问并且能开启硬件编码。

唯独 sunshine 连接不上，启动日志显示硬件编码工作正常

Moonlight客户端可以正常添加和配对串流主机，但在启动【Desktop】串流之后总会报错：

启动 RTSP handshake 失败: 错误 10054
检查防火墙和端口转发规则: TCP 48010，UDP 48000，UDP 48010

按照以上提示检测端口连通性，因为我和串流主机都在内网环境，我的客户端是 Windows 系统，防火墙已经关掉了，而串流的 Archlinux 是没有装防火墙服务的，所以不存在防火墙挡掉端口的问题，果然，使用 nc 测试端口连通：

➜  ~ nc -v 10.1.1.63 48010
Connection to 10.1.1.63 48010 port [tcp/*] succeeded!

UDP 的端口只有在串流的过程中才会打开监听，所以没法直接测试，但是通过手动端口监听测试也证明 UDP 端口也是没有被防火墙挡掉的。

# 服务端监听 udp 48010
 ~ nc -lu -p 48010

# 客户端连接
➜  ~ nc -uv 10.1.1.63 48010
Connection to 10.1.1.63 48010 port [udp/*] succeeded!

查看 sunshine 的详细连接日志发现执行 desktop 之后 sunshine 接收到了一个 rtsp 的 Request，sequence 是1，之后就客户端就退出报错了。

[2023:12:29:17:03:29]: Debug: ------  h264 ------
[2023:12:29:17:03:29]: Debug: PASSED: supported
[2023:12:29:17:03:29]: Debug: REF_FRAMES_RESTRICT: unsupported
[2023:12:29:17:03:29]: Debug: CBR: supported
[2023:12:29:17:03:29]: Debug: DYNAMIC_RANGE: unsupported
[2023:12:29:17:03:29]: Debug: VUI_PARAMETERS: supported
[2023:12:29:17:03:29]: Debug: -------------------
[2023:12:29:17:03:29]: Info: Found H.264 encoder: h264_nvenc [nvenc]
[2023:12:29:17:03:29]: Debug: ------  hevc ------
[2023:12:29:17:03:29]: Debug: PASSED: supported
[2023:12:29:17:03:29]: Debug: REF_FRAMES_RESTRICT: unsupported
[2023:12:29:17:03:29]: Debug: CBR: supported
[2023:12:29:17:03:29]: Debug: DYNAMIC_RANGE: unsupported
[2023:12:29:17:03:29]: Debug: VUI_PARAMETERS: supported
[2023:12:29:17:03:29]: Debug: -------------------
[2023:12:29:17:03:29]: Info: Found HEVC encoder: hevc_nvenc [nvenc]
[2023:12:29:17:03:29]: Debug: /CN=NVIDIA GameStream Client -- verified
[2023:12:29:17:03:29]: Debug: TUNNEL :: HTTPS
[2023:12:29:17:03:29]: Debug: METHOD :: GET
[2023:12:29:17:03:29]: Debug: DESTINATION :: /serverinfo
[2023:12:29:17:03:29]: Debug: User-Agent -- Mozilla/5.0
[2023:12:29:17:03:29]: Debug: Accept-Language -- zh-CN,en,*
[2023:12:29:17:03:29]: Debug: Accept-Encoding -- gzip, deflate
[2023:12:29:17:03:29]: Debug: Connection -- Keep-Alive
[2023:12:29:17:03:29]: Debug: Host -- 10.1.1.63:47984
[2023:12:29:17:03:29]: Debug:  [--]
[2023:12:29:17:03:29]: Debug: uuid -- d63f79a098fb43e199209d93b001b333
[2023:12:29:17:03:29]: Debug: uniqueid -- 0123456789ABCDEF
[2023:12:29:17:03:29]: Debug:  [--]
[2023:12:29:17:03:29]: Debug: handle_read(): Handle read of size: 93 bytes
[2023:12:29:17:03:29]: Debug: handle_payload(): Handle read of size: 0 bytes
[2023:12:29:17:03:29]: Debug: type [REQUEST]
[2023:12:29:17:03:29]: Debug: sequence number [1]
[2023:12:29:17:03:29]: Debug: protocol :: RTSP/1.0
[2023:12:29:17:03:29]: Debug: payload ::
[2023:12:29:17:03:29]: Debug: command :: OPTIONS
[2023:12:29:17:03:29]: Debug: target :: rtsp://10.1.1.63:48010
[2023:12:29:17:03:29]: Debug: CSeq :: 1
[2023:12:29:17:03:29]: Debug: X-GS-ClientVersion :: 14
[2023:12:29:17:03:29]: Debug: Host :: 10.1.1.63
[2023:12:29:17:03:29]: Debug: ---Begin MessageBuffer---
OPTIONS
---End MessageBuffer---
[2023:12:29:17:03:29]: Debug: ---Begin Response---
RTSP/1.0 200 OK
CSeq: 1



---End Response---
[2023:12:29:17:03:32]: Debug: TUNNEL :: NONE

这就是问题的所在，说明客户端很可能没收到这个Sequence为1的应答，导致双方连接不上，并不是因为硬件编码的问题，也不是防火墙的问题，更不是 X11 显示系统的问题。

那是什么问题呢，我看着 RTSP 陷入了沉思，联想到各大网络直播多是使用的 RTSP 协议推流，该不会是 IT 禁用了该协议吧，果然，公司上班时间是无法观看直播网站的，直播推流的流也是拉取不到的！

事已至此，一切都真相大白了，公司用的是深信服的网络行为管理，老板为了省钱IT是外包的，一周来一次，平时接触不到，没想到这个策略的设置如此简单粗暴，内网的RTSP协议都给禁掉了，那开发如果用到该协议推流，我估计光是排查问题就得浪费半天时间吧，哎，结合到最近各大互联网公司频发的运维事故我只想说：降本增效害死人！

4. 解决问题

既然知道问题发生的原因了，解决就好办了，既然直连的 RTSP 协议不行，我通过 VPN 开个隧道总可以了吧。果然，通过 wireguard 建立隧道之后一切问题解决，串流成功，不得不感叹 Moolight 和 Sunshine 项目做的真是完美，低延迟，高性能，画质还不差，体验秒杀前面的 VNC 和 rustdesk，接下来继续我的平铺窗口管理器之旅了，Awesome !

Tesla P4 - Nvidia 专业卡 vGPU 解决方案体验

Wed, 13 Dec 2023 00:00:00 +0000

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. 软件

一番折腾终于正确安装好了，现在试下他有什么魔力吧。

3.1 宿主机设置

我的pve版本还是7.x，并没有升级到8.x，所以下面的操作均是在7.x的环境下进行，8.x内核升级到了6.x，按照我的操作不一定能成功！看官自行分辨。

Nvidia官网下载专业卡驱动需要注册申请啥的，比较麻烦，好在有热心大佬维护了一个仓库更新官方驱动，我们使用这个版本，找到最新的Release 包，我这里下载了 535.129.03-537.7 的版本，下载到宿主机安装:

wget https://github.com/justin-himself/NVIDIA-VGPU-Driver-Archive/releases/download/16.2/NVIDIA-GRID-Linux-KVM-535.129.03-537.70.zip
# 解压
unzip NVIDIA-GRID-Linux-KVM-535.129.03-537.70.zip
# 安装dkms
apt install dkms
# 安装驱动
Host_Drivers/NVIDIA-Linux-x86_64-535.129.03-vgpu-kvm.run --dkms
# 重启
reboot

如没问题重启之后运行 nvidia-smi

识别到 Tesla P4 就安装好了宿主机驱动。

运行 mdevctl types 可列出支持的vGPU类型。

3.2 系列解读

接下来我们看看这些vGPU的系列有什么区别，看到图中的类型 nvidia-65 即 GRID P4-4Q

简单说下类别类目里的一些区别，GRID 是 Nvidia 早期 vGPU 技术的名词，P4 是显卡型号，后缀的大写字母 A 、 B、 Q 代表不同的侧重点系列，首先，不同的系列需要的授权不同，当然我们使用的是特殊授权，所以这点不重要，对我们来说重要的在以下方面：

系列	侧重	最大分辨率
A系列	面向虚拟应用程序用户的应用程序流或基于会话的解决方案	1280 x 1024 60Hz
B系列	面向商务专业人士和知识工作者的虚拟桌面	5120 x 2880 45Hz
Q系列	适合需要 Quadro 技术性能和功能的创意和技术专业人员的虚拟工作站	7680 x 4320 60Hz

如图，如果你的vm侧重计算，不在意显示，那选 A 系列，如果运行的是 VDI 应用，那选 B 系列，而我这种注重显示的就选Q 系列啦。

而系列字母前的数字则是分配的专有显存的大小，如 GRID P4-4Q 代表该vGPU将具有4GB 的专有显存。

可用 则是可同时启动的实例数目，比如上面的 GRID P4-4Q 每台实例具有 4GB 的显存，而 P4 总共具有 8GB 显存，那显然能同时启用的实例即是 2台 （截图中因为我这台虚拟机已经开机了，所以显示还有1台可用）

3.3 Windows客户机

下面我们来看下 Windows 客户机 vGPU 是如何使用的，首先创建虚拟机：

# 创建6C4G的windows虚拟机
qm create 116 \
--cores 6 \
--cpu host \
--bios ovmf \
--machine q35 \
--memory $((4 * 1024)) \
--net0 virtio,bridge=vmbr0,firewall=1 \
--name Win-P4-4Q \
--scsihw virtio-scsi-single \
--efidisk0 file=local-vzb:0,format=qcow2 \
--scsi0 file=local-vzb:32,format=qcow2 \
--tpmstate0 file=local-vzb:0 \
--ide2 file=ugreen:iso/Win11_22H2_Chinese_Simplified_x64v2.iso,media=cdrom \
--ide0 file=ugreen:iso/virtio-win-0.1.240.iso,media=cdrom \
--boot order="scsi0;ide2" \
--hostpci0 0000:05:00.0,mdev=nvidia-65,pcie=1 \
--audio0 device=ich9-intel-hda,driver=none

3.3.1 Widnows vGPU 驱动

正常安装之后Windows设备管理器中没有正确识别到GPU，显示为“Microsoft基本显示适配器”

Windows 所用的驱动在刚才我们下载的文件下，我们安装 Guest_Drivers/537.70_grid_win10_win11_server2019_server2022_dch_64bit_international.exe ，安装完之后即可正常驱动vGPU了。

任务管理器也可以看到 GPU 具有了负载。

安装完成之后可以打开 RDP ，关机将显示设置为“无”，将vGPU设置为主GPU，这样便于程序识别正确的 GPU 。

3.3.2 vGPU 授权

上文提到过，我们需要对 vGPU 进行授权，获得相关的许可证才能完全的使用 vGPU，否则使用受限，无法完整使用。

我们使用 fastapi-dls 搭建一个授权服务器获取授权，具体做法这里不赘述，想了解详情可以查看项目文档，然后通过授权服务器获取授权，推荐使用 Powershell 脚本，方便快捷。

curl.exe --insecure -L -X GET https://<dls-hostname-or-ip>/-/client-token -o "C:\Program Files\NVIDIA Corporation\vGPU Licensing\ClientConfigToken\client_configuration_token_$($(Get-Date).tostring('dd-MM-yy-hh-mm-ss')).tok"

安装完重启，查询授权情况：

nvidia-smi -q  | Select-String "License"

授权成功。

这里获取授权之前一定要先 ntp 同步一下系统时钟，我因为没有同步时钟导致和服务器的时间不一致授权一直失败，找了一番原因才找到原因所在。

3.3.3 远程方案

vGPU 是没有物理输出的，但得益于今天各种串流技术的发展，我们的远程连接可以做到和实机相差无几的体验，除了微软自带的RDP方案之外也有不少选择，RDP 虽好，但毕竟不是专门为了 Gaming 串流而生，在视频播放，游戏串流等方面体验较专门为了 Gaming 串流优化的软件如 Parsec 、Sunshine 等体验还有差距，所以我们就试下后面这两者的串流。

Parsec

Parsec 的安装我们默认即可，可以不安装 Parsec 的 VDD，因为 vGPU 驱动自带了虚拟显示适配器，我们就用他的就好了，安装好了之后登录账号。在客户端也登录对应的账号就可以看到远程机器了。

看到这是我在公司连接的效果，场景为浏览器 ufo test 使用的是 2k 分辨率的串流，网络开销 7.65Mbps 换算下来 1.06Mb/s，网络延迟 18ms，宿主机编码延迟 7.34ms，解码延迟 14.51ms 左右，整体在 40ms 左右的延迟，在公司的使用情况是完全可以当作主力机使用了。

可以看到对应任务的 GPU 负载，主要是编码器，可以看到性能开销很小，还有余力进行其他大型的 3D 运算。

Sunshine

Sunshine 是一个开源的 moonlight 协议的服务端实现，在 Nvidia 宣布将不再其驱动中集成 Shield 串流之后 Sunshine 的是使用变得广泛了起来，社区也很活跃，支持 Intel 、Amd 、 Nvidia 三大主流 GPU，具有 webui 配置也比较方便。

正常安装好了之后访问 webui ，第一次访问需要设置管理密码，好了之后安装打开客户端 moonlight ，内网环境应该自动发现了设备，我在公司需要主动添加，输入主机 IP 即可添加。

点击图标连接会得到一个 pin 码，在 webui 中 Pin 选项卡下输入该 pin 码即可配对成功。

接下来点击默认配置的 Desktop 程序即可连接桌面

接下来我们看下串流表现

同样场景 2k 分辨率的串流，网络延迟 8ms 左右，平均编码时间 0.13ms ，渲染时间 0.13ms ，和 Parsec 的指标不同，所以单纯比较数据也是没有意义的，以我实际体验的感觉来看，两者之间是没有很大的差别的，完全可以应付日常使用。

3.4 Linux 客户机

接下来体验一下 Linux 客户机，发行版选择 Arch Linux ，创建虚拟机：

qm create 117 \
--cores 6 \
--cpu host \
--bios ovmf \
--machine q35 \
--memory $((4 * 1024)) \
--net0 virtio,bridge=vmbr0,firewall=1 \
--name Arch-P4-4Q \
--scsihw virtio-scsi-single \
--efidisk0 file=local-vzb:0,format=qcow2 \
--scsi0 file=local-vzb:32,format=qcow2 \
--ide2 file=ugreen:iso/archlinux-2023.10.14-x86_64.iso,media=cdrom \
--boot order="scsi0;ide2" \
--hostpci0 0000:05:00.0,mdev=nvidia-65,pcie=1 \
--audio0 device=ich9-intel-hda,driver=none

3.4.1 Linux 驱动

正常安装完之后就可以安装显卡驱动了

# 安装dkms
sudo pacman -S dkms

# 拷贝驱动至虚拟机之后安装
./Guest_Drivers/NVIDIA-Linux-x86_64-535.129.03-grid.run --dkms

安装完重启可以查看 nvidia-smi 是否正常识别显卡。

3.4.2 Linux 授权

利用刚才我们搭建的授权服务同样可以授权 Linux 的驱动

# 下载授权文件
sudo curl --insecure -L -X GET https://<dls-hostname-or-ip>/-/client-token -o /etc/nvidia/ClientConfigToken/client_configuration_token_$(date '+%d-%m-%Y-%H-%M-%S').tok

# 重启服务
sudo systemctl restart nvidia-gridd

# 查看授权信息
nvidia-smi -q | grep "License"

授权正常将看到一下信息：

3.4.3 CUDA Toolkit

vGPU 支持 CUDA，正常安装 CUDA Toolkit 即可，我这里安装了 12.2 版本的。

3.4.4 桌面环境

Linux 桌面我使用不多，在我看来 Linux server 模式很稳定，但是 Linux GUI 却常有问题，用处真的不大，尤其 vGPU 没有物理输出，一旦 GUI 奔溃难以远程将很难调试，这里我只是安装了驱动支持较好的 x11-vnc 和 rustdesk 用来简单测试一下，桌面环境则是使用的 KDE。

X11-VNC

VNC 的客户端我选择了 TigerVNC ，可以看到分辨率可以设置为 2k ，但奇怪的是这个客户端无法设置缩放，所以我只能拖动高度条使用，要么就是全屏之后鼠标靠近边缘可以自动滑动画面。或者像下面设置为 1080P 使用。

rustdesk

rustdesk 是一个由 rust 编写的开源的远程桌面工具，其目标是做 TeamViewer 的替代品，支持 X 和 Wayland ，支持自建中心服务，rustdesk 有维护 Arch Linux 的包，直接安装即可。

sudo pacman -S rustdesk

下面是客户端连接的效果：

两个工具的远程都还算流畅，但是有个问题暂时没有眉目，就是无法调用显卡硬件编码，所以你看到的 rustdesk 的远程是由 CPU 进行编码的串流，所以看起来有一丝不流畅，但是显卡的 3D 加速是正常的，这个问题待日后再解决吧。

4. 总结

这张 Tesla P4 的表现可以说是远超我的预期，功耗不高的同时可以解锁到几个 VM 同时调用显卡加速，以后还可以用来部署一些 AI 模型，仅 300 左右的价格能做到这么多事，可以说物超所值，兴许以后出二手还不会太掉价！哈哈，理财产品。

甲骨文免费Arm主机新玩法-云安卓手机

Wed, 06 Dec 2023 00:00:00 +0000

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.10 版本来编译redroid提供的两个内核模块的源码，最终用 amazonlinux2 的分支可已正常编译ashmem模块，然而另一个 binder 模块始终无法编译成功。

# Amadevel-uname-r == `uname -r`"
sudo make # build kernel modules
sudo make install # build and install *unsigned* kernel modules

2.3 Debian 10

于是我又想到了，Ubuntu 起源于 Debian，那倘若我将系统dd成Debian是否就可以正常加载这些内核模块了呢，于是我找到了一个手动重装的教程该教程基于网络安装，是走的官方渠道获取的系统镜像，不用担心被植入后门，这也是为什么不选择那些 一键dd脚本 的原因，缺点是只能安装 Debian 10 ，较新的 Debian 11 只能装完之后再寻求升级方法了。

比较顺利系统安装成功之后顺利登录系统，看了一下系统内核版本是 4.19 版本，还是有点老，于是从官方库升级了一下最新的稳定版内核 5.10 ，~~开始编译以上两个模块，这次很顺利编译成功了（虽然报了几个警告）~~，看了官方内核已经编译了两个内核模块，果然和 Ubuntu 20.04 以上版本一样，2个内核模块都可以加载。按照官方的教程开始运行容器：

# 加载内核模块
modprobe ashmem_linux
modprobe binder_linux devices=binder1,binder2,binder3,binder4,binder5,binder6
# 修改权限
chmod 666 /dev/binder*
chmod 666 /dev/ashmem

# 运行容器
docker run -itd --rm --privileged \
    --pull always \
    -v /dev/binder1:/dev/binder \
    -v /dev/binder2:/dev/hwbinder \
    -v /dev/binder3:/dev/vndbinder \
    -v ~/data11:/data \
    -p 5555:5555 \
    --name redroid11 \
    redroid/redroid:11.0.0-latest \
    androidboot.redroid_gpu_mode=guest

# adb 连接容器
adb connect arm-2

# scrcpy 连接
scrcpy -e

然而在 scrcpy 连接容器的时候却报了个错：

[server] ERROR: Could not create default video encoder for h264
List of video encoders:
    (none)
[server] ERROR: Exception on thread Thread[video,5,main]
java.lang.IllegalArgumentException: Failed to initialize video/avc, error 0xfffffffe (NAME_NOT_FOUND)
	at android.media.MediaCodec.native_setup(Native Method)
	at android.media.MediaCodec.<init>(MediaCodec.java:2000)
	at android.media.MediaCodec.<init>(MediaCodec.java:1978)
	at android.media.MediaCodec.createEncoderByType(MediaCodec.java:1933)
	at com.genymobile.scrcpy.ScreenEncoder.createMediaCodec(ScreenEncoder.java:229)
	at com.genymobile.scrcpy.ScreenEncoder.streamScreen(ScreenEncoder.java:73)
	at com.genymobile.scrcpy.ScreenEncoder.lambda$start$0$com-genymobile-scrcpy-ScreenEncoder(ScreenEncoder.java:294)
	at com.genymobile.scrcpy.ScreenEncoder$$ExternalSyntheticLambda0.run(Unknown Source:4)
	at java.lang.Thread.run(Thread.java:1012)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 22.3.3
INFO: Trilinear filtering enabled

scrcpy报告找不到有效的视频编码器，然而虽然甲骨文的arm主机没有给gpu资源，但是看了用cpu 编码也是可行的呀，为啥运行不了，最终在这个 Issue 下面找到了答案，那即是在编译的内核中需要启用内核 codec2 的支持，于是最终还是走到了自己编译内核这步。

2.4 自编译Debian的内核

Debian的内核源码以软件包的方式提供，我们搜索一下最新的源码包：

➜  ~ apt search ^linux-source
Sorting... Done
Full Text Search... Done
linux-source/oldstable 5.10.197-1 all
  Linux kernel source (meta-package)

linux-source-5.10/oldstable,now 5.10.197-1 all
  Linux kernel source for version 5.10 with Debian patches

可以看到最新的 5.10 的源码，安装:

sudo apt install linux-source-5.10

在用户目录中编译：

# 创建目录
mkdir ~/kernel; cd ~/kernel
# 解压内核源码
tar -xaf /usr/src/linux-source-5.10.tar.xz

至于为什么不在 /usr/src 目录中用 root 编译，官方是这么说的, 我认为非常合理：

传统上，Linux内核源代码放置于 /usr/src/linux/，需要root权限才能编译。但是，在不需要时应避免使用管理员权限。src 群组的成员也可以使用该文件夹，但是应避免使用 /usr/src/。把核心源代码置于个人文件夹时，应把安全放在第一位：在 /usr/ 内的文件都应明确其在软件包系统内的作用，试图收集内核使用的信息时，不能在读取 /usr/src/linux 时误导程序。

配置内核:

# 先将原本的内核配置保留，在原基础上修改
cp /boot/config-5.10.0-26-arm64 ~/kernel/linux-source-5.10/.config
vim ~/kernel/linux-source-5.10/.config

修改一下内容：

CONFIG_DMABUF_HEAPS=y
CONFIG_DMABUF_HEAPS_SYSTEM=y
CONFIG_ANDROID_BINDERFS=y
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"

开始编译：

make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1

开始漫长的等待，期间有可能提示缺少某个包之类的，按照提示处理一下即可，处理编译建议单线程，然后经过2天试错之后终于编译完成。安装内核：

sudo dpkg -i ../linux-image*.deb
# 重启
sudo reboot

重启之后重复 2.3 的运行步骤即可成功运行, 运行后的一下截图：

运行效果：

3. 结语

从上一张的GIF运行效果图相比大家也不难看出，这个云安卓的效率也不是很强，虽然能运行安卓应用，但是帧数很低，这是因为以下几个原因：

网络问题：

我的主机位置在韩国春川，家宽为联通，最近两边的网络延迟已经飙升到200了，还时常伴随丢包，所以操作有很大延迟，对延迟很敏感的应用肯定不适合运行。
配置问题：

我开了2台Arm，所以这台的配置为 2C12G 没有硬件加速的情况下cpu压力太大，下面是运行抖音播放视频时的资源占用截图：

容器问题：

容器在用纯CPU下仅有15Hz的刷新率，使得在源头上就不可能流畅。

总结：适合用来做一些静态应用的测试，或者一些挂机的应用，日常使用还是算了。

Oracle Linux 8 升级内核

Fri, 24 Nov 2023 00:00:00 +0000

甲骨文的免费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.0 for Oracle Linux 8 (aarch64)
ol8_MySQL80_connectors_community               MySQL 8.0 Connectors Community for Oracle Linux 8 (aarch64)
ol8_MySQL80_tools_community                    MySQL 8.0 Tools Community for Oracle Linux 8 (aarch64)
ol8_addons                                     Oracle Linux 8 Addons (aarch64)
ol8_appstream                                  Oracle Linux 8 Application Stream (aarch64)
ol8_baseos_latest                              Oracle Linux 8 BaseOS Latest (aarch64)
ol8_developer_EPEL                             Oracle Linux 8 EPEL Packages for Development (aarch64)
ol8_ksplice                                    Ksplice for Oracle Linux 8 (aarch64)
ol8_oci_included                               Oracle Software for OCI users on Oracle Linux 8 (aarch64)

没有包含Release 7的这个内核仓库，现在添加一下：

sudo yum-config-manager --add-repo http://yum.oracle.com/repo/OracleLinux/OL8/UEKR7/aarch64

检查一下是否添加成功

➜  ~ 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.0 for Oracle Linux 8 (aarch64)
ol8_MySQL80_connectors_community                  MySQL 8.0 Connectors Community for Oracle Linux 8 (aarch64)
ol8_MySQL80_tools_community                       MySQL 8.0 Tools Community for Oracle Linux 8 (aarch64)
ol8_addons                                        Oracle Linux 8 Addons (aarch64)
ol8_appstream                                     Oracle Linux 8 Application Stream (aarch64)
ol8_baseos_latest                                 Oracle Linux 8 BaseOS Latest (aarch64)
ol8_developer_EPEL                                Oracle Linux 8 EPEL Packages for Development (aarch64)
ol8_ksplice                                       Ksplice for Oracle Linux 8 (aarch64)
ol8_oci_included                                  Oracle Software for OCI users on Oracle Linux 8 (aarch64)
yum.oracle.com_repo_OracleLinux_OL8_UEKR7_aarch64 created by dnf config-manager from http://yum.oracle.com/repo/OracleLinux/OL8/UEKR7/aarch64

最后再更新一下:

sudo yum update

可已查看到将要更新的包了，同时 yum 会自动移除旧的内核，这里是同时升级仓库中所有已安装的包版本，如果只想升级内核可以使用 sudo yum update kernel\*

最后重启一下

reboot

3. 验证内核安装

➜  ~ uname -r
5.15.0-200.131.27.el8uek.aarch64

新的内核已经安装成功！

一次防火墙纠错，让我更了解防火墙机制

Tue, 07 Nov 2023 00:00:00 +0000

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.168.200.2.61048 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
10:28:50.654392 IP 192.168.200.2.61048 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
10:28:51.655551 IP 192.168.200.2.61048 > {my-home-ip}.25379: Flags [R], seq 0, win 65535, length 0

IP 192.168.200.2 一直在向服务端发送 SYN 握手包，而服务端是没有响应任何内容的，这明显可以看出这个包是没办法送达的，因为 192.168.200.2 这个地址属于 phantun_client 创建的tun设备的地址，是没有互联网访问能力的，所以我们需要将该接口的包转发至具有互联网访问能力的接口，通俗的讲就是 lan 口，首先确认内核开启了 IP 转发：

sudo sysctl -a | grep ip.forward

net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

看到 net.ipv4.ip_forward = 1 的值为1已经开启了IP转发，如若不是需开启ip转发，开启ipv4的IP转发即可：

sudo sysctl -w net.ipv4.ip_forward=1

启用源地址转换：

sudo iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE

这里 ens160 是我可以访问互联网的接口，这里指的是对 nat 表的 POSTROUTING 链添加一条规则，对出口接口为 ens160 的所有流量执行 MASQUERADE 操作，MASQUERADE 是源地址转换（SNAT）的一种实现，通过这样的操作即可实现局域网内的地址可转换为ens160的地址进行互联网访问，从而使得 phantun_client 的流量包能成功发出。

2.3 还是不行？

再看看看日志：

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
11:09:26.356501 IP 192.168.200.2.5320 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
11:09:27.357822 IP 192.168.200.2.5320 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
11:09:28.358988 IP 192.168.200.2.5320 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
11:09:29.360160 IP 192.168.200.2.5320 > {my-home-ip}.25379: Flags [R], seq 0, win 65535, length 0

额。。。看样子我们并没有成功，日志还是和之前没有区别，这难道是分析有误？我不禁开始怀疑自己的水平，还是那么菜。然而消沉并没有用，问题还要解决，是时候祭出天书了，翻遍了我的书籍找到了下面这张图(鸟哥的Linux私房菜)：可以看到 wireguard 的握手包是需要发出之前是需要经过 FORWARD 链的，那会不会是被这条路阻了呢，查看 iptables 详情：

sudo iptables -L -v -n

果然，FORWARD 链默认策略是 DROP，正是这个地方阻止了流量包，调整 FORWARD 链默认策略：

sudo iptables -P FORWARD ACCEPT

再来看抓包日志：

13:52:54.939793 IP 192.168.200.2.11968 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
13:52:54.939857 IP 10.1.1.137.11968 > {my-home-ip}.25379: Flags [S], seq 0, win 65535, options [nop,wscale 14], length 0
13:52:54.949558 IP{my-home-ip}.25379 > 10.1.1.137.11968: Flags [S.], seq 0, ack 1, win 65535, options [mss 536,nop,wscale 14], length 0
13:52:54.949585 IP {my-home-ip}.25379 > 192.168.200.2.11968: Flags [S.], seq 0, ack 1, win 65535, options [mss 536,nop,wscale 14], length 0
13:52:54.949644 IP 192.168.200.2.11968 > {my-home-ip}.25379: Flags [.], ack 1, win 65535, length 0
13:52:54.949658 IP 10.1.1.137.11968 > {my-home-ip}.25379: Flags [.], ack 1, win 65535, length 0

可以看到握手包正常发出和接收了，再看 wireguard 状态：

通过 phantun 伪装的 wireguard 也连接成功，至此问题解决。

2.4 保存规则

至此就完结了吗，并没有，我们以上设置的 iptables 规则并不是永久的，重启之后之前设置的规则都会重置，事实上之所有有此次问题正是因为我之前设置好的 iptables 规则没有保存，无法开机自动应用规则导致的此次事件，下面我们就来保存规则：

安装 iptables-persistent 包

sudo apt install iptables-persistent

保存规则：

sudo iptables-save | sudo tee /etc/iptables/rules.v4

这样重启之后规则自会自动应用了

拯救你的idea,解决ubuntu下idea字体发虚

Fri, 03 May 2019 22:36:15 +0000

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 选择一张背景图设置透明度编辑界面主题选择一张亮色的主题，字体不变

成果

完成以上设置之后来看看成果字体看起来平滑多了，好了，安心编码吧 :)

Linux on Linkzz's Blog

简单记录一下 Docker 容器中信任一个自签名证书的案例

1. 背景

2. 信任证书

2.1 确认证书类型

2.2 宿主机信任证书

2.3 映射到容器证书目录

3. 总结

Docker 环境下的 qBittorrent 容器迁移至 lxc 保留配置

1. 背景

2. 迁移

2.1 创建容器

2.2 设置容器

2.3 迁移配置 qbittorrent-nox

2.4 下载数据迁移

3. 结语

pve 宿主机挂载虚拟机磁盘镜像

1. 背景

2. Raw

2.1 挂载

2.2 卸载

3. Qcow2

3.1 挂载

3.2 卸载

4. 结语

记一次 Moonlight 10054 错误的解决经历

1. 起因

2. 环境

2.1 串流设置

3. 排查

4. 解决问题

Tesla P4 - Nvidia 专业卡 vGPU 解决方案体验

1. 前言

2. 硬件

3. 软件

3.1 宿主机设置

3.2 系列解读

3.3 Windows客户机

3.3.1 Widnows vGPU 驱动

3.3.2 vGPU 授权

3.3.3 远程方案

3.4 Linux 客户机

3.4.1 Linux 驱动

3.4.2 Linux 授权

3.4.3 CUDA Toolkit

3.4.4 桌面环境

4. 总结

甲骨文免费Arm主机新玩法-云安卓手机

1. 前言

2. 加载内核模块 ashmem_linux、binder_linux

2.1 基于 Ubuntu 20.04 以上发行版

2.2 Oracle Linux 8

2.3 Debian 10

2.4 自编译Debian的内核

3. 结语

Oracle Linux 8 升级内核

1. 查看已经安装的内核包

2. 安装内核

3. 验证内核安装

一次防火墙纠错，让我更了解防火墙机制

1. 起因

2. 排查

2.1 报错日志

2.2 抓包分析

2.3 还是不行？

2.4 保存规则

拯救你的idea,解决ubuntu下idea字体发虚

idea在ubuntu下的字体表现

idea环境

更换系统主题

成果

2.1 基于 `Ubuntu 20.04` 以上发行版