From: Norbert Kasperczyk-Borgmann (nkb@informatik.haw-hamburg.de)
Date: Fri Mar 28 2003 - 11:21:58 EST
Hi TRU64 Administrators,
this is not a real Summary cause a bigger part of the Problems still
exist.
In the archive you can read me original question:
http://www.xray.mpe.mpg.de/mailing-lists/tru64-unix-managers/2003-03/msg00293.html
First, a big "thank you very much" goes to Joseph A Senulis
(Joseph.Senulis@dnr.state.wi.us)
who gives me a lonely answer:
===== Joe's answer beginn ====
We may have had a similar problem for a while. It turns out that we
didn't have an rpc map, but YP really wanted one. Once we set that up,
things worked much better. I am not sure that this is your problem though.
You should verify that /etc/svc.conf and the YP configuration are correct.
===== Joe's answer end ====
I set up the map at my site but the problems still exists.
After checking every byte of the NIS-Configuration it turns out
that the map 'ypservers' was empty. After some testing I get the
best result when just the name of the Master-Server is in this map.
You create the map 'ypservers' by typing in each line of the file
'/var/yp/src/ypservers' the hostname of one NIS-Server once (don't forget
the name of the NIS-Master!!).
After this you just type: 'make ypservers' in the directory '/var/yp'.
This creates the map 'ypservers' if the following lines are in your
Makefile:
$(YPDBDIR)/$(DOM)/ypservers.time: $(DIR)/ypservers
-@if [ -f $(DIR)/ypservers ]; then \
$(AWK) '{print $$0, $$0}' $(DIR)/ypservers \
| $(MAKEDBM) -a $(METHOD) - $(YPDBDIR)/$(DOM)/ypservers; \
$(TOUCH) $(YPDBDIR)/$(DOM)/ypservers.time; \
else \
$(ECHO) "couldn't find $(DIR)/ypservers"; \
fi
ypservers: $(YPDBDIR)/$(DOM)/ypservers.time
$(DIR)/ypservers:
The command 'ypcat ypservers' should give twice at line the name of each
ypserver e.g:
NIS-MASTER@some.where NIS-MASTER@some.where
After this the NIS-Master pushes every change at the sources just to the
own database.
The NIS-Slaves get their copy only through their cronjobs.
I know that isn't the recommended configuration. But if you give the
name of the NIS-Slaves
there is a long time-out between the update and the push of the database.
The following error messages occur after about 5 minutes at the
NIS-Master when
typing (e.g.) 'yppush mail.aliases' when a NIS-SLAVE is in the
ypservers map:
Status received from ypxfr on NIS_SLAVE@some.where:
Map successfully transferred, but ypxfr couldn't send "Clear map"
to ypserv
If there was the file '/var/cluster/members/memberX/yp/ypxfr.log' at the
NIS-SLAVE
you can read there:
Fri Mar 28 16:32:19: clnt call NIS-MASTER@some.where ypxfrd getdbm
NOTOK <NIS-DOMAIN> ypservers code=2
Fri Mar 28 16:32:19: Attempt to use hi-speed xfr daemon on
NIS-MASTER@some.where failed
Fri Mar 28 16:32:19: Proceeding with basic xfr of <NIS-DOMAIN> ypservers
ypxfr: bind_to_server clnt_call error: RPC: Timed out
ypxfr: bind_to_server clnt_call error: RPC: Timed out
<NIS-DOMAIN> is the name of your NIS Domain.
The map itself is after about 1 second at the NIS-SLAVE (you can see it
with a 'ls -l /var/yp/<NIS-DOMAIN>'.
With the above configuration the Problem (RPC: Timed out) with the
command 'yppasswd' still exists.
I saw that only the map '/var/yp/<NIS-DOMAIN>/passwd.byname.pag' get's
an update immediatly
after the call of 'yppasswd'!! All other maps (passwd.byname.dir,
passwd.byuid.{dir | pag}
still have there old time for a longer period. The user who calls
'yppasswd' can allways login with
the new given passwort.
I removed all old NIS Configuration at the Master and the Slave. At both
server I do a fresh 'nissetup'.
I believe there is a problem somewhere deep in the NIS-System (ypserv,
ypxfrd, ...) itself.
I hope someone of the engineering can spend some time to this problem.
Best Regards
Norbert
-- Norbert Kasperczyk-Borgmann Hochschule fuer Angewandte Wissenschaften Hamburg - Hamburg University of Applied Sciences - Fachbereich E/I, Softwarelabor, Raum 1186 Berliner Tor 7, D-20099 Hamburg, Germany phone: +49 40 42875-8417 fax : +49 40 2803770 email: nkb@informatik.haw-hamburg.de
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:14 EDT