ldap fails to start when /etc/network/interfaces not used

[heckheck]

This bug is very similar in nature to Bug #958704. In a nutshell, autofs is unable to initialize correctly on boot due to upstart not starting things in proper sequence. In my case, network drives are described in LDAP maps and autofs is most likely starting before the system is able to use the network to retrieve the proper maps from LDAP. That results in drives not being mountable unless I restart autofs. For example

root@bar:/localhome/jheck# cd /dat/foo
bash: cd: /dat/foo: No such file or directory
root@bar:/localhome/jheck# restart autofs
autofs start/running, process 2188
root@bar:/localhome/jheck# cd /dat/foo
root@bar:/dat/foo#

So you see that for me to get my network drives working, I need to restart autofs after boot. This smacks of improper initialization sequencing.

The following packages are installed on my system and in use to use autofs with LDAP maps
autofs-ldap, ldap-utils, ldap-auth-client, nscd

I think this problem should be easily solvable by having autofs wait for the proper network utilities to be started and running before it attempts to initialize. This has been a perennial problem for NIS and LDAP reliant networks for MANY versions of Ubuntu. I had similar problems back in 8.04 when our system used NIS and also in 10.04. Please straightnen this out, since Ubuntu needs to be useful in network environements that use these types of auto-configuring network topologies.

nobody@bar:/data/network$ lsb_release -rd
Description: Ubuntu 12.04 LTS
Release: 12.04
nobody@bar:/data/network$ apt-cache policy autofs5
autofs5:
  Installed: 5.0.6-0ubuntu5
  Candidate: 5.0.6-0ubuntu5
  Version table:
 *** 5.0.6-0ubuntu5 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: autofs5 5.0.6-0ubuntu5
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Thu May 3 16:20:30 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: autofs5
UpgradeStatus: No upgrade log present (probably fresh install)

[Serge Hallyn (serge-hallyn)]

Thanks for submitting this bug.

The autofs upstart job starts on runlevel 2345, which ensures that static network configurations are up. Can you show your /etc/network/interfaces file?

If your /etc/network/interfaces file is empty and you are using networkmanager to provide network interfaces for users, then I think we need a different way of making that work with autofs.

[heckheck (jinfo)]

Below is the contents of my network interfaces file. As you suspected, it is empty and I am using network manager to provide network interface setup for the user, and so I guess the network isn't being brought up early enough to satisfy autofs.

The network manager has long bothered me. I REALLY don't like the fact that essential system configuration such as the network interfaces is stored in GNOME config instead of the nominal configuration files such as /etc/network/interfaces. I found in 12.04 that I am no longer able to directly add lines to /etc/resolv.conf either, as this file gets overwritten by network manager and the information stored elsewhere, where I can't easily see it.

root@bar:/etc/network# cat interfaces
auto lo
iface lo inet loopback

[Drew (drew-woz-f)]

Hello Serge,

I have seen a similar issue with 12.04 installed on a corporate network that uses LDAP for authentication. As was described in the original bug posting, automount fails to startup at bootup. When I manually restart autofs, networked NFS shares are automounted as expected.

I have attached a syslog which shows that automount attempts to start but fails because NetworkManager has not finished initializing the network interface. My interfaces file is the same as the one posted by heckheck.

If I can supply any other details or perform experiments, please advise.

Thanks, Drew

[Drew (drew-woz-f)]

Perhaps this is a 'default' configuration issue? My NetworkManager.conf had managed=false and interfaces had no eth0 entry. I don't know for sure whether this 'false' setting is an installation artifact or if I changed it at some point.

The following changes appear to resolve my issue - automount starts successfully! And syslog no longer shows any automount failures. dhclient now appears in log and cd /home/... works (see attached).

I hope this works for other folks.

// /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile
dns=dnsmasq

[ifupdown]
managed=true

// /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

[Serge Hallyn (serge-hallyn)]

lowering priority since using /etc/network/interfaces is a workaround.

[Serge Hallyn (serge-hallyn)]

Really I think that automount starting too early is a symptom. The real problem is that automount should be able to handle network interfaces going up and down.

[Ro (robert-markula)]

Well, fact is, that the autofs daemon is started right before network manager is bringing (wired) interfaces up:

<snip>
Jul 8 12:39:07 myclient automount[1431]: Starting automounter version 5.0.6, master map ou=auto.master,ou=[...],dc=example,dc=org
Jul 8 12:39:07 myclient automount[1431]: using kernel protocol version 5.02
Jul 8 12:39:07 myclient automount[1431]: lookup(file): file map /etc/ou=auto.master,ou=[...],dc=example,dc=org missing or not readable
Jul 8 12:39:07 myclient automount[1431]: no mounts in table
[...]
Jul 8 12:39:09 myclient NetworkManager[1100]: <info> Auto-activating connection 'Kabelnetzwerkverbindung 1'.
[...]
Jul 8 12:39:10 myclient NetworkManager[1100]: <info> Activation (eth0) successful, device activated.
</snip>

An elegant workaround would be to use a NetworkManager dispatcher script. Create a new empty file and make it executable:
touch /etc/NetworkManager/dispatcher.d/80automount
chmod 755 /etc/NetworkManager/dispatcher.d/80automount

Now you can open this file and paste your script which, in its simplest form, restarts the autofs daemon:

<snip>
#!/bin/bash

# These arguments are handed over by NetworkManager
INTERFACE=$1
ACTION=$2

case "$2" in
        up)
         # Restart the automount daemon
                /etc/init.d/autofs restart
                ;;

        down)
                ;;

        pre-up)
                ;;

        post-down)
                ;;

        *)
                echo $"Usage: $0 {up|down|pre-up|post-down}"
                exit 1
esac
</snip>

Save, exit and restart. Automount should be working now.

What it does: As soon as a new network connection is brought up successfully, the autofs daemon is restarted. Since at this point the connection is up already, it is now able to get the correct LDAP automount maps from the LDAP server.
This script can be improved of course, but you get the idea.