[Pacemaker] RFC: Any interesting in 2.0.0 betas?
Vladislav Bogdanov
bubble at hoster-ok.com
Fri Oct 26 10:38:58 UTC 2012
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
More information about the Pacemaker
mailing list