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.
On Thu, 2016-01-21 at 15:18 -0700, Orion Poplawski wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=1284323%C2%A0as 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.
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
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:
https://github.com/systemd/systemd/issues/2026
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
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:
https://github.com/systemd/systemd/issues/2026
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
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:
https://github.com/systemd/systemd/issues/2026
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
On Mon, 25.01.16 09:08, Florian Weimer (fweimer@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
On 01/25/2016 03:23 PM, Lennart Poettering wrote:
On Mon, 25.01.16 09:08, Florian Weimer (fweimer@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
On Mon, 25.01.16 17:11, Florian Weimer (fweimer@redhat.com) wrote:
On 01/25/2016 03:23 PM, Lennart Poettering wrote:
On Mon, 25.01.16 09:08, Florian Weimer (fweimer@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
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
On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson pbrobinson@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
On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <pbrobinson@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:
- It shows up in the default bash prompt.
- 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
- 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. org
On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams dcbw@redhat.com wrote:
On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <pbrobinson@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:
- It shows up in the default bash prompt.
- 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.
I think this depends a bit on the use case.
On a public network, I think that NetworkManager and related tools should send the bare minimum of identifying information. I think that means that a MAC address should be sent and as little as possible that isn't a MAC address. If I name my computer "fluffybunnies" or "mysocialsecuritynumber", I do *not* want to advertise that, and if something else on the network is trying to resolve fluffybunnies using DDNS, then something is already very wrong.
On a private network that uses pre-assigned MAC-to-IP+name or port-to-IP+name mappings on the DHCP server, DDNS is irrelevant.
That leaves only private networks that actually use DDNS in some useful manner with a user clueful enough to set up a meaningful name.
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<digits>" instead of "localhost".Would it make sense to teach NetworkManager to skip sending the client ID (or send some compatibility value) instead of "localhost"?
If public vs private networks ever get implemented in a meaningful manner, the same behavior could be flipped on for public networks.
--Andy
On Tue, 2016-01-26 at 09:47 -0800, Andrew Lutomirski wrote:
On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams dcbw@redhat.com wrote:
On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson < pbrobinson@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:
- It shows up in the default bash prompt.
- 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.
I think this depends a bit on the use case.
On a public network, I think that NetworkManager and related tools should send the bare minimum of identifying information. I think that means that a MAC address should be sent and as little as possible that isn't a MAC address. If I name my computer "fluffybunnies" or "mysocialsecuritynumber", I do *not* want to advertise that, and if something else on the network is trying to resolve fluffybunnies using DDNS, then something is already very wrong.
On a private network that uses pre-assigned MAC-to-IP+name or port-to-IP+name mappings on the DHCP server, DDNS is irrelevant.
That leaves only private networks that actually use DDNS in some useful manner with a user clueful enough to set up a meaningful name.
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<digits>" instead of "localhost".Would it make sense to teach NetworkManager to skip sending the client ID (or send some compatibility value) instead of "localhost"?
If public vs private networks ever get implemented in a meaningful manner, the same behavior could be flipped on for public networks.
Agreed. The issue is more around UI; no interaction gurus that I know think the Windows "PICK A ZONE FOOL!!!" is the right thing to do. We do have the firewall zone thing in NetworkManager, but that's not quite the same thing as public/private networks, thought they are closely related. It's all possible to set right now by:
nmcli con mod <name> ipv4.dhcp-send-hostname false nmcli con mod <name> ipv4.dhcp-client-id "sillyclientid" nmcli con mod <name> 802-11-wireless.mac-address-randomization 2
and maybe a couple other toggles. But it's more about the interaction design than any underlying deficiencies in the software.
Dan
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<digits>" 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.
On Tue, Jan 26, 2016 at 12:48 PM, Samuel Sieb samuel@sieb.net 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<digits>" 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
On Tue, 2016-01-26 at 13:32 -0800, Andrew Lutomirski wrote:
On Tue, Jan 26, 2016 at 12:48 PM, Samuel Sieb samuel@sieb.net 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<digits>" 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
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:
- It shows up in the default bash prompt.
- 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.
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
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.
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:
It shows up in the default bash prompt.
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.
- 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
On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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:
It shows up in the default bash prompt.
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.
- Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the general nonexistence of such a concept.
I'll propose a strawman:
- gethostname(2) always returns "localhost".
So you are proposing to make the current hostname mechanism useless and add a replacement mechanism. I don't get the point, if this got implemented we would be in the same place a few years down the road. If the point is to avoid DHCP sending out the hostname, this can already be achieved with a simple config change.
The current situation seems to be worse than useless in a lot of cases. I've literally never had it do anything useful except show up in a bash prompt, whereas it's caused services to break for me due to DNS resolution issues on many, many occasions.
- "localhost" always resolves to 127.0.0.1 or ::1
That's what nss-myhostname provides.
It's part of what nss-myhostname provides. There's clearly no consensus on the "gateway" feature.
- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query
It's better not to send anything if not desired as discussed above. DHCP servers don't use this to generate leases, so there's little point in sending a random value.
It's more of a compatibility thought. Do servers in the wild work if the client id is missing entirely or if there are duplicates on the same network? Hopefully they do, but I don't know that.
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
No, systemd doesn't do that. First, nss-myhostname resolves localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost' as the lease name.
Something causes bash to show garbage that came from DHCP if I set /etc/hostname to localhost. I don't know what it is. I've seen this on a totally stock Fedora 23 system.
Systemd will use the DHCP provided "transient" name, but only if the "static" name (from /etc/hostname is not set). The "transient" name is a fallback value only.
This is probably what I meant above. It caused a good deal of confusion and it didn't improve anything for me. What's the point?
This trivially solves one silly annoyance: when I install Fedora, why on Earth is "what's your hostname" a reasonable question to ask me?
Because all installations of Fedora are similar and a 16 byte UUID is not something that most humans can remember.
OK, but this doesn't answer the question at all. Pretend I'm a regular computer user. Why am I supposed to name my computer? What's in it for me?
Servers may have their own considerations, and NetworkManager and/or networkd could consider having a client-id override.
(They do.)
If people really want to force a non-"localhost" hostname on a server, then forcing it to resolve to something intelligent might make sense, as having everything fail when resolution times out or ends up with SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to "foo.corp.bar.com", I probably have something other than 127.0.0.1 in mind.
This is something to be discussed, certainly. We already ask for a user name, so it might be nice to simply to default to a hostname generated from that, and the automatically detected chassis type (user 'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname "mikeys-laptop"). This field should still be editable, but a sensible default would work nicely. IIRC, this is what Windows does more or less, and it is pretty intuitive. At least for Workstation.
Anaconda could say "This computer will be visible as "Mikey's Laptop" in the local network." to make people aware that the name is visible.
Then Anaconda could offer a checkbox "don't do that" because if I'm a normal person on a laptop, why the @*!& would I want my laptop to advertise my pet name for it to the world?
--Andy
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 zbyszek@in.waw.pl 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:
It shows up in the default bash prompt.
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.
- 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 networkd could consider having a client-id override.
(They do.)
If people really want to force a non-"localhost" hostname on a server, then forcing it to resolve to something intelligent might make sense, as having everything fail when resolution times out or ends up with SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to "foo.corp.bar.com", I probably have something other than 127.0.0.1 in mind.
This is something to be discussed, certainly. We already ask for a user name, so it might be nice to simply to default to a hostname generated from that, and the automatically detected chassis type (user 'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname "mikeys-laptop"). This field should still be editable, but a sensible default would work nicely. IIRC, this is what Windows does more or less, and it is pretty intuitive. At least for Workstation.
Anaconda could say "This computer will be visible as "Mikey's Laptop" in the local network." to make people aware that the name is visible.
Then Anaconda could offer a checkbox "don't do that" because if I'm a normal person on a laptop, why the @*!& would I want my laptop to advertise my pet name for it to the world?
Well, if you want to call your machine something personal, that's your choice. Something less private like "new laptop", "dell", "thinkpad", "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.
Zbyszek
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
On 25.1.2016 17:39, Lennart Poettering wrote:
On Mon, 25.01.16 17:11, Florian Weimer (fweimer@redhat.com) wrote:
On 01/25/2016 03:23 PM, Lennart Poettering wrote:
On Mon, 25.01.16 09:08, Florian Weimer (fweimer@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/applicatio...
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
On Tue, 26.01.16 08:58, Petr Spacek (pspacek@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-st...
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
On 01/26/2016 12:45 PM, Lennart Poettering wrote:
On Tue, 26.01.16 08:58, Petr Spacek (pspacek@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
On Fri, 22.01.16 19:06, Florian Weimer (fweimer@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:
https://github.com/systemd/systemd/issues/2026
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/AAAA 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/AAAA 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-... https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-st...
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
-----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:
https://github.com/systemd/systemd/issues/2026
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.
-
Andrew Lutomirski -
Dan Williams -
Florian Weimer -
Glen Turner -
Jan Pokorný -
Lennart Poettering -
Michael Catanzaro -
Orion Poplawski -
Peter Robinson -
Petr Spacek -
Samuel Sieb -
Stephen Gallagher -
Zbigniew Jędrzejewski-Szmek