Größe: 8661
Kommentar:
|
Größe: 8723
Kommentar:
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 130: | Zeile 130: |
Alternativ dazu auch mit [http://lufs.sourceforge.net/ lufs] |
NFS (Network File System) ist die im UNIX-Bereich übliche Art, Verzeichnisse zu ex- bzw. zu importieren und dadurch auf mehreren Rechnern zu benutzen.
Es wird dabei transparent auf die freigegebenen Verzeichnisse zugegriffen. So kann also am Server das komplette /home oder /usr-Verzeichnis exportiert werden, welches dann vom Client übernommen wird - die Benutzer merken davon nichts (außer bei langsamen Netzen ).
Das Angenehme ist, dass man bestimmte Verzeichnisse nach Wahl nur für bestimmte Rechner oder Domänen freigeben kann.
Wer einen festplattenlosen ThinClient aufziehen will, kann auch das gesamte DateiSystem des Servers per NFS importieren.
Siehe auch das [http://www.tldp.org/HOWTO/NFS-HOWTO/ Linux NFS-HowTo].
Um Datenverzeichnisse von anderen Rechnern einzubinden, kann auch der AutoMounter verwendet werden - dadurch reduziert sich bei sehr vielen Clients die Zahl der Mounts auf die wirklich gebrauchten.
NFS ist ein relativ unsicheres Protokoll und kann deshalb nur in geschützten Umgebungen (lokales Netz ohne feindliche Rechner) eingesetzt werden. NFS vertraut auf TCP/IP bzw. DNS und darauf, dass die Clientrechner zuverlässige Authentifizierung ihrer Benutzer machen und lässt sich dementsprechend über diese Mechanismen angreifen - zudem ist NFS unverschlüsselt.
HowTo
Vorbereitung Server
Man installiere portmap - dies ist für NFS unbedingt notwendig, sonst gibt es merkwürdige Fehlermeldungen.
Außerdem braucht man natürlich entweder den Userspace-nfsd oder den Kernel-nfsd (und für letzteren natürlich auch den entsprechenden Support im Kernel).
Dann sorgt man dafür, dass portmap und nfsd automatisch beim Booten gestartet werden (Initskript entsprechend verlinken) und startet diese Dienste auch einmalig manuell per Initskript (erspart nen Reboot).
Bei RedHat müssen z.B. folgende Dienste laufen:
- network (versteht sich eigentlich von selbst)
- portmap
- nfslock
- nfs
Konfiguration Server
Dies ist relativ einfach, man braucht nur zwei Dateien anzupassen.
Auf dem Server schreibt man folgendes in die /etc/exports:
/home *.home.lan(rw)
Mit der Option async werden Zugriffe gepuffert und schneller. z.B (rw,async).
Zu beachten ist, dass die Freigaben automatisch vor "Rootzugriffen" geschützt sind. Der Admin root vom Client hat auf den freigegebenen Verzeichnissen also minimale Rechte (wie "nobody"). Um das Ummappen von root zu verhindern, kann die Option no_root_squash in /etc/exports hinzu gefügt werden.
Näheres siehe man 5 exports.
Den * als Wildcard kann man nur bei Domainnamen verwenden, nicht bei IP-Adressen (diese kann man mit der Netzmaske angeben)
falsch |
192.168.1.* |
richtig |
192.168.1.0/24 |
auch richtig |
192.168.1.0/255.255.255.0 |
Damit die Änderung wirksam wird, auf dem Server als root ausführen:
exportfs -a -r
Wichtig: Es dürfen keine Unterverzeichnisse von exportierten Verzeichnisse selbst freigegeben werden:
Bsp:
/raid tiger.linuxnet(ro) /raid/doc tiger.linuxnet(rw)
Hier ist der 2. Eintrag falsch, da /raid/doc ein Unterverzeichnis von /raid ist. Dies führt zu der Fehlersituation, dass der Export funktioniert, beim mounten auf dem Client jedoch die Meldung "permission denied" erscheint.
Überprüfen der Serverfreigabe
Um zu überprüfen, ob die Verzeichnisse auch exportiert werden, könnt Ihr folgenden Befehl auf der lokalen Maschine absetzen:
showmount -e [Nodename]
Vorbereitung Clients
Auf den Clients muss ebenfalls der Portmapper laufen.
Bei RedHat müssen folgende Dienste aktiv sein:
- portmap
- nfslock
Konfiguration Clients
Auf den Clients hängt man an die /etc/fstab folgendes an -
<servername>.<netzname>.<lan>:/home /home nfs defaults 0 0
Dann löschst man auf dem Client /home und alles, was darunter existiert (oder schiebt es erstmal irgendwo anders hin) - als root natürlich.
Danach mountet man auf allen Clients:
mount /home
und nun sollte /home den Inhalt von /home auf dem Server anzeigen - für alle Benutzer.
Statt dem o.g. defaults besser, rsize=8192,wsize=8192,hard,intr verwenden.
rsize und wsize sind Tuning-Optionen, die NFS beschleunigen. Man sollte sie nicht auf den Defaultwerten belassen, da dies die NFS-Verbindung bis zu einem Faktor 10 ausbremsen kann. Dies kann dann auch gerne zu weiteren Problemen wegen der Timeouts führen.
hard,intr sind Kompatibilitätsoptionen, die bei manchen Programmen sonst Probleme machen könnten. hard lässt Programme bei Unterbrechungen ohne Timeout warten bis der Server wieder normal erreichbar ist. intr erlaubt ein wartendes Programm bei Bedarf dennoch zu unterbrechen/killen.
Eine weitere mögliche Option nolock braucht man eigentlich nur, wenn kein lockd läuft (z.B. bei AutomatisierteInstallation)
Weitere interessante mount-Optionen:
nodev
nosuid
Siehe auch man mount.
Der neue Kernel NFS Service ("neu" = ab v2.2)
Wenn man den Kernel-NFS-Daemon benutzen will (z.B. weil man File Locking benötigt), muss man allerdings jeden Rechner, an den die jeweiligen Dateisysteme exportiert werden sollen, explizit in der /etc/exports aufführen - sonst kann es u.U. Probleme bei Wiederverbindung nach Netzwerkunterbrechungen geben (der Tipp ist aus der linux-kernel Mailingliste). Der knfsd ist auch sonst zu empfehlen, er ist nämlich etwas schneller als der normale nfsd. Allerdings hat der knfsd (Stand Kernel 2.2 - ist das auch später noch der Fall?) das Problem, dass er a) noch nicht ganz fertig ist und b) mandatory locks nicht vernünftig implementiert, falls er also nicht funktioniert, benutzt man einfach den alten user-space nfsd - der ist zwar langsamer, aber dafür auch bombenstabil.
Der Standard Red Hat 7.3 Kernel (=2.4.18-3) hat mehrer massive Bugs, die ihn als NFS Client unbrauchbar machen. Lösungsmöglichkeit: Upgrade auf 2.4.18-5 oder aktueller.
Im LinuxKernel 2.4.19 scheint ein Fehler im Kernel NFS Service enthalten zu sein, welcher bei gleichzeitigem Lesen und Schreiben von einem NFS-Verzeichnis zu Fehlern beim Schreiben führt (cp meldet: Input/Output error und bricht ab). Dies scheint im LinuxKernel 2.4.20 behoben zu sein.
Fragen und Antworten
OffeneFrage : Was kann/muß ich machen wenn der Server nicht erreichbar ist und Programme blockiert werden ich jetzt aber lieber einen Abbruch bzw. eine Fehlermeldung erzwingen will? Ich kann das NFS nicht unmounten, um es wieder richtig zu mounten. Geht das denn nicht ohne kompletten Neustart? Hätte ich mal besser vorher den mount gelößt.
OffeneFrage : Wie kann man am besten die Homeverzeichnisse in Clients einmounten die gleichzeitig auch lokale User beherbergen sollen? falls der Server (Erstrechner) gerade aus ist. (in BSD kann man wohl die lokalen Verzeichnisse unter /home sichtbar lassen, auch wenn ein remote /home "drübergemounted" wird.) Das Problem was ich für umgelegte lokale Homeverzeichnisse sehe ist, dass manche Programme einfach von /home/benutzername ausgehen und nicht z.B /home.local/benutzername. Hat da jemand Erfahrungen?
InterMezzo sollte AFAIK genau da helfen.
OffeneFrage : Da NFS ob der fehlenden Verschlüsselung unsicher ist, wie realisiert man dann alternativ das Im- und Exportieren von Verzeichnissen über's Netz besser? Selbst M$ wirbt inzwischen damit, dass SMB/CIFS verschlüsselt und Linuxfreigaben unverschlüsselt seien .
Man könnte auf dem Client die unverschlüsselte Freigabe via ["CFS"] Freigeben und das über loopback mounten. Nicht schön, aber sicher.
- Dazu taugen auch alle Formen von sicheren Tunneln. Etwa ein SSH-Tunnel auf den Server oder ein VPN.
OK, man kann ssh und unter KDE mit dem fish:/-Protokoll gaz komfortabel arbeiten, aber somit ist beispielsweise ein transparentes Mounten eines kompletten /home nicht so schön möglich. Ideen?
Doch das geht schau mal nach [http://shfs.sourceforge.net/ shfsmount] -- ReimarBauer DateTime(2004-03-27T08:17:12Z) Alternativ dazu auch mit [http://lufs.sourceforge.net/ lufs]
Tipps und Tricks
Vor jeder Änderung alle Clients unmounten!
Werden mehrerere Verzeichnisse eines NFS-Servers importiert, so empfiehlt es sich, bei Änderungen alle mounts zu lösen, da sonst beim Export ("exportfs -a") die Fehlermeldung "invalid parameter" erscheint und ein mount dann zur Fehlermeldung "keine Berechtigung" führt. Der "schwierige Zusammenhang" zwischen Fehlerbehebungsort und Fehlermeldung hat mich viel Zeit gekostet.