NAME¶
openipmi_cmdparms - Connection parmeters for OpenIPMI
SYNOPSIS¶
smi smi-num
lan [
-U username] [
-P password] [
-p[2]
port] [
-A authtype] [
-L privilege]
[
-s] [
-Ra auth alg] [
-Ri integ alg]
[
-Rc conf algo] [
-Rl] [
-Rk bmc key]
[
-H hackname]
host [
host]
DESCRIPTION¶
The connection parameters for OpenIPMI vary depending on the connection type.
This document describes the standard connection types; others may be available
from OEMs.
OPTIONS¶
- smi-num
- The SMI interface for the local connection. There may be
more than one BMC connection on a system and they are generally numbered,
like /dev/ipmi0, /dev/ipmi1, etc.
- -U username
- Use the given username for the LAN connection. If
none is given, then no username is used.
- -P password
- The password to use for the connection. If none is
given, the user is assumed to have an empty password
- -p[2] port
- The UCP port to connect to. This defaults to the
standard 623 port, so it is not necessary unless a special port is
required. Note that since you can have two connections (hosts), -p
is for the first host and -p2 is for the second host.
- -A authtype
- The authentication type to use, one of rmcp+,
md5, md2, straight, or none. If you don't
supply this, the most secure one available is chosen, in the order given
in the previous list.
- -L privilege
- The privilege to use for the connection. Lower
privileges cannot execute some commands. Privileges are: callback,
user, operator, admin, and oem. The default is
admin.
- -Ra authentication algorithm
- Set the RMCP+ authentication algorithm to use.
Options are: bmcpick, rakp_none, rakp_hmac_sha1, and
rakp_hmac_md5. The bmcpick option is used by default, which
means the BMC picks the algorithm it wants to use.
- -Ri integrity algorithm
- The RMCP+ integrity algorithm to use. This ensures
that the data has not be altered between the sender and receiver. Valid
options are: bmcpick, none, hmac_sha1,
hmac_md5, and md5. The bmcpick option is used by
default, which means the BMC picks the algorithm it wants to use.
- -Rc confidentiality algorithm
- The RMCP+ confidentiality (encryption) algorithm to
use. This keeps evesdroppers from seeing the data. Valid values are:
bmcpick, aes_cbc_128, xrc4_128, and xrc_40.
The bmcpick option is used by default, which means the BMC picks
the algorithm it wants to use.
- -Rl
- If this is specified, the username is looked up using the
privilege level along with the username. This allows the same name to have
different passwords with different privilege levels.
- -Rk BMC Key
- If the system requires two-key lookups, this specifies the
second key (the BMC key) to use. This is ignored if two-key lookups
are not enabled by the BMC.
- -H hackname
- Well, it always happens. Things in the field don't work
quite like they are supposed to. There was some vagueness in the first
IPMI specs and different vendors interpreted RMCP+ in different ways. This
allows different options to be supported. Try different hacks if your
RMCP+ systems don't authenticate properly. These are:
- rakp3_wrong_rolem
- Some systems use the incorrect Role(m) field in a specific
authentication message (the RAKP3 message). This is a common problem.
- rmcpp_integ_sik
- The original IPMI 2.0 spec specified the incorrect key to
use for the integrity key. This forces use of the Session Initiation Key.
The default is to use K(1)
- -s
- Make two connections to the BMC. This means the BMC has two
different IP addresses/ports that are equivalent. If this is specified, a
second host must be supplied. This is not the same as two connections to
two different BMCs. This must be a connection to the same BMC.
- host
- The IP address (either by name lookup or specified
directly) to connect to. If the -s is specified, two hosts must be
supplied.
The
-Ra,
-Ri,
-Rc,
-Rk and
-Rl options only
apply to RMCP+ connections and will be ignored if the connection does not
support RMCP+ or if a non-RMCP+ authentication type is specified.
SEE ALSO¶
ipmish(8),
openipmicmd(8),
solterm(1)
KNOWN PROBLEMS¶
This is excessively complicated, but the defaults should be good.
AUTHOR¶
Corey Minyard <cminyard@mvista.org>