|
|
Dieses Dokument ist verfübar auf: English Castellano Deutsch Francais Nederlands Portugues Russian Turkce |
von Frédéric Raynal Über den Autor: Frédéric Raynal schreibt zur Zeit seine Doktorarbeit am INRIA1. Er liest gerne (wobei ihm Tolkien so lieb ist wie Balzac), und hört gerne Musik (von Mozart bis Philip Glass2 und von Led Zeppelin bis Massive Attack über Björk und Boris Vian, wobei er sorgsam Rap, Techno und alle anderen Arten von Lärm vermeidet ;-) Institut National de Recherche en Informatique et en Automatique, das heißt etwa Nationales Forschungsinstitut für Informatik und Automation ein "klassischer" Musiker. Inhalt: |
Zusammenfassung:
Der Network Information Service (NIS) stellt auf einem Server eine Datenbank zur Verfügung. Jeder Computer im Netzwerk, auf dem ein NIS Client läuft, kann eine Abfrage an diese Datenbank absetzen, um Benutzerinformationen zu erhalten (z.B. Login-Name, Passwort, User Groups,.....). Durch diese Datenbank wird die zentralisierte Administration einer großen Anzahl von Computern ermöglicht - insbesondere, wenn hier gleichzeitig ein Dateisystem wie NFS eingesetzt wird, da durch den Server und die Datenbank Änderungen der Benutzerinformationen sofort allen Clients zur Verfügung stehen.
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.
|
Der LinuxFocus Redaktion schreiben
© Frédéric Raynal, FDL LinuxFocus.org Einen Fehler melden oder einen Kommentar an LinuxFocus schicken |
Autoren und Übersetzer:
|
2001-07-19, generated by lfparser version 2.17