Re: autofs reverts to IPv4 for multi-homed IPv6 server ?

[Ian Kent <raven@themaw.net>]

On Fri, 2016-04-08 at 18:15 +0200, Christof Koehler wrote:
> OK, this actually fails to mount anything at all

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.

> 
> Apr  8 18:12:53 core324 automount[963]: parse_mount: parse(sun): core
> of entry: options=fstype=nfs4,rw,intr,nosuid,soft,nodev,
> loc=core320:/locals
> Apr  8 18:12:53 core324 automount[963]: sun_mount: parse(sun):
> mounting root /local, mountpoint core320, what core320:/locals, fstype
> nfs4, options rw,intr,nosuid,soft,nodev
> Apr  8 18:12:53 core324 automount[963]: mount_mount: mount(nfs):
> root=/local name=core320 what=core320:/locals, fstype=nfs4,
> options=rw,intr,nosuid,soft,nodev
> Apr  8 18:12:53 core324 automount[963]: mount_mount: mount(nfs): nfs
> options="rw,intr,nosuid,soft,nodev", nobind=0, nosymlink=0, ro=0
> Apr  8 18:12:53 core324 automount[963]: get_nfs_info: called with host
> core320(192.168.220.70) proto 6 version 0x40
> Apr  8 18:12:53 core324 automount[963]: get_nfs_info: called with host
> core320(2001:638:708:1261:2000::70) proto 6 version 0x40
> Apr  8 18:12:53 core324 automount[963]: mount(nfs): no hosts available
> Apr  8 18:12:53 core324 automount[963]: dev_ioctl_send_fail: token =
> 3006
> Apr  8 18:12:53 core324 automount[963]: failed to mount /local/core320
> Apr  8 18:12:53 core324 automount[963]: handle_packet: type = 3
> 
> Maybe I am missing dependencies ... 
> 
> 
> On Fri, Apr 08, 2016 at 06:12:26PM +0200, Christof Koehler wrote:
> > Hello,
> > 
> > I managed to build a new autofs 5.1.1 from the ubuntu 16.04 source
> > package after throwing out all systemd dependencies. With that
> > 
> > root@core324:~/autofs-5.1.1# ldd /usr/lib/x86_64-linux
> > -gnu/autofs/mount_nfs.so
> >         linux-vdso.so.1 =>  (0x00007ffff7ffd000)
> >         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x00007ffff7b73000)
> >         libtirpc.so.1 => /lib/x86_64-linux-gnu/libtirpc.so.1
> > (0x00007ffff794b000)
> >         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > (0x00007ffff7585000)
> >         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> >         libgssglue.so.1 => /lib/x86_64-linux-gnu/libgssglue.so.1
> > (0x00007ffff737b000)
> >         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> > (0x00007ffff7177000)
> > 
> > However, I had to edit lib/rpc_subs.c as indicated in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737679, otherwise
> > it would not 
> > work (/usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so: undefined
> > symbol: auth_put).
> > 
> > With the new binary /local/core330 does not mount either, but the
> > error message is
> > probably an improvement:
> > 
> > Apr  8 18:05:25 core324 automount[963]: parse_mount: parse(sun):
> > dequote("core330:/locals"
> > ) -> core330:/locals
> > Apr  8 18:05:25 core324 automount[963]: parse_mount: parse(sun):
> > core of entry: options=fs
> > type=nfs4,rw,intr,nosuid,soft,nodev, loc=core330:/locals
> > Apr  8 18:05:25 core324 automount[963]: sun_mount: parse(sun):
> > mounting root /local, mount
> > point core330, what core330:/locals, fstype nfs4, options
> > rw,intr,nosuid,soft,nodev
> > Apr  8 18:05:25 core324 automount[963]: mount_mount: mount(nfs):
> > root=/local name=core330 
> > what=core330:/locals, fstype=nfs4, options=rw,intr,nosuid,soft,nodev
> > Apr  8 18:05:25 core324 automount[963]: mount_mount: mount(nfs): nfs
> > options="rw,intr,nosu
> > id,soft,nodev", nobind=0, nosymlink=0, ro=0
> > Apr  8 18:05:25 core324 automount[963]: get_nfs_info: called with
> > host core330(192.168.220
> > .118) proto 6 version 0x40
> > 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
> > Apr  8 18:05:25 core324 automount[963]: dev_ioctl_send_fail: token =
> > 3004
> > Apr  8 18:05:25 core324 automount[963]: failed to mount
> > /local/core330
> > Apr  8 18:05:25 core324 automount[963]: handle_packet: type = 3
> > Apr  8 18:05:25 core324 automount[963]:
> > handle_packet_missing_indirect: token 3005, name core330, request
> > pid 2397
> > 
> > I had no success trying to get the 5.0.7 source package to actually
> > link libtirpc, 
> > no idea why.
> >  
> > Best Regards
> > 
> > Christof
> > 
> > On Fri, Apr 08, 2016 at 04:29:07PM +0200, Christof Koehler wrote:
> > > Hello,
> > > 
> > > apparently I confused my 5.1.1 source built experiment and my
> > > debian
> > > package rebuild experiment when I reported that libtirpc was used
> > > in my
> > > last email. So here is a new try to rebuild the deb source with
> > > --with-libtirpc.
> > > 
> > > I did a apt-get source autofs and added --with-libtirpc to debian
> > > rules.
> > > After that it would of course not allow me to build a package,
> > > "aborting
> > > due to unexpected upstream changes". So I just did a "dpkg
> > > -buildpackage
> > > -b" and then dpkg -i autofs... . Attached is the file build.out.gz
> > > which
> > > contains the stdout output. Clearly libtirpc is used somehow in
> > > the build.
> > > 
> > > After restoring maps in /etc I did a service restart autofs and
> > > with
> > > debug loglevel I get 
> > > 
> > > Apr  8 16:20:33 core324 automount[14615]: open_mount:247:
> > > parse(sun):
> > > cannot open mount module nfs
> > > (/usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so: undefined symbol:
> > > clnt_dg_create)
> > > 
> > > as reported. I then double checked and actually
> > > 
> > > root@core324:~# ldd /usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so
> > >         linux-vdso.so.1 =>  (0x00007ffff7ffd000)
> > >         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > > (0x00007ffff79f3000)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> > > 
> > > no libtirpc. 
> > > 
> > > I will have to read up on how to properly rebuild the package. The
> > > debian documentation is unfortunately not very user friendly, any
> > > hints are appreciated.
> > > 
> > > Best Regards
> > > 
> > > Christof
> > > 
> > > On Fri, Apr 08, 2016 at 02:25:52PM +0200, Christof Koehler wrote:
> > > > Hello again,
> > > > > I've been thinking about this and I have a couple of thoughts.
> > > > > 
> > > > > As far a IPv6 goes using glibc RPC is, I think, not going to
> > > > > work!
> > > > > 
> > > > > That's the first thing that needs to be sorted out.
> > > > > 
> > > > > I've been using libtirpc in Fedora and RHEL builds for nearly
> > > > > 10 years
> > > > > so I don't think the library problem is with autofs.
> > > > > 
> > > > > This is an indication someone is doing something a little
> > > > > dumb:
> > > > > 
> > > > > automount[20444]: open_mount:247: parse(sun): cannot open
> > > > > mount module
> > > > > nfs (/usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so: undefined
> > > > > symbol:
> > > > > clnt_dg_create)
> > > > 
> > > > concerning my failures to build autofs. First the client has all
> > > > libtirpc packages I think are necessary:
> > > > # dpkg -l libtirpc\*|grep ii
> > > > ii  libtirpc-dev                                   0.2.2
> > > > -5ubuntu2
> > > > ii  libtirpc1:amd64                                0.2.2
> > > > -5ubuntu2
> > > > 
> > > > We have libtirpc1 on the machines by default and I had to
> > > > install libtirpc-dev so that ./configure would conclude that
> > > > --with-libtirpc should do anything. 
> > > > 
> > > > Actually I tried to compile autofs 5.1.1 from source and a new
> > > > 5.0.7
> > > > package from ubuntu's source deb.
> > > > 
> > > > Using the sources at 
> > > > https://www.kernel.org/pub/linux/daemons/autofs/v5/
> > > > I was basically confused what to do about the patches. Do I have
> > > > to
> > > > apply everything in patches-5.1.2 to autofs-5.1.1.tar.gz to get
> > > > 5.1.2 ? 
> > > > How do I do that automatically ? I noticed that autofs
> > > > -5.1.1.tar.gz
> > > > misses the patch mentioned in message 15 of
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737679
> > > > but contained in autofs-5.1.1-revert-fix-libtirpc-name
> > > > -clash.patch.
> > > > 
> > > > So to make it short I certainly messed something up
> > > > somewhere, the final binary and libs were no success .
> > > > Additionally
> > > > installation did not play nice, although --prefix= was set it
> > > > overwrote
> > > > configuration files in /etc.  But I think I
> > > > cleaned everything up afterwards.
> > > > 
> > > > If someone can provide some hints I would try it again.
> > > > 
> > > > After that I rebuild the 5.0.7 package from source deb after
> > > > adding
> > > > --with-libtirpc to debian/rules as suggested in the bug reports.
> > > > I
> > > > installed from that package.  I checked with ldd after
> > > > installing
> > > > that ldd /usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so was build
> > > > with a
> > > > reference to libtirpc. 
> > > > 
> > > > This try gave the error message in the ubuntu bug
> > > > report 
> > > > https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1564380
> > > > 
> > > > So, any hints are appreciated. As long as I can stick to 5.0.7
> > > > rebuilt
> > > > from the source deb installing/re-installing is no problem and I
> > > > can try
> > > > different things you might want. Assuming I can get the program
> > > > to work :-)
> > > > 
> > > > Thank you very much for all your help !
> > > > 
> > > > 
> > > > Best Regards
> > > > 
> > > > Christof
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Dr. rer. nat. Christof Köhler       email: 
> > > > c.koehler@bccms.uni-bremen.de
> > > > 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
> > > 
> > > -- 
> > > Dr. rer. nat. Christof Köhler       email: 
> > > c.koehler@bccms.uni-bremen.de
> > > 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/
> > 
> > 
> > 
> > -- 
> > Dr. rer. nat. Christof Köhler       email: 
> > c.koehler@bccms.uni-bremen.de
> > 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