Ubuntu
nis package

Is there a problem with NIS in Hardy Heron?

Asked by David

Upgraded from Gutsy to Hardy last week. Rebooted my computer today after installing a bunch of upgrades through the Upgrade Manager.

Automounting started failing to mount my home directory. So I tried restarting autofs (automount) and saw that was failing because it couldn't get the mount points from NIS, where they are stored.

"ypcat -k auto.home" gave a message that it could not locate my NIS domain. So I restarted nis on the master server, then restarted nis on my computer, which is a secondary nis server, and ypcat started working again. This allowed autofs to start and everything works fine.

Since I don't want to have to restart services manually every time the computers are rebooted, it would be great to solve this. Is it a Hardy Heron bug?

Thanks.

David

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu nis Edit question
Assignee:
No assignee Edit question
Solved by:
Art Cancro
Solved:
Last query:
Last reply:
Revision history for this message
David (david-kahn) said : 		#1

uname -a
Linux CERTIBY-DEV1 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

Revision history for this message
David (david-kahn) said : 		#2

I noticed that I am not the only person to have this problem: http://www.experts-exchange.com/OS/Linux/Setup/Q_23362347.html

Revision history for this message
xcorex (xcorex) said : 		#3

I too can confirm the problem.

Hardy 64

Revision history for this message
David (david-kahn) said : 		#4

My problem still exists.

Revision history for this message
Arne (arne-c-mueller) said : 		#5

similar problem here.

First of all NFS doesn't work with nis, because nfs is mounted before nis is started (that's like that for some weeks now). Didn't bother me really.

But today I discovered, that nis doesn't start up correctly, like you mentioned.

Because I had this NFS problem previously, I have a program running, that creates a bootflow diagram every time I boot. From these diagrams I was able to see, that soemhow hald moved in the execution order from S12 to S24. Nis starts here at S18. So I gather, that HAL is somehow required for nis, or something, that is started together with hald.

Previous boot-order:
...
S12hal
hald
hald-runner
hald-addon-acpi
hald-probe-vide
hald-addon-inpu
hald-addon-stor
console-kit-dae
sshd
avahi-daemon
S18nis
sleep
ypbind
cupsd
dhcdbd
...

current boot-order:
...
S18nis
sleep
ypbind
S19cupsys
cupsd
dhcdbd
S24hal
...

Revision history for this message
David (david-kahn) said : 		#6

The dependency of the automounter/autofs (not nfs) is because my mount points are stored in the yellow pages.

My /etc/auto.master contains a single line: +auto.master
which tells the automounter to get the mount information from YP.
    $ ypcat -k auto.master
    /home yp:auto.home --ghost
    /backup yp:auto.backup --ghost

The YP entries for the home directories look like:
    $ ypcat -k auto.home
    ftp certiby1:/localmasters/home/&
    jkahn certiby1:/localmasters/home/&
    gkahn certiby1:/localmasters/home/&
    david certiby-dev1:/localmasters/home/&
    administrator certiby1:/localmasters/home/&
    ...

In other words, each person's home directory gets mounted from whichever server is holding it.

The problem I am having is that when NIS fails to start, it also causes autofs, again not nfs, to fail. Fortunately, after rebooting I can use Webmin to remotely start NIS then autofs, and everything works okay. However, it's still a hassle.

Revision history for this message
Best Art Cancro (artcancro) said : 		#7

Confirmed here on my Hardy desktop as well. Renaming /etc/rc2.d/S18nis to /etc/rc2.d/S30nis in order to change the startup order, fixed the problem. It's rather stupid that this is broken out of the box.

Revision history for this message
David (david-kahn) said : 		#8

Thanks Art. That works great.

Revision history for this message
Gary Swofford (gary-olsen) said : 		#9

My office uses NIS (and autofs) on all our Ubuntu desktops, so NIS problems are a big deal for me. I found this same NIS problem with Hardy, although luckily I am just testing Hardy on two computers at the moment. The result is a bit strange, one Hardy desktop has the problem and the other does not. Both have the same order of services in /etc/rc2.d. Both were upgrades from Gutsy.

Can anyone confirm this is a problem when doing a new Hardy install?

The fix Art mentioned above worked fine for the "broken" desktop. Thanks Art :-)

Revision history for this message
randallw (rwayth) said : 		#10

I have this problem with a fresh Hardy 64bit install. I'm using NIS & autofs to connect to a server for accounts and home directories. Thanks for the workaround.

I think this should be upgraded to a bug. It is clearly broken out of the box.

Revision history for this message
David (david-kahn) said : 		#11

This has become Bug #233807 in Ubuntu.

Revision history for this message
Gary Swofford (gary-olsen) said : 		#12

Thanks David.

Revision history for this message
Dan Woodard (dan-e-woodard) said : 		#13

Same problem here on hardy:
uname -a
Linux bari 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux

I too am in an office that uses autofs to mount home directories and until now I have had to login and restart nis to restore home directories.

Revision history for this message
David (david-kahn) said : 		#14

The identical problem was reported as several bugs, and I cannot tell you if it has actually been solved. However, it is known that the problem is caused by NIS' use of D-Bus, and a workaround that worked for me was proposed by BlueCamel at https://bugs.launchpad.net/ubuntu/+source/nis/+bug/224828. Here it is:

"I ran in to this same issue on a fresh Hardy install. I fixed this by adding the -no-dbus flag to the /etc/default/nis config:

# Additional options to be given to ypbind when it is started.
YPBINDARGS=-no-dbus

With the above change you can disable roaming mode and use a static IP without changing the order of init scripts."

Good luck.

Revision history for this message
Mark Brown (broonie) said : 		#15

As discussed in the linked bugs the use of -no-dbus sidesteps the bugs in network manager. This workaround is employed in Debian releases but unfortunately Hardy (and Intrepid) synced when this was disabled for test purposes.

The Ubuntu guys seem keen to resolve this in Network Manger (which would be nice) so are reluctant to apply the workaround.