| |
|
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 (z.B. /etc/shadow, /etc/passwd, /etc/group ...)
verschiedener vernetzter Computer in einer Datenbank. Die NIS Clients
wiederum richten ihre Anfragen an diese Server, anstatt eigene
Konfigurationsdateien zu benutzen, bzw. als Erweiterung der
eigenen Konfigurationsdateien.
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üssten wir auch die Passwortdateien 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 Passwort 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
Passwort mit dem in der Datenbank auf dem Server verglichen (natürlich
müsste auch dann ein NIS-Client auf dem Computer des Users laufen).
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.
|
|
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
wiederzuspiegeln.
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 Programm makedbm.
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 (mit Ausnahme der Daten, die den Master-Server
betreffen). Das bedeutet, dass für den Server eine Map mit Passwörtern,
Gruppen, oder was-auch-immer, nichts anderes ist als eine Ansammlung von
Schlüssel/Wert-Paaren. Nur der Client weiss, 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
 Passwö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, muss die Passwort-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 muss
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:
-
der Name der Domain: das ist der Name der Datenbank auf dem YP-Server
-
der Name der Map
-
der Name des Schlüssels
Benötigt also ein Client das Passwort 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.
|
|
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-Packete 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.
-
YPPROC_DOMAIN und YPPROC_DOMAIN_NOACK ermöglichen den Clients, zu
einer gegebenen Domain den richtigen Server zu finden.
-
Die Funktionen YPPROC_MATCH, YPPROC_FIRST, YPPROC_NEXT und
YPPROC_ALL ermöglichen es, auf die Daten der Maps zuzugreifen.
-
YPPROC_XFR wird von yppush aufgerufen, um den Slaves anzuzeigen,
dass sich die Map auf dem Master geändert hat und die Kopien auf den
neuesten Stand gebracht werden müssen.
-
YPPROC_CLEAR löscht den Inhalt des Caches und der File-Handles.
Diese Funktion wird aufgerufen, nachdem eine Map upgedated wurde, z.B.
nach dem makedbm -c Kommando.
-
YPPROC_MASTER, YPPROC_ORDER und YPPROC_MAPLIST ermöglichen es,
spezielle Informationen über die Maps zu erhalten. Wenn zum Beispiel auf
einem Client ein Passwort geändert wird, ruft das Programm yppasswd die
Funktion YPPROC_MASTER auf, um den Server zu bestimmen, bevor dort die
Datenbank geändert wird.
|
|
|
SelfLinux 
