[Bug 1037192] Re: NFS shares are mounted with wrong clientaddr or not at all

[Sarah Angelini]

Hi Steve.  I'm working with Niko on the server mountall problem.  You're
right that the 0.0.0.0 client address issue occurs because mountall is
able to mount our NFS shares before it should.  Initially upon startup,
we run busybox's ipconfig (no tinc) and then rsync with the server to
get system updates.  After that, ifconfig is used to bring the device
down and startup is to proceed as normal.  It seems that some ip
information must be hanging around, though.  The log is recorded in
mountall-0000.log

Adding an "ip addr flush" command prevents mountall from completing the
mount before tinc is up.  Unfortunately, it also keeps our shares from
mounting at all.  If while it's sitting there I issue a "mount /opt"
command, then mountall seems to jump back in and continue with mounting
/home.  The log is mountall-flush.log and the lines at the end with "+"
in front are after I've manually mounted /opt.

Adding "initctl emit -n net-device-up" to our tinc scripts prompts
mountall-net.conf to send the SIGUSR1 signal.  The logs show mount
commands and the SIGUSR1 signal, but the network shares still don't come
up unless I manually mount one.  The log is mountall-net-device.log and
the "+" lines are after the manual mount.

What I have gotten to work is a bit of a hack.  Instead of depending on net-device-up, tinc sends out a custom signal (vpn-node-up), which mountall-net.conf is modified to listen for instead.  I think the net-device-up signal is sent when the ethernet itself comes up, but before tinc is fully initialized.  With the vpn-node-up signal, mountall-net only runs after tinc is up.  The log for this is in mountall-hack.log.  I would prefer to use the net-device-up signal properly if possible.  
  
Please let me know what further information would be helpful.

** Attachment added: "Mounts with 0.0.0.0 for client address"
   https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1037192/+attachment/3264211/+files/mountall-0000.log

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/1037192

Title:
  NFS shares are mounted with wrong clientaddr or not at all

Status in “mountall” package in Ubuntu:
  Incomplete

Bug description:
  With the following fstab:

  proc /proc proc nodev,noexec,nosuid 0 0
  /dev/mapper/vg0-fat_client / ext4 relatime,errors=remount-ro 0 1
  /dev/mapper/vg0-swap none swap sw 0 0
  spitzer:/opt /opt nfs4 auto 0 0
  spitzer:/home /home nfs4 auto 0 0

  The  /opt and /home are sometimes not mounted at all, and sometimes
  with the wrong clientaddr:

  $ mount | grep nfs
  rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
  spitzer:/home on /home type nfs4 (rw,clientaddr=0.0.0.0,addr=192.168.1.2)
  spitzer:/opt on /opt type nfs4 (rw,clientaddr=0.0.0.0,addr=192.168.1.2)

  Since this happens on all clients (they all get same clientaddr), this
  results in a frozen mount (cf
  http://thread.gmane.org/gmane.linux.nfs/47780)

  The "spitzer" host is only reachable via a tinc VPN, and mounting (or
  remounting) manually after boot always works and results in the
  correct clientaddr, so I believe that mountall is attempting to mount
  this too early.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: mountall 2.15.3
  ProcVersionSignature: Ubuntu 3.0.0-23.39~lucid1-server 3.0.36
  Uname: Linux 3.0.0-23-server x86_64
  Architecture: amd64
  Date: Wed Aug 15 12:16:17 2012
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: mountall

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1037192/+subscriptions