Change Ipmi port
damned6 opened this issue · 11 comments
Hi, i check some remote servers through Ip Nat, so not all 623 udp port is natted to the 623 udp port of the public ip...is possible to specify another port?
Thanks
The FreeIPMI Tools allow the specification of a port according to the manpage ("man ipmi-sensors"):
-h IPMIHOST1,IPMIHOST2,..., --hostname=IPMIHOST1[:PORT],IPMI‐
HOST2[:PORT],...
Specify the remote host(s) to communicate with. Multiple host‐
names 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.
So you could just try to execute the plugin in the following way
./check_ipmi_sensor -H [IP]:[PORT] -U [username] -P [password] -L [user]
For me this worked in a test, using the default port :623. But I'm not 100% sure whether the plugin handles it correctly for forward the port information to ipmi-sensors.
As I don't have a NAT-setup currently here, I ask you to just test it and give us feedback whether it worked for you :-)
It worsk!
Thanks! : )
btw..is there a way to increase the timeout?
it could be useful with remote systems..
Hi again (and sorry for not replying earlier, I've overlooked your message).
FreeIPMI has a default timeout of 20 seconds (see ipmi-sensors man page):
--session-timeout=MILLISECONDS
Specify the session timeout in milliseconds.
Defaults to 20000 milliseconds (20 seconds) if not specified.
Nagios/Icinga's service check timeout can also be configured, see https://docs.icinga.com/latest/en/configmain.html#configmain-service_check_timeout
Thanks!
Now the timeout problems was gone and from the shell woks, with the command:
/usr/local/nagios/libexec/check_ipmi_sensor -H ip:port -U USERID -P PASSW0RD -L user -x 69,70,71 -O --session-timeout=500000000
But from nagios web interface i’ve got this error:
ipmi_ctx_open_outofband_2_0: bad rmcpplus status code
do you know what it could be?
Sorry for my late reply. Try to run the plugin with the -vvv option to see how it calls "ipmi-sensors". According to the manpage of "ipmi-sensors" you could try the "opensesspriv" workaround:
Inventec 5441, Supermicro X8DTH: 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. This may cause "password invalid" or "bad rmcpplus status code" errors to occur. It can be worked around by specifying the "opensesspriv" workaround.
You could then try to run the ipmi-sensors command with the workaround option. See also https://www.thomas-krenn.com/en/wiki/IPMI_Sensor_Monitoring_Plugin#FreeIPMI_Configuration for further details.
Hi @damned6
do you still have the error "ipmi_ctx_open_outofband_2_0: bad rmcpplus status code" or has the the opensesspriv helped?
No problem - thank you for your answer.
As you have solved your issue I hereby close it :-)
Hi!
We are using your plugin to monitor over 100 hardware hosts (dell). It works great! But sometimes we get the same thing like damned6: 'ipmi_ctx_open_outofband_2_0: bad rmcpplus status code'. A simple recheck solves the problem. We aren't quite sure where the problem is: It can be dell firmware (which is buggy), it can be the ipmi-sensors that's producing the problem, it can be the plugin.
We already tried to use the "opensesspriv" workaround but without success. Is it possible to implement some kind of a "retry-if-unknown" functionality? We can hack around in locally, but that's not f good solution at all.
Best regards, Petr Zaytsev
P.S.
The config file we use for the plugin:
workaround-flags opensesspriv
username read-only
password read-only
privilege-level USER
session-timeout 20000
ipmi-sensors-interpret-oem-data on
ipmi-sensors-ignore-unrecognized-events on
Ok, I'll give it a try with more retries. I hope that Thomas will have time to find a better solution.