Einführung in den Network-Information-Service (NIS)

  Eines der Hauptziele bei verteilten Rechensystemen ist es, daß ein Benutzer unabhänging vom Rechner, an dem er sich anmeldet, immer die gleiche Arbeitsumgebung vorfindet. In einem heterogenen Netz von UNIX-Workstations genügt es hierfür nicht, daß der Benutzer auf jeder Maschine die gleiche Kennung besitzt. Es muß außerdem sichergestellt werden, daß er von jeder Maschine Zugriff auf andere Rechner im Netz hat und die gewohnten Dienste und Anwendungen nutzen kann.

Unter UNIX sind hierfür gemeinsame, einheitliche Konfigurationsdateien für Kennungen (/etc/passwd), Benutzergruppen (/etc/group) oder Dienste (/etc/services) erforderlich, von denen jeder Rechner im Netz eine Kopie besitzt. Die Wartung dieser Dateien stellt in einem größeren Netz ein ernstes Problem dar. Änderungen, wie das Einrichten einer neuen Benutzerkennung oder das Entfernen eines Rechners aus dem Netz, erfordern eine konsistente Modifikation der Konfigurationsdateien auf jeder Workstation im Netz. Aufgrund dieser Problematik hat Sun Microsystems, Inc. den Network Information Service entwickelt.

NIS ersetzt die Kopien der Konfigurationsdateien auf jedem Rechner durch einen Verzeichnisdienst, der die Information aus den Dateien jedem teilnehmenden Rechner zur Verfügung stellt. Für jede Konfigurationsdatei existiert eine Datenbank auf einem zentralen Server. Änderungen an der Konfiguration werden ausschließlich in der Datenbank auf dem Server durchgeführt und sind anschließend sofort für jeden NIS-Client sichtbar. Das Anlegen eines neuen Benutzers erfordert somit nur einen neuen Eintrag in der Datenbank für die Datei /etc/passwd anstatt der Änderung der Paßwortdatei auf jedem Rechner. Eine detaillierte Einführung in NIS findet sich in [Ste91].

Bei NIS handelt es sich ebenfalls um einen Systemdienst nach dem Client/Server-Prinzip. Er basiert genau wie NFS auf dem RPC-Mechanismus und benutzt UDP als Transportprotokoll. Findet ein Client eine benötigte Information nicht in seiner lokalen Datei, befragt er über einen RPC-Auftrag den NIS-Server. Dieser greift auf die entsprechende Datenbank (map) zu und sendet das Ergebnis als Antwort. Die Verfügbarkeit des Dienstes muß außerordentlich hoch sein, da die von NIS bereitgestellte Konfigurationsinformation essentiell für den Betrieb der Clients ist. Da auf die Information mancher Maps oft zugegriffen wird, hat ein NIS-Server in einem Netz mit vielen Clients eine hohe Last zu verkraften. Aus diesen beiden Gründen werden neben dem Master-Server ein oder mehrere Slave-Server betrieben. Slave-Server besitzen Kopien der Maps des NIS-Masters und haben nur die Aufgabe, Anfragen von Clients zu beantworten. Die Verwaltung und Aktualisierung der Datenbanken wird weiterhin ausschließlich auf dem Master-Server durchgeführt. Nach Änderung einer Map auf dem Master, muß diese zur Sicherstellung der Konsistenz explizit an alle Slaves verteilt (push) werden. Abbildung 3.4 zeigt die Beziehungen zwischen Master, Slaves und Clients.

 

Abbildung 3.4:  Master, Slaves und Clients bei NIS

11#11

Die Rechner eines Clusters können bezüglich der Administration und Konfiguration in unterschiedliche Domänen eingeteilt werden. Eine Domäne ist eine Menge von NIS-Maps und wird durch den Domänennamen (domain name) eindeutig beschrieben. Anschaulicher, wenn auch nicht ganz korrekt, ist eine Domäne eine Gruppe von Rechnern, die sich einen Satz NIS-Maps teilen. Das bedeutet, daß ein Client im Normalfall nur zu einer Domäne gehört, aus deren NIS-Datenbanken er alle benötigten Konfigurationsinformationen bezieht. Ein Master-Server ist ,,Eigentümer`` der Maps einer Domäne. Da eine Verwaltung mehrerer unterschliedlicher Map-Sätze nicht vorgesehen ist, kann ein Master-Server diese Rolle nur für eine Domäne übernehmen. Theoretisch kann ein Slave-Server Anfragen zu mehreren Domänen bearbeiten. Dieser Fall ist aber in der Praxis eher selten. Für die weitere Betrachtung des Dienstes in dieser Arbeit werden daher folgende, die Allgemeinheit nur unwesentlich einschränkende Vereinbarungen getroffen. Master- und Slave-Server stellen den NIS-Dienst für genau eine Domäne zur Verfügung. Ein Client wird per Default an mindestens eine Domäne gebunden, von der er alle für den Betrieb des Systems benötigten Informationen beziehen kann. Spezielle Anwendungen können den Client veranlassen, eine Bindung zu einer weiteren Domäne einzugehen.

Auf dem Master liegen die Konfigurationsdateien weiterhin im ASCII-Format vor. Ein spezielles Werkzeug (makedbm) transformiert eine ASCII-Datei in eine Map im DBM-Format. Da diese Dateien einfach indiziert sind, kann auf sie nur über einen Schlüssel zugegriffen werden. Jeder Map-Eintrag ist daher ein Tupel («key», «information»). Zu einigen Dateien gibt es daher mehrere Maps, die die gleiche Information enthalten aber unterschiedlich indiziert sind. Zur Datei /etc/passwd existieren beispielsweise die Maps passwd.byname mit dem Schlüssel Benutzername und passwd.byuid mit dem Schlüssel User-ID. Einige NIS-Maps ersetzen die entsprechende lokale Datei auf dem Client völlig, andere erweitern nur die lokale Datei durch die Einträge der Map. Der Server stellt RPC-Prozeduren zum sequentiellen Durchlauf aller Einträge einer Map (yp_get_first(), yp_get_next()) sowie zum gezielten Suchen eines Eintrags über den Schlüssel (yp_match()) bereit. Hierzu gibt es auch die Kommandozeilen-Tools ypcat und ypmatch. Für Anwendungen auf dem Client ist der Einsatz von NIS transparent, da NIS die UNIX-Systemaufrufe, die normalerweise aus den Konfigurationsdateien lesen, entsprechend modifiziert.