Wednesday, May 9, 2012

freeipmi *-config tools primer

Basic usage of bmc-config, pef-config, and other freeipmi *-config tools

The documentation below should work for all freeipmi *-config commands. It only discusses how to connect to a BMC (including iDRAC, iLO, etc) then read from and modify its configuration. I picked bmc-config to demonstrate program usage, though the same parameters will work for all the related commands.

In some places I reference the "-f" parameter which allows you to specify a filename. In newer versions it appears to still work but have been deprecated by "-n".

Local vs. Remote

All of the documentation below should work both locally and remotely, assuming a correct configuration.

Local configuration:
In Linux, load the following modules with modprobe: ipmi_si, ipmi_devintf, ipmi_msghandler. Order might matter.

Remote configuration:
IPMI
over LAN must be enabled and you probably need a certain privilege
level (haven't tried with anything lower than Administrator for the root
user). I've never had to mess with the user privilege level, but it's
easy enough to change.

If you are doing IPMI over LAN, simply add the following flags:

-h hostname

-u username

-p password

-D LAN_2_0 # only if your BMC can't talk 1.5, such as HP and some newer Dells I've used. Can usually be omitted.

Operations

There are three standard operations that can be performed:

checkout (-o)

commit (-c)

diff (-d)

The "-d" parameter can be used to show differences between a file (add "-f file") and the live config.

To "checkout" (i.e. print) the current configuration, run:

# bmc-config -o

To save the configuration to a file:# bmc-config -o -f filename

To diff the file and the bmc's live config:# bmc-config -d -f filename

To commit a file:# bmc-config -c -f filename

Sections of key-value pairs

freeipmi breaks everything up into sections which contain key-value pairs. You can operate on all settings at once, a section at once, or just one key-value pair.

The
output starts with the "Section" and the section name, "User2" in this
case. This is so that this text can be fed directly back into
bmc-config's commit option. The lines in the Section block are key
value pairs with comments. Lines starting with "##" are comments.
Lines without "##" are key-value pairs that are separated by spaces.

In the example above, one key is "Username" and its value is "root". Easy enough.

You may notice that "Password"
is shown as a comment. This is a security feature that makes it so the
password can't be retrieved. It can be set, however. The reason it is
commented out is because this text is meant to be directly usable as a
commit. A blank password or some placeholder would wipe out the
currently-configured password. If you want to set a new password,
remove the "##" on Password and add the password on the end of the line.

Note that the line above each key-value pair has a comment regarding acceptable values that can be used.

The text can be saved to a file, edited with $EDITOR_OF_CHOICE, then committed with "-c".

To commit changes from a single section or even the entire configuration:# bmc-config -c -f filename

Key-Value Pairs

It doesn't get much easier than working with key-value pairs. Here is the syntax for retrieving a value:

# bmc-config -o -e $SECTION:$KEY

For example:

# bmc-config -o -e User2:Username

Section User2 ## Give Username Username rootEndSection

To set a new value, the syntax is:

# bmc-config -o -e $SECTION:$KEY=$VALUE

For example:

# bmc-config -c -e User2:Enable_User=No

Tips

If you have a working system and one that's not working, grab the config off of both systems using "-o" and then diff the files. Alternatively, grab the config off of one and use "-d" to compare it with the live configuration on the other. This should show you what needs to be changed.

One other thing you can do to figure out how to change a setting is to grab a vendor-specific tool that accomplishes the same thing. Make changes with the tool and compare how the output of the freeipmi *-config (e.g bmc-config, pef-config, etc) changes. Sometimes it's nice not to have to install a vendor-specific tool on all of your systems, especially when the vendor software seems to find new ways not to install with every version change.

No comments:

Post a Comment

Please leave any comments, questions, or suggestions below. If you find a better approach than what I have documented in my posts, please list that as well. I also enjoy hearing when my posts are beneficial to others.

About Me

Ryan is the Operations Director for the Fulton Supercomputing Lab
at BYU. He has used Linux almost exclusively for over a
decade (with some BSD on the side) and has worked in the HPC field for eight years.