刚刚好:我的 Atlas Canyon NUC 与低配 "Homelab"

看别人的 Homelab 馋啊,空有需求但没有好的硬件,就买了个 Intel NUC11ATKC4,四核赛扬 N5105 CPU,代号 Atlas Canyon(阿特拉斯峡谷)。有人可能会问,就这么个破赛扬能干啥啊?其实只要摆脱坑比 Windows,能干的事情多着呢。

不过我承认,标题确实是我临时起的,之后性能余量是否够用,那就是以后的事情了。

开箱

NUC 嘛大家都懂,买回来就是个准系统,没有硬盘没有内存,更别提操作系统了。硬盘买的是血统纯正的国产货,致态(钛)TiPlus 5000 512G,内存则是笔记本换下来的海力士 8G*2。这里吹一波东哥的售后啊,硬盘买回来外包装破了,直接进行了一个上门换新,不到 24 小时搞定。

盒子是一个简洁的纸壳盒子,结合包着每一个部件的塑料袋来看,很难说它是环保还是不环保。包装盒中含有主机、不用看系列(还真得看)、分体式的电源,以及一个灵魂 Celeron Inside logo。

外包装

电源来自航嘉,约 65W 功率,三脚插头,考虑到主要部件的功率,余量留得很足。可惜没有做成 PD 充电。

拆装的话需要拧开底下的四个角的螺丝,这之后就可以直接揭开后盖。

底部

前面板接口有两个 USB 3.0 5Gbps,一个 8 针的工控用途 IO,耳机和麦克风各一个;后面板有惊人的两个 USB 3.1 10Gbps、两个 USB 2.0、一个千兆网口、一个 RJ45、一个 HDMI、一个 DP,以及一个供电用的 DC 圆口。这个接口量是超出我预期的,但美中不足的是没有 USB-C。只有一个网口,注定了它不能当作通常的软路由。反正我不是拿来当路由器的,不管它。

背部

卸下底部盖板后就可以看到内部,排列还是比较紧凑的。如图是装好硬盘和内存的样子,网卡是很令人惊喜的 AX201,支持 WiFi 6,被盖在硬盘下面。

内部结构

底盖是金属材质,SSD 位置有导热贴。其他地方的导热贴贴得似乎比较散乱。两边具有散热孔,方便空气流通;而散热模组在机身上部。

操作系统与 BIOS

使用 archinstall 脚本,安装了 Arch Linux。其实在它的加持下,Arch 的安装没有那么难了,也不再需要一点一点的配置,顶多就是 TUI 界面看起来不太友好。

  • 为什么不是 Windows?我可不想让这赛扬整天满载;

  • 为什么不是 TrueNAS?我不会用 FreeBSD;

  • 为什么不是 Unraid?要钱,也对 Slackware 不熟悉;

  • 为什么没有虚拟化(ESXi 之类的)?据传 N5105 跑虚拟化有点问题;

  • 为什么是 Arch Linux?更新快,Wiki 完善,较为轻量,AUR。

装了个 GNOME 桌面环境,不光是因为有领先的 Wayland 支持,而且还有一个原因我们后面会提到。虽然 I 家驱动做得烂,但也不再有 NVIDIA 独显那样烂泥扶不上墙的问题。

BIOS 的设置非常丰富,能够自由调整 CPU 温度墙、PL1/PL2 功耗、风扇转速各方面阈值,也可以自由开关各种接口,可玩性很强。

主页

散热控制

性能释放

性能

也不要有什么过高的期望了,N5105 只有四个低功耗 Jasper Lake 核心,总 TDP 才 15W,满载还没一颗骁龙 8 Gen 1 功耗高。但过热应该非常难出现,毕竟就这点功耗还有主动散热加持。事实证明我的猜想是对的,BIOS 风扇设置为 cool 档之后,烤机 CPU 温度维持在 65 度,也比骁龙 8 凉(狗头)。

烤机占用

Geekbench 5 CPU 跑分为单核 699、多核 2286(详见 测试记录);Geekbench 6 单核 557,多核 1646(记录);Vulkan Compute 跑分为 2313(详见 测试记录)。

使用 Firefox 观看 4K YouTube 视频,接 2K 显示器,略有卡顿。2K 分辨率的 CS 能够流畅运行。平常浏览网页等用途则完全未感受到卡顿。

可能由于本身机能限制或文件系统限制,其实是无法完全发挥这块硬盘性能的,标称读 3500 写 2700,在 Btrfs 文件系统下,实际上只能做到读写 1700 左右。

综合硬盘性能,不能代表硬盘水平

在 KDiskMark 中,跑出了一个更慢的成绩。

KDiskMark 成绩,不能代表硬盘水平

内存只能跑在 2933MHz,应该对核显性能有一定程度的影响,不过核显本来就很菜,无所谓了。

互联

网络

要从外网访问内网中的主机,内网穿透是一个很经典的方案,但这需要一台带宽够高、延迟够低、流量足够多的服务器,这在国内成本比较高,将内网服务暴露到外网也让所有人可以访问,有些危险。虚拟局域网方案顾名思义,将在不同内网下的电脑划在同一个 “局域网” 里。在这其中,Tailscale 算是体验最好的之一了。NAT 打洞成功率较高,这意味着大部分时候可以以直连的延迟与带宽在不同设备之间连接。

tailscale/tailscale

Tailscale 的配置非常简单,按照指引配置即可,用起来就知道有多爽了。目前用起来缺点很少,就是不能为同一个机器分配多个域名并签发多个 HTTPS 证书,极限网速也比不了直连(并不是因为性能开销过大,表现见下)。某种程度上,就是这种异地组网程序让下面的许多用途从” 可能” 变为 “好用”。

其他的方案还有 n2n、Netmaker 和 ZeroTier 等,在此不做介绍。

桌面

这样一来桌子上就有两台电脑、两台手机、一台平板了,但外接屏幕只有一块,键鼠也只有一套,笔记本和 NUC 打架是自然而然的事情。

关于这种情况,开源社区已经有多种解决方案,主要分为键鼠漫游和远程桌面两种。

键鼠漫游当然是理想中体验最好的解决方案。NUC 接外部显示器,跑 Linux 程序;笔记本用内置屏幕,跑 Windows 程序。一套键鼠插在某一台设备上,用一个鼠标控制两台设备的桌面。成熟的方案有很多,但统统被我毙掉了,分别由于以下几个理由:

  • Mouse Without Borders,仅支持 Windows;

  • Synergy/Barrier,不支持 Wayland;

  • Waynergy(Synergy 的 Wayland fork),不支持 GNOME 自带 compositor;

  • rkvm,不支持 Windows。

幸好 GNOME 42 为我留了另一条路,远程桌面。我得以在 NUC 上开一个远程桌面服务端,然后在 Windows 下连接。说起来体验还可以,起码日常使用还是够了的。窗口可以全屏,让 Linux 的桌面铺满整个显示器,局域网内视觉体验非常接近直连;我也可以将远程桌面窗口最小化,从而 Windows 应用(如游戏)也可以使用大尺寸显示器。

我也试过使用 Remmina 连接 Windows 的远程桌面,但结果就是卡顿极其严重,清晰度也很差。当然也可以使用 RustDesk 或 Parsec 等其他远程桌面协议,倒也挺好用。

远程桌面

这里推荐一个 GNOME 插件:Allow Locked Remote Desktop,让锁屏时也可以连接远程桌面,就像 Windows 那样。

而一旦出现了不方便接显示器的情况,可以使用如下的命令启动一个 headless session(来自 Reddit):

bash
1
2
3
echo -n "user_password" | /usr/bin/gnome-keyring-daemon --unlock
systemctl --user restart gnome-remote-desktop.service
gnome-shell --wayland --headless --virtual-monitor 1280x720 --no-x11

不过问题在于此时 GNOME 远程桌面连不上。据传,可以使用以下的命令将远程桌面模式设为” 扩展 “,这样它会为你创建一个虚拟显示器(来自 RedditGNOME GitLab):

bash
1
gsettings set org.gnome.desktop.remote-desktop.rdp screen-share-mode extend

当不需要用桌面的时候,就用 SSH。尤其是出门后,网络条件难以支持远程桌面,SSH 就显得比较好用了。SSH 比较好配置,此处省略。

文件互传

KDE Connect 完全可以称为最好的跨平台互联工具,通吃所有常见桌面端与移动端环境。GNOME 桌面环境上,可以使用 GSConnect 插件。

文件共享

要将文件暴露到网络上,协议还是很多的。对于公网,一个 Web UI+WebDAV 会很方便;而在内网中,可以选择 SMB。这里与前面 KDE Connect 的区别,则在于前者是 “拉”,而后者是 “推”。

Caddy 带一个文件服务器 Web UI+WebDAV 的功能,但死活没配好,就让它等着做反代吧。作为替代的,我使用了 AList。AUR 有 alist 包,可以直接配好 systemd 服务和配置文件。但在新的 AUR package 中,alist 会作为单独的用户运行,对于共享家目录等需要大规模更改权限的场景则不是非常方便。

alist-org/alist

我是 Cloudreve 的老用户了,它是非常优秀的网盘程序,而它会重新组织上传的文件;相反,AList 能够忠实地将系统文件目录结构呈现出来,既方便远程访问,又方便本地访问。这就是它叫做 “目录程序” 的原因。它也自带一个 WebDAV 服务端,很方便。

AList

通过 AList+Tailscale 下载大文件,约能跑到 160Mbps 左右;通过内网直连下载,则能够达到 720Mbps(路由器硬件所限,非 WiFi 6),不管怎样看 4K HDR 是没有什么压力的,也能喂饱我的百兆小水管外网。


这玩意速度还是有点玄学的,那相较于带加密的 WebDAV,不如直接上 SMB,负担小,对 Windows 的支持也更好。Linux 上 SMB 支持主要由 Samba 软件包提供。

SMB 的配置方法由 ChatGPT 生成。

安装就不用说了。先创建一个 SMB 账户,这里图省事,个人会直接用 Linux 账户。跟 passwd 差不多用法。

bash
1
sudo smbpasswd -a <account_name>

然后编辑配置文件,路径位于 /etc/samba/smb.conf。你可以选择去 下载官方模板,但实际上只需要以下的部分:

ini
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[global]
    workgroup = WORKGROUP
    security = user

[homes]
    comment = Home Directories
    browseable = no
    read only = no
    create mask = 0700
    directory mask = 0700
    valid users = %S

如果你使用了模板,没连打印机的话,记得把打印机注释掉。

然后把服务启动一下。

bash
1
sudo systemctl enable --now smb.service

然后在 Windows 添加 \\<machine-ip>\homes 就能访问了。

那有了这些空间,干点什么呢?比如存个手机备份,这不比某些厂商的 USB 2.0 体验好多了嘛,不一定比无线快,还得时刻连根线。

XayahSuSuSu/Android-DataBackup

笔记

在 Notion-like 的软件中,思源笔记拥有较好的 Markdown 支持,用起来较为舒服,也有自行托管选项(浏览器端),唯一的缺点是 Firefox 支持较差(可惜由于精力原因,开发者 不一定会修)。

siyuan-note/siyuan

思源笔记

使用 Podman rootless container + Quadlet,编写 container 文件如下:

properties
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[Unit]
Description=Siyuan Notes container

[Container]
Image=docker.io/b3log/siyuan
ContainerName=siyuan
User=1000
Group=1000
PublishPort=6806:6806
Volume=siyuan:/siyuan/workspace
Exec="--workspace=/siyuan/workspace/" "--accessAuthCode=<your-auth-code>"
AutoUpdate=registry

此处使用 volume 而非本机目录,是因为尝试过多次本机目录,在权限设置应该没什么问题的情况下,容器仍无权限创建文件,使用 volume 则没有这个问题。确实没之前那么方便,但毕竟都是挂载到本地的,也差不太多。

服务的快捷访问

本文早些时候使用了互联网上的常用方式——域名来指代服务,并使用 Caddy 自动进行 HTTPS 加密和多路复用。将域名指向对应主机,因为指向的 IP 都是 Tailnet 中的保留 IP,所以实际上也没什么问题。但是由于主机间连接使用的 Wireguard 本身就带有加密,所以 HTTPS 完全没有必要。如果读者愿意阅读之前的方法,可以点击下方的折叠菜单将其展开。

以前的方法:使用 Caddy+自签证书 HTTPS

到此为止,搭建的服务都是用 IP 地址 + 端口号访问,不太优雅。虽然 Tailscale 提供了 MagicDNS,但也只能为每个设备分配一个域名。既然上有一个自己的域名,就想到配合 Caddy 访问内部服务。

就以上面的 AList 举例,先在 DNS 中将 alist.internal.cyp0633.icu(仅作示例,你当然用这个访问不到)指向 NUC 的 Tailscale IP,然后 Caddyfile 可以这么填写:

text
1
2
3
4
alist.internal.cyp0633.icu {
    reverse_proxy :5244
    tls internal
}

然后 Caddy 就可以搞定反向代理,甚至包括自签名的 HTTPS 证书。第三行是必不可少的,因为. icu 是公认的 TLD,Caddy 会尝试向公网 CA 申请一个证书,它当然不能接入 Tailscale 局域网;显式指定 tls internal 之后,Caddy 才会自行签名一个证书(见 官方论坛帖子)。这样,便可以访问这个域名来获取服务,无需记住端口号,就像是在平常的服务器上一样。类似的,也可以这样配置多个域名指向同一 IP,来让 Caddy 做分流。

思源笔记有 WebSocket 部分,但不需要特别设置。

针对上面 Tailscale 的速度问题,如果想在内网下达到更快的传输速度,可以在路由器上将域名解析至内网 IP,而非 Tailscale IP。这样在内网下就可以直连,无需通过 Tailscale。

Tailscale 开发了一个小工具叫做 golink,能够将 <go/linkname> 重定向至一个自定义的网址,类似于前些年流行的短网址服务。其配置起来并不麻烦,所以个人建议直接用 systemd 管理。先用 go install 安装,然后创建一个systemd user unit,需要的话可以参考我的配置文件。

properties
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[Unit]
Description=Golink service

[Service]
Type=simple
ExecStart=/home/<username>/go/bin/golink --sqlitedb /home/<username>/.config/tsnet-golink/data.db
Environment="TS_AUTHKEY=tskey-auth-yourkey"
Restart=on-failure

[Install]
WantedBy=default.target

用浏览器访问 http://go/,新建映射即可以和老方法一样简单易懂的名字访问内部服务。比如我将 go/siyuan 映射到 http://nuc:6806,就可以直接访问思源笔记了。

* 在制定短链接映射时,个人不建议使用形如上文 nuc 的主机名代替 Tailscale IP 地址,因为部分工具不能正确将其识别为内网服务,从而禁用某些功能。比如 Bitwarden 浏览器插件,就会禁用 HTTP 下的自动填充功能,除非访问的是保留 IP。通过跳转到对应 IP 而非主机名,可以启用其自动填充功能。

远程下载

有了这个,就可以远程下片了(逃)。算是用了一种经典方案吧,aria2。pacman 就有打包。

配置文件 aria2.conf 可以参考 P3TERX 的配置文件,但 注意不要照搬,先读完,再使用。

P3TERX/aria2.conf

如果要让 aria2 在后台运行,可以使用 systemd 服务,在 / etc/systemd/system 中编辑 aria2cd.service(改编自 Arch Wiki),然后启用即可:

properties
1
2
3
4
5
6
7
8
9
[Unit]
Description=aria2 Daemon

[Service]
Type=simple
ExecStart=/usr/bin/aria2c --conf-path = 你的配置文件路径

[Install]
WantedBy=default.target

至于 Web 界面,我使用了 AriaNG,也是经典的解决方案。使用 Caddy 反代一下就行了。在 Caddyfile 里限制了 HTTP,否则必须一起反代 HTTPS 的 Aria2 JSON-RPC。

mayswind/AriaNG

开发

只要提到远程开发,必定少不了神通广大的 VS Code。之前写过文章的第三方的 code-server 仍然可用,而且是一个完全开源的版本(基于 code-oss),感兴趣的可以看一下 GitHub 页面,讲得很详细(我写的太久没更新,不推荐阅读)。

coder/code-server

此处要讲的是另外一种途径,来自微软的 VS Code Server,这意味着它可以使用 Copilot 等必须在微软发行的版本才能使用的插件。这项功能已经进入公测,并包含在所有 1.74.0 或更新的 VS Code 版本中。可以使用 vscode.dev 网页或现成的 VS Code 客户端连接,即使不在同一局域网下也可。具体的启用方法可以见 这篇 blog post,但长话短说,就是使用 code tunnel 命令。另附内测时期的开启方法如下:

内测时的 VS Code Server 启用方法

VS Code Server 在内测,通过后就可以在 vscode.dev 里直接连接开发机器了,但我并没有通过内测。很幸运的是微软提供了一种不需资格的运行方式,只需加上 --serve-local 参数,就可以在本地机器浏览器中运行, 再加一个反代,就可以让 Tailscale 内网中的远程机器连接了。
需要注意:VS Code Server 不是开源 / 自由软件,有自己的协议。将 VS Code Server 暴露到公网上是违反许可协议的。
同样的,也建议创建一个 sysetmd 服务来保持其后台运行。

两个方法都占用很大,占用内存可能达到 2G 左右,CPU 负载也很高,因为所有 language server 的 parsing 等操作都是在这台 NUC 上进行的。但不管是上述两种方法中的哪一种,都可以在平板上码代码了,并且得到很舒服的延迟与比我自己公网上服务器高得多的性能。

iPad 上 VS Code Server 效果

照片

请见:

https://cyp0633.icu/archives/2093

数据保护

如果你使用的也是 Btrfs 文件系统,且对数据安全没有那么高的要求,那么可以参考这篇文章。

https://cyp0633.icu/archives/2120

此篇文章首个版本约有四分之三通过 NUC 的远程桌面写成。它作为没那么多预算的我买的入门 Homelab,经过这一段时间的使用,已经证明了能够胜任目前的需求,性价比目前看还算不错。

许可证:CC BY-SA 4.0
最后更新于 Dec 28, 2023 22:03 +0800