ServerBox 的 BMCRedfish支持详解带外电源管理与传感器读取的设计与硬件兼容性【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_boxServer Box 通过 Redfish 的 HTTPS/JSON 接口与主板上的 BMC基板管理控制器通信在主机断电、卡死或重启时仍能读取电源状态与硬件传感器、执行电源操作作为 SSH 与 Monitor agent 之外的独立带外管理通道。本文以 docs/src/content/docs/zh/principles/bmc.md 为核心结合 BmcCfg / BmcCredential 模型 与 BmcNotifier 轮询实现完整讲解 Server Box 中 BMC 功能的配置模型、TLS 首次信任机制、厂商差异处理、轮询策略、Phase 1 功能范围与真实硬件验证方法帮助读者理解该功能的实现边界与设计取舍。为什么需要 BMC主机不可用时的独立信息源SSH 和 Monitor agent 都要求主机操作系统正常运行SSH 需要sshdMonitor agent 需要在主机上运行进程。当主机断电、卡死或重启时二者通常只能报告连接失败。BMCBaseboard Management Controller是主板上的独立计算机拥有独立的供电和网络接口。即使主机上的其他服务全部不可用BMC 仍可能响应提供电源状态、硬件传感器读数和硬件事件等主机操作系统无法提供的信息。Server Box 正是利用这一特性把 BMC 作为 SSH / Monitor 之外的侧通道能力。⚠️ 当前 BMC 功能处于Beta阶段只有读取功能电源状态和传感器在一台真实设备上验证过电源控制尚未进行自动化验证。文档中的硬件差异主要来自厂商文档、录制的响应和本地测试服务不能视为硬件兼容列表。请把电源操作当作按下远程服务器上的物理电源按钮。为什么选择 Redfish 而不是 IPMIServer Box 通过 Redfish 的 HTTPS/JSON API 与 BMC 通信。Redfish 是现代服务器常见的带外管理接口与 IPMI 2.0 over LAN 的对比决定了这一选择对比项RedfishIPMI 2.0 over LAN传输HTTPS JSONRMCP over UDP 623二进制协议在本项目中的实现成本用dio即可实现不需要原生代码没有 Dart 实现需要通过 FFI 在crates/中实现客户端数据模型自描述资源可通过链接遍历SDR、SEL、chassis 命令及厂商自定义 raw 数据认证TLS session tokenRAKP硬件覆盖通常为 2016 年及之后的设备还覆盖更早和入门级设备规范状态持续更新最近一次修订在 2013 年IPMI 的优势主要是支持更早的硬件和 Serial-over-LAN。当前项目暂不引入 IPMI 客户端如果未来需要覆盖 Redfish 之前的设备需单独评估 FFI 客户端和另一套安全模型。在应用模型中的位置挂在 Spi 上的侧通道BMC 是主机的带外管理通道属于服务器配置中的独立侧通道。服务器的 SSH 和 Monitor HTTP 配置决定状态数据和常规操作从哪里获取BMC 用于主机操作系统不可用时读取硬件状态和执行电源操作。BMC 配置挂在Spi上与 Wake-on-LAN 的wolCfg同级class Spi { SshCredential? ssh; MonitorHttpCredential? monitorHttp; WakeOnLanCfg? wolCfg; BmcCfg? bmc; // 未配置 BMC 时为 null } final class BmcCfg { String addr; // https://... String? credId; // 多台服务器共用 BmcCredential String? certSha256; // 用户确认后固定 } class BmcCredential { String id; // 生成的 ID不是显示名称 String name; // 选择器中显示的唯一名称 String user; String? pwd; }这一模型在源码中有更细的约束。BmcCfglib/data/model/server/bmc_cfg.dart只有三个字段其中addr只取 scheme、host 和 port/redfish/v1/服务根路径是固定的由客户端追加而非配置uri与port按 scheme 缺省端口HTTPS→443、HTTP→80且只接受https/http因此10.0.0.9、ftp://...这类非法地址在编辑器阶段就会被拒绝isComplete只要求地址 账户证书不参与判断——因为核对证书需要先能连上设备两者有先后依赖。BmcCredentiallib/data/model/server/bmc_credential.dart中id是生成的稳定标识永不使用name作为引用——这是从私钥name 即 id导致改名后所有引用服务器全部脱钩的教训中抽象出的同一决策pwd可为 null用于表达已命名但尚未录入密码的状态而不是存储一个空字符串冒充密码。账户与设备分离的设计理由BMC 账户是独立记录按 ID 引用。机架中的多台服务器通常共用一组 BMC 账户因此修改一次账户即可更新所有引用它的服务器。如果把密码复制到每台服务器轮换密码时就要改二十个地方漏改哪一台只能靠机器不再应答来发现。删除账户使用ON DELETE SET NULL不级联删除服务器。见 lib/data/provider/bmc_credential.dart 的delete()它会先找出所有spi.bmc?.credId cred.id的服务器并逐个把credId置空再删除账户记录。之所以要在应用层显式清理而非只依赖外键是因为直接写列不会移动updated_at和rev同步对端才不会把悬空的 id 又同步回来同时ServerStore从缓存应答删除操作对它不可见若不清理受影响服务器下次保存时会把已删除的 id 写回在编辑器里爆出外键错误。地址和证书 fingerprint 属于单台 BMC保存在BmcCfg中。不同 BMC 使用不同证书且永远不会有两台 BMC 出示同一张证书如果把 fingerprint 放在共享账户记录里第一台设备的 fingerprint 会被拿去验证第二台设备——等于完全没有校验。物理主机和虚拟机可能共同指向一台 BMC。此时从任意虚拟机执行电源操作都会影响整台物理主机读到的PowerState也是主机状态。当前模型不处理这种 host/guest 关系文档建议只在物理主机记录上配置 BMC。分层设计让 fixture 可验证的代码不依赖真实服务器BmcCfg BmcCredential 用户配置 App ↓ RedfishClient TLS 信任、session、GET/POST package:redfish RedfishDiscovery 一次性发现资源和 reset 类型 package:redfish resources / sensors JSON → model不执行 IO package:redfish ↓ BmcNotifier 状态和独立轮询周期 App只有RedfishClient访问网络下层解析组件接收已获取的 JSON map 并返回 model。因此厂商差异可以通过保存的响应fixture测试而不必每次连接真实硬件。协议侧被抽到了独立的 packages/redfish 包由 pubspec.yaml 以path:方式引用它不关心 Server Box 如何存储配置。TLS 与首次使用信任BMC 证书如何被安全确认BMC 通常使用自签名证书。BMC 具有电源控制权限接受地址上的任意证书会允许其他服务冒充 BMC因此 Server Box 采用与 SSH host key 类似的**首次使用信任TOFU**机制首次连接时显示证书的 SHA-256 fingerprint。你在 BMC 自带的 Web 界面中核对 fingerprint并确认是否信任。App 保存已确认的 fingerprint后续只接受匹配的证书。fingerprint 变化时拒绝连接显示新旧值并要求重新确认。实现上BmcCfg.certSha256保存的是证书 DER 形式的 SHA-256小写十六进制字段缺失意味着尚未核对过此时连接会被拒绝而非信任——这是有意为之PVE 和 monitor agent 都带忽略证书开关而一个握着电源控制权的管理接口是最不该沿用这种开关的地方。copyWith(certSha256: null)被显式支持以便用户清除已固定的证书见 test/bmc_cfg_test.dart 中的copyWith can clear the pinned certificate用例。BMC 重新生成证书或升级固件后fingerprint 可能正常变化中间人攻击也会造成相同现象。接受新证书前请先确认 BMC 的身份。厂商差异Redfish 资源模型里的坑以下内容都需要通过 Redfish 资源发现不能根据厂商名称或常见路径硬编码。不同固件可能实现不同版本的资源模型。资源 ID 不固定/redfish/v1/是固定入口但Systems和Chassis下的 ID 由厂商决定厂商典型的 system IDSupermicro1Dell iDRACSystem.Embedded.1OpenBMCsystem客户端应遍历/redfish/v1/Systems读取集合返回的Members然后访问具体资源。这也解释了为何BmcCfg只保存服务根地址Systems/1、Chassis/1这类路径必须通过发现得到。传感器模型可能有两套Redfish 2020.4 将Chassis/{id}/Thermal和/Power标记为旧模型推荐使用ThermalSubsystem、PowerSubsystem和统一的Sensors集合。许多固件仍然只实现旧模型也有固件同时提供两套。客户端应检查Chassis资源实际提供的 links优先使用完整的新模型缺少新模型时再使用旧模型不要根据厂商名称推断模型。已验证的 H3C 设备就是这种两套并存但不完整的典型Sensors有链接但ThermalSubsystem不完整因此回退到旧模型ThermalPower。ResetType的声明可能不可靠ComputerSystem.Resetaction 会通过ResetTypeRedfish.AllowableValues声明支持的值。不同设备支持的值不同Nmi和PowerCycle尤其可能因固件实现或 license 限制而不可用。App 将重启电源循环等用户意图映射到设备声明的值并为必要操作提供降级顺序找不到可用值时不显示对应按钮。厂商可能扩展ResetTypeH3C R5350 G6 会声明标准枚举中不存在的ForcePowerCycle同时不声明其他断电操作。如果只匹配标准名称就会错误地把电源循环映射为ForceRestart重启而非断电再上电。因此每个用户意图的候选列表会在标准名称之后包含已知的厂商扩展名称扩展名称来自实际设备响应不能只根据规范推断。传感器可能返回哨兵值规范建议没有读数时返回null但有些固件会返回哨兵值。例如测试过的 H3C 设备将无法读取的温度返回42949672950xFFFFFFFF。App 按合理范围过滤读数而不是只匹配已知哨兵值当前过滤范围不会接受低于绝对零度或高于 1000°C 的温度也不会接受不合理的风扇转速。-1被保留因为它既可能是哨兵值也可能是真实的低温读数。Graceful 操作只表示请求已接受HPE iLO 文档说明GracefulShutdown和GracefulRestart的行为取决于操作系统204 No Content只能说明请求已被接受不能证明操作系统已经执行。因此 App 会轮询PowerState直到观察到状态变化或达到超时HTTP status code 不作为电源操作结果。Session 数量有限Redfish session 通过POST到SessionService/Sessions创建并在响应中返回X-Auth-Token。未删除的 session 会在 BMC 上保留到超时BMC 的并发 session 数量通常很少泄漏过多可能导致管理界面拒绝新连接。每个 client 只创建一个 session并在销毁时DELETE对应资源正常路径和失败路径都必须释放 session只探测服务根资源时无需创建 session。License 可能限制功能部分 Supermicro license 会限制固件更新和虚拟介质等功能。测试表明某些 X11 到 X13 设备的只读 GET 和ComputerSystem.Reset不需要这些 license——这属于设备经验不代表所有型号的固定政策。子资源返回401或403时App 应如实报告该资源不可用并继续处理其他资源。轮询策略独立周期 一次性发现 并发保护BMC 的响应通常比操作系统 API 慢一次传感器读取可能需要几秒。因此 BMC 使用独立的轮询周期不与常规服务器状态轮询共用计时器。在 lib/data/provider/bmc/bmc.dart 中可以确认这些关键常量_pollInterval Duration(minutes: 1)BMC 轮询周期为一分钟。原因在源码注释中写得很清楚BMC 很慢、回答的是硬件数据变化速率远低于状态页搭常规轮询的便车会把设备大部分容量花在没人看的变化上。_powerConfirmTimeout Duration(minutes: 2)与_powerPollInterval Duration(seconds: 5)电源操作后每 5 秒轮询一次PowerState最多等 2 分钟。因为 HTTP 状态不是答案答案在PowerState里。_maxSensorMembers 64新模型把每个读数放在独立资源里一百个传感器就是一百次请求不设上限一次轮询会拖到下一次开始。截断时通过BmcState.sensorsTruncated明确告知避免静默截断读起来像这台机器只有 64 个传感器。资源 ID、传感器模型和可用 reset 类型属于每个 client 的 discovery 结果只发现一次并缓存每次轮询只读取和转换实时数据避免重复请求设备结构。BmcNotifier持有一个RedfishClient即设备上一个 session因此dispose时关闭 client 是唯一把 session 还回去的途径设备允许的 session 极少。并发保护上_refreshing标志保证慢轮询与电源确认操作不重叠——电源确认最长 2 分钟、而定时器 1 分钟触发一次不加保护就会同时出现两个 discovery 和最多 64×2 次传感器请求策略是跳过而不是排队因为轮询产出的是当前状态已经在跑的那次马上就会发布它。此外用_generation计数器让配置变更后仍在途的请求能识别自己的答案已过期。电源操作的结果枚举BmcPowerResult也体现了状态变化才算结果的设计confirmed表示PowerState真的移动了唯一机器做了点什么的证据accepted表示服务接受了请求但等待超时前状态未变——这不是失败graceful shutdown 可能比任何人愿意等的都久但也不能当结果上报notSupported表示设备声明中没有任何值能满足该意图请求根本没发出failed表示失败。Phase 1 功能范围探测GET /redfish/v1/及其集合读取Systems/{id}电源状态、机型、序列号、BIOS 版本和健康汇总读取Chassis/{id}温度、风扇转速和功耗使用设备提供的传感器模型调用ComputerSystem.Reset显示确认对话框协商 reset 类型并通过轮询确认结果暂不支持事件日志、存储清单、启动项覆盖、虚拟介质以及通过 Monitor agent 中继访问隔离网络中的 BMC。已验证硬件H3C R5350 G6下表记录的是已经实际响应过的设备不是兼容性列表其他行为来自厂商文档、录制的响应和本地测试服务。项目值型号H3C R5350 G6BIOS6.30.50Redfish 版本1.15.1根节点Vendor/Product两者都缺失不能依赖它们识别服务System IDSystems/1Chassis IDChassis/1传感器模型legacyThermalPowerSensors有链接但ThermalSubsystem不完整因此使用旧模型ResetTypeForceOff、ForcePowerCycle、ForceRestart、GracefulShutdown、Nmi、On温度20 个其中 18 个返回0xFFFFFFFF哨兵值风扇8 个位置每个位置返回两条不同读数整机功耗PowerControl返回 48 WSession一个 client 保持一个 session关闭时释放证书自签名测试时在有效期内测试时间2026-08-23尚未覆盖DellSystem.Embedded.1、OpenBMCsystem、Supermicro X11–X14 的传感器模型差异、HPE iLO 的 graceful 操作以及提供多个 system 的设备。如何验证真实硬件只读测试packages/redfish/test/e2e_test.dart是 opt-in 的只读测试。在工作区根目录的.env中设置以下变量后才会连接真实设备未设置时会静默跳过SBM_E2E_BMC_URLhttps://10.0.0.9 SBM_E2E_BMC_USER... SBM_E2E_BMC_PWD...测试会打印发现到的资源 ID、传感器模型、reset 类型和每个用户意图的映射结果不会断言某个厂商必须使用某种形状。它会读取 reset action但不会向 action 发送 POST。电源操作手工验证电源控制没有自动化测试。手工验证时请使用不承载重要业务的设备配置 BMC并核对证书 fingerprint。确认 App 显示的电源状态与设备实际状态一致。点击重启在确认对话框中核对协商得到的ResetType。检查结果是confirmed还是accepted。对于 iLO 的 graceful 操作accepted是合理结果对于明确区分请求和结果的设备accepted表示尚未观察到状态变化需要进一步检查。总结Server Box 的 BMC 功能围绕三条主线设计配置模型上把账户机架共享与地址/证书单设备独有彻底分离避免共享凭证污染设备校验协议实现上坚持一切通过资源发现不按厂商名称硬编码并逐一处理了资源 ID、传感器双模型、厂商扩展ResetType、哨兵值、graceful 语义、session 配额和 license 限制等真实世界差异运行时策略上用独立轮询周期、一次性 discovery 缓存和严格的并发保护适配 BMC慢、连接数少、但提供主机不可替代信息的硬件特性。当前功能处于 Beta电源控制仅经一台设备手工验证随着更多真实硬件Dell、OpenBMC、Supermicro、HPE iLO加入验证厂商差异清单还会继续扩展。【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_box创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考