Re: nss_myhostname as default in Fedora

[Glen Turner]

> It's part of what nss-myhostname provides.  There's clearly no
> consensus on the "gateway" feature.

The belief of operating systems' programmers that a lack of a default 
gateway must imply no network connectivity constricts useful network 
designs.

My objection to the "gateway" name is simply that "ping gateway" gives 
applications another way to test this incorrect belief.

-glen
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Andrew Lutomirski]

On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
 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 

Re: nss_myhostname as default in Fedora

[Zbigniew Jędrzejewski-Szmek]

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
>  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.

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 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.

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" 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?

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 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
> >> 

Re: nss_myhostname as default in Fedora

[Petr Spacek]

On 3.2.2016 16:34, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> On Wed, Jan 27, 2016 at 11:57:37PM +0100, Jan Pokorný wrote:
>> attempt on settle this one down: http://tools.ietf.org/html/rfc6761
> 
> rfc6761 is a useful reference, but it doesn't really solve this
> discussion one way or another.
> It's concerned with names to be "carved off a sub-tree of the DNS
> namespace in which the modified name treatment rules apply", but
> single label names are already special anyway.

Well, all special names are specified in RFC 6761 and associated registry.

What RFC says that single-label names are 'special'?
In what sense 'special'?
How do you differentiate arbitrary 'single-label' from TLD in DNS?

Answers to these questions need backing from standards because all parties
doing name resolution need to do it consistently.

Petr Spacek  @  Red Hat

>> (also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)
> This is one of the problems that myhostname solves.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Zbigniew Jędrzejewski-Szmek]

Hi,

On Wed, Jan 27, 2016 at 11:57:37PM +0100, Jan Pokorný wrote:
> attempt on settle this one down: http://tools.ietf.org/html/rfc6761

rfc6761 is a useful reference, but it doesn't really solve this
discussion one way or another.
It's concerned with names to be "carved off a sub-tree of the DNS
namespace in which the modified name treatment rules apply", but
single label names are already special anyway.

> (also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)
This is one of the problems that myhostname solves.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[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.

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.

>  - "localhost" always resolves to 127.0.0.1 or ::1
That's what nss-myhostname provides.

>  - bash learns to use some intelligent value derived from whatever
> hostnamectl would return
I think bash is fine now: is shows gethostname(), which defaults
to contents of /etc/hostname.

>  - 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.

>  - 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.

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 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.

> 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.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Jan Pokorný]

On 25/01/16 19:43 -0800, Andrew Lutomirski wrote:
> 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

attempt on settle this one down: http://tools.ietf.org/html/rfc6761
(also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)

>  - 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.

-- 
Jan (Poki)


pgpNrBMeOIERp.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/26/2016 08:58 AM, Petr Spacek wrote:
> So, please, do not push "gateway." or any other single-label name forward. It
> will cause trouble sooner or later.

I think “_gateway” or “gateway_” would work, despite being a single
label.  We could give this one priority over DNS, even.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Tue, 26.01.16 08:58, Petr Spacek (pspa...@redhat.com) wrote:

> I disagree with your disagreement. We have only 1 shared namespace for this
> world, and like it or not, the root zone (and thus all single-label names in
> it) is managed by ICANN.

Well, did you actually read the earlier discussions in this thread?

Again: it is well-known that single-label (aka "dotless domains") are
supposed to be interpreted in a local context, using domain search
paths, LLMNR and other local configuration. This is widely documented
by various Internet bodies, for example here:

https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

We only synthesize an address for the single-label name "gateway", not
for the whole domain, or stuff below it. We do not synthesize anything
for names with multiple dots, thus we are not in conflict with
documented Internet specifications, we simply locally define one of
those single-label names, fully in line with what the specs suggest.

> Fritzbox already did the mistake and used "box." as fake TLD for their
> "gateways", and this is going to cause trouble because Amazon bought
> box. TLD [1].

Firstly, it's a very different case, because the fritzbox does not
touch any single-label name! The zone they fake (and where the first
address RRs are located) is actually "fritz.box", and not "box". In
fact, they fake exactly nothing, not even a SOA RR for "box". 

(The fact that they did it this way actually buys them a
get-out-of-jail-free-card for the DNSSEC situation: as long as they
buy the fritz.box domain as soon as .box is delegated one day, they
can simply leave it unsigned, and then their routers can continue to
do what they want with it... But that's very much unrelated to the
discussion around single-label names here.)

(Also, as a matter of fact, not that it would matter much: you'll see
that the Amazon application has been withdrawn, just scroll down on
that page.)

> "gateway." (as any other single-label name) can face the same faith one day,
> when somebody decides to spend $$$ and buy it. Training anyone to rely on
> "gateway" or any other single-label name is a bad idea.

Nope. because IAB and ICANN and others made clear that single-label
domains are supposed to be resolved in local context, and gateway
hence is local.

> agateway.local." is okay, because RFC 6762 reserved "local." for
> this purpose.

Nope! .local is the TLD for MulticastDNS, nothing else.

AFAICS not a single claim in your mail is correct...

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/26/2016 12:45 PM, Lennart Poettering wrote:
> On Tue, 26.01.16 08:58, Petr Spacek (pspa...@redhat.com) wrote:
> 
>> I disagree with your disagreement. We have only 1 shared namespace for this
>> world, and like it or not, the root zone (and thus all single-label names in
>> it) is managed by ICANN.
> 
> Well, did you actually read the earlier discussions in this thread?
> 
> Again: it is well-known that single-label (aka "dotless domains") are
> supposed to be interpreted in a local context, using domain search
> paths, LLMNR and other local configuration.

This is irrelevant for the concerns Petr and others have voiced.

You cannot use priorities to resolve namespace collisions.  The
collision still exists with the low-priority synthesized “gateway” name
we have today.  The name is not a stable reference to the address of the
default gateway because of its low priority.  This makes it unreliable,
difficult to use, and unsuitable for documentation and other user
guidance.  Changing it to something that does not collide with names in
the DNS namespace (such as “_gateway”) would change that because we
could give it higher priority and make sure that it is a stable name for
the gateway addresses.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
> On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson  > 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.

Dan

> 3. Some programs seem to thing that gethostbyname(gethostname())
> should return 

Re: nss_myhostname as default in Fedora

[Andrew Lutomirski]

On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams  wrote:
> On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
>> On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson > > 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 

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Tue, 2016-01-26 at 09:47 -0800, Andrew Lutomirski wrote:
> On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams 
> 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
> > 

Re: nss_myhostname as default in Fedora

[Samuel Sieb]

On 01/26/2016 09:47 AM, Andrew Lutomirski wrote:

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" instead of "localhost".Would it make
sense to teach NetworkManager to skip sending the client ID (or send
some compatibility value) instead of "localhost"?

It's not mandatory for installation. If your IP address resolves, it 
uses whatever hostname is returned.  If not, it stays at localhost.  You 
can manually modify that of course, but you aren't required to.  This 
works perfectly for me deploying computers with freeipa.  I set up the 
DHCP server, the installer picks up the right name and freeipa 
configures correctly.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Andrew Lutomirski]

On Tue, Jan 26, 2016 at 12:48 PM, Samuel Sieb  wrote:
> On 01/26/2016 09:47 AM, Andrew Lutomirski wrote:
>>
>> 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" instead of "localhost".Would it make
>> sense to teach NetworkManager to skip sending the client ID (or send
>> some compatibility value) instead of "localhost"?
>>
> It's not mandatory for installation. If your IP address resolves, it uses
> whatever hostname is returned.  If not, it stays at localhost.  You can
> manually modify that of course, but you aren't required to.  This works
> perfectly for me deploying computers with freeipa.  I set up the DHCP
> server, the installer picks up the right name and freeipa configures
> correctly.

This is rather awkward for laptops in particular.  It gets a bit
confusing when my laptop's idea of what it's called varies depending
on where I am.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Tue, 2016-01-26 at 13:32 -0800, Andrew Lutomirski wrote:
> On Tue, Jan 26, 2016 at 12:48 PM, Samuel Sieb 
> wrote:
> > On 01/26/2016 09:47 AM, Andrew Lutomirski wrote:
> > > 
> > > 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" instead of "localhost".Would it
> > > make
> > > sense to teach NetworkManager to skip sending the client ID (or
> > > send
> > > some compatibility value) instead of "localhost"?
> > > 
> > It's not mandatory for installation. If your IP address resolves,
> > it uses
> > whatever hostname is returned.  If not, it stays at localhost.  You
> > can
> > manually modify that of course, but you aren't required to.  This
> > works
> > perfectly for me deploying computers with freeipa.  I set up the
> > DHCP
> > server, the installer picks up the right name and freeipa
> > configures
> > correctly.
> 
> This is rather awkward for laptops in particular.  It gets a bit
> confusing when my laptop's idea of what it's called varies depending
> on where I am.

The only way to keep a stable, guaranteed hostname is by putting that
into /etc/hostname, regardless of whether it's localhost or something
else.  So in the workstation case, just leaving it as localhost is
fine.

FWIW, NetworkManager will never send "localhost"-type hostnames to the
DHCP server for DDNS, even if you set dhcp-send-hostname=true.

Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Andrew Lutomirski]

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

Re: nss_myhostname as default in Fedora

[Petr Spacek]

On 25.1.2016 17:39, Lennart Poettering wrote:
> On Mon, 25.01.16 17:11, Florian Weimer (fwei...@redhat.com) wrote:
> 
>> On 01/25/2016 03:23 PM, Lennart Poettering wrote:
>>> On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.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".

I disagree with your disagreement. We have only 1 shared namespace for this
world, and like it or not, the root zone (and thus all single-label names in
it) is managed by ICANN.

Fritzbox already did the mistake and used "box." as fake TLD for their
"gateways", and this is going to cause trouble because Amazon bought box. TLD 
[1].

"gateway." (as any other single-label name) can face the same faith one day,
when somebody decides to spend $$$ and buy it. Training anyone to rely on
"gateway" or any other single-label name is a bad idea.

"gateway.local." is okay, because RFC 6762 reserved "local." for this purpose.

However, I agree with you that 'search' mechanism is broken by design. Still,
disabling the search mechanism does not make use of single-label names safe or
even reliable.

So, please, do not push "gateway." or any other single-label name forward. It
will cause trouble sooner or later.

[1]
https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/990

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Fri, 22.01.16 19:06, Florian Weimer (fwei...@redhat.com) wrote:

> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
> 
> > PS - There is some other discussion around "mymachines" which seems much 
> > more
> > problematic.  I'd like to just focus on myhostname for now.  The glibc
> > maintainer has indicated that he wants to wait for mymachines to be 
> > resolved,
> > but it's almost two months now and I don't see that being resolved soon.
> 
> I still have philosophical objects to myhostname as well.  I find it odd
> that at one end, we struggle with DNS name space hijacking, but on
> another end, we do basically the same thing:
> 
>   
> 
> The order in nsswitch.conf does not matter (and neither does any non-DNS
> name resolution mechanism) because if we end up having software which
> expects that “gateway” resolves to the IP address of the default
> gateway, we still have an interoperability problem.  And if “gateway” is
> never intended for name resolution, why synthesize the name at all?

nss-myhostname and systemd-resolved map the "gateway" name to the
addresses of the locally configured default routing gateway. Note that
we only do this for the single-label "gateway". A such it might
conflict with LLMNR names (which are all single-label names) as well
as search domain lists (which are generally applied to single-label
names), but generally not with classic DNS fqdns. This is because
A/ RRs are generally not assigned to TLDs, and while that's not a
strict requirement (and in fact there are some TLDs which have A/
RRs, such as .dk), this is strongly recommended against by many
internet organizational bodies, including ICANN and IAB:

https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-08-13-en
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

They recommend against allowing TLDs with address RRs specifically
because they conflict with local uses of single-label domains, in the
contexts of search lists and systems such as LLMNR.

Now, with that background, which clearly suggests that single-label
names are subject to *local* interpretation, nss-myhostnames resolves
"gateway" locally to the locally configured gateway, and I believe
that's completely within the idea and general accepted logic of
single-label domains. Now, you can argue this might create conflicts
with search domain logic and LLMNR, but well, the basic idea of
LLMNR/search lists is that it is non-organized, that it creates a very
local view of the worrld and subject to first-come-first-serve
conflicts.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/22/2016 01:06 PM, Florian Weimer wrote:
> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
> 
>> PS - There is some other discussion around "mymachines" which seems much
>> more problematic.  I'd like to just focus on myhostname for now.  The
>> glibc maintainer has indicated that he wants to wait for mymachines to be
>> resolved, but it's almost two months now and I don't see that being
>> resolved soon.
> 
> I still have philosophical objects to myhostname as well.  I find it odd 
> that at one end, we struggle with DNS name space hijacking, but on another
> end, we do basically the same thing:
> 
> 
> 
> The order in nsswitch.conf does not matter (and neither does any non-DNS 
> name resolution mechanism) because if we end up having software which 
> expects that “gateway” resolves to the IP address of the default gateway,
> we still have an interoperability problem.  And if “gateway” is never
> intended for name resolution, why synthesize the name at all?


For what it's worth, nss_myhostname is extremely valuable even without
"gateway". Having the the machine's hostname automatically resolving even to
DHCP-assigned addresses solves a lot of issues, including some extremely
common ones related to FreeIPA installation.

So if nothing else, I'd really like to see this feature back to being
installed by default.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlamMT4ACgkQeiVVYja6o6NuYwCgsByDXdtc2Ok1zwtdgSXOTN01
/RsAnRdCAjMDFD6Vch3kN4Bdo/B7IC9z
=BOZh
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.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.

I also know that in my local wlan, as well as in the one of my
girlfriend's or my parent's: I can reconfigure the router by typing
http://gateway/ into my webbrowser, without having to check IP
configuration, leave the web browser, or even know the router's brand
or default configuration.

> As I tried to explain above, I'm not really worried about nss_myhostname
> overriding name resolution, but that software relies on the specific
> functionality of the “gateway” name provided by nss_myhostname, but
> *this* name is overridden by DNS (with a suitable search path) or
> nss_files, so that it no longer resolves to the expected address.

Search lists are local configuration. Software which relies on
specific search paths to be configured will already break pretty much
everywhere...

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Mon, 25.01.16 17:11, Florian Weimer (fwei...@redhat.com) wrote:

> On 01/25/2016 03:23 PM, Lennart Poettering wrote:
> > On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.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".

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/25/2016 03:23 PM, Lennart Poettering wrote:
> On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.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).

Because it's so unreliable, we cannot put this trick into documentation,
and we shouldn't train users to rely on this functionality.

>> As I tried to explain above, I'm not really worried about nss_myhostname
>> overriding name resolution, but that software relies on the specific
>> functionality of the “gateway” name provided by nss_myhostname, but
>> *this* name is overridden by DNS (with a suitable search path) or
>> nss_files, so that it no longer resolves to the expected address.
> 
> Search lists are local configuration. Software which relies on
> specific search paths to be configured will already break pretty much
> everywhere...

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).

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/22/2016 10:45 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jan 22, 2016 at 07:06:26PM +0100, Florian Weimer wrote:
>> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
>>
>>> PS - There is some other discussion around "mymachines" which seems much 
>>> more
>>> problematic.  I'd like to just focus on myhostname for now.  The glibc
>>> maintainer has indicated that he wants to wait for mymachines to be 
>>> resolved,
>>> but it's almost two months now and I don't see that being resolved soon.
>>
>> I still have philosophical objects to myhostname as well.  I find it odd
>> that at one end, we struggle with DNS name space hijacking, but on
>> another end, we do basically the same thing:
>>
>>   
>>
>> The order in nsswitch.conf does not matter (and neither does any non-DNS
>> name resolution mechanism) because if we end up having software which
>> expects that “gateway” resolves to the IP address of the default
>> gateway, we still have an interoperability problem.  And if “gateway” is
>> never intended for name resolution, why synthesize the name at all?
> 
> 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.
As I tried to explain above, I'm not really worried about nss_myhostname
overriding name resolution, but that software relies on the specific
functionality of the “gateway” name provided by nss_myhostname, but
*this* name is overridden by DNS (with a suitable search path) or
nss_files, so that it no longer resolves to the expected address.

From my point of view, the fact that software (or the user) cannot know
that “gateway” resolves to the default gateway makes the name pretty
much useless.

What am I missing?

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Peter Robinson]

>> >>> 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".

Peter
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 22, 2016 at 07:06:26PM +0100, Florian Weimer wrote:
> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
> 
> > PS - There is some other discussion around "mymachines" which seems much 
> > more
> > problematic.  I'd like to just focus on myhostname for now.  The glibc
> > maintainer has indicated that he wants to wait for mymachines to be 
> > resolved,
> > but it's almost two months now and I don't see that being resolved soon.
> 
> I still have philosophical objects to myhostname as well.  I find it odd
> that at one end, we struggle with DNS name space hijacking, but on
> another end, we do basically the same thing:
> 
>   
> 
> The order in nsswitch.conf does not matter (and neither does any non-DNS
> name resolution mechanism) because if we end up having software which
> expects that “gateway” resolves to the IP address of the default
> gateway, we still have an interoperability problem.  And if “gateway” is
> never intended for name resolution, why synthesize the name at all?

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)?

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/21/2016 11:18 PM, Orion Poplawski wrote:

> PS - There is some other discussion around "mymachines" which seems much more
> problematic.  I'd like to just focus on myhostname for now.  The glibc
> maintainer has indicated that he wants to wait for mymachines to be resolved,
> but it's almost two months now and I don't see that being resolved soon.

I still have philosophical objects to myhostname as well.  I find it odd
that at one end, we struggle with DNS name space hijacking, but on
another end, we do basically the same thing:

  

The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default
gateway, we still have an interoperability problem.  And if “gateway” is
never intended for name resolution, why synthesize the name at all?

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

nss_myhostname as default in Fedora

[Orion Poplawski]

See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well

For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of
the hosts line in /etc/nsswitch.conf in %post via sed.  This has been removed
as it is error prone, and the above request filed to add it by default to
/etc/nsswitch.conf in glibc.  The glibc maintainer would like to see
discussion of this on the devel list, hence this email.

My interest in this stems from build issues with mpich using programs.  This
may have been triggered by a combination of the above change as well as
changes in mpich, I'm not sure.  In any case, mpich uses gethostbyname() on
the hostname of the machine it is running on in order to configure itself
properly, and fails if it cannot do this.  So the mpich tests run by netcdf
are currently failing on the builders, and has since Nov 27 when systemd
dropped adding myhostname took place.

So:

- Is the change to nsswitch.conf in glibc (back to behavior that was the
default for quite a while) desired?

- If not, is there some other way we can get the koji builders' mock
configuration to be setup so they can at least resolve their own hostname?

Thanks.

PS - There is some other discussion around "mymachines" which seems much more
problematic.  I'd like to just focus on myhostname for now.  The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Michael Catanzaro]

On Thu, 2016-01-21 at 15:18 -0700, Orion Poplawski wrote:
> See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well
> 
> For a while (from 197-1 until 228-5), systemd added "myhostname" to
> the end of
> the hosts line in /etc/nsswitch.conf in %post via sed.  This has been
> removed
> as it is error prone, and the above request filed to add it by
> default to
> /etc/nsswitch.conf in glibc.  The glibc maintainer would like to see
> discussion of this on the devel list, hence this email.

I don't care how it gets there, but I very much hope it gets there
somehow. mpich is not the only program that will be broken without
nss_myhostname.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Zbigniew Jędrzejewski-Szmek]

Hi,

yes, it's been a while with little progress. Initially I thought
it would be just a packaging issue, but various issues were raised
which require upstream fixes. I let it slip, but I still hope
to get this finished. Thank you for pushing for a resolution.

On Thu, Jan 21, 2016 at 03:18:47PM -0700, Orion Poplawski wrote:
> - Is the change to nsswitch.conf in glibc (back to behavior that was the
> default for quite a while) desired?

I think there is general agreement that it is desirable, but got
stalled on technical issue and tied up with nss_mymachines. The
technical issue was that nss_myhostname.so was overlinked. My pull
request was merged upstream yesterday, but unfortunately it doesn't
solve the issue completely.  I was told that Debian patches the build
process to fix the issue, but I haven't looked into it. Maybe glibc
maintainers would be OK with adding nss_myhostname now (after systemd
is rebuilt with the patch), without waiting for nss_mymachines.

> - If not, is there some other way we can get the koji builders' mock
> configuration to be setup so they can at least resolve their own hostname?
> 
> Thanks.
> 
> PS - There is some other discussion around "mymachines" which seems much more
> problematic.  I'd like to just focus on myhostname for now.  The glibc
> maintainer has indicated that he wants to wait for mymachines to be resolved,
> but it's almost two months now and I don't see that being resolved soon.
Yeah, mymachines is much more specific and problematic. It shouldn't
hold up myhostname.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org