julian-corbet/nixbmc-corbet-ch

# nixbmc 这是一个针对 AMI MegaRAC 系列 BMC（AST2500/AST2600，技嘉、超微、ASRock Rack、泰安和联想均采用此相同固件谱系）中不稳定且内置的 KVM 查看器的全新纯净开发、原生浏览器替代方案。 ## 愿景 [`rd450x-console`](https://github.com/BadCoder1337/rd450x-console) 是本项目在形态上而非实质上效仿的先例：它将联想 RD450X 的 `JViewer.jar`——一个诞生于浏览器放弃插件支持之前的 Java Web Start 小程序——替换为了一个通过桥接接入 noVNC 的原生 Go 二进制程序。在那里，Go 是唯一的选择，因为当时根本没有任何办法能让浏览器去解析那个协议。 这个限制并不适用于我们。我们 BMC 自带的 KVM 客户端 (H5Viewer) 已经是 HTML5/JS/WebSocket 实现了——不需要插件，不需要原生二进制文件，也不需要任何桥接。问题从来都不是“不存在原生浏览器客户端”，而是“自带的客户端太不稳定”。仅仅为了通过 noVNC 将结果交还给浏览器，而用编译型语言重新实现整个协议，这等于在解决一个我们根本不存在的问题，同时却增加了一个我们不需要的服务器进程。 相反，nixbmc 是一个**纯净开发的 JavaScript 客户端**（与 `rd450x-console` 保持相同的纯净立场——根据逆向工程的协议事实从头重新实现，绝不将厂商自身的提取出来的 JS 代码提交到这里），它直接与 BMC 真实的 REST + WebSocket 接口通信（`POST /api/session`，`wss:///kvm`，IVTP 帧格式，ASPEED VQ+JPEG+RC4 编解码器——所有这些都来源于对真实主板的真实抓包记录），完全在浏览器中运行。唯一起支撑作用的是 BMC 前面的一个小型反向代理，之所以需要它，是出于两个与协议本身毫无关系的原因： - **TLS 信任。** BMC 提供的是自签名证书；浏览器不会像在加载普通页面时让你点击忽略警告那样，允许 `wss://` 连接通过不受信任的证书。代理会在我们这一端终止真实证书的验证，并在其自身连接 BMC 的链路上跳过验证（与 `rd450x-console` 采取的立场相同）。 - **认证代理。** 由代理——而不是浏览器——持有 BMC 的管理员凭据 (sops) 并自行执行 `POST /api/session`，因此真正的 BMC 密码永远不会到达客户端 JS。浏览器只需要能访问到我们的服务即可。 所有协议层面的工作（session-token 握手、IVTP 操作码、视频解码、HID 输入）都是静态页面的职责。代理只是无脑的底层管道，而不是对协议的重新实现。 ## 状态 **Pre-alpha 阶段——仅有脚手架，尚未编写任何模块。** 在编写实际客户端/代理的第一行代码之前，被两个悬而未决的问题阻碍了（将它们带到这里讨论而不是盲目猜测，是根据本项目自身“不要 MVP，构建正确的最终状态”的习惯——在这两个问题中任何一个上猜错，都意味着要重新调整模块的架构，而不仅仅是修改配置）： 1. **代理在哪里运行？** AST2500 KVM 链路（在本项目分离出的更广泛的裸机控制中心计划中）的全部意义在于提供预启动 / 降级状态下的访问——在资源池停机或 k3s 本身没有启动时也能访问。将 nixbmc *作为 k3s 应用运行* 会使其与它旨在抵御的故障模式产生命运共同体。倾向于：在中心宿主机本身上运行一个小型的、由裸机 NixOS 声明的 systemd 服务（与 `rescue-maintain` / 其他由裸机声明的服务立场相同），而不是 k3s 部署。 2. **暴露模型。** 仅限 NetBird（符合对待敏感的带外访问的一贯方式——对物理主机进行完全的 HID/键盘/鼠标控制，比大多数集群服务的影响范围更大），还是也应该可以通过 cloudflared 访问，以便从没有安装 NetBird 客户端的设备进行访问？更广阔愿景中“在手机上打开一个 URL”的构想可能意味着两者之一，这取决于是否预期该手机本身就已经处于 NetBird mesh 网络中。 一旦这些问题落地，第一个真实版本的范围是：首先针对我们的特定主板实现完整的视图**和**输入（键盘/鼠标 HID），并且在编写时要保证足够的通用性（BMC 主机/凭据作为 NixOS 模块选项，而不是硬编码），这样任何属于此固件代际的 AMI MegaRAC 系列 BMC 都只需更改配置即可实现——这与凭据/目标保持私有（本仓库自身的值）而机制保持公开的思路相吻合，这也是此系列中所有其他项目采用的相同拆分方式。虚拟介质（远程 ISO 挂载）明确不在 v1 的范围内——显示 + 输入才是真正的诉求。 ## 仓库布局 | 路径 | 用途 | |---|---| | `flake.nix` | Flake 入口点。一旦上述悬而未决的问题得到解决，`nixosModules.kvm` 就会落地。 | | `experiments/` | 抛弃式试验——参见 [`experiments/README.md`](experiments/README.md)。 | | `studies/` | 书面调查结果——参见 [`studies/README.md`](studies/README.md)。 | ## 相关项目 nixbmc 是共享一个通用设计系统的几个小型、可独立使用的开源项目之一：[nixarch](https://github.com/julian-corbet/nixarch-corbet-ch)， nixvps、nixram、nixnas、[nixremote](https://github.com/julian-corbet/nixremote-corbet-ch)、 [nixfish](https://github.com/julian-corbet/nixfish-corbet-ch)。它的定位是 单一且带外的控制台协议——在设计上非常专注（范围窄），对于拥有相同 BMC 代际的任何人都很有用，无论他们是否运行此系列中的任何其他项目。 ## 许可证 [MIT License](LICENSE) © 2026 Julian Corbet

标签：BMC管理, CMS安全, JavaScript, KVM Viewer, 数据可视化, 自定义脚本, 运维工具, 音视频编解码