Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 17 Netzwerkdienste
Pfeil 17.1 inetd und xinetd
Pfeil 17.1.1 inetd
Pfeil 17.1.2 tcpd
Pfeil 17.1.3 xinetd
Pfeil 17.2 Standarddienste
Pfeil 17.2.1 Echo
Pfeil 17.2.2 Discard
Pfeil 17.2.3 Systat und Netstat
Pfeil 17.2.4 Daytime und Time
Pfeil 17.2.5 QotD
Pfeil 17.2.6 Chargen
Pfeil 17.2.7 Finger
Pfeil 17.2.8 Telnet und R-Dienste
Pfeil 17.3 DHCP
Pfeil 17.3.1 dhcpd
Pfeil 17.3.2 Client-Konfiguration
Pfeil 17.4 NNTP-Server (WendzelNNTPd 2)
Pfeil 17.4.1 Konfiguration
Pfeil 17.4.2 Server starten
Pfeil 17.4.3 Authentifizierung
Pfeil 17.4.4 Anonyme Message-IDs
Pfeil 17.5 Network File System
Pfeil 17.5.1 NFS-Server aufsetzen
Pfeil 17.5.2 Clients konfigurieren
Pfeil 17.6 FTP
Pfeil 17.6.1 Konfigurationsdateien
Pfeil 17.7 Samba
Pfeil 17.7.1 Windows-Freigaben mounten
Pfeil 17.7.2 Dateien freigeben
Pfeil 17.7.3 smb.conf
Pfeil 17.7.4 Samba, LDAP & Co.
Pfeil 17.8 Zusammenfassung
Pfeil 17.9 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

17.5 Network File SystemZur nächsten Überschrift

Unter Windows stehen Ihnen über Netzwerkfreigaben und SMB einzelne Dateien, Verzeichnisbäume und sogar ganze Laufwerke netzwerkweit zur Verfügung. Unter Linux kann man dies entweder mittels Samba auf die gleiche Art und Weise umsetzen, was jedoch nur sinnvoll ist, wenn man auch Windows-PCs mit diesen Netzwerkfreigaben verbinden möchte. Eine pure und saubere Unix-Lösung wäre hingegegen das Network File System.

Mit dem NFS kann praktisch jedes Unix-System, jedes BSD-System und jedes Linux-System arbeiten. Es gibt auch eine kostenpflichtige Implementierung für Windows. Das Network File System, im Folgenden nur noch NFS genannt, wurde von Sun Microsystems entwickelt. Daher findet man auf den Dokumentationsseiten von Sun (z. B. docs.sun.com) auch tonnenweise Informationsmaterial zum Thema.

NFS ermöglicht es also, Verzeichnisse – und das können in Form von Mountpoints auch ganze Partitionen sein – im Netzwerk bereitzustellen. Die Freigaben liegen dabei physisch auf dem NFS-Server. Die NFS-Clients können dann über entsprechende Software, die in der Regel bereits direkt in den Kernel implementiert ist, auf diese Freigaben zugreifen und sie ins eigene Dateisystem einhängen. Daher ist NFS für den Anwender völlig transparent.

Es macht keinen Unterschied, ob man unter Unix auf eine Diskette, eine Festplatte oder ein Netzwerk-Dateisystem schreibt. Ebenso kann die Netzwerkfreigabe beim Server auf einer Festplatte oder einem anderen Medium liegen. [Fn. Einmal abgesehen von erheblichen Performanceunterschieden.]

NFS kann dadurch den Bedarf an lokalem Festplattenspeicher in Workstations und damit effektiv Kosten senken. Für den Administrator ist es wiederum einfacher, Backups zu erstellen, da er diese nur noch von den Daten des NFS-Servers ziehen muss. Wie bei Client/Server-Architekturen üblich, besteht der Nachteil darin, dass bei einem Serverausfall niemand mehr an seine Daten herankommt.


Rheinwerk Computing - Zum Seitenanfang

17.5.1 NFS-Server aufsetzenZur nächsten ÜberschriftZur vorigen Überschrift

NFS verwendet den RPC-Dienst, daher muss zunächst der Portmapper gestartet werden. Wie dies funktioniert, haben Sie bereits in Kapitel 13, »Benutzerverwaltung«, erfahren. [Fn. In Abschnitt 13.5, NIS/NIS+.] Der restliche Teil der Konfiguration ist nicht sonderlich schwer.

Es gibt verschiedene Dienste, die alle miteinander kooperieren und erforderlich sind, um einen funktionsfähigen NFS-Server zu betreiben. Dazu zählen:

  • nfsd
    Der nfsd nimmt NFS-Anfragen von Clients entgegen.
  • (rpc.)mountd
    Der mountd verarbeitet die Mount-Anfragen der Clients.
  • (rpc.)lockd
    Dieser Dienst kümmert sich um Anforderungen des File-Lockings.
  • (rpc.)statd
    Dieser Dienst wird zum Monitoring und für lockd benötigt.

Die Dienste lockd und statd laufen übrigens auch auf Client-Systemen. In der Regel werden sie vom jeweiligen Derivat beziehungsweise von der jeweiligen Distribution über Shellskripts beim Startvorgang gestartet. Ist dies nicht der Fall, müssen Sie diese Dienste selbst starten.

Dateien freigeben

Nun sind aber noch gar keine Dateien freigegeben. Um dies zu ändern, gibt es zwei Wege: Entweder man verwendet ein Unix-System, das das Tool share zur Verfügung stellt (etwa Solaris), oder man verwendet die Datei /etc/exports. Da die zweite Variante unter Linux und BSD immer funktioniert, werden wir uns im Folgenden auf die exports-Datei beschränken.

Dort werden die freizugebenden Verzeichnisse sowie deren Zugriffsrechte [Fn. ... bei denen man eigentlich schon von Access Control Lists sprechen kann.] festgelegt. Zugriffsrechte können nämlich nicht nur wie im Unix-Dateisystem (von ACLs einmal abgesehen) konfiguriert, sondern bei Bedarf auch hostspezifisch gesetzt werden.

Die Einträge sind, wie unter Linux üblich, zuerst zeilenweise und anschließend spaltenweise zu interpretieren. In der ersten Spalte wird das Verzeichnis angegeben, das man freigeben möchte. Darauf folgen verschiedene Parameter, die den Zugriff auf die Freigabe regeln.

Listing 17.21 Beispiel einer exports-Datei

/exports/pub_ftp (ro)
/exports/homes 192.168.0.0/24(rw)

In diesem Beispiel haben wir das Verzeichnis /exports/pub_ftp für alle Hosts aller Netzwerke freigegeben. Allerdings darf niemand auf diese Ressource schreiben (»ro« = read-only). Das Verzeichnis homes, in dem alle Heimatverzeichnisse der Nutzer enthalten sind, wird für das gesamte Netzwerk 192.168.0.0/24 mit Lese- und Schreibrechten freigegeben.

Netzmaske

Wie Ihnen sicher aufgefallen ist, können Netzwerke also in der Form Adresse/Netz- maske angegeben werden. Falls Ihnen die Bit-Schreibweise der Netzmaske nicht geläufig ist, kann sie auch ausgeschrieben werden. Im Beispiel wäre die Netzmaske also 255.255.255.0.

Wildcards

Außerdem können Wildcards verwendet werden. Sollen beispielsweise alle Hosts im Netz doomed-reality.org auf eine Ressource zugreifen können, so lässt sich auch *.doomed-reality.org schreiben.

(a)sync

Durch das Schlüsselwort async kann man die Performance von NFS-Netzwerken verbessern. Werden Daten verändert, so werden diese sofort auch im Netzwerk in veränderter Form verfügbar, selbst dann – und das ist der springende Punkt --, wenn sie noch nicht auf dem Datenträger abgespeichert worden sind. Es herrscht folglich kein synchroner Zustand zwischen Speicher und Medium.

async hat nicht nur den Vorteil der Performancesteigerung, sondern auch den Nachteil, dass bei Absturz des Servers die Daten im Speicher verloren gehen, bevor sie auf das Medium gespeichert wurden. Daher stellt ein möglicher Datenverlust ein großes Risiko dar. Um dies zu verhindern, kann man NFS dazu zwingen, die Daten synchron zu halten, und zwar mit dem Schlüsselwort sync. [Fn. Übrigens gibt es – unabhängig von NFS – auch das Dateisystem-Tool sync, das die Daten, die aktuell nur im Speicher sind, auf die eingehängten Speichermedien des Systems schreibt.]

(no)dev

Das Schlüsselwort dev bewirkt, dass auch Device-Dateien über das Netzwerk verfügbar gemacht werden dürfen oder eben nicht (nodev).

(no)exec

exec erlaubt das Ausführen von Dateien im Netzwerk-Dateisystem; noexec bewirkt das Gegenteil.

(no)suid

Bei gesetztem nosuid-Keyword dürfen keine Binaries mit setuid-Flag ausgeführt werden. Dies verbessert die Sicherheit von NFS. Das Keyword suid bewirkt natürlich wieder das Gegenteil.

(no)user

Falls nur root ein Dateisystem mounten dürfen soll, wird das Schlüsselwort nouser angegeben.

Weitere Optionen

Es gibt noch diverse weitere NFS-Optionen. Diese würden allerdings den Rahmen dieses Abschnitts sprengen und sind zudem oft systemabhängig. Wir verweisen daher auf die jeweilige exports-Manpage.


Rheinwerk Computing - Zum Seitenanfang

17.5.2 Clients konfigurierenZur vorigen Überschrift

Auch auf dem Client wird RPC sowie (rpc.)lockd und (rpc.)statd gestartet. Anschließend kann ein Remote-Dateisystem mit mount eingehängt werden, wozu Sie den NFS-Server und die Freigabe angeben müssen. Unter Linux verwendet man für NFS den Parameter -t nfs; unter OpenBSD wird einfach mount_nfsd benutzt.

Listing 17.22 Dateisystem mounten unter Linux

# mount -t nfs 192.168.0.5:/exports/homes /home
# df -h | grep homes
192.168.0.5:/exports/home 6.6G 2.6G 3.7G 42 % /home

showmount

Um nun zu überprüfen, welche Freigaben auf einem Host verfügbar sind, nutzen Sie das Tool showmount.

Listing 17.23 showmount

# showmount -e localhost
Export list for localhost:
/exports/pub_ftp (everyone)
/exports/homes 192.168.0.0/24

[zB]NFS wird, wie Sie im Beispiel gesehen haben, häufig für die Verteilung von Home-Verzeichnissen eingesetzt. So kann gewährleistet werden, dass für einen Benutzer die Dateien samt Arbeitsumgebung auf allen Rechnern in einem Pool identisch sind. Um keine Konflikte mit der Rechtevergabe und der Benutzerverwaltung zu bekommen, wird NFS daher auch oft in Verbindung mit LDAP oder NIS eingesetzt.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Linux Handbuch






 Linux Handbuch


Zum Rheinwerk-Shop: Linux Server






 Linux Server


Zum Rheinwerk-Shop: Raspberry Pi






 Raspberry Pi


Zum Rheinwerk-Shop: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Rheinwerk-Shop: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern