On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > Sorry to reply with such a delay. > > On Mon, Jan 25, 2016 at 07:43:35PM -0800, Andrew Lutomirski wrote: >> 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. > > Like discussed elsewhere in the thread, this is used by DDNS, which is > very useful in closed environments. It is also useful for diagnostics: > if I look on the router what leases were made, it's much nicer to see > the names rather than just the MAC addresses. The hostname is > something that essentially is used to identify a machine for humans, > and not allowing the hostname to be visible defeats the purpose. In my opinion, if I weight the privacy and tracking implications of advertising my laptop's name to every network I connect to against the minor convenience for network admins who like to read the leases file, I think the privacy implication is so much more important that it's silly to even consider the human-readable leases file at all. > > Not sending the hostname in DHCP requests on non-trusted networks was > discussed in the other part of the thread. It's a great idea, but not > really relevant to this discussion, since DHCP libraries already make > this configurable (e.g. SendHostname=, Hostname= settings described in > systemd.network(5)). The issue is knowing when to set it on and when > to off, but this is needs to be solved at a slightly higher level. > >> 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". > So you are proposing to make the current hostname mechanism useless > and add a replacement mechanism. I don't get the point, if this > got implemented we would be in the same place a few years down the > road. If the point is to avoid DHCP sending out the hostname, this can > already be achieved with a simple config change. > The current situation seems to be worse than useless in a lot of cases. I've literally never had it do anything useful except show up in a bash prompt, whereas it's caused services to break for me due to DNS resolution issues on many, many occasions. >> - "localhost" always resolves to 127.0.0.1 or ::1 > That's what nss-myhostname provides. It's part of what nss-myhostname provides. There's clearly no consensus on the "gateway" feature. >> - the default DHCP clients send a client identifier that's a function >> only of the MAC address used to send the query > It's better not to send anything if not desired as discussed above. > DHCP servers don't use this to generate leases, so there's little > point in sending a random value. It's more of a compatibility thought. Do servers in the wild work if the client id is missing entirely or if there are duplicates on the same network? Hopefully they do, but I don't know that. > >> - Whatever systemd magic special-cases "localhost" as "trust what >> DHCP says" goes away. > No, systemd doesn't do that. First, nss-myhostname resolves > localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost' > as the lease name. Something causes bash to show garbage that came from DHCP if I set /etc/hostname to localhost. I don't know what it is. I've seen this on a totally stock Fedora 23 system. > > Systemd will use the DHCP provided "transient" name, but only if the > "static" name (from /etc/hostname is not set). The "transient" name > is a fallback value only. This is probably what I meant above. It caused a good deal of confusion and it didn't improve anything for me. What's the point? > >> This trivially solves one silly annoyance: when I install Fedora, why >> on Earth is "what's your hostname" a reasonable question to ask me? > Because all installations of Fedora are similar and a 16 byte UUID > is not something that most humans can remember. OK, but this doesn't answer the question at all. Pretend I'm a regular computer user. Why am I supposed to name my computer? What's in it for me? > >> Servers may have their own considerations, and NetworkManager and/or >> networkd could consider having a client-id override. > (They do.) > >> 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. > > This is something to be discussed, certainly. We already ask for a > user name, so it might be nice to simply to default to a hostname > generated from that, and the automatically detected chassis type (user > 'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname > "mikeys-laptop"). This field should still be editable, but a sensible > default would work nicely. IIRC, this is what Windows does more or > less, and it is pretty intuitive. At least for Workstation. > > Anaconda could say "This computer will be visible as "Mikey's Laptop" > in the local network." to make people aware that the name is visible. Then Anaconda could offer a checkbox "don't do that" because if I'm a normal person on a laptop, why the @*!& would I want my laptop to advertise my pet name for it to the world? --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
