"ypcat" und "ypmatch username passwd" nicht nach Änderung auf Server

Question

Ich versuche, NIS für die Authentifizierung auf einer st von Maschinen zu verwenden. Ich musste eine der Benutzer-ID-Nummern für ein Benutzerkonto auf dem NIS-Server ändern (ich änderte die Benutzer-ID für username von 500 auf 509, um einen Konflikt mit einem lokalen Benutzerkonto mit ID 500 auf den Clients zu vermeiden). Das Problem ist, dass es auf dem Client nicht ordnungsgemäß aktualisiert wurde.

Insbesondere dann, wenn ich ypcat passwd | grep username tun, erhalte ich die up-to-date Informationen:

username:*hidden*:509:509:User Name:/home/username:/bin/bash 

Aber wenn ich es tue, ypmatch username passwd, heißt es:

username:*hidden*:500:500:User Name:/home/username:/bin/bash 

Das bedeutet, dass, wenn Der Benutzer meldet sich bei einem der Clients an. Er hat die falsche Benutzer-ID, die alle möglichen Probleme verursacht. Ich habe "cd /var/yp; make" auf dem Server und "service ypbind restart" auf dem Client getan, aber das hat das Problem nicht behoben. Weiß jemand, was das verursacht und wie ich eine Aktualisierung auf dem Client erzwingen kann? (Ich betreibe Fedora 8 auf Client und Server).

Answer 1

OK, ich fand das Problem, ich hatte auch den NIS-Dienst auf dem Server neu zu starten, um es zu bekommen, alles zu aktualisieren ("service ypserv restart")

Answer 2

hmm, ich bin nicht haben, um einen Neustart den ypserver haben sollte Aktualisierungen werden wirksam; die make in/var/yp sollte den Trick machen. Vielleicht möchten Sie das Makefile in/var/yp überprüfen, um sicher zu gehen, dass es unter den richtigen Bedingungen triggert (namentlich passwd.by * sollte den Zeitstempel auf/etc/passwd in gewisser Weise im Vergleich zu seiner aktuellen Tabelle überprüfen gehe eine passwd.time-Regel auf dem NIS-Server durch, den ich ausgeführt habe, zurück in den dunklen Zeiten). Das Beenden und Neustarten Ihres NIS-Servers kann auf (insbesondere nicht-Linux-) Clients flippige Effekte haben, also seien Sie vorsichtig, wenn Sie es nolens volens tun.

Answer 3

Das gleiche Problem festgestellt - RHEL 5.5. Ändern Sie (beliebige) Quellkarte, und führen Sie make aus. ypcat zeigt die geänderten Informationen an, ypmatch nicht. Alles, was nötig ist, um die neue Karte zu verwenden, schlägt fehl. Wie beim letzten Post macht der Neustart von ypserv alles in Ordnung. Nach Tagen des Testens, dem Ausführen von strace usw. habe ich festgestellt, dass ypserv einen "file handle cache" hat, der durch den Eintrag "file:" in /etc/ypserv.conf gesteuert wird. Der Standardwert ist 30. Ändere dies zu 0 und Alles funktioniert nach der Marke.

sollte das nicht tun --- Per Manpage für ypserv.conf ...

„Es war eine große Veränderung zwischen ypserv 1.1 und ypserv 1.2. Seit der Version 1.2, die Datei-Handles zwischengespeichert werden Dies bedeutet, dass Sie makedbm immer mit der Option -c aufrufen müssen, wenn Sie neue Maps erstellen.Vergewissern Sie sich, dass Sie das neue/var/yp/Makefile von ypserv 1.2 oder höher verwenden, oder fügen Sie makedbm im Feld das Flag -c hinzu Makefile. Wenn Sie das nicht tun, wird ypserv weiterhin die alten Karten verwenden und nicht die aktualisierte. "

Das Makefile DOES verwenden Sie "makedbm -c", aber immer noch ypserv verwendet die alte (im Cache gespeicherte) Karte.

Antwort: Die Dateizugriffsnummern, z. set "files: 0" in ypserv.conf

Answer 4

John O wies mich in die richtige Richtung.

Er hat Recht. Wenn Sie in /etc/ypserv.conf "files: 0" setzen, können Sie ypserv veranlassen, keine Dateien zwischenzuspeichern. Wenn du ypserv nach jedem make neu starten musst, ist das das Problem.

Die wirkliche Lösung ist/var suchen in/log/messages für diesen Fehler:

ypserv[]: refused connect from 127.0.0.1 to procedure ypproc_clear (,;0) 

makedbm -c bedeutet: YPPROC_CLEAR zum lokalen ypserv senden. Die Fehlermeldung im Protokoll bedeutet, dass die CLEAR-Nachricht verweigert wird. Sie müssen 127.0.0.1 zu/var/yp/securenets hinzufügen.

Answer 5

ist es wegen der Nscd-Daemon. Legen Sie den Wert für die Zeit bis zum Live-Wert auf 60 in der Datei /etc/nscd.conf für die passwd-Sitzung fest. Es wird funktionieren