On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <pbrobin...@gmail.com> wrote: >>> >>> It is intended as a convenient fallback mechanism, and is only supposed >>> >>> to have an effect if 'gateway' is not defined in the local DNS (the >>> >>> 'domain' or 'search' zones). Would it help if those limitations were >>> >>> more explicit, e.g. documented in nss-myhostname(8)? >>> >> >>> >> I understand that the goal is that nss_myhostname will not override >>> >> existing names, due to the way the NSS is configured. >>> >> >>> >> What I do not understand is how the the “gateway” name can be >>> >> useful. >>> > >>> > Here's a very obvious, trivial example: wherever I am I can now simply >>> > type "ping gateway" to know whether connectivity to my local router >>> > works. >>> >>> But that's not actually true, isn't it? If nss_myhostname doesn't >>> override “gateway”, the outcome depends on the network you are on. With >>> a captive portal, you are likely pinging the portal server, not the >>> default gateway. And if you are on one of Microsoft's corporate >>> networks, you might end up at gateway.microsoft.com (whatever this >>> is). >> >> Well, IRL you'd actually quickly notice, since ping shows you the full >> fqdn of the host, and hence gives you a very clear hint on what it is >> actually pinging. >> >>> Because it's so unreliable, we cannot put this trick into documentation, >>> and we shouldn't train users to rely on this functionality. >> >> Yeah, single-label names are like that. If you want trustable >> single-label names, you better shouldn't use search domains (and quite >> frankly, I am not particularly a fan of the search domain concept >> myself, because of its ambiguities. In systemd-resolved we by default >> ignore the DHCP-reported search domains because of this.) >> >> Note that systemd-resolved's LLMNR implementation actually excepts >> itself from resolving "gateway" even though a single-label name (it >> also excepts itself from a couple of other names, such as >> "localhost"). Which basically means: the "gateway" name is safe >> exactly when you turn off the search domain logic (or to put this >> correctly if networkd is used: it is safe unless you *turn on* the >> search domain logic). >> >>> Right. If software (or documentation) uses “gateway” to mean “address >>> of the default gateway”, it will break, depending on search path >>> configuration and other network properties. >>> >>> I don't think this is what Fedora wants (and what you intended). >> >> I disagree. It only breaks if the user enables domain search logic, >> and configures a domain in there that actually serves a host called >> "gateway". > > Which from my time, a good 10 years or so, at a large global service > provider and as a Red Hat consultant on customer sites both of those > were often true so I'm not sure it's something that you can assume > either way. And given on those networks there's generally LOT of > legacy platforms that make assumptions about that sort of thing I'm > not sure it's something you can just turn around and say "well just > turn it off you idiots". >
I think that the "gateway" override should not be conflated with always letting the gethostname(2) return value resolve. I also think that the whole gethostname(2) mechanism is terminally screwed up. We abuse the hostname for multiple purposes: 1. It shows up in the default bash prompt. 2. It gets sent to remote DHCP servers. I think this is a mistake on desktop machines. 3. Some programs seem to thing that gethostbyname(gethostname()) should return some reasonable concept of "my ip address" despite the general nonexistence of such a concept. I'll propose a strawman: - gethostname(2) always returns "localhost". - "localhost" always resolves to 127.0.0.1 or ::1 - bash learns to use some intelligent value derived from whatever hostnamectl would return - the default DHCP clients send a client identifier that's a function only of the MAC address used to send the query - Whatever systemd magic special-cases "localhost" as "trust what DHCP says" goes away. and that's it. This trivially solves one silly annoyance: when I install Fedora, why on Earth is "what's your hostname" a reasonable question to ask me? Servers may have their own considerations, and NetworkManager and/or networkd could consider having a client-id override. But I think that my strawman proposal should cover almost all desktop usecases and even almost all server usecases. If people really want to force a non-"localhost" hostname on a server, then forcing it to resolve to something intelligent might make sense, as having everything fail when resolution times out or ends up with SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to "foo.corp.bar.com", I probably have something other than 127.0.0.1 in mind. Heck, strawman #2 should cover every use case: - Anaconda defaults the hostname to "localhost". For the workstation product, Anaconda stops asking for a hostname entirely. - "localhost" always resolves to 127.0.0.1 or ::1 - bash learns to use some intelligent value derived from whatever hostnamectl would return if gethostname(2) says "localhost". - If gethostname(2) returns "localhost", then the default DHCP clients send a client identifier that's a function only of the MAC address used to send the query - Whatever systemd magic special-cases "localhost" as "trust what DHCP says" goes away. - (optional) We add something to nsswitch.conf that causes gethostname(2) to resolve to 127.0.0.1 or ::1 if the actual resolution attempt results in a failure. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
