Redfish

The Redfish extension manages physical servers out-of-band, through their BMC (Baseboard Management Controller) over the DMTF Redfish API. Because it talks to the BMC rather than the operating system, it needs no agent and works even when the server is powered off: you get live power state and health sensors, firmware and hardware inventory, the System Event Log, power and boot control, the chassis identify LED, and quick access to the server's SSH and KVM consoles.

Redfish is a Pro feature - without a Pro license the Sources workspace is replaced by a "Server sources" upgrade notice and the data views show "Redfish requires a Pro license". See Plans & Pro.

Supported Hardware

Any Redfish-compliant BMC works. Kunobi discovers each server's actual Redfish resource layout instead of assuming vendor paths, so BMCs with non-standard resource ids (such as AMI MegaRAC-based firmware) work out of the box. On top of that, three vendors get automatic enrichment - the vendor is detected on first connection:

Vendor	BMC	Extras
Dell	iDRAC	Service tag as asset tag, KVM console link
HPE	iLO	iLO firmware version as BMC version, KVM console link
Supermicro	Supermicro BMC	BMC firmware version, iKVM console link discovered through the BMC's own API

You'll also need HTTPS reachability from the machine running Kunobi to the BMC (port 443 by default) and a BMC account with Redfish access. BMCs commonly ship with self-signed TLS certificates - see Security.

Setup

Install the Redfish extension from Settings → Extensions (see Extensions). It starts automatically. If you open a Redfish view while the extension isn't running, Kunobi shows a "Redfish extension required" notice instead.
Add your first server as described below - it connects immediately and becomes the active server.

Managing Servers

Click Sources in the left navigation bar.
Open the workspace selector in the sidebar (press W) and pick Redfish Servers.

The table lists your servers with columns Server (name and address), Status, Model, Power, and Last check (the result of the latest test, or how long ago the server was last polled). Select a row and press o or y for the Overview and YAML sidebar tabs with the full record.

The Status column tells you where each server is in its lifecycle:

Status	Meaning
`connected`	Logged in; the last poll succeeded.
`connecting`	Logging in to the BMC.
`polling`	A poll is in progress.
`unreachable`	The connection attempt failed - network or login problem. A server that has never managed to log in stays here.
`disconnected`	A previously connected server failed three or more consecutive polls; retries continue with backoff.
`unknown`	Not contacted yet.

Adding a Server

Press Add (n) and fill in the form:

Field	Notes
Name	A friendly label. Empty means `host:port`.
Host	BMC hostname or IP address. Required.
Port	BMC HTTPS port, default `443`.
Accept untrusted certs	Accept the BMC's self-signed certificate. Default off.
Username / Password	The BMC account. The password goes to your OS keychain, never to a config file.
Profile	What the background poll fetches (see Polling Profiles). Empty means `full`.

Test Connection in the dialog performs a full login with the values in the form and, on success, reports the detected vendor, model, serial number, and power state - useful before committing.

Adding connects immediately: Kunobi logs in, detects the vendor, and reads the system information. If the login fails or the BMC is unreachable, the error is shown and nothing is saved. Two more rules apply:

The BMC must report a serial number - it is what gives the server a stable identity, so the same machine is recognized even if you later re-add it under a different address. A BMC that reports none is rejected.
Duplicates are rejected: the same host:port, or the same physical server (same serial) under another address.

Your first server automatically becomes the active server.

Testing, Editing & Removing

With a server row selected:

Test (t) - logs in with the stored credentials. The result appears in the Last check column: Testing..., then OK or Failed, with the message in a tooltip.
Edit (e) - everything is editable: name, host, port, username, password, profile, poll interval, and the certificate policy. Leaving the password blank keeps the stored one. Changing the host, port, username, or password triggers a reconnect - the status resets and the next poll logs in fresh.
Remove (Backspace) - after a confirmation ("Remove server?"), the server is removed along with all its collected data, and its password is deleted from the keychain.

The Active Server

Activate (c) marks a server as the active one - and for Redfish this matters beyond the status bar:

The active server gets full detail polling on the background schedule: health sensors, firmware, events, and inventory, according to its profile.
Every other server gets a lightweight status poll: reachability, power state, and basic system information. The fleet table stays live for all servers; the detail views are only kept fresh for the active one.
Refresh server fetches full detail for any server on demand, active or not (see Server Actions).

The active server shows in the connection indicator in the status bar at the bottom of the app, where you can also switch it. The selection survives restarts; a sole server is selected automatically, but with several servers Kunobi never guesses - you pick.

Browsing Server Data

Open the Kubernetes data page, open the workspace selector (press W), and pick Redfish Servers. The sidebar lists the fleet view followed by ten component views - filter them with the box at the top:

Redfish Servers - the fleet: name and address, vendor, status, model, profile, power state, overall health, last poll, and last error. Health is the worst of the server's temperature, fan, and power-supply sensors: OK, Warning, or Critical.
Firmware - the firmware inventory: component, version, and whether it is updateable.
Events - the System Event Log: severity (OK / Warning / Critical), message, message ID, and time. The newest entries are kept, up to the profile's event count (50 by default).
Processors - model, cores, threads, max frequency, manufacturer, health.
Memory - each DIMM: capacity, type, frequency, manufacturer, health.
Drives - each physical drive: controller, media type (HDD/SSD/NVMe), capacity, protocol, manufacturer, model, drive and controller health.
Volumes - RAID volumes: controller, RAID type, capacity, health.
Network Interfaces - BMC-reported NICs: MAC, speed, link status, IPv4/IPv6 addresses, health.
Temperatures - each sensor: current reading in °C, warning and critical thresholds, health.
Fans - each fan: RPM or percentage (vendors report one or the other), health.
Power Supplies - each PSU: model, output watts, capacity watts, health.

Component views show the components of the server you drill into: select a server and use the drilldown buttons in the action bar (see Drilldown). Remember the freshness rule: component data is kept current for the active server and refreshed for any server with Refresh server. While the Redfish workspace is active, the kind filter shows only Redfish kinds.

Server Details

Selecting a server row opens detail tabs in the sidebar:

Overview - the server's identity and hardware summary: vendor, model, serial number, asset tag, host and port, host name, profile, power state, indicator LED, status, health, last poll and last error; plus processors, processor model, total memory, BIOS version, and BMC version.
Console - remote access at a glance:
- Serial console: whether it is enabled and which connection types the BMC supports. When SSH is available, the ready-to-run ssh command is shown with a copy button and an Open terminal button that starts the session in Kunobi's integrated terminal.
- Graphical console (KVM): whether it is enabled and its connection types. When the BMC exposes a console URL, it is shown with a copy button and an Open button that opens the BMC's own console in your browser.
- Console information is discovered during polling - if the tab says "No console data", select the server and refresh it.
YAML - the raw record.

Server Actions

All actions are available from the action bar with a server row selected, and from the command palette.

Refresh Server

Fetches everything for the selected server on demand - system information, health sensors, firmware, events, and inventory - regardless of which server is active and what its profile says. Use it to inspect a non-active server without re-pointing the background poll.

Power Actions

Five actions, one per Redfish reset type:

Action	What it does
Power: On	Powers the server on.
Power: GracefulShutdown	Asks the OS to shut down cleanly.
Power: ForceOff	Cuts power immediately, like holding the power button.
Power: ForceRestart	Hard reset without an OS shutdown.
Power: PowerCycle	Full power-off/power-on cycle.

Each opens a confirmation dialog. On and GracefulShutdown confirm with one click. ForceOff, ForceRestart, and PowerCycle abruptly cut power - unsaved state may be lost - so they require typing the server's name before the button enables.

A submitted action means the BMC accepted the request; the Power column updates on the next poll.

Set Next Boot Device

A one-shot boot override for the next boot only: Pxe, Hdd, Cd, BiosSetup, or None (clears a previous override). It doesn't reboot the server by itself - follow it with a power action. Typical uses: a PXE reinstall, or getting into BIOS setup on a machine in another room.

Indicator LED

LED: Off, LED: Lit, and LED: Blinking set the chassis identify light, so you (or remote hands) can find the machine in the rack. Applied immediately, no confirmation. Works across BMC generations - both the current and the legacy Redfish LED controls are handled.

Polling Profiles

A profile controls what the background poll fetches for the active server: health sensors, firmware inventory, event log, hardware inventory, and how many event-log entries to keep. Two profiles are built in and can't be deleted:

Profile	Polls
`full`	Everything, 50 event entries
`health-only`	Health sensors only

Manage Redfish profiles (from the command palette or action bar, no selection needed) lists your profiles with inline Edit and Delete, and a form for creating new ones: name (fixed once created), description, the four category toggles, and the event count (1 to 500).

Assign a profile per server when adding or editing it, or rely on the default (full). Profiles only shape the background poll of the active server - non-active servers are status-only regardless of profile, and Refresh server always fetches everything.

Settings

Redfish settings (from the command palette or action bar, no selection needed):

Setting	Notes
Default poll interval	Seconds between background polls for servers without their own interval. `10` to `3600`.
Accept untrusted TLS certificates by default	The default certificate policy for servers that don't set their own.

Per-server values always win over these defaults.

Security

Passwords never touch the config file. BMC passwords are stored in your operating system's keychain (macOS Keychain, Windows Credential Manager, or the Linux Secret Service), one entry per server. Removing a server deletes its entry. Configs from older versions that still contain plain-text passwords are migrated to the keychain automatically at startup. Passwords are never displayed anywhere in the app.
TLS verification is on by default. BMCs often ship with self-signed certificates; the Accept untrusted certs option (per server, or as a global default) makes Kunobi accept them. Doing so trades away protection against interception on the path to the BMC - prefer installing proper certificates on BMCs where you can, and keep the option scoped to the servers that need it.

Configuration File

Server definitions and settings are persisted in a TOML file (read at startup, rewritten whenever you change something in the app):

macOS: ~/Library/Application Support/<app-id>/extensions/redfish/config.toml
Linux: ~/.local/share/<app-id>/extensions/redfish/config.toml
Windows: %APPDATA%\<app-id>\extensions\redfish\config.toml

where <app-id> matches your Kunobi variant (for example ninja.kunobi.desktop).

[extension]
default_poll_interval = 60
default_profile = "full"
accept_untrusted_certs = false
# selected_server_id = "..."   # the active server - managed by the app

[profiles.rack-audit]
description = "Health + events"
poll_health = true
poll_firmware = false
poll_events = true
poll_inventory = false
event_count = 100

[[servers]]
name = "prod-db-01"
host = "192.168.1.100"
port = 443
username = "root"
profile = "full"
# poll_interval = 30
# accept_untrusted_certs = true

There is no password field - passwords live in the keychain. The extension also records each server's discovered serial number and Redfish resource paths in this file; leave those managed fields alone.

Polling Behavior

The extension checks every 60 seconds which servers are due and polls each on its own interval. The active server gets its full profile; the others get a status-only poll.
A failing server retries with exponential backoff - starting at one minute and doubling up to a ten-minute cap - and a previously connected server is marked disconnected after three consecutive poll failures (one that never managed to log in stays unreachable). One successful poll resets everything.
Server identity follows the hardware serial number, so a machine re-added under a new IP is recognized as the same server.

Troubleshooting

Login failed / unreachable - check the BMC address and port, that the network path allows HTTPS to the BMC, and that the account has Redfish access (accounts can also be locked out after failed attempts).

Certificate errors when adding - the BMC presents a self-signed certificate; tick Accept untrusted certs for that server, or install a proper certificate on the BMC.

"Server did not report a serial number" - the BMC's Redfish implementation doesn't expose one, so Kunobi can't give the server a stable identity. Check for a BMC firmware update.

Component views look stale - detail data is only kept fresh for the active server. Activate the server you're inspecting, or use Refresh server.

No events or firmware for some servers - not every BMC exposes those endpoints; the rest of the poll still works.

A power action was submitted but nothing happened - the BMC accepted the request but may process it asynchronously. Check the Events view; the power state updates on the next poll.

The Console tab says "No console data" - console capabilities are discovered while polling; select the server and refresh it.

Limitations

Control is limited to power, next-boot override, and the indicator LED: no firmware updates, BIOS settings editing, or virtual media mounting.
The event log is read-only - entries can't be cleared from Kunobi.
Background detail polling covers one server at a time (the active one); others are status-only until refreshed manually.
Authentication is a single username/password per server.
KVM access opens the BMC's own console; Kunobi links to it rather than embedding it.