Redfish

Redfish 驱动参考：到 BMC 的 HTTPS 连接、资源路径加 JSON 指针的寻址、读取、PATCH 写入和类型。

Redfish 驱动读写 DMTF Redfish 管理服务，也就是服务器 BMC（基板管理控制器）、机箱和其他数据中心硬件为带外管理暴露出来的那套 REST API。这是一个普通的客户端模式驱动，由 Ganter Lab 连到仪器上，而传输永远是 HTTPS：加固过的 BMC 只暴露这一种，驱动也绝不会自己降级到普通 HTTP。

这样读到的典型的点有：电源状态、安全启动状态、机箱和管理器的健康状况、固件版本，以及热管理资源里的温度和风扇读数。

连接字段

连上时，驱动通过读服务根（/redfish/v1/）来核实这个服务。BMC 的 TLS 证书在 Windows 信任它，或你在本驱动页面的现场设备访问里批准了这份证书本身时被接受：BMC 出厂自带的自签名证书不需要在 Windows 里安装任何东西。连接失败时，事件页面和当天的日志文件会说明原因，并把底层错误附在后面，这样密码被驳回和证书在等待批准才分得开。

轮询间隔可以配置：设备的默认值（1000 毫秒）适用于每一个没有自己另作规定的点位。

点位寻址

Redfish 的点位靠一条资源路径，加上一个可选的、指向那个资源返回的文档里的 JSON 指针来寻址：

拼好的地址的几个例子（作为总线来源预览以只读方式显示）：

• redfish/v1/Systems/1#/PowerState：系统的电源状态，一个字符串。
• redfish/v1/Chassis/1/Thermal#/Temperatures/0/ReadingCelsius：第一个热传感器，一个数字。
• redfish/v1/Systems/1/SecureBoot#/SecureBootEnable：安全启动，一个布尔量。

读取时，驱动 GET 这个资源、解析 JSON、顺着指针走下去，再把结果转换成点位声明的数据类型。一个在文档里什么都没点到的指针，以及一个文档里存的是 JSON null 的字段，两者都读作没有值：点位转为质量不可用，由它的读取失败策略决定呈现什么，而不是让 null 这个词作为一次好的读数进来。不是 JSON 的响应会被直接按声明的类型解析。服务返回一个在成功范围之外的状态，那是服务在拒绝这次读取：点位同样转为质量不可用，它的原因会点名那个状态，以及服务随它发来的错误文档里的一小段摘录（HTTP 404 Not Found: …）。其他没有值的读取也会说出原因：没有资源路径的点位、在文档里什么都没点到的指针、存为 null 的字段（各自点名资源和指针），以及读不成声明类型的响应。一个完全不答的服务是设备的连接失败：设备会报告它并重新连接，它的点位会指向这台设备。点位红色那一行用工作站的语言说出这样的状态，401、403 和 404 还附上含义；设备红色那一行在每次尝试时说明它的连接为什么失败，是端口拒绝还是 401 这样的状态；服务自己的原话留在事件页面。

写入

读写方式可写的点位会对被寻址的那个字段发 PATCH：驱动构造出覆盖指针那条路径的最小 JSON 文档（对 /Parent/Child 来说就是 {"Parent":{"Child":<value>}} 这个请求体），并把它发到那个资源上。由此有两条约束：

• 写入必须有 JSON 指针。整份文档的点位（指针留空）没法被写：你还在编辑的时候，点位面板就拒绝这种组合，说这个字段缺了；而一次绕过去、真发到服务的尝试会失败，原因写进诊断日志。
• 什么可写由 BMC 说了算；服务驳回的 PATCH 会得到一个答复，里面有状态，以及服务随它发来的错误文档里的一小段摘录（HTTP 400 Bad Request: …），写入这个值的一方读得到原因。

和别处一样，你在点位写入框里打的是工程值，原始值上总线之前会先把这个点位的转换环节反过来走一遍，见 Connector 页面。

支持的数据类型

Boolean、Int32、Int64、Float、Double 和 String。请挑和那个 JSON 字段对得上的类型：像 SecureBootEnable 这样的标志用布尔，读数用数字，像 PowerState 或 Health 这样的状态用字符串。

命令

一个 Redfish 服务会为它能被要求做的每一件事发布一个 action，各自挂在它所作用的那个资源下面的路径上。工作站不去猜它们，因为只有硬件自己的文档才说得清哪些存在：你在设备上声明它们，位置是它页面上的命令卡片。每一条命令带一个名称、一条 action 路径（redfish/v1/Systems/1/Actions/ComputerSystem.Reset），以及可选的、它所接收的那一个值的名字（ResetType）；行上的“运行”把它发出去，服务答了什么会报告回来。一条命令同时也成为这台设备在本工作站自己的 OPC UA 地址空间里的一个方法，所以任何能调用方法的东西都能下发它。

值作为请求体发出去。已经是 JSON 的值原样发出；其余一切都按 {"<声明的名称>": "<值>"} 发出，那正是 Redfish 自己的 reset action 所要求的形状。

服务驳回的 action 会得到一个答复，里面有状态，以及服务随它发来的错误文档里的一小段摘录（HTTP 400 Bad Request: …），用的是和被驳回的写入一样的说法，这台设备上别的什么都不受它打扰。

设备发现

发现设备按钮读的是一个服务：把它的地址填进驱动页面的“扫描范围”卡片（https://bmc-host，或者厂商文档给的那个地址），扫描就走一遍那个服务的第一个 system、manager 和 chassis，把设备连同那些点一起提供出来，可以直接添加。扫描是走 HTTPS 且不带凭据去读的，因为它跑的时候那台该拿着凭据的设备还不存在，所以一个对每次请求都要求认证的服务什么都不会回答，那就改为手工添加。Redfish 自己的 SSDP 发现需要 UDP 组播，而进程内的驱动不做这个，所以广播找不到任何东西：扫描读的就是你给它的那个地址。

已经有的 Redfish 设备可以在自己的页面上找出它的点：“点位”卡片标题栏里的发现点位用设备的用户名和密码登录，走一遍同样的资源，所以对每次请求都要求认证的服务也会回答；它只列出设备还没有点位的点（见发现一台设备的点位）。

现场设备访问

BMC 通常用它自己的证书应答，这份证书是自签名的或由厂商颁发，Windows 中已安装的任何根证书都不为它担保。无需在这台计算机上安装那个根证书。第一次连接会被拒绝，设备在树里和它的页面上显示正在等待证书批准，页面上的查看证书按钮会在那份证书上打开这张卡片；证书则在 Redfish 驱动页面末尾的现场设备访问里等你决定。这张卡片和 OPC UA 驱动页面上的是同一张。

批准之前，请与管理该服务器的人核对指纹。批准只接受这一份证书，而且只在它的有效期内；它代替 Windows 缺少的根证书和证书上写的名字，所以按 IP 地址连接的 BMC，即使证书上写的是别的名字也能连上，而证书的其他方面一概不放宽。如果现场设备在你批准过证书的地址上换出另一份证书（证书续期、更换控制器等），读取就会停止，新证书在这里等待，工作站会带着审核按钮提示“证书已更换：<名称>”。Windows 已经信任的证书照旧被接受，永远不会出现在这里；没有任何东西会被自动批准。

驱动自己的失败会说明原因，而不是一个没有名字的 TLS 错误：“这台现场设备的证书（指纹的前 16 个字符）正在 Redfish 驱动页面的‘现场设备访问’里等待你的批准。批准之后就开始读取。”被阻止的则显示“……在本工作站已被阻止。请在 Redfish 驱动页面的‘现场设备访问’里审核它。”超出有效期、已吊销或签名损坏的证书会以这个原因被拒绝，且永远不会被列出，因为批准也不能让它变得可靠。无论从“扫描范围”卡片还是从设备页面上的发现点位扫描这个 BMC，都遵循同样的决定：陌生的证书会以这句话结束扫描，并在这里等待。

这些决定保存在工作站数据文件夹的 ua\pki\redfish 下，重启后依然有效。操作按钮只对能配置 Connector 的角色显示，而且只在工作站自己的窗口里生效：其他设备上的浏览器只能查看卡片、不能修改，也没有任何代理工具能批准证书（connector_browse 用 awaitingCertificate 标出正在等待的设备）。列表最多保留 100 份等待批准的证书；列表满了以后，新的证书仍会被拒绝但不会列出，卡片会说明这一点。