NIS / YP

Network Information System


 

Inhalt

- Was ist NIS? -
- Wie funktioniert NIS? -
- Beteiligte Daemonen -
- Änderung der passwd -
- Master-Installation -
- Client-Installation -
- Sicherheitsaspekte -

 

Erstellt von Oliver Fromme
Copyright © 2002-2006
secnetix GmbH & Co KG

Wie funktioniert NIS?

Der zentrale Server wird NIS-Master genannt. Zusätzlich kann es eine beliebige Anzahl von NIS-Slave-Servern geben, deren alleinige Aufgabe es ist, Redundanz zu erzeugen, für den Fall, dass der Master einmal nicht erreichbar ist (vergleichbar mit den Primary- und Secondary-Servern bei DNS). Jeder Master und jeder Slave kann zugleich auch NIS-Client sein. Dies ist der Normalfall.

Werden auf dem Master Änderungen an einer Map durchgeführt (z.B. ein User in der passwd hinzugefügt oder entfernt), schickt der Master einen sogenannten Push an alle Slaves (vergleichbar mit einem Notify bei DNS). Dies veranlaßt die Slaves, die betreffenden Maps erneut vom Master zu holen (vergleichbar mit einem DNS-Zone-Transfer).

Daraus folgt, daß (wie bei DNS) der Master alle Slaves kennen muß. Die Slaves müssen sich aber nicht untereinander kennen, und auch die Clients müssen nicht bekannt sein. Alle Informationen werden zentral auf dem Master gepflegt.

Wenn auf einem NIS-Client der Dienst gestartet wird, macht er einen Broadcast ins lokale Netz und nimmt einfach die Antwort des ersten Servers (Master oder Slave), der antwortet. Bei jeder nachfolgenden NIS-Anfrage wird dann nur dieser bekannte Server gefragt. Man sagt, der Client hat auf den Server gebunden. Das Kommando ypwhich zeigt an, welcher Server dies ist.

Falls der Server, auf den ein Client gebunden hat, innerhalb einer gewissen Zeit nicht antwortet, wird wieder ein Broadcast gemacht, um ggf. einen anderen NIS-Server zu finden.

Wenn man passwd-Daten per NIS in einem Netz verteilt, möchte man den Benutzern häufig auch die Möglichkeit bieten, ihre Daten (Passwort, Shell, Fullname) von jedem beliebigen Client aus ändern zu können. Wenn man dies erlauben möchte, muß man auf dem NIS-Master zusätzlich einen Daemon namens yppasswdd laufen lassen. Die Benutzer können auf den Clients ganz normal das passwd-Kommando verwenden. Dieses stellt automatisch fest, ob der Benutzer-Account per NIS verwaltet wird, und schreibt die Änderungen in dem Fall nicht in die lokale /etc/passwd (unter FreeBSD: /etc/master.passwd), sondern schickt sie an den yppasswdd-Daemon, der auf dem NIS-Master läuft. Dieser wiederum trägt die neuen Daten in die NIS-Maps ein und pusht sie an alle Slaves.

Varianten

Man kann die Adressen, die der Client als Server akzeptiert, auf eine bestimmte Liste einschränken. Darüberhinaus kann man einen Client auch zwingen, ausschließlich auf einen bestimmten Server zu binden. In diesem Fall werden keine Broadcasts gemacht, allerdings besteht keine Redundanz mehr, wenn dieser Server ausfällt.

Aus diesem Grund wird häufig jeder Client zu einem NIS-Slave gemacht und gezwungen, auf sich selbst zu binden. Somit ist jeder Client autark, und wenn es einen Ausfall gibt, sind die Folgen minimal, da sie nur den jeweiligen Client betreffen, aber keinen anderen. Ferner verbessert es die Performance, da die Anfragen nicht mehr über das Netz gemacht werden. Netzverkehr findet nur statt, wenn auf dem NIS-Master Änderungen durchgeführt werden, die dann an die NIS-Slaves gepusht werden. Diese Art von Setup wird in den folgenden Abschnitten beschrieben, da er viele Vorteile bietet. (In der DNS-Analogie wäre es so, als wenn man auf jedem Client einen eigenen Nameserver-Prozeß laufen ließe, und in der /etc/resolv.conf steht als Nameserver nur localhost drin. Dies ist sogar der Default, wenn gar kein Nameserver angegeben ist.)

Das einzige Problem, das in diesem Szenario auftreten kann, ist, daß ein Slave gerade offline ist, wenn der NIS-Master eine Änderung per Push durchfuehrt. In diesem Fall fehlt die Änderung auf dem Slave, und er arbeitet eventuell mit einer veralteten Map weiter. Daher wird üblicherweise auf den Slaves ein Cronjob verwendet, der regelmäßig (z.B. einmal pro Tag) die Maps vom Master abgleicht, um sicherzustellen, daß er auf dem aktuellen Stand ist. Es muß aber betont werden, daß diese Maßnahme nur für den genannten Ausnahmefall erforderlich ist, wenn ein Slave während einer Änderung offline ist. Im Normalfall wird jede Änderung auf dem Master sofort allen Slaves mitgeteilt und ist überall wirksam.


 

[Valid XHTML 1.0]