Autofs fails to start with maps from NIS

[Paul Smith]

Binary package hint: autofs

On Ubuntu Hardy with NetworkManager enabled, autofs doesn't work if your maps are distributed by NIS (which is extremely common in corporate environments).

In Hardy, NIS is configured to wait for NetworkManager to bring up the interface; it listens on dbus for the network start event and only then will it bind to the NIS server. This is good, I guess, since otherwise NIS can't bind.

However, it means that after S18nis starts, unlike a typical system, on Ubuntu NIS is not bound to a server yet. That means when we get to S19autofs and it tries to run ypcat etc. to grab the auto.master and other maps, nothing is printed.

That means autofs doesn't come up properly and we have to restart it by hand after the system has successfully booted.

I HATE the idea of forcing autofs to start listening on dbus, like someone hacked ypbind to do; it just seems really wrong to have to go through all system daemons and modify them like that. Doesn't NetworkManager come with some kind of wrapper utility that can be used to easily wrap around common network services like that and start/restart them using traditional sysv init operations, when the proper dbus messages are received? If not, that is where someone should spend some time rather than hacking GNU/Linux-specific features like dbus into generic packages like nis and autofs.

Anyway, this bug still stands: autofs is completely non-functional when using NIS to distribute maps in Hardy.

I've heard that this was true (NIS listened for dbus events) in Gutsy as well but I didn't notice it there; maybe NetworkManager was so buggy that I turned it off and I don't remember doing it.

$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

ii network-manager 0.6.6-0ubuntu5
ii nis 3.17-12ubuntu1
ii autofs 4.1.4+debian-2.1

[Mathi (mathiraj)]

I too face the same problem in 8.04. my home directory doesn't get auto mounted when I configure my system to use NIS.

Note : This functionality used to work in 7.10

I had to manually create auto.home to temporarily over come the problem. It'd be good if this is fixed.

[Wilbur Harvey (wilbur-harvey-spirentcom)]

My problem is that nis doesn't seem to start at all, but if I wait until the system is booted, and manually start NIS, it starts ok.
I have network manager installed, but I am using a fixed IP address for eth0

[Jonathan Purcell (jonathan-purcell)]

Yes I have been hitting the same problem, automount can't seem to use my nis maps. I swtiched to using an auto.master and auto.home file setup and everything sprung into life.

[Paul Smith (psmith-gnu)]

Note that using a local files is not a reasonable workaround for enterprise environments... the whole point of using NIS is to centralize management of the maps.

At the moment I cannot recommend Hardy to any environment that relies on NIS distribution of automount maps (which is actually, as I say, quite common for larger companies which have traditional infrastructures).

[deti (deti)]

same problem here

[Lionel Porcheron (lionel.porcheron)]

It is a more general issue : autofs with network maps tends to not start correctly with network manager. As a workaround, I use a script in /etc/network/if-up.d :
8<--------------------------------
#!/bin/sh

AUTOFS=/etc/init.d/autofs

if [ ! -x $AUTOFS ]; then
   exit 0
fi

$AUTOFS start
8<-------------------------------

autofs is restarted when interface bring up, and it works fine here.

[Paul Smith (psmith-gnu)]

I don't think adding this to if-up.d is robust. There could easily be a timing issue here where the facility that distributes your maps, which also cannot be started until the interface comes up, will not be started before the autofs script asks for them. For example, with NIS, after the interface comes up then we bind to a server, THEN the maps are available. But the binding can take a few seconds (especially if you're broadcasting for a server rather than using a hard-coded one) and in the meantime, autofs will try to start and fail to get any maps just as it does now.

[shark (weltepe)]

Same problem here. After the system boots, autofs needs to be manually started.

[yoyoq (yoyoq)]

hi,
autofs4 is the default and i had many problems with it,
i found the autofs5 deb file and
have had much better luck with that.
google for autofs5 should lead you to it.

hth
jpd

--- On Wed, 9/3/08, shark <email address hidden> wrote:

> From: shark <email address hidden>
> Subject: [Bug 213574] Re: Autofs fails to start with maps from NIS
> To: <email address hidden>
> Date: Wednesday, September 3, 2008, 4:21 PM
> Same problem here. After the system boots, autofs needs to
> be manually
> started.
>
> --
> Autofs fails to start with maps from NIS
> https://bugs.launchpad.net/bugs/213574
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>
> Status in “autofs” source package in Ubuntu: New
>
> Bug description:
> Binary package hint: autofs
>
> On Ubuntu Hardy with NetworkManager enabled, autofs
> doesn't work if your maps are distributed by NIS (which
> is extremely common in corporate environments).
>
> In Hardy, NIS is configured to wait for NetworkManager to
> bring up the interface; it listens on dbus for the network
> start event and only then will it bind to the NIS server.
> This is good, I guess, since otherwise NIS can't bind.
>
> However, it means that after S18nis starts, unlike a
> typical system, on Ubuntu NIS is not bound to a server yet.
> That means when we get to S19autofs and it tries to run
> ypcat etc. to grab the auto.master and other maps, nothing
> is printed.
>
> That means autofs doesn't come up properly and we have
> to restart it by hand after the system has successfully
> booted.
>
> I HATE the idea of forcing autofs to start listening on
> dbus, like someone hacked ypbind to do; it just seems really
> wrong to have to go through all system daemons and modify
> them like that. Doesn't NetworkManager come with some
> kind of wrapper utility that can be used to easily wrap
> around common network services like that and start/restart
> them using traditional sysv init operations, when the proper
> dbus messages are received? If not, that is where someone
> should spend some time rather than hacking
> GNU/Linux-specific features like dbus into generic packages
> like nis and autofs.
>
> Anyway, this bug still stands: autofs is completely
> non-functional when using NIS to distribute maps in Hardy.
>
> I've heard that this was true (NIS listened for dbus
> events) in Gutsy as well but I didn't notice it there;
> maybe NetworkManager was so buggy that I turned it off and I
> don't remember doing it.
>
> $ lsb_release -rd
> Description: Ubuntu hardy (development branch)
> Release: 8.04
>
> ii network-manager 0.6.6-0ubuntu5
> ii nis 3.17-12ubuntu1
> ii autofs 4.1.4+debian-2.1

[Jason Speck (jason-speck)]

The following fixes it for me in 8.10.

Basically, if you change the startup script sequence so that nis runs after NetworkManager, you should be okay.

check what sequence number the NetworkManager startup script has:

> ls /etc/rc2.d/*NetworkManager
/etc/rc2.d/S28NetworkManager

It should be 28. If so, you need to change the order of the nis and autofs scripts to run after NetworkManager

> sudo update-rc.d -f autofs remove
> sudo update-rc.d -f nis remove
> sudo update-rc.d nis defaults 29 71
> sudo update-rc.d autofs defaults 30 70

I

[Paul Smith (psmith-gnu)]

I'm not so sure that's it. There's no NetworkManager in /etc/init.d at all in 8.04, which I'm using, and it still has this problem.

[David Wilson (mcs6502)]

I have 5 labs of computers previously running 7.04 with YP/autofs which will be running 8.04 LTS this year. I found moving S18nis and S19autofs to S40nis and S41autofs works. I think anywhere after S24dhcdbd might do the trick but the 40's were otherwise unused so I put them there.

[David Holloway (daveh-dholloway)]

This is an important bug to me and anyone working with more than just a single-user machine.

[MikeGags (mikegags)]

I have tried all of the workarounds I have seen so far:
   - add scripts to restart autofs in if-up.d/if-down.d
   - add -no-dbus to YPBINDARGS
   - change the order in /etc/rc2.d (at least 2 varieties of this one)
None of these work for me.

Is there a known, reliable workaround for this yet?

Thanks!

[Paul Smith (psmith-gnu)]

Nope. Pretty sad. I guess no one at Canonical / Ubuntu cares much about legacy UNIX environments based on NIS. RedHat, SuSE, etc. have had this working out of the box for years and years. It worked on Ubuntu, too, until network manager came along.

What I do on my systems is create a new service that runs late and simply waits for NIS to be up, then restarts autofs.

I've attached it. See the comments for how to install it.

This is a bogus smelly hack but it works.

[MikeGags (mikegags)]

Hi Paul.

I was able to work around this - and the key is your comment:
"It worked on Ubuntu, too, until network manager came along."

I uninstalled NM (apt-get remove).
Then manually configured my eth0 for DHCP and it works like a champ.
I did add that "-no-dbus" to the YPBINDARGS in /etc/defaults/nis, but I'm not sure if its
necessary or not. I didn't want to put much more time into this. Next time I reboot....

This box is in a rack and isn't going anywhere, so I guess NM didn't offer me much
anyway. It is not as if I can't configure an interface via the GUI or command line.

If this setup (autofs over NIS for mouting home dirs) is legacy env, I wonder what the
current/next-gen env is?
I'd be interested in trying that out as I'm not necessarily bound to the autofs/NIS env.
Of course if there really isn't an alternative for mounting a home dir then I guess ubuntu
will have to do something at some point? Right? :-O

[Paul Smith (psmith-gnu)]

I think many newer environments are switching from NIS to ActiveDirectory (in Windows deployments) or LDAP, for both user account info as well as things like automount.

I've never used a setup like that so I can't say whether it works better or not with networkmanager.

Certainly it's ridiculous that this has been broken for years in Ubuntu. I've never worked at a company that DIDN'T use this model for mapping directories, and not just home directories but all sorts of standard shared directories. It works so nicely with Red Hat: you just bring up a system, tell it to use DHCP and what its hostname is, and voila! All is perfect: you have your DNS servers configured, NIS service configured, NTP service configured, hostname entered into DNS, etc. No effort required.

On Ubuntu, many of these things don't work and require manual tweaking, for no reason that I can see except that no one has felt it was a priority to fix the problems.

Pity.

[David Holloway (daveh-dholloway)]

Yep, Paul, that's how I'm perceiving this problem.

I'm not going stop using NIS anytime soon.. I have too many "classic" machines that I have to use on my network including HPUX 10, Solaris 2.5.1 and FreeBSD 5.4

[Paul Smith (psmith-gnu)]

On Tue, 2009-10-13 at 18:16 +0000, Chuck Short wrote:
> *** This bug is a duplicate of bug 50430 ***
> https://bugs.launchpad.net/bugs/50430
>
> ** This bug has been marked a duplicate of bug 50430
> NIS has problems starting before the network comes up

Why has this bug been marked as a duplicate of 50430?

50430 talks about NIS (ypbind) not working properly on NetworkManager
enabled systems. That should be fixed for a few releases now, and
indeed I haven't seen it on my systems in a while. My suspicion is that
the people who are still having trouble are really having problems with
NetworkManager not detecting/reporting the network status of their
systems properly (saying the network is up when it isn't or vice versa).

This bug (213574) is about autofs not working properly on NetworkManager
enabled systems. That is basically the same problem, but a completely
different package (in fact that's my major complaint about
NetworkManager: adding it to your system requires that you go around and
hack on each network-aware service on your system, one at a time, to
make them compatible with NetworkManager).

I've not upgraded to Karmic but I've seen absolutely nothing that leads
me to believe anyone has made any effort to enhance autofs, either the
daemon itself (a la ypbind) or even just the init scripts, to be
NM-aware. Until that happens this bug will not be fixed.

What has to happen on a very abstract level is that you can't start
autofs until all the services that it utilizes (based
on /etc/nsswitch.conf for example) are running, if they are supposed to
be started. It's hard because on many systems, /etc/nsswitch.conf lists
"nis" or "nisplus" as a source for automount, and yet these services are
not enabled. On other systems, automount data is taken from LDAP.
Other places it comes from flat files. Etc.

And remember, by "running" I don't just mean that the init script has
completed. In the brave new world of NetworkManager, having the init
script complete does NOT mean that the service is available. It just
means that it may _become_ available, sometime later.

autofs has to wait until these services are actually active, before it
can start. In the old days, with a simple serialized boot process
implying that once an init script was complete that service was
available, this was simple. Now it's become very tricky indeed.

[fil (fil-taz)]

I assume there's a conceptual bug, not to fix in any single package: NetworkManager is basically incompatible with sysV init. This also applies to "sysV powered by upstart". Unless a consistent event-driven model is in place NetworkManager may be fine for the occasional network-hopping Laptop but stays bogus on any centrally-managed corporate network. Just don't use it there yet. For the time being dependencies should be fixed: Install nis or kin -> purge nwm.

Even then: The idea behind nwm is to flexibly handle failures or delay of non-essential services. There's no flexibility in handling missing user-maps or other name-service. On my OSX Desktop I regularly get a login prompt refusing my nis credentials since booting the shell overtook setting up the network. Three failures gave me some early coffe and newspaper befor I realized the cause. The only sensible way here would be to tell the user what we're waiting for. Another package to be hacked.

For the new era to dawn we have to look into service dependencies from a higher level. Guess here's the limitation of a per-package bug-tracking approach. And I'd agree to favour wrapping over fixing. Shouldn't be autofs's burden what new concepts nwm or upstart make up.

g., fil

----- "Paul Smith" <email address hidden> schrieb:

> *** This bug is a duplicate of bug 50430 ***
> https://bugs.launchpad.net/bugs/50430
>
> On Tue, 2009-10-13 at 18:16 +0000, Chuck Short wrote:
> > *** This bug is a duplicate of bug 50430 ***
> > https://bugs.launchpad.net/bugs/50430
> >
> > ** This bug has been marked a duplicate of bug 50430
> > NIS has problems starting before the network comes up
>
> Why has this bug been marked as a duplicate of 50430?
>
> 50430 talks about NIS (ypbind) not working properly on NetworkManager
> enabled systems. That should be fixed for a few releases now, and
> indeed I haven't seen it on my systems in a while. My suspicion is
> that
> the people who are still having trouble are really having problems
> with
> NetworkManager not detecting/reporting the network status of their
> systems properly (saying the network is up when it isn't or vice
> versa).
>
>
> This bug (213574) is about autofs not working properly on
> NetworkManager
> enabled systems. That is basically the same problem, but a
> completely
> different package (in fact that's my major complaint about
> NetworkManager: adding it to your system requires that you go around
> and
> hack on each network-aware service on your system, one at a time, to
> make them compatible with NetworkManager).
>
> I've not upgraded to Karmic but I've seen absolutely nothing that
> leads
> me to believe anyone has made any effort to enhance autofs, either
> the
> daemon itself (a la ypbind) or even just the init scripts, to be
> NM-aware. Until that happens this bug will not be fixed.
>
> What has to happen on a very abstract level is that you can't start
> autofs until all the services that it utilizes (based
> on /etc/nsswitch.conf for example) are running, if they are supposed
> to
> be started. It's hard because on many systems, /etc/nsswitch.conf
> lists
> "nis" or "nisplus" as a source for automount, and yet these ...

[Paul Smith (psmith-gnu)]

Chuck, can you please undo the "duplicate" status of this bug? This is NOT a duplicate of bug 50430

[Paul Smith (psmith-gnu)]

Please undo the "duplicate" status of this bug.

This bug still exists in Precise 12.04 and 12.04.1: when I start my system autofs cannot see any maps that are stored in NIS.