Red Hat Bugzilla – Bug 428219
FQDN in cluster.conf causes issues with fencing
Last modified: 2009-04-16 15:46:17 EDT
Description of problem: In RHEL4, cman_tool status/node reports a non FQDN even if the node in the cluster.conf is. This will cause fencing to fail. <?xml version="1.0"?> <cluster config_version="4" name="TAFT"> <cman> </cman> <fence_daemon clean_start="0" post_fail_delay="30" post_join_delay="30"/> <clusternodes> <clusternode name="taft-01.lab.msp.redhat.com"> <fence> . . . [root@taft-01 ~]# cman_tool status Protocol version: 5.0.1 Config version: 4 Cluster name: TAFT Cluster ID: 1156 Cluster Member: Yes Membership state: Cluster-Member Nodes: 4 Expected_votes: 4 Total_votes: 4 Quorum: 3 Active subsystems: 0 Node name: taft-01 Node ID: 3 Node addresses: 10.15.89.67 [root@taft-01 ~]# vi /etc/cluster/cluster.conf [root@taft-01 ~]# cman_tool nodes Node Votes Exp Sts Name 1 1 4 M taft-02 2 1 4 M taft-03 3 1 4 M taft-01 4 1 4 M taft-04 This is not the case in RHEL5 Version-Release number of selected component (if applicable): 2.6.9-67.ELsmp fence-1.32.50-2.fencescsi.test.patch
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This has to do cman not giving fenced what's in the cluster.conf file. <clusternodes> <clusternode name="taft-01.dark.lab.msp.redhat.com" nodeid="1"> <fence> <method name="1"> <device name="scsi" node="taft-01.dark.lab.msp.redhat.com"/> </method> </fence> </clusternode> [root@taft-02 tmp]# hostname taft-02.lab.msp.redhat.com [root@taft-02 tmp]# cman_tool nodes Node Votes Exp Sts Name 1 1 4 M taft-04 2 1 4 M taft-03 3 1 4 M taft-01 4 1 4 M taft-02
Created attachment 291370 [details] Patch to fix The patch is attached, and quite trivial. I'd be tempted to say that the possible repercussions of it are almost nil, but I've been horribly wrong about that before! It is just a cosmetic change. It does NOT change the way that cman decides which interface or hostname to use, merely what it thinks the node names are. One warning though: You will need to restart the whole cluster after applying this patch. If you apply it to a single node and ask it to rejoin the cluster it will be rejected, because the hostname doesn't natch the previous name associated with that node ID.
on RHEL4 branch: Checking in cman/cman_tool/join_ccs.c; /cvs/cluster/cluster/cman/cman_tool/Attic/join_ccs.c,v <-- join_ccs.c new revision: 1.7.2.9; previous revision: 1.7.2.8 done on RHEL46 (for z-stream) branch: Checking in cman/cman_tool/join_ccs.c; /cvs/cluster/cluster/cman/cman_tool/Attic/join_ccs.c,v <-- join_ccs.c new revision: 1.7.2.8.4.1; previous revision: 1.7.2.8 done
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 the 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-2008-0799.html