openipmigui(1)

πŸ’– openipmigui β€” GUI interface to an IPMI system πŸ’–

okay bestie, sit down, hydrate, because we're about to talk about openipmigui(1) β€” the section 1 manual page for the GUI interface to an IPMI system. she's pretty, she's powerful, she will absolutely let you stare at a tree of hardware until you understand your server's feelings. let's go 🫢


✨ SYNOPSIS ✨

openipmigui [--dmsg] [--drawmsg] [--glib12] [--trace] [--logstderr] [-n]
[-p preffile]

that's the whole vibe check right there. now let's unpack her.


🌸 DESCRIPTION 🌸

openipmigui is a GUI interface that uses the OpenIPMI library. what does it give you? a tree-structured view of all the IPMI domains it's connected to. literally a whole family tree of your hardware, iconic.

by default, openipmigui starts up with no connections or anything of that nature. you have to open connections to domains yourself, bestie β€” she's not gonna do it for you, she's not your mom. however, you can save your current configuration, the current domains, and some GUI settings, and those will be automatically restored at startup. so she does remember things. she's thoughtful like that. ✨

the main window has a tree on the left and a log window on the right. the log window captures informational and error logs from OpenIPMI. but listen β€” events are NOT reported in the log window. if you want to see events you have to open an SEL window for a domain. no shortcuts, no cap. 😀


πŸŽ€ OPTIONS πŸŽ€

  • --dmsg β€” turns on message debugging. this dumps all messages to debug log output. all of them. every single one. she's not holding back πŸ’…
  • --drawmsg β€” turns on raw message debugging, which dumps all low-level messages to debug log output. this differs from normal message debugging in that all protocol messages are also dumped, not just IPMI messages. so yeah, more messages. more. 🫠
  • --dmem β€” turns on memory debugging. this causes memory allocations and deallocations to be checked. when the program terminates, it will dump all memory that was not properly freed (leaked), plus overruns, writing of freed memory, or other types of memory errors. she's doing a full audit of your messy room, bestie 🧹
  • --logstderr β€” sends all logs to standard error output as well as the GUI console. two places. because one is never enough πŸ’–
  • --trace β€” turns on python tracing so that all python procedure calls entered and exited will be printed out. every entrance, every exit, narrated. main character energy for your call stack πŸ‘‘
  • -n β€” turns off reading of the preferences file at startup. fresh start, no baggage, we love a clean slate πŸ¦‹
  • -p preffile β€” use preffile as the name of the preferences file instead of $HOME/.openipmigui.startup. you get to pick where she keeps her diary πŸ““

the main menu bar has two pull-down menus: File and View. that's it. minimal. chic. πŸŽ€

the File menu contains the Exit, Open Domain, and Save Prefs commands:

  • Exit β€” does exactly what it says. and it does not prompt to be sure you want to exit. no "are you sure??" no second chances. she trusts you. or she's chaos. either way, it's giving πŸ’€
  • Open Domain β€” this is how you establish a connection to an IPMI system. the whole point, honestly.
  • Save Prefs β€” stores the current domains and the configuration of the main GUI window. these settings will be restored at startup. the settings are stored in $HOME/.openipmigui.startup, and this file may be removed to clear all the settings. delete her diary, reset the vibe. πŸ™ˆ

the View menu contains commands to expand and contract the entire tree. zoom in, zoom out, spiritually. ✨


πŸ¦‹ TREE VIEW πŸ¦‹

the tree window has a top-level list of all the domains for which OpenIPMI has connections (or pending connection). each domain expands into domain-specific information plus a list of entities and Management Controllers (MCs) for that domain.

right click drives most of the operations in the tree window. many tree elements have pull-down menus driven by a right mouse button click. when in doubt, click. that's the whole tutorial, bestie. when in doubt, CLICK. πŸ’…

color is used in the GUI to denote error status, and shading is used to denote availability. here's the legend:

  • yellow means warning
  • red means critical
  • blue means non-recoverable
  • black means no error

if a sensor has an error, the tree entry for that sensor changes colors. these errors propagate up, so the entity containing that sensor will be the same color as the most critical error for the sensors underneath it. same goes for the domain β€” it'll be the same color as the most critical error for the entities underneath it. so if you just watch the domain, you can tell if a system is in trouble from the top-level view alone, and then drill down to find the problem. it's the group chat of error reporting, fr fr πŸ”₯

if a tree entry is shaded, it means the entry has information identifying it but does not exist. for instance: a domain with no connection, an entity that is not present, or an MC that is not present. ghosted, but make it technical πŸ‘»

note: all information visible in the tree is polled. and only visible information is polled. so if you expose something by expanding a tree element or scrolling, it may take a few seconds before the data is updated. patience, bestie, she's getting there 🌸

πŸ‘‘ DOMAINS πŸ‘‘

the domains contain various high-level information and an aggregation of all the System Event Logs (SELs) contained within it.

the SEL Rescan Time and IPMB Rescan Time are settable via right-click; these values are remembered when saved and restored. (note: these values in the MC-specific entries are not saved and restored β€” only the domain level ones. so keep that in mind 😭)

right clicking on the domain gives you a set of operations, including the ability to view the SEL. slay.


🧚 ENTITIES 🧚

the Entities element under the domain element contains a list of the entities discovered for that domain. and heads up β€” this is only the top-level entities (ones not contained in other entities). entities contained in other entities are listed under their parent entity. this keeps the clutter down for very complicated systems, like ATCA. she's organized, she's tidy, she's that girl πŸ’–

  • if the entity is hot-swappable, hot-swap activation and deactivation commands are available via right-click on the entity. πŸ”₯
  • if the entity has FRU information, you can view that via a right-click command too.

the information under an entity also contains a sensors and controls list for the entity. 🌈


⭐ SENSORS ⭐

sensors are available under the entity they belong to. sensor information is beyond the scope of this document, because IPMI sensors are very complex β€” see the IPMI document from OpenIPMI for information about sensors. πŸ“–

as expected, right-clicking on a sensor gives operations available on that sensor. ✨


πŸ’œ CONTROLS πŸ’œ

controls are available under the entity they belong to. control information is beyond the scope of this document, because IPMI controls are very complex β€” see the IPMI document from OpenIPMI for information about controls. πŸ“–

as expected, right-clicking on a control gives operations available on that control. πŸ’…


πŸ”₯ MANAGEMENT CONTROLLERS (MCs) πŸ”₯

an MC is the intelligent node in an IPMI system. it is not generally required to know about MCs for normal IPMI sensor and control operations. you do need access to MCs, though, for system configuration. so like, casual users can ignore her, but if you're doing config work she's your girl.

an MC contains a lot of information about itself and its capabilities. this is generally automatically interpreted by OpenIPMI, but the information is available for view. for instance, if an MC contains an SEL device, OpenIPMI will automatically handle getting events from it β€” but you can also view this setting under the MC information. both. and. ✨

a number of operations are available under the right-click menu on the MC; most of these are self-explanatory. the MC is generally configured via the Channel Info command under this. πŸ‘‘


πŸ’™ CONNECTIONS πŸ’™

a set of connections for the domain is listed under the domain. each connection has one or more ports. the state of these ports may be viewed by color:

  • if a port is yellow (warning), it is down.
  • if a connection is red (severe), then all its ports are down.
  • if all connections are down, the "Connections" tree item turns blue (critical). πŸ’€

🌸 CHANNEL INFO 🌸

if you right click on an MC, it will show a Channel Info entry. this is used to configure the LAN and channel information for the MC. if you select this, it pulls up a list of channels in a tree view.

note: unlike the main tree, this information is not dynamically updated β€” it will not change if the underlying data changes. she's a snapshot, not a livestream. πŸ“Έ

to configure individual channels, expand them.

  • the Info settings are read only and cannot be changed. look, don't touch πŸ‘€
  • the User Access settings can be changed by right-clicking on them.
note: the change is not immediate β€” you must use the Save button at the bottom of the window to save the changes you have made. πŸ™ˆ

also, there are two versions of the User Access settings:

  • one is volatile, and will update the current settings for the MC, but if the MC restarts, the non-volatile settings will be restored.
  • setting the non-volatile settings will not cause an immediate change, but those changes will be restored on the next MC restart.

some channels have user information; you can configure these by selecting that command in the right-click menu of a channel. 🫢

LAN channels also have LAN configuration; you can configure these by selecting that command in the right-click menu of a channel. 🌈


πŸŽ€ USER INFO πŸŽ€

IPMI systems with remote access have users that can be used to log in. these users are configured by the User Info command in the channel listing.

note: some user settings (the name and password) are global to all channels on the MC. 🌍

due to the IPMI spec and some unfortunate implementation bugs, some weird issues exist with this information. buckle up, bestie 😭

  • the user has an Enabled value that tells whether the user is enabled or not. when initially displayed, this field shows as a "?" because this field is not readable. it will be displayed as the actual value when it is modified, but will not be changed otherwise.
  • there is also a session limit field that gives the maximum number of sessions a user is allowed to make. this field is also not readable and displays as a "?" when first displayed. this field is marked as optional in the IPMI spec, which means the field does not have to be supplied. some implementations, however, require this field to be set. if you get a DataLenInv error back from your system when setting something, you must set the field to something for any value to be set. generally, setting it to zero disables the field and is the right thing to do. 🫠

⭐ LANPARMS ⭐

in the channel display on a 8023_LAN channel, a LANPARM configuration command is available. this pulls up all the parameters for the LAN and allows them to be set. right-clicking on an item allows it to be changed. πŸ’…


🧚 PEFPARMS 🧚

if an MC supports PEF, it will have a "PEF Parms" menu item in the pulldown menu for the MC. this pulls up all the parameters for the PEF and allows them to be set. right-clicking on an item allows it to be changed. ✨


πŸ’œ SOLPARMS πŸ’œ

in the channel display on a 8023_LAN channel, a LANPARM configuration command is available if the MC supports SOL (Serial Over LAN). this pulls up all the parameters for the LAN and allows them to be set. right-clicking on an item allows it to be changed. πŸ”₯


okay that's part 1, bestie β€” there's more coming, don't go anywhere πŸ’–

✨ SOL (Serial Over LAN, bestie) ✨

Okay so on a connection, there's this menu item called "Open SOL". If the BMC on the far end of your connection has SOL (Serial Over LAN) support, then congrats babe, you can establish a serial connection with that BMC β€” assuming it's configured properly and you've got the proper rights. No rights, no serial. πŸ’…

When you pick it, you get a whole new connection with a VT100/ANSI terminal emulator. And here's the thing: the connection is not open yet. You gotta open it yourself (under "File") to actually establish it. When the status down at the bottom right says "connected", you're ready to type, bestie. πŸŽ€

If something goes wrong, the connection may drop and you'll have to reopen it. Annoying but true. You can also close the connection from the file menu, or just quit the emulator. Your call. πŸ¦‹


πŸŽ›οΈ The "Controls" menu for SOL

The "Controls" menu on the SOL connection is stacked β€” it's got a large number of settings for SOL. These let you manipulate various values on the remote side of the connection. Obsessed honestly. Here they all are:

  • Accept Input β€” If this is disabled, data from the BMC gets refused, which effectively flow-controls the data (assuming the BMC actually supports that properly… some don't πŸ™ˆ).
  • Use Encryption β€” Encrypts the data on the LAN using the RMCP+ encryption negotiated for the connection. Only available when the connection is closed β€” you literally cannot change this dynamically, no cap.
  • Use Authentication β€” Authenticates the data on the LAN using the RMCP+ authentication negotiated for the connection. Same deal: only available when the connection is closed, cannot be changed dynamically.
  • Deassert CTS/DCD/DSR on connect β€” Don't raise the lines when a connection is made. This lets you do stuff like set the baud rate before the device on the far end of the serial port even knows there's a connection. Sneaky but iconic.
  • CTS Assertable β€” If set, the BMC has control over the CTS line. Otherwise the CTS line is deasserted.
  • DCD/DSR Asserted β€” Sets the DCD and DSR lines.
  • RI Asserted β€” Asserts the Ring Indicator line, which can be used for remote wakeup on some systems (though, ngl, with IPMI you kinda have to wonder why you wouldn't just use IPMI for this 😭).
  • Set Ack Timeout β€” Sets the timeout for waiting on an ACK from the BMC.
  • Set Ack Retries β€” Sets how many times a packet gets retried before the connection is closed.
  • Send Break β€” Sends a 300ms break signal to the remote serial port. πŸ’₯
  • Serial Rate β€” Sets the bitrate on the serial port. Not all systems support this. Some, in fact, completely ignore this setting and use 19.2K instead. Also heads up: this is only the volatile rate. The non-volatile rate setting is done with SOLPARM.
  • Serial Alert Behavior β€” Sets what to do when an IPMI alert occurs and is going out the serial port somehow. If set to "succeed", the SoL session will be disconnected when an alert comes out. 🚨
  • Queue Flush β€” Lets you flush various queues.

πŸ‘€ SEE ALSO


πŸ’€ KNOWN PROBLEMS

Some functionality is missing. If you wanna work on something, check the list in the swig/python/openipmigui/TODO. Go off, main character. 🫢


πŸ‘‘ AUTHOR

Corey Minyard <cminyard@mvista.com>


And that's a wrap on the whole page, bestie!! πŸ’– This little beauty comes from OpenIPMI, dated 05/13/03, and it's page openipmigui(1) in the manual. Go forth and GUI responsibly. 🌸✨