Bug 843083
| Summary: | fence_xvm reports success while the operation has failed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jaroslav Kortus <jkortus> | ||||
| Component: | cman | Assignee: | Ryan McCabe <rmccabe> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 5.8 | CC: | cluster-maint, edamato, mjuricek | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | cman-2.0.115-104.el5 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-01-08 03:37:39 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release. Created attachment 600315 [details]
Backported fix from RHEL6
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-2013-0076.html |
Description of problem: While using incorrect hashes, the fence_xvm detects the failure correctly but returns bad status, effectively faking successful fencing operation. Correct hashes in the example below are sha256/sha256. What's interesting is that sha256/sha512 combination results in successful fence. Is this expected behaviour? [root@c1-node01:~]$ fence_xvm -C sha512 -c sha256 -k /etc/cluster/fence_xvm.key -H c1-node02 Hash mismatch: C = a6aec2b23580c27f9060a4f8149c42864db748478efdecec38f5a6002f5d5b26e1157c0fbb63d2a30304aa7de191e044152b02c04dcc34ee681fca2f977ad1e5 H = 599067580117c396b5846d0fe5e38fe9e871ce8566e283a87ce332794d2be5197e8caaf24285f7dd8578a5dc29735b410383f65540478cd5cd4f999ddbfe30d2 R = 0cf2eae9677c206cf0d74404d13949fd6c4ab1773fe68a8ef870976c51f5d0880000000000000000000000000000000000000000000000000000000000000000 Invalid response to challenge (09:19:59) [root@c1-node01:~]$ echo $? 0 RHEL6 host fence_virtd.conf: $ cat /etc/fence_virt.conf fence_virtd { listener = "multicast"; backend = "libvirt"; } listeners { multicast { key_file = "/etc/cluster/fence_xvm.key"; address = "225.0.0.12"; hash="sha256"; auth="sha256"; interface="virbr0"; } } backends { libvirt { uri = "qemu:///system"; } } Version-Release number of selected component (if applicable): cman-2.0.115-101.el5 How reproducible: always Steps to Reproduce: 1. use fence_xvm with different parameters from what's in fence_virtd.conf 2. 3. Actual results: fencing operation reported as successful while it has actually failed Expected results: return code should be > 0 if response-challenge authentication fails. Additional info: