81 lines
3.6 KiB
Markdown
81 lines
3.6 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: early development.** The HTTPS transport (`napalm_redfish/transport.py`) and pure
|
|
parsers for the Redfish resources in [docs/redfish-map.md](docs/redfish-map.md)
|
|
(`napalm_redfish/parsers/`) exist and are tested against DMTF mockups. The driver class and
|
|
its `napalm.drivers` entry point wait for the `ManagementControllerDriver` role base in
|
|
napalm-device-types. 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.
|
|
|
|
## Development
|
|
|
|
```bash
|
|
python -m venv .venv && . .venv/bin/activate
|
|
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](LICENSE).
|