|
|
|
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.
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)
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.
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.
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
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.
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" -> "Netzdienste" -> den Punkt "NIS-Server EINschalten" wählen, wie in Kapitel 5.7 beschrieben. 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
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.
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
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.
|
|
|