Network Information System

Als Benutzer erwarten Sie in einem lokalen Netzwerk, dass Sie, unabhängig vom konkreten Rechner, an dem Sie sich gerade anmelden, stets die gleiche Umgebung vorfinden. Der naive Ansatz, solchen »Komfort« zu realisieren, wäre aus Benutzersicht, Daten, die Sie an einem Rechner ändern, bei Beendigung der Sitzung auf allen anderen Rechnern zu replizieren. Natürlich wäre eine solche Lösung zum einen ziemliche Vergeudung von Speicherplatz (da die Daten mehrfach vorhanden wären) als auch, und der Grund wiegt wohl schwerer, nur mit hohem Aufwand zu betreiben. Letzterer ließe sich sicher mittels eines Skripts automatisieren und damit reduzieren... aber die meisten Anwender wären mit dem Verfassen eines solchen überfordert.

Selbst auf den Schultern des Administrators würde unnötig Mehrarbeit lasten, denn unter seine Verantwortung fiele es, jedem Benutzer Zugang zu jedem Rechner einzuräumen. Der nächste Auftrag für Sisyphus stünde an, sollten die Daten zu einem Benutzer geändert oder dessen Zugang gelöscht werden. Ob die Datenkonstistenz in umfangreichen Netzwerken noch gewährleistet wäre? Wohl kaum!

Der Ausweg ist die zentrale Lagerung wichtiger administrativer Daten und ein Dienst, der diese netzwerkweit zur Verfügung stellt. Eben der Network Information Service (NIS).

Gelbe Seiten

»Gelbe Seiten« ist der Inbegriff für eine Sammlung nützlicher Informationen. Wohl deshalb nannte SUN Microsystems seine erste Version eines solchen Dienstes »Yellow Pages«. Doch kollidierte der Name mit einem eingetragenen Warenzeichen der British Telecom, sodass SUN nach kurzem rechtlichen Gefecht auf den Begriff Network Information Service auswich. An den ürsprünglichen Namen erinnern noch die zahlreichen Programme rund um NIS, die, von wenigen Ausnahmen einmal abgesehen, allesamt mit dem Präfix »yp« beginnen.

SUN legte die Spezifikation zu NIS offen und reichte gleich noch eine freie Referenzimplementierung nach, die von BSD aufgegriffen und als Basis einer eigenen Realisierung von NIS diente. Die NIS-Client-Funktionalität in der Bibliothek »GNU-libc Version 5« basiert komplett auf diesem BSD-Code.

Der in den aktuellen »Glibc«-Versionen (»glibc-2«) enthaltene NIS-Code ist eine komplette Neuimplementierung der alten Routinen, ergänzt um neue Funktionen zur Zusammenarbeit mit SUN's NIS-Nachfolger NIS+ und einem erweiterten Konfigurationsschema. Im Wesentlichen werden wir nachfolgend auf die Belange der Konfiguration dieser NIS-Version eingehen und auf Abweichungen des alten Schemas nur kurz verweisen.

NIS vs. NIS+

SUN's NIS+ hat - abgesehen vom Wortstamm - nicht viel mit dem traditionellen NIS gemeinsam. Anstatt einer einzelnen Domain setzt NIS+ auf einen hierarchischen Verwaltungsbereich ähnlich der Strukturierung des Domain Name Service. Ein Knoten der Baumstruktur definiert eines von 6 möglichen NIS+-Objekten, wobei die Wurzel stets ein Objekt vom Typ »directory« ist. Innerhalb des Baums existieren die speziellen »directory«-Objekte »org_dir« und »groups_dir«. Ersteres enthält die zu verwaltenden Daten in Form von Tabellen und letzteres umfasst Einträge, die den Zugriff auf die Daten kontrollieren. Ein Paar von Objekten »org_dir« und »groups_dir« bildet zusammen mit dem übergeordneten »directory«-Objekt eine NIS+-Domain. Um das Schema flexibel zu halten, sind innerhalb der Tabellen Verweise auf Objekte aus anderen NIS+-Domains zulässig.

Die aus Anwendersicht wichtigsten Neuerungen von NIS+ sind die Unterstützung von Datenverschlüsselung und Authentifizierung via SecureRPC.

Bislang existiert keine Implementierung eines NIS+-Servers für Linux, sodass wir es bei dieser knappen Einführung zu NIS+ belassen.

Da die Suche nach Datensätzen in reinen ASCII-Dateien recht ineffizient ist, hält der NIS-Server die Daten in so genannten Maps vor. Die Daten der Maps sind im DBM-Format (Database Management) organisiert, sodass der Zugriff mittels Hashing-Funktionen enorm beschleunigt erfolgt. Die Maps müssen hierzu zunächst aus den »Original-ASCII-Dateien«, wie bspw. der /etc/passwd oder der /etc/group generiert werden. Diese Originale werden auch als Master-Dateien bezeichnet und oft existieren mehrere Maps für eine Master-Datei - für jeden Suchschlüssel eine. Im Falle der Passwortdatei sind die beiden Maps »passwd.byname« und »passwd.byuid« üblich, die die schnelle Suche per Benutzername bzw. per UserID ermöglichen.

Für bestimmte Maps werden gern Spitznamen vergeben, um den Schreibaufwand beim Zugriff auf diese möglichst gering zu halten. Die einzigen Programme, die diese Spitznamen verstehen, sind ypcat und ypwhich (Vergleiche Diagnose). Mit ersterem Programm können alle bekannten Spitznamen in Erfahrung gebracht werden:

Welche Informationen via NIS?

Die Motivation zum Einsatz von NIS entspringt wohl in nahezu allen Fällen dem Wunsch, auf allen Rechnern eines lokalen Netzwerks den Benutzern eine identische Umgebung anzubieten. Demnach sind die Konfigurationsdateien der Benutzerverwaltung, insbesondere die Dateien »/etc/passwd« und »/etc/group«, heiße Anwärter auf die Verwaltung durch einen NIS-Server. Normalerweise geht die zentrale Verwaltung der Benutzer einher mit einer zentralen Bereitstellung der Home-Verzeichnisse über NFS.

Prinzipiell kann jede ASCII-Datei via NIS den Clients zur Verfügung gestellt werden. Wirklich sinnvoll erscheint eine solche Konfiguration allerdings nur bei Dateien, die für alle Clients identisch aufgebaut und deren Inhalte dynamischer Natur sind. Denn so erspart sich der Administrator den Aufwand, nach Änderungen an einer Datei diese auch auf allen Clients nachziehen zu müssen.

Der Aufwand zur Erzeugung einer Map ist vergleichweise enorm - solange kein geeignetes Skript sich der Sache annimmt. Den meisten Distributionen liegt daher ein Makefile bei, das die Map-Erzeugung für gängige Dateien automatisiert. Was eine »gängige Datei« ist, ist hierbei Ermessensfrage des Distributors; Maps für /etc/networks, /etc/hosts, /etc/protocols, /etc/services, /etc/ethers,... gehören (fast) immer zum Standardrepertoire.

Abschließend sei darauf hingewiesen, dass es eine Konfigurationsfrage des NIS-Clients ist, welche der zur Verfügung stehenden Maps er vom Server bezieht und welche Dateien er lokal betrachtet (Vergleiche /etc/nsswitch.conf beim NIS-Client).

Manuelles Erzeugen der Maps

Die wichtigsten Optionen sind »-c«, womit makedbm nach Erzeugung der Map den NIS-Server (das Programm ypserv) anweist, seinen Cache zu leeren (der Server bekommt somit die Änderungen mit) und »-r«, womit Kommentarzeilen (Zeilen, die mit »#« beginnen) automatisch entfernt werden.

Ältere Versionen der Bibliothek »glibc« (Versionen < 2.2) unterstützten einzig NIS-Schlüssel und -Daten mit einer maximalen Länge von 1024 Bytes (genau genommen entstammt diese Beschränkung dem NIS-Protokoll). Um die Zusammenarbeit aktueller Server auch mit Clients zu gewährleisten, welche derartige Bibliotheken verwenden, überprüft »makedbm« in der Voreinstellung die Schlüssel- und Datensatzlänge und verweigert die Map-Generierung bei Überschreitung der Limits. Erst die Option »--no-limit-check« hilft in einem solchen Fall weiter (passen Sie ggf. den makedbm-Aufruf im weiter unten beschriebenen Makefile an!). In heterogenen Netzwerkumgebungen ist diese Option mit Vorsicht zu genießen, da etliche NIS-Clients kommerzieller Unix-Systeme mit langen Datensätzen und Schlüsseln nicht zusammen arbeiten.

»Makedbm« arbeitet zeilenweise, indem alle Zeichen bis zum ersten Leerzeichen oder Tabulator als Schlüssel und der Rest der Zeile als Daten interpretiert werden. Spätestens jetzt sollte Ihnen bewusst werden, dass die Map-Generierung doch nicht in jedem Fall trivial ist, denn nicht immer sollte die erste Spalte als Schlüssel dienen und - noch schlimmer - nicht jede Master-Datei trennt die Spalten per Leerzeichen oder Tabulator. Bestes Beispiel ist die Datei »/etc/passwd«, die den Doppelpunkt als Separator nutzt. Und die Lösung des »Problems«?

»Makedbm« erhält die Daten in »geeignet aufbereitetem« Format, i.d.R. generiert ein Awk-Skript die korrekten Datensätze. Ein Aufruf zum Erzeugen der Map »passwd.byname« könnte wie folgt aussehen:

Obigen Aufruf finden Sie in etwas abgewandelter Syntax in der Datei »/var/yp/Makefile«. Knapp »umrissen« finden folgende Schritte statt: Awk verwirft zunächst sämtliche Leerzeilen und Datensätze, deren Benutzerkennzeichen kleiner als 500 sind (i.d.R. werden »reale« Nutzeridentifikationen ab 500 vergeben). In allen übrigen Zeilen extrahiert Awk die erste Spalte (Benutzerkennzeichen), die als Schlüssel in der Map dienen soll, und schreibt deren Inhalt sowie nochmals die gesamte Eingabezeile, voneinander durch einen Tabulator getrennt, auf die Standardausgabe. Makedbm liest von der Standardeingabe (symbolisiert durch das Minus vor dem Map-Namen) und schreibt das Ergebnis in die Map »passwd.byname«.

Den Inhalt einer Map vermag ein Hex-Editor darzustellen (das folgende Beispiel dient einzig der Demonstration; wie viele Bytes tatsächlich vor den relevanten Informationen stehen, differiert von Map zu Map, sodass der Zahlenwert der Option »-j« vermutlich nicht korrekt sein wird):

Automatisches Erzeugen der Maps

Das dem NIS-Paket beiliegende Makefile enthält Steueranweisungen, um die Maps zu den gängigsten Dateien automatisch zu generieren. Ein Makefile enthält mehrere Einsprungspunkte, die so genannten Ziele (Targets), wobei das erste Ziel der Datei die voreingestellte Einsprungsmarke ist. Dieses default-Ziel testet die Umgebung und verzweigt seinerseits zum mit »all« bezeichneten Ziel. Der einfachste Weg, alle notwendigen Maps automatisch zu erzeugen, ist, dieses »all«-Ziel entsprechend anzupassen. Suchen Sie hierzu die mit all: beginnende Zeile in »/var/yp/Makefile«:

Im vorliegenden Makefile sind alle denkbaren Ziele als Kommentare (die mit »#« beginnenden Zeilen) beschrieben. Aktuell hängt »all« von den Zielen »passwd«, »group«, »rpc«, »services« und »netid«, ab, d.h. mit Bearbeitung von »all« werden auch die anderen Ziele angesprungen. Genau hinter jenen Zielen verbergen sich die komplexen Anweisungen zum Generieren der entsprechenden Maps. Fügen Sie also die Namen der von Ihnen gewünschten Ziele hinter »all« ein oder entfernen Sie sie, wenn sie nicht durch NIS verwaltet werden sollen.

Die Datei /etc/shadow darf nicht bei Systemen via NIS verwaltet werden, wenn diese noch auf die alte Bibliothek »libc5« aufsetzen, da Shadow-Passwörter von dieser nicht unterstützt werden.

Bei Problemen mit der Datensatzlänge (die Generierung der Maps bricht mit entsprechender Meldung ab) sollten Sie den Aufruf von makedbm im Makefile anpassen:

Der Aufruf kann sich bei anderen NIS-Versionen bzw. Distributionen (hier SuSE 8.0) vom Beispiel unterscheiden, wichtig ist, dass Sie die Option »--no-limit-check« ergänzen, den Rest aber unverändert belassen.

Als letzte Voraussetzung zur Genierung der Maps muss der NIS-Domainname gesetzt werden. In der folgenden Beschreibung zum Master-Server finden Sie eine weitergehende Erläuterung. Für unser Beispiel verwenden wir als NIS-Domainnamen »galaxis.de«:

Obiger Aufruf arbeitet ohne Interaktion mit dem Benutzer und eignet sich daher für die Automatisierung (siehe nachfolgenden Punkt »Aktualisierung der Maps«). Für den Fall, dass neben dem Master-Server noch weitere NIS-Server in der Domain arbeiten sollen, ist das Skript ypinit für die Map-Generierung zu bevorzugen, da es zur Eingabe der Slave-Server auffordert und diese Liste in der Datei »/var/yp/ypservers« hinterlegt:

Die Option -m ist auf dem Masterserver erforderlich. Im Unterschied zum direkten Aufruf von »make« erzeugt »ypinit« alle Maps generell neu, selbst wenn sich an den Masterdateien nichts geändert haben sollte. Letztlich ist »ypinit« wohl nur zum erstmaligen Erzeugen der Maps hilfreich oder im Falle sich ändernder Slave-Server. Aber selbst dann bleibt es Ihnen überlassen, ob Sie »make« bevorzugen und die Datei »/var/yp/ypservers« von Hand anpassen (jeden Server auf eine neue Zeile!).

Falls der NIS-Server nicht läuft, erhalten Sie bei der Map-Generierung - ob via »ypinit« oder »make« ist unerheblich - Fehlermeldungen der Art: »failed to send 'clear' to local ypserv: RPC: Program not registered«. Die Erzeugung der Maps wird dadurch nicht beeinträchtigt.

Im Verzeichnis »/var/yp« finden Sie anschließend das Unterverzeichnis »galaxis.de« (der Name entspricht exakt dem NIS-Domainnamen), das die erzeugten NIS-Maps enthält.

Aktualisierung der Maps

Änderungen an den vom NIS-Server bereitgestellten Konfigurationsdateien werden i.d.R. nicht direkt an den Maps vorgenommen, sondern mit eventuell vorhandenen Werkzeugen an den Master-Dateien in »/etc«. Der Administrator sollte jede Modifikation schnellstmöglich in die NIS-Maps übernehmen, nur... ob er wirklich stets dran denkt?

Der erfahrene Admin sorgt vor und automatisiert die Anpassung mittels eines Cron-Jobs. Im Terminkalender »/etc/crontab« steht dann bspw. folgender Eintrag:

Mit jenem Eintrag würde make alle 10 Minuten die Maps aktualisieren, insofern sich an den zugehörigen Masterdateien seit der letzten Generierung etwas geändert haben sollte. Im schlimmsten Fall könnte sich ein Benutzer, der soeben sein Passwort geändert hat, erst nach 10 Minuten mit dem neuen Passwort am System anmelden.

Verantwortungsbereich

Jeder NIS-Server ist für genau einen Verantwortungsbereich zuständig. Die Zugehörigkeit zu diesem Bereich ist durch die Verwendung einunddesselben (NIS-)Domainnamens gegeben. Dieser Domainname hat nichts mit der gleichnamigen Bezeichnung einer DNS-Domain zu tun, auch wenn er im Falle von NIS+ gleich lauten sollte (nicht muss!). Im Unterschied zum DNS wird beim NIS-Domainnamen die Groß- und Kleinschreibung unterschieden.

Der NIS-Domainname muss vor dem Start des NIS-Servers gesetzt sein, hierzu bedient sich der Administrator des Kommandos domainname:

I.d.R. wird der Domainname unmittelbar in einem der Skripte während des Bootens des Systems gesetzt (bei SuSE bwsp. in »/etc/init.d/boot.localnet«). Um den Namen permanent zu speichern, wird dieser in der Datei »/etc/defaultdomain« abgelegt. Das Kommando »domainname« kann nun mittels der Option »-F Datei« zur Entnahme des Domainnames aus einer Datei angewiesen werden.

/var/yp/securenets

Da die Zugehörigkeit zu einer NIS-Domain allein durch den gemeinsamen Domainnamen gegeben ist, kann ein jeder Rechner schon durch Verwendung des gleichen Namens Mitglied der Domain werden. Als Mitglied verfügt er über Zugriff auf sämtliche vom NIS-Server verteilte Maps. In offenen Netzwerken birgt diese einfache Verfahrensweise ein hohes Sicherheitsrisiko in sich.

Ein gangbarer Weg der Zugriffskontrolle, der durchaus auch in der Praxis angewandt wird, ist der Start des NIS-Servers bei Bedarf durch den Inetd, wobei ein zwischengeschalteter TCP-Wrapper die Verifizierung des Clients übernimmt. Allerdings wird der NIS-Server meist als permanter Server-Dienst betrieben, sodass anstatt des Wrappers ein anderes Verfahren tritt. Die neueren Implementierungen des Server-Prozesses verwenden daher die Datei »/var/yp/securenets«, die die Zugangsregeln enthält.

Die Datei »/var/yp/securenets« besteht aus Zeilen mit jeweils einem Paar aus Netzmaske und Netzwerkadresse. Die Adresse eines zugreifenden Clients wird bitweise UND mit der Netzmaske verknüpft. Stimmt das Ergebnis mit der Netzwerkadresse überein, ist der Zugriff gestattet. Bei Abweichung ignoriert der NIS-Server die Anforderung und protkolliert den fehlgeschlagenen Kontakt.

Anstatt der Netzmaske 255.255.255.255 darf das Schlüsselwort »host« verwendet werden. Die nachfolgende Datei enthält eine kommentierte Beispielkonfiguration:

Eine fehlende Datei »/var/yp/securenets« gestattet den Zugang für jeden Rechner.

Nach Änderungen an der Datei kann der laufende NIS-Server durch das Signal SIGHUP zum Einlesen der Konfiguration bewogen werden:

/etc/ypserv.conf

Die Datei »/etc/ypserv.conf« enthält vier Optionen für den NIS-Server »ypserv« und weitere Regeln zur Steuerung des Zugriffs von Clients auf die verschiedenen Maps. Letztere Regeln betreffen ebenso den Map-Transfer-Server »rpc.ypxfrd« der bei Betrieb von NIS-Slave-Servern eine Rolle spielt und später im Abschnitt betrachtet wird.

Jede Option steht auf einer extra Zeile und besteht aus dem Schlüsselwort, gefolgt von einem Doppelpunkt und dem Wert der Option. Nicht explizit erwähnte Optionen werden mit ihrem Default-Wert interpretiert, der in nachfolgender Aufzählung in Klammern unterstrichen angegeben ist:

dns

[yes, no], der NIS-Server versucht Rechnernamen, die nicht in den hosts*-Maps enthalten sind, durch Befragung des DNS-Servers aufzulösen. Üblich ist, Clients so zu konfigurieren, dass sie den DNS-Server selbst kontaktieren, falls die Befragung des NIS-Servers kein Ergebnis erbrachte.

files

[30], Anzahl der Map-Dateihandle, die der Server maximal im Cache zwischen speichern soll.

trusted_master

Diese Option ist für NIS-Slave-Server relevant und enthält den vollständigen Namen des Master-Servers. Der Slave-Server akzeptiert neue Maps nur vom angegebenen Master-Server. Fehlt diese Option, wird der Slave keine neuen Maps akzeptieren.

xfr_check_port

[yes, no], der NIS-Server wartet an Ports mit Nummern < 1024.

Die Optionen »tryresolve« und »sunos_kludge« sind veraltet und werden nicht mehr unterstützt; »trusted_master« wurde erst mit ypserv-2.2 eingeführt.

Die Datei »/var/yp/securenets« kontrolliert den Zugriff zum NIS-Server, wobei dieser entweder gewährt oder verhindert werden konnte. Mit den Regeln aus der Datei »/etc/ypserv.conf« kann der Zugriff detaillierter auf konkrete Maps beschränkt werden (natürlich muss ein betreffender Client durch »/var/yp/securenets« überhaupt den NIS-Server kontaktieren dürfen).

Eine Zeile für eine Zugangsregel besteht aus 4 durch Doppelpunkte getrennten Spalten mit folgender Bedeutung (bei älteren NIS-Implementierungen existierte noch eine optionale fünfte Spalte):

IP-Adresse

Die IP-Adresse, für die die Regel gilt. Netzwerkadressen und Wildcards sind ebenso zulässig.

NIS-Domain

Name der NIS-Domain, für die diese Regel gilt. Ein Stern »*« steht für »alle Domains«.

Map-Name

Name der Map, für die die Regel gilt. Ein Stern »*« steht für »alle Maps«.

Sicherheit

Die 3 möglichen Werte sind »none«, »port« und »deny«.

»none« erlaubt den Zugriff stets, während »deny« diesen konsequent ablehnt. Mit »port« werden Zugriffe nur gestattet, wenn sie an einem Port mit einer Nummer <1024 erfolgen.

Anmerkung: Die Datei »ypserv.conf« in älteren NIS-Implementierungen kannte keine Spalte »NIS-Domain« Dafür existierten zwei Spalten, die es ermöglichten, ein bestimmtes Feld einer Map zu verbergen, indem dessen Inhalt bei der Auslieferung durch ein x ersetzt wurde. Anwendung fand die Methode zum Ausblenden des Passwortfeldes entsprechender Maps (passwd.*, groups.*). Die aktuelle Implementierung maskiert Passwörter von Haus aus, sobald eine Regel für einen Client zutrifft. Ohne Regel ist der Zugriff stets erlaubt, womit keine Maskierung stattfindet!

Portmapper

Die Server-Dienste rund um das Network Information System basieren allesamt auf den Remote Procedure Call (RPC). Jeder RPC-Server muss sich zum Zeitpunkt seines Starts beim so genannten Portmapper registrieren, d.h. der Portmapper muss vor jedem zu startenden RPC-Dienst aktiviert werden.

Wir verzichten hier auf eine nochmalige Diskussion des RPC-Mechanismen. Ausführliche Einblicke gewährt ein eigener Abschnitt zum Remote Procedure Call. In der Diskussion zum NFS-Server finden Sie weitere Hinweise.

Ob der Portmapper auf Ihrem System aktiv ist, können Sie u.a. durch Aufruf von »rpcinfo - p« in Erfahrung bringen. Läuft er nicht, ähnelt die Ausgabe der folgenden:

Eventuell existiert in Ihrem System ein Runlevel-Skript zum Start des Portmappers. Bei SuSE und RedHat ist dies bspw. »/etc/init.d/portmap«. Rufen Sie als Root das Skript mit dem Argument »start«:

Fehlt ein solches Skript, dann suchen Sie in Ihrem System nach einem Kommando mit dem Namen »portmap« (manchmal auch »portmapper«) und starten dieses.

Start der Programme

Der NIS-Server wird mittels des Kommandos ypserv gestartet. Auch zum Start dieses Kommandos bringen viele Distributionen ein entsprechendes Runlevelskript (oft »/etc/init.d/ypserv«) mit, das mit der Option »start« auszuführen ist. Nach geglücktem Start sollte »rpcinfo - p« in etwa folgende Ausgabe produzieren:

Warum taucht der Server gleich vierfach in der Ausgabe auf? Tatsächlich ist nur ein einziges Serverprogramm aktiv, das sich mehrfach beim Portmapper registriert. Der Portmapper benötigt genaue Informationen, über welche Fähigkeiten ein Serverdienst verfügt. Der NIS-Server vermag Anforderungen sowohl über TCP als auch über UDP zu behandeln und unterstützt hierbei jeweils die Protokollversionen 1 und 2. Die Version 1 wird in aktuellen Konfigurationen oft fehlen, sie ist ohnehin nur bei vorhandenen NIS-Clients notwendig, die auf SunOS-4-Systemen laufen.

Auch zum Start des NIS-Servers existieren in den Distributionen entsprechende Runlevel-Skripte. Falls vorhanden, sollten Sie diese auch nutzen, da intern eine rudimentäre Prüfung der korrekten Konfiguration stattfindet. Bei SuSE und RedHat finden Sie das Skript »/etc/init.d/ypserv«, das mit der Option »start« zu rufen ist.

Nun haben Sie einen NIS-Server laufen, Ihre Benutzerverwaltung ist zentralisiert... doch was hat ein Benutzer zu tun, um bspw. sein Passwort zu ändern? Das Kommando passwd manipuliert nur lokale Dateien, der Zugriff auf die Server-Datenbanken ist ihm verwehrt. Auf Clientseite wird sich ein Benutzer daher an neue Kommandos gewöhnen müssen (im Falle des Passworts »yppasswd«), auf Serverseite steht dem NIS-Server ein weiterer Daemon zur Seite, der sich um Belange der Benutzerdaten kümmert. Der Server rpc.yppasswdd nimmt diesbezügliche Anforderungen von NIS-Clients entgegen, prüft die Berechtigungen und manipuliert die Felder der Passwortdateien. Abschließend führt »rpc.yppasswdd« das Skript »pwupdate« aus, das die Maps »passwd.*« und »shadow.byname« neu generiert.

In der Voreinstellung gestattet »rpc.yppasswdd« einzig das Setzen der Passwörter. Mittels der Optionen »-e chsh« und »-e chfn« kann den Benutzern der Zugriff auf das Shell- bzw. das Info-Feld ermöglicht werden. Auch die Verwendung alternativer Dateien kann »rpc.yppasswdd« mittels »-p <Passwortdatei>« bzw. »-s <Shadowdatei>« naheglegt werden.

Der Start des Server »rpc.yppasswdd« erfolgt entweder über das gleichnamige Kommando oder über ein Runlevelskript (insofern vorhanden):

Noch ein dritter Dienst könnte serverseitig von Interesse werden. Nämlich dann, wenn neben dem Master-NIS-Server auch noch ein oder mehrere Slave-NIS-Server die Clients einer Domaine bedienen und im Zuge sich häufig änderter und umfangreicher Maps die Geschwindigkeit der Aktualisierung eine zu wünschen übrig lässt.

Der Master-Server wird die Slave-Server über geänderte Maps unterrichten. Das Standardverfahren sieht nun vor, dass die Slaves das Kommando »/usr/lib/yp/ypxfr« starten, welches die Maps vom Master-Server herunter lädt. Die Kopien landen zunächst in einem temporären Verzeichnis und erst nach erfolgreichem Abschluss aller Transfers wird der Slave hieraus seine neue Datenbasis generieren.

Wird serverseitig der Dienst rpc.ypxfrd aktiviert, kümmert sich das zu Grunde liegende RPC-basierte Dateitransferprotokoll um eine gesicherte Übertragung, sodass ein Client die Maps vom Server direkt übernimmt, anstatt daraus erst eine neue Datenbasis zu erzeugen.

Obwohl »rpc.ypxfrd« durchaus per (x)inetd gestartet werden könnte, empfehlen die Entwickler wegen dessen gemächlichen Startzeiten den Start im Zusammenhang mit »ypserv«.

Eine Überprüfung der Funktionalität des Servers erfolgt mittels der Client-Werkzeuge zum Zugriff auf die Informationen der Maps. Den einzelnen Kommandos widmen wir uns konkret in der Diskussion zum NIS-Client; hier interessiert und einzig, ob der Server antwortet.

Dazu starten wir auf dem NIS-Server gleichzeitig einen NIS-Client. Ein simpler Aufruf von ypbind genügt:

Die Option »-broadcast« erzwingt eine Suche nach einem NIS-Server für die Domain. Auf sie kann verzichtet werden, wenn der Server in der Datei /etc/yp.conf eingetragen ist. Diese »saubere« Lösung ist aber Bestandteil der Client-Konfiguration und sollte uns an dieser Stelle nicht näher interessieren.

Der einfachste und Aussage kräftigste Test ist die Anfrage, welcher Rechner denn nun der Master-Server für eine Domain ist. Ein ypwhich, gerufen ohne Argumente, sollte den Server benennen:

Wenn hier schon etwas schief läuft, dann ist mit aller Wahrscheinlichkeit kein Server aktiv. Überprüfen Sie ggf. die am Portmapper angemeldeten Dienste.

Als Weiteres sollten Sie den Zugriff auf eine komplette Map verifizieren, bspw. indem Sie ypcat mit dem Namen der gewünschten Map konsultieren:

Solange die geforderte Map existiert, wird ihr Inhalt aufgelistet werden. Mit »ypcat -x« bringen Sie die Namen aller vom Server bedienten Maps in Erfahrung.

Schon konkreter, und in Hinsicht auf die spätere transparenten Zugriff auf Informationen der Maps von Bedeutung, ist eine gezielte Anfrage nach einem einzelnen Datensatz einer Map. So sollte folgender Aufruf die Information zum Benutzer »user« aus der Passwort-Datei extrahieren:

Wenn soweit alles funktioniert, sollten Sie die einzelnen Schritte auf entfernten Clients wiederholen. Die Feuerprobe hat Ihr Server allerdings erst bestanden, wenn auch das Login via NIS von den Client-Rechnern aus funktioniert. Gelingen die obigen Schritte, während das Login missglückt, sollten Sie das Kommando getent bemühen, um den tasächlich vom NIS-Server gelieferten Daten auf die Schliche zu kommen.

Ggf. erkennen Sie hier Felder, die vom Server maskiert wurden. Allerdings sollte dies nur bei älteren Implementierungen noch der Fall sein.

In Netzwerken mit nur wenigen angeschlossenen Rechnern wird ein einzelner Rechner als NIS-Server vollauf genügen. Zuverlässige Hardware vorausgesetzt, ist die Ausfallwahrscheinlichkeit des Servers gering, zumindest wenn er nicht zusätzlich als Arbeitsplatzrechner genutzt wird. In großen Netzwerken erweisen sich auch weniger die (Linux-)Server als Quelle von Ausfällen, sondern vielmehr die Netzwerkhardware wie Router, Switches oder einfach nur die Verkabelung. Ein stabiler Server nützt dann herzlich wenig, wenn der Client wegen unterbrochener Leitungen keinen Kontakt zu diesem findet. Hier bieten sich Slave-Server in den unabhängigen Netzsegmenten an, um zum einen den Master-Server zu entlasten und zum anderen bei Ausfall dessen die wesentlichen Aufgaben weiter anbieten zu können. »Wesentlichen« Aufgaben meint damit die Bereitstellung der Informationen der Maps. Änderungen an diesen, wie bspw. das Manipulieren von Passwörtern mittels »yppasswd«, kann jedoch einzig vom Master selbst vorgenommen werden und ist bei Ausfall dessen nicht möglich.

Um einen Rechner in den Stand eines NIS-Slave-Server zu erheben, muss dieser ebenso das Kommando ypserv ausführen. Das impliziert, dass sowohl der NIS-Domainname gesetzt als auch der Portmapper aktiv sein muss.

Woher erfährt der Slave nun den Namen des Master-Servers und die Namen der von ihm verwalteten Maps? Indem der Slave-Server sich der Funktionen eines NIS-Clients bedient. D.h. das Kommando ypbind ist zu starten:

Dieselben Bibliotheksfunktionen, denen sich bspw. das Kommando ybwhich bedient, nutzt der Slave, um die Informationen vom Master anzufordern.

Anstatt »ypwhich« können Sie auch direkt den Namen des Master-Servers oder eines anderen Slave-Servers mit aktueller Datenbasis angeben.

Ggf. sollten Sie auf dem Master-Server noch den Dienst rpc.ypxfrd starten. Näheres dazu finden Sie im Abschnitt zum Master-Server (»Start der Programme«).

Um die Funktionalität zu verifizieren, könnten Sie bspw. den Master-Server kurzfristig außer Dienst setzen und NIS-Anfragen absetzen, die nun von einem Slave-Server beantwortet werden sollten.