26.10.2012 12:43, Andrew Beekhof wrote: ... >> May be also set it forcibly to uname if uname contains full lexem found >> in dns name? > > Run that past me again?
I mean that if ip address resolves to fqdn, and that fqdn begins with what uname call returns (so both node itself and DNS agree on a node name for a node with give IP address), then that value from uname could be safely used directly. To illustrate: ring_address == 10.0.0.XXX uname() == "host232" getaddinfo(ring_address) == host232.some.very.long.domain.name.com. then "host232" could be safely used as a node name (but not "host23" and not "host232.s") Of course, it would be even more safe if gentnameinfo("host232") or getnameinfo("host232.some.very.long.domain.name.com.") returns 10.0.0.XXX, so additional check may be introduced. That is normal for "correct" static DNS setups, where PTR record is consistent with what node has configured as a hostname internally. That is also what I have for DHCP-based static address assignments (central configuration place for a whole cluster network), where node usually sets (or at least can be configured to set) its name to what DHCP server says. And DHCP server is usually set up to update A and PTR records in DNS zone. Also that should work correctly when FQDN is used as an uname (long hostname), like redhat setups usually do. Anyways, if FQDN does not begin with uname, then DNS info should be used for node name (like it is now), possibly with that "strip" hack. That could be useful for multi-ring setups I think. Vladislav _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org