Hello,
please excuse me that this summary describes not a real solution - after
a reinstall of the system the *my* problem was gone, hopefully.
The problem was, that, although the modification of the NIS/C2 prpasswd
(map) was done and pushed correctly with no delay, the calling process
(i.e. passwd,dxaccounts) ran in a timeout situation (see also original
mail below).
This behaviour i was able to trace back to the network packets sent
between NIS client/server:
- after properly getting the RPC numbers for yppasswdd
- the requesting program (i.e. passwd through prpassdd) sends a packet
with the old and the verified new password to the NIS master (**);
maps got modified
- instead of getting an instant reply (after ca. 100ms)
- the new password packet (**) is sent 4 times within 30 seconds and
all getting an "ICMP desination unreachable" after that time
(the NIS master (AS2000) has a CDDI interface up and Ethernet not beeing
configured)
At this point i configured a 433au as NIS master (enhanced security)
without problems - so further invenstigation on my AS2000 without
knowledge of what rpc.yppasswdd should talk consumes time only.
With best regards
Uwe
---------- Forwarded message ----------
Date: Thu, 29 Jun 2000 15:36:02 +0200 (MET DST)
From: Uwe Richter <ur_at_minet.uni-jena.de>
To: tru64-unix-managers_at_ornl.gov
Subject: yppasswdd: prpasswd ndbm update failed (Tru46 V5.0/C2/NIS)
Followup-To: poster
Hello all,
after beeing happy to got a little NIS test domain running for enhanced
security and setting (hopefully) all the things recommended
(d_skip_ttys_updates, d_skip_success_login_log, ndbm),
I constantly get complains of the "rpc.yppasswdd" process on the NIS
master about not beeing able to update a map:
Jun 29 14:44:54 mynismater yppasswdd[22486]:
yppasswdd: prpasswd ndbm update failed for key testuser
In fact, all maps (and sources) are updated correctly!! and pushed to NIS
slaves by the
/usr/sbin/rpc.yppasswdd /var/yp/src/passwd /var/yp/src/prpasswd -m passwd
prpasswd
But every update action on enhanced security items forced by the default
system entry result in a delay of 1 min. until the requesting
user process gets a ready back.
"tracing" the listening prpasswd shows that the rpc-calls are serviced
successfully.
The same messages occur *regardless* the DB format (ndbm/btree) that was
set up for the maps.
So I'm a little bit in doubt what the rpc.yppasswd does after beeing told
to do a "make" in /var/yp, because manually rebuilding all NIS maps takes
about 10 seconds only.
Does anyone can give me a hint or observed the same behaviour?
Many thanks in advance
Uwe
--
Uwe Richter
Jena University, Faculty of Mathematics & Computer Science
Ernst-Abbe-Platz 1-4, Room#1219, D-07740 Jena, Germany
eMail: ur_at_inf.uni-jena.de Tel. : +49.3641.9.46044
Received on Tue Jul 04 2000 - 09:21:21 NZST