IPMI-CHASSIS(8)

📦
version 1.6.20 · 14 versions
, in arch rolling, centos-stream 10, centos-stream 9

💅 IPMI-CHASSIS(8) — the chassis management utility, bestie

okay so this is ipmi-chassis from the System Commands manual, and it's literally the glow-up your IPMI chassis has been waiting for ✨

🌸 NAME 🌸

ipmi-chassis — the IPMI chassis management utility. that's it, that's the vibe 🎀

✨ SYNOPSIS ✨

ipmi-chassis [OPTION...]

🦋 DESCRIPTION 🦋

ipmi-chassis is your girl for managing and monitoring an IPMI chassis — think chassis power, identification (which is the LED control situation, iykyk), and status. if you wanna see every single chassis management option available, just scroll down to OPTIONS, it's all there 💖

below you're gonna find general IPMI options, tool-specific options, troubleshooting info, workaround info, examples, and known issues. for a general intro to FreeIPMI, go peek at freeipmi(7).

real talk though — if you're trying to do IPMI chassis configuration, that's ipmi-config(8)'s whole thing. and for some advanced chassis management, hit up bmc-device(8). and if you want a way more powerful chassis power control utility? ipmipower(8), no cap 👑

🌈 GENERAL OPTIONS 🌈

these are the general options for setting up IPMI communication and running general tool commands. lowkey the foundation of everything 🫶

  • -D IPMIDRIVER, --driver-type=IPMIDRIVER — tell it which driver type to use instead of letting it auto-select. the out-of-band drivers available rn are LAN and LAN_2_0, which do IPMI 1.5 and IPMI 2.0 respectively. the in-band drivers available rn are KCS, SSIF, OPENIPMI, SUNBMC, and INTELDCMI.
  • --disable-auto-probe — do NOT probe in-band IPMI devices for default settings. like, don't even try it.
  • --driver-address=DRIVER-ADDRESS — specify the in-band driver address to use instead of the probed value. DRIVER-ADDRESS should be prefixed with "0x" for a hex value and '0' for an octal value.
  • --driver-device=DEVICE — specify the in-band driver device path to use instead of the probed path.
  • --register-spacing=REGISTER-SPACING — specify the in-band driver register spacing instead of the probed value. the argument is in bytes (so like, 32bit register spacing = 4).
  • --target-channel-number=CHANNEL-NUMBER — specify the in-band driver target channel number to send IPMI requests to.
  • --target-slave-address=SLAVE-ADDRESS — specify the in-band driver target slave number to send IPMI requests to.
  • -h IPMIHOST1,IPMIHOST2,..., / --hostname=IPMIHOST1[:PORT],IPMIHOST2[:PORT],... — specify the remote host(s) to communicate with. multiple hostnames can be separated by comma, or you can use a range format (see HOSTRANGED SUPPORT below 👀). you can also toss an optional port on each host, which is super useful for port forwarding and similar situations. if you're specifying an IPv6 address AND port, use the format [ADDRESS]:PORT.
  • -u USERNAME, --username=USERNAME — the username to use when authenticating with the remote host. if you don't specify one, a null (i.e. anonymous) username is assumed. heads up: the user must have at least ADMIN privileges for this tool to operate fully 💀
  • -p PASSWORD, --password=PASSWORD — the password to use when authenticating with the remote host. if not specified, a null password is assumed. max password length is 16 for IPMI 1.5 and 20 for IPMI 2.0.
  • -P, --password-prompt — prompts for the password so it doesn't end up listed in process lists. privacy queen behavior 🙈
  • -k K_G, --k-g=K_G — specify the K_g BMC key to use when authenticating with the remote host for IPMI 2.0. if not specified, a null key is assumed. to input the key in hexadecimal form, prefix the string with '0x'. e.g., the key 'abc' can be entered with either the string 'abc' or the string '0x616263'.
  • -K, --k-g-prompt — prompts for k-g so it doesn't get listed in process lists. same energy, different secret 🔐
  • --session-timeout=MILLISECONDS — the session timeout in milliseconds. defaults to 20000 milliseconds (20 seconds) if you don't specify.
  • --retransmission-timeout=MILLISECONDS — the packet retransmission timeout in milliseconds. defaults to 1000 milliseconds (1 second) if not specified. important: the retransmission timeout cannot be larger than the session timeout. that's the rule, periodt.
  • -a AUTHENTICATION-TYPE, --authentication-type=AUTHENTICATION-TYPE — the IPMI 1.5 authentication type to use. available rn: NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5. defaults to MD5 if you don't say anything.
  • -I CIPHER-SUITE-ID, --cipher-suite-id=CIPHER-SUITE-ID — the IPMI 2.0 cipher suite ID to use. the Cipher Suite ID identifies a set of authentication, integrity, and confidentiality algorithms for IPMI 2.0 communication. the authentication algorithm is the one used for session setup, the integrity algorithm is the one used for session packet signatures, and the confidentiality algorithm is the one used for payload encryption. defaults to cipher suite ID 3 if not specified. here are the cipher suite ids currently supported, bestie:
0 - Authentication Algorithm = None; Integrity Algorithm = None;
Confidentiality Algorithm = None

1 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
None; Confidentiality Algorithm = None

2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = None

3 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128

6 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
None; Confidentiality Algorithm = None

7 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = None

8 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128

11 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = None

12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
MD5-128; Confidentiality Algorithm = AES-CBC-128

15 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm
= None; Confidentiality Algorithm = None

16 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm
= HMAC_SHA256_128; Confidentiality Algorithm = None

17 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm
= HMAC_SHA256_128; Confidentiality Algorithm = AES-CBC-128
  • -l PRIVILEGE-LEVEL, --privilege-level=PRIVILEGE-LEVEL — the privilege level to use. available rn: USER, OPERATOR, and ADMIN. defaults to ADMIN if you don't specify — main character energy only 👑
  • --config-file=FILE — specify an alternate configuration file.
  • -W WORKAROUNDS, --workaround-flags=WORKAROUNDS — specify workarounds for vendor compliance issues. you can stack multiple workarounds separated by commas. there's a special command line flag of "none" which indicates no workarounds (handy for overriding configured defaults). see WORKAROUNDS below for the list of available workarounds.
  • --debug — turn on debugging. we love a paper trail 🔍
  • -?, --help — outputs a help list and exits.
  • --usage — outputs a usage message and exits.
  • -V, --version — outputs the program version and exits.

🎀 IPMI-CHASSIS OPTIONS 🎀

these ones are specific to ipmi-chassis. the actual chassis stuff, slay 💅

  • --get-chassis-capabilities — get chassis capabilities. this returns info on which main chassis management functions are available.
  • --get-chassis-status — get chassis status. returns high level status info on the chassis.
  • --chassis-control=CONTROL — control the chassis. this gives you power-up, power-down, and reset control. supported values: POWER-DOWN, POWER-UP, POWER-CYCLE, HARD-RESET, DIAGNOSTIC-INTERRUPT, SOFT-SHUTDOWN.
  • --chassis-identify=IDENTIFY — set chassis identification. this controls physical system identification, typically a LED. supported values: TURN-OFF to turn off identification, <interval> to turn on identification for "interval" seconds, FORCE to turn it on indefinitely.
  • --get-system-restart-cause — get system restart cause. like, why did you restart, bestie 😭
  • --get-power-on-hours-counter — get power on hours (POH) counter.

🧚 HOSTRANGED OPTIONS 🧚

these options manipulate hostranged output. see HOSTRANGED SUPPORT below for extra info on hostranges 💖

  • -B, --buffer-output — buffer hostranged output. for each node, buffer standard output until that node has finished its IPMI operation. ngl, when you specify this, data may appear to output slower to you because the entire IPMI operation has to complete before any data can be output. see HOSTRANGED SUPPORT below for more.
  • -C, --consolidate-output — consolidate hostranged output. the complete standard output from every node you specified gets consolidated so nodes with identical output aren't output twice. a header lists those nodes with the consolidated output. when you specify this, no output can be seen until the IPMI operations to all nodes have completed. if you break out of the program early, all currently consolidated output will be dumped. see HOSTRANGED SUPPORT below for more.
  • -F NUM, --fanout=NUM — specify multiple host fanout. a "sliding window" (or fanout) algorithm is used for parallel IPMI communication so slower nodes or timed out nodes won't impede parallel communication. the max number of threads available at the same time is limited by the fanout. default is 64.
  • -E, --eliminate — eliminate hosts determined as undetected by ipmidetect. this tries to remove the common issue of hostranged execution timing out because several nodes got removed from service in a large cluster. the ipmidetectd daemon must be running on the node executing the command.
  • --always-prefix — always prefix output, even if only one host is specified or communicating in-band. this one's mainly useful for scripting purposes. the option will be ignored if you specify it with the -C option.

✨ HOSTRANGED SUPPORT ✨

Okay bestie, this is the part where you get to be lazy in the best way possible 💅 You can feed in a bunch of hosts two different ways: either an explicit comma separated list of hosts, or a range of hostnames shaped like this general form: prefix[n-m,l-k,...], where n < m and l < k, etc. 🎀

Heads up fr fr — that second form is not the same thing as regular expression character classes (which also happen to use []). Do not confuse them, iykyk. For example, foo[19] does not mean foo1 or foo9. It literally represents a degenerate range: foo19. 😭

This range syntax is honestly just a convenience thing for clusters that follow the prefixNN naming convention, and specifying ranges should not be considered necessary — like, the list foo1,foo9 could just be specified as such, or by the range foo[1,9]. Both slay, pick your fave 🫶

Some examples of range usage follow, and yes they're iconic:

foo[01-05] instead of foo01,foo02,foo03,foo04,foo05
foo[7,9-10] instead of foo7,foo9,foo10
foo[0-3] instead of foo0,foo1,foo2,foo3

Quick reminder to the reader (that's you 💖): some shells will interpret brackets ([ and ]) for pattern matching. Depending on your shell, it may be necessary to enclose ranged lists within quotes. So quote it or your shell will do its own little thing 🙈

When multiple hosts are specified by the user, a thread will be executed for each host in parallel up to the configured fanout (which can be adjusted via the -F option). This lets you talk to large numbers of nodes far more quickly than if it were done in serial. Main character energy for your cluster 🔥

By default, standard output from each node specified will be output with the hostname prepended to each line. This output is readable in many situations, but ngl it may be difficult to read in other situations — for example, output from multiple nodes may be mixed together 😵‍💫 The -B and -C options can be used to change this default. Use them, bestie.

In-band IPMI Communication will be used when the host "localhost" is specified. This lets you add the localhost into the hostranged output. Cute, right? 🎀

🩺 GENERAL TROUBLESHOOTING 🩺

Most often, IPMI problems are due to configuration problems. Like, it's almost always the config. It's giving "have you tried turning it off and on again" but for BMC settings 💀

IPMI over LAN problems involve a misconfiguration of the remote machine's BMC. Double check to make sure the following are configured properly in the remote machine's BMC: IP address, MAC address, subnet mask, username, user enablement, user privilege, password, LAN privilege, LAN enablement, and allowed authentication type(s). For IPMI 2.0 connections, double check to make sure the cipher suite privilege(s) and K_g key are configured properly. The ipmi-config(8) tool can be used to check and/or change these configuration settings. Go check them, bestie, I believe in you 🫶

Inband IPMI problems are typically caused by improperly configured drivers or non-standard BMCs. Rude of them, honestly.

In addition to the troubleshooting tips below, please see WORKAROUNDS below to also if there are any vendor specific bugs that have been discovered and worked around. (Yes, that sentence is a little chaotic, but it's in the original and we keep every detail around here 💜)

Listed below are many of the common issues for error messages. For additional support, please e-mail the <freeipmi-users@gnu.org> mailing list. They're lovely, fr fr.

  • "username invalid" — The username entered (or a NULL username if none was entered) is not available on the remote machine. It may also be possible the remote BMC's username configuration is incorrect.
  • "password invalid" — The password entered (or a NULL password if none was entered) is not correct. It may also be possible the password for the user is not correctly configured on the remote BMC.
  • "password verification timeout" — Password verification has timed out. A "password invalid" error (described above) or a generic "session timeout" (described below) occurred. During this point in the protocol it cannot be differentiated which occurred. Spooky 😭
  • "k_g invalid" — The K_g key entered (or a NULL K_g key if none was entered) is not correct. It may also be possible the K_g key is not correctly configured on the remote BMC.
  • "privilege level insufficient" — An IPMI command requires a higher user privilege than the one authenticated with. Please try to authenticate with a higher privilege. This may require authenticating to a different user which has a higher maximum privilege.
  • "privilege level cannot be obtained for this user" — The privilege level you are attempting to authenticate with is higher than the maximum allowed for this user. Please try again with a lower privilege. It may also be possible the maximum privilege level allowed for a user is not configured properly on the remote BMC.
  • "authentication type unavailable for attempted privilege level" — The authentication type you wish to authenticate with is not available for this privilege level. Please try again with an alternate authentication type or alternate privilege level. It may also be possible the available authentication types you can authenticate with are not correctly configured on the remote BMC.
  • "cipher suite id unavailable" — The cipher suite id you wish to authenticate with is not available on the remote BMC. Please try again with an alternate cipher suite id. It may also be possible the available cipher suite ids are not correctly configured on the remote BMC.
  • "ipmi 2.0 unavailable" — IPMI 2.0 was not discovered on the remote machine. Please try to use IPMI 1.5 instead. Downgrade era, lowkey 💀
  • "connection timeout" — Initial IPMI communication failed. A number of potential errors are possible, including an invalid hostname specified, an IPMI IP address cannot be resolved, IPMI is not enabled on the remote server, the network connection is bad, etc. Please verify configuration and connectivity.
  • "session timeout" — The IPMI session has timed out. Please reconnect. If this error occurs often, you may wish to increase the retransmission timeout. Some remote BMCs are considerably slower than others. Be patient with them, they're doing their best 🌸
  • "device not found" — The specified device could not be found. Please check configuration or inputs and try again.
  • "driver timeout" — Communication with the driver or device has timed out. Please try again.
  • "message timeout" — Communication with the driver or device has timed out. Please try again.
  • "BMC busy" — The BMC is currently busy. It may be processing information or have too many simultaneous sessions to manage. Please wait and try again. Give it a minute, it's overwhelmed 🫶
  • "could not find inband device" — An inband device could not be found. Please check configuration or specify specific device or driver on the command line.
  • "driver timeout" — The inband driver has timed out communicating to the local BMC or service processor. The BMC or service processor may be busy or (worst case) possibly non-functioning. Worst case is genuinely worst case here, no cap 😭
  • "internal IPMI error" — An IPMI error has occurred that FreeIPMI does not know how to handle. Please e-mail <freeipmi-users@gnu.org> to report the issue. Report it bestie, they want to know 💌

🛠️ WORKAROUNDS 🛠️

Okay bestie, listen — literally every vendor out there ships their own little IPMI snowflake, and some of them implemented the protocol wrong. Like, not even a little wrong. Fully wrong. So here's the tea on the workarounds FreeIPMI has available for compliance drama it's already discovered. Where possible these are done transparently and you'll never notice — but some of them you have to explicitly ask for with the -W option. 💅

The hardware listed below may only indicate the hardware that a problem was discovered on. Newer versions of hardware may fix the problems indicated below. Similar machines from vendors may or may not exhibit the same problems. And plot twist — different vendors may license their firmware from the same IPMI firmware developer, so it may genuinely be worth trying the workarounds listed below even if your motherboard is not listed. iykyk.

If you believe your hardware has an additional compliance issue that needs a workaround to be implemented, please contact the FreeIPMI maintainers at <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. They will absolutely want to hear about it. 🫶

  • assumeio — this workaround flag assumes inband interfaces talk to system I/O instead of being memory-mapped. It works around systems that report invalid base addresses. If you're hitting this you may see device not supported or could not find inband device errors. Issue observed on HP ProLiant DL145 G1.
  • spinpoll — this workaround flag tells some inband drivers (most notably the KCS driver) to spin while polling instead of putting the process to sleep. This may significantly improve the wall clock running time of tools, because an operating system scheduler's granularity may be much larger than the time it takes to perform a single IPMI message transaction. The tradeoff? By spinning, your system may be performing less useful work by not contexting out the tool for a more useful task. Effort vs. vibes, honestly.
  • authcap — this workaround flag skips early checks for username capabilities, authentication capabilities, and K_g support, and just lets IPMI authentication succeed. It works around multiple issues where the remote system doesn't properly report username capabilities, authentication capabilities, or K_g status. Hitting this? You may see username invalid, authentication type unavailable for attempted privilege level, or k_g invalid errors. Issue observed on Asus P5M2/P5MT-R/RS162-E4/RX4, Intel SR1520ML/X38ML, and Sun Fire 2200/4150/4450 with ELOM.
  • nochecksumcheck — this workaround flag tells FreeIPMI to not check the checksums returned from IPMI command responses. It works around systems that return invalid checksums due to implementation errors, where the packet is otherwise valid. ⚠️ Users are cautioned on the use of this option, as it removes validation of packet integrity in a number of circumstances. However, it is unlikely to be an issue in most situations. Hitting this? You may see connection timeout, session timeout, or password verification timeout errors. On IPMI 1.5 connections, the noauthcodecheck workaround may also needed too. Issue observed on Supermicro X9SCM-iiF, Supermicro X9DRi-F, and Supermicro X9DRFR.
  • idzero — this workaround flag lets empty session IDs be accepted by the client. It works around IPMI sessions that report empty session IDs to the client. Hitting this? You may see session timeout errors. Issue observed on Tyan S2882 with M3289 BMC.
  • unexpectedauth — this workaround flag allows unexpected non-null authcodes to be checked as though they were expected. It works around an issue when packets contain non-null authentication data when they should be null due to disabled per-message authentication. Hitting this? You may see session timeout errors. Issue observed on Dell PowerEdge 2850,SC1425. Confirmed fixed on newer firmware. 💀
  • forcepermsg — this workaround flag forces per-message authentication to be used no matter what is advertised by the remote system. It works around an issue when per-message authentication is advertised as disabled on the remote system, but it's actually required for the protocol. Hitting this? You may see session timeout errors. Issue observed on IBM eServer 325.
  • endianseq — this workaround flag flips the endian of the session sequence numbers so the session can continue properly. It works around IPMI 1.5 session sequence numbers that are the wrong endian. Hitting this? You may see session timeout errors. Issue observed on some Sun ILOM 1.0/2.0 (depends on service processor endian).
  • noauthcodecheck — this workaround flag tells FreeIPMI to not check the authentication codes returned from IPMI 1.5 command responses. It works around systems that return invalid authentication codes due to hashing or implementation errors. ⚠️ Users are cautioned on the use of this option, as it removes an authentication check verifying the validity of a packet. However, in most organizations, this is unlikely to be a security issue. Hitting this? You may see connection timeout, session timeout, or password verification timeout errors. Issue observed on Xyratex FB-H8-SRAY, Intel Windmill, Quanta Winterfell, and Wiwynn Windmill.
  • intel20 — this workaround flag handles several Intel IPMI 2.0 authentication issues. The issues covered include padding of usernames, and password truncation if the authentication algorithm is HMAC-MD5-128. Hitting this? You may see username invalid, password invalid, or k_g invalid errors. Issue observed on Intel SE7520AF2 with Intel Server Management Module (Professional Edition).
  • supermicro20 — this workaround flag handles several Supermicro IPMI 2.0 authentication issues on motherboards w/ Peppercon IPMI firmware. The issues covered include handling invalid length authentication codes. Hitting this? You may see password invalid errors. Issue observed on Supermicro H8QME with SIMSO daughter card. Confirmed fixed on newerver firmware.
  • sun20 — this workaround flag handles several Sun IPMI 2.0 authentication issues. The issues covered include invalid lengthed hash keys, improperly hashed keys, and invalid cipher suite records. Hitting this? You may see password invalid or bmc error errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM. This workaround automatically includes the opensesspriv workaround.
  • opensesspriv — this workaround flag slightly alters FreeIPMI's IPMI 2.0 connection protocol to work around an invalid hashing algorithm used by the remote system. The privilege level sent during the Open Session stage of an IPMI 2.0 connection is used for hashing keys instead of the privilege level sent during the RAKP1 connection stage. Hitting this? You may see password invalid, k_g invalid, bad rmcpplus status code, or privilege level cannot be obtained for this user errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM, Inventec 5441/Dell Xanadu II, Supermicro X8DTH, Supermicro X8DTG, Intel S5500WBV/Penguin Relion 700, Intel S2600JF/Appro 512X, Quanta QSSC-S4R/Appro GB812X-CN, Dell C5220, and the OpenIPMI software BMC. This workaround is automatically triggered with the sun20 workaround.
  • integritycheckvalue — this workaround flag works around an invalid integrity check value during an IPMI 2.0 session establishment when using Cipher Suite ID 0. The integrity check value should be 0 length, however the remote motherboard responds with a non-empty field. Hitting this? You may see k_g invalid errors. Issue observed on Supermicro X8DTG, Supermicro X8DTU, and Intel S5500WBV/Penguin Relion 700, and Intel S2600JF/Appro 512X.
  • No IPMI 1.5 Support — some motherboards that support IPMI 2.0 have been found to not support IPMI 1.5. Hitting this? You may see ipmi 2.0 unavailable or connection timeout errors. This issue can be worked around by using IPMI 2.0 instead of IPMI 1.5 by specifying --driver-type=LAN_2_0. Issue observed on a number of HP and Supermicro motherboards.

🌸 EXAMPLES 🌸

Real commands, no gatekeeping. Go off. ✨

# ipmi-chassis --get-chassis-status

Get the chassis status of the local machine. Your own machine! Main character energy.

# ipmi-chassis -h ahost -u myusername -p mypassword --get-chassis-status

Get the chassis status of a remote machine using IPMI over LAN.

# ipmi-chassis -h mycluster[0-127] -u myusername -p mypassword --get-chassis-status

Get the chassis status across a cluster using IPMI over LAN. A whole cluster, bestie. We love scaling. 👑

# ipmi-chassis -h ahost -u myusername -p mypassword --chassis-control=POWER-UP

Power on a remote machine using IPMI over LAN. Slay.

📋 DIAGNOSTICS 📋

Upon successful execution, exit status is 0. On error, exit status is 1.

If multiple hosts are specified for communication, the exit status is 0 if and only if all targets successfully execute. Otherwise the exit status is 1. Like, one flop and the whole thing flops. No partial credit. 😭

💀 KNOWN ISSUES 💀

On older operating systems, if you input your username, password, and other potentially security relevant information on the command line, this information may be discovered by other users when using tools like the ps(1) command or looking in the /proc file system. It is generally more secure to input password information with options like the -P or -K options. Configuring security relevant information in the FreeIPMI configuration file would also be an appropriate way to hide this information. Please don't be that girl with the password in your shell history. 🙈

In order to prevent brute force attacks, some BMCs will temporarily "lock up" after a number of remote authentication errors. You may need to wait awhile in order for this temporary "lock up" to pass before you may authenticate again. It's not ghosting you, it's just on cooldown. 💅

🐛 REPORTING BUGS 🐛

Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. They genuinely want to know, fr fr.

Copyright © 2007-2015 FreeIPMI Core Team

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

🦋 SEE ALSO 🦋

freeipmi(7), bmc-device(8), ipmi-config(8), ipmipower(8)

http://www.gnu.org/software/freeipmi/

Okay that's the whole page, bestie — go configure some chassis. 💖

This lovely little number is from ipmi-chassis version 1.6.20, dated 2026-10-05, and it'll always be IPMI-CHASSIS(8) to me. 🎀 periodt.

📦 where this page comes from