On 2005-02-19, Mark Johnson <mXrXj001@shaw.ca> wrote:

> I'm not sure why doing this fixed it since it looks like the same sort
> of thing a reboot would do in running the rc.yp script at boot time. I
> hesitate to reboot now to test it.

I'm not positive of the order in which you did things. It sounds
like maybe you changed defaultdomain, rebooted, then fixed your
/var/yp directory, but perhaps didn't reboot after that? If so,
it's probable that your /var/yp had the right information, but
you still had some issues with ypserv not working with the right
nisdomainname and maps. *shrug* If it's working now, and your
/etc/defaultdomain is correct, then now's the best time to test
a reboot. You don't want to ''test'' it later when you depend
on it.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information

Keith Keller wrote:
> a reboot. You don't want to ''test'' it later when you depend
> on it.
>
Clearly, a good idea :-) When I reboot, the NIS processes don't start
automatically. rc.yp is invoked by rc.inet2, and it is marked as
executable.

I found the following in /var/log/syslog:
Feb 19 08:10:23 enterprise ypbind[2271]: Unable to register (YPBINDPROG,
YPBINDV
ERS, udp).

It works fine when I manually start it by running rc.yp as root. I
expect this means that there is some issue around the order in which
things are done at boot time. I'll investigate more later in the day.

Also, I have to unmount and remount the NFS file system on the client.
However, this is a separate (NFS) issue.
> --keith
>