>> ./src/ipmitool -I open chassis status
>> Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0:
that's local ipmi, which to me is quite beside the point. ipmi is valuable
primarily for its out-of-band-ness - that is, you can get to it when
the host is off or wedged.
> you're connecting locally over the IPMI bus. Here's the modules I see
> loaded on one of my RHEL5 Dell systems:
>> ipmi_devintf 44753 0
> ipmi_si 77453 0
> ipmi_msghandler 72985 2 ipmi_devintf,ipmi_si
>> If you can't get the IPMI devices working even after loading those
> modules, you might try looking at configuring your system's IPMI network
> interface manually. You should be able to do this during the boot
> process on any system (look for a device called "Service Processor" or
> "Baseboard Management Controller" after POST and before the OS boots).
> Some systems also have their own non-IPMI ways of configuring IPMI. If
on our dl145's, we don't normally have local ipmi enabled at all,
since it's inferior to remote. but
modprobe ipmi_devintf;modprobe ipmi_si
loads it, which can be useful for something like
ipmitool user set password 3 foobar
or
ipmitool mc reset
> you're on Dell you can use OpenManage's omconfig command-line tool.
IMO, proprietary tools are evil. using them encourages vendors to
diverge from open standards and hurts everyone, and in the long-term.
demand standards and just say "no" to non-standards, especially when
venors claim that they're supra-standard features. if we as computer
people have learned anything at all from our own history,
it is that open standards drive everything in the end.