On Thu, Feb 04, 2016 at 01:11:48PM -0800, Andrew Lutomirski wrote:
On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
> 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.
It's not just network admins. The primary use case is users connecting
to a different machine in the local network.
> Not sending the hostname in DHCP requests on non-trusted
> 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.
Sounds like a bug. Can you provide some details?
>> - 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.
Yeah, they seem to work fine.
>> - 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.
Yes, if the hostname is localhost, the transient hostname from DHCP is
used. I think I now understand what you meant in the previous mail.
Just set the hostname to anything except localhost.
> Systemd will use the DHCP provided "transient" name,
but only if the
> "static" name (from /etc/hostname is not set). The "transient"
> 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?
To make it easy to have machines configured over DHCP that have no local
state (e.g. public terminals at unirsity booted over the network).
>> This trivially solves one silly annoyance: when I install
>> on Earth is "what's your hostname" a reasonable question to ask
> 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
>> networkd could consider having a client-id override.
> (They do.)
>> If people really want to force a non-"localhost" hostname on a
>> 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
> 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
> 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?
Well, if you want to call your machine something personal, that's your
choice. Something less private like "new laptop", "dell",
"desktop" or even "machine12" work just as well. The idea is that
if you are on SOHO network, it is easy to identify your machines.