Hide Forgot
> Description of problem: Attempts to update the cluster configuration with 'cman_tool -r version' when the file contains an ampersand '&' (i.e. in the password field of the fence device) fail. The same attempt using Conga succeeds. > Version-Release number of selected component (if applicable): cman-3.0.12-41.el6 > How reproducible: Always. > Steps to Reproduce: 1. Using Conga, add a fence device that requires password (such as an iLO) and enter a password that contains an ampersand. The configuration is updated successfully. 2. Manually edit the cluster.conf file and increase its version. 3. Try to update the configuration from the command line with 'cman_tool -r version'. > Actual results: The cluster.conf validation fails since ccs_config_dump output doesn't match /etc/cluster/cluster.conf: # cman_tool -r version tempfile:15: parser error : EntityRef: expecting ';' e_ilo" ipaddr="10.33.11.95" login="jentrena" name="RHEV4" passwd="jander&klander ^ cman_tool: Not reloading, configuration is not valid > Expected results: The cluster configuration is updated successfully: # cman_tool -r version # > Additional info: Updating a cluster.conf file that contains an ampersand is possible from Conga, but not from the command line. This is not an XML validation problem, since manually validating the cluster.conf file succeeds: # xmllint --relaxng /usr/share/cluster/cluster.rng /etc/cluster/cluster.conf <?xml version="1.0"?> <cluster config_version="2" name="cl60"> <clusternodes> <clusternode name="cl60n1" nodeid="1"/> <clusternode name="cl60n2" nodeid="2"/> </clusternodes> <cman expected_votes="1" two_node="1"/> <fencedevices> <fencedevice agent="fence_ilo" ipaddr="10.33.11.95" login="testuser" name="ilotest" passwd="jander&klander"/> </fencedevices> </cluster> /etc/cluster/cluster.conf validates The problem seems to be in ccs_config_dump: # ccs_config_dump > cluster.dump # diff cluster.dump /etc/cluster/cluster.conf 9c9 < <fencedevice agent="fence_ilo" ipaddr="10.33.11.95" login="testuser" name="ilotest" passwd="jander&klander"/> --- > <fencedevice agent="fence_ilo" ipaddr="10.33.11.95" login="testuser" name="ilotest" passwd="jander&klander"/>
http://git.fedorahosted.org/git/?p=cluster.git;a=commitdiff;h=ccfe7c7037d784cd4b004a4ff808f93517738247 How to test the patch and test results: add a semi-random & in cluster.conf: for example: <fencedevices> <fencedevice name="xvm" agent="fence_xvm&"/> </fencedevices> (cluster is not running/can´t start) ccs_config_validate will fail update packages to the new version ccs_config_validate will succeed cluster can/will start Attempt to update config (just bump the version num is sufficient) config will be loaded correctly (cluster.conf was propagated manually, ricci uses xml to import/export the config and the saveXML functions should do the right thing) the above tests will verify ccs_config_dump code path. To test the equivalent changes in libccs, keep the above cluster running and perform ccs_tool query. By default ccs_tool use libccs fullxpath implementation (the bits that have been modified) [root@rhel6-node2 cluster]# ccs_tool query /cluster/fencedevices/fencedevice/@agent fence_xvm& and double check with direct output from xmlimport in objdb: [root@fedora14-node2 cluster]# ccs_tool query -n /cluster/fencedevices/fencedevice/@agent fence_xvm& [root@fedora14-node2 cluster]# corosync-objctl |grep fencedevice.agent cluster.fencedevices.fencedevice.agent=fence_xvm&
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: xml format requires special handling of some characters Consequence: the handling of those characters was not implemented correctly, causing cluster.conf not to function as expected Fix: implemented correct handling of characters Result: cluster.conf works as expected
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1516.html