Christian Manivong
8998e1342e
Session login through the SessionService with X-Auth-Token, the session deleted on close (also on errors and when the DELETE fails), basic auth as fallback only when the service cannot create sessions, never after a rejected password. Certificate verification is on by default and configurable per device; True passes the requests CA bundle explicitly because the redfish library disables verification without a CA file. Collections are followed by @odata.id, including expanded members and nextLink pages. Links to other hosts are refused so the session token stays on the BMC.
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: planning. There is no code yet. This repository holds the design so far. The first test device is a Supermicro X10DRL-i (BMC firmware 3.91, Redfish).
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 (planned)
| 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.
License
Apache License 2.0, see LICENSE.