Administratorhandbuch:NFS - Versionsgeschichte

Schoffer: kat

2012-03-16T10:16:16Z

kat

← Nächstältere Version		Version vom 16. März 2012, 12:16 Uhr
Zeile 139:		Zeile 139:
	----		----
	<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>		<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>


			[[Kategorie:ArchivArktur40]]

Schoffer: Archiv

2009-05-01T09:47:11Z

Archiv

← Nächstältere Version		Version vom 1. Mai 2009, 11:47 Uhr
Zeile 1:		Zeile 1:
	__NOTOC__		__NOTOC__
	{{~~fertig~~}}		{{Archiv}}

Schoffer: Schützte „Administratorhandbuch:NFS“ [edit=sysop:move=sysop]

2008-05-16T15:19:07Z

Schützte „Administratorhandbuch:NFS“ [edit=sysop:move=sysop]

← Nächstältere Version	Version vom 16. Mai 2008, 17:19 Uhr
(kein Unterschied)

Schoffer: 16 Versionen

2008-03-04T21:42:16Z

16 Versionen

← Nächstältere Version	Version vom 4. März 2008, 23:42 Uhr
(kein Unterschied)

Schoffer am 28. Dezember 2005 um 18:44 Uhr

2005-12-28T18:44:09Z

← Nächstältere Version		Version vom 28. Dezember 2005, 20:44 Uhr
Zeile 133:		Zeile 133:
	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.		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.

	Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für [[Installationshandbuch:~~SuSELinux~~\|~~SuSELinux~~]]).		Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für [[Installationshandbuch:SUSELinux\|SUSELinux]]).


	----		----
	<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>		<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>

Schoffer am 28. Dezember 2005 um 18:42 Uhr

2005-12-28T18:42:19Z

← Nächstältere Version		Version vom 28. Dezember 2005, 20:42 Uhr
Zeile 133:		Zeile 133:
	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.		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.

	Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für [[Installationshandbuch:SuSELinux]]).		Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für [[Installationshandbuch:SuSELinux\|SuSELinux]]).


	----		----
	<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>		<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>

Schoffer: Link entfernt

2005-12-28T18:41:39Z

Link entfernt

← Nächstältere Version		Version vom 28. Dezember 2005, 20:41 Uhr
Zeile 133:		Zeile 133:
	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.		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.

	Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also [[Installationshandbuch:SuSELinux~~]] oder [[Installationshandbuch:DebianLinux~~]]).		Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für [[Installationshandbuch:SuSELinux]]).


	----		----
	<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>		<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>

Schoffer: fertig gesetzt

2005-11-25T11:02:51Z

fertig gesetzt

Neue Seite

__NOTOC__
{{fertig}}

{| align="center" border="0" cellpadding="5" cellspacing="2" style="border: 1px solid #AFAFAF; background-color: #FCFCFC; border-left: 5px solid #AFAFAF"
|-
| style="font-size: 95%;" | NFS wird auf dem Arktur-Schulserver in Verbindung mit der Anmeldung mittels LDAP genutzt. Die aus älteren Arkturversionen stammende Anmeldung per NIS wird nicht mehr unterstützt. Die auf den Clients dadurch notwendig gewordene Umstellung von NIS auf LDAP ist bei SuSE-Linux problemlos.
|}

== Der NFS Server ==

=== Was ist NFS? ===

NFS, das "Network File System", ist eine Client-Server-Applikation, welche entfernte Laufwerke (von einem Server) für den lokalen Rechner (den Client) transparent zur Verfügung stellt. Der Nutzer bekommt im Normalfall überhaupt nicht mit, das er seine Daten gar nicht "lokal" speichert oder lädt, sondern sie über das Netzwerk zum Server übertragen und von dort geladen werden. Dafür werden verschiedene Programme genutzt, die für eine konsistente Datenübertragung sorgen.

NFS basiert auf dem RPC (remote procedure call) Protokoll, welches ursprünglich 1980 (!) von Sun Microsystems entwickelt wurde, um Filesharing auf Unix-Plattformen zu ermöglichen.

=== Was ist die Gefahr von NFS? ===

Normalerweise benutzen die von NFS eingesetzten Programme keine weiteren Mittel um die Authentizität der Benutzer zu überprüfen. Das macht das System so gefährlich. Im Schulnetz brauchen Sie sich darüber allerdings nur dann Gedanken machen, wenn externe Rechner Zugriff auf das Intranet haben können.

Einerseits ist hierfür sicherlich das benutzte Übertragungsprotokoll UDP verantwortlich, welches als "zustandsloses" Protokoll keine Möglichkeit bietet, die Verbindung zwischen zwei Stationen zu überprüfen. Das macht das UDP-Protokoll zwar wesentlich schneller als das heute sehr bekannte TCP Protokoll und war seinerzeit sicherlich auch der Hauptgrund für Sun Micosystems auf diese Übertragungstechnik zu setzen (weniger "Protokoll" = weniger Serverbelastung) - allerdings mussten so auch zusätzliche Sicherungsmassnahmen eingeführt werden, um auch nur eine sichere Übertragung der Pakete sicherzustellen: so versucht NFS für jeden ausgesendeten Befehl eine Antwort zu bekommen. Bleibt diese aus, so wird der Befehl immer wieder wiederholt. (Anmerkung: bei TCP ist das Verfahren zwar ähnlich - setzt aber schon auf "Protokollebene" an; der das Protokoll nutzende Dienst braucht sich darum nicht zu kümmern.)

=== NFS-Server einrichten ===

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 Arktur-Schulserver gesagt werden, welche Verzeichnisse er wie freigeben soll. Das geschieht in der Datei ''/etc/exports'' . Die folgende Abbildung enthält ein Beispiel für diese Datei an einem Arktur-Schulserver:

<pre>
# /etc/exports beim Arktur-Schulserver
# 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.rg1.dd.sn.schule.de(rw)
</pre>
:''Abbildung: Beispiel für /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='''r'''ead-'''o'''nly, also zur zum Lesen freigegeben. Das Home-Verzeichnis hingegen wird mit der Option rw='''r'''ead&'''w'''rite, 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.

Zusätzlich lassen sich noch einige Sicherheitsattribute setzen:

'''secure ''' Hier werden nur Anfragen von einem hohen Port an einen niedrigeren (und damit priviligierten) Port erlaubt. Damit wird die Gefahr verringert, dass ein normaler Nutzer einen NFS-Server aufsetzt und diesen dann mit ihrem Server "unter gleichen" reden lässt. Diese Einstellung ist zwar Standard - Sie ausdrücklich zu setzen beruhigt aber auf jeden Fall das Gewissen.

'''noaccess '''Mit diesem Parameter können Unterverzeichnisse eines exportierten Verzeichnisses gesperrt werden.

'''link_relative '''Hiermit werden vorhandene Links relativ zum eigentlichen Root-Verzeichnis des Servers gesetzt. Sollte der Server z.B. mit einer Chroot-Umgebung laufen, so würden Links auf das reale Dateisystem des Servers sonst ins Leere zeigen.

'''link_absolute '''Hier werden die Links im exportierten Verzeichnis absolut gesetzt. Ein "relativer" Link auf dem Server wird dem Client also als "absolut" vorgegaukelt.

'''root_squash '''Standardeinstellung: Hier wird der Nutzer root des entfernten Systems behandelt, als wäre er nobody. Damit bekommt ein Hacker von einem fremden Rechner keine Möglichkeit sich auszubreiten.

'''no_root_squash '''Hier hat der Nutzer "root" des fremden Systems dieselben Rechte wie der lokale root.

'''squash_uids''' und '''squash_gids '''Mit dieser Option können bestimmte UIDs und GIDs vom fremden System behandelt werden, als wären sie "nobodys" - was sich besonders bei Systemaccounts als nützlich erweist. Beispiel: squash_uids=0-499 Lässt alle Anfragen von Nutzern mit einer ID kleiner als 500 nur als "nobodys" zu.

'''all_squash '''Alle UIDs werden "gesquasht", d.h. dem Nutzer nobody angerechnet. Damit haben alle fremden Nutzer die geringsten Rechte.

'''map_daemon '''Damit werden UIDs und GIDs vom entfernten System dynamisch an die im lokalen System vorhandenen angepasst. Ein Nutzer "lars" auf dem entfernten System bekommt dann dieselben Rechte wie der lokale "lars" - auch wenn dieser eine andere Nutzer-ID hat. Allerdings muss dazu auf beiden Systemen der rpc.ugidd laufen.

'''map_static '''Hiermit wird ein statisches Mapping eingeführt. Dazu muss eine Datei mit den entsprechenden Zuweisungen vorhanden und als Parameter angegeben sein.

Ein Beispiel: ''map_static=/etc/nfs/foobar.map''

Die Datei ''/etc/nfs/foobar.map'' könnte dann so aussehen:

<pre>
# Mapping for client foobar:
# remote local
uid 0-99 - # squashen - also eigentlich keine Rechte
uid 100-500 1000 # Mappe die UIDs von 100-500 nach 1000-1400
gid 0-49 - # Gruppen squashen
gid 50-100 700 # Mappe Gruppen mit IDs von 50-100 nach 700-750
</pre>

'''anonuid''' and '''anongid '''Hiermit werden die UIDs und GIDs für den Nutzer nobody und die entsprechende Gruppe festgelegt.

'''no_exec '''Das Dateibit für ausführbare Dateien wird im entfernten System nicht gestattet: aus diesem exportierten Verzeichnis heraus dürfen keine Programme aufgerufen werden.

'''no_suid '''Das setzen des "User-ID"-Bits wird nicht gestattet. Dateien können nur mit den Rechten des jeweils angemeldeten Benutzers ausgeführt werden.

'''no_sgid '''Das setzen des "Group-ID"-Bits wird nicht gestattet. Dateien können nur mit den Gruppen-Rechten des angemeldeten Benutzers ausgeführt werden.

=== NFS-Server einschalten ===

Das NFS-Protokoll aktivieren Sie als Benutzer ''sysadm'' über das Menü "Verwalten" -> "Dienste" und dort "NFS-Server" wählen und mit der Leertaste das (x) setzen. Vergessen Sie danach nicht das Aktivieren.

'''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:

<pre>
root@Arktur# /etc/init.d/nfsserver stop
root@Arktur# /etc/init.d/nfsserver start
</pre>

=== NFS-Clients einrichten ===

Wenn Sie Linux-Clients einbinden wollen, benutzen Sie am einfachsten den mitgelieferten Konfigurationsmanager wie YaST bei SuSE. Näheres dazu finden Sie im Installationshandbuch Client. Sie können den Client aber auch von Hand einrichten, wie es im folgenden beschrieben wird.

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.

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

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. Statt dem Servernamen Arktur können Sie auch die IP-Adresse von Arktur (oder Capella) verwenden, also z.B. mount -t nfs 192.168.0.1:/home /home schreiben. Wenn /home einmal freigegeben ist, kann der Client auch Unterverzeichnisse davon einbinden, also z.B.

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

Damit wird nur "/home/adm" vom Server eingeklinkt, allerdings an einem anderen Mount-Punkt auf dem Client, also hier nach "/opt/adm" . Wenn das Verzeichnis, welches 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:

<pre>
/dev/hda1 / ext2 defaults 1 1
Arktur:/home /home nfs nodev,nolock 0 0
Arktur:/var/spool/mail /var/spool/mail nfs nodev,nolock 0 0
Arktur:/home/adm /Arkturpub nfs nodev,nolock 0 0
Arktur:/home/tmp /Arkturtmp nfs nodev,nolock 0 0
Arktur:/cdrom /media/cdrom nfs nodev,nolock 0 0
</pre>
:''Abbildung: Beispiel für die /etc/fstab auf dem Client''

So können Sie also das Homeverzeichnis, das Mailverzeichnis, das Programmverzeichnis "/home/adm" und das Tauschverzeichnis "/home/tmp" vom Arktur-Schulserver allen Clients zur Verfügung stellen. Damit hat in einem Unix-/Linux-Netz jeder seine persönlichen Daten auch auf dem lokalen Client zur Verfügung. Damit startet zum Beispiel KDE so, als hätte man sich als lokalen Benutzer angemeldet. Alle dabei notwendigen privaten Einstellungen liegen aber auf dem Server. Und unter "/home/<Benutzer>" befindet sich in Wirklichkeit das Homeverzeichnis des Benutzers auf Arktur. Deswegen ist auch in "/home" auch der ganze Inhalt von "/home" auf Arktur zu sehen. In einer Schule sind dies hunderte von Verzeichnissen.

Aus Erfahrung empfehle ich Ihnen, "/home/adm" und "/home/tmp" auf eigene Verzeichnisse "/Arkturpub" und "/Arkturtmp" zu legen. Es macht auf die Dauer keinen Spass, diese beiden immer wieder durch langes Scrollen suchen zu müssen.

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.

Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also [[Installationshandbuch:SuSELinux]] oder [[Installationshandbuch:DebianLinux]]).

----
<div align="right">[[Administratorhandbuch|zurück]] | [[Hauptseite]]</div>

Schoffer am 4. November 2005 um 20:34 Uhr

2005-11-04T20:34:20Z

← Nächstältere Version		Version vom 4. November 2005, 22:34 Uhr
Zeile 115:		Zeile 115:
	Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also [[Installationshandbuch:SuSELinux]] oder [[Installationshandbuch:DebianLinux]]).		Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also [[Installationshandbuch:SuSELinux]] oder [[Installationshandbuch:DebianLinux]]).


	~~== PCNFS ==~~

	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 Arktur-Schulserver 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).

	~~'''Achtung:''' Schalten Sie PCNFS nur ein, wenn Sie es wirklich benötigen! Für Clients mit Linux wird es nicht benötigt.~~

	----		----
	<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>		<div align="right">[[Administratorhandbuch\|zurück]] \| [[Hauptseite]]</div>

Schoffer: pcnfs entfernt

2005-11-04T20:32:09Z

pcnfs entfernt

Neue Seite

__NOTOC__
{{zumTest}}

{| align="center" border="0" cellpadding="5" cellspacing="2" style="border: 1px solid #AFAFAF; background-color: #FCFCFC; border-left: 5px solid #AFAFAF"
|-
| style="font-size: 95%;" | NFS wird auf dem Arktur-Schulserver in Verbindung mit der Anmeldung mittels LDAP genutzt. Die aus älteren Arkturversionen stammende Anmeldung per NIS wird nicht mehr unterstützt.
|}

== Der NFS Server ==

=== Was ist NFS? ===

NFS, das "Network File System", ist eine Client-/Server-Applikation, welche entfernte Laufwerke (von einem Server) für den lokalen Rechner (den Client) transparent zur Verfügung stellt. Der Nutzer bekommt im Normalfall überhaupt nicht mit, das er seine Daten gar nicht "lokal" speichert oder lädt, sondern sie über das Netzwerk zum Server übertragen und von dort geladen werden. Dafür werden verschiedene Programme genutzt, die für eine konsistente Dateiübertragung sorgen.

NFS basiert auf dem RPC (remote procedure call) Protokoll, welches ursprünglich 1980 (!) von Sun Microsystems entwickelt wurde, um Filesharing auf Unix-Plattformen zu ermöglichen.

=== Was ist die Gefahr von NFS? ===

Normalerweise benutzen die von NFS eingesetzten Programme keine weiteren Mittel um die Authentizität der Benutzer zu überprüfen. Das macht das System so gefährlich.

Einerseits ist hierfür sicherlich das benutzte Übertragungsprotokoll UDP verantwortlich, welches als "zustandsloses" Protokoll keine Möglichkeit bietet, die Verbindung zwischen zwei Stationen zu überprüfen. Das macht das UDP-Protokoll zwar wesentlich schneller als das heute sehr bekannte TCP Protokoll und war seinerzeit sicherlich auch der Hauptgrund für Sun Micosystems auf diese Übertragungstechnik zu setzen (weniger "Protokoll" = weniger Serverbelastung) - allerdings mussten so auch zusätzliche Sicherungsmassnahmen eingeführt werden, um auch nur eine sichere Übertragung der Pakete sicherzustellen: so versucht NFS für jeden ausgesendeten Befehl eine Anwort zu bekommen. Bleibt diese aus, so wird der Befehl immer wieder wiederholt. (Anmerkung: bei TCP ist das Verfahren zwar ähnlich - setzt aber schon auf "Protokollebene" an; der das Protokoll nutzende Dienst braucht sich darum nicht zu kümmern.)

=== NFS-Server einrichten ===

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 Arktur-Schulserver gesagt werden, welche Verzeichnisse er wie freigeben soll. Das geschieht in der Datei ''/etc/exports'' . Die folgende Abbildung enthält ein Beispiel für diese Datei an einem Arktur-Schulserver:

# /etc/exports beim Arktur-Schulserver
# 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.rg1.dd.sn.schule.de(ro)

:''Abbildung: Beispiel für /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='''r'''ead-'''o'''nly, also zur zum Lesen freigegeben. Das Home-Verzeichnis hingegen wird mit der Option rw='''r'''ead&'''w'''rite, 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.

Zusätzlich lassen sich noch einige Sicherheitsattribute setzen:

'''secure ''' Hier werden nur Anfragen von einem hohen Port an einen niedrigeren (und damit priviligierten) Port erlaubt. Damit wird die Gefahr verringert, dass ein normaler Nutzer einen NFS-Server aufsetzt und diesen dann mit ihrem Server "unter gleichen" reden läßt. Diese Einstellung ist zwar Standard - Sie ausdrücklich zu setzen beruhigt aber auf jeden Fall das Gewissen.

'''noaccess '''Mit diesem Parameter können Unterverzeichnisse eines exportierten Verzeichnisses gesperrt werden.

'''link_relative '''Hiermit werden vorhandene Links relativ zum eigentlichen Root-Verzeichnis des Servers gesetzt. Sollte der Server z.B. mit einer Chroot-Umgebung laufen, so würden Links auf das reale Dateisystem des Servers sonst ins Leere zeigen.

'''link_absolute '''Hier werden die Links im exportierten Verzeichnis absolut gesetzt. Ein "relativer" Link auf dem Server wird dem Client also als "absolut" vorgegaukelt.

'''root_squash '''Standardeinstellung: Hier wird der Nutzer root des entfernten Systems behandelt, als wäre er nobody. Damit bekommt ein Hacker von einem fremden Rechner keine Möglichkeit sich auszubreiten.

'''no_root_squash '''Hier hat der Nutzer "root" des fremden Systems dieselben Rechte wie der lokale root.

'''squash_uids''' und '''squash_gids '''Mit dieser Option können bestimmte UIDs und GIDs vom fremden System behandelt werden, als wären sie "nobodys" - was sich besonders bei Systemaccounts als nützlich erweist. Beispiel: squash_uids=0-499 Läßt alle Anfragen von Nutzern mit einer ID kleiner als 500 nur als "nobodys" zu.

'''all_squash '''Alle UIDs werden "gesquasht", d.h. dem Nutzer nobody angerechnet. Damit haben alle fremden Nutzer die geringsten Rechte.

'''map_daemon '''Damit werden UIDs und GIDs vom entfernten System dynamisch an die im lokalen System vorhandenen angepasst. Ein Nutzer "lars" auf dem entfernten System bekommt dann dieselben Rechte wie der lokale "lars" - auch wenn dieser eine andere Nutzer-ID hat. Allerdings muß dazu auf beiden Systemen der rpc.ugidd laufen.

'''map_static '''Hiermit wird ein statisches Mapping eingeführt. Dazu muss eine Datei mit den entsprechenden Zuweisungen vorhanden und als Parameter angegeben sein. Ein Beispiel: ''map_static=/etc/nfs/foobar.map'' Die Datei ''/etc/nfs/foobar.map'' könnte dann so aussehen:

# Mapping for client foobar:
# remote local
uid 0-99 - # squashen - also eigentlich keine Rechte
uid 100-500 1000 # Mappe die UIDs von 100-500 nach 1000-1400
gid 0-49 - # Gruppen squashen
gid 50-100 700 # Mappe Gruppen mit IDs von 50-100 nach 700-750

'''anonuid''' and '''anongid '''Hiermit werden die UIDs und GIDs für den Nutzer nobody und die entsprechende Gruppe festgelegt.

'''no_exec '''Das Dateibit für ausführbare Dateien wird im entfernten System nicht gestattet: aus diesem exportierten Verzeichnis heraus dürfen keine Programme aufgerufen werden.

'''no_suid '''Das setzen des "User-ID"-Bits wird nicht gestattet. Dateien können nur mit den Rechten des jeweils angemeldeten Benutzers ausgeführt werden.

'''no_sgid '''Das setzen des "Group-ID"-Bits wird nicht gestattet. Dateien können nur mit den Gruppen-Rechten des angemeldeten Benutzers ausgeführt werden.

=== NFS-Server einschalten ===

Das NFS-Protokoll aktivieren Sie über das Menü "Verwalten" -> "Netzdienste" und dort "NFS-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# /etc/init.d/nfsserver stop
root@Arktur# /etc/init.d/nfsserver start

=== 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, also hier ''/opt/adm'' . Wenn das Verzeichnis, welches 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
Arktur:/var/spool/mail /var/spool/mail nfs nodev,nolock 0 0
Arktur:/cdrom /media/cdrom nfs nodev,nolock 0 0

:''Abbildung: Beispiel für die /etc/fstab auf dem Client''

So können Sie also das Homeverzeichnis und das Mailverzeichnis vom Arktur-Schulserver allen Clients zur Verfügung stellen. 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.

Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also [[Installationshandbuch:SuSELinux]] oder [[Installationshandbuch:DebianLinux]]).

== PCNFS ==

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 Arktur-Schulserver 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).

'''Achtung:''' Schalten Sie PCNFS nur ein, wenn Sie es wirklich benötigen! Für Clients mit Linux wird es nicht benötigt.

----
<div align="right">[[Administratorhandbuch|zurück]] | [[Hauptseite]]</div>