Re: nss_myhostname as default in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux