30.10.2012 04:27, Andrew Beekhof wrote: > On reflection, I think making this configurable is going to cause more > trouble than its worth. > Any sysconfig mismatch between the nodes would result in major breakage. > > We need to pick one way and make it the default - if people want/need > anything else, they need to use the corosync node list. > For consistency with older releases, I think your original "strip > everything" patch is the best way to go.
That is OK for me as I currently use it. Although I'd ask you to think again about stripping "known" domain name part from resolver-provided FQDN if uname and FQDN of local node match at the beginning. Something says me this would provide better backwards compatibility, while visible result for the discussed use-case will be exactly the same. I know at least one cluster (not mine) which will be broken if just to strip everything at the first dot - it uses long hostnames (and this is the default for a fresh-installed redhat/fedora if you enter FQDN in the anaconda prompt when installing a node). Also, way I propose provides better flexibility - assume that one sets hostname using two lexems from FQDN - node01.cluster01 (or n01.c01) instead of just node01 or n01. FQDN itself could be n01.c01.some.location.domain.com. That could be done just to add safety for shell actions - hostname is usually shown in the shell prompt (I recall many cases when I issued command on a different host from I thought I do it on). The same applies to cluster commands. If visible nodenames have some (administrator controlled) hints, cluster could be safer to operate. And this way should not cause any breakage - cluster node are usually named the same way and no additional configuration is involved. I can develop patch for that if you want. It would introduce one global var (domain name), and will have one extra call to uname() and three or less calls to string-handling functions. > > On Fri, Oct 26, 2012 at 9:57 PM, Vladislav Bogdanov > <bub...@hoster-ok.com> wrote: >> 26.10.2012 13:38, Vladislav Bogdanov wrote: >>> 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. >> >> Ah, that is for local node only... >> For remote nodes I would strip FQDN part which begins right at that dot >> where FQDN of local node and its uname differ. >> >> my_ring_address == 10.0.0.XXX >> my_uname() == "host232" >> getaddinfo(my_ring_address) == host232.some.very.long.domain.name.com. >> >> my_node_name = "host232" >> my_domain = "some.very.long.domain.name.com." >> >> his_ring_address == 10.0.0.YYY >> getaddinfo(his_ring_address) == host238.some.very.long.domain.name.com. >> >> strstr("host238.some.very.long.domain.name.com.", my_domain) != NULL >> >> his_node_name = "host238" >> >> >>> >>> 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 >>> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 > _______________________________________________ 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