[arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
Hi Arch enthuasiasts, With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example: $ hostname PC12574 $ ping PC12574 ping: PC12574: Name or service not known Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine: $ ping PC12574 PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 ttl=64 time=0.078 ms Is it a bug? Or such a usage is just a non-standard coincidence? Thanks for any help. Yen Chi Hsuan [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a
On Tue, Nov 8, 2016 at 8:37 PM, Chi-Hsuan Yen <yan12125@gmail.com> wrote:
Hi Arch enthuasiasts,
With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example:
$ hostname PC12574
$ ping PC12574 ping: PC12574: Name or service not known
Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine:
$ ping PC12574 PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 ttl=64 time=0.078 ms
Is it a bug? Or such a usage is just a non-standard coincidence?
Thanks for any help.
Yen Chi Hsuan
[1] https://git.archlinux.org/svntogit/packages.git/commit/ trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a
Sorry, the title should be: "Can no longer resolve local hostname with the new nsswitch.conf"
On Tue, Nov 8, 2016 at 1:37 PM Chi-Hsuan Yen via arch-general < arch-general@archlinux.org> wrote:
Hi Arch enthuasiasts,
With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example:
$ hostname PC12574
$ ping PC12574 ping: PC12574: Name or service not known
Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine:
$ ping PC12574 PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 ttl=64 time=0.078 ms
Is it a bug? Or such a usage is just a non-standard coincidence?
Thanks for any help.
Yen Chi Hsuan
[1]
This is an effect of putting "myhostname" at the end of the list. If you don't want your network to be able to override lookup for your hostname move "myhostname" to after "files". It seems this only happens when you're part of a domain. AFAICT resolve/dns won't ask upstream for unqualified names.
On Tue, Nov 8, 2016 at 9:11 PM, Jan Alexander Steffens via arch-general < arch-general@archlinux.org> wrote:
On Tue, Nov 8, 2016 at 1:37 PM Chi-Hsuan Yen via arch-general < arch-general@archlinux.org> wrote:
Hi Arch enthuasiasts,
With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example:
$ hostname PC12574
$ ping PC12574 ping: PC12574: Name or service not known
Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine:
$ ping PC12574 PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 ttl=64 time=0.078 ms
Is it a bug? Or such a usage is just a non-standard coincidence?
Thanks for any help.
Yen Chi Hsuan
[1]
https://git.archlinux.org/svntogit/packages.git/commit/ trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a
This is an effect of putting "myhostname" at the end of the list. If you don't want your network to be able to override lookup for your hostname move "myhostname" to after "files".
Thanks for the solution! Maybe it should be the default? I see https://bugs.archlinux.org/task/51709 changed nsswitch.conf to the current settings.
It seems this only happens when you're part of a domain. AFAICT resolve/dns won't ask upstream for unqualified names.
How to check whether I'm in a domain or not? Here's my /etc/resolv.conf: $ cat /etc/resolv.conf # Generated by resolvconf nameserver 8.8.8.8 And another seemingly related command: $ hostname --domain (none) Best, Yen Chi Hsuan
On 8 November 2016 at 13:37, Chi-Hsuan Yen via arch-general <arch-general@archlinux.org> wrote:
Hi Arch enthuasiasts,
With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example:
$ hostname PC12574
$ ping PC12574 ping: PC12574: Name or service not known
Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine:
do you have systemd-resolved running? what does `getent -s resolve hosts <you hostname>` return? -- damjan
On Tue, Nov 8, 2016 at 10:02 PM, Damjan Georgievski via arch-general < arch-general@archlinux.org> wrote:
On 8 November 2016 at 13:37, Chi-Hsuan Yen via arch-general <arch-general@archlinux.org> wrote:
Hi Arch enthuasiasts,
With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example:
$ hostname PC12574
$ ping PC12574 ping: PC12574: Name or service not known
Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine:
do you have systemd-resolved running? what does `getent -s resolve hosts <you hostname>` return?
-- damjan
Here it is: $ getent -s resolve hosts $(hostname) [2] $ systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-resolved.service(8) http://www.freedesktop.org/wiki/Software/systemd/resolved http://www.freedesktop.org/wiki/Software/systemd/writing-network-configurati... http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients The getent command prints nothing and exits with 2. And from strace, it asks Google DNS, which is set in my /etc/resolv.conf: $ strace -f getent -s resolve hosts "$(hostname)" |& grep recvfrom recvfrom(6, "^\236\201\203\0\1\0\0\0\1\0\0\17PC12574\0\0\34\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, [28->16]) = 108 recvfrom(6, "\314d\201\203\0\1\0\0\0\1\0\0\17PC12574\0\0\1\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, [28->16]) = 108 Is it normal? Best, Yen Chi Hsuan
$ getent -s resolve hosts $(hostname)
this should fail since you don't have the resolved service running. but, when using `hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname` standard resolving should then go to the dns source, and then to the myhostname source. what does getent -s dns hosts $(hostname) getent -s myhostname hosts $(hostname) return ? also are you up-to-date with systemd 232? -- damjan
On Tue, 8 Nov 2016 18:01:32 +0100 Damjan Georgievski via arch-general <arch-general@archlinux.org> wrote:
$ getent -s resolve hosts $(hostname)
this should fail since you don't have the resolved service running.
nss-resolve will chainload nss-dns when systemd-resolved is not running (see `man 8 nss-resolve`).
but, when using `hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname` standard resolving should then go to the dns source, and then to the myhostname source.
The `resolve [!UNAVAIL=return]` entry in the new default nsswitch.conf causes NSS to /only/ continue down the list if the nss-resolve module is /not available/; i.e., in a standard Arch setup nss-resolve will always be queried, and pass the query on to systemd-resolved if it is running, or fall back to nss-dns if it is not. Nothing after the conditional will be queried — that is, in this configuration myhostname will /always/ be skipped unless nss-resolve fails to load. See `man 5 nsswitch.conf` for details on how the conditional works. There is actually a sensible reason for this: if both `resolve` and `dns` are in there without the conditional, querying a non-existent DNS record will cause the query to go out twice: once for nss-resolve and once for nss-dns, because a NOTFOUND result automatically falls back to the next item in the chain (that is, from nss-resolve to nss-dns). Sensible solution: change the hosts line as follows. hosts: files myhostname mymachines resolve [!UNAVAIL=return] dns Or if you you use Zeroconf (Avahi)... hosts: files myhostname mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns ~Celti
On 8 November 2016 at 18:43, Patrick Burroughs (Celti) via arch-general <arch-general@archlinux.org> wrote:
On Tue, 8 Nov 2016 18:01:32 +0100 Damjan Georgievski via arch-general <arch-general@archlinux.org> wrote:
$ getent -s resolve hosts $(hostname)
this should fail since you don't have the resolved service running.
nss-resolve will chainload nss-dns when systemd-resolved is not running (see `man 8 nss-resolve`).
ah right, that fallback should be removed *in the future* and I was under the impression it already happened https://github.com/systemd/systemd/commit/344874fcd0a3fc1f9bc6cdf34ecaf537c1... -- damjan
On Wed, Nov 9, 2016 at 1:53 AM, Damjan Georgievski via arch-general < arch-general@archlinux.org> wrote:
On 8 November 2016 at 18:43, Patrick Burroughs (Celti) via arch-general <arch-general@archlinux.org> wrote:
On Tue, 8 Nov 2016 18:01:32 +0100 Damjan Georgievski via arch-general <arch-general@archlinux.org> wrote:
$ getent -s resolve hosts $(hostname)
this should fail since you don't have the resolved service running.
nss-resolve will chainload nss-dns when systemd-resolved is not running (see `man 8 nss-resolve`).
ah right, that fallback should be removed *in the future* and I was under the impression it already happened
https://github.com/systemd/systemd/commit/344874fcd0a3fc1f9bc6cdf34ecaf5 37c10a3ad3
-- damjan
getent -s dns hosts $(hostname) also returns 2 getent -s myhostname hosts $(hostname) gives reasonable results: fe80::ae22:bff:fe77:e20b NEWSLAB-PC12574 fe80::800:27ff:fe00:0 NEWSLAB-PC12574 The package testing/systemd is the latest r232. My machine has been online for half a month. Should I reboot to use the latest systemd? By the way, from your commit, seems r232 has fixed it? Many thanks, Yen Chi Hsuan
participants (4)
-
Chi-Hsuan Yen
-
Damjan Georgievski
-
Jan Alexander Steffens
-
Patrick Burroughs (Celti)