Configuration

mcidrac reads its registry of managed iDRACs from a TOML file.

Search order

First match wins:

1. $MCIDRAC_CONFIG — explicit override
2. ./mcidrac.toml — project-local
3. ~/.config/mcidrac/idracs.toml — per-user
4. /etc/mcidrac/idracs.toml — system-wide

mcidrac --check loads the config, prints what it found, and exits — status 0 on success, 2 with a specific message on any problem.

Schema

One [[idracs]] table per BMC:

[[idracs]]
name = "r740-lab"                # required, unique — the handle tools use
host = "192.0.2.10"              # required — IP or hostname (":port" allowed)
user = "root"                    # optional, default "root"
password_env = "R740_LAB_PASS"   # exactly one of password / password_env
# password = "literal"           #   (inline alternative)
# cert_path = "~/ca/idrac.pem"   # optional — pin TLS to this CA bundle
description = "rack 2 U12"       # optional — shown in idrac_list

Field	Rules
name	Unique within the file. Every tool’s first argument.
host	Whatever the management plane answers on. A port suffix (bmc:8443) works.
password / password_env	Exactly one required. password_env names an environment variable resolved at startup; an unset/empty variable is a config error, not a silent blank password.
cert_path	PEM CA bundle for pinned TLS. If set but the file is missing, connections fail rather than silently downgrading to unverified. Pinning validates the chain, not the hostname (BMCs are reached by IP and rarely have SANs).
description	Free text for humans and LLMs.

Credential handling

Without cert_path, TLS verification is off — the pragmatic default for BMCs with self-signed certificates on a management LAN.

Passwords are resolved at load time and never leave the server process: idrac_list and the idrac://registry resource return summaries with credentials stripped. Duplicated names, missing fields, and both-password-forms are all rejected at load with messages naming the offending entry.