On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams <d...@redhat.com> wrote: > On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote: >> 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 > > 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. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
