On Tuesday, January 27, 2015 at 10:02:06 PM UTC-6, Eli Young wrote: > > > On Tuesday, January 27, 2015 at 2:53:46 PM UTC-8, John Bollinger wrote: >> >> >> As far as I can tell, it is a design characteristic of the current hosts >> file format that it associates each address with exactly one canonical >> name, and each canonical name with exactly one address. This is a bit >> ticklish, though, because there seems to be no canonical reference for the >> file format itself. Nevertheless, the Linux manpage for it says it has *one >> line* per IP address, and that "[f]or each host *a single line* should >> be present [...]" (emphasis added). >> > > I've done some investigation into various implementations of DNS resolvers > and can say that the documentation (or at least this interpretation > thereof) is inaccurate. getaddrinfo(3) >
DNS resolvers are irrelevant to the hosts file format. The hosts file is not a *DNS* data source, even if resolver libraries happen to consult it, too. In fact, the original objective of DNS was to altogether replace hosts files. That *getaddrinfo*(3) can provide multiple records for one canonical name in no way implies that every data source it draws upon is expected to be able to describe such data. Moreover, the official specification for *getaddrinfo*(3) <http://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html> (from POSIX 1003.1) does not even mention the hosts file, so it is completely up to implementations whether to use such a file, and if so, how. (POSIX doesn't even require that the function perform resolutions against DNS, though it notes that many implementations in fact do so.) > , which is used on all platforms including Windows to resolve hostnames, > provides a linked list of results and can optionally provide the canonical > hostname. When a hostname is listed in the hosts file multiple times, > getaddrinfo(3) provides all the IP addresses that are listed for that host, > just like it would if it had to fetch that information from DNS. > Sorry, you simply cannot support that based only on use of the *getaddrinfo*(3) interface. The behavior of that function is implementation-defined with respect to ALL data sources, even DNS. As you yourself observe, its behavior in fact does differ among implementations. It is flexible enough to support the behavior you describe, which is common, but it cannot be taken as any sort of specification for hosts files. I have more regard for your survey of actual implementations, though. [...] > So yeah. I do think that the host type should support specifying multiple > IPs for the same hostname, because every resolver implementation I can > track down seems to support that (with the possible exception of Solaris, > which I can check tomorrow, though I very much doubt that it'll prove an > outlier). > It is a big step from "known resolvers handle hosts files giving multiple addresses for the same name" (in not altogether consistent ways) to "Puppet's Host resource should be modified to support multiple addresses per name", and even a bigger one to "Host resources should be modified to have a composite namevar." I did not and do not deny that there is a problem to be solved here, but on the other hand, I don't necessarily agree with your characterization of the problem or your proposed solution. > This makes sense as the hosts file is something of a poor man's > lightning-fast DNS server. It may be worth also putting some logic in to > detect cases where a hostname is specified as both a canonical name and an > alias and throwing a warning or an error. Also to detect cases (at least > on OS X) where an alias is specified for some but not all of the IP > addresses listed for its canonical name. > > > >> Indeed, though the type's documentation merely says that a Host resource >> represents a "host entry", the longtime design demonstrates that it more >> specifically represents a mapping from a canonical hostname to properties >> of that hostname including a network address. It is implicit in the >> historic use of hostname alone as namevar that duplicate canonical names >> cannot be modeled. That these entries are typically recorded in /etc/hosts >> (on some systems) is in fact a function of the provider and of the 'target' >> property, so really the format and allowed usage of particular host files >> in particular contexts can be only weak guidance for whether the model is >> appropriate. >> > > By contrast, in Chef the namevar is the IP address > <https://github.com/customink-webops/hostsfile/>. The fact that the > canonical hostname is the namevar here is merely a choice that was made > when the type was designed, and I am of the opinion that the design is > flawed. > > I agree that a different namevar could as easily have been chosen back when the Host resource was designed. Inasmuch as the Host resource does not support multiple addresses for the same name, and that is a desirable feature, it is inarguable that the design has an unfortunate limitation. Call it a flaw if you will. At the time the type was designed, however, hostname as namevar better suited Puppet's capabilities and users' requirements, particularly with respect to resource relationships. It would be rare for another resource to depend on there being a name mapped to (say) address 10.11.12.13, but it is reasonably common for another resource to depend on a name such as 'myservice.my.com' being mapped to an address. Only with the advent of the chain operators did Puppet gain the ability to declare relationships other than via the target resource's namevar. > Objection, Your Honor! Describing the issue as flawed parsing assumes >> that the files being parsed are correct, and that they are (intended to be) >> supported by Puppet, but the validity of both assertions is unclear. To be >> sure, Host files containing more than one record bearing the same canonical >> name do not comply with Puppet's model for host entries. It is >> unsurprising that Puppet does not handle such files well, but that could as >> easily be ascribed to invalid/incompatible files as to flawed parsing. >> > > This is true, and doesn't really matter for a system entirely provisioned > by/with Puppet, but if one is attempting to Puppetize infrastructure that > already exists, this may well be a problem, one with no good solution at > present other than to fall back to managing the hosts file with a file > resource. This is suboptimal. > Agreed. I never argued that there wasn't any issue here. > > >> Additionally, perhaps it would be better to deprecate the Host resource >> in favor of something different, maybe a "HostEntry", that is not burdened >> with the same limitations. >> > > I actually suggested this very thing in my most recent comment on the > JIRA issue > <https://tickets.puppetlabs.com/browse/PUP-3901?focusedCommentId=133116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-133116>, > > albeit as part of way to enable relationships without requiring collectors. > I think your suggestion could be tweaked such that introduction of the proposed new resource type didn't require *any* change to most existing code. If, just as you suggested, the hypothetical new type, "Hostentry" / "Hostname" / whatever, 1. autogenerated a corresponding Host resource, and 2. created a 'before' relationship from itself to the corresponding Host, then other resources could continue to 'require' Host resources just as they do now. (I assert that other than as described above, no useful purpose is served by a 'before' edge targeting a Host resource). Furthermore, with a bit of care in the type implementation, and perhaps a new parameter or two for the Host resource, this scheme could also cause duplicate resource errors to be properly thrown when a manually-declared Host resource conflicts with a Hostentry resource. Avoiding a breaking change is an attractive feature of this strategy in its own right, but it has the additional advantage that it does not require hurrying to get an implementation into Puppet 4 (or waiting years for Puppet 5). With P4 imminent, I am uncertain whether there is any chance at this point to get an additional change/features into 4.0.0. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/776d5856-c696-4c6d-9295-70bff9423665%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
