ipmiseld - IPMI SEL logging daemon
daemon polls the system event log (SEL) of specified hosts
and stores the logs into the local syslog. By default, the daemon can also
make best efforts to manage the remote SEL's buffer to ensure events are never
lost. Recent logging data will be cached to disk to ensure that SEL events are
not missed in the event the client or server is rebooted.
Many of the options for this daemon are very similar to the ipmi-sel(8)
tool. It can be configured to log the local host, a remote host, or a range of
hosts to the local syslog. It can be configured via the command line arguments
listed below or via the /etc/freeipmi//ipmiseld.conf configuration file.
Listed below are general IPMI options, tool specific options, trouble shooting
information, workaround information, examples, and known issues. For a general
introduction to FreeIPMI please see freeipmi(7).
The following options are general options for configuring IPMI communication and
executing general tool commands.
- -D IPMIDRIVER, --driver-type=IPMIDRIVER
- Specify the driver type to use instead of doing an auto selection. The
currently available outofband drivers are LAN and LAN_2_0, which perform
IPMI 1.5 and IPMI 2.0 respectively. The currently available inband drivers
are KCS, SSIF, OPENIPMI, SUNBMC, and INTELDCMI.
- Do not probe in-band IPMI devices for default settings.
- Specify the in-band driver address to be used instead of the probed value.
DRIVER-ADDRESS should be prefixed with "0x" for a hex
value and '0' for an octal value.
- Specify the in-band driver device path to be used instead of the probed
- Specify the in-band driver register spacing instead of the probed value.
Argument is in bytes (i.e. 32bit register spacing = 4)
- Specify the in-band driver target channel number to send IPMI requests
- Specify the in-band driver target slave number to send IPMI requests
- -h IPMIHOST1,IPMIHOST2,...,
- Specify the remote host(s) to communicate with. Multiple hostnames may be
separated by comma or may be specified in a range format; see HOSTRANGED
SUPPORT below. An optional port can be specified with each host, which may
be useful in port forwarding or similar situations.
- -u USERNAME, --username=USERNAME
- Specify the username to use when authenticating with the remote host. If
not specified, a null (i.e. anonymous) username is assumed. The user must
have atleast USER privileges in order for this tool to operate fully.
- -p PASSWORD, --password=PASSWORD
- Specify the password to use when authenticationg with the remote host. If
not specified, a null password is assumed. Maximum password length is 16
for IPMI 1.5 and 20 for IPMI 2.0.
- -P, --password-prompt
- Prompt for password to avoid possibility of listing it in process
- -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 the either the string 'abc' or the string '0x616263'
- -K, --k-g-prompt
- Prompt for k-g to avoid possibility of listing it in process lists.
- Specify the session timeout in milliseconds. Defaults to 20000
milliseconds (20 seconds) if not specified.
- Specify the packet retransmission timeout in milliseconds. Defaults to
1000 milliseconds (1 second) if not specified. The retransmission timeout
cannot be larger than the session timeout.
- -a AUTHENTICATION-TYPE,
- Specify the IPMI 1.5 authentication type to use. The currently available
authentication types are NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5.
Defaults to MD5 if not specified.
- -I CIPHER-SUITE-ID,
- Specify the IPMI 2.0 cipher suite ID to use. The Cipher Suite ID
identifies a set of authentication, integrity, and confidentiality
algorithms to use for IPMI 2.0 communication. The authentication algorithm
identifies the algorithm to use for session setup, the integrity algorithm
identifies the algorithm to use for session packet signatures, and the
confidentiality algorithm identifies the algorithm to use for payload
encryption. Defaults to cipher suite ID 3 if not specified. The following
cipher suite ids are currently supported:
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,
- Specify the privilege level to be used. The currently available privilege
levels are USER, OPERATOR, and ADMIN. Defaults to OPERATOR if not
- Specify an alternate configuration file.
- -W WORKAROUNDS,
- Specify workarounds to vendor compliance issues. Multiple workarounds can
be specified separated by commas. A special command line flag of
"none", will indicate no workarounds (may be useful for
overriding configured defaults). See WORKAROUNDS below for a list of
- Turn on debugging.
- -?, --help
- Output a help list and exit.
- Output a usage message and exit.
- -V, --version
- Output the program version and exit.
The following options are specific to Ipmiseld.
- Log verbose information. This option will log additional information. Most
notably it will output additional hex codes to given information on
ambiguous SEL entries or SEL records. For example, it will output
Generator ID hex codes for sensors without names. Additional non-critical
SEL errors or issues will also be logged. Somewhat common errors, such as
timeouts or invalid hostnames, will output with increased verbosity.
- -t SENSOR-TYPE-LIST,
- Specify sensor types of SEL events to log. By default, all sensor types
are logged. A special command line type of "all", will indicate
all types should be shown (may be useful for overriding configured
defaults). Multiple types can be separated by commas or spaces. Users may
specify sensor types by string (see --list-sensor-types in
ipmi-sel(8)) or by number (decimal or hex).
- -T SENSOR-TYPE-LIST,
- Specify sensor types of SEL events to not log. By default, no sensor types
are filtered. A special command line type of "none", will
indicate no types should be excluded (may be useful for overriding
configured defaults). Multiple types can be separated by commas or spaces.
Users may specify sensor types by string (see --list-sensor-types
in ipmi-sel(8)) or by number (decimal or hex).
- Log only system event records (i.e. don't log OEM records).
- Log only OEM event records (i.e. don't log system event records).
- Specify an alternate event state configuration file.
- Attempt to interpret OEM data, such as event data, sensor readings, or
general extra info, etc. If an OEM interpretation is not available, the
default output will be generated. Correctness of OEM interpretations
cannot be guaranteed due to potential changes OEM vendors may make in
products, firmware, etc. See OEM INTERPRETATION below for confirmed
supported motherboard interpretations.
- Output sensor names prefixed with their entity id and instance number when
appropriate. This may be necessary on some motherboards to help identify
what sensors are referencing. For example, a motherboard may have multiple
sensors named 'TEMP'. The entity id and instance number may help clarify
which sensor refers to "Processor 1" vs. "Processor
- Output non-abbreviated units (e.g. 'Amps' instead of 'A'). May aid in
disambiguation of units (e.g. 'C' for Celsius or Coulombs).
- Specify event states to be filtered out and not logged. Possible inputs
are NOMINAL, WARNING, CRITICAL, and NA. Multiple states can be listed
separted by comma. The special case string of "none" will
indicate no event states should be excluded (may be useful for overriding
- Specify SEL fullness warning threshold as an integer percentage. When the
SEL is past this percentage full, a warning will be output indicating that
SEL is nearly full. Specify 0 to disable warning logs. Defaults to
- Specify SEL fullness clear threshold as an integer percentage. When the
SEL is past this percentage full, ipmiseld will attempt to clear
the SEL. Specify 0 to disable clearing. When the SEL is full, it will be
the responsibility of the user to clear the SEL manually if clearing is
disabled. Defaults to 0. If specified to a non-zero value, be careful that
the clearing of the SEL could affect other applications that monitor the
SEL, such as monitoring applications that use ipmi-sel(8) or
- Specify the format of the log output when a SEL system event is
encountered. Defaults to "SEL System Event: %d, %t, %s, %I, %E"
if logging locally, "SEL System Event(%h): %d, %t, %s, %I, %E"
if logging outofband or with hostranges. See SEL LOG FORMAT STRING below
for formatting details.
- Specify the format of the log output when a SEL OEM timestamped event is
encountered. Defaults to "SEL OEM Event: %d, %t, %I, %o" if
logging locally, "SEL OEM Event(%h): %d, %t, %I, %o" if logging
outofband or with hostranges.. See SEL LOG FORMAT STRING below for
- Specify the format of the log output when a SEL OEM non-timestamped event
is encountered. Defaults to "SEL OEM Event: %I, %o" if logging
locally, "SEL OEM Event(%h): %I, %o" if logging outofband or
with hostranges.. See SEL LOG FORMAT STRING below for formatting
- Specify the poll interval to check the SEL for new events. Defaults to 300
seconds (i.e. 5 minutes).
- Specify the log facility to use. Defaults to LOG_DAEMON. Legal inputs are
LOG_DAEMON, LOG_USER, LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, LOG_LOCAL3,
LOG_LOCAL4, LOG_LOCAL5, LOG_LOCAL6, LOG_LOCAL7.
- Specify the log priority to use. Defaults to LOG_ERR. Legal inputs are
LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE,
- Specify an alternate cache directory location for ipmiseld to use.
The cache directory will be used to cache a wide variety of data,
including the SDR and recent logging information to ensure log entries are
not missed on reboots and other system failures.
- Ignore SDR related processing. May lead to incomplete or less useful
information being output, however it will allow functionality for systems
without SDRs or when the correct SDR cannot be loaded.
- Re-download the SDR on start even if it is not out of date. This may help
work around systems that do not properly timestamp SDR modification
- On startup, clear any SEL being monitored. May be useful the first time
running ipmiseld to avoid warning messages or SEL clears until a
long time in the future.
- Specify the number of threads for parallel SEL polling. This option is
very similar to the --fanout option in ipmi-sel(8) but the
threads are created only once on initialization for faster processing.
Defaults to 8, however the threadpool count will always be decreased if
the number of nodes specified is less than the number of threads.
- Do not daemonize, output the current SEL of configured hosts as a test of
current settings and configuration. SEL entries will be output to stdout
instead of syslog.
- Run daemon in the foreground. SEL entries will be output to stdout instead
SEL LOG FORMAT STRING¶
The output format of log messages can be adjusted via the
options. Options such as
can further adjust the output format. The
following conversion directives will allow the user to output specifics of
each SEL event that occurs.
For System, OEM timestamped, and OEM non-timestamped events
%h - target host, useful if logging from multiple hosts
%i - record ID in decimal
%I - event state interpretation (NOMINAL, WARNING, or CRITICAL)
For System and OEM timestamped events
%t - time in format H:M:S using 24 hour clock
%d - date in format D-M-YEAR
For System events
%T - sensor type
%s - sensor name
%e - event data 1 string
%f - event data 2 string 
%h - event data 3 string
%c - combined event data 2 and event data 3 string
%p - event data 2 previous state string
%S - event data 2 severity string
%E - combined event data 1, 2, and 3 string
%k - event direction
For OEM timestamped events
%m - manufacturer id
For OEM timestamped and OEM non-timestamped events
%o - oem data in hex
%O - OEM supplied string describing the event (depends on manufacturer)
Multiple hosts can be input either as an explicit comma separated lists of hosts
or a range of hostnames in the general form: prefix[n-m,l-k,...], where n <
m and l < k, etc. The later form should not be confused with regular
expression character classes (also denoted by ). For example, foo does
not represent foo1 or foo9, but rather represents a degenerate range: foo19.
This range syntax is meant only as a convenience on clusters with a prefixNN
naming convention and specification of ranges should not be considered
necessary -- the list foo1,foo9 could be specified as such, or by the range
Some examples of range usage follow:
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
As a reminder to the reader, some shells will interpret brackets ([ and ]) for
pattern matching. Depending on your shell, it may be necessary to enclose
ranged lists within quotes.
In-band IPMI Communication will be used when the host "localhost" is
specified. This allows the user to add the localhost into the hostranged
Most often, IPMI problems are due to configuration problems.
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
tool can be used to check and/or change these
Inband IPMI problems are typically caused by improperly configured drivers or
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
Listed below are many of the common issues for error messages. For additional
support, please e-mail the <firstname.lastname@example.org> mailing list.
"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.
"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.
"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
"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.
"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
"could not find inband device" - An inband device could not be found.
Please check configuration or specify specific device or driver on the command
"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.
"internal IPMI error" - An IPMI error has occurred that FreeIPMI does
not know how to handle. Please e-mail <email@example.com> to report
Some timestamps in the SEL may report a date of 1-Jan-1970, the epoch for SEL
timestamps. This timestamp is not necessarily incorrect. It usually indicates
a hardware event that occurred before a timestamp in firmware has been
initialized. For example, certain hardware components will have their internal
clocks reset during a power cycle.
However, if the internal clock of the SEL appears to be regularly incorrect, you
may need to set the SEL time. This can be done using bmc-device(8).
The following are common SEL related messages.
"sel config file parse error" - A parse error was found in the sel
event interpretation configuration file. Please see
With so many different vendors implementing their own IPMI solutions, different
vendors may implement their IPMI protocols incorrectly. The following
describes a number of workarounds currently available to handle discovered
compliance issues. When possible, workarounds have been implemented so they
will be transparent to the user. However, some will require the user to
specify a workaround be used via 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.
Different vendors may license their firmware from the same IPMI firmware
developer, so it may be worthwhile to try workarounds listed below even if
your motherboard is not listed.
If you believe your hardware has an additional compliance issue that needs a
workaround to be implemented, please contact the FreeIPMI maintainers on
<firstname.lastname@example.org> or <email@example.com>.
- This workaround flag will assume inband interfaces communicate
with system I/O rather than being memory-mapped. This will work around systems
that report invalid base addresses. Those hitting this issue may see
"device not supported" or "could not find inband device"
errors. Issue observed on HP ProLiant DL145 G1.
- This workaround flag will inform some inband drivers (most
notably the KCS driver) to spin while polling rather than 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. However, by
spinning, your system may be performing less useful work by not contexting out
the tool for a more useful task.
- This workaround flag will skip early checks for username
capabilities, authentication capabilities, and K_g support and allow IPMI
authentication to succeed. It works around multiple issues in which the remote
system does not properly report username capabilities, authentication
capabilities, or K_g status. Those hitting this issue 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
- This workaround flag will tell FreeIPMI to not check
the checksums returned from IPMI command responses. It works around systems
that return invalid checksums due to implementation errors, but 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. Those hitting this issue 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.
- This workaround flag will allow empty session IDs to be accepted
by the client. It works around IPMI sessions that report empty session IDs to
the client. Those hitting this issue may see "session timeout"
errors. Issue observed on Tyan S2882 with M3289 BMC.
- This workaround flag will allow 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. Those hitting this issue may see
"session timeout" errors. Issue observed on Dell PowerEdge
2850,SC1425. Confirmed fixed on newer firmware.
- This workaround flag will force 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 is actually required for the protocol. Those hitting
this issue may see "session timeout" errors. Issue observed on IBM
- This workaround flag will flip the endian of the session
sequence numbers to allow the session to continue properly. It works around
IPMI 1.5 session sequence numbers that are the wrong endian. Those hitting
this issue may see "session timeout" errors. Issue observed on some
Sun ILOM 1.0/2.0 (depends on service processor endian).
- This workaround flag will tell 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. Those hitting
this issue may see "connection timeout", "session
timeout", or "password verification timeout" errors. Issue
observed on Xyratex FB-H8-SRAY, Intel Windmill, Quanta Winterfell, and Wiwynn
- This workaround flag will work around 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. Those
hitting this issue may see "username invalid", "password
invalid", or "k_g invalid" errors. Issue observed on Intel
SE7520AF2 with Intel Server Management Module (Professional Edition).
- This workaround flag will work around several Supermicro
IPMI 2.0 authentication issues on motherboards w/ Peppercon IPMI firmware. The
issues covered include handling invalid length authentication codes. Those
hitting this issue may see "password invalid" errors. Issue observed
on Supermicro H8QME with SIMSO daughter card. Confirmed fixed on newerver
- This workaround flag will work work around several Sun IPMI 2.0
authentication issues. The issues covered include invalid lengthed hash keys,
improperly hashed keys, and invalid cipher suite records. Those hitting this
issue 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.
- This workaround flag will slightly alter FreeIPMI's IPMI
2.0 connection protocol to workaround 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. Those hitting this issue may see
"password invalid", "k_g invalid", or "bad rmcpplus
status code" 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, and Quanta
QSSC-S4R/Appro GB812X-CN. This workaround is automatically triggered with the
- This workaround flag will work 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. Those hitting this issue
may see "k_g invalid" errors. Issue observed on Supermicro X8DTG,
Supermicro X8DTU, and Intel S5500WBV/Penguin Relion 700, and Intel
- This workaround option will assume invalid SEL record
types are system event records. Records may be formatted correctly but report
invalid record types. Those hitting this issue may see "Unknown SEL
Record Type" errors. Output may be unknown, pray for the best. This
option is confirmed to work around compliances issues on HP DL 380 G5
No IPMI 1.5 Support - Some motherboards that support IPMI 2.0 have been found to
not support IPMI 1.5. Those hitting this issue 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
. Issue observed on HP Proliant DL 145.
The following motherboards are confirmed to have atleast some support by the
option. While highly probable the OEM data
interpretations would work across other motherboards by the same manufacturer,
there are no guarantees. Some of the motherboards below may be rebranded by
Dell Poweredge 2900, Dell Poweredge 2950, Dell Poweredge R610, Dell Poweredge
R710, Fujitsu iRMC S1 and iRMC S2 systems, Intel S5500WB/Penguin Computing
Relion 700, Intel S2600JF/Appro 512X, Intel S5000PAL, Inventec 5441/Dell
Xanadu II, Inventec 5442/Dell Xanadu III, Quanta S99Q/Dell FS12-TY, Quanta
QSSC-S4R/Appro GB812X-CN, Sun X4140 Supermicro X7DBR-3, Supermicro X7DB8,
Supermicro X8DTN, Supermicro X7SBI-LN4, Supermicro X8DTH, Supermicro X8DTG,
Supermicro X8DTU, Supermicro X8DT3-LN4F, Supermicro X8DTU-6+, Supermicro
X8DTL, Supermicro X8DTL-3F, Supermicro X8SIL-F, Supermicro X9SCL, Supermicro
X9SCM, Supermicro X8DTN+-F, Supermicro X8SIE, Supermicro X9SCA-F-O, Supermicro
H8DGU-F, Supermicro X9DRi-F, Supermicro X9DRI-LN4F+, Supermicro X9SPU-F-O,
Supermicro X9SCM-iiF, Wistron/Dell Poweredge C6220.
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
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.
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 to this temporary "lock up" to pass before you may
Report bugs to <firstname.lastname@example.org> or <email@example.com>.
Copyright (C) 2012-2015 Lawrence Livermore National Security, LLC.
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