Skip to content

The board

Generated from the committed OpenAPI document, bmcd 2.36.3. Do not edit this file: just refresh-api rewrites it.

Firmware, daemon, kernel and board identity

Legacy form: GET /api/bmc?opt=get&type=about with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — About The result.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `About`
field type required description
api string yes The /api/bmc contract version, not a release of anything.
bmcd_version string yes
board_model string yes From the board's EEPROM. Empty on a board that cannot be read, rather than absent: upstream's shape, and the interface renders the blank.
board_revision string yes
board_serial string or null no None when the EEPROM field is missing or blank after trimming.
build_version string yes The same value as bmcd_version. The web interface reads this key for its "Build version" field and renders vundefined without it, so it is duplicated deliberately rather than left for the client to alias.
buildroot string yes
buildtime string yes
hostname string yes
kernel string yes The running kernel. "unknown" when uname cannot be read; the one field an operator wants after a kernel bump.
version string yes The firmware, from /etc/os-release. "unknown" when it cannot be read -- a string, because an About page with a gap is still worth rendering and this field has never been nullable.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Who may reach this board, and how you reached it

The local account the password belongs to, the trust anchor for proxied identity if one is in effect, the header an identity is read from, and how THIS request was authenticated. client_ca_pinned_in_config means config.yaml chose it and the daemon will not overwrite that choice.

response body meaning
200 application/json — AccessState The board's access configuration.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `AccessState`
field type required description
actor object yes How this request was authenticated.
client_ca object or null no Null when this board trusts no proxy.
client_ca_pinned_in_config boolean yes
identity_header object yes
local_account string yes
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Stop trusting any proxy

Refused when the caller is authenticated BY that CA -- removing it ends the session asking, through the proxy it is asking through. Do it from the board's own interface with a password. Also refused when config.yaml pins the path.

response body meaning
202 empty Removed; a reload is required.
default application/problem+json — Problem A refusal, RFC 9457.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Set the CA whose client certificates name an operator

The bundle is loaded through the same call the TLS acceptor makes at startup before it is stored, so a bundle this accepts is one the daemon can start with. Takes effect on the next reload (opt=set&type=reload). Refused when config.yaml pins the path.

Request body (`application/json`)
field type required description
identity_header string no Optional. The header an identity is read from; absent leaves it alone.
pem string yes One or more certificates, PEM.
response body meaning
202 application/json — object Stored; a reload is required.
default application/problem+json — Problem A refusal, RFC 9457.
`202` body (`application/json`)
field type required description
detail string no
reload_required boolean no
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Change a local account's password

The CURRENT password is required, including from an operator a proxy vouched for: a certificate proves the gateway trusts you, not that you hold this board's console. At least 12 characters, counted as characters rather than bytes. Existing sessions keep working -- a token outlives the password it was minted from.

Request body (`application/json`)
field type required description
current_password string (password) yes
new_password string (password) yes
username string yes Whose password. root on a board.
response body meaning
204 empty Changed.
403 application/problem+json — Problem The current password is wrong. The same answer is given for an account that does not exist, so this cannot enumerate them.
default application/problem+json — Problem A refusal, RFC 9457.
`403` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Everything configured on this board, as one document

Legacy form: GET /api/bmc?opt=get&type=config with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — ConfigExport The result.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `ConfigExport`
field type required description
exported_at string yes When and from what. Not read back on import; it is what makes a file found on a workstation six months later identifiable.
exported_from ExportOrigin yes
firmware_sources object no
format_version integer (uint32) yes
hostname string or null no
nodes array or null no
ntp_servers array or null no
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Apply an exported configuration; reports per field

Legacy form: GET /api/bmc?opt=set&type=config with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

Request body (`application/json`)
field type required description
config string no the exported document; a JSON body that is the document itself is accepted as-is
Request body (`application/x-www-form-urlencoded`)
field type required description
config string no the exported document; a JSON body that is the document itself is accepted as-is
response body meaning
200 application/json — — The result. Its shape is not described in this document.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

The board's own condition: uptime, load, memory, NAND, clock

Legacy form: GET /api/bmc?opt=get&type=health with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — Health The result.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `Health`
field type required description
clock Clock yes
load Load yes
memory Memory yes
nand Nand yes
uptime_seconds number or null no Seconds since the BMC booted, as /proc/uptime gives it. Not the uptime of any compute module.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

The board's name, live and after the next boot

Legacy form: GET /api/bmc?opt=get&type=hostname with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — Hostname The result.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `Hostname`
field type required description
hostname string or null no What sethostname(2) currently says. None if it cannot be read.
on_next_boot string or null no What /etc/hostname holds. None when the file is absent.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Rename the board; its metrics carry no name, so none of them move

Legacy form: GET /api/bmc?opt=set&type=hostname with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

Request body (`application/json`)
field type required description
name string no one DNS label: letters, digits, hyphens; no dots
Request body (`application/x-www-form-urlencoded`)
field type required description
name string no one DNS label: letters, digits, hyphens; no dots
response body meaning
200 application/json — — The result. Its shape is not described in this document.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Storage and interfaces, as the Overview page reads them

Legacy form: GET /api/bmc?opt=get&type=info with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — BoardInfo The result.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`200` body (`application/json`): `BoardInfo`
field type required description
ip array of NetInfo yes
storage array of StorageInfo yes
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Reboot the BMC; the compute modules keep running

Legacy form: GET /api/bmc?opt=set&type=reboot with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — — The result. Its shape is not described in this document.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Restart the daemon

Legacy form: GET /api/bmc?opt=set&type=reload with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.

response body meaning
200 application/json — — The result. Its shape is not described in this document.
204 empty Done, with nothing to report.
default application/problem+json — Problem A refusal, RFC 9457.
`default` body (`application/problem+json`): `Problem`
field type required description
detail string no
status integer yes
title string yes
type string no

Last updated: