Christian Manivong
42940d7e90
The redfish driver implements get_facts, get_interfaces, get_interfaces_ip, get_environment, get_users, get_ntp_servers and get_snmp_information for the BMC, and the role methods get_power_state, set_power_state, get_hardware_inventory, get_event_log, get_firmware_inventory and get_management_protocols for the managed server. reboot_host resets the BMC through Manager.Reset, never the server. Registered as the napalm.drivers entry point redfish; depends on napalm and napalm-device-types >= 4.6.
101 lines
4.4 KiB
Markdown
101 lines
4.4 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 `redfish` driver (`napalm_redfish.RedfishDriver`, a
|
|
`ManagementControllerDriver` from napalm-device-types) implements the NAPALM getters and
|
|
the role methods in [docs/redfish-map.md](docs/redfish-map.md), tested end to end against
|
|
DMTF mockups. It has not yet run against real hardware; the first test device is a
|
|
Supermicro X10DRL-i (BMC firmware 3.91, Redfish). The `ipmi` fallback does not exist yet.
|
|
|
|
## 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.
|
|
|
|
## Usage
|
|
|
|
```python
|
|
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
|
|
|
|
```bash
|
|
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](LICENSE).
|