[opensuse-factory] yast nfs client - defaults to ipv4 instead of ipv6 ?
On a test system with leap15 - Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again. Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address. -- Per Jessen, Zürich (7.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 13, Per Jessen wrote:
On a test system with leap15 -
Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again.
Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address.
What is correct? I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match. And if it is dual-stack, it shouldn't matter what is used. For RPC: the config file is /etc/netconfig. And there, IPv4 is before IPv6. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2018-03-13 10:01, Thorsten Kukuk wrote:
On Tue, Mar 13, Per Jessen wrote:
On a test system with leap15 -
Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again.
Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address.
What is correct? I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match.
They call getaddrinfo({without AI_PASSIVE}) and evaluate the first entry's address family. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 13, Jan Engelhardt wrote:
On Tuesday 2018-03-13 10:01, Thorsten Kukuk wrote:
On Tue, Mar 13, Per Jessen wrote:
On a test system with leap15 -
Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again.
Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address.
What is correct? I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match.
They call getaddrinfo({without AI_PASSIVE}) and evaluate the first entry's address family.
??? The first entry is decided by a complicated algorithm, maybe with this special tools not by the tools itself, but latest by glibc. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, 13 March 2018 10:19 Thorsten Kukuk wrote:
On Tue, Mar 13, Jan Engelhardt wrote:
On Tuesday 2018-03-13 10:01, Thorsten Kukuk wrote:
What is correct? I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match.
They call getaddrinfo({without AI_PASSIVE}) and evaluate the first entry's address family.
???
The first entry is decided by a complicated algorithm, maybe with this special tools not by the tools itself, but latest by glibc.
That complicated algorithm is implemented in getaddrinfo() in glibc, application is supposed to use the order determined by getaddrinfo() unless it is configured to use only AF_INET or only AF_INET6 which it should tell getaddrinfo() via hints. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mär 13 2018, Jan Engelhardt <jengelh@inai.de> wrote:
They call getaddrinfo({without AI_PASSIVE}) and evaluate the first entry's address family.
Only using the first entry is wrong. All entries should be tried in that order. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
On Tue, Mar 13, Per Jessen wrote:
On a test system with leap15 -
Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again.
Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address.
What is correct?
To give preference to IPv6 as per /etc/gai.conf, I would have thought.
I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match. And if it is dual-stack, it shouldn't matter what is used.
I thought /etc/gai.conf sets the rules/priorities for what is being used? Anyway, I grep'ed through the YaST sources etc, and the problem appears to be "showmount" which seems to prefer IPv4. -- Per Jessen, Zürich (7.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-13 10:10, Per Jessen wrote:
Anyway, I grep'ed through the YaST sources etc, and the problem appears to be "showmount" which seems to prefer IPv4.
I tried, and... surprise: Telcontar:~ # showmount Hosts on Telcontar: *.valinor 127.0.0.1 192.168.1.12 <=== 192.168.1.129 192.168.1.14 Telcontar:~ # That host has not been booted in years! Where is it getting the information from? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 13 Mar 2018, 14:55:47 +0100, Carlos E. R. wrote:
On 2018-03-13 10:10, Per Jessen wrote:
Anyway, I grep'ed through the YaST sources etc, and the problem appears to be "showmount" which seems to prefer IPv4.
I tried, and... surprise:
Telcontar:~ # showmount Hosts on Telcontar: *.valinor 127.0.0.1 192.168.1.12 <=== 192.168.1.129 192.168.1.14 Telcontar:~ #
That host has not been booted in years! Where is it getting the information from?
/var/lib/nfs/rmtab BUT, according to the man page (rpc.mountd): Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab. HTH, cheers. l8er manfred
On 2018-03-13 15:54, Manfred Hollstein wrote:
On Tue, 13 Mar 2018, 14:55:47 +0100, Carlos E. R. wrote:
On 2018-03-13 10:10, Per Jessen wrote:
Anyway, I grep'ed through the YaST sources etc, and the problem appears to be "showmount" which seems to prefer IPv4.
I tried, and... surprise:
Telcontar:~ # showmount Hosts on Telcontar: *.valinor 127.0.0.1 192.168.1.12 <=== 192.168.1.129 192.168.1.14 Telcontar:~ #
That host has not been booted in years! Where is it getting the information from?
/var/lib/nfs/rmtab
Telcontar:~ # l /var/lib/nfs/rmtab -rw-r--r-- 1 root root 308 Jul 14 2013 /var/lib/nfs/rmtab Telcontar:~ #
BUT, according to the man page (rpc.mountd):
Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab.
Not even that! Shouldn't that info be cleared at least on boot, perhaps on restart of the nfsd daemon? Should I report this in bugzilla? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
13.03.2018 18:05, Carlos E. R. пишет:
Telcontar:~ # l /var/lib/nfs/rmtab -rw-r--r-- 1 root root 308 Jul 14 2013 /var/lib/nfs/rmtab Telcontar:~ #
BUT, according to the man page (rpc.mountd):
Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab.
Not even that!
Shouldn't that info be cleared at least on boot, perhaps on restart of the nfsd daemon?
NFSv3 is stateless, server can reboot or resource can fail over to completely different system and clients will continue access it transparently (with some delay of course). Clearing this table will err on other side - remove current valid clients that are actively using resources from server.
Should I report this in bugzilla?
If there is a bug, it is in NFS protocol which cannot be changed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-13 18:20, Andrei Borzenkov wrote:
13.03.2018 18:05, Carlos E. R. пишет:
Telcontar:~ # l /var/lib/nfs/rmtab -rw-r--r-- 1 root root 308 Jul 14 2013 /var/lib/nfs/rmtab Telcontar:~ #
BUT, according to the man page (rpc.mountd):
Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab.
Not even that!
Shouldn't that info be cleared at least on boot, perhaps on restart of the nfsd daemon?
NFSv3 is stateless, server can reboot or resource can fail over to completely different system and clients will continue access it transparently (with some delay of course). Clearing this table will err on other side - remove current valid clients that are actively using resources from server.
Oh :-o Still, I have files there from 2013, all the machines have been rebooted since. One has not been powered up since. I guess I should then erase information manually.
Should I report this in bugzilla?
If there is a bug, it is in NFS protocol which cannot be changed.
-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Thorsten Kukuk wrote:
On Tue, Mar 13, Per Jessen wrote:
On a test system with leap15 -
Yesterday when I was playing with the yast nfs client module, I noticed it was using ipv4 for the rpc call to "rainbow" (the nfs server) to list the exported shares. The test system is dual-stack, so I thought that was odd. I then booted it as ipv6-only, and now it used ipv6 to query the nfs server. Revert to dual-stack, and it defaults to ipv4 again.
Other tools - e.g. ping and nfs-ls, correctly use the ipv6 address.
What is correct? I don't know the current situation, but I know a lot of tools of complicated algorithm to find out if ipv4 or ipv6 would be the better match. And if it is dual-stack, it shouldn't matter what is used.
For RPC: the config file is /etc/netconfig. And there, IPv4 is before IPv6.
From the changelog of libtirpc, I see you fixed something for SLES12:
* Thu Jan 21 2016 kukuk@suse.de - Remove 004-netconfig-prefer-IPv6.patch for SLES12. Anyway, it's not important, I was just surprised that something should want to override /etc/gai.conf. -- Per Jessen, Zürich (7.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Andreas Schwab -
Andrei Borzenkov -
Carlos E. R. -
Jan Engelhardt -
Manfred Hollstein -
Michal Kubecek -
Per Jessen -
Thorsten Kukuk