8.5 NIS/NIS+ 
Benutzerverwaltung im Netzwerk
Bis hier ist die Benutzerverwaltung relativ einfach, da sie noch lokal ist. Schwieriger wird die Benutzerverwaltung im Netzwerk. Im Netzwerk möchte man möglichst nur eine Datenbasis für alle Benutzer beziehungsweise Gruppen pflegen und nicht die Einstellungen für jeden Server oder eventuell sogar Client extra verwalten.
8.5.1 Die Funktion 
Eine Möglichkeit, diese Daten zentral zu verwalten, ist der Network Information Service (NIS). NIS ist ein Verzeichnisdienst, der Konfigurationsdaten wie eben Benutzerdaten oder Rechnernamen im Netzwerk verteilt.
NIS wurde ursprünglich von Sun Microsystems unter dem Namen »Yellow Pages« (YP) entwickelt. Jedoch ist diese Bezeichnung in Großbritannien durch das Markenrecht geschützt, <Auch in Deutschland kennt man ja in einem anderen Zusammenhang die »gelben Seiten«, in denen zum Beispiel die Gewerbetreibenden verzeichnet sind.> daher musste die Umbenennung in NIS erfolgen.
Ein Verzeichnisdienst ist eine im Netzwerk verteilte (meist hierarchische) Datenbank.
Intern nutzen NIS wie auch dessen sicherere Variante NIS+ sogenannte Remote Procedure Calls (RPC). Damit können Funktionsaufrufe auf fremden Rechnern in der Regel synchron ausgeführt werden. Wenn dabei ein Client eine solche »entfernte Funktion« aufruft, so wartet er, bis der Server das Ergebnis zurücksendet. Unter Linux übernimmt der portmap-Dienst die Koordination der angebotenen Funktionen. Jedes Serverprogramm, das RPC-Dienste anbieten will, muss sich demzufolge beim portmap-Dienst anmelden. Ein Client greift dann über den TCP- beziehungsweise UDP-Port 111 auf den portmap zu und kann dort dann die gewünschten Funktionen ausführen lassen.
So wird RPC gestartet: Um RPC zu verwenden, müssen Sie nur den portmap-Dienst starten.
Der Dateiname dieses Programms lautet unter einigen Systemen jedoch nicht unbedingt portmap. Unter Slackware-Linux wird zum Beispiel rpc.portmap und unter Solaris 2.5 rpcbind gestartet. Um zu überprüfen, ob der Portmapper läuft, sollte eine rpcinfo-Abfrage genügen.
# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapperListing 8.28 rpcinfo
NIS selbst ist viel eher ein Protokoll und weniger eine Software, da es verschiedene Implementierungen für die einzelnen Unix-Systeme gibt.
NIS kann aber nicht nur die Account-Daten netzweit verfügbar machen, sondern kümmert sich auch darum, einige Konfigurationsdateien zu übertragen. Dazu gehören:
- /etc/group
- /etc/passwd
- /etc/ethers
- /etc/hosts
- /etc/networks
- /etc/protocols
- /etc/services
- /etc/aliases (enthält E-Mail-Aliase)
NIS betrachtet diese Dateien intern als Datenbanken, als sogenannte NIS-Maps. Die vom Server angebotenen NIS-Maps erfragt man mit dem Befehl ypcat -x.
Wir werden uns im Folgenden nur mit NIS, nicht mit NIS+ auseinandersetzen. Dass hat ganz einfach den Grund, dass NIS+ auf den meisten Linux- und Unix-Systemen sowieso nicht verfügbar ist und dass wir selbst auch immer nur NIS-Systeme verwendet haben. <Falls Sie sich für die Administration von NIS+ (unter Solaris) interessieren, sei Ihnen [HenMrks00A] und bedingt auch [Hertzog02A] empfohlen.>
8.5.2 Konfiguration der NIS-Clients
Der NIS-Client wird auf eine sehr einfache Weise aufgesetzt: Man setzt nur den NIS-Domainnamen. Dieser ist unabhängig vom DNS-Domainnamen zu betrachten, beide Dienste verwenden ein ganz unterschiedliches Protokoll. Der NIS-Domainname wird mit dem Kommando domainname konfiguriert. In den meisten Fällen wird ein ähnlicher (oder gar gleicher) Name wie beim DNS-System verwendet. Wir empfehlen diese Vorgehensweise ebenfalls, da man sich nur einen Hostnamen pro Rechner und einen Domainnamen pro Subnetz merken muss.
Unser Netzwerk heißt »sun«, was nichts mit SUN Microsystems zu tun hat, sondern damit, dass die meisten Hosts die Namen von Planeten bekommen haben.
# domainname sun # domainname sun
Listing 8.29 Setzen und Abfragen des NIS-Domainnamens
Um das Setzen des NIS-Domainnamens zu automatisieren, genügt es in der Regel, ihn in der /etc/domainname einzutragen. Da die Authentifizierung via NIS erfolgen soll, wird, um dies zu signalisieren, in die /etc/shadow beziehungsweise bei BSD in die /etc/master.passwd unter die bestehenden Account-Daten die folgende Zeile eingetragen:
+:*::::::::
ypbind
Um die Konfiguration zu testen, startet man am besten neu, so weiß man gleich, ob der Rechner automatisch ypbind (das Tool, das via Broadcast den NIS-Server lokalisiert) aufruft, was man zur Laufzeit aber auch erst einmal manuell erledigen kann.
In der Regel sollten noch Veränderungen an der Datei /etc/nsswitch.conf vorgenommen werden, um den Client anzuweisen, bestimmte Daten über NIS und nicht lokal zu beziehen. Das Schlüsselwort nis muss in diesem Fall vor dem Schlüsselwort files stehen. Für die Datei /etc/protocols würde ein Eintrag beispielsweise folgendermaßen aussehen:
protocols: nis files
Listing 8.30 Ausschnitt einer nsswitch.conf
8.5.3 Konfiguration des NIS-Servers
Auch auf dem Server wird zunächst der NIS-Domainname gesetzt. Der NIS-Server wird anschließend im Verzeichnis /var/yp mit make initialisiert. <Unter OpenBSD verwendet man ypinit -m.>
Server initialisieren
Auf dem Server werden schließlich die Dienste ypserv und ypbind gestartet. Von nun an können Clients über RPC <RPC = Remote Procedure Calls> Anfragen an den Server senden.
8.5.4 Testen der Konfiguration
Nun sollte ypwhich unseren Server als NIS-Server anzeigen, und die bereitgestellten Dateien können via ypcat <Dateiname> vom Server geladen werden. Ist dies nicht der Fall, sollte zunächst mit rpcinfo und pgrep überprüft werden, ob RPC funktioniert und ypserv und ypbind auf dem Server laufen. Falls dem so ist und trotzdem Probleme auftreten, sollte ein Blick in die Logdateien weiterhelfen.
8.5.5 Sicherheit
NIS selbst ist recht unsicher, da die Systemdateien während der Übertragung abgefangen werden können. Es empfiehlt sich daher, ein VPN und/oder Kerberos einzusetzen. Mehr zu diesen beiden Themen erfahren Sie in unserem Buch »Praxisbuch Netzwerksicherheit«.
