Yellow Pages, Teil 1

ArticleCategory:

System Administration

AuthorImage:

[Photo of the Author]

TranslationInfo:

Original in fr Frédéric Raynal

fr to en Johan Decock

en to de Dieter Breitenstein

AboutTheAuthor:

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.

Abstract:

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.

ArticleIllustration:

[Illustration]

ArticleBody:

Einleitung

Der Network Information Service (NIS) ist �rspr�nglich eine Entwicklung von Sun und als Sun Yellow Pages bekannt (noch bekannter einfach als Yellow Pages oder YP). Doch dies ist eigentlich eine Handelsmarke der British Telecom und d�rfte konsequenterweise nicht ohne die entsprechenden Rechte benutzt werden. Die Yellow Pages der British Telecom sind das Branchentelefonbuch (wie im deutschsprachigen Raum die "Gelben Seiten").

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.

Wie funktioniert YP (NIS)?

Die Struktur

Im Netzwerk wird ein Computer als NIS-Server f�r eine Dom�ne dienen. Diese Dom�ne stimmt mehr oder weniger mit dem Namen der Datenbank �berein, die vom Server verwaltet wird. Der Dom�nenname ist der Schl�ssel, der von den NIS-Clients gebraucht wird, um die ben�tigte Information auf dem Server zu lokalisieren. Dieser Dom�nenname hat absolut nichts mit dem DNS Domain Name zu tun.
Es kann mehr als einen NIS-Server in derselben DNS-Domain geben. Sie k�nnen auf dem NIS-Level unterschiedliche Dom�nen verwalten, oder diesselbe NIS-Dom�ne (in diesem Fall gibt es einen Master-Server und einen Slave-Server).

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 Maps

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:

  1. der Name der Domain: das ist der Name der Datenbank auf dem YP-Server
  2. der Name der Map
  3. der Name des Schl�ssels
Ben�tigt also ein Client das Pa�wort des Users Toto in der Domain titi, wird er in der Datei /var/yp/titi/passwd.byname nach dem User Toto suchen.

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.

Remote Procedure Calls (RPC)

Die Funktionalit�t der Yellow Pages basiert im wesentlichen auf den Remote Procedure Calls (RPCs), dem Austausch von Anfragen zwischen Server und den Clients.

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.

Schlu�

Nun kennen wir das generelle Prinzip, der n�chste Artikel wird die Client-Seite der Yellow-Pages beleuchten. Wie sie funktionieren, wie sie zu konfigurieren sind, welche Tools zur Anwendung kommen, etc.... Wir werden auch einen Blick auf die Tools werfen, die n�tig sind, um unseren Client korrekt zu konfigurieren, sowohl f�r die RPC's, als auch f�r die YP's.