Network Information System

Das Network Information System ist ein Verzeichnisdienst, der die Benutzung bestimmter Konfigurationsdateien von verschiedenen Rechnern aus ermöglicht. Insbesondere in Verbindung mit dem Network File System wird NIS verwendet, um Benutzern netzwerkweit dieselbe Umgebung zur Verfügung zu stellen. Eine ausführliche Darstellung zu den Möglichkeiten des NIS und einen historischen Abriss findet der interessierte Leser im Abschnitt über den NIS-Server.

Die notwendigen Programme zur Administration eines Clients sind ypbind, yppoll und ypset. Zur Arbeit über NIS stehen die Kommandos ypcat, ypchfn, ypchsh, ypmatch, yppasswd und ypwhich zur Verfügung und sollten nach Installation des entsprechenden Paketes (ein typischer Paketname lautet »ypclient...«) im Verzeichnis »/usr/sbin« (die 3 ersten Kommandos) bzw. »/usr/bin« vorhanden sein.

Da es sich beim Network Information Service um einen RPC-Dienst handelt, ist ein aktiver Portmapper erforderlich. Wie dieser zu starten ist, sollte aus dem entsprechenden Abschnitt zum Remote Procedure Call bereits bekannt sein.

Jeder NIS-Client ist einer so genannten NIS-Domain zugeteilt. Und zu jeder NIS-Domain existiert mindestens ein Server, der die Datenbanken für seinen Verantwortungsbereich verwaltet und auf Anfragen der Clients antwortet. Innerhalb eines Netzwerkes können mehrere NIS-Domänen unabhängig voneinander existieren und ein einzelner Server kann mehrere Domänen verwalten.

Damit ein Client weiß, welcher NIS-Domain er zugehört, muss ihm diese vorab bekannt gegeben werden:

Dieser Domainname hat nichts mit dem Internet-Domainnamen zu tun! Er könnte durchaus gleich lauten, ohne dass zwischen beiden eine Wechselwirkung bestehen würde. Der Systemverwalter hat jederzeit das Recht, den eigenen Rechner einer anderen NIS-Domain zuzuordnen.

»Name Service Switch« bezeichnet einen Mechanismus, nachdem symbolische Rechnernamen in Adressen und umgekehrt umgewandelt werden. Linux übernahm das Vorgehen einer Lösung von SUN, wobei der Name der Datei nicht exakt den Kern trifft, denn /etc/nsswitch.conf konfiguriert weit mehr als die bloße Gewinnung von Rechnernamen und -adressen.

Einem NIS-Client stehen prinzipiell mehrere Wege offen, wie er an eine Information wie bspw. an die IP-Adresse zu einem symbolischen Rechnernamen gelangen kann. Er könnte den NIS-Server konsultieren oder aber auch die lokale Datei /etc/hosts durchforsten. Und auch eine direkte Anfrage an einen DNS-Server ist denkbar. Für welchen Weg er sich letztlich entscheidet, ist in der Datei »/etc/nsswitch.conf« beschrieben:

Der erste Eintrag einer Zeile ist der Name der betreffenden Datenbank. Er deckt sich mit den Namen der lokalen Konfigurationsdatei, womit sein Zweck klar sein sollte. Dem Doppelpunkt folgen die Mechanismen, die, in gegebener Reihenfolge, angewandt werden, um eine Information aus der betreffenden Datenbank zu gewinnen. Liefert ein Versuch kein Ergebnis, wird in der Voreinstellung das nächste Verfahren versucht.

Rechnernamen bzw. IP-Adressen zuerst in der lokalen Datei /etc/hosts gesucht (»files«) und nur wenn dort ein entsprechender Eintrag fehlt, wird der Domain Name Service (»dns«) bemüht. »dns« darf einzig in Zusammenhang mit »hosts« verwendet werden.

Informationen zu »services« und »protocols« werden laut obiger Konfiguration einzig durch die jeweiligen lokalen Dateien bereitgestellt. Auch dies ist typisch für Dateien statischer Natur (deren Inhalt sich i.d.R. niemals ändert).

Eine Befragung des NIS-Servers findet in obiger Konfiguration nur für Informationen aus »passwd«, »shadow« und »group« statt. Als Antwort auf eine Anfrage sind SUCCESS bei Erfolg, NOTFOUND, falls keine entsprechende Information gefunden wurde, UNAVAIL, falls der Dienst generell, und TRYAGAIN, falls der Dienst temporär nicht erreichbar ist (bspw. bei dessen Überlastung), möglich. Die Semantik für SUCCESS ist, dass die Befragung endet (»return«). Für alle weiteren Antworten ist das Fortfahren mit Befragung des nächsten konfigurierten Mechanismus die Voreinstellung (»continue«). In

modifizieren wir das Vorgehen dahingehend, dass eine Anfrage als gescheitert gilt, wenn der NIS-Server den gewünschten Eintrag nicht findet. »[NOTFOUND=return]« ist zu lesen als »Antwortet NIS mit »NOTFOUND«, dann kehre zurück (»return«)" (und schaue nicht mehr in den lokalen Dateien nach). Der Sinn? Ein Rechner könnte so eingerichtet werden, dass sich einige Benutzer selbst dann anmelden können, wenn der NIS-Server ausgefallen ist (Root sollte das stets können!). Bei aktivem Server sind für solche Benutzer jedoch die Informationen des Servers bindend.

Die letzte Option compat steuert nicht die Reihenfolge der Befragung, sondern aktiviert die Auswertung einer erweiterten Syntax in den Datenbanken »passwd«, »shadow« und »group«. Auf diese weiter gehenden Konfigurationsmöglichkeiten kommen wir weiter unten im Text zurück.

Handelt es sich bei dem Client um ein älteres System, das noch auf der C-Bibliothek »libc5« (oder gar 4) basiert, spielt die Datei /etc/nsswitch.conf für NIS gar keine Rolle. Womöglich existiert sie nicht einmal.

Bei derartigen Clients ist einzig die Auflösung von Rechnernamen und IP-Adressen zu konfigurieren, wenn sie auch über NIS geschehen soll. Der Resolver der alten C-Bibliothek wird über die Datei /etc/host.conf gesteuert.

Der einzig für NIS relevante Eintrag betrifft die Ergänzung der mit »order« eingeleiteten Zeile um das Schlüsselwort nis:

Die Zeile im Beispiel legt fest, dass zunächst in der lokalen Datei »/etc/hosts« nachgeschaut wird (»hosts«). Schlägt die lokale Suche fehl, wird NIS befragt (»nis«) und bei negativen Bescheid von diesem wird letztlich der DNS konsultiert (»bind«; alternativ könnte hier auch »dns« stehen).

Der NIS-Client wird durch Aufruf des Kommandos ypbind gestartet, wobei er den Namen des NIS-Servers in Erfahrung bringen muss, um ihn zu kontaktieren. Zwei Wege stehen einem Client hierfür zur Verfügung:

Serversuche per Broadcast

Den geringsten administrativen Aufwand erfordert die Suche eines für die NIS-Domain zuständigen Servers via Broadcast, d.h. der Client sendet eine Anfrage ins Netz mit der Bitte, ein verantwortlicher NIS-Server möge sich melden. Hierfür genügt die Angabe der entsprechenden Option beim Aufruf von ypbind:

Sind mehrere NIS-Server für eine Domain konfiguriert (ein Master, mehrere Slaves), so sollte jeder der Server auf die Anfrage reagieren. Der Client wird sich bei weiteren Anfragen allerdings stets an den Server wenden, vom dem die Antwort zuerst eintraf.

Die Broadcast-Methode sollten Sie nur in Netzwerken verwenden, die vollständig unter Ihrer Kontrolle sind, denn es ist ein Leichtes, einen fingierten NIS-Server aufzusetzen...

Serverspezifikation per Konfigurationsdatei

Das Kommando ypbind liest beim Start seine Konfigurationsdatei /etc/yp.conf ein. Sie wird verwendet, um das Vorgehen der Kontaktaufnahme zu einem NIS-Server einer Domain festzuschreiben.

Im einfachsten Fall wird eine Datei »/etc/yp.conf« Einträge folgender Art umfassen:

Die Beispielkonfiguration benennt drei NIS-Server für die lokale Domain (also die, die zuvor per »domainname« gesetzt wurde). ypbind setzt gleichzeitig eine Anfrage an alle drei Server ab und der, der zuerst antwortet, wird zum Server für den Client.

Für unterschiedliche NIS-Domains werden die Server angegeben. Es sind mehrere Angaben zu einer Domain zulässig. Durch eine solche Konfiguration kann ein Client seine Mitgliedschaft zu einer Domain ändern, zu einem Zeitpunkt kann er jedoch nur einer Domain angehören!

Ein NIS-Server für die Domain »nis.galaxis.de« wird per Broadcast ermittelt. Ein solcher Eintrag hat Vorrang vor einer Zeile, die einen konkreten Server für eine Domain benennt.

Die Arbeitsweise von ypbind

Bislang könnte der Eindruck entstanden sein, »ypbind« ist der NIS-Client. Dem ist nicht so, genau genommen existiert kein Clientprogramm sondern ein Rechner ist ein NIS-Client, wenn er Funktionen der Standard-C-Bibliothek aufruft, welche sich der NIS-Funktionalität bedienen. Solche Funktionen erfordern Informationen über die Bindung an einen NIS-Server, den sie letztlich kontaktieren, und jene Informationen liefert »ypbind«. Das Kommando ist somit die zentrale Instanz eines NIS-Clients.

Wenn »ypbind« startet, sucht es zunächst nach einem Server für die gesetzte NIS-Domain. Die Broadcast-Option der Kommandozeile genießt dabei Vorrang vor der Konfiguration der Datei »/etc/yp.conf«. Nach erfolgreicher Bindung an einen Server, sendet »ypbind« alle 20 Sekunden eine YPPROC-DOMAIN-Anforderung an den Server, um dessen Aktivität zu überprüfen. Antwortet der Server nicht oder meldet er, dass er für die Domain nicht länger zuständig ist, so sucht »ypbind« selbsttätig nach einem anderen Server (Broadcast oder gemäß Konfiguration in »/etc/yp.conf«). In 15-Minuten-Intervallen testet »ypbind«, ob ein anderer konfigurierter Server eventuell schneller antwortet als der aktuell gebundene. Falls ja, wechselt »ypbind« die Bindung zum neuen Server.

Die Optionen von ypbind

Neben »broadcast« versteht »ypbind» eine Reihe weiterer Kommandozeilenoptionen (Auswahl):

-c

»ypbind« prüft die Syntax der Datei »/etc/yp.conf« und endet anschließend.

-d | --debug

Start im Debug-Modus; nützlich bei der Fehlersuche.

-broadcast

Ein NIS-Server wird per Broadcast gesucht.

-no-ping

Die Überprüfung, ob der NIS-Server noch antwortet, wird abgeschaltet. Die Option ist bei Modemverbindungen sinnvoll, um eine permanente Einwahl zu verhindern.

-f <Konfigurationsdatei>

»ypbind« verwendet die angegebene Konfigurationsdatei anstatt »/etc/yp.conf«.

-p <Port>

»ypbind« verwendet den angegebenen Port; im Zusammenhang mit Firewalls hilfreich.

-ypset

Erlaubt das dynamische Ändern des zu verwendenden NIS-Servers durch Administratoren anderer Rechner (siehe »Konfiguration zur Laufzeit«).

-ypsetme

Erlaubt das dynamische Ändern des zu verwendenden NIS-Servers nur durch den Administrator des lokalen Rechners (siehe »Konfiguration zur Laufzeit«).

Ein einfacher Test

Nach obigen Anpassungen und (Neu)Start von »ypbind« kann eine Überprüfung nicht schaden, ob die Verbindung zu einem NIS-Server steht. Bemühen Sie zunächst das Kommando ypwhich, um zu erfahren, zu welchem NIS-Server die Bindung besteht:

Ob auch die Dateien korrekt dargeboten werden, erfahren Sie, indem Sie eine Liste der Nicknamen aller exportierter Datenbanken anfordern:

Konfiguration zur Laufzeit

ypbind nimmt beim Start Kontakt zu einem für die NIS-Domain zuständigen NIS-Server auf und hält die Bindung zu diesem aufrecht, bis entweder der Server ausfällt oder im Zuge der Reaktionszeittests ein anderer Server schneller antwortet und damit den Zuschlag erhält.

Das Kommando, um »ypbind« explizit einen neuen Server unterzuschieben, ist ypset. Mit

wird »melmac« zum neuen NIS-Server für den Client »sonne«, allerdings nur, wenn »ypbind« tatsächlich eine Verbindung zu diesem herstellen konnte. Ansonsten begibt sich »ypbind« nach den schon bekannten Regeln auf die Suche nach einem gültigen Server.

Um den Server einer anderen als der lokal konfigurierten NIS-Domain zu setzen, ist diese Domain anzugeben:

Schließlich kann auch der Rechnername angegeben werden, falls die Änderung auf einem anderen als dem lokalen Rechner vollzogen werden soll (dann muss das dortige »ypbind« aber mit der Option »-ypset« gestartet worden sein):

Für Linuxsysteme, die auf früheren Versionen der Standard-C-Bibliothek basieren (libc4 und 5), ist die Datei /etc/passwd zu modifzieren, um Benutzerkonten vom NIS-Server verwenden zu können. Für die aktuellen Versionen der glibc2-Bibliothek kommen Anpassungen an den Dateien /etc/shadow und /etc/group hinzu.

Datenimport ohne lokale Zugangskontrolle

Um die Datensätze der oben genannten Dateien unverändert vom Server zu übernehmen, genügt das Einfügen einer Zeile mit einem Pluszeichen in obige Dateien:

Beachten Sie, dass »normale« Zeilen, die solchen NIS-Einträgen folgen, keine Beachtung mehr finden, d.h. NIS-Datensätze sollten stets am Ende der Dateien angefügt werden.

Bei Verwendung der Standard-C-Bibliotheken der Versionen 4 und 5 müssen dem Pluszeichens 6 Doppelpunkte folgen:

Der Grund für diese Syntax liegt in der steten Verwendung des Compat-Modus durch die alten C-Bibltiotheken (siehe nächster Abschnitt).

Datenimport mit lokaler Zugangskontrolle (Compat-Modus)

Die beschriebenen Mechanismen funktionieren mit der Standard-C-Bibliothek »glibc2« nur, wenn die korrespondierenden Einträge in der Datei nsswitch.conf das Schlüsselwort compat enthalten.

Benutzerinformationen sind sensible Informationen und die netzwerkweite Allgemeingültigkeit aller Parameter ist nicht in jedem Fall erwünscht oder sinnvoll. Z.B. könnte auf einem bestimmten Rechner nur eine konkrete Shell installiert sein. Sollte dennoch jeder auf dem NIS-Server eingetragene Benutzer sich dort anmelden dürfen, sollte sicher gestellt sein, dass auch diese Shell als Loginshell gesetzt ist - unabhängig von der Einstellungen in der NIS-Datenbank. Auch kollidierende Benutzer-/Gruppen-IDs lassen sich lokal korrigieren. Und im Sinne der Sicherheit enorm wichtig: Bestimmten Benutzern kann explizit der Zugang verwehrt werden.

Beginnen wir mit dem Sperren eines Zugangs. Dazu ist in die lokale Datei /etc/passwd der Benutzername mit einem vorangestellten Minuszeichen aufzunehmen:

Eine andere Variante, das Anmelden eines Benutzers zu unterbinden, ist die Vergabe eines ungültigen Passworts, womit wir ein erstes Beispiel haben, wie ein vom Server gelieferter Wert lokal überschrieben werden kann:

In obigen Beispielen ermöglichen wir durch die abschließende Zeile mit dem einzelnen Pluszeichen, das sämtliche Benutzer, die nicht zuvor explizit erwähnt wurden, unverändert vom NIS-Server übernommen werden. Wenn Sie auf letztere Zeile verzichten, erhalten demzufolge nur die zuvor aufgeführten Benutzer Zugang zum lokalen System.

Auf einem Mailserver muss zwar zu jedem Mailkonto dessen Benutzer eingetragen sein, dessen Anmeldung ist jedoch zumeist unerwünscht. Um nun allen auf dem NIS-Server eingetragenen Benutzern zwar das Mailkonto einzurichten, das Login zu verwehren, wird auf dem Mailserver (als NIS-Client) die Login-Shell auf »/bin/false« gesetzt:

Bislang galten Einstellungen für einen einzelnen Benutzer (+alf::::::) oder für alle Benutzer (+::::::). Flexibler ist das Schema durch Verwendung von Netzgruppen. Eine solche wird durch ein vorangestelltes »@« gekennzeichnet. Sie muss in der Datei netgroup konfiguriert sein:

Etliche Programme arbeiten im Verborgenen mit den NIS-Mechanismen zusammen, ohne dass der Benutzer dies merkt. So offenbart »login« niemandem, ob eine Benutzerauthentifizierung lokal oder über NIS erfolgt. Und auch die zahlreichen Netzwerkprogramme halten sich mit Hinweisen bedeckt, wie eine Rechneradresse gewonnen wurde.

Doch nicht alle Programme können von sich aus entscheiden, ob sie Aktionen via NIS oder über lokale Funktionen erledigen sollen. Wünscht ein Benutzer bspw. sein Passwort zu ändern, so wäre das lokal als auch auf dem NIS-Server denkbar. Bei ersterem beträfe die Änderung einzig die Anmeldung am Client-Rechner, bei letzterem gelte das Passwort fortan auf allen NIS-Clients.

Die »Arbeitsprogramme«

Genau genommen handelt es sich um ein einziges Programm, das entweder durch Optionen oder durch Aufruf unter anderen Namen die Funktionen verschiedener lokaler Programme übernimmt.

yppasswd ist dabei das eigentliche Programm, das, wie der Name schon andeutet, zum Setzen des Passwortes in der NIS-Datenbank dient.

Beachten Sie, dass das neue Passwort erst wirksam wird, nachdem auf dem NIS-Server die NIS-Maps aktualisiert wurden.

Mit der Option -f arbeitet »yppasswd» wie ypchfn, womit das so genannte GECOS-Feld modifiziert wird:

Die Änderungen wurden abgewiesen? Dann hat Ihr Administrator - aus welchen Gründen auch immer - die Modifikation des Feldes unterbunden, indem er beim Start des zuständigen Daemons rpc.yppasswdd auf die Option »-e chfn« verzichtete.

Mit der Option -l arbeitet »yppasswd» wie ypchsh, womit die Login-Shell des Benutzers konfiguriert werden kann. Auch hierzu muss der Server-Administrator den Daemon rpc.yppasswdd mittels der Option »-e chsh« dazu ermächtigt haben.

Das Beispiel offenbart eine häufige Schwäche der Internationalisierung von Linux: Die unvollständige Übersetzung der Begleittexte. Aber das soll uns hier nicht weiter stören.
Wichtig beim Ändern der Shell ist, dass Sie diese unbedingt mit vollständigem Pfad angeben; sonst wird Ihnen das Anmelden mit dem nächsten Versuch nicht mehr möglich sein (weil die PATH-Variable der Shell noch nicht existiert).

Die Option »-p« von »yppasswd» ist eigentlich überflüssig, da die damit erzwungene Änderung der Passwortes ohnehin die Voreinstellung ist.

Der Administrator hat die Möglichkeit, durch Angabe des Benutzernamens als Kommadozeilenoption von »yppasswd», »ypchfn» bzw. »ypchsh», den jeweilgen Parameter eines jeden Benutzers zu ändern.

Die Diagnoseprogramme

Einige der hier vorgestellten Programme begegneten Ihnen bereits im Laufe des Abschnitts. Sie werden i.d.R. nur während des Einrichtens von Client und Server benötigt, um deren korrekte Arbeit zu überprüfen.

ypcat ermöglicht das Betrachten der Inhalte von Maps. Zwingend anzugeben ist der Name der Map, womit sie in der aktuellen NIS-Domain gesucht wird. Mit »-d Domain« kann die Map einer jeden anderen NIS-Domain betrachtet werden (sofern der NIS-Client die Rechte dazu besitzt).

Da zu einer NIS-Datenbank oft mehrere Maps mit verschiedenen Suchschlüsseln existieren, wird häufig für die gebrächlichste ein kurzer Aliasname gewälht (Bspw. wird die Passwortdatei nach Benutzerkennzeichen »passwd.byname« und nach Benutzer-IDs »passwd.byuid« sortiert gespeichert. Der Alias »passwd« verweist auf »passwd.byname«.). Welche Aliasse existieren, verrät »ypcat -x«.

Denkbar (aber unüblich) sind Konfigurationen, in denen ein Aliasname gleich einem konkreten Mapnamen lautet. Um eine solche Map dennoch betrachten zu können, ist die Option »-t« erforderlich, die die Aliasbindungen unterdrückt.

Die Option »-k« schreibt nochmals den Schlüsselwert explizit vor jeden Datensatz.

Im Unterschied zu »ypcat« beschränkt ypmatch die Auflistung auf die Datensätze, die mit den angegebenen Suchschlüsseln (auch mehrere) in der Map übereinstimmen. Die Optionen besitzen dieselbe Bedeutung wie unter »ypcat« beschrieben.

yppoll zeigt die Version und den Namen des NIS-Servers zu der angegebenen Map an. Mit »-h Rechner« kann ein konkreter Server benannt werden. Ohne diese Option wird der Server, den »ypwhich« liefert, befragt. Mit »-d Domain« werden die Informationen zu angegebenen anstatt zur aktuellen NIS-Domain geliefert. Als Mapname werden keine Aliase akzeptiert.

ypwhich zeigt den zuständigen NIS-Server an. Die Optionen »-d Domain«, »-t« und »-x« besitzen dieselbe Bedeutung wie beim Kommando »ypcat« beschrieben.

Wird ein Mapname angegeben (Option »-m [Mapname]«), liefert »ypwhich« den Namen des Servers, der diese Map anbietet. Bei alleiniger Angabe von »-m« erhalten Sie eine Auflistung für alle existierenden Maps.

Ein Rechnername auf der Kommandozeile bewirkt, dass die Anfrage von diesem Rechner aus gestellt wird, d.h. die Frage lautet: »Welcher NIS-Server ist für diesen Rechner zuständig?«.

In der Voreinstellung wird nach dem NIS-Server gefahndet, der das NIS-Protokoll der Version 2 unterstützt. Mit »-V1« fragen sie nach dem zuständigen NIS-Server der Version 1 (unter Linux unterstützen die bekannten Implementierungen beide Versionen, sodass Sie dieselbe Antwort erhalten werden).

Administrative Programme

Bereits ausführlich diskutiert wurden die Kommandos domainname zum Setzen des NIS-Domainnamens und ypbind, das die Bindung zum NIS-Server herstellt und überwacht. Fehlt noch die Beschreibung zu ypset, das »ypbind« anweist, sich an einen konkreten NIS-Server zu binden. Das klappt jedoch nur, wenn »ypbind« mit der Option »-ypset« (bzw. »-ypsetme«) gestartet wurde.

Bei alleiniger Angabe des NIS-Servers werden als Domainname die aktuelle NIS-Domain und als Rechnername der aufrufende Clientrechner angenommen. Bevor »ypbind« tatsächlich die aktuelle Bindung wechselt, wird überprüft, ob der neue NIS-Server erreichbar ist:

Im Beispiel ist auf dem angegebenen Rechner kein NIS-Server aktiv. Die alte Bindung von »ypbind« bleibt erhalten.

Mit der Option »-d Domain« wird die Bindung zu einem Server für die angegebene NIS-Domain vorgenommen; mit »-h Rechnername« betrifft dies den ypbind-Prozess auf dem angegebenen Rechner. Jener muss zwingend mit der Option »-ypset« gestartet worden sein.

Network Information System - Der Client