IPMI: Intelligent Platform Management Interface

The Intelligent Platform Management Interface (IPMI) specification defines a set of common interfaces to a computer system which system administrators can use to monitor system health IPMI and manage the system.

Dell, HP, Intel Corporation and NEC Corporation announced IPMI v1.0 on 1998-09-16, v1.5 on 2001-03-01, and v2.0 on 2004-02-14. New in IPMI V2.0

• Enhanced Authentication  A higher level of security has been added through extensions to the protocols for IPMI over IP, collectively referred to as “RMCP+” that support new security algorithms.
• VLAN Support Configuration options have been added to support IEEE 802.1q VLAN (virtual LAN) headers for IPMI over IP sessions on IEEE 802.3 Ethernet. 
• Serial Over LAN (SOL)  Serial Over LAN enables the serial controller of a managed system to be redirected over an IPMI session on IP with encryption. 
• Encryption Support  Another security enhancement supports the encryption of IPMI messages and other payloads carried over RMCP+. 
• Firmware Firewall  Additional security is provided by the Firmware Firewall which restrict the ability to execute certain commands or functions for a given BMC interface. 
• SMBus System Interface (SSIF)  The SMBus System Interface (SSIF) is a low pin-count hardware option to provide local access to the BMC via a connection to the system’s SMBus host controller.

IPMI is implemented on a hardware chip known as the Baseboard Management Controller (BMC), or Management Controller (MC). BMC operates independently of the operating system and allows administrators to manage a system remotely even in the absence of an operating system, or if the monitored system is powered off, but connected to a power source.

IPMI also functions after the operating system has started, and offers enhanced features when used with system management software.

IPMI version 1.5 and later can send out alerts via a direct serial connection, a local area network (LAN) or a serial over LAN (SOL) connection to a remote client. System administrators can then use IPMI messaging to query platform status, to review hardware logs, or to issue other requests from a remote console through the same connections.

The standard also defines an alerting mechanism for the system to send a simple network management protocol (SNMP) platform event trap (PET). Among them temperature, voltage, fan speed, bus errors, etc. It can perform recovery operations (local or remote system resets and power on/off operations), and an interface for logging without operating system intervention for abnormal or ‘out-of-range’ conditions for later examination and alerting.

BMC is always powered  on even when the main system is OFF, or the operating system has crashed. So the BMC can be configured to look at the status of local hardware from another server for secure remote monitoring and recovery (such as system reset) regardless of the status of the platform.

Along with  main controller  BMC (Baseboard Management Controller ) there can be other management controllers distributed among different system modules that are referred to as "satellite" controllers. Such satellite controllers can implement Web interface like Dell DRAC as well as additional functions. For example remote CDROM drive.

The satellite controllers within the same chassis connect to the BMC via the system interface called IPMB (Intelligent Platform Management Bus/Bridge) — an enhanced implementation of I²C (Inter-Integrated Circuit). The BMC connects to satellite controllers or another BMC in another chassis via IPMC (Intelligent Platform Management Chassis) bus/bridge. It may be managed with the Remote Management Control Protocol (RMCP), a specialized wire protocol defined by this specification.

A Field Replaceable Unit (FRU) holds the inventory (such as vendor id, manufacturer etc.) of potentially replaceable devices.

A Sensor Data Records (SDR) repository provides the properties of the individual sensors present on the board. For example, the board may contain sensors for temperature, fan speed, and voltage.

NEWS CONTENTS

• 20171109 : Looks like IME is running on MINIX by Steven J. Vaughan-Nichols ( Nov 07, 2017 , www.zdnet.com )
• 20171109 : IPMI on CentOS/RHEL ( IPMI on CentOS/RHEL, )
• 20171109 : ipmitool Cheatsheet and Configuring DRAC from ipmitool ( ipmitool Cheatsheet and Configuring DRAC from ipmitool, )
• 20090820 : Blueprints Using Intelligent Platform Management Interface (IPMI) on IBM System x Linux Platforms ( Blueprints Using Intelligent Platform Management Interface (IPMI) on IBM System x Linux Platforms , Aug 20, 2009 )
• 20090820 : SuSE ( softpanorama.org, )
• 20090820 : IBM Information Center for Linux / ( IBM Information Center for Linux / , )
• 20090820 : Novell Doc Novell ZENworks 7.2 Linux Management Installation Guide - Managed Device Requirements ( Novell Doc Novell ZENworks 7.2 Linux Management Installation Guide - Managed Device Requirements, )

Old News ;-)

[Nov 09, 2017] Looks like IME is running on MINIX by Steven J. Vaughan-Nichols

Nov 07, 2017 | www.zdnet.com

Matthew Garrett, the well-known Linux and security developer who works for Google, explained recently that, "Intel chipsets for some years have included a Management Engine [ME] , a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT [Active Management Technology] is another piece of software running on the ME."

In May, we found out that AMT had a major security flaw , which had been in there for nine -- count 'em -- nine years.

"Fixing this requires a system firmware update in order to provide new ME firmware (including an updated copy of the AMT code)," Garrett wrote. "Many of the affected machines are no longer receiving firmware updates from their manufacturers, and so will probably never get a fix," he said. "Anyone who ever enables AMT on one of these devices will be vulnerable."

Quick! How many of you patched your PC or server's chip firmware? Right. Darn few of you. That's bad. It's not every processor, but if you or your hardware vendor has "explicitly enabled AMT", your machine is still vulnerable to attack.

The Electronic Frontier Foundation (EFF) has called for Intel to provide a way for users to disable ME . Russian researchers have found a way to disable ME after the hardware has initialized, and the main processor has started. That doesn't really help much. ME is already running by then.

But Minnich found that what's going on within the chip is even more troubling. At a presentation at Embedded Linux Conference Europe , he reported that systems using Intel chips that have AMT, are running MINIX.

If you learned about operating systems in the late '80s and early '90s, you knew MINIX as Andrew S Tanenbaum's educational Unix-like operating system. It was used to teach operating system principles. Today, it's best known as the OS that inspired Linus Torvalds to create Linux.

So, what's it doing in Intel chips? A lot. These processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what version or how it's been modified since we don't have the source code. We do know that with it there:

• Neither Linux nor any other operating system have final control of the x86 platform
• Between the operating system and the hardware are at least 2 ½ OS kernels (MINIX and UEFI)
• These are proprietary and (perhaps not surprisingly) exploit-friendly
• And the exploits can persist, i.e. be written to FLASH, and you can't fix that

In addition, thanks to Minnich and his fellow researchers' work, MINIX is running on three separate x86 cores on modern chips. There, it's running:

• TCP/IP networking stacks (4 and 6)
• File systems
• Drivers (disk, net, USB, mouse)
• Web servers

MINIX also has access to your passwords. It can also reimage your computer's firmware even if it's powered off. Let me repeat that. If your computer is "off" but still plugged in, MINIX can still potentially change your computer's fundamental settings.

And, for even more fun, it "can implement self-modifying code that can persist across power cycles". So, if an exploit happens here, even if you unplug your server in one last desperate attempt to save it, the attack will still be there waiting for you when you plug it back in.

How? MINIX can do all this because it runs at a fundamentally lower level.

x86-based computers run their software at different privilege levels or "rings" . Your programs run at ring three, and they have the least access to the hardware. The lower the number your program runs at, the more access they have to the hardware. Rings two and one don't tend to be used . Operating systems run on ring zero. Bare-metal hypervisors, such as Xen , run on ring -1. Unified Extensible Firmware Interface (UEFI) runs on ring -2. MINIX? It runs on ring -3.

You can't see it. You can't control it. It's just humming away there, running your computer. The result, according to Minnich is "there are big giant holes that people can drive exploits through." He continued, "Are you scared yet? If you're not scared yet, maybe I didn't explain it very well, because I sure am scared."

... ... ...

IPMI on CentOS/RHEL

Thu 11 Mar 2010 | Hackery

Tags: linux, centos, rhel, ipmi, dell

Spent a few days deep in the bowels of a couple of datacentres last week, and realised I didn't know enough about Dell's DRAC base management controllers to use them properly. In particular, I didn't know how to mess with the drac settings from within the OS. So spent some of today researching that.

Turns out there are a couple of routes to do this. You can use the Dell native tools (e.g. racadm) included in Dell's OMSA product, or you can use vendor-neutral IPMI, which is well-supported by Dell DRACs. I went with the latter as it's more cross-platform, and the tools come native with CentOS, instead of having to setup Dell's OMSA repositories. The Dell-native tools may give you more functionality, but for what I wanted to do IPMI seems to work just fine.

So installation is just:

yum install OpenIPMI OpenIPMI-tools
chkconfig ipmi on
service ipmi start

and then from the local machine you can use ipmitool to access and manipulate all kinds of useful stuff:

# IPMI commands
ipmitool help
man ipmitool

# To check firmware version
ipmitool mc info
# To reset the management controller
ipmitool mc reset [ warm | cold ]

# Show field-replaceable-unit details
ipmitool fru print

# Show sensor output
ipmitool sdr list
ipmitool sdr type list
ipmitool sdr type Temperature
ipmitool sdr type Fan
ipmitool sdr type 'Power Supply'

# Chassis commands
ipmitool chassis status
ipmitool chassis identify [<interval>]   # turn on front panel identify light (default 15s)
ipmitool [chassis] power soft            # initiate a soft-shutdown via acpi
ipmitool [chassis] power cycle           # issue a hard power off, wait 1s, power on
ipmitool [chassis] power off             # issue a hard power off
ipmitool [chassis] power on              # issue a hard power on
ipmitool [chassis] power reset           # issue a hard reset

# Modify boot device for next reboot
ipmitool chassis bootdev pxe
ipmitool chassis bootdev cdrom
ipmitool chassis bootdev bios

# Logging
ipmitool sel info
ipmitool sel list
ipmitool sel elist                       # extended list (see manpage)
ipmitool sel clear

For remote access, you need to setup user and network settings, either at boot time on the DRAC card itself, or from the OS via ipmitool:

# Display/reset password for default root user (userid '2')
ipmitool user list 1
ipmitool user set password 2 <new_password>

# Display/configure lan settings
ipmitool lan print 1
ipmitool lan set 1 ipsrc [ static | dhcp ]
ipmitool lan set 1 ipaddr 192.168.1.101
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 192.168.1.254

Once this is configured you should be able to connect using the 'lan' interface to ipmitool, like this:

ipmitool -I lan -U root -H 192.168.1.101 chassis status

which will prompt you for your ipmi root password, or you can do the following:

echo <new_password> > ~/.racpasswd
chmod 600 ~/.racpasswd

and then use that password file instead of manually entering it each time:

ipmitool -I lan -U root -f ~/.racpasswd -H 192.168.1.101 chassis status

I'm using an 'ipmi' alias that looks like this:

alias ipmi='ipmitool -I lan -U root -f ~/.racpasswd -H'

# which then allows you to do the much shorter:
ipmi 192.168.1.101 chassis status
# OR
ipmi <hostname> chassis status

Finally, if you configure serial console redirection in the bios as follows:

Serial Communication -> Serial Communication:       On with Console Redirection via COM2
Serial Communication -> External Serial Connector:  COM2
Serial Communication -> Redirection After Boot:     Disabled

then you can setup standard serial access in grub.conf and inittab on com2/ttyS1 and get serial console access via IPMI serial-over-lan using the 'lanplus' interface:

ipmitool -I lanplus -U root -f ~/.racpasswd -H 192.168.1.101 sol activate

which I typically use via a shell function:

# ipmi serial-over-lan function
isol() {
   if [ -n "$1" ]; then
       ipmitool -I lanplus -U root -f ~/.racpasswd -H $1 sol activate
   else
       echo "usage: sol <sol_ip>"
   fi
}

# used like:
isol 192.168.1.101
isol <hostname>

Further reading:

• http://www.cuddletech.com/blog/archives/archive_2008-m06.php
• http://buttersideup.com/docs/howto/IPMI_on_Debian.html
• http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Serial_Consoles
• http://openipmi.sourceforge.net/IPMI.pdf

ipmitool Cheatsheet and Configuring DRAC from ipmitool

1) List of helpful ipmitool commands:

• Check BMC Firmware Revision:

#ipmitool -I open bmc info | grep -A3 "Firmware Revision"

• Check SEL log:

#ipmitool sel

• List SEL log:

#ipmitool sel list

• Check which node you are in [For Dell Cloud edge]:

#ipmitool raw 0x34 0x11

• Reset BMC/DRAC to default:

#ipmitool mc reset cold

2) Configure DRAC from ipmitool

• Set BMC/DRAC static IP

#ipmitool lan set 1 ipsrc static

• Set BMC/DRAC IP Address

#ipmitool lan set 1 ipaddr <ip add of bmc>

• Set BMC/DRAC Subnet Mask

#ipmitool lan set 1 netmask <netmask addr>

• Set BMC/DRAC Default Gateway

#ipmitool lan set 1 defgw ipaddr <ip add>

• Change the NIC settings to dedicated

#ipmitool raw 0x30 0x24 2

• Change the NIC settings to shared

#ipmitool raw 0x30 0x24 0

• Check the NIC settings

#ipmitool raw 0x30 0x25

[Output of 00 means shared and 02 means dedicated]

• Restart the BMC/DRAC

#ipmitool mc reset warm

[Aug 20, 2009] Blueprints Using Intelligent Platform Management Interface (IPMI) on IBM System x Linux Platforms

Html version is at IBM Information Center for Linux

Note that while many IBM Blades include a BMC, remote management of the BladeCenter is typically done through the Management Module using a different protocol. Also, the Blade's BMC LAN channel is limited to internal access by the Management Module. However, you can run most of the IPMItool commands covered in this Blueprint directly to the BMC of the Blade using the OpenIPMI driver.

OpenIPMI Driver is included in all IBM supported Red Hat Enterprise Linux and Suse Linux Enterprise Server distributions.

The driver consists of several driver modules. In RHEL 5.2 and SLES 10.2, the OpenIPMI modular drivers that may be loaded include ipmi_msghandler, ipmi_devintf, ipmi_si, ipmi_watchdog, and ipmi_poweroff.

There is also a legacy, closed source deprecated driver known as the OSA IPMI driver which is in use mainly with older versions of Linux. However, you should consider using the open source driver OpenIPMI.

Activating the IPMI Service

In default RHEL5 and SLES10 installations, the OpenIPMI drivers are automatically installed as modules To start using IPMI to manage your hardware, activate the IPMI service by issuing the following commands:

# chkconfig ipmi on
# service ipmi start
# service ipmi status
ipmi_msghandler module loaded.
ipmi_si module loaded.
ipmi_devintf module loaded.
/dev/ipmi0 exists.
Note: This loads the 3 basic drivers: ipmi_msghandler, ipmi_devintf, ipmi_si.

IPMItool

IPMItool is a utility to monitor, configure, and manage devices that support the Intelligent Platform Management Interface (IPMI).

Installing IPMItool

Although the IPMItool utility is available with most recent Linux distributions, this blueprint uses version IPMItool v1.8.10. Follow the instructions to download, build, and install the latest version of the IPMItool utility:

Download latest Linux Open Source IPMItool utility (MIGR 5069505) at http://www-304.ibm.com/ systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5069538&brandind=5000008. A C compiler is the prerequisite of the install and needs to be available. For RHEL, the Development Tools package group is needed. For SLES, the C/C++ Complier & Tools package pattern is sufficient.

This blueprint includes some 'passive probing' commands to allow you to see specific aspects of your system through use of IPMItool. Each system can provide somewhat unique output in response to these commands. In some cases you will want to refer to the IPMI Specification to help interpret the results.

Considerations using IPMItool

Before using IPMItool, there are some important considerations that you must keep in mind.

Log In as Root IPMItool commands works only for root user.

IPMItool Version on Linux This blueprint is based on IPMItool version 1.8.10. To check your version:

# ipmitool -V

ipmitool version 1.8.10

You can use the instructions provided in section to install the IPMItoo version 1.8.10 l if needed.

IPMI Version on BMC

It is important to know what IPMI hardware version you have on the BMC in your system. Systems with IPMI v2.0 based BMCs have been out for several years plus many more have IPMI v1.5. Appendix B, "New in IPMI V2.0," on page 23 provides a short summary of the differences between IPMI v1.5 and IPMI v2.0 based BMCs.

The instructions in this blueprint are tested on both IPMI 1.5 and IPMI 2.0 hardware. However, only IPMI2.0 version is documented. You should expect possible differences in the IPMItool command outputs compared to this blueprint if your hardware is based on IPMI v1.5. The Serial Over LAN (SOL) section assumes your system has IPMI v2.0.If you have an IBM standalone server containing IPMI v1.5, it may be possible to upgrade the BMC firmware to IPMI v2.0. See the Baseboard Management Controller (BMC)

Update at

https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-64081&brandind=5000008

fora list of applicable systems and latest version of BMC firmware. These instructions were tested on an IBMxSeries 366 (Type 8863) that had been upgraded from IPMI v1.5 to IPMI v2.0.The BMC (or MC) command allows you to directly interact with the BMC and to display information about the BMC hardware. Issue the following command to get information about your BMC hardware and IPMI version. Note that the BMC in this hardware is of version 2.0:

# ipmitool mc info Device ID : 32
Device Revision : 0
Firmware Revision : 2.7
IPMI Version : 2.0
Manufacturer ID : 2
Manufacturer Name : Unknown (0x02)
Product ID : 7 (0x0007)
Product Name : Unknown (0x7)
Device Available : yes
Provides Device SDRs : no
Additional Device Support :
Sensor Device
SDR Repository Device
SEL Device
FRU Inventory Device
IPMB Event Receiver
IPMB Event Generator
Chassis Device
Aux Firmware Rev Info :
0x5a
0x32
0x42
0x54

IPMItool commands

For more information about IPMItool, there are two good references for IPMItool commands:

1. The man page (new and improved with v1.8.10)

2. The built-in command line help provides a list of IPMItool commands:

# ipmitool help

You can also get help for many specific IPMItool commands by adding the word help after the command:

# ipmitool channel help

Logical Channels

IPMI uses logical channels as BMC communication pathways. Two key channels are the Open Interface and the LAN channel. The Open Interface is also called the System Interface and uses the OpenIPMI kernel driver. The LAN channel is used when the IPMItool is communicating with a remote machine's BMC. The command line -I option specifies the channel. The Open Interface is the default if you do not use this option. For example, both of these commands provide the same result:

# ipmitool -I open mc info

# ipmitool mc info

Since IPMI is a standardized, message-based interface, in general all the IPMItool commands in this blueprint work with all the IPMItool Interfaces (Open or System, LAN, and others). IPMItool uses the System Interface (″in-band″) so that the IPMI command executes on the local BMC through the OpenIPMI Driver. IPMItool can also use a LAN Interface to receive IPMI responses from a remote IPMI based platform, if you know its BMC IP address and have user access to the BMC. To find this information, you need to discover the specific channel numbers for your IPMI system. IBM platforms with IPMI assign the System Interface to channel number 15 and the LAN to channel number 1. You can discover details for each channel in your system by using info along with the channel number (in a range from 0 to 15). If you do not provide a channel number the BMC will always reply with information about the current channel that you are running the command on. For example, in this case the current channel is the System Interface and is on channel 15 (oxf).

# ipmitool channel info
Channel 0xf info: br> Channel Medium Type : System Interface
Channel Protocol Type : KCS
Session Support : session-less
Active Session Count : 0
Protocol Vendor ID : 7154
You can also use the following command and receive the same output as above:
# ipmitool channel info 15
All IBM platforms with IPMI also have a LAN interface which is assigned to channel number 1:
# ipmitool channel info 1
Channel 0x1 info:
Channel Medium Type : 802.3 LAN
Channel Protocol Type : IPMB-1.0
Session Support : multi-session
Active Session Count : 0
Protocol Vendor ID : 7154
Volatile(active) Settings
Alerting : enabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available
Non-Volatile Settings
Alerting : enabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available

See the IPMI specification for more details on available IPMI channels/communication pathways.

Chapter 2. Checking your system health

You can use your system BMC to keep watch of your system vital signs. Additionally, the BMC logs any potential health issues into the System Event Log (SEL). The vital signs are available for viewing with the

ipmitool Sensor Data Record (SDR) command.

To see all available SDRs in your system, issue the following command:

# ipmitool sdr list

For illustration purposes, focus on CPU temperature readings. In IPMI 2.0 environment running RHEL5.2, the temperature readings are listed as CPU * Temp records. To see all CPU temperature reading, issue the following Sensor Data Record (SDR) command:

# ipmitool sdr list | grep Temp
Ambient Temp | 24 degrees C | ok
CPU 1 Temp | 42 degrees C | ok
CPU 2 Temp | disabled | ns
CPU 3 Temp | disabled | ns
CPU 4 Temp | disabled | ns

The first column is the sensorid name. This name is used to reference the sensor in other commands as well. The sensor reading in the second column indicates a healthy system at the moment. The value of disabled for several CPU's indicates that these CPU sockets are empty. The last column displays the reading relative to threshold values. You can find more information about the possible CPU temperature Sensor States by examining those of CPU 1's. Use a command utilizing the sensorid name, ″CPU 1 Temp″, in this case. Note when the sensorid name contains blanks it must be surrounded by double quotes. The following command lists all the possible states of CPU 1's temperature.

# ipmitool event "CPU 1 Temp" list
Finding sensor CPU 1 Temp... ok
Sensor States:
lnr : Lower Non-Recoverable
lcr : Lower Critical
lnc : Lower Non-Critical
unc : Upper Non-Critical
ucr : Upper Critical
unr : Upper Non-Recoverable

If a CPU temperature becomes too cold, a new record is created in the System Event Log (SEL). You can simulate a CPU temperature becoming too cold by selecting a sensorid name and a Sensor State name -"CPU 1 Temp" and "lnc: Lower Non-Critical" respectively, to pretend that CPU 1 is overheating to low temperature:

# ipmitool event "CPU 1 Temp" "lnc : Lower Non-Critical"
Finding sensor CPU 1 Temp... ok
0 | Pre-Init Time-stamp | Temperature CPU 1 Temp | Lower Non-critica l |
going low | Reading -128 < Threshold -128 degrees C

This command simulates a -128 Celsius Reading (below the -128 Celsius threshold) - even though the actual CPU 1 Reading from the sdr list command was 42 Celsius and creates a log in the System Event Log (SEL). You can confirm that the event is actually logged with the SEL command by looking at the last event entry:

# ipmitool sel list | tail -1
1c0 | 11/19/2008 | 21:38:22 | Temperature #0x98 | Lower Non-critical going low

The first column is a unique record number in hexadecimal, the next two are a date and time stamp, the fourth shows the corresponding sensor, and the final shows what happened. Finally, you can look back in time to see if your system had a possible bad health event by showing the entire history of your System Event Log:

# ipmitool sel list

The ipmievd deamon is related to the SEL. ipmievd is an event daemon that is packaged with IPMItool that listens for events from the BMC that are being sent to the SEL and also log those messages to a system log file. The daemon can run in one of two modes: either using the Event Message Buffer and asynchronous event notification from the OpenIPMI kernel driver or actively polling the contents of the SEL for new events. See the ipmievd man page for more information.

Chapter 3. Setting up password controls

You can set up password controls for BMC LAN access in stand-alone System x hardware. The following shows how to set up password control for two users in the LAN channel. They are the default user with userid 2 and the null user. See Section 6.9 User and Password Support of the IPMI Specification for more information about users and passwords. Additionally, there is an IPMI Specification convention relating to creation of a 'Null' user on userid #1 - section 6.9.1 Anonymous Login Convention for information about using a 'Null' user. This possibility is intended to support login by a separate software application if desired. Part of the convention is to set it up on userid #1 so the BMC can readily report whether anonymous login is enabled or not.

Note: To reduce vulnerability it is strongly advised that the IPMI LAN interface only be enabled in a trusted environment where system security is not an issue, or where it is connected to a dedicated secure or private network. Instructions in this section do not apply to IBM BladeCenters. IBM BladeCenter do not have IPMI remote access to the BMC on a Blade (the BMC IP address is not available outside of the BladeCenter). You should instead use remote management through the BladeCenter Management Module interface. For more information, see IBM eServer xSeries and BladeCenter Server Management Redbook. The BMC can be configured to support multiple users and passwords for all channels except the Open channel. Typically the same user and same password should work for all the BMC channels. Instructions to set up password control for other channels are not included here as they are less commonly used. The instructions in this section are for LAN channel only. User IDs and privilege levels are unique for each channel. To see the current user IDs in use and related information for the LAN channel (0x1):

# ipmitool user list 1

ID Name Callin Link Auth IPMI Msg Channel Priv Limit
2 USERID true false true ADMINISTRATOR

Note that on all IBM BMCs, the default userid 2 is USERID with a password of PASSW0RD with a zero
(0) instead of an O.
To change the name of userid 2 do the following:

# ipmitool user set name 2 <New User ID>

Set a new password for userid 2:

# ipmitool user set password 2 ipmitool user set password 2 <New Password>

You can also use a null user for anonymous login. Change the password for the null user (userid 1) on
the LAN channel:

# ipmitool lan set 1 password <New Password>

You can see the users you have set up and find the new name (user ID) for userid 2 user. The null user is
not listed using this command when it is disabled in the BMC BIOS settings:

# ipmitool user list 1

Now that you have the users configured, set up the BMC LAN channel parameters to secure it for your
situation by setting its IP address, netmask, and snmp public community string:

# ipmitool lan set 1 ipaddr <Your IP address for the BMC>
# ipmitool lan set 1 netmask <Your Subnet Mask>
# ipmitool lan set 1 snmp <Your SNMP>

There may be other LAN parameters you want to set. You can use the help to see the possibilities:

# ipmitool lan set help

Check your LAN parameter settings with the following command. This shows output from the test environment:

# ipmitool lan print

Set in Progress : Set Complete

Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback :
: User : MD2 MD5 PASSWORD
: Operator : MD2 MD5 PASSWORD
: Admin : MD2 MD5 PASSWORD
: OEM :
IP Address Source : BIOS Assigned Address

IP Address : 192.168.0.3
Subnet Mask : 255.255.255.0

MAC Address : 00:14:5e:1b:c6:c1

SNMP Community String : public

IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP : 192.168.0.1
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : aaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN

If these results are what you expect, no unauthorized person can use the published defaults to access your BMC LAN channel to remotely cause your system to power cycle or other unauthorized activities. If you lose the BMC userid passwords, you can simply set new ones again with the above user commands, provided that you can login to the system and run ipmitool as root.

Chapter 4. Power cycling your system

The IPMItool chassis command can be used to obtain information and the status of a system locally or remotely. In the test environment, running ipmitool chassis status command returned the following results:

# ipmitool chassis status System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false

You can use the IPMItool on a second server (it doesn't need to have IPMI hardware), to display the
chassis status of your first IPMI server by accessing through the BMC LAN interface. To do this you need
the BMC IP address, and you'll need to know the user ID and password for the remote BMC's LAN channel. To find out the BMC IP address of the remote IPMI server, issue ipmitool lan print in the remote server, as shown in the end of previous section.

# ipmitool lan print | grep "IP Address "
IP Address : 192.168.0.3

To view the chassis status from a remote server, use the following command. Note it is necessary to use
the '-I' (Capital I) option to specific use of the LAN channel. Use your BMC IP address for the '-H' parameter:

# ipmitool -I lan -H 192.168.0.3 -U <User ID> -a chassis status

Note the '-U' option parameter is the 'userid' name. The '-a' option indicates to prompt for password; or you can use '-f <filename>' to get the password from a file; or you can use '-P <password>' to include the password on the command line. If the above command returns correctly, you can gracefully remote power cycle your system. Be very careful with this command as it might cause you to have to physically locate the machine and manually boot the system back on:

# ipmitool -I lan -H 192.168.0.3 -U <User ID> -a chassis power cycle System Power : on Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false

Chapter 5. IPMI Watchdog Timer

IPMI includes a hardware timer built into the BMC that can be setup to automatically recover a hung or
crashed system. You can use this timer with the Linux software watchdog daemon. You do this by setting up two timers:

• a hardware timer in the BMC with a longer count time (in this example, 300 seconds)
• a software timer with a shorter count time (in this example, 5 seconds - a count of 10 results in about 5 seconds with the software timer). Then configure the timers to make the software timer reset the hardware timer. If the hardware timer counts down for 300 seconds without getting a reset from the software timer then the system must be hung so the hardware timer is going to cause a system reboot. The Linux watchdog daemon is typically setup as a software mechanism used to reset a system that is not operating properly. Although it is typically used as a highly configurable software watchdog daemon, it may alternately be configured to utilize the hardware timer built into the BMC. It does this by using the OpenIPMI watchdog device driver and the /dev/watchdog device node. Hardware based watchdogs are inherently much more reliable compared to software watchdogs - particularly when a system becomes hung to the point that system interrupts are prevented altogether, thereby effectively suspending the operation of the software watchdog itself. When this occurs, a software watchdog will be unable to trigger, and system recovery via the watchdog facility will fail. Alternately, a hardware watchdog such as the one available in the IPMI hardware BMC will not fail during a system hang and will trigger to execute the specific user-configured behavior (system reset, etc.) to allow for system recovery.

Note the Linux watchdog daemon process must be continually running on the system after the IPMI hardware watchdog timer has been setup. The daemon must periodically ″poke″ the IPMI watchdog hardware timer (through the OpenIPMI watchdog driver). The "poke" is needed to keep the IPMI watchdog hardware timer from causing a system reset (or some other configurable action). Consequently, if the system becomes hung and the software watchdog daemon can no longer ″poke″ the IPMI hardware watchdog timer, the hardware timer will continue to count down and trigger the desired system event (power down, system reset, etc.).

Setting up the IPMI Watchdog Timer

There are three main steps to set up the IPMI watchdog timer. Follow the instructions found on Linux Open Source watchdog daemon support replaces IPMI ASR - Servers at http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR- 5069505&brandind=5000008. The followings are some tips for each of the steps described, and also some additional steps to help you get through the process.

1. The first step is the enablement of the IPMI hardware timer. You will have to reboot the machine and get into the BIOS and find the option to set the two BMC watchdog variables. We found the option listed under Advanced Settings in our test environment.

2. The second step describes configuring and activating the IPMI watchdog driver. You can use one of two methods described in the instructions. We recommend the use of the method 2a. The activation of the ipmi service should output:

# service ipmi start Starting ipmi drivers: done

Starting ipmi_watchdog driver: done

3. After step 2, issue the following to stop the watchdog timer so that you have time to complete step 3:

# ipmitool mc watchdog off

Watchdog Timer Shutoff successful -- timer stopped

4. Before starting step 3 in the instructions, check to see if the configuration of your hardware watchdog

timer is setup correctly:

# ipmitool mc watchdog get

Watchdog Timer Use: SMS/OS (0x04)

Watchdog Timer Is: Stopped

Watchdog Timer Actions: No action (0x00)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x00

Initial Countdown: 300 sec

Present Countdown: 300 sec

5. The third step of the instructions is the configuration and activation of the watchdog daemon. Both RHEL5.2 and SLES10SP2 do not install the daemon by default. Therefore you need to install the watchdog daemon manually, as described in the Workaround step 1 of the instruction URL. This workaround involves downloading the latest watchdog package, compiling, and installing it.

6. After step 3, issue the following command to start the watchdog timer:

# ipmitool mc watchdog on

7. Now all the configuration is done and all related services are activated, the watchdog timer would reboot the hardware every 300 seconds, but at the same time a software timer resets the hardware watchdog timer every 5 seconds. By issuing the following command a few times and comparing the initial and present countdown values, you can see that the timer is constantly being reset back to 300 seconds.

# ipmitool mc watchdog get

Watchdog Timer Use: Digital State (0x44)

Watchdog Timer Is: Started/Running

Watchdog Timer Actions: Power Cycle (0x03)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x00

Initial Countdown: 300 sec

Present Countdown: 295 sec

8. If the system gets hung for some reason, the hardware timer will countdown and cause a power cycle

within 5 minutes.

9. To activate the watchdog so it will restart on every reboot, run the following command:

# chkconfig watchdog on

Turning off the Watchdog

It may become necessary to turn off the watchdog occasionally without triggering the watchdog to fire, such as when performing a BMC firmware flash (be sure to disable the watchdog daemon and driver before flashing). The IPMItool utility may be used to safely turn off a running hardware watchdog and so should be installed prior to the first use of the IPMI watchdog. For instructions on how to safely turn off the IPMI hardware watchdog using IPMItool v1.8.9 or prior versions, how to safely stop the Linux watchdog daemon, and how to unload the OpenIPMI watchdog driver see Safely disabling the open source watchdog used with OpenIPMI at http://www-304.ibm.com/ systems/support/supportsite.wss/docdisplay?brandind=5000008&lndocid=MIGR-5075280. The IPMItool v1.8.10 includes a new watchdog command interface for safely turning off a running IPMI hardware watchdog timer:

# ipmitool mc watchdog off

Additional commands for Watchdog Timer adminstration

In addition to starting and stopping Watchdog Timer, there are several other commands that you can use for administering Watchdog Timer. You can see the Present Countdown value counting down at any time by issuing:

# ipmitool mc watchdog get

You can stop and start the Watchdog hardware timer prior to completion of the 300 second countdown by issuing:

#ipmitool mc watchdog off #ipmitool mc watchdog on

Note for IPMItool v1.8.9 and earlier, you can use the raw command to to the watchdog hardware:

# ipmitool raw 0x06 0x25

Sift through the bytes returned to find the current running status. For example:

# ipmitool raw 0x06 0x25 04 00 00 00 b8 0b b8 0b

The ″0″ portion of the first byte ″04″ indicates that the timer is off. If the timer were on, this byte would have been ″44″. The other bytes (in sequence) indicate the following: 00 = No pre-timeout set, no timeout action set 00 = Pre-timeout interval set to 0

00 = Timer hasn't expired yet

b8 0b = Initial countdown value. 0b is the most significant byte so countdown is set to 0x0bb8 (100

ms/count) which is 5 minutes.

b8 0b = Present countdown value. As with Initial countdown value, 0b is the most significant byte.

Should match Initial countdown value when the timer is first set.

For more information, see section 27.7 of the IPMI specification.

A simple howto for compile OpenIPMI 2.0 on SuSE Linux

Coly

1, Why write this text
I have to say, OpenIPMI is pretty hard to compile. I always have
difficalty on every new version compiling. This simple text is to help
people compile OpenIPMI more easy on SuSE Linux.

2, Preparation
On OpenSuSE10.1, SLES10, SLED10, the OpenIPMI 1.4 is included. OpenIPMI
2.0 is still under testing in OpenSuSE10.2 yet.

In order to compile, install and run OpenIPMI 2.0 binaries and
libraries, it is recommended to uninstall the installed OpenIPMI 1.4
packages.

Compiling OpenIPMI 2.0 needs more auxiliary packages. All the packages
can be found in SLE10/OpenSuSE SDK, some of them can not be found in
distribution media.

Installing OpenIPMI 2.0 is easy, all the auxiliary packages are
available on distribution media.

These packages should be install into your SuSE Linux before compiling
OpenIPMI 2.0:
aaa_base acl attr audit-libs autoconf automake bash bind-libs bind-utils
binutils bison bzip2 coreutils cpio cpp cracklib cvs cyrus-sasl db dia
diffutils e2fsprogs file filesystem fillup findutils flex gawk gcc gd
gd-devel gdbm gdbm-devel gettext gettext-devel glib glib-devel glibc
glibc-devel glibc-locale gpm grep groff gzip info insserv klogd
latex-ucs less libacl libattr libcom_err libgcc libjpeg libjpeg-devel
libpng libpng-devel libnscd libstdc++ libtool libxcrypt libzio m4 make
man mktemp module-init-tools ncurses ncurses-devel net-tools netcfg
openldap2-client openssl pam pam-modules patch perl permissions popt
popt-devel procinfo procps psmisc pwdutils python python-devel rcs
readline rpm sed strace swig sysvinit tar tcl tcl-devel tcpd te_latex
texinfo timezone tix unzip util-linux vim zlib zlib-devel.

Take it easy, most of the packages are installed when you selected
develop group. Just watch out to make sure the bellowed packages are
installed:
gd gd-devel swig swig-doc glib-devel swig-examples latex-ucs tcl-devel
libjpeg-devel te_latex libjpeg tetex libpng tix libpng-devel
python-devel.

Finally, do not forget download the source code from source forge.

3, Configuration
use the command line:
./bootstrap
./configure --with-tcl=yes --with-tclcflags="-I /usr/include"
--with-tcllibs=-ltcl8.4

On SuSE Linux Code 10 (OpenSuSE 10.1, SLES/D 10), the default path of
tcl is different to the one in OpenIPMI sourcecode. We need to assign
the arbitrary value by configure.

4, Make
Typing 'make' will compile all the sourcecode.
After compilation completed, typing 'make rungui' can invoke the
openipmigui.
Typing 'make install' will install all the binaries, scripts and
libraries.

5, Build RPM
OpenIPMI packaging is different between SuSE version and sourceforge
version. So, typing 'make rpm' can not generate a set of RPM packages
for SuSE Linux.

The template of RPM spec file should be modified in order to build RPM
packages for SuSE Linux. I'll not touch this topic, we can wait for the
RPM and spec file on OpenSuSE 10.2.

============================================================================

Hope this text helpful to SuSE Linux guys.

Coly

IBM Information Center for Linux / Other considerations when using IPMItool

This topic discusses considerations when using IPMItool with multi-node, multi-BMCs, LAN access, and SOL and BMC LAN access with IBM BladeCenter.

Multi-node and Multi-BMCs

• IPMItool versions 1.8.9 and later include a command line option that allows inband addressing of any BMC resident within the multiple nodes present in multi-node systems.

  The -d < N> IPMItool parameter may be used to target any specific BMC/IPMI device node for running any desired IPMItool command. See the IPMItool man page for more details about how to use this option to send inband commands to any BMC within your multi-node system.

• Maximum number of nodes supported by the OpenIPMI driver in various RHEL and SLES versions

  In early RHEL and SLES versions, the OpenIPMI driver supported a maximum of 4 IPMI device nodes. Due to this limitation, the BMCs beyond those found in the first four nodes were not addressable inband. This 4-node limitation was present in RHEL3 (all), RHEL4 (all), SLES 9, SLES10.

  Some subsequent Linux distributions have an 8-node maximum, including RHEL5 and SLES10.1 Recent Linux distributions with 2.6 kernels now have no limit to the number of BMCs the OpenIPMI driver can support in a multi-node system. RHEL5.1 and beyond, SLES10.2 and beyond.

• IPMI (BMC) device node reversal on 2.6.14 - 2.6.22 kernels

  The Baseboard Management Controllers (BMC) found in many servers are accessed programmatically at the Linux Kernel level by the OpenIPMI device driver. The OpenIPMI driver creates a "device node" special file /dev/ipmi <N> for each BMC found at driver start up which will allow the IPMI driver to access each BMC. On single-node (standalone) systems, there is normally only one BMC and only one of these "device node" files is created (/dev/ipmi0). On multi-node systems, however, each node contains a BMC and a separate device node file is created for each by the OpenIPMI driver (/dev/ipmi0, /dev/ipmi1, etc.).

  An issue was discovered in several Linux distributions in which the device nodes on multi-node systems were named in reverse order of how the BMCs are physically located. In these cases, commands sent to /dev/ipmi0 will actually execute on the BMC physically located last on the system. Commands sent to /dev/ipmi1 are sent to the second-to-last BMC. Note that since only a maximum of 4 nodes are supported by the OpenIPMI driver in early SLES 10 versions, this means that on 8-node systems, the 4 BMCs physically located last in the stack will be the ones addressed (and in reverse order) rather than the BMCs in the (physically) first 4 nodes.

  RHEL and SLES versions affected: If you're running an early SLES10 or RHEL5 distribution, you should see Multi-node Device Names in Wrong Order at https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5075272&brandind=5000008 for information on how to determine whether your system is affected and for information on how to create a udev rules file to work around the issue on your machine. In general, the issue is found in SLES10, SLES10.1, RHEL5, RHEL5.1, and RHEL5.2 (GA version).

  RHEL and SLES versions where fix appears: A RHEL5.2.z kernel update and the RHEL5.3 release contain the fix, but both require user intervention to turn it on: ipmi device nodes will be re-named in physical node order upon reboot after you add the kernel boot parameter "ipmi_dev_order=2" to the kernel command line in /boot/grub/menu.lst. In RHEL6 and SLES 10.2 and beyond, the fix is automatic and is part of the released Linux distribution. No user action is required.

• Warning/informational message in the system message log about BMCs having a common Device ID on some multi-node systems.

  The IPMI specification does not specifically require Device IDs should be unique across BMC instances or simply across specific BMC vendor/model combinations. Whereas the OpenIPMI driver maintainer has defined Device IDs to be unique across all BMCs (such as a GUID would be), some BMC vendors have a common Device ID for all BMCs of an identical model. The OpenIPMI driver maintainer put the warning/informational message into the system message log (/var/log/messages) to identify systems in which Device IDs are not unique for each BMC. This is not an error on your system and will not cause any issues with your IPMI operations.

  Example of the message found in var/log/messages after bootup of a 2-node system:

  IPMI message handler: This machine has two different BMCs with the same product id and device id.

  This is an error in the firmware, but you can increment the device id to work around the problem by using the following:

  Prod ID = 0xe7, Dev ID = 0x20

  This is displayed for each of the BMCs in non-primary nodes.

• Boot parameter numa=acpi

  Is required for correct NUMA initialization on RHEL4.4, RHEL4.5, and RHEL4.6 on multi-node x460, x3950, x3950 M2 systems. Fix is in RHEL4.7. Please see the installation instructions for these machines for more information. For example, in the Red Hat Enterprise Linux Version 4 Update 4 Install Instructions at http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5069533&brandind=5000008#45, in step 3, notice that you need to type

  linux numa=acpi 

  in the boot screen and then press Enter

LAN Access

Note that IPMItool typically can not access the local machine via the LAN. Local IPMItool commands need to go through the Open Interface (the OpenIPMI Driver) by using -I Open or not specifying a -I option at all for the IPMItool command, thereby defaulting to using the Open Interface.

SOL and BMC LAN Access with IBM BladeCenter

SOL with IBM BladeCenter can be done through the Management Module. See the Serial over LAN (SOL) Setup Guide - BladeCenter at http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?brandind=5000008&lndocid=MIGR-54666 for details on how to do SOL for specific BladeCenter platforms. Also the IBM BladeCenter is internally configured such that the LAN channel for the BMC can only be seen by the Management Module. Thus external management of a BladeCenter is accomplished through the Management Module.

Novell Doc Novell ZENworks 7.2 Linux Management Installation Guide - Managed Device Requirements

Novell ZENworks Linux Management provides advanced features to deploy and manage Dell PowerEdge servers. Before you can use these features, you must install a newer release of the OpenIPMI driver than that included in the currently supported Linux distributions.

The following features are available for Dell PowerEdge servers in ZENworks Linux Management:

• Dell Configuration bundles: Let you use Preboot Services to configure a Dell PowerEdge server's BIOS, BMC, RAID, and DRAC settings and to create a Dell utility partition. For more information, see Using Dell Configuration Bundles in the Novell ZENworks 7.2 Linux Management Administration Guide.

• Dell Update Package bundles: Let you update and configure hardware and system settings on Dell PowerEdge servers. For more information, see Using Dell Update Package Bundles in the Novell ZENworks 7.2 Linux Management Administration Guide.

• Dell inventory: Lets you display inventory information specific to Dell PowerEdge servers. After discovering the hardware information about your Dell PowerEdge servers, you can use Dell Update Packages to update them, if necessary. For more information, see Hardware and Software Inventory in the Novell ZENworks 7.2 Linux Management Administration Guide.

• Dell reports: Let you run reports specific to Dell PowerEdge servers to find devices that do not have valid Dell Update Packages installed or to show devices with Dell applications installed (per device or per device model). For more information, see Dell Reports in the Novell ZENworks 7.2 Linux Management Administration Guide.

Dell provides the updated OpenIPMI driver as well as the Dynamic Kernel Module Support (DKMS) package to assist in compiling and installing the driver.

Recommended Links

Softpanorama Recommended

Top articles

Sites

IPMI Specifications

• http://www.intel.com/design/servers/ipmi

IPMITool/OpenIPMI Projects

• http://ipmitool.sourceforge.net
• http://openipmi.sourceforge.net OpenIPMI Library The OpenIPMI Library is a user-level library that provides a high-level abstraction of IPMI programmatic interfaces. It may be used to access IPMI commands and services through the OpenIPMI driver or the LAN interface. The OpenIPMI Library includes several library modules for user-written programs, plus there are several user-level utilities for accessing IPMI information and control. The OpenIPMI Library package is included with most distributions. The OpenIPMI library provides different helpful interfaces from IPMItool. Some of the user-level utilities that are included with the OpenIPMI library include a LAN daemon, command and shell interfaces, a SOL program, a Ping program, and a GUI interface. See the man page included with the OpenIPMI library package for more information.

http://ipmiutil.sourceforge.net IPMI Management Utilities The IPMI Management Utilities (ipmiutil) provides various tools to manage an IPMI system, such as view the IPMI firmware log, perform an IPMI reset, configure the IPMI LAN interface, get and set sensor thresholds, and so on.

Dell OpenIPMI drivers (RHEL/SLES packages)

http://linux.dell.com/files/openipmi

Dell PowerSolutions Articles

Managing and Monitoring High-Performance Computing Clusters with IPMI http://www.dell.com/downloads/global/power/ps4q04-20040138-Fang.pdf

Managing Dell PowerEdge servers using IPMITool http://www.dell.com/downloads/global/power/ps4q04-20040204-Murphy.pdf

• Lights out management (LOM)
• List of computer standards
• Wired for Management (WfM)
• Intel Website (includes specification download)
• OpenIPMI An IPMI client (open source)
• ipmitool Command-line interface to IPMI (open source)
• ipmiutil IPMI client-side utilities (open source)
• GNU Freeipmi IPMI libraries and tools (open source)
• coreIPM Project Firmware for IPMI baseboard management (open source)
• IPM430 CoreIPM firmware ported to TI MSP430. (open source)
• Zhuo, Haihong; Yin, Jianwen; Rao, Anil V.. "Remote Management with the Baseboard Management Controller in Eighth-Generation Dell PowerEdge Servers" (pdf). Dell. http://www.dell.com/downloads/global/power/ps4q04-20040110-Zhuo.pdf. Retrieved 2005-06-20.
• Novell
  • Novell SUSE Linux Enterprise Desktop 10 OpenIPMI
  • Recommended update for OpenIPMI

• Other IPMI-related products, tools, and Open source utilities

  • Lflash Usage, Distribution Support, and Known Limitations Linux Flash, commonly known as LFlash, is a user-level utility that allows run time firmware updating of BIOS, RSA, and BMC hardware, eliminating the need to manually load new firmware or firmware updates from a physical diskette or other medium. Some LFlash considerations specific to IPMI:
    • If the IPMI hardware watchdog is running, it should be stopped prior to running Lflash, and the OpenIPMI ipmi_watchdog driver should be stopped. See the watchdog timer section on how to safely stop the IPMI watchdog timer and watchdog daemon, and to unload the ipmi_watchdog driver.
    • Some older Linux distributions had an issue with LFlash (and IBM Director SEL processing) running too slowly. If you're running a v3.0.0 or v3.0.1 VMWare or RHEL3U6 operating system, see IPMI runs slowly on VMware v3 & RHEL3 U6 OpenIPMI driver - Servers at http://www-304.ibm.com/systems/ support/supportsite.wss/docdisplay?lndocid=MIGR-66581&brandind=5000008 for tips about upgrading your operating system to eliminate this problem. For more information about LFlash:
    • Deployment and Update Tools for xSeries Servers http://www.alphaworks.ibm.com/tech/xseriesdeploy
    • Online update packages (wflash/lflash) http://publib.boulder.ibm.com/infocenter/toolsctr/v1r0/index.jsp?topic=/com.ibm.xseries.tools.doc/ update_tools_lflash.html

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019