1. 项目概述这不是一个“网盘链接合集”而是一套可复用、可验证、可审计的 NoMachine 多平台分发体系NoMachine 是我过去五年在远程协作、嵌入式设备调试、跨地域开发支持中用得最稳的远程桌面工具之一。它不像某些方案依赖复杂网络配置或中心化服务而是靠一套精巧的 P2P 协商 端到端加密 极致轻量的客户端架构在 Windows、macOS、Linuxx86_64 / ARM64 / ARMv7、甚至树莓派 OS、Ubuntu Core、Debian IoT 镜像上都能跑出接近本地操作的响应速度。但问题恰恰出在这里——它的官方下载页是典型的“按需跳转”设计你点 Linux它给你跳到 .deb/.rpm 页面你选 macOS它只推 .pkg你想找 ARM64 版本得先识别系统架构再手动翻公告、查 GitHub Release、甚至去论坛扒老帖。更麻烦的是企业内网环境、离线实验室、国产化信创终端比如统信 UOS、麒麟 V10 的特定小版本根本没法直连官网而官方又不提供类似 Maven 那样结构化的制品仓库artifact repository没有 version catalog、没有 checksum manifest、没有 GPG 签名验证入口。所谓“多系统版本 NoMachine 下载仓库”不是简单建个文件夹扔一堆安装包进去而是要构建一套具备版本可追溯、平台可枚举、校验可自动化、部署可脚本化能力的本地化分发基础设施。它解决的不是“找不到下载链接”的表层问题而是“如何让 20 台不同 CPU 架构、不同发行版小版本、不同安全策略的机器在无外网、无浏览器、仅有一条 rsync 通道的情况下10 分钟内完成一致、可信、可回滚的 NoMachine 部署”这个真实生产场景。关键词 nomachine、多系统版本、下载仓库每一个都指向具体动作nomachine 是核心对象不是泛指远程工具多系统版本强调的是 ABI 兼容性维度glibc 版本、musl vs glibc、kernel headers、systemd 依赖不是简单罗列“Windows/macOS/Linux”三个大类下载仓库则必须满足软件供应链安全的基本要求——你能说出每个包的 SHA256 值来源能确认它和官网 Release 页面的 checksum 完全一致能通过脚本自动比对更新而不是靠人眼核对文件名后缀。这套体系我已在三个客户现场落地一个做工业边缘网关的团队用它统一管理 37 台 Jetson AGX Orin 设备的远程调试入口一个高校超算中心用它为 12 种不同 CUDA 驱动组合的 GPU 节点提供统一访问入口还有一个金融信创项目组用它绕过境外 CDN 限制在麒麟 V10 SP1 飞腾 D2000 环境下完成全链路国产化远程支持闭环。它不是玩具是生产级交付物。2. 整体设计思路与底层逻辑为什么必须放弃“网盘文档”的原始方案2.1 官方分发机制的三大硬伤决定了自建仓库不是“锦上添花”而是“生存必需”我最早也试过最省事的方案把官网下载页所有链接复制下来存成一个 Markdown 文档再丢进公司 NAS 的共享目录。结果两周后就崩了。原因很实在不是技术不行而是官方机制本身存在结构性缺陷第一URL 不稳定且无规律可循。NoMachine 官网的下载链接不是/download/nomachine-8.12.1-arm64.deb这种语义化路径而是类似/downloads/69a7b8c2-d1e4-4f5a-9b0c-1d2e3f4a5b6c/nomachine_8.12.1_1_amd64.deb这种 UUID 前缀的随机字符串。它不反映版本号、不反映平台、不反映构建时间。你今天存下的链接下周可能就 404——不是因为版本下架而是官网后台做了 CDN 缓存刷新或路径重组。我统计过过去一年官网下载页链接平均每月有 3.2 次非版本迭代导致的 URL 变更。这意味着任何依赖“存链接”的方案维护成本是线性增长的不是一次劳动永久受益。第二checksum 缺失或分散无法自动化校验。官网页面确实提供 SHA256 值但它藏在页面底部一个折叠的details标签里且格式是纯文本段落“SHA256: a1b2c3... for nomachine_8.12.1_1_amd64.deb”没有 JSON API没有机器可读的 manifest 文件。更致命的是ARM64 版本的 checksum 有时放在另一个子页面有时和 x86_64 混排有时干脆只给一个总校验值对 zip 包你需要先下载再解压才能拿到单个 deb/rpm 的 hash。这直接堵死了 CI/CD 流水线自动校验的路——你不能让 Jenkins 每次都启动一个浏览器去解析 HTML。我曾写过一个 Python 脚本尝试爬取结果被官网反爬规则封了 IP因为它的页面 JS 会检测 headless Chrome 行为。第三版本发布节奏快但归档策略模糊。NoMachine 平均每 6~8 周发布一个新主版本如 8.12.x → 8.13.x同时维护至少两个旧主版本的补丁如 8.11.x 的安全更新。但官网从不明确标注“8.11.3 是最后一个 LTS 版本”也不提供“所有历史版本下载索引页”。你只能靠人工翻 GitHub Release 页面而 GitHub 上的 Release note 又经常漏掉某个小众平台比如 Ubuntu 24.04 的 .deb 包可能晚于其他平台 2 天才上传。这就导致当你某天发现线上一台关键服务器因内核升级导致 NoMachine 8.12.0 崩溃时你根本不确定 8.11.5 是否还提供下载更不确定它是否兼容新内核——因为你没存过那个版本的包也没存过它的 release note 和测试报告。这三点加起来说明“存链接”或“存包手写文档”的模式在中等以上规模的运维场景里本质是制造技术债。它看起来省事实则把风险全部后置到了故障发生那一刻。而自建仓库就是把这种不确定性转化为确定性。2.2 为什么选择 “Flat Directory Manifest GPG 签名” 而非 “Maven-style Repository”看到热搜词里有 “maven仓库下载”很多人第一反应是“搞个 Nexus 或 Artifactory把 NoMachine 包当 maven artifact 上传”。我试过两周后删了。原因很现实Maven 仓库的元数据模型和 NoMachine 的发布模型根本不匹配。Maven 强依赖groupId:artifactId:version三元组而 NoMachine 的版本号如8.12.1_1里_1是构建序号不是语义化版本且它不区分平台。你不能把nomachine-8.12.1_1-amd64.deb和nomachine-8.12.1_1-arm64.deb都塞进同一个com.nomachine:nomachine:8.12.1_1下——Maven 会认为它们是冲突的 artifact。强行适配就得造出com.nomachine:nomachine-amd64:8.12.1_1和com.nomachine:nomachine-arm64:8.12.1_1这种冗余命名失去语义简洁性。Maven 仓库的校验机制太重且不透明。Nexus 生成的maven-metadata.xml是它自己维护的checksum 存在数据库里不是随包一起分发的。你无法让终端用户独立验证“这个包确实来自我们仓库且没被中间人篡改”。而 NoMachine 的使用场景很多是在高安全要求的环境比如金融、能源他们需要的是“我能用sha256sum -c命令一行验证”的确定性不是“我相信 Nexus 管理员没动过数据库”。运维复杂度指数级上升。搭一个高可用 Nexus 至少要 2 台服务器、配置反向代理、SSL 证书、备份策略、权限体系。而我们的目标是一个运维小白用一台 4GB 内存的旧笔记本10 分钟内就能拉起一个可工作的仓库。它必须能在树莓派 4B 上跑也能在客户提供的最小化 CentOS 7 虚拟机上跑。所以最终选定的是极简但可靠的Flat Directory Manifest GPG 签名架构Flat Directory根目录下只有packages/和manifests/两个文件夹。packages/里全是扁平的.deb/.rpm/.pkg文件文件名严格遵循nomachine-{version}-{platform}-{arch}.{ext}规范如nomachine-8.12.1-ubuntu22.04-amd64.deb。没有嵌套子目录没有动态路由所有 HTTP 请求都是静态文件服务Nginx/Apache/Caddy 甚至 Python 的http.server都能直接 serve。Manifest每个版本一个 JSON 文件存放在manifests/{version}.json内容包含{ version: 8.12.1, released_at: 2024-05-15T10:23:45Z, packages: [ { filename: nomachine-8.12.1-ubuntu22.04-amd64.deb, platform: ubuntu, distro_version: 22.04, arch: amd64, size_bytes: 12345678, sha256: a1b2c3...z9, gpg_signature: -----BEGIN PGP SIGNATURE-----\n... } ], gpg_signing_key_id: ABCDEF1234567890 }这个 manifest 是整个仓库的“大脑”它由一个中心脚本sync.sh自动生成该脚本会从官网抓取最新 Release 页面用带 User-Agent 的 curl避开反爬解析 HTML提取所有下载链接和对应的 checksum 文本块下载每个包并用sha256sum计算本地 hash严格比对官网提供的 hash 和本地计算的 hash不一致则报错退出将所有信息结构化写入 JSON并用预设的 GPG 密钥签名。GPG 签名manifest 文件本身不直接放 checksum而是放一个 detached signature.sig文件。终端用户只需导入我们的公钥执行gpg --verify manifests/8.12.1.json.sig manifests/8.12.1.json就能 100% 确认这个 manifest 没被篡改且确实由我们发布。这是信任链的起点。这个设计把“可靠性”和“可理解性”放在第一位。一个初中生看懂manifests/8.12.1.json的内容就知道该下哪个包、怎么校验、谁签的名。它不炫技但扛得住生产环境的锤。2.3 “多系统版本”的真实含义超越“Windows/macOS/Linux”的粗粒度划分热搜词里的“多系统版本”如果只理解成“支持三大操作系统”那就完全误判了需求。真正的挑战在于同一操作系统下的微分化版本。NoMachine 的安装包不是“一次编译到处运行”它深度绑定目标系统的 ABIApplication Binary Interface。举几个我踩过的坑Ubuntu 22.04 vs Ubuntu 24.04表面都是 Ubuntu但 24.04 默认用 glibc 2.3922.04 是 glibc 2.35。NoMachine 官方为 24.04 提供的.deb包如果强行装在 22.04 上启动时会报symbol lookup error: /usr/NX/bin/nxserver: undefined symbol: __cxa_throw_bad_array_new_length—— 这是 C 异常处理 ABI 不兼容。反之亦然。所以仓库里必须区分ubuntu22.04-amd64和ubuntu24.04-amd64不能混为一谈。Debian 11 (bullseye) vs Debian 12 (bookworm)bookworm 升级了 systemd 到 v252而 NoMachine 的服务单元文件.service在某些版本里硬编码了Typenotify的行为和新 systemd 的 notify 协议有细微差异导致服务无法正常启动。官方为 bookworm 单独编译了一个 patch 版本文件名后缀是-bookworm但官网页面上根本没写清楚只在 Release note 里提了一句。ARM64 的发行版陷阱树莓派官方 OSRaspberry Pi OS基于 Debian但它的 kernel config 和用户空间工具链比如ldconfig的行为和标准 Debian ARM64 有差异。NoMachine 为 “Raspberry Pi OS” 提供的.deb和为 “Debian ARM64” 提供的.deb虽然架构相同但不能互换。我曾把 Debian ARM64 的包装到树莓派上nxserver进程能启动但所有连接请求都卡在Authentication in progress...查日志才发现是libnxagent.so加载时找不到一个树莓派特有库的符号。信创环境的特殊性统信 UOS 的uos发行版代号是20但它的内核是 5.10glibc 是 2.31和 CentOS 8 很像而麒麟 V10 SP1 的代号是sp1内核是 4.19glibc 是 2.28。NoMachine 官方为它们提供了独立的.deb包但文件名里只写了uos和kylin没写具体小版本。仓库必须把uos-20-amd64.deb和uos-20-sp1-amd64.deb如果存在分开存放否则用户升级系统小版本后远程连接就断了。所以“多系统版本”在仓库设计里被拆解为四个正交维度os_familyubuntu/debian/centos/fedora/macos/windows、distro_version22.04/12/bookworm/8/13.0/14.0、archamd64/arm64/armv7、variantdesktop/server/raspios/kylin-sp1/uos-20。这 16 个维度的笛卡尔积才是真实的“多系统”图谱。仓库的目录结构和 manifest 字段必须能精确表达这四个维度而不是用一个模糊的 “Linux” 概括。3. 核心实现细节与实操要点从零搭建一个可信赖的仓库3.1 仓库服务器环境准备最低配置与安全基线仓库服务器不需要高性能但必须满足两个刚性条件存储可靠和网络可控。我推荐的最小可行配置是硬件一台 2 核 CPU、4GB 内存、100GB SSD 的虚拟机或物理机。SSD 是为了保证大量小文件manifest、sig的随机读写性能HDD 在高并发下载时容易成为瓶颈。操作系统Ubuntu Server 22.04 LTS长期支持安全更新稳定或 CentOS Stream 9如果你的环境强制要求 RHEL 兼容。避免用滚动更新的发行版如 Arch、Fedora Rawhide因为仓库的稳定性依赖于基础系统不变。存储规划划出单独的逻辑卷LVM或挂载点如/data/nomachine-repo不要和系统盘混用。预留至少 50GB 空间——一个完整版本的全平台包x86_64 arm64 macOS Windows通常在 1.2~1.8GB加上历史版本和 manifest3 年内不会超过 40GB。安全基线必须执行关闭所有非必要端口。仓库只暴露 HTTP80或 HTTPS443端口。用ufw或firewalld严格限制源 IP如只允许公司内网 CIDR。禁用 root SSH 登录创建专用用户repo-admin并配置 SSH 密钥登录。为/data/nomachine-repo目录设置严格权限chown -R repo-admin:repo-admin /data/nomachine-repo chmod -R 755 /data/nomachine-repo。packages/和manifests/目录下所有文件权限应为644确保 Web 服务器如 Nginx能读取但普通用户无法写入。配置自动安全更新sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgradesUbuntu或sudo dnf install dnf-automatic sudo systemctl enable --now dnf-automatic.timerCentOS Stream。提示不要在仓库服务器上运行任何其他服务如数据库、Web 应用。它的唯一职责就是安全、稳定、高速地分发文件。多一个进程就多一分被攻击或干扰的风险。3.2 GPG 密钥对生成与管理信任链的基石GPG 签名是整个仓库可信度的核心。它不是可选项是必选项。生成和管理密钥必须遵循最小权限和离线原则在离线环境生成密钥对找一台不联网的干净机器可以是你的个人笔记本拔掉网线安装 GPGsudo apt install gnupg然后执行gpg --full-generate-key # 选择RSA and RSA (default), 4096 bits, key does not expire # Real name: NoMachine Repo Signing Key # Email: repo-signingyourcompany.com (这个邮箱不用于通信只是标识) # Passphrase: 设置一个强密码至少 16 位含大小写字母、数字、符号这会生成一对密钥。私钥secret key必须立即导出并保存在离线 USB 设备上永不联网。公钥public key可以导出并上传到仓库服务器。导出并分发公钥# 在离线机上 gpg --armor --export NoMachine Repo Signing Key nomachine-repo-public.key # 把 nomachine-repo-public.key 拷贝到仓库服务器的 /data/nomachine-repo/ 目录下在仓库服务器上导入公钥并配置 GPG# 切换到 repo-admin 用户 sudo su - repo-admin # 导入公钥 gpg --import /data/nomachine-repo/nomachine-repo-public.key # 查看密钥 ID记住这个 ID后面 sync 脚本要用 gpg --list-keys NoMachine Repo Signing Key # 输出类似pub rsa4096 2024-01-01 [SC] [expires: 2029-01-01] # ABCDEF1234567890ABCDEF1234567890ABCDEF12 # 这个 ABCDEF1234567890ABCDEF1234567890ABCDEF12 就是 KEY_ID密钥轮换计划GPG 密钥不是一劳永逸的。建议每 3 年轮换一次。轮换时用新密钥签署旧密钥certify形成信任链确保旧 manifest 依然可验证。详细流程见 GPG 官方文档的 “Key Expiration and Revocation”。注意绝对不要在仓库服务器上生成私钥私钥一旦接触网络信任链即告崩溃。我见过太多团队把私钥放在 Git 仓库里或者用弱密码保护结果被扫描工具扫出整个仓库的签名失去意义。3.3 同步脚本sync.sh的核心逻辑与防错设计sync.sh是仓库的“心脏”它负责从官网抓取、下载、校验、生成 manifest、签名。它的健壮性直接决定仓库的可用性。以下是经过生产环境千锤百炼的脚本核心逻辑简化版实际使用请用完整版#!/bin/bash # sync.sh - NoMachine 仓库同步脚本 set -e # 任何命令失败立即退出 REPO_ROOT/data/nomachine-repo PACKAGES_DIR$REPO_ROOT/packages MANIFESTS_DIR$REPO_ROOT/manifets KEY_IDABCDEF1234567890ABCDEF1234567890ABCDEF12 # 替换为你的 KEY_ID TMP_DIR$(mktemp -d) # 1. 获取官网最新 Release 页面带 User-Agent模拟真实浏览器 echo Fetching latest NoMachine release page... curl -sSL -A Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 \ https://www.nomachine.com/download/downloadid1 $TMP_DIR/release.html # 2. 解析 HTML提取所有下载链接和 checksum 块用 grep sed不用 jsdom避免依赖 # 官网 checksum 块格式固定pstrongSHA256:/strong a1b2c3... for nomachine_8.12.1_1_amd64.deb/p CHECKSUM_LINES$(grep -oP pstrongSHA256:/strong\s*\K[a-f0-9]{64}\s*for\s*[^] $TMP_DIR/release.html) # 3. 提取版本号从页面标题或 H1 标签 VERSION$(grep -oP titleNoMachine.*?(\d\.\d\.\d) $TMP_DIR/release.html | cut -d -f2) # 4. 创建本次同步的临时工作区 WORK_DIR$TMP_DIR/$VERSION mkdir -p $WORK_DIR # 5. 遍历每个 checksum 行下载并校验 while IFS read -r line; do if [[ -z $line ]]; then continue; fi SHA256$(echo $line | awk {print $1}) FILENAME$(echo $line | awk {$1$2; print $0} | sed s/^[[:space:]]*//; s/[[:space:]]*$//) # 构建规范化的本地文件名修复官网乱七八糟的命名 # 例如nomachine_8.12.1_1_amd64.deb - nomachine-8.12.1-ubuntu22.04-amd64.deb # 这里需要一个映射表根据 FILENAME 中的线索如 _ubuntu22.04_重命名 LOCAL_FILENAME$(echo $FILENAME | sed -E s/nomachine_([0-9.])_([0-9])_([a-z0-9])\.deb/nomachine-\1-ubuntu22.04-\3.deb/) echo Downloading $FILENAME as $LOCAL_FILENAME... curl -sSL -o $WORK_DIR/$LOCAL_FILENAME https://download.nomachine.com/download/$FILENAME # 本地计算 SHA256 LOCAL_SHA256$(sha256sum $WORK_DIR/$LOCAL_FILENAME | cut -d -f1) # 严格比对 if [[ $SHA256 ! $LOCAL_SHA256 ]]; then echo ERROR: SHA256 mismatch for $FILENAME! Expected $SHA256, got $LOCAL_SHA256 exit 1 fi done $CHECKSUM_LINES # 6. 生成 manifest.json echo Generating manifest for $VERSION... cat $WORK_DIR/manifest.json EOF { version: $VERSION, released_at: $(date -u %Y-%m-%dT%H:%M:%SZ), packages: [ EOF # 7. 为每个包生成 JSON 条目略循环写入 # 8. 添加 JSON 结尾 echo ] $WORK_DIR/manifest.json echo } $WORK_DIR/manifest.json # 9. 用 GPG 签名 manifest gpg --detach-sign --armor --local-user $KEY_ID $WORK_DIR/manifest.json # 10. 原子化地移动到仓库 mv $WORK_DIR/manifest.json $MANIFESTS_DIR/$VERSION.json mv $WORK_DIR/manifest.json.asc $MANIFESTS_DIR/$VERSION.json.sig mv $WORK_DIR/*.deb $WORK_DIR/*.rpm $WORK_DIR/*.pkg $PACKAGES_DIR/ # 11. 清理 rm -rf $TMP_DIR echo Sync completed for version $VERSION这个脚本的关键防错设计set -e任何一步失败立即终止防止半成品污染仓库。mktemp -d所有下载和处理都在临时目录进行避免直接操作仓库目录。原子化移动mvmanifest.json和.sig文件是成对出现的mv是原子操作确保用户永远看不到“只有 json 没有 sig”或“只有 sig 没有 json”的中间状态。严格的 SHA256 比对不是“大概一样”而是逐字节比对差一个字符就报错退出。离线解析不依赖 Node.js 或 Python 的复杂 HTML 解析库用grep/sed/awk这些 POSIX 标准工具确保在任何 Linux 发行版上都能跑。实操心得第一次运行sync.sh前务必先手动执行一遍curl和grep命令确认官网 HTML 结构没变。NoMachine 官网 UI 改版时有发生这时你需要微调grep的正则表达式。我把这个检查步骤写进了团队 SOP每次同步前花 2 分钟确认比半夜被报警电话叫醒强一百倍。3.4 Web 服务器配置Nginx 示例让仓库“快、稳、准”仓库的 Web 服务核心诉求是零延迟响应、零配置错误、零缓存歧义。Nginx 是我的首选配置极简# /etc/nginx/sites-available/nomachine-repo server { listen 80; server_name repo.yourcompany.com; # 根目录指向仓库 root /data/nomachine-repo; index index.html; # 所有请求都映射到文件系统 location / { try_files $uri 404; } # 禁止列出目录安全 location /packages/ { autoindex off; } location /manifests/ { autoindex off; } # 为 .json 和 .sig 文件设置正确的 MIME 类型 location ~ \.json$ { add_header Content-Type application/json; } location ~ \.sig$ { add_header Content-Type application/pgp-signature; } # 可选添加 CORS 头方便前端页面调用如果你们有内部管理页面 add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods GET, OPTIONS; }启用配置sudo ln -sf /etc/nginx/sites-available/nomachine-repo /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx关键点说明try_files $uri 404这是最高效的静态文件服务方式。Nginx 直接查找文件系统不走任何 PHP 或代理逻辑毫秒级响应。autoindex off绝对禁止目录浏览。用户只能通过你知道的 URL如/packages/nomachine-8.12.1-ubuntu22.04-amd64.deb下载不能curl http://repo.yourcompany.com/packages/看到所有包列表——这是基本的安全红线。MIME 类型显式声明.json必须是application/json否则浏览器可能把它当文本下载.sig必须是application/pgp-signature否则 GPG 工具可能无法正确识别。这些看似小事但在某些老旧终端上缺了 MIME 头会导致校验失败。提示如果公司有 HTTPS 强制要求用 Lets Encrypt 的certbot一键配置即可。HTTPS 对仓库不是功能必需但它是现代基础设施的默认基线不做反而显得不专业。4. 终端用户使用指南如何在各种环境下安全、高效地下载和安装4.1 通用下载与校验流程三步建立信任无论你在什么系统上下载和验证 NoMachine 包的流程都应该是标准化的三步获取 manifest 并验证签名# 下载 manifest 和其签名 curl -sSL -o manifest.json https://repo.yourcompany.com/manifets/8.12.1.json curl -sSL -o manifest.json.sig https://repo.yourcompany.com/manifets/8.12.1.json.sig # 导入仓库公钥只需一次 curl -sSL https://repo.yourcompany.com/nomachine-repo-public.key | gpg --import # 验证 manifest 签名 gpg --verify manifest.json.sig manifest.json # 输出必须包含 Good signature from ... 和 Primary key fingerprint: ABCD ...从 manifest 中提取目标包信息# 查找 Ubuntu 22.04 AMD64 包 jq -r .packages[] | select(.platform ubuntu and .distro_version 22.04 and .arch amd64) | .filename manifest.json # 输出nomachine-8.12.1-ubuntu22.04-amd64.deb # 获取其 SHA256 jq -r .packages[] | select(.platform ubuntu and .distro_version 22.04 and .arch amd64) | .sha256 manifest.json # 输出a1b2c3...下载包并校验# 下载 curl -sSL -o nomachine-8.12.1-ubuntu22.04-amd64.deb https://repo.yourcompany.com/packages/nomachine-8.12.1-ubuntu22.04-amd64.deb # 本地计算 SHA256 并比对一行命令搞定 echo a1b2c3... nomachine-8.12.1-ubuntu22.04-amd64.deb | sha256sum -c - # 输出必须是 nomachine-8.12.1-ubuntu22.04-amd64.deb: OK这个流程把信任建立在数学GPG和哈希SHA256之上而不是“我相信这个链接是官网的”。它可以在任何有curl和gpg的 Linux/macOS 系统上运行包括最小化安装的 Docker 容器。4.2 各平台安装命令速查告别“百度教程”的碎片化有了可信的包安装就是体力活。以下是各主流平台的一行安装命令已通过生产环境验证Ubuntu/Debian.debsudo apt update sudo apt install -y ./nomachine-8.12.1-ubuntu22.04-amd64.deb # 如果提示依赖问题先装依赖 sudo apt install -y libx11-6 libxext6 libxrender1 libxrandr2 libxcursor1 libxfixes3 libxdamage1 libxcomposite1 libasound2 libpulse0 libgl1 libsm6CentOS/RHEL/Fedora.rpmsudo dnf install -y ./nomachine-8.12.1-centos8-amd64.rpm # 或者用 yum旧版 sudo yum localinstall -y ./nomachine-8.12.1-centos8-amd64.rpmmacOS.pkg# 下载后双击安装或命令行静默安装 sudo installer -pkg ./nomachine-8.12.1-macos13-amd64.pkg -target /Windows.exe# PowerShell 命令行安装静默 Start-Process -FilePath .\nomachine-8.12.1-windows10-amd64.exe -ArgumentList /S -Wait**树莓派 OSRaspberry Pi OS
