An `amt` driver (napalm_amt.AmtDriver), a ManagementControllerDriver for the management controller of Intel vPro machines, with its own lean WS-Management client (requests + ElementTree, HTTP Digest, ports 16992/16993). It reads the machine's identity, hardware with the SMBIOS system UUID, firmware (AMT with build, BIOS), power state and the hardware event log, reports what AMT listens on (plain HTTP or TLS, KVM incl. port 5900, IDE-R), and switches the machine's power. AMT cannot be reset over WS-Management, so there is no reboot_host. Discovery recognises AMT by its ports and its Server header. Tested against Intel's published AMT 12 recordings (go-wsman-messages, Apache-2.0, see NOTICE). `python -m napalm_amt.record` records a real AMT read-only; the first test devices are two Lenovo ThinkCentre M910x.
74 lines
3.3 KiB
Markdown
74 lines
3.3 KiB
Markdown
# napalm-amt
|
|
|
|
NAPALM driver for **Intel Active Management Technology (AMT)**, the management controller
|
|
built into Intel vPro business desktops, mini PCs and notebooks, over DMTF
|
|
WS-Management. Built on
|
|
[napalm-device-types](https://git.netork.io/NAPALM/napalm-device-types). Written for netOrk.
|
|
|
|
**Status: early development.** One driver, `amt` (`napalm_amt.AmtDriver`), a
|
|
`ManagementControllerDriver` from napalm-device-types like the server BMC drivers in
|
|
[napalm-redfish](https://git.netork.io/NAPALM/napalm-redfish). It reads the machine's
|
|
identity, hardware, firmware, power state and event log, reports what AMT listens on, and
|
|
switches the machine's power. It is tested against Intel's published recordings of an
|
|
AMT 12 (NUC9). Recordings of the first real test devices, two Lenovo ThinkCentre M910x
|
|
(AMT 11.x), are still to come.
|
|
|
|
## Why a driver of its own
|
|
|
|
AMT does the job of a server BMC (power control and inventory while the operating system
|
|
is down or the machine is off), but speaks a different protocol: no Redfish and no IPMI,
|
|
only WS-Management (SOAP, CIM classes) on port 16992, or 16993 with TLS. It shares
|
|
nothing with napalm-redfish beyond the role, so it lives here.
|
|
|
|
## Layout
|
|
|
|
| Entry point | Transport | Scope |
|
|
|---|---|---|
|
|
| `amt` | WS-Management over HTTP (16992) or HTTPS (16993), HTTP Digest auth | Read, plus power control; no reset of AMT itself |
|
|
|
|
`optional_args`: `port` (16992; 16993 means TLS), `tls` (overrides what the port
|
|
implies), `verify_ssl` (`True`, a CA file path, or `False`), `retries` (1).
|
|
|
|
The WS-Management client in `napalm_amt/wsman.py` is self-contained (requests and
|
|
ElementTree). Neither `pywsman` (a C binding) nor `python-amt` (unmaintained, power only)
|
|
is used.
|
|
|
|
## What AMT knows, and what it does not
|
|
|
|
AMT reads the machine's SMBIOS: manufacturer, model, serial number, system UUID, CPUs,
|
|
DIMMs, drives (sizes only), BIOS version. It has no temperature, fan or power-supply
|
|
readings on client platforms, no core counts, and no drive models. Where it knows nothing,
|
|
the driver says so (`None`, empty) and does not guess. See [docs/amt-map.md](docs/amt-map.md).
|
|
|
|
AMT shares the machine's network controller. In DHCP mode it also uses the operating
|
|
system's IP address. netOrk keeps one device per address, so give AMT a static IP address
|
|
of its own in the MEBx ([docs/lenovo-m910x.md](docs/lenovo-m910x.md)).
|
|
|
|
## Documents
|
|
|
|
- [docs/amt-map.md](docs/amt-map.md): getters mapped to WS-Management classes
|
|
- [docs/security.md](docs/security.md): plain HTTP vs TLS, accounts, KVM, known CVEs
|
|
- [docs/lenovo-m910x.md](docs/lenovo-m910x.md): first test devices, MEBx setup, what to verify
|
|
- [docs/testing.md](docs/testing.md): fixtures, recording a real AMT
|
|
- [docs/references.md](docs/references.md)
|
|
|
|
## Development
|
|
|
|
```bash
|
|
python -m venv .venv
|
|
.venv/bin/pip install -e ../napalm-device-types # not on PyPI
|
|
.venv/bin/pip install -e '.[test]' ruff mypy types-requests
|
|
.venv/bin/python -m pytest
|
|
.venv/bin/ruff check . && .venv/bin/mypy napalm_amt
|
|
```
|
|
|
|
## 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 (`napalm_amt/parsers/`), tested on recorded responses
|
|
under `tests/fixtures/<source>/`, with a `COMMANDS.txt` listing the request behind each
|
|
file.
|