Vorheriger Abschnitt Inhaltsverzeichnis Nächster Abschnitt

7.8 NFS und NIS - Server

Für die Anbindung von Unix-Clients (z.B. mit Linux) sollten Sie das Network-File-System, kurz NFS einsetzen. Es wird meist - aber nicht zwingend - in Verbindung mit NIS (Network Information System, eine Entwicklung von SUN Microsystems), früher auch YP-Protokoll (Yellow Pages, das aber ein eingetragenes Warenzeichen von AT&T ist) genannt. Andersherum macht NIS ohne NFS keinen Sinn, so dass man zur Aktivierung von NIS unbedingt auch NFS einschalten sollte.

a) NFS-Server einrichten

Das Network-File-System gibt Verzeichnisse des NFS-Servers für andere Clients im Netzwerk frei. Die Clients können die freigegebene Verzeichnisse in den eigenen Verzeichnisbaum einbinden und darauf zugreifen, als ob die Dateien lokal liegen. In Unix-Netzwerken wird auf diese Weise meist das Heimatverzeichnis /home auf allen Rechnern gleichartig zur Verfügung gestellt, aber auch das Mailverzeichnis kann exportiert werden.

Dazu muss zunächst dem Server gesagt werden, welche Verzeichnisse er wie freigeben soll. Das geschieht mit der Datei /etc/exports . Die folgende Abbildung enthält ein Beispiel für diese Datei an Arktur:


# /etc/exports  beim ODS-Server
# wir geben folgendes im ganzen Netz frei
/cdrom  192.168.0.0/255.255.192.0(ro)
/home   192.168.0.0/255.255.192.0(rw)
/var/spool/mail  192.168.0.0/255.255.192.0(rw)
# und das bekommt nur der Lehrerrechner zu sehen
/var/log  Lehrer.MSJohann.dd.sn.schule.de(rw,no_root_squash) 

Abbildung 7.8-1: Beispiel für die /etc/exports

Hier wird das CD-ROM-Laufwerk an alle Clients des Netzes 192.168.0.0 mit der Netzmaske 255.255.192.0 mit der Option ro=read-only, also zur zum Lesen freigegeben. Das Home-Verzeichnis hingegen wird mit der Option rw=read&write, also zum Lesen und Schreiben freigegeben, ebenso das Mailverzeichnis /var/spool/mail. Das Verzeichnis /var/log wird hingegen nur einem Rechner, dafür aber mit vollem Lese- und Schreibzugriff freigegeben. Die Option "no_root_squash" sorgt dafür, dass auch root vom Rechner "Lehrer" volle Rechte erhält, sonst wird bei NFS allen Nutzern mit der UID=0 (also root, sysadm und internet) aus Sicherheitsgründen der Zugriff auf die Rechte von "nobody" umgemappt. Damit aber root die Rechte behält, muss dieses Mappen durch die Option "no_root_squash" unterbunden werden. Achten Sie bei Änderungen an dieser Datei unbedingt darauf, dass sich am Ende eine Leerzeile befindet! Der NFS-Sevrer startet sonst nicht.

Ein Problem in Unix-Netzen ist generell die Authentifizierung: In klassischen Unix-Netzen ist der Client dafür zuständig. Auf Rechnern mit DOS oder Windows kann diese Authentifizierung nicht vom Client vorgenommen werden. Deshalb wurde eine veränderte Variante mit der Bezeichnung "PCNFS" entwickelt. Beim ODS-Server können Sie auch dieses Protokoll freigeben. Nutzen können Sie es mit der Shareware XNFS oder den Werkzeugen aus dem LAN-Workgroup-Paket von Novell (Groupwise-Funktionen).

Das NFS und das PCNFS-Protokoll aktivieren Sie über das Menü "Verwalten" -> "Netzdienste" und dort "NFS-Server EINschalten" bzw. (nur wenn auch NFS ein ist) "PCNFS-Server EINschalten". Beachten Sie noch: Damit nach einer Änderung der Datei /etc/exports diese Veränderung auch aktiv wird, muss der NFS-Dienst neu gestartet werden. Das geht am einfachsten als root mit den Befehlen:

root@Arktur# /sbin/init.d/nfs stop 
root@Arktur# /sbin/init.d/nfs start 

Damit ist die Konfiguration des Servers abgeschlossen.

b) NFS-Clients einrichten

Damit ein Client ein freigegebenes Verzeichnis in sein Dateisystem einklinken kann, muss es in den Verzeichnisbaum des Clients eingebunden ("gemountet") werden. Dabei wird als Dateisystemtyp "nfs" angegeben. Statt der üblichen Device-Angabe wird der Servername bzw. die IP-Adresse angegeben und das Verzeichnis des Servers, das freigegeben ist. Außerdem ist natürlich der Mount-Punkt anzugeben, an dem das Verzeichnis eingebunden wird, z.B.

root@Client# mount -t nfs Arktur:/home /home

Damit wird das Homeverzeichnis von Arktur auf dem Client in das Verzeichnis /home auf dem Client eingebunden - das übliche Verfahren, wenn das Verzeichnis im Netzwerk verteilt werden soll. Wenn /home einmal freigegeben ist, kann der Client auch Unterverzeichnisse davon einbinden, also z.B.

root@Client# mount -t nfs Arktur:/home/adm /opt/adm

Damit wird nur /home/adm vom Server eingeklinkt, allerdings an einem anderen Mount-Punkt auf dem Client, nämlich /opt/adm . Wenn das Verzeichnis, das als Mount-Punkt benutzt wird, nicht leer ist, wird alles andere einfach ausgeblendet - nur das eingeklinkte Verzeichnis ist "sichtbar".

Meist sollen die NFS-Verbindungen gleich beim Start des Clients eingebunden werden. Dazu trägt man diese Laufwerke in die Datei /etc/fstab ein:


/dev/hda1      /         ext2           defaults       1  1
Arktur:/home   /home     nfs            nodev,nolock   0  0

Abbildung 7.8-2: Beispiel für die /etc/fstab auf dem Client

So kann also das Homeverzeichnis von Arktur allen Clients zur Verfügung gestellt werden. Damit hat in einem Unix-/Linux-Netz jeder seine persönlichen Daten auf dem lokalen Client. Natürlich können Sie mit den oben angegebenen Befehlen auch Arktur selbst als NFS-Client benutzen. Das ist besonders interessant, wenn Arktur nicht der einzige Linux-Server im Netzwerk ist. Auch die Einrichtung von NFS-Laufwerken in der /etc/fstab unterstützt Arktur.

 

c) NIS-Server einrichten

Das Network Information System ist ein sehr universelles Protokoll zur Übertragung netzwerkspezifischer Einstellungen im gesamten (Unix-) Netzwerk. Die wichtigste Aufgabe ist jedoch, Nutzernamen und deren Passwörter im Netzwerk bekannt zu machen. Mit NIS erreichen sie also, dass alle Linux- bzw. Unix-Rechner im lokalen Netz die Anmeldedaten für jeden Nutzer des Netzwerks kennen und ihm - sofern freigegeben - den Zugang ermöglichen. Sie müssen jeden Nutzer nur am NIS-Server bekannt machen und er kann sich an jedem Netzwerkrechner anmelden.

Um den NIS-Server auf Arktur zu aktivieren, müssen Sie unter "Verwalten" -> "Dienste" -> den Punkt "NIS-Server EINschalten" wählen, wie in Kapitel 5.7 beschrieben. Dieser Menüpunkt ist erst nach dem Einschalten des NFS-Servers sichtbar. Nach dem üblichen "AKTIVIEREN" sollte der NIS-Server starten. Vorher muss in /var/yp die Datenbank erzeugt werden, die alle Informationen enthält. Manchmal kommt es beim Erstellen der Datenbank zu Problemen. In diesen Fall müssen Sie sich als root anmelden, in das Verzeichnis /var/yp wechseln und dort ein "make" ausführen. Anschließend starten Sie am besten den gesamten Server neu.

Der NIS-Server entnimmt der lokalen Installation Nutzerkennungen und Passwörter und trägt sie in die Datenbank ein. Wechselt ein Nutzer sein Passwort an einem Client, muss über ein geeignetes Passwort-Programm der Server über die Änderung informiert werden. Dann gilt das geänderte Passwort im gesamten Netzwerk. Auf dem NIS-Server wird dazu ein Daemon "yppasswdd" gestartet, der die geänderten Passwörter aus dem Netzwerk entgegennimmt. Auf den Client muss entweder ein geeignetes PAM-Programm (Plugable Authentification Module)genutzt werden, oder die lokale Datei /usr/bin/passwd muss auf dem Client gegen die /usr/bin/yppasswd ausgetauscht (kopiert oder Hardlink) werden. Ob Ihre Linux-Distribution PAM unterstützt, müssen Sie im Handbuch oder der Dokumentation nachlesen. Die verbeiteten Distributionen von SuSE oder Red Hat unterstützen seit Ausgabe 7.0 dieses System. Anderseits entsteht ein Problem, wenn der Nutzer sein Passwort über das Online-Interface ändert bzw. wenn sysadm oder root das Passwort ändern. Dann wird die Datenbank des NIS-Servers nicht über die Änderung informiert. Deshalb wird beim Neustart ein Cron-Job aktiviert, der alle 15 Minuten die Datenbank mit den lokalen Dateien synchronisiert. So kann es also im ungünstigsten Fall 15 Minuten dauern, bis ein über das Menü geänderte Passwort eines Nutzers auch gültig wird.

Ob alle Dienste auf Arktur richtig gestartet wurden, prüfen Sie am besten als root mit dem Befehl "rpcinfo -p":


root@Arktur:~ # rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100004    2   udp    859  ypserv
    100004    1   udp    859  ypserv
    100004    2   tcp    862  ypserv
    100004    1   tcp    862  ypserv
    100009    1   udp    973  yppasswdd
 600100069    1   udp    986  fypxfrd
 600100069    1   tcp    988  fypxfrd
    100024    1   udp   1009  status
    100024    1   tcp   1011  status
    100003    2   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100021    1   udp   1055  nlockmgr
    100021    3   udp   1055  nlockmgr
    100021    4   udp   1055  nlockmgr
    100005    1   udp   1056  mountd
    100005    1   tcp   1024  mountd
    100005    2   udp   1056  mountd
    100005    2   tcp   1024  mountd
    100011    1   udp    614  rquotad
    100011    2   udp    614  rquotad
    100011    1   tcp    617  rquotad
    100011    2   tcp    617  rquotad

Abbildung 7.8-3: Beipiel für die Ausgabe von rpcinfo

Auf diesem Rechner sind also NFS und NIS eingeschaltet, zudem ist Quota aktiviert worden. Die Zahlenwerte von "program" und "port" können variieren. Wichtig sind vor allem die Dienstbezeichnung in der letzten Spalte. Hier steht "ypserv" für den NIS-Server, "yppasswdd" für den Passwort-Dienst, "nfs" und "mountd" bilden den NFS-Server, "rquotad" überträgt die Quota-Informationen an die Client-Rechner, auf denen auch Quota aktiviert sein muss. Die Dienste "status" und "nlockmgr" übernehmen eventuell die Locking-Funktionen für per NFS freigegebene Dateien. Diese sind nicht immer nötig.

Außer der Passwortfunktion kann NIS noch viele weitere Informationen übertragen: Netzkartenadressen mit deren IP-Nummer statt DHCP, Druckerkonfigurationen, Netzwerk- und Rechnernamen (statt des Nameservers), Gruppeninformationen und einiges mehr. Wie man diese Dienste nutzt, entnehmen Sie bitte den Dokumentationen zum Client-System.

d) NIS-Clients einrichten

Grundsätzlich ist die Einbindung von NIS-Clients sehr stark von der Distribution abhängig. Den Weg mit dem bei SuSE-Linux enthaltenen YaST2 ist im Kapitel 5.7 beschrieben. Bei anderen Distributionen richten Sie sich bitte nach den dort vorhandenen Distributionen.

In der Regel müssen drei Einstellungen vorgenommen werden: Der NIS-Domainname muss auf der Arbeitsstation nach der NIS-Domain gesetzt werden, eine /etc/yp.conf muss erstellt (angepasst) und der ypbind-Daemon gestartet werden. Dazu muss in den Dateien /etc/passwd und /etc/group jeweils eine Zeile ergänzt werden.

Sehen wir uns zuerst die /etc/yp.conf an.


# /etc/yp.conf
domain MSJohann.dd.sn.schule.de server 192.168.0.1
ypserver 192.168.0.1

Abbildung 7.8-4: Beispiel für die /etc/yp.conf auf dem Client

Es können beide Zeilen eingetragen sein oder nur eine von beiden. Steht nur die letzte Zeile (ypserver) da, muss mit dem Befehl "nisdomainname" die Domain geprüft oder eventuell gesetzt werden.

Wichtig ist die Änderung der Datei /etc/passwd. Dort sollte am Ende eine Zeile angefügt sein:

+::::::

Damit wird die Passwortliste um die Einträge ergänzt, die der NIS-Server liefert und die der Daemon ypbind einbindet. Die Standard-Shell bei Arktur ist aber /usr/bin/passwd, was nur das Ändern des Passworts am lokalen Rechner und keine echte Anmeldung ermöglichen würde. Deshalb ist es günstig, diesen Eintrag zu ändern in:

+::::::/bin/bash

Damit wird die vom Server gelieferte Information über die Standard-Shell überschrieben mit /bin/bash, der normalen Benutzershell auf einem Linux-System. Der Nutzer kann sich am lokalen Clientrechner innerhalb seiner Nutzerrechte frei bewegen, sich aber nicht am Server selbst anmelden. Damit ist auch die Einrichtung des NIS-Clients abgeschlossen.


Vorheriger Abschnitt Inhaltsverzeichnis Nächster Abschnitt
© Reiner Klaproth, 23.02.2001