[Bug 213574] Re: Autofs fails to start with maps from NIS

fil fil at taz.de
Wed Oct 14 11:50:41 BST 2009


*** This bug is a duplicate of bug 50430 ***
    https://bugs.launchpad.net/bugs/50430

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" <psmith at gnu.org> 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 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.
> 
> -- 
> 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 (via bug 50430).
> 
> Status in “autofs” 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

-- 
Autofs fails to start with maps from NIS
https://bugs.launchpad.net/bugs/213574
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to autofs in ubuntu.



More information about the Ubuntu-server-bugs mailing list