Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 10
Das »Network Information System«

Wenn Sie ein lokales Netzwerk betreiben, ist Ihr Ziel üblicherweise, den Benutzern eine Umgebung zur Verfügung zu stellen, die das Netzwerk transparent erscheinen läßt. Ein wichtiger Schritt in diese Richtung ist die Synchronisation aller lebenswichtigen Daten wie Account-Informationen zwischen allen Hosts. Wir haben bereits gesehen, daß für die Auflösung von Hostnamen ein leistungsfähiger Service bereitsteht -- DNS. Für andere Aufgaben gibt es keinen so spezialisierten Service. Darüber hinaus scheint die Einrichtung von DNS auf einem kleinen LAN ohne Internet-Connectivity kaum der Mühe wert zu sein.

Aus diesem Grund entwickelte Sun NIS, das Network Information System. NIS bietet einfache Datenbank-Zugriffseinrichtungen, die verwendet werden können, um Informationen, wie sie in den Dateien passwd und groups enthalten sind, an alle Hosts in Ihrem Netzwerk zu verteilen. So erscheint das Netzwerk als einzelnes System mit denselben Accounts auf allen Hosts. Auf ähnliche Weise können Sie NIS einsetzen, um die Informationen zu Hostnamen aus /etc/hosts an alle Maschinen im Netzwerk zu verteilen.

NIS basiert auf RPC und besteht aus einem Server, einer Bibliothek für die Client-Seite und verschiedenen administrativen Tools. Bekannt wurde NIS unter dem Namen Yellow Pages (»Gelbe Seiten«), kurz YP, der heute immer noch häufig verwendet wird. Andererseits ist »Yellow Pages« ein Warenzeichen der British Telecom, was dazu führte, daß Sun den Namen fallen ließ. Aber wie die Dinge nun einmal laufen, bleiben manche Namen einfach hängen, und so lebt YP als Präfix für die Namen der meisten NIS-Befehle wie ypserv, ypbind etc. weiter.

Heutzutage ist NIS für nahezu jedes UNIX-System verfügbar, es existieren sogar freie Implementierungen. Eine davon ist die BSD-Net-2-Release, die von einer freien Referenz-Implementierung abgeleitet ist, die Sun bereitgestellt hat. Der Client-Library-Kode dieser Release ist seit langer Zeit Teil der GNU-libc enthalten, während die administrativen Programme erst kürzlich von Swen Thümmler(1) implementiert wurden. Ein NIS-Server aus der Referenz-Implementierung fehlt aber. Tobias Reber hat ein anderes NIS-Paket geschrieben, das alle Tools und einen Server enthält; es heißt yps.(2)

Momentan wird der gesamte NIS-Kode unter der Bezeichnung NYS von Peter Eriksson(3) neu geschrieben. Unterstützt wird dabei sowohl das einfache NIS als auch das von Sun stark überarbeitete NIS+. NYS stellt nicht nur eine Reihe von NIS-Tools und einen Server zur Verfügung, sondern enthält auch einen neuen Satz von Bibliotheks-Funktionen, die möglicherweise einmal in die Standard-libc übernommen werden. Es schließt ein neues Konfigurations-Schema zur Auflösung von Hostnamen ein, das das aktuelle Schema ersetzt, das noch host.conf verwendet. Die Features dieser Funktionen werden noch weiter unten erläutert.

Dieses Kapitel behandelt schwerpunktmäßig NYS und nicht so sehr die beiden anderen Pakete, die ich als den »traditionellen« NIS-Kode bezeichne. Wenn Sie eines dieser Pakete verwenden wollen, könnten die Anweisungen in diesem Kapitel ausreichen oder auch nicht. Für weitere Informationen seien Sie auf die entsprechende NIS-Literatur verwiesen.

Zur Zeit befindet sich NYS immer noch in der Entwicklung. Darum erkennen die Standard-Linux-Utilities wie die Netzwerk-Programme oder das login-Programm noch nicht das neue NYS-Konfigurationsschema. Trotzdem wurde NYS in die Hauptbibliothek libc (seit Version 4.6) integriert, so daß Sie Ihre eigene C-Bibliothek mit NYS-Unterstützung anstelle des traditionellen NIS-Kodes aufbauen können. Standard ist aber immer noch der traditionelle NIS-Kode. Das GNU-Projekt scheint auch daran interessiert zu sein, NYS in seine offiziellen GNU-libc aufzunehmen, von der die Linux-Bibliothek abstammt. (Informationen zum Kompilieren einer C-Bibliothek mit NYS-Unterstützung finden Sie in der Datei README.nys, die der Library-Quelldistribution beiliegt.)

Vertraut werden mit NIS

NIS hält seine Datenbank-Informationen in sogenannten Maps (etwa: Zuordnungen), die Key/Value-Paare enthalten. Die Maps werden auf einem zentralen Host gespeichert, auf dem der NIS-Server läuft. Clients können die Informationen dann von diesem Server über verschiedene RPC-Calls abrufen. Häufig werden Maps in DBM-Dateien gespeichert.(4)

Die Maps selbst werden normalerweise aus Master-Textdateien wie /etc/hosts oder /etc/passwd generiert. Aus manchen Dateien werden mehrere Maps generiert, jeweils eine pro Suchschlüssel. Zum Beispiel können Sie die Datei hosts nach einem Hostnamen ebenso wie nach einer IP-Adresse durchsuchen. Entsprechend werden zwei NIS-Maps daraus erzeugt: hosts.byname und hosts.byaddr. Tabelle 10--1 enthält eine Liste der gängigen Maps sowie der Dateien, aus denen sie generiert werden.

------------------------------------------------------
Master-Datei      Map(s)                                
------------------------------------------------------
/etc/hosts        hosts.byname, hosts.byaddr            
/etc/networks     networks.byname, networks.byaddr      
/etc/passwd       passwd.byname, passwd.byuid           
/etc/group        group.byname, group.bygid             
/etc/services     services.byname, services.bynumber    
/etc/rpc          rpc.byname, rpc.bynumber              
/etc/protocols    protocols.byname, protocols.bynumber  
/usr/lib/aliases  mail.aliases                          
------------------------------------------------------
Tabelle 10.1: Einige Standard-NIS-Maps und die entsprechenden Dateien

In dem einen oder anderen NIS-Paket könnten auch andere Dateien und Maps unterstützt werden. Diese enthalten in der Regel Informationen zu in diesem Buch nicht behandelten Programmen. Dazu gehört beispielsweise die bootparams-Map, die vom bootparamd-Server von Sun verwendet wird.

Bei manchen Maps werden normalerweise »Spitznamen« (Nicknames) verwendet, die kürzer und darum auch einfacher einzugeben sind. Beachten Sie, daß diese Spitznamen nur von ypcat und ypmatch interpretiert werden können, zwei Tools, mit denen Sie Ihre NIS-Konfiguration prüfen können. Um eine Übersicht aller von diesen Programmen verstandenen Spitznamen zu erhalten, können Sie den folgenden Befehl ausführen:

$ ypcat -x
NIS map nickname translation table:
        "passwd" -> "passwd.byname"
        "group" -> "group.byname"
        "networks" -> "networks.byaddr"
        "hosts" -> "hosts.byname"
        "protocols" -> "protocols.bynumber"
        "services" -> "services.byname"
        "aliases" -> "mail.aliases"
        "ethers" -> "ethers.byname"
        "rpc" -> "rpc.bynumber"
        "netmasks" -> "netmasks.byaddr"
        "publickey" -> "publickey.byname"
        "netid" -> "netid.byname"
        "passwd.adjunct" -> "passwd.adjunct.byname"
        "group.adjunct" -> "group.adjunct.byname"
        "timezone" -> "timezone.byname"

Das NIS-Serverprogramm wird traditionell ypserv genannt. Bei einem durchschnittlichen Netzwerk reicht ein Server üblicherweise aus, große Netzwerke verwenden mehrere davon auf unterschiedlichen Maschinen und Segmenten des Netzwerks, um die Last der Server und Router zu verringern. Die Server werden synchronisiert, indem einer als Master-Server und die anderen als Slave-Server eingerichtet werden. Die Maps werden nur auf dem Host des Master-Servers erzeugt. Von dort aus werden sie an alle Slaves verteilt.

Wir haben uns bisher nur sehr vage über »Netzwerke« unterhalten. Tatsächlich gibt es unter NIS ein eindeutiges Konzept, das ein Netzwerk als Sammlung von Hosts definiert, die sich einen Teil ihrer System-Konfigurationsdaten über NIS teilen: die NIS-Domain. Leider haben NIS-Domains überhaupt nichts mit den Domains gemeinsam, die wir bei DNS kennengelernt haben. Um in diesem Kapitel also Verwechslungen zu vermeiden, werde ich auch immer angeben, von welchem Typ ich gerade spreche.

Eine NIS-Domain hat nur eine rein administrative Funktion. Mit Ausnahme der gemeinsamen Nutzung von Paßwörtern zwischen allen Maschinen der Domain ist sie für den Benutzer größtenteils unsichtbar. Darum ist der einer NIS-Domain vergebene Name nur für die Administratoren von Bedeutung. In der Regel kann jeder Name verwendet werden, solange er sich von anderen NIS-Domainnamen in Ihrem lokalen Netz unterscheidet. Beispielsweise könnten die Administratoren der virtuellen Brauerei sich entschließen, zwei NIS-Domains aufzubauen, eine für die Brauerei und eine für die Winzerei. Als Namen werden brewery und winery vereinbart. Ein anderes häufig verwendetes Schema ist die Verwendung des DNS-Domainnamens auch für NIS. Sie können den NIS-Domainnamen mit dem Befehl domainname setzen. Rufen Sie ihn ohne Argumente auf, wird der aktuelle NIS-Domainname ausgegeben. Wenn Sie den Namen neu setzen wollen, müssen Sie Superuser werden und folgendes eingeben:

# domainname brewery
NIS-Domains bestimmen, welchen NIS-Server eine Anwendung abfragt. Zum Beispiel sollte das login-Programm auf einem Host der Winzerei natürlich nur den NIS-Server der Winzerei (oder einen davon, falls es mehrere gibt) nach den Paßwort-Informationen des Benutzers abfragen. Eine Anwendung auf einem Host der Brauerei sollte entsprechend die Server der Brauerei verwenden.

Ein Geheimnis muß noch gelüftet werden, nämlich wie ein Client herausfindet, auf welchen Server er zugreifen muß. Die einfachste Lösung wäre eine Konfigurations-Datei, die den Namen des Host enthält, auf dem sich der Server befindet. Andererseits ist diese Lösung ziemlich unflexibel, weil sie es Clients nicht erlaubt, abhängig von ihrer Verfügbarkeit auf andere Server (innerhalb derselben Domain natürlich) zuzugreifen. Darum benötigen traditionelle NIS-Implementierungen einen speziellen Dämon namens ypbind, um den passenden NIS-Server ihrer NIS-Domain zu ermitteln. Bevor Sie also in der Lage ist, NIS-Anfragen durchzuführen, ermittelt eine Anwendung zuerst über ypbind, welcher Server zu verwenden ist.

ypbind sucht nach Servern, indem es Anforderungen an alle Stationen im lokalen IP-Netzwerk verschickt. Der erste, der antwortet, wird als der schnellste betrachtet und in allen weiteren NIS-Anfragen eingesetzt. Nach einer gewissen Zeit, oder falls der Server nicht mehr erreichbar ist, sucht ypbind erneut nach aktiven Servern.

Das Fragwürdige an dynamischer Bindung ist nur, daß sie nur selten benötigt wird und daß sie ein Sicherheitsproblem darstellt: ypbind vertraut dem Antworter blind, sei es ein einfacher NIS-Server oder ein böser Eindringling. Dies ist natürlich besonders gefährlich, wenn Sie Ihre Paßwort-Datenbanken über NIS verwalten. Um sich davor zu schützen, wird ypbind von der Linux-NIS-Bibliothek per Standardeinstellung nicht verwendet; der Hostname des Servers wird vielmehr aus einer Konfigurations-Datei gelesen.

NIS verglichen mit NIS+

NIS und NIS+ haben nur wenig mehr als den Namen und ein Ziel gemeinsam. NIS+ ist auf völlig andere Weise strukturiert. Anstelle eines flachen Namensraums mit unzusammenhängenden NIS-Domains verwendet es ähnlich wie DNS einen hierarchischen Namensraum. Statt Maps werden sogenannte Tabellen verwendet, die aus mehreren Zeilen und Spalten bestehen. Jede Zeile steht für ein Objekt in der NIS+-Datenbank, und die Spalten beschreiben die Eigenschaften der Objekte, von denen NIS+ weiß und die es verwaltet. Jede Tabelle für eine gegebene NIS+Domain umfaßt die Tabellen seiner Parent-Domains. Darüber hinaus kann jeder Eintrag in der Tabelle einen Verweis auf eine andere Tabelle enthalten. Auf diese Weise ist es möglich, Informationen auf unterschiedlichste Arten zu strukturieren.

Das traditionelle NIS verwendet die RPC-Versionsnummer 2, während NIS+ Version 3 hat. NIS+ ist bisher nicht sonderlich weit verbreitet, und ich weiß wirklich nicht besonders viel darüber. (Nun, eigentlich gar nichts.) Aus diesem Grund wird hier auch nicht weiter darauf eingegangen.

Die Client-Seite von NIS

Wenn Sie mit dem Schreiben oder Portieren von Netzwerk-Anwendungen vertraut sind, wird Ihnen aufgefallen sein, daß die meisten der oben aufgeführten NIS-Maps mit Bibliotheks-Funktionen der C-Library übereinstimmen. Um beispielsweise passwd-Informationen zu bekommen, nutzen Sie die Funktionen getpwnam und getpwuid, die die mit einem Benutzernamen oder Benutzer-ID verknüpften Account-Informationen zurückgeben. Unter normalen Umständen führen die Funktionen die erforderlichen Lookups in den Standard-Dateien wie /etc/passwd durch.

Eine Implementierung dieser Funktionen, bei der NIS berücksichtigt wird, modifiziert dieses Verhalten etwas und fügt einen RPC-Aufruf ein, damit der NIS-Server nach dem Benutzernamen oder -ID sucht. In der Anwendung wird diese Operation transparent durchgeführt. Die Funktion kann die NIS-Map entweder an die Originaldatei »anhängen« oder diese komplett »ersetzen«. Natürlich handelt es sich dabei nicht um eine wirkliche Modifizierung der Datei; es sieht für die Anwendung nur so aus, als wäre die Datei ersetzt bzw. erweitert worden.

Bei traditionellen NIS-Implementierungen gab es verschiedene Konventionen darüber, welche Maps die Original-Informationen ersetzten, und welche an sie angehängt wurden. Einige, wie beispielsweise die passwd-Maps, benötigten Modifikationen an der passwd-Datei. Wurden diese nicht korrekt durchgeführt, öffneten sich aber Sicherheitslücken. Um diesem Fallstrick zu entgehen, verwendet NYS ein allgemeines Konfigurations-Schema, das bestimmt, ob und in welcher Reihenfolge eine Reihe von Client-Funktionen die Original-, NIS- oder NIS+-Dateien verwendet. Darauf wird später in diesem Kapitel noch eingegangen.

Betrieb eines NIS-Servers

Nach so viel Theorie wird es Zeit, daß wir uns bei der eigentlichen Konfigurations-Arbeit die Hände schmutzig machen. In diesem Abschnitt wird die Konfiguration eines NIS-Servers behandelt. Läuft bereits ein NIS-Server in Ihrem Netz, müssen Sie keinen eigenen einrichten. In diesem Fall können Sie diesen Abschnitt getrost überspringen.

Wenn Sie nur ein wenig mit dem Server experimentieren wollen, müssen Sie darauf achten, daß Sie keinen NIS-Domainnamen verwenden, der in Ihrem Netzwerk bereits eingesetzt wird. Das könnte die gesamten Netzwerkdienste zum Absturz bringen und einige Leute sehr unglücklich und sehr böse machen.

Zur Zeit sind für Linux zwei NIS-Server frei verfügbar. Dies ist zum einen Tobias Rebers yps-Paket und zum anderen das ypserv-Paket von Peter Eriksson. Es spielt keine Rolle, welches Paket Sie verwenden, gleichgültig, ob Sie NYS oder den Standard NIS-Client-Kode verwenden, der in die libc integriert ist. Während dieses Buch geschrieben wird, scheint der Kode für die Behandlung von NIS-Slave-Servern bei yps vollständiger zu sein. Auf der anderen Seite löst ypserv ein bei NIS auftretendes Sicherheitsproblem (das später noch beschrieben wird), was yps nicht tut. Die Wahl hängt also von Ihren Bedürfnissen ab.

Nach der Installation des Server-Programms (ypserv) in /usr/sbin sollten Sie das Verzeichnis anlegen, in dem Sie die Map-Dateien speichern wollen, die Ihr Server verteilen soll. Beim Einrichten der NIS-Domain für die brewery-Domain würden die Maps in /var/yp/brewery untergebracht werden. Der Server prüft, ob er eine bestimmte NIS-Domain bedient, indem er nachsieht, ob ein entsprechendes Map-Verzeichnis vorhanden ist. Wenn Sie den Service für eine NIS-Domain einstellen, müssen Sie auch sicherstellen, daß das Verzeichnis entfernt wird.

Maps werden üblicherweise in DBM-Dateien gespeichert, um Lookup-Zeiten zu minimieren. Diese werden aus den Master-Dateien erzeugt, wobei ein Programm namens makedbm (für Tobias' Server) bzw. dbmload (für Peters Server) eingesetzt wird. Diese DBM-Dateien sind nicht austauschbar. Die Umwandlung einer Master-Datei in eine für dbmload verwendbare Form muß über awk oder sed erfolgen, was lästige Schreibarbeit bedeutet und nur schwer zu merken ist. Darum enthält Peter Erikssons ypserv-Paket ein Makefile (ypMakefile), das die ganze Arbeit für Sie erledigt. Sie sollten es unter dem Namen Makefile in Ihrem Map-Verzeichnis installieren und es so editieren, daß alle benötigten Maps enthalten sind. Ziemlich zu Anfang der Datei finden Sie den Eintrag all, der die Dienste aufführt, die ypserv anbieten soll. Nachfolgend die Zeile, wie Sie in der Distribution zu finden ist:

all: ethers hosts networks protocols rpc services passwd group netid
Sollen beispielsweise keine ethers.byname- und ethers.byaddr-Maps erzeugt werden, entfernen Sie einfach die Bedingung ethers aus dieser Regel. Um Ihr Setup zu testen, können Sie zuerst mit ein oder zwei Maps wie den services.*-Maps beginnen.

Nachdem Sie die entsprechenden Korrekturen am Makefile vorgenommen haben, geben Sie einfach make ein, während Sie sich im Map-Verzeichnis befinden. Die Maps werden nun automatisch generiert und installiert. Sie müssen die Maps jedesmal aktualisieren, wenn Sie die Master-Dateien verändern, weil diese Änderungen sonst für das Netzwerk nicht sichtbar sind.

Der nächste Abschnitt beschreibt die Konfiguration des NIS-Client-Kodes. Wenn Ihr Setup nicht funktioniert, sollten Sie prüfen, ob Anforderungen bei Ihrem Server eingehen oder nicht. Wenn Sie ypserv mit der Kommandozeilen-Option -debug starten, erscheinen auf dem Bildschirm Debugging-Informationen zu allen eingegangenen NIS-Anforderungen sowie zu den zurückgelieferten Resultaten. Dies sollte Ihnen einen Hinweis darauf geben, wo das Problem liegt. Tobias' Server verfügt über keine solche Option.

Sicherheit von NIS-Servern

NIS hatte eine große Sicherheitslücke: Beinahe jeder im gesamten Internet konnte Ihre Paßwort-Datei lesen, was für eine beträchtliche Anzahl möglicher Eindringlinge sorgte. Wenn ein Eindringling Ihren NIS-Domainnamen und die Adresse Ihres Servers kannte, konnte er einfach eine Anforderung an die passwd.byname-Map schicken und erhielt die gesamten Paßwörter Ihres Systems. Ausgestattet mit einem schnellen Paßwort-Knackprogramm wie crack und mit einem guten Wörterbuch ist es kaum ein Problem, die Paßwörter von zumindest einigen Benutzern zu knacken.

Aus diesem Grund wurde die securenets-Option eingeführt. Sie beschränkt den Zugriff auf Ihren NIS-Server anhand der IP-Adresse oder der Netzwerknummer auf einige wenige Hosts. Die neueste Version von ypserv implementiert dieses Feature auf sehr bequeme Weise, indem sie die Dateien /etc/hosts.allow und /etc/hosts.deny verwendet, die Sie ja bereits in Kapitel 9, Wichtige NetzwerkFeatures kennengelernt haben.(5) Um den Zugriff beispielsweise auf die Hosts innerhalb der Brauerei zu beschränken, würden deren Administratoren die folgende Zeile in hosts.allow aufnehmen:

ypserv: 172.16.2.
So können alle Hosts vom IP-Netzwerk 172.16.2.0 auf den NIS-Server zugreifen. Um alle anderen Hosts auszuschließen, müßte folgender Eintrag in hosts.deny aufgenommen werden:
ypserv: ALL
IP-Nummern sind nicht der einzige Weg, Hosts oder Netzwerke in hosts.allow und hosts.deny anzugeben. Details entnehmen Sie bitte der hosts_access(5)-Manpage Ihres Systems. Aber Vorsicht: Host- oder Domainnamen können bei ypserv-Einträgen nicht verwendet werden. Wenn Sie einen Hostnamen angeben, versucht der Server ihn aufzulösen -- aber der Resolver ruft wiederum ypserv auf, und Sie enden in einer Endlosschleife.

Sie können auch den sicheren Portmapper anstelle der securenets-Option bei ypserv verwenden. Der sichere Portmapper (portmap-3.0)(6) verwendet ebenfalls das Schema mit hosts.allow, bietet dieses aber für alle RPC-Server und nicht nur für ypserv an. Allerdings sollten Sie aufgrund des damit verbundenen Overheads die securenets-Option und den sicheren Portmapper nicht gleichzeitig verwenden.

Mit NYS einen NIS-Client einrichten

Den Rest dieses Kapitels verbringen wir mit der Konfiguration eines NIS-Client.

Im ersten Schritt sollten Sie NYS mitteilen, welcher Server für den NIS-Service verwendet werden soll. Den Namen des Servers können Sie in die Konfigurations-Datei /etc/yp.conf eintragen. Eine sehr einfache Datei für einen Host des Winzerei-Netzwerks würde wie folgt aussehen:

# yp.conf -- YP-Konfiguration für NYS-Library.
#
domainname winery
server     vbardolino
Die erste Zeile teilt Ihrem Host mit, daß er zur NIS-Domain winery gehört. Fehlt dieser Eintrag, verwendet NYS den Domainnamen, den Sie Ihrem System mit dem Befehl domainname zugewiesen haben. Die server-Zeile benennt den zu verwendenden NIS-Server. Natürlich muß die zu vbardolino gehörende IP-Adresse in hosts eingetragen sein. Alternativ können Sie auch direkt die IP-Adresse in der server-Anweisung angeben.

In der oben aufgeführten Form weist der server-Befehl NYS an, den angegebenen Server zu verwenden, unabhängig von der aktuellen NIS-Domain. Wenn Sie sich aber mit Ihrem Rechner häufig in unterschiedlichen Domains bewegen, wollen Sie die Informationen zu den verschiedenen Domains ebenfalls in Ihrer yp.conf festhalten. Sie können Informationen zu Servern verschiedener NIS-Domains in yp.conf speichern, indem Sie den NIS-Domainnamen im server-Befehl mit angeben. Für einen Laptop könnte die obige Beispieldatei etwa wie folgt aussehen:

# yp.conf -- YP-Konfiguration für NYS-Library.
#
server vbardolino winery
server vstout     brewery
Damit können Sie den Laptop in jeweils einer von beiden Domains betreiben, indem Sie die gewünschte NIS-Domain einfach mit dem Befehl domainname während der Bootphase setzen. Nachdem Sie die grundlegende Konfigurationsdatei erzeugt und sichergestellt haben, daß sie allgemein lesbar ist, sollten Sie den ersten Test durchführen, um zu prüfen, ob Sie sich an Ihren Server anbinden können. Wählen Sie eine Map wie hosts.byname, von der Sie sicher sind, daß Ihr Server sie auch verteilt, und versuchen Sie mit Hilfe des ypcat-Utilities auf sie zuzugreifen. ypcat sollte wie alle anderen administrativen NIS-Tools in /usr/sbin zu finden sein.
# ypcat hosts.byname
172.16.2.2      vbeaujolais.vbrew.com    vbeaujolais
172.16.2.3      vbardolino.vbrew.com     vbardolino
172.16.1.1      vlager.vbrew.com         vlager
172.16.2.1      vlager.vbrew.com         vlager
172.16.1.2      vstout.vbrew.com         vstout
172.16.1.3      vale.vbrew.com           vale
172.16.2.4      vchianti.vbrew.com       vchianti
Die Ausgabe sollte mit dem oben Gezeigten vergleichbar sein. Erhalten Sie statt dessen die Fehlermeldung »Can't bind to server which serves domain«, dann existiert für den von Ihnen gesetzten NIS-Domainnamen entweder kein passender Server, oder der Server ist aus irgendeinem Grund nicht erreichbar. Im letzteren Fall sollten Sie mit ping sicherstellen, daß der Host da ist. Daß auch tatsächlich ein NIS-Server auf diesem Host läuft, können Sie mit dem Befehl rpcinfo überprüfen, der Ihnen folgendes Resultat zurückliefern sollte:
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waiting

Die Wahl der richtigen Maps

Wenn Sie sicher sind, daß Sie den NIS-Server erreichen, müssen Sie entscheiden, welche Konfigurations-Dateien durch NIS-Maps ersetzt oder erweitert werden sollen. Üblicherweise wollen Sie NIS-Maps bei den Host- und Paßwort-Lookup-Funktionen benutzen. Das letztere ist besonders nützlich, wenn Sie den BIND-Service nicht verwenden. Durch den Paßwort-Lookup können sich alle Benutzer an jedem System innerhalb der NIS-Domain einloggen. Das geht normalerweise einher mit der Nutzung eines zentralen /home-Verzeichnisses zwischen allen Hosts über NFS. Die Paßwort-Map wird im nächsten Abschnitt ausführlich behandelt.

Andere Maps wie services.byname bieten Ihnen keine solch großen Möglichkeiten, sparen Ihnen aber einiges an Editierarbeit. services.byname ist besonders nützlich, wenn Sie Netzwerk-Anwendungen installieren, die einen Servicenamen verwenden, der nicht in der standardmäßigen services-Datei steht.

Normalerweise wollen Sie die Wahl haben, ob eine Lookup-Funktion die lokalen Dateien oder den NIS-Server verwendet. Bei NYS können Sie die Reihenfolge festlegen, in der auf diese Dienste zugegriffen wird. Kontrolliert wird dies durch die Datei /etc/nsswitch.conf, die für Name Service Switch steht, aber natürlich nicht nur auf den Name-Service beschränkt ist. Für jede der von NYS unterstützten Lookup-Funktionen enthält sie eine Zeile, die den Namen des zu verwendenden Dienstes enthält.

Die richtige Reihenfolge der Dienste ist vom Typ der Daten abhängig. Es ist unwahrscheinlich, daß die services.byname-Map Einträge enthält, die sich von der lokalen services-Datei unterscheiden; es kann aber sein, daß sie zusätzliche Einträge enthält. Es ist also durchaus sinnvoll, zuerst die lokalen Dateien abzufragen und NIS nur dann zu nutzen, wenn der Servicename nicht gefunden werden konnte. Andererseits können sich Informationen zu Hostnamen sehr häufig verändern, so daß DNS oder NIS die aktuellsten Informationen haben sollten, während die lokale hosts nur als Backup verwendet wird, falls DNS und NIS nicht funktionieren sollten. In diesem Fall würden Sie die lokalen Dateien also zuletzt verwenden.

Das folgende Beispiel zeigt, wie Sie gethostbyname, gethostbyaddr und getservbyname zwingen können, zuerst in NIS und DNS nachzusehen, bevor auf die lokale hosts-Datei zugegriffen wird. Die aufgeführten Dienste werden nacheinander aufgerufen. Ist eine Suche erfolgreich, wird das Ergebnis zurückgegeben, ansonsten wird der nächste Service ausprobiert.

# /etc/nsswitch.conf (ein kleines Beispiel)
#
hosts:     nis dns files
services:  files nis
Eine komplette Liste aller Dienste, die mit einem Eintrag in nsswitch.conf verwendet werden können, ist nachfolgend aufgeführt. Welche Maps, Dateien, Server und Objekte tatsächlich angefordert werden, ist vom Namen des Eintrags abhängig.
nisplus oder nis+
Benutze den NIS+-Server für diese Domain. Der Name des Servers wird aus der Datei /etc/nis.conf ermittelt.
nis
Benutze den aktuellen NIS+-Server für diese Domain. Der Name des angeforderten Servers wird, wie im vorhergehenden Abschnitt beschrieben, in yp.conf konfiguriert. Beim hosts-Eintrag werden die Maps hosts.byname und hosts.byaddr abgefragt.
dns
Benutze den DNS-Nameserver. Dieser Service-Typ ist nur zusammen mit dem hosts-Eintrag sinnvoll. Die abgefragten Name-Server werden weiter aus der Standarddatei resolv.conf ermittelt.
files
Benutze die lokale Datei, wie z. B. /etc/hosts für den hosts-Eintrag.
dbm
Suche die Informationen in DBM-Dateien im Verzeichnis /var/dbm. Der für die Datei verwendete Name ist der der entsprechenden NIS-Map.

Momentan unterstützt NYS die folgenden nsswitch.conf-Einträge: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc und ethers. Weitere werden wohl folgen.

Beispiel 10--1 zeigt ein vollständigeres Beispiel, das ein weiteres Feature von nsswitch.conf einführt. Das Schlüsselwort [NOTFOUND=return] im hosts-Eintrag weist NYS an, die Suche abzubrechen, wenn der benötigte Eintrag in der NIS- oder DNS-Datenbank nicht gefunden werden kann. Das bedeutet, daß NYS die Suche in lokalen Dateien nur aufnimmt, wenn Anforderungen an die NIS- oder DNS-Server aus einem anderen Grund fehlgeschlagen sind. Die lokalen Dateien werden dann nur während der Bootphase und als Backup (falls der NIS-Server nicht erreichbar ist) benutzt.

Beispiel 10-1. nsswitch.conf-Beispieldatei

# /etc/nsswitch.conf (Beispieldatei)
#
hosts:      nis dns [NOTFOUND=return] files
networks:   nis [NOTFOUND=return] files
services:   files nis
protocols:  files nis
rpc:        files nis

Verwendung von passwd- und group-Maps

Eine der Hauptanwendungen von NIS ist die Synchronisation von Benutzer- und Account-Informationen auf allen Hosts in einer NIS-Domain. Daher haben Sie üblicherweise nur eine kleine lokale /etc/passwd-Datei, an die die Domain-weiten Informationen aus den NIS-Maps angehängt werden. Allerdings ist die Aktivierung von NIS-Lookups für diesen Service in nsswitch.conf bei weitem nicht genug.

Wenn Sie sich auf die von NIS verteilten Paßwort-Informationen verlassen, müssen Sie zuerst sicherstellen, daß die numerischen Benutzer-IDs aller in Ihrer lokalen passwd-Datei stehenden Benutzer mit den Vorstellungen des NIS-Servers von Benutzer-IDs übereinstimmen. Sie benötigen dies auch für andere Zwecke, wie dem Mounten von NFS-Verzeichnissen von anderen Hosts in Ihrem Netzwerk.

Wenn sich numerische IDs in /etc/passwd oder /etc/group von denen in den Maps unterscheiden, müssen Sie zuerst die Besitzrechte für alle Dateien korrigieren, die diesem Benutzer gehören. Zuerst sollten Sie alle UIDs und GIDs in passwd und group auf die neuen Werte setzen, alle Dateien suchen, die den gerade geänderten Benutzern gehören, und schließlich deren Besitzrechte entsprechend ändern. Nehmen wir einfach an, news hätte die Benutzer-ID 9 und okir hätte die Benutzer-ID 103, die beide durch einen anderen Wert ersetzt wurden. Sie können dann die folgenden Befehle eingeben:

 # find / -uid   9 -print >/tmp/uid.9
 # find / -uid 103 -print >/tmp/uid.103
 # cat /tmp/uid.9   | xargs chown news
 # cat /tmp/uid.103 | xargs chown okir
Es ist wichtig, daß Sie diese Befehle mit der neu installierten passwd-Datei aufrufen und daß Sie alle Dateinamen ermitteln, deren Besitzerrechte Sie ändern. Zum Aktualisieren der Gruppen-Besitzerrechte verwenden Sie einen vergleichbaren Befehl.

Nachdem Sie dies erledigt haben, stimmen die numerischen UIDs und GIDs auf Ihrem System mit denen auf allen anderen Hosts in Ihrer NIS-Domain überein. Der nächste Schritt ist, einige Konfigurations-Zeilen in die nsswitch.conf einzutragen, die die NIS-Lookups für Benutzer- und Gruppeninformationen aktivieren:

# /etc/nsswitch.conf -- passwd and group treatment
passwd: nis files
group:  nis files
Dies hat Einfluß darauf, wo der login-Befehl und all seine Freunde nach Benutzerinformationen Ausschau halten. Versucht sich ein Benutzer einzuloggen, fragt login zuerst die NIS-Maps ab; erst wenn dies fehlschlägt, wird auf die lokalen Dateien zurückgegriffen. Üblicherweise entfernen Sie alle Benutzer aus Ihren lokalen Dateien und lassen nur Einträge für root und Accounts wie mail stehen. Der Grund dafür liegt darin, daß einige wichtige Tasks UIDs auf Benutzernamen abbilden müssen und umgekehrt. Zum Beispiel könnten administrative cron-Jobs den su-Befehl ausführen, um kurzzeitig news zu werden, oder das UUCP-Subsystem könnte einen Statusreport über E-Mail übertragen. Besitzen news und uucp keinen Eintrag in der lokalen passwd-Datei, schlagen diese Jobs während eines NIS-Ausfalls kläglich fehl.

Nun gibt es an dieser Stelle aber zwei große Vorbehalte. Zum einen funktioniert das bisher beschriebene Setup nur für Login-Suites, die keine Shadow-Paßwörter wie die aus dem util-linux-Paket benutzen. Die Komplikationen bei der Verwendung von Shadow-Paßwörtern mit NIS werden später noch behandelt. Zum anderen sind die Login-Befehle nicht die einzigen, die auf die passwd-Datei zugreifen -- sehen Sie sich den ls-Befehl an, den die meisten Leute fast dauernd benutzen. Wenn Sie ein ausführliches Inhaltsverzeichnis anfordern, gibt ls die symbolischen Namen der Benutzer- und Gruppenbesitzer einer Datei aus. Das bedeutet, daß für jede UID und GID, der ls begegnet, der NIS-Server einmal abgefragt werden muß. Das kann die Dinge ganz beträchtlich verlangsamen, wenn das lokale Netz überlastet ist. Noch schlimmer sieht es aus, wenn der NIS-Server sich nicht in demselben physikalischen Netzwerk befindet, so daß Datagramme über einen Router laufen müssen.

Aber das ist noch nicht alles. Stellen Sie sich vor, was passiert, wenn eine Benutzerin ihr Paßwort ändern möchte. Normalerweise würde sie passwd aufrufen, das das neue Paßwort einliest und die lokale passwd-Datei aktualisiert. Das ist bei NIS unmöglich, weil die Datei lokal nicht mehr vorhanden ist. Daß sich Benutzer in den NIS-Server einloggen, wenn sie das Paßwort ändern wollen, ist auch keine Lösung. NIS stellt aus diesem Grund ein Programm namens yppasswd als Ersatz für passwd bereit, das dieselbe Aufgabe übernimmt, wenn NIS präsent ist. Um das Paßwort auf dem Server-Host zu ändern, ruft es den yppasswdd-Dämon auf diesem Host über RPC auf und versorgt ihn mit der aktualisierten Paßwort-Information. Normalerweise ersetzen Sie das normale Programm durch yppasswd, beispielsweise durch die nachstehende Befehlsfolge:

# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd

Gleichzeitig müssen Sie rpc.yppasswdd auf dem Server installieren und ihn von rc.inet2 aus starten. Auf diese Weise werden die gesamten Klimmzüge von NIS vor den Benutzern versteckt.

NIS und Shadow-Paßwörter verwenden

NIS in Verbindung mit Shadow-Paßwortdateien ist eine etwas trickreiche Angelegenheit. Shadow-Paßwörter wurden eingeführt, um zu verhindern, daß normale Benutzer die Paßwörter anderer Anwender, selbst im verschlüsselten Zustand, lesen können. Andererseits zwingt NIS sie dazu, diese Paßwörter netzwerkweit verfügbar sind, was dem ursprünglichen Zweck von Shadow-Paßwörtern natürlich völlig entgegenläuft.

Momentan gibt es unter Linux keine wirkliche Lösung für dieses Dilemma. Der einzige Weg, Paßwort- und Benutzerinformationen über NIS zu verteilen, sind die Standard-passwd.*-Maps. Wenn Sie Shadow-Paßwörter installiert haben, besteht die einfachste Möglichkeit der gemeinsamen Nutzung darin, eine ordentliche passwd-Datei aus /etc/shadow zu erzeugen (mit Tools wie pwuncov) und aus dieser Datei die entsprechenden NIS-Maps aufzubauen.

Natürlich gibt es einige Hacks, um NIS und Shadow-Paßwörter zur selben Zeit zu verwenden, beispielsweise indem Sie eine /etc/shadow-Datei auf jedem Host im Netzwerk installieren, während die Benutzer-IDs etc. über NIS verteilt werden. Es ist natürlich unnötig zu erwähnen, daß diese Vorgehensweise ziemlich rüde ist und dem Ziel von NIS, die Systemadministration zu vereinfachen, völlig entgegenläuft. Meiner Meinung nach ist der Grundsatz, Benutzer dazu anzuhalten »gute« Paßwörter zu verwenden, wesentlich besser, als die Paßworte in zusätzlichen Dateien zu verstecken, die zu Kompatibilitäts-Problemen führen.

Den traditionellen NIS-Kode verwenden

Wenn Sie den Client-Kode verwenden, der momentan in der Standard-libc enthalten ist, läuft die Konfiguration eines NIS-Client etwas anders ab. Zuerst unterstützt der traditionelle Kode nur Maps für hosts-, passwd- und group-Lookups. Auch die Art und Weise, wie Informationen aus lokalen Dateien mit denen der NIS-Maps kombiniert werden, unterscheidet sich stark von dem bei NYS verwendeten Schema.

Um beispielsweise die NIS-Paßwortmaps zu verwenden, müssen Sie die folgende Zeile irgendwo in Ihrer /etc/passwd-Map eintragen:

 +:*:0:0:::
Dies markiert die Stelle, an der die Paßwort-Lookup-Funktionen die NIS-Maps »einfügen«. Das Einfügen einer ähnlichen Zeile (ohne die letzten beiden Doppelpunkte) in /etc/group erledigt dasselbe für die group.*-Maps.

Um die verschiedenen von Ihrem YP-Server angebotenen hosts.*-Maps zu nutzen, ändern Sie die order-Zeile in Ihrer host.conf-Datei. Wollen Sie z. B. etwa NIS, DNS und die Datei /etc/hosts (in dieser Reihenfolge) verwenden, müssen Sie die Zeile wie folgt ändern:

order yp bind hosts
Anders als bei NYS ist der traditionelle YP-Kode vom ypbind-Dämon abhängig, um einen aktiven Server für die YP-Clients zu ermitteln. ypbind muß während der Bootphase gestartet werden, nachdem die NIS-Domain gesetzt und der RPC-Portmapper aktiviert wurde.

Bis vor kurzem suchte ypbind über RPC-Broadcasts nach Servern. Wie bereits früher angesprochen, ist diese Vorgehensweise ziemlich unsicher. Darum besitzt die neueste Version der YP-Tools (aus der yp-linux-Distribution) nun einen ypbind-Dämon, der auch die Konfigurations-Datei /etc/yp.conf unterstützt. Existiert diese Datei, wird sie nach einer oder mehreren Zeilen durchsucht, die in etwa wie folgt aussehen:

# yp.conf -- benenne YP-Server für ypbind.
ypserver      vbardolino
ypbind überprüft dann die benannten Hosts nach aktiven Servern.(7) Wenn ypbind keine yp.conf-Datei findet oder wenn keiner der genannten Server antwortet, greift es auf die althergebrachte Methode zurück und sendet RPC-Broadcasts.

Vor kurzem gab es zahlreiche Bugreports, die sich damit beschäftigten, daß NIS bei einem Fehlversuch die folgende Fehlermeldung zurückliefert:

clntudp_create: RPC: portmapper failure -- RPC: unable to receive
Dies rührt von einer inkompatiblen Art des Formats her, in dem ypbind die Bindungs-Informationen an die Bibliotheks-Funktionen durchreicht. Besorgen Sie sich die neuesten Quellen der NIS-Utilities und kompilieren Sie sie, dann sollte dieses Problem behoben sein.(8)

Fußnoten

(1)
Swen kann über swen@uni-paderborn.de erreicht werden. Die NIS-Clients sind als yp-linux.tar.gz von sunsite.unc.edu unter system/Network verfügbar.
(2)
Die aktuelle Version (während dieses Buch geschrieben wurde) ist yps-0.21 und kann von ftp.lysator.liu.se aus dem Verzeichnis /pub/NYS heruntergeladen werden.
(3)
Zu erreichen unter pen@lysator.liu.se.
(4)
DBM ist eine einfache Datenbank-Verwaltungsbibliothek, die eine Hash-Technik verwendet, um Suchoperationen zu beschleunigen. Vom GNU-Projekt gibt es eine freie DBM-Implementierung namens gdbm, die Teil der meisten Linux-Distributionen ist.
(5)
Um diese Option zu aktivieren, müssen Sie den Server neu kompilieren. Bitte lesen Sie die entsprechenden Anweisungen in der der Distribution beiliegenden README-Datei.Um diese Option zu aktivieren, müssen Sie den Server neu kompilieren. Bitte lesen Sie die entsprechenden Anweisungen in der der Distribution beiliegenden README-Datei.
(6)
Verfügbar über anonymous FTP von sunsite.unc.edu unter dem Verzeichnis Linux/systems/Network.
(7)
Beachten Sie, daß das zur Angabe des Servernamens verwendete Schlüsselwort nicht mit dem von NYS übereinstimmt.
(8)
Die Quellen für yp-linux können von ftp.uni-paderborn.de aus dem Verzeichnis /pub/Linux/LOCAL heruntergeladen werden.

Inhaltsverzeichnis Kapitel 9 Kapitel 11