christianmanivong
332e6090a7
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.
107 lines
4.7 KiB
Markdown
107 lines
4.7 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.** Two drivers, both `ManagementControllerDriver`s from
|
|
napalm-device-types:
|
|
|
|
- `redfish` (`napalm_redfish.RedfishDriver`) implements the NAPALM getters and the role
|
|
methods in [docs/redfish-map.md](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 reports `bmc_license_required` through
|
|
`get_device_warnings` instead 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](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](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).
|