Dear Mark, > On a more detailed look at this the bug is in fact based on a > misunderstanding of the purpose of ypxfrd. Rather than accepting and
You are right. I am very embarrassed to realize that both bugs I reported on your package are invalid. I am so sorry for wasting your time on this. Re: bug #186363: By a strange feat of misfortune, the debugging I did on my slave server consistently lead me to the wrong conclusion. I was too fast in reporting to LP, and not careful enough in checking. When I started ypxfrd on the slave, the map transfer no longer hung on the master, but that was coincidental. That led me to conclude that the daemon must run there. It has been app. 10 years since I set up the NIS system, and I have forgotten about the details in the meantime. You are right that ypxfrd should run on the master, _not_ on the slaves. As for the other one, bug #186363, it is also invalid. What happened was that our domainname recently changed, and it seems that the old master name remained embedded in those databases that are not updated often, and the new master name was embedded in the rest. Consequently, when the slaves run ypinit, they only received maps associated with the new master name I was not aware that the database entries identified their master, but thinking about it, it is absolutely reasonable. What I _should_ have done -- and have now -- was to force the master to update all maps from the "source files" when noticing that the slaves did not enumerate all the master's maps. It is possible to provide a script that would reveal the situation. One solution is to see how many hosts are listed in the second field when doing ypwhich -m. For example: ypwhich -m|cut -f2 -d' ' should only list one master host. Also, the output of: ypwhich -m|cut -f1 -d' '|sort and /usr/lib/yp/yphelper --maps <master> |sort should be identical. If they are not, it indicates that the master's maps should be updated from source files. (The yphelper command is very finicky on what hostname it is given, in my case I need to use the FQDN.) So, the only thing that has come out of this is that the commented-out line in ypinit, that has $MASTER$, should be $MASTER. A bug in a comment line. Wow... :-( Cheers, Morten -- nis init.d script should start ypxfrd on slave, not master https://bugs.launchpad.net/bugs/186363 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
