IPMI Setup for Workstations
running FreeBSD
IPMI Specification Features
Session-based Access (for LAN and serial channels)
- Supports multiple username/password/access levels
- MD5 or MD2 hashing of password and session data for authentication
- Also supports plaintext password or No authentication
for secure channels
Link-level Authentication supported for Serial/PPP
System Sensor
- Data collection (fan speed, temperature, power supply
status)
- System Event Log inspection and event posting (for example, memory
errors, system boots, and chassis intrusions are logged to the SEL)
Sensor Data Repository (sensor configuration
information)
- Max/Min/Hysteresis watermarks for event generation
- Enable/Disable/Present/Not Present flags
- Translation of raw sensor values into value & units
Field-Replaceable Unit (FRU) repository
- Lists of devices in system, including serial numbers
in many cases
- Sample devices: backplane board, power supply, removable devices
Multiple Interface access channels
- LAN
- Serial: PPP, Basic, Terminal
- System: Keyboard Controller Style (KCS), Server Management
Interface Chip (SMIC), Block Transfer (BT) via System I/O space
Inter-channel messaging
- LAN can send messages to System Interfaces or other
devices on internal Intelligent Platform Management Busses (IPMB)
as bridged by the BMC
- Inter-Chassis Management Bus (ICMB) allows multiple chassis to communicate
- BMC can broker messages to other Private Management
Buses internal to the system
- Most buses use I2C and raw messages can be sent using I2C Master
commands via the BMC
Chassis Control
- Reset
- Power On/Off/Cycle
- Send NMI
- Chassis Status
Alerting and Paging
- Can send IPMI messages, numeric or text pages, and SNMP
traps to alert operators to system problems
- Events can be filtered to cause different actions based on severity
Basic Hardware Monitoring
- Unified Watchdog Timer
- Power-On Hours Timer
While not IPMI-mandated features per se, some platforms (the Intels
in particular) implement these management features which are controllable
with IPMI:
- BIOS I/O redirection to a serial port, including post-boot
programs that utilize BIOS video routines, i.e. DOS
- Alternative boot to a repair partition
Current Progress
Three sets of tools currently exist for interfacing with IPMI-equipped
computers.
KCS
- A userland driver can communicate with the KCS interface.
- A simple command-line C program that can communicate with the system
BMC. The command and request bytes are given on the command line,
and a response is displayed as hex bytes with the standard IPMI/KCS
return bytes decoded.
- Some small programs that execute particular command(s) and decode
the output for inspection.
SMIC
- A userland driver and simple command executor adapted
from the KCS one exist for testing.
Python IPMI
- A Python module that implements IPMI interfaces and
commands. The module takes care of session management, including authentication.
The module provides a method to send raw commands and receive responses.
- Supported interfaces: KCS, SMIC, LAN
- The module also provides accessory functions for handing
data from the SDR and FRU repositories, reading and converting sensor
values, controlling chassis functions, and reading the SEL.
- A sample program that uses the module(s) to retrieve and decode
SEL and SDR info, perform chassis control, and return a converted
sensor value.
All of this code is made available under a standard three-clause BSD
license.
Design Ideas
The following tools or features are currently under consideration.
- A command-line tool to request frequently desired information
and return it to stdout. The return format would be machine-readable
and be targeted at automated monitoring and/or data collection. The
output format could be as easy as whitespace-separation, or as complex
as XML.
- A GUI browser to pick through sensor or System Event Log (SEL) records
and display them in a table format.
- A daemon that polls important sensor and SEL events
and write syslog messages if important events occur.
- A remote-control application that allows easy power control of remote
systems, removing the need for dedicated hardware (power manager strips
/ APCs).
- A daemon to broker requests to the IPMI interfaces,
since writing to I/O space from userland requires root privileges
to run i386_set_ioperm (2).
Future Directions, Ideas, and Unfocused Rambling
- Intel has an advertising slick on their Intel Server
Management page promising to bring full serial redirection over LAN
via IPMI to a future version of the specification. This would remove
the need for separate console servers entirely, although some may
contend that it puts a heavy burden on the NIC and network infrastructure;
if the NIC fails, the system becomes unreachable, even for management.
Currently IPMI does support redirecting the BIOS video out the serial
port and the LAN (this includes anything else that uses the BIOS video
routines, including DOS and option ROMs, like SCSI setup).
- Hopefully, Intel will make available their modifications to ucd-snmp
so that their Windows tools (Direct Platform Control (DPC)) can access
the system and request the system to shut down nicely before restarting.
Right now, the OS is "Unknown" so any actions cause an abrupt
restart. The ucd-snmp modifications are binary-only on RedHat and
use (ancient) version 4.1.1.
- On a related thread, Intel is putting forward an initiative,
called Metolius, which would push much of the IPMI driver functionality
into ACPI. This would require the OS to only make ACPI method calls
to access IPMI features. The BMC could then signal the OS via ACPI
instead of requring custom daemons. Considering the track record of
ACPI and DSDT methods, this has a long way to go before becoming reality.
- Encryption over the LAN channels would be a big bonus. The authentication
isn't great, but MD5 hashing with sequence numbers is better than
nothing. End-to-end encryption is really necessary for console-over-LAN,
where root passwords going out in the clear would be a Bad Thing.
- A newbus driver might be fun to put together since the
BMC acts like a big bridge to multiple busses that can be addressed
directly. It's not clear at this point which System Interfaces will
end up in common use. IPMI mandates that one of the specified interfaces
exist in the system, and there doesn't appear to be any consensus
as to which to implement. Intel primarily uses KCS while HP uses SMIC.
- Some of the config info for the system interface is hidden in the
SMBIOS tables. This is a problem for early IPMI systems that chose
not to use the reference implemention's addresses (like the HP LH
6000). Also, the BMC interrupt is stored there (if not directly configurable
in BIOS). Hopefully someone will add a command to get the BMC hardware
config information so you could start at KCS and move to BT once you
have the resource information.
Session-based Access (for LAN and serial channels)
These are recommended settings for the iNET1700, iNET2200, (and similar)
servers for optimal use under FreeBSD, with full console redirection
from BIOS and from loader(8), and enabling remote control over LAN (optional).
Only the "Setup Utilities" section should be required; the IPMI commands
can be used for automated reconfiguration if desired.
This configuration assumes that the machine will be connected to a (secure)
LAN and that the serial console will be connected to a console server
or similar device, and not a modem. This means that you do not plan
on using the built-in modem paging capabilities and/or PPP or Direct
mode IPMI sessions to the BMC (from a tool such as Intel Direct Platform
Control).
Some of the items give the data bytes for equivalent IPMI commands.
Use with caution! Note:
This is a work in progress. This page, and the associated program(s)
found on the link below will be updated as work is further completed
and validated on other iNET servers.
Setup Utilities
BIOS Settings
Change Serial Port2 to COM1 settings
- Address 3F8, IRQ 4
- This makes the onboard RJ45 ports COM1 and thus the default serial
console.
- You can disable Serial Port1 if it isn't present on
your system (i.e., iNET1700/2200 chassis)
- Put "-h" in /boot.config to make FreeBSD use the serial console
by default.
See Handbook section 15.6 ("Setting Up the Serial Console") for
details.
Change BIOS console redirection settings (under Server / Console Redirection)
- Enable serial console redirection
- Serial port: COM1 3F8 IRQ 4
Baud Rate
- 9600 if using default FreeBSD speeds
- Whatever you like if you have built new boot1/2/loader with
BOOT_COMCONSOLE_SPEED set (I've rebuilt it to use 115200)
Flow Control
- Whatever your hardware supports
System Setup Utility (SSU) Settings
Platform Event Manager
Configure EMP
- Access Mode to "Disabled"
Configure PEP
Configure LAN (optional, if LAN IPMI access desired)
- set static IP or DHCP
- Disable LAN alerts
- Access Mode to "Always available"
- Must set SNMP trap string if enabled
IPMI Commands
Set Channel Access for Channel #1 (serial) -- 0x20
- Same effect as changing the SSU settings above for EMP
- Platform Event Filtering off
- Disable access mode (always shunt to SYSTEM [BIOS & host])
- These can be configured in SSU. 'Shared' channel access mode
can't, but I don't think we want to use it on this system.
Set Serial Mux -- 0x2
- Updates Enabled
- set to SYSTEM
Set Serial Config --
Modepage 8 -- 0x11 0x7
- Enable switch keys
- disable autodetect
- disable reset keys
Downloading and Building IPMI on FreeBSD
The tools provided in the tarball are intended as a sneaky-peek at
what is to come, and to give some tools for finding hardware support
for IPMI. I would not suggest using these in any serious application
yet. The APIs are not fixed and in fact change daily. There
are as yet unknown hardware dependencies. There are certainly
bugs.
Download: ipmi-0.2.tar.gz
Building
For the KCS and SMIC userland drivers, you generally just need to grab
smic-common.c or kcs-common.c, ipmi/ipmi-common.c
and the appropriate header files. Eventually this will get built
into a library.
ioport is a Python C module that provides Python routines for calling
i386_set_ioperm(2), inb(), and outb(). To
build it, go into the ioport directory and run:
- make -f Makefile.pre.in boot
- make
- make install
Request For Comments
The following mailing list has been created for public discussion and
comments with respect to IPMI.
Please subscribe
to our IPMI email list |
