On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <pbrobinson(a)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.
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