[Bug 213574] Re: Autofs fails to start with maps from NIS
*** This bug is a duplicate of bug 50430 *** https://bugs.launchpad.net/bugs/50430 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. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to autofs in Ubuntu. https://bugs.launchpad.net/bugs/213574 Title: Autofs fails to start with maps from NIS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/213574/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 213574] Re: Autofs fails to start with maps from NIS
*** This bug is a duplicate of bug 50430 *** https://bugs.launchpad.net/bugs/50430 ** Changed in: autofs (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to autofs in Ubuntu. https://bugs.launchpad.net/bugs/213574 Title: Autofs fails to start with maps from NIS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/213574/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 213574] Re: Autofs fails to start with maps from NIS
*** This bug is a duplicate of bug 50430 *** https://bugs.launchpad.net/bugs/50430 Chuck, can you please undo the duplicate status of this bug? This is NOT a duplicate of bug 50430 -- 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. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 213574] Re: Autofs fails to start with maps from NIS
*** 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 psm...@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 +, 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
Re: [Bug 213574] Re: Autofs fails to start with maps from NIS
*** This bug is a duplicate of bug 50430 *** https://bugs.launchpad.net/bugs/50430 On Tue, 2009-10-13 at 18:16 +, 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 member of Ubuntu Server Team, which is subscribed to autofs in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
