--- Additional comment from jkortus on 2010-03-15 14:43:36 EDT --- [root@z1 sbin]# fence_apc_snmp -a 1.1.1.1 -l x -p x -n 4 Timed out waiting to power ON Success: Rebooted [root@z1 sbin]# echo $? 0 Is this behaviour as intended? I tried it also against 127.0.0.1 an the result is identical. Does this really check that the node was powered off (i.e. fenced) which is very key part of fencing? ------------------------------------- I tried with 127.0.0.1 (a host w/o SNMP): [lhh@localhost fenced]$ fence_apc_snmp -a 127.0.0.1 -l x -p x -n 4 -o off Success: Already OFF [lhh@localhost fenced]$ echo $? 0 This means that if someone mistypes IP address in cluster.conf that fencing will always succeed.
Created attachment 400429 [details] Proposed patch Proposed patch, committed to git master branch as fa9d0561d813b2d2002623e0aad665a5949fcc59 Net-SNMP command-line utilities have interesting "feature" causing too short pass-phrase (shorter then 8 characters) write error but sadly, not return error code. In such case, fencing can be considered successful even if it is not. Patch fixes this by: - Pass v3 options only for v3 mode - Search for Error string in snmpcmd output
Commited in RHEL55 branch as 78e7ffd2488b53e627482e78d9f7a23d0b4ba514
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: User use new SNMP FA with password option (used for SNMP v3) and enters password shorter then 8 characters. Consequence Fence agent returns invalid return value. In all cases, it return off, even if host doesn't exist and/or host is on. Fix Workaround call of snmpget/snmpwalk so if Error string is present, error is returned form FA. Result If password is shorter then 8 characters, proper error is returned.
works as expected now, tested with snmpv1 and snmpv3. cman-2.0.115-34.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0266.html