IPMI

Original Article ↗ Hacker News Discussion ↗

Out‑of‑band management standards like IPMI and newer Redfish give servers a separate “baseboard management controller” that can power-cycle machines, expose a remote console, and report hardware status even when the OS is down—capabilities that proved crucial in events like the CrowdStrike mass reboot. Commenters weigh how useful this is in practice, from enterprise racks to homelabs, comparing vendor implementations (iLO, iDRAC, Supermicro, ASRock Rack) and DIY KVM alternatives based on Raspberry Pi or NanoKVM. A recurring theme is the trade-off between convenience and risk: BMCs add idle power draw, are often poorly maintained and insecure, and must be isolated on dedicated networks or VPNs to be used safely.

Usefulness of IPMI / OOB Management

  • Widely seen as indispensable for remote servers: power control, rebooting, and remote console were crucial in events like large‑scale agent failures requiring many reboots.
  • Even in small deployments, tools like ipmitool/ipmiutil are valued for hardware introspection and automation.
  • Some boards expose BMC graphics as a simple framebuffer device; usable for basic desktops but too slow for modern GUIs or high resolutions.

Homelab vs Datacenter Trade‑offs

  • Homelab users like integrated IPMI but dislike its idle power draw (often ~5–7W even when host is “off”).
  • Debate over where that power goes: some blame the BMC, others the PSU’s inefficiency at low load.
  • Datacenter‑oriented designs (no ACPI sleep, crude fan control, loud chassis) clash with SMB/homelab expectations, but are seen as acceptable for rack environments.

Security, Isolation, and Long‑Term Support

  • Strong consensus: treat IPMI as highly sensitive and potentially insecure.
    • Always isolate on separate VLANs/VRFs, often only reachable via VPN or bastion.
    • Avoid BMCs that share the main NIC; some implementations silently fall back to it.
  • Known weaknesses:
    • IPMI 2.0 sends password hashes to clients and limits passwords to 20 chars.
    • Past bugs allowed null encryption or any password to succeed.
    • Some designs expose unauthenticated admin from the host; useful for recovery but expands attack surface.
  • Concern that BMC firmware receives poor long‑term updates; many would prefer fully user‑controlled, open firmware.

Vendors, Hardware, and Firmware Quirks

  • Supermicro, ASRock Rack, Dell, HPE, Lenovo all have fans and detractors:
    • Supermicro praised for reliability and flexibility but criticized for archaic UIs, fan handling, lack of sleep, proprietary utilities, and recent secure boot key leaks.
    • ASRock Rack praised for modern features and layout, but some report high RMA rates or specific firmware bugs.
  • Intel vs AMD:
    • Many see AMD as better value/performance; Intel NICs are generally respected despite some bad driver eras.
    • AMD PSP / Intel ME are acknowledged as necessary low‑level init engines but distrusted due to opacity and past vulnerabilities.

Redfish and Management Standards

  • Redfish is promoted as IPMI’s successor (HTTP/JSON, better security model, broader feature set).
  • In practice, implementations are inconsistent:
    • Tasks like SSL cert upload or virtual media/boot control require vendor‑specific workarounds.
    • Automation frameworks must carry per‑vendor logic despite apparent standardization.
  • Some regard IPMI as a “dangerous, attractive nuisance” and see Redfish as an improvement, but not yet uniformly reliable.

Alternatives to Built‑In IPMI

  • External KVM devices discussed for systems without or with untrusted IPMI:
    • PiKVM, TinyPilot, BliKVM, and NanoKVM offer HDMI capture, USB keyboard/mouse, and sometimes ATX power control.
    • Concerns about closed firmware on some devices; enthusiasm rises when vendors promise or deliver open backends.
  • Some pair servers with Raspberry Pis or routers running OpenWrt as always‑on serial/KVM controllers, reverting to simple serial management plus out‑of‑band power (e.g., smart plugs, WoL).