Red Hat Bugzilla – Bug 906432
Corosync 1.4.1 does not support IPv6 double colon notation in /etc/corosync/corosync.conf totem section
Last modified: 2013-11-20 23:32:09 EST
Created attachment 691039 [details] Proposed patch - part 1 - Handle colon on end of value +++ This bug was initially created as a clone of Bug #901536 +++ Created attachment 682396 [details] Working IPv6 UDPU corosync.conf Description of problem: Corosync 1.4.1 does not support IPv6 double colon notation in /etc/corosync/corosync.conf totem section, starts successfully according to logs but fails to start the actual service. Version-Release number of selected component (if applicable): [root@ns4 corosync]# corosync -v Corosync Cluster Engine, version '1.4.1' Copyright (c) 2006-2009 Red Hat, Inc. How reproducible: Always. Steps to Reproduce: 1. Use an IPv6 memberaddr and bindaddr, with double colon notation to shorten the address, in /etc/corosync/corosync.conf's totem section. 2. service corosync start 3. Watch the service fail to come up, check logs to see incomplete startup sequence. Actual results (with double colon notation): ================================================================== [root@ns4 corosync]# service corosync start Starting Corosync Cluster Engine (corosync): [FAILED] Meanwhile, in /var/log/cluster/corosync.log: Jan 18 11:39:42 corosync [MAIN ] Corosync Cluster Engine ('1.4.1'): started and ready to provide service. Jan 18 11:39:42 corosync [MAIN ] Corosync built-in features: nss dbus rdma snmp Jan 18 11:39:42 corosync [MAIN ] Successfully read main configuration file '/etc/corosync/corosync.conf'. Jan 18 11:39:42 corosync [TOTEM ] Initializing transport (UDP/IP Unicast). Jan 18 11:39:42 corosync [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0). ================================================================== Expected results (as seen without double colon notation): ================================================================== [root@ns4 corosync]# service corosync start Starting Corosync Cluster Engine (corosync): [ OK ] Jan 18 13:37:17 corosync [MAIN ] Corosync Cluster Engine ('1.4.1'): started and ready to provide service. Jan 18 13:37:17 corosync [MAIN ] Corosync built-in features: nss dbus rdma snmp Jan 18 13:37:17 corosync [MAIN ] Successfully read main configuration file '/etc/corosync/corosync.conf'. Jan 18 13:37:17 corosync [TOTEM ] Initializing transport (UDP/IP Unicast). Jan 18 13:37:17 corosync [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0). Jan 18 13:37:17 corosync [TOTEM ] The network interface is down. Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync extended virtual synchrony service Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync configuration service Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync cluster closed process group service v1.01 Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync cluster config database access v1.01 Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync profile loading service Jan 18 13:37:17 corosync [SERV ] Service engine loaded: corosync cluster quorum service v0.1 Jan 18 13:37:17 corosync [MAIN ] Compatibility mode set to whitetank. Using V1 and V2 of the synchronization engine. ================================================================== Additional info: Attached is the corosync.conf that works. To make it fail, replace fc00:1c7:da7a:3:0:0:0:0 with fc00:1c7:da7a:3:: and repeat this for every other IPv6 address in the config. I've also tried running this with debug: on, but no extra log messages were dumped. --- Additional comment from Jan Friesse on 2013-01-31 09:23:21 EST --- Hi, thanks for bug report. This is problem in corosync parser, which removes trailing ::, so address will end up being fc00 (what is invalid IPv6 address and is handles as dns name). --- Additional comment from Jan Friesse on 2013-01-31 10:59:33 EST --- Problem is now fixed in upstream as c04af91ada3c4ca29643cad599ed5605f6bb10bd. There is also another problem in parsing with extra close brace. This is fixed by 60a9f809c17d6cfe73c34263233dbf8e4677d6b5. Thanks again for BZ, closing as upstream.
Created attachment 691040 [details] Proposed patch - part 2 - Handle unexpected closing brace
"Unit" tests for both bugs are: https://github.com/jfriesse/csts/commit/fd1f0cf6e2ea5650af9d68ad1e7ea3ae721d3406 https://github.com/jfriesse/csts/commit/0a976463bf712e619e37f17b7e776501df36ab7c Result of unpatched package: $? != 0 Result of patched package: $? == 0
Tested with config-unexpected-closing-brace.sh and config-parse-colon.sh: FAIL on corosync-1.4.1-15.el6.x86_64 (RHEL6.4) PASS on corosync-1.4.1-17.el6.x86_64 (RHEL6.5) Following config works in 1.4.1-17 and did not work with 1.4.1-15: interface { ringnumber: 0 bindnetaddr: 3456:: mcastaddr: ff02:111:: mcastport: 5405 ttl: 1 } Marking as verified
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-1531.html