Christian Manivong
5f8a4ef975
No code yet. The README explains why one Redfish driver with vendor quirk modules beats a Supermicro-only IPMI driver, and keeps IPMI over LAN as a read-only fallback. docs/ holds a draft for a new ManagementController role base in napalm-device-types, the getter-to-resource map, the first test device (Supermicro X10DRL-i, Redfish firmware 3.91), the security points (IPMI RAKP hash disclosure, power control, credentials) and the test plan with DMTF mockups and fixtures to record.
66 lines
3.0 KiB
Markdown
66 lines
3.0 KiB
Markdown
# napalm-redfish
|
|
|
|
NAPALM driver for server **baseboard management controllers (BMCs)** over
|
|
[DMTF Redfish](https://www.dmtf.org/standards/redfish), with a read-only IPMI fallback for
|
|
boards that predate Redfish. Built on
|
|
[napalm-device-types](https://git.netork.io/NAPALM/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](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](docs/role.md): the role base this needs in napalm-device-types (draft)
|
|
- [docs/redfish-map.md](docs/redfish-map.md): getters mapped to Redfish resources
|
|
- [docs/supermicro-x10.md](docs/supermicro-x10.md): first test device, its Redfish level, IPMI
|
|
- [docs/security.md](docs/security.md): credentials, IPMI over LAN, power control
|
|
- [docs/testing.md](docs/testing.md): DMTF mockups, emulators, fixtures to record
|
|
- [docs/references.md](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 a `COMMANDS.txt` (here: the request
|
|
paths) listing what produced each file.
|
|
- `napalm-device-types` is not on PyPI: install it from
|
|
`git+https://git.netork.io/NAPALM/napalm-device-types.git` before this package.
|
|
|
|
## License
|
|
|
|
Apache License 2.0, see [LICENSE](LICENSE).
|