Original in fr Frédéric Raynal
fr to en Johan Decock
en to de Dieter Breitenstein
Die NIS Server speichern Kopien von gemeinsamen Konfigurationsdateien verschiedener vernetzter Computer in einer Datenbank. Die NIS Clients wiederum richten ihre Anfragen an diese Server, anstatt eigene Konfigurationsdateien zu benutzen.
Nehmen wir einmal an, wir w�ren User im Netzwerk und wollten das Passwort �ndern. Und nehmen wir weiter an, YP sei nicht installiert. Wenn wir uns die M�glichkeit offenhalten wollten, uns von jedem Computer im Netzwerk einloggen zu k�nnen, m��ten wir auch die Pa�wortdateien auf jedem einzelnen Computer aktualisieren. W�re aber YP installiert, dann w�re es uns m�glich, die �nderung auf einer einzigen Maschine vorzunehmen, auf der ein NIS-Client l�uft. Das neue Pa�wort w�rde dann dem NIS-Server �bermittelt und in der Datenbank ge�ndert. Und wenn sich nun ein User an einem vernetzten Computer einklinken wollte, w�rde das Pa�wort mit dem in der Datenbank auf dem Server verglichen (nat�rlich m��te auch dann ein NIS-Client auf dem Computer des Users laufen ;-).Es gibt verschiedene Versionen der YP, doch da dies ein
einf�hrender Artikel sein soll, werden wir uns auf die
Grundz�ge der Funktionsweise beschr�nken, ohne allzu sehr
ins Detail zu gehen. Auf die Einzelheiten gehen wir sp�ter
ein.
glibc 2.x (libc6) unterst�tzt den Einsatz von NSS (Name Switch
Service). Dieser Dienst bestimmt durch die Datei /etc/nsswitch.conf, in welcher
Reihenfolge Informationen gesucht werden m�ssen. Er
unterst�tzt Aliases, das Ethernet-Protokoll, Groups, Hosts,
Netgroups, Netzwerke, Protokolle, �ffentliche Schl�ssel,
Passwd, RPC, Dienste und Shadow Maps.
Die Slave-Server speichern lediglich eine Kopie der Datenbank des Master-Servers. Sie unterst�tzen den Master, wenn er zu viel Zeit ben�tigt, um die Anfragen der Clients zu beantworten, oder er gar in die Knie geht.
Die Slaves werden �ber jede �nderung im Datenbestand durch das Programm yppush informiert, und sie werden daraufhin ihre eigenen Datenbanken auf den neuesten Stand bringen, um die Master-Datenbank exakt widerzuspiegeln.
Die Clients ben�tigen ihrerseits keine Pflege, da sie st�ndig mit dem NIS-Server verbunden sind und auf die Informationen in dessen Datenbank zugreifen k�nnen.
Die YP-Datenbanken liegen im GDBM-Format vor, das aus dem ASCII-Format erzeugt wird. Diese Konvertierung geschieht bei der Installation des Servers durch das makedbm Programm.
Diese Maps bestehen aus Schl�ssel/Wert-Beziehungen. Alle YP-Maps basieren auf diesem Modell. F�r den Server ist der Inhalt dieser Paare ohne Bedeutung (okay, mit Ausnahme der Daten, die den Master-Server betreffen). Das bedeutet, da� f�r den Server eine Map mit Pa�w�rtern, Gruppen, oder was-auch-immer, nichts anderes ist als eine Ansammlung von Schl�ssel/Wert-Paaren. Nur der Client wei�, wie diese richtig zu deuten sind, und wie er die Information findet, die er braucht.
Diese Repr�sentation von Daten kann problematisch werden. Da der Server den zu einem Schl�ssel geh�renden Wert nicht interpretierend lesen kann, kann er auch einen zweiten, verborgenen Schl�ssel nicht finden. An einem Beispiel wird deutlich, was gemeint ist: Sucht der Client nach Pa�w�rtern, k�nnte er vom Login-Namen ausgehen oder von der UID (User ID, eine eindeutige Kennung f�r jeden User im Netzwerk). Um diese Suche zu erm�glichen, mu� die Pa�wort-Information verdoppelt werden. Dies f�hrt uns allerdings zu redundanter Information, wie man an den Dateien passwd.byname und passwd.byuid sehen kann. F�r jede Form der Suche mu� eine Map erzeugt werden, und bei einer �nderung m�ssen die Daten mehrfach �bertragen werden.
Drei Parameter werden von dem Client ben�tigt, um eine gesuchte Information in der Datenbank aufzusp�ren:
Das f�hrt zu einem sehr flexiblen System, da es nun, um eine neue Domain einzurichten, lediglich n�tig ist, das Verzeichnis /var/yp/new_domain zu erzeugen, das Makefile zu kopieren, und mit den korrekten Optionen auszuf�hren.
Der RPC Portmapper portmap ist ein Programm, das die RPC-Programm-Nummern in Portnummern �bersetzt. Wenn ein RPC gestartet wird, wird es portmap mitteilen, welchen Port es benutzen will und welche RPC-Programm-Nummer es ansprechen will.
Wenn ein Client eine RPC-Abfrage an eine bestimmte Programm-Nummer richten will, wird er zuerst den portmap-Server kontaktieren, um die Nummer des Ports zu erfahren, auf dem dieses Programm l�uft. Dann kann der Client die RPC-Packets an den entsprechenden Port schicken. Das YP Client/Server-Modell ist also nur ein Sonderfall des RPC Client/Server-Modells.
Die Datei yp_prot.h enth�lt die Strukturen und die Prototypen f�r 11 Funktionen, die das RPC-Protokoll definieren.