{"id":368,"date":"2011-04-29T23:01:20","date_gmt":"2011-04-30T05:01:20","guid":{"rendered":"http:\/\/benincosa.com\/blog\/?p=368"},"modified":"2014-11-19T11:25:16","modified_gmt":"2014-11-19T17:25:16","slug":"dell-ipmi-issues-with-xcat","status":"publish","type":"post","link":"https:\/\/benincosa.com\/?p=368","title":{"rendered":"Dell IPMI issues with xCAT"},"content":{"rendered":"

One of our customers had some Dell R410 machines that were humming along just nicely. \u00a0One day something happened and all of the sudden xCAT rpower stopped working. \u00a0Was it that we updated the firmware? \u00a0Was it new xCAT code? \u00a0We couldn’t figure it out.<\/p>\n

Our first epiphany came when we realized that ipmitool worked just fine with lan (IPMI 1.5) and lanplus (IPMI2.0). \u00a0ipmitool works? \u00a0Why didn’t xCAT? \u00a0It turns out that there was a problem authenticating. \u00a0In fact, if we used lanplus, we didn’t have to even enter the correct password and we could turn machines off and on!<\/p>\n

# ipmitool -I lanplus -U user1 -P thispasswordisbogus -H node001-drac -C 0 mc info<\/p>\n

Wow! \u00a0That’s a major security violation. \u00a0We alerted Dell. \u00a0But that still didn’t get xCAT’s rpower working. \u00a0As a temp solution, we modified \/opt\/xcat\/lib\/perl\/xCAT\/IPMI.pm to not try IPMI 2.0 and instead use only IPMI 1.5. \u00a0This worked fine for some things, but the great necessities of rcons, reventlog, and rinv would have taken more time to get working… and after all this was a temporary patch right?<\/p>\n

So today I woke up determined to resolve the issue once and for all. \u00a0Working with Dell support (who were very nice and eager to help us) I figured out that there was a an IPMI Encryption key that was set to some random 40 character\u00a0hexadecimal\u00a0string. \u00a0How it was set, I still don’t know. \u00a0Viewing it in the iDRAC looked like this:<\/p>\n