A Supermicro X10DRL-i refuses Redfish without a license (SUM, DCMS or
OOB), even the service root. IPMI answers without one.
- New entry point `ipmi` (napalm_redfish.ipmi.IpmiDriver) on
ManagementControllerDriver, over pyghmi: facts and inventory from the
FRU (serial number, system UUID), the BMC's LAN interface, sensors
(temperatures, fans, power supplies), the power state, the event log
and the BMC firmware. Read-only: no power control, no BMC reset.
Tested against recordings of the X10 with serials, the UUID, MACs and
IPs replaced.
- RedfishDriver.open() no longer fails on a license refusal: get_facts
returns what is known without Redfish, get_device_warnings reports
bmc_license_required with the licenses the BMC names, every other
getter raises. netOrk then shows the reason instead of an offline BMC.
- IpmiDriver is not exported from the package: NAPALM's own
get_network_driver("redfish") takes the first driver class of
napalm_redfish.
napalm-redfish
NAPALM driver for server baseboard management controllers (BMCs) over DMTF Redfish, with a read-only IPMI fallback for boards that predate Redfish. Built on napalm-device-types. Written for netOrk.
Status: early development. Two drivers, both ManagementControllerDrivers from
napalm-device-types:
redfish(napalm_redfish.RedfishDriver) implements the NAPALM getters and the role methods in docs/redfish-map.md, tested end to end against DMTF mockups. A BMC that refuses Redfish for want of a vendor license (a Supermicro X10 without SUM, DCMS or OOB) still opens: the driver reportsbmc_license_requiredthroughget_device_warningsinstead of failing.ipmi(napalm_redfish.ipmi.IpmiDriver) reads over IPMI 2.0 only: FRU facts and inventory, sensors, power state, event log, BMC firmware. Tested against recordings of a Supermicro X10DRL-i (BMC 3.91), which refuses Redfish without a license.
Why Redfish, and why not one driver per vendor
Redfish is the DMTF's REST API for management controllers. Supermicro (X10 with Redfish
firmware, X11 and later), Dell iDRAC, HPE iLO and Lenovo XCC all implement it. One driver
with small vendor quirk modules covers all of them; a napalm-supermicro-ipmi would cover
one.
IPMI over LAN stays a read-only fallback for boards without Redfish. Its IPMI 2.0 RAKP handshake hands the password hash to anyone who asks (CVE-2013-4786), so netOrk should not depend on it. Finding IPMI over LAN enabled is itself worth reporting, see docs/security.md.
Layout
| Entry point | Transport | Scope |
|---|---|---|
redfish |
HTTPS, Redfish REST (session token or basic auth) | Read, plus power control and BMC reset |
ipmi |
IPMI 2.0 over LAN (UDP 623) via pyghmi |
Read-only: facts, sensors, power state, SEL |
Vendor quirks (Supermicro, Dell, HPE, Lenovo) live in one module per vendor, selected from
the service root's Vendor/Oem data and Manager.Model. No separate entry point per
vendor.
Documents
- docs/role.md: the role base this needs in napalm-device-types (draft)
- docs/redfish-map.md: getters mapped to Redfish resources
- docs/supermicro-x10.md: first test device, its Redfish level, IPMI
- docs/security.md: credentials, IPMI over LAN, power control
- docs/testing.md: DMTF mockups, emulators, fixtures to record
- docs/references.md
Building without hardware
Unlike most drivers in this organisation, much of this one can be built and tested without a device: the DMTF publishes complete mockups of Redfish services (DSP2043), and both the DMTF Redfish-Mockup-Server and OpenStack's sushy-tools serve them over HTTP. Recorded output from the X10DRL-i then covers what the mockups do not: an old Redfish 1.0.x implementation and Supermicro's quirks.
Conventions
These follow the other drivers in the NAPALM organisation:
- Role bases declare, they never implement. Generic logic goes into napalm-device-types, vendor mechanics stay here.
- Parsing lives in pure functions, tested on recorded responses under
tests/fixtures/<vendor>-<model>-<firmware>/, with aCOMMANDS.txt(here: the request paths) listing what produced each file. napalm-device-typesis not on PyPI: install it fromgit+https://git.netork.io/NAPALM/napalm-device-types.gitbefore this package.
Usage
import napalm
driver = napalm.get_network_driver("redfish")
with driver("bmc01.example.net", "netork", "secret",
optional_args={"verify_ssl": "/etc/netork/bmc-ca.pem"}) as bmc:
bmc.get_facts() # the BMC: firmware as os_version, its ports
bmc.get_power_state() # the server: {"state": "On", "actions": [...]}
bmc.get_hardware_inventory()
Optional args: port (443), verify_ssl (True, False or a CA file path; default
True), auth (auto, session or basic; auto uses a Redfish session and falls back
to basic auth only if the service cannot create sessions), retries (1).
reboot_host restarts the BMC, never the server; the server is switched through
set_power_state. get_config is not implemented: a BMC has no configuration file.
Development
python -m venv .venv && . .venv/bin/activate
pip install git+https://git.netork.io/NAPALM/napalm-device-types.git
pip install -e '.[test]'
pytest
Fixtures from the DMTF mockups live under tests/fixtures/dmtf-<mockup>/, unmodified, with
the DMTF license and a COMMANDS.txt naming the source commit and request paths.
License
Apache License 2.0, see LICENSE.