Cause:
=======
User wants use fence_ipmilan agent, without specifying -M parameter.
Consequence:
============
Because memory is not properly initialized, agent called without -M parameter can:
- Use onoff method as usual and expected. OR
- Fail with message "method, if included, muse be 'onoff', 'cycle'". OR
- use cycle method
Fix:
====
Correctly initialize -M parameters memory
Result:
=======
Without using -M, default action is now correctly always onoff.
DescriptionChris Marcantonio
2009-10-30 20:34:41 UTC
Description of problem:
We recently introduced the -M option in fence_ipmilan to support different methods to reboot when fencing (either "onoff" or "cycle") in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=522529
The introduction of this attempts to allow you to set -M if needed. If it is unset after reading in all arguments, we try to default to "onoff" here:
if (!strlen(method))
snprintf(method, sizeof(method), "onoff");
A few lines down from here, we test to make sure method is set to either "onoff" or "cycle" and bomb out if it isn't:
if (strcasecmp(method, "onoff") &&
strcasecmp(method, "cycle")) {
fail_exit("method, if included, muse be 'onoff', 'cycle'.");
Somehow, I kept hitting this block of code and the fence agent kept failing with:
failed: method, if included, muse be 'onoff', 'cycle'.
even though I wasn't using -M at all. Dropping in a few debug statements and looking through this a bit, I believe this is because we never properly initialize the method variable, so sometimes the random chunk of memory it grabs when allocating "char method[64];" is detected as a non-zero length string.
Unfortunately, this isn't always reproducible...sometimes it works fine, other times it fails like above.
I also believe this introduces a possible regression, because previously existing clusters using the fence_ipmilan fence agent without a method specified (since it didn't exist until just recently) are vulnerable to breakage because of this.
Version-Release number of selected component (if applicable):
# rpm -q cman
cman-2.0.115-1.el5_4.3
# fence_ipmilan -V
fence_ipmilan 2.0.115 (built Sep 29 2009 08:55:13)
Copyright (C) Red Hat, Inc. 2004 All rights reserved.
How reproducible:
Rather randomly.
Steps to Reproduce:
1. upgrade to the newest cman package above which includes the new "method" option for fence_ipmilan
2. issue fence_ipmilan without using a -M option
Actual results:
Sometimes, fencing fails with "failed: method, if included, muse be 'onoff', 'cycle'."
Expected results:
Fencing event should complete successfully. If no -M is specified, then the option should properly default to "onoff".
Additional info:
This is a pretty simple one line patch to properly initialize the method variable:
diff -up ./fence/agents/ipmilan/ipmilan.c.ORIG ./fence/agents/ipmilan/ipmilan.c
--- ./fence/agents/ipmilan/ipmilan.c.ORIG 2009-10-30 16:36:43.000000000 -0400
+++ ./fence/agents/ipmilan/ipmilan.c 2009-10-30 16:37:33.000000000 -0400
@@ -1064,6 +1064,7 @@ main(int argc, char **argv)
memset(passwd, 0, sizeof(passwd));
memset(user, 0, sizeof(user));
memset(op, 0, sizeof(op));
+ memset(method, 0, sizeof(method));
if (argc > 1) {
/*
Comment 1Chris Marcantonio
2009-10-30 20:38:13 UTC
Release note added. If any revisions are required, please set the
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause:
=======
User wants use fence_ipmilan agent, without specifying -M parameter.
Consequence:
============
Because memory is not properly initialized, agent called without -M parameter can:
- Use onoff method as usual and expected. OR
- Fail with message "method, if included, muse be 'onoff', 'cycle'". OR
- use cycle method
Fix:
====
Correctly initialize -M parameters memory
Result:
=======
Without using -M, default action is now correctly always onoff.
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