On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote: > On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <pbrobinson@xxxxxxxxx > > 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 When sent to DHCP servers, the hostname is used only for DDNS updates and not for any kind of client identification. That's what the Client Identifier is used for, or missing that, the MAC address (depending on the server). I'm not aware of any DHCP server that uses the DDNS hostname as a lease identifier. It's not a mistake to send a hostname if your DHCP server also handles DDNS updates. It doesn't have to be the name set for the local machine, but almost all of the time its going to be since you want your local queries to return the same result for your machine name as non -local queries would. One problem is that there is no way to determine that the DHCP server has DDNS functionality enabled, and thus to selectively send the hostname. Which is why NetworkManager has ipv4.dhcp-send-hostname and ipv6.dhcp-send-hostname toggles so you can turn it off. Dan > 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@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
