On Tue, 2016-01-26 at 09:47 -0800, Andrew Lutomirski wrote: > On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams <dcbw@xxxxxxxxxx> > wrote: > > 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. > > I think this depends a bit on the use case. > > On a public network, I think that NetworkManager and related tools > should send the bare minimum of identifying information. I think > that > means that a MAC address should be sent and as little as possible > that > isn't a MAC address. If I name my computer "fluffybunnies" or > "mysocialsecuritynumber", I do *not* want to advertise that, and if > something else on the network is trying to resolve fluffybunnies > using > DDNS, then something is already very wrong. > > On a private network that uses pre-assigned MAC-to-IP+name or > port-to-IP+name mappings on the DHCP server, DDNS is irrelevant. > > That leaves only private networks that actually use DDNS in some > useful manner with a user clueful enough to set up a meaningful name. > > I still think that, for the default workstation use case, configuring > a hostname as a mandatory part of installation is counterproductive. > Would it make sense to improve support for hostname-less > workstations? > NetworkManager could take hostname=="localhost" or > "localhost.localdomain" to mean that DDNS should be turned off and > the > client ID should be "MAC<digits>" instead of "localhost".Would it > make > sense to teach NetworkManager to skip sending the client ID (or send > some compatibility value) instead of "localhost"? > > If public vs private networks ever get implemented in a meaningful > manner, the same behavior could be flipped on for public networks. Agreed. The issue is more around UI; no interaction gurus that I know think the Windows "PICK A ZONE FOOL!!!" is the right thing to do. We do have the firewall zone thing in NetworkManager, but that's not quite the same thing as public/private networks, thought they are closely related. It's all possible to set right now by: nmcli con mod <name> ipv4.dhcp-send-hostname false nmcli con mod <name> ipv4.dhcp-client-id "sillyclientid" nmcli con mod <name> 802-11-wireless.mac-address-randomization 2 and maybe a couple other toggles. But it's more about the interaction design than any underlying deficiencies in the software. Dan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
