On Mon, 2016-04-11 at 18:35 +0200, Christof Koehler wrote: > Oops, replace 0.25.2 by 0.2.5 ... Sorry. > > On Mon, Apr 11, 2016 at 06:32:41PM +0200, Christof Koehler wrote: > > Hello, > > > > I will try to consolidate the answer in a single email without > > messing > > up the quoting too much. > > > > > But we can't really start to work out what needs to be done unless > > > libtirpc is being used. > > > > > And I think the best chance is to use 5.1.1 and possibly back port > > > any > > > changes. > > > > > As I say, the only other thing we can do is add some targeted > > > debug > > > logging and see if we can spot what is going wrong. > > > > I will then stick to the plan to defer this > > until ubuntu 16.04 has been released which should contain autofs > > 5.1.1 > > and libtirpc 0.25.2. From the libtirpc git repo and the sourceforge > > page > > I see that 0.25.2 is from 2014, but not even debian unstable is > > using a newer version (and from the changelog things like gss_api > > support are the main changes ?). > > > > I will use a virtual machine with ubuntu 16.04 (or if preferable > > debian > > testing or unstable) and then start experimenting. In that > > environment we > > can do to autofs and also libtirpc (and nfs-common if necessary) > > whatever > > is needed to get the necessary information. > > > > I will let you know when I start with that and what the baseline > > with > > the original packages of the distribution and simple rebuild of > > autofs > > --with-libtirpc is. > > > > > > Apr 8 18:05:25 core324 automount[963]: get_nfs_info: called > > > > with host > > > > core330(fd5f:852:a27c:1261:2000::118) proto 6 version 0x40 > > > > Apr 8 18:05:25 core324 automount[963]: get_nfs_info: called > > > > with host > > > > core330(2001:638:708:1261:2000::118) proto 6 version 0x40 > > > > Apr 8 18:05:25 core324 automount[963]: mount(nfs): no hosts > > > > available > > > > > Sadly that doesn't tell us much either, only that the rpc > > > communication > > > has failed to get a result in some expected way. > > > > Well, at least it shows that this autofs built at least is somehow > > aware of > > all the different IP adresses and trying the IPv4 one first. Of > > course > > no other conclusions can be drawn from this. > > > > > That's right, as I say the RPC communication isn't failing in an > > > unexpected way so we aren't seeing any error messages. > > > > > > About all that can be done is to add a patch that adds some extra > > > logging to try and get to the bottom of it. > > > > That should be possible with a virtual machine as mentioned above. > > > > > The first thing that stands out is that if libtirpc is not being > > > used > > > all IPv6 hosts will be ignored because (my impression is that) > > > glibc RPC > > > doesn't support IPv6. > > > > The libtirpc documentation says that libtirpc is needed for IPv6 > > ready > > rpc support, http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php a > > s > > linked from sourceforge. > > Might even be that glibc does actually no longer contain any rpc > > functionality ? > > https://archives.gentoo.org/gentoo-dev/message/186be8dc9753d18aafc9a > > 5a616b3b991 > > This would be supported by information on the tirpc web page > > mentioned > > above. > > > > As far as I understand your analysis you are saying the IPv6 > > mount in the "2001" case is just working by accident, right ? Basically, yes. The code that determines if there are multiple addresses for a host has a mistake in it. If it was working correctly I think you would have seen both mounts as IPv4. Fixing that mistake is possibly going to be part of a larger change for this so I'll leave it for now. > > > > > It's mount.nfs(8) mounting from the IPv6 address (when given a > > > host name > > > not an address) in the former case and not autofs that's getting > > > you an > > > IPv6 mount. And, AFAICS, the mount.nfs your using does use > > > libtirpc. > > Yes. > > # ldd /sbin/mount.nfs4|grep tirpc > > libtirpc.so.1 => /lib/x86_64-linux-gnu/libtirpc.so.1 > > (0x00007ffff7d9d000) > > and libtirpc is a hard package dependency of nfs-common. > > > > Best Regards > > > > Christof > > -- > > Dr. rer. nat. Christof Köhler email: > > c.koehler@xxxxxxxxxxxxxxxxxxx > > Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 > > Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 > > 28359 Bremen > > > > PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/ > > -- > > To unsubscribe from this list: send the line "unsubscribe autofs" in > -- To unsubscribe from this list: send the line "unsubscribe autofs" in