Ein Netzwerk Datei System erlaubt es auf Ressourcen die auf irgend ein Rechner vorhanden sein zurückzugreifen.
Damit kann ein Anwender, transparent, mit den üblichen Mitteln seinen Betriebssystem Dateien Lesen, Erzeugen, Ändern, Berzeichnisse Anlegen usw.
Die Einbindung der Resourcen kann mittels verschiedene Verfahren erfolgen. mit iSCSI wird eine Festplatte oder eine Partition als SCSI Gerät behandelt, wobei die Daten über das Netzwerk ausgetaucht werden. Solch einer Einbindung ist nicht für den Zugrif von verschiedene Systeme geeignet, es ist äquivalent zur Zugriff mittels USB oder Fireware.
Damit mehere Anwender, von verschiedene Resourcen die über das Netzwerk bereithestellt werden zurückgreifen können müssen kompliziertere Verfahren angewandt werden die sowohl auf den Klient wie auch auf den Server die Einbindung auf eine höhere Ebene als die die von iSCSI verwendet wird, erlauben.
Mit iSCSI werden Befehle wie Lese Daten asu Sektor 5 im 2. Zlylinder.
Wenn mehere solche Befehle aus verschiedene Rechner kommen, ist die
Gefahr einen Datenverlist sehr groß, zumal die einzelne Systeme nicht
von andere Operationen erfahren.
Netzwerk Datei Systeme müssen dementsprechend dafür sorge tragen, dass
die normale Operationen vom Kernel des Servers verwaltet werden und
dieser hat dafür zu sorgen, dass es nicht zu Probleme kommt.
Die Klients müssen natürlich auch erfahren das Resource verändert wurden.
Ein sehr großen Anzahl an Netzwerk Datei Systemen ist vorhanden, jeder ist dabei mehr oder weniger für ein bestimmten Einsatzgebiet entwickelt worden.
Neben Veteranen wie NFS oder SMB die für den Einsatz im geschlossene Netze konzipiert wurden, sind auch Systeme die für den Zugriff über öffentliche Netze ausgelegt sind, z.B. sshfs oder Coda. Weiterer Systeme können als ein Art Raid Verbund betrachtet werden wobei der Zugrif entweder in ein Locales hochgeswindigkeits Netzwerk GlusterFS oder über das Internet erfolgen kann (Cloud). Andere verwenden die gleiche Resourcen wie das WEB (WebDAv) und ermöglichen es Dokumenten mit andere zu teilen oder nur zu sichern.
Ein Netwerk Datei System erlaubt es auf Verzeichnisse, die auf entfernten Rechner sich befinden, genauso zurückzugreifen wie auf Verzeichnisse die sich auf der Festplatte des Rechners befinden.
Der Zugriff auf einen Netzwerk Datei System kann auch benutzt werden um Daten zu archivieren oder auf ein besonders sicheren Medien (RAID Verbund) welches über das Netzwerk ansprechbar ist, zu bringen.
Wenn ein Anwender Daten über das Netzwerk zur Verfügung stellen oder auf diese ein Zugriff haben will, ist unter verschieden Szenarien zu unterscheiden.
Der Zugriff auf die Daten kann abhängig von einer Login Prozedur, in diesem Fall kann der Anwender nur auf die Daten des "eingeloggten" Anwender Schreibend zurückgreifen (falls nicht in Nur-Lese Modi eingebunden) und gegeben falls lesend auf Daten anderen Teilnehmern.
Entsprechend diese Anforderungen bieten sich verschieden Möglichkeiten an.
Weitere Netzwerk Dateisysteme, wie AFS, Coda, WebDav XtreemFS usw. sind auch vorhanden. Diese Dateisystemen sind für sehr speziellen Zwecke ausgelegt oder bedürfen ein zu großen Installation/Konfiguration Aufwand.
Der einfachsten Fall, die Daten gehören nur ein einzigen Anwender, bedarf keine großartige Infrastruktur oder besondere Vorkehrungen. Als Dateisystem (oder virtueller Dateisystem) bietet sich z.B. sshfs. Sshfs ist mittels ein FUSE Modul (Datei System im Anwendungsbereich) implementiert. Ein großen Vorteil ist, dass damit der Anwender keinen Root-Rechte um das entfernte Verzeichnis einzubinden benötigt.
Sind auf das entferntes System Daten von mehrere Anwendern, ist dagegen ein System welches mit der vollständige Verwaltung von Rechte und Anwendern umgehen kann ein Muss.
Damit das ganzes funktioniert müssen die Anwenderkennungen und Gruppen auf beide Systeme (Lokaler und entfernen) identisch sein. NFS bietet das notwendiges hierfür. GlusterFS bietet auch solche Möglichkeiten an. Da Glusterfs auf der Client-Seite FUSE verwendet kommen in erster Linie Linux Rechner oder solche für den es schon ein Port von FUSE vorhanden ist, z.B. Solaris, FreeBSD, Mac OS X in Frage.
Eine Sonderstellung nimmt RemoteFS ein. RemoteFS funktionniert ähnlich wie Sshfs, hat aber den Vorteil das die Eingentümmern und Gruppen so gut wie möglich auf der Workstation abgebildet werden.
Dateien die den Anwender nicht gehöhren, werden je nach Konfiguration des
Klient nobody, nogroup oder root zugeordnet.
oder dank ein NSS Module werden die Anwender und
Gruppenname des entferntes Rechner auf den Arbeitsplatzrechner angeboten,
aber nur wenn die Objekte sich unterhalb des eingebundenes Verzeichnis
sich befinden.
Die Berechtigung für denn Zugriff auf bestimmte Resourcen kann sowohl auf den Klient wie auf den Server stattfinden.
Bei Login basierte Systeme wird die Berechtigung auf den Server vorgenommen.
Bei nicht Loginbasierten Netzwerk Datei Systeme kann die Berechtigung auf den Klient ausgelagert werden, Voraussetzung hierfür ist nur dass, Eigentümer Gruppen der Resourcen den Klient bekannt sind. Bei einen erlaubten Zugriff der die Daten ändern muss aber sichergestellt werden dass die Rechte Server seitig korrekt gestellt werden (Anwender/Gruppe).
Ein gemischten Betrieb ist auch denkbar, eine Vorabprüfung der Zugriffsrechte erfolgt auf den Klient, damit kann den Zugriff auf das Netwerk vermieden werden, die entgültige Prüfung erfolgt auf den Server.
Bei nicht login basierten Netwerk Datei Systeme müssen die Anwendern und Gruppen normalerweise auf den Klient und den Server identisch sein.
Durch das sogennante ID-Mapping kann erreicht werden dass eine Synchronisierung der Anwender und Gruppen Kennungen sich errübrigen. Dies wird von NFS Version 4 angeboten, ist aber noch nicht wirklich funktionsfähig.
Bei Login basierten Netwerk Datei Systeme wird ein recht einfaches Mapping vorgenommen, der Server läuft mit der Kennung des Anwenders, auf den Klient werden alle Resourcen den Anwender zugeordnet, wass zu verwierende Reaktionen führen kann (Datei X gehört scheinbar den Anwender aber eine Verändrung schlägt wegen mangelden Rechte fehl).
Bei Remotefs werden die Anwender- und Gruppennamen beim einbinden des entferntes Verzeichniss übertragen und stehen somit zur Verfügung. Passende UID Bzw GID werden fabei erzeugt. Diese Betriebsart ist allerdings abhängig von der Installation und Arbeitsmodus von Remotefs.
Wenn die Datei /etc/resolv.conf ein speziellen Eintrag nicht beinhaltet werden unbekannten Name auf z.N.nobody abgebildet.
Auf Wunsch kann der Anwender einer Zusatz-Komponente rfs_nss auf den Klient starten, mit diese Komponente werden die login ung gruppen Namen, auch wenn sie eingentlich im System unbekannt sind, richtig ausgegeben.
Sshfs basiert auf das ftpfs Protokol und verwendet ssh um den Datentransfer zu verschlüsseln. Das Einbinden kann als normaler Anwender erfolgen.
Eine Verzeichnis zum Einbinden der entfernte Verzeichniss ist anzulegen, z.B. /home/anton/mnt.
Nachstehend sind 3 Beispiele aufgeführt, diese sollte auch aufzeigen wie wichtig es ist, im Netzwerk, eine saubere Verwaltung der Anwender und Gruppen zu haben.
$ sshfs anton@local-server /home/anton/mnt anton@local-server password:
$ ls -l mnt -rw-rw---- 500 500 20 1. Mai 15:35 datei -rw-rw---- 502 502 21 1. Mai 15:37 kuckucksei
$ sshfs anton@local-server /home/anton/mnt -o idmap=user anton@local-server password:
$ ls -l mnt -rw-rw---- anton 500 20 1. Mai 15:35 datei -rw-rw---- anton 502 21 1. Mai 15:37 kuckucksei
$ id uid=1000(anton) gid=1000(anton) Gruppen=1000(anton) $ $ sshfs anton@local /home/anton/mnt -o uid=1000,gid=1000 anton@local-server password:
$ ls -l mnt -rw-rw---- anton anton 20 1. Mai 15:35 datei -rw-rw---- anton anton 21 1. Mai 15:37 kuckucksei
Die Eigentümer/Gruppe werden entsprechend an sshfs übergebene Optionen angezeigt.
Es ist zu bemerken, dass das kuckucksei nicht verändert/gelöscht werden kann, auch wenn das Besiztum scheinbar stimmt.
Wenn die Eingentümern und Groupen auf beide Rechner übereinstimmen, sieht die Welt, mit den ersten Aufruf (ohne Option) richtig aus,
$ sshfs anton@local-server / mnt anton@local-server password: $ ls -l mnt/home drwxr------ 1 anton anton 4096 24. Jan 13:53 anton drwxr------ 1 bert bert 4096 27. Jan 19:42 bert
$ fusermount -u mnt
Dies ist eine sehr schlechte Idee, neue Dateien und Ordner werden den Anwender root zugeordnet, damit ist diese Vorgehensweise ungeeignet. Sshfs basiert auf ein FTP Protokol welches Anwender und Gruppen account nicht unterstüzt.
Ein Nachteil von sshfs ist dass die Übertragung der Daten nicht gerade schnell erfolgt. Durch der Verschlüsselung wird sehr viel Zeit in Anspruch genommen so dass auf Leistungsschwache Hardwäre wie z.B. NAS Geräte für den Heimbereich die Performance nicht gerade berauschend ist.
Remotefs ist ein schnelles Dateisystem und soll es ermöglichen, auf Leistungsschwachen Geräte die für den Einsatz im Heimvereich konzipiert wurden, wie z.B. Network Attached Storage (NAS), einer optimale Anbingung zu gestatten.
Remotefs läuft auf verschiedene POSIX Systeme wie Linux, OpenSolaris, FreeBSD und Mac OS X.
Remotefs eignet sich auch um, über das Internet, auf den Server zurück zugreifen. Für diesen Einsatzzweck wird die Verbindung mittels SSL geregelt. Die Übertragungsrate ist natürlich wesentlich geringer als bei eine unverschlüsselte Anbindung aber besser als mit sshfs
Remotefs unterstüzt IPv6 Verbindungen.
Remotefs unterstüzt POSIX ACL.
Die am weitesten fortgeschrittene Version wird bei sourcefoge.net gehostet. Die Sourcen sollten mit svn installiert werden:
$ svn co https://remotefs.svn.sourceforge.net/svnroot/remotefsNach dem Herunterladen im Verzeichnis remotefs/trunk/Makefiles wechseln und die Datei options.mk gegebenfalls anpassen (IPv6 / ACL, ...) aktivieren.
Nach dieser Schritt im Verzeichnis remotefs/testing wecheln und
$ make client; sudo make installaufrufen. Auf den server
$ make server; sudo make install
Remotefs benötigt die Dateien /etc/rfs-passwd und /etc/rfs-exports.
Die Datei rfs-passwd beinhalten die md5 kodierten Passwörter für den berechtigten Anwender. Sie wird mit das Dienstprogram rgspasswd verwaltet.
Die Datei /etc/rfs-exports beinhaltet die Verzeichnisse die zu exportieren sind sowie die zugelassenen Anwender und das Exportmodus
/home/alice alice (user=alice,group=alice) /home/bob bob () /shared/filme 10.1.1.1, 10.1.1.2 (ro) /shared/dokumente alice, bob (ugo)
Die einzige Datei die vorhanden sein muss ist eine Datei die das Passwort des Anwenders beinhaltet. Diese Datei sollte passend geschützt sein (kein Leserechte für die Gruppe und den Rest der Welt). Damit wird vermiden dass das Passwort als Argument rfs übergeben wird und damit in Klartext erscheint.
Die Logindaten werden verschlüsselt über das Netzwerk ausgetauscht so dass das Passwort nicht entschlüsselt werden kann.
# unverschlüsselt: rfs -ousername=anton,passwd=passwortDatei server:/share ~/priv_mnt # verschlüsselt rfs -ousername=anton,passwd=passwortDatei,ssl server:/share ~/priv_mntDie Datei passwortDatei beinhaltet das Passwort zur Berbindung mit der Server. Diese Datei sollte nicht von andere Anwendern esbar sein.
Im SVN befindet sich die Komponente rfs_nss. Diese Komponente erlaubt es Name die auf den Klient nicht bekannt sind ttozdem aufzulösen.
Die Namensazlösung unter UNIX® wird unter Verwendung von NSS Name Service Switch vorgenommen. In der Datei /etc/nsswitch.conf werden Module für die verschiedene Zwecke aufgelistet. rfs_nss stellt solch ein Modul zur Verfügung.
Dieses Modul (rfs) muss in der Datei /etc/nsswitch.conf eingetragen werden.
passwd: files rfs group: files rfsDer Eintrag rfs muss der letzten Eintrag in einer Zeile sein,
Der Server rfs_nss muss auf den Klient gestartet wetden, er liefert die Daten den Applicationen die falls eine UID oder GID in ein Name auflösen wollen, die NSS Modulen aufrufen.
Der Server rfs_nss kann mitgeteilt werden dass ein User oder eine Gruppe anzulegen sind, rfs_nss generiert dazu eine passende UID oder GID und kann dann die Namen die an sonst nur den remotefs Server bekannt umsetzen so dass diese, zb mit "ls -l Datei" angezeigt werden.
Damit das ganzes funktionniert muss natürlich ein Weg zur Bekanntmachung vorhanden sein. Auf den Remotefs Server ist ein weiteren Server zu starten, rfs_nss_rem, auf der Client muss die Applikation rfs_nss_get aufgerufen werden.
Diese Funktionalität wird in einer zukünftige Version von remotefs integriert
Die Daten über Anwender und Gruppen werden nur im Speicher gehalten, dies bedeutet dass, rfs_nss_get nachdem rfs_nss gestartet wurde aufgerufen werden muss.
Die Anwender und Gruppen Namen können mit rfs_nss auf verschiedene Art und Weise dargestellt werden, die Namen wie auf den Server werden so wie sie sind angezeit, die Namen werden zur Kennzeichnung dass es sich um Namen die nur auf den entfernten Rechner gültig sein mit einer Kennung ergänzt.
$ ls -l mnt/home drwxr------ 1 anton anton 4096 24. Jan 13:53 anton drwxr------ 1 bert bert 4096 27. Jan 19:42 bert
$ ls -l mnt/home drwxr------ 1 anton anton 4096 24. Jan 13:53 anton drwxr------ 1 bert@nas.home-net bert@nas.home-net 4096 27. Jan 19:42 bert
Da der Anwender den Name Anton besitzt wird sein Name nicht umgesetzt, dagegen werden andere Namen mit @<server name> ergänzt,
Wenn die ACL Unterstützung konfiguriert wurde, ist den Zugriff auf gemeinsame Dateien leicht möglich und die Zugrifsrechte können gezielt vergeben werden.
Damit kann zum Beispiel im Ordner GemeinsameDaten Dateien vorhanden sein auf den Anton sowie Bert Schreib- und Leserechte besitzen, Christian keinerlei Rechte besitz und Dieter nur Leserecht hat.
$ getfacl -t mnt/GemeinsameDaten/datei # file: datei # owner: anton # group: anton user::rw- user:anton:rwx user:bert: rwx user:christian: --- user:dieter: r-x group::--- mask::rw- other::---
SMB ist eigentlich nicht vernünftiges und sollte nur zum Zugriff auf Windows verwendet werden.
Moderne Linux Distributionen bieten vom Haus aus die Möglichkeit solche Shared Laufwerke zur Verfügung zu stellen oder einzubinden. Die Dateien Manager unterstützen das Einbinden als virtualen Dateisystem.
Die Linux Rechner im Netzwerk können über samba Dienste anbieten. Die Einrichtung einen demensprechenden Server sollte kein Problems sein, die default Konfigurations dateien sind weitgehend korrekt konfiguriert. Das Paket samba ist zu installieren.
CIFS beinhaltet, zum mindest unter aktuelle Distributionen eine gute Einbindung der POSIX Rechte und ACL, und könnte daher auch in einen Linux Verbund verwendung finden.
Zur Konfiguration existieren auch graphische Oberfächen z.B. unter Fedora das Packet system-config-samba Unter Ubuntu ist eine passende Tool, sofern Samba installiert wurde, auch vorhanden.
Störend ist demnoch die nicht optimaler Einbindung in der UNIX Welt und einige kleine Fehlern die das Leben nicht einfacher gestalten.
NFS wurde von Sun entwickelt und basiert auf RPC (Remote Protocol Call = Aufruf Entfernte Prozeduren).
Da NFS für UNIX Systeme entwickelt wurde, kennt diese Netzwerk Datei Systeme auch die Rechte die auf lokale Verzeichnisse vorhanden sind.
Unter Unix Systeme habe Anwender zwar ein Name, dieses ist aber unbedeutend eine numerischen Wert (UID) wird zur Kontrolle der Zugriffsberechtigung herangezogen. Im übrigens gilt ähnliches für Windows, die UID ist in diesem Fall ein wenig komplitierten aufgebaut und sollte Weltweit eindeutig sein.
Wenn NFS verwendet wird ist sicher zu stellen das die uid Netzwerkweit gültig sind. anton@rechner-a mit uid 500 ist nicht identisch mit anton@rechner-b mit uid 1000.
Mechanismen und tools wurden herstellt um die Anwender Daten konsistent zu halten:
NFS befindet sich immer noch in der Entwicklung. Nach NFS 1 folgte
NFS 2 und schliesslich NFS 3.
Diese 3 Versionen unterscheiden sich auf Protokol Ebene. Für den Administrator
sind sie beinahe identisch.
POSIX-ACL werden (zum mindest mit NFS v3) unterstüzt.
Nachteil Von NFS 1 bis 3 ist dass die Verschlüsselung der Daten nicht vorgesehen ist und dass eine Authentifizierung (der Rechner) nicht vorgesehen ist
Die neueste Version, NFS 4, ist eine Weiterentwicklung des alten Versionen, unterscheidet sich aber in einiges.
Vorteile von NFS 4 sind:
NFS 4 hat allerdings einigen Nachteilen, die IPv6 Unterstützung ist nicht unter Linux gegeben, NFS4 ACL funktionnieren nur wenn das Dateisystem Serverseitig dieses Model unterstützt (für Linux Dateisystem ungeeignet).
Weitere Besonderheit:
Client-seitig ist die Einbindung von nfs recht einfach. es muss lediglich eine Verzeichniss vorhanden sein unter welches das entferntes Verzeichnis eingebunden wird und ein Eintrag in der Datei /etc/fstab
lisa:/home/anton /home/anton nfs auto,defaults,noatime,async,acl 0 0
Die Konfigurationsarbeiten sind geringfügig höher aber überschaubar.
Diese Datei beinhaltet eine Liste der Verzeichnisse die über das Netzwerk erreichbar sein sollen
/home/anton *.intranet(rw,squash_uids=0-499,squash_gids=0-499)
Wenn diese Datei verändert wurde kann mit das Kommando
# exportfs -r
den Server beauftragt werden diese Datei neu zu lesen und die vorgegebene Verzeichnisse zu exportieren.
Die Optionen squash_*=0-499 bewirken, dass Anwendern
und Gruppen mit UID respektiv GID im Bereich von 0 bis 499 als Anwender
nfsnobody Bzw. nobody auf den Server abgebildet werden. Dies ist ein Sicherheits
relevante Einstellung. Ferner sollte das exportietern Verzeichnis mit den
Rechten dr-xr-xr-x oder rwxrwxrwt
versehenen sein. Im ersten Fall kann niemanden im obersten Verzeichniss schreiben
im 2. Fall können im Verzeichnis Dateien und Ordner angelegt werden, jedoch
nicht mit Sicherheits relevanten UID oder GID.
Falls die Verzeichniss einen normalen Anwender gehöhrt reichen die Rechte
drwxrwxr-x.
Die unterschiede bei der Konfiguration sind gering. Anstelle von nfs wird in der Datei /etc/fstab nfs4 eingetragen und, dass die Pfade für Die Verzeichnisse Relativ zum Orner /exports des Servers anzugeben sind (/export/anton wird /anton)
lisa:/anton /home/anton nfs4 defaults 0 0'
Die Serverprozesse die auf den Client laufen sollen sind rpc.idmapd und, falls die Daten gesichert (verschlüsselt) übertragen werden sollen (Authentizifierung mittels Kerberos) rpc.gssd
Der Server rpc.idmapd soll sicherstellen, dass den richtigen Anwender Name eingesetzt wird (wird anhand der UID ermittelt). Die Konfigurationsdatei /etc/idmapd.conf soll die des Server entsprechen.
[General] Domain = localdomain [Mapping] Nobody-User = nfsnobody Nobody-Group = nfsnobody [Translation] Method = nsswitch
Hauptunterschied beim Einsatz von NFS 4 auf den Server ist, dass ein Speudo File System exportiert wird. Das exportierten Dateisystem bedarf ein eigener Verzeichniss, welches exportiert wird, alle weitere Verzeichnisse werden unter diese Hauptverzeichniss eingebunden.
# mkdir /exports # mkdir /exports/anton /exports/berta # chmod -R 1777 /exports
/home/anton /export/anton none bind 0 0 /home/berta /export/berta none bind,acl=nfs4 0 0
Das Ordner /exports muss genauso wie mit NFS 1 bis 3 in der Datei /etc/exports eingtragen werden:
Die Option acl=nfs4 kann gesetzt werden wenn NFS4 ACL verwendung finden sollen.
/export *(rw,sync,no_subtree_check,fsid=0,squash_uids=0-499,squash_gids=0-499) /export/anton *(rw,sync,no_subtree_check,squash_uids=0-499,squash_gids=0-499) /export/berta *(rw,sync,no_subtree_check,squash_uids=0-499,squash_gids=0-499)
Genauso wie mit NFS 1 bis 3 muss das NFS Server die Änderung dieser Datei bekannt gegeben werden.
# exportfs -r
Die Rechte orientieren sich an den Rechten von Windows Systemen und werden nicht optimal auf die POSIX Rechte abgebildet.
[anton@client.daheim ~] $ nfs4_getfacl dir
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:rxtcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:anton@daheim:rwaDxtcy
A:fdi:berta@daheim:rwaDxtcy
A:fdi:GROUP@:rxtcy
A:fdig:users@daheim:rwaDxtcy
A:fdig:anton@daheim:rwaDxtcy
A:fdi:EVERYONE@:rxtcy
[anton@server.daheim ~] $ getfacl dir
# file: dir
# owner: jj
# group: jj
user::rwx
group::rwx
other::---
default:user::rwx
default:user:anton:rwx
default:user:berta:rwx
default:group::rwx
default:group:anton:r-x
default:group:users:r-x
default:mask::rwx
default:other::---
Bei der Representation der ACL werden 4 Felder benuzt:
TYPES : FLAGS : HAUPTEINTRAG : RECHTE
Auszug aus der Manual Seiten
ACE TYPES:
There are four types of ACEs, each represented by a single character.
An ACE must have exactly one type.
A Allow - allow principal to perform actions requiring permis-
sions.
D Deny - prevent principal from performing actions requiring per-
missions.
U Audit - log any attempted access by principal which requires
permissions. Requires one or both of the successful-access and
failed-access flags. System-dependent; not supported by all
servers.
L Alarm - generate a system alarm at any attempted access by prin-
cipal which requires permissions. Requires one or both of the
successful-access and failed-access flags. System-dependent;
not supported by all servers.
ACE FLAGS:
There are three kinds of ACE flags: group, inheritance, and administra-
tive. An Allow or Deny ACE may contain zero or more flags, while an
Audit or Alarm ACE must contain at least one of the successful-access
and failed-access flags.
Note that ACEs are inherited from the parent directory’s ACL at the
time a file or subdirectory is created. Accordingly, inheritance flags
can be used only in ACEs in a directory’s ACL (and are therefore
stripped from inherited ACEs in a new file’s ACL). Please see the
INHERITANCE FLAGS COMMENTARY section for more information.
GROUP FLAG - can be used in any ACE
g group - indicates that principal represents a group instead of a
user.
INHERITANCE FLAGS - can be used in any directory ACE
d directory-inherit - newly-created subdirectories will inherit
the ACE.
f file-inherit - newly-created files will inherit the ACE, minus
its inheritance flags. Newly-created subdirectories will
inherit the ACE; if directory-inherit is not also specified in
the parent ACE, inherit-only will be added to the inherited ACE.
n no-propagate-inherit - newly-created subdirectories will inherit
the ACE, minus its inheritance flags.
i inherit-only - the ACE is not considered in permissions checks,
but it is heritable; however, the inherit-only flag is stripped
from inherited ACEs.
ADMINISTRATIVE FLAGS - can be used in Audit and Alarm ACEs
S successful-access - trigger an alarm/audit when principal is
allowed to perform an action covered by permissions.
F failed-access - trigger an alarm/audit when principal is pre-
vented from performing an action covered by permissions.
ACE PRINCIPALS:
A principal is either a named user (e.g., ‘myuser@nfsdomain.org’) or
group (provided the group flag is also set), or one of three special
principals: ‘OWNER@’, ‘GROUP@’, and ‘EVERYONE@’, which are, respec-
tively, analogous to the POSIX user/group/other distinctions used in,
e.g., chmod(1).
ACE PERMISSIONS:
There are a variety of different ACE permissions (13 for files, 14 for
directories), each represented by a single character. An ACE should
have one or more of the following permissions specified:
r read-data (files) / list-directory (directories)
w write-data (files) / create-file (directories)
a append-data (files) / create-subdirectory (directories)
x execute (files) / change-directory (directories)
d delete - delete the file/directory. Some servers will allow a
delete to occur if either this permission is set in the
file/directory or if the delete-child permission is set in its
parent direcory.
D delete-child - remove a file or subdirectory from within the
given directory (directories only)
t read-attributes - read the attributes of the file/directory.
T write-attributes - write the attributes of the file/directory.
n read-named-attributes - read the named attributes of the
file/directory.
N write-named-attributes - write the named attributes of the
file/directory.
c read-ACL - read the file/directory NFSv4 ACL.
C write-ACL - write the file/directory NFSv4 ACL.
o write-owner - change ownership of the file/directory.
y synchronize - allow clients to use synchronous I/O with the
server.
Glusterfs ist ein Filesysteme welches es erlaubt ein 1 oder mehere Partitionen als ein Netwerkdateisystem zu betreiben. Dies bedeutet, dass der Anwender alle Daten unter ein Directory (Mount Point) findet, welche Daten auf welchen Rechner gespeichert sind ist für den Anwender nicht ersichtlich. Durch den Aufbau von Cluster, können sehr große Dateisystemen erzeugt werden.
Glusterfs bedient sich client-seitig Fuse. Dies bedeutet dass ein Anwender dass entferntes Dateisysten, genauso wie mit sshfs, ohne Administrator Rechte, einbinden kann.
Nachteil von glusterfs ist, dass eine Unterstützung von IPv6 nicht vorhanden ist, dass die Daten nicht verschlüsselt übertragen werden, und schliesslich dass die Sicherheitsmechanismen gegen das Einbinden der Verzeichniss nur auf IP Ebene stattfindet.
Ein wesentlichen Vorteil ist, dass auf der (die) Server(n), nur ein einzige Daemon laufen muss, auf der Client reicht eine einfache Konfigurationsdatei.
Glusterfs muss von der www.glusterfsfs.org
heruntergeladen und installiert werden.
Als zusätlich notwendige Komponenten auf den Rechner sind neben der Entwicklungsumgebung
build-essensial unter Debian basierte Systeme flex und bison mit das
Packetmanagment der Distribution zu installieren.
# tar xzf glusterfs.1.3.8pre6.tar.gz # cd glusterfs.1.3.8pre6 # ./configure --prefix= # make install
Ein Server mit Gluster mit nur ein Verzeichniss (kein Cluster) aufzusetzen bedarf nur eine einfache Datei im Verzeichnis /etc/glusterfs.
### /etc/glusterfs/glusterfs-server.vol ### Export volume "brick" with the contents of "/home/export" directory. volume brick type storage/posix # POSIX FS translator option directory /home/export # Export this directory end-volume volume server option client-volume-filename /etc/glusterfs/glusterfs-client.vol subvolumes brick #option auth.ip.brick.allow * # Allow access to "brick" volume option auth.ip.brick.allow 10.1.1.* # Allow access to "brick" volume end-volume
Selbstverständlich muss der Daemon glusterfsd laufen. Er kann von Hand wie folgt gestartet werden:
# glusterfsd -f /etc/glusterfs/glusterfs-server.vol
Das Einbinden erfolgt mit:
$ glusterfs -f /etc/glusterfs/glusterfs-client.vol /mnt
Die Datei /etc/glusterfs/glusterfs-client.vol sieht so aus;
volume remote type protocol/client option transport-type tcp/client # for TCP/IP transport option remote-subvolume brick # name of the remote volume option remote-host 10.1.1.1 # IP address of the remote brick end-volume
Anstelle der IP Adresse kann selbstverständlich auch das Netzwerk Name, sofern es vom verwendeten DNS Server aufgelöst werden kann. eingetragen werden.
Mit fusermount kann die Einbindung des Volumes rückgängig gemacht werden.
$ fusermount -u /mnt
Das Volume kann aber auch mit umount freigegeben werden
# umount /mnt
Wenn die passende Einträge in der Datei /etc/fstab vorgenommen werden, kann das Gluster Netzwerk Verzeichnis automatisch eingebunden werden.
mount.glusterfs#/etc/glusterfs/glusterfs-client.vol /mnt/glusterfs fuse defaults 0 0
Das Script mount.glusterfs ist anzulegen und soll natürlich auch gefunden werden. Dieses Script sollte im Ordner /sbin angelegt werden
# echo '/sbin/glusterfs $1 $2' > /sbin/mount.glusterfs # chmod +x /sbin/mount.glusterfs
Wenn auf das Netwerk einen Zugriff über das Internet möglich ist, sollten die Daten über ein passenden sicheren Tunnel transportiert werden.
Eine Datei von glusterfs muss allerdings geringfügig geändert werden, dies
ist eine sehr einfache Sache.
Datei auth/ip/src/ip.c mit den lieblings Editor öffnen un die Zeile:
#define PRIVILEGED_PORT_CIELING 1024
suchen und wie folgt korrigieren:
#define PRIVILEGED_PORT_CIELING 65535.
Dies bewirkt dass die Überprüfung bezüglich zulässiger Port abgeschaltet wird.
Danach muss selbstverständlich glusterfs neukompiliert und installiert werden.
Es bieten sich hier verschiedene Möglichkeiten.
Stunnel in der Version 4.x sollte installiert werden. Diese Version ist für den hier vorgesehenen Einsatz besser geeignet als die vorgehenden Versionen die immer noch bei DEBIAN basierten Systeme eingesetzt werden.
Die übertragung der Daten ist versschlüsselt. In der einfachste Variante wird
lediglich geprüft ob der Server vertauenswürdig ist.
Damit kann jedermann, welches die IP Adresse des Rechners und die Konfiguration
kennt, eine Verbindung zum Server vornehmen. Die Daten werden jedoch verschlüsselt
übertragen so, dass stunnel eine Berechtigung hat.
### /etc/glusterfs/glusterfs-server.vol ### Export volume "brick" with the contents of "/home/export" directory. volume brick type storage/posix # POSIX FS translator option directory /home/export # Export this directory end-volume volume server option client-volume-filename /etc/glusterfs/glusterfs-client.vol subvolumes brick option bind-address 127.0.0.1 # Default is to listen on all interfaces option auth.ip.brick.allow 127.0.0.1 # Allow access to "brick" volume end-volume
Der Client verbindet sich ebenfalls mit der Adresse 127.0.0.1
### /etc/glusterfs/glusterfs-client.vol
volume remote
type protocol/client
option transport-type tcp/client # for TCP/IP transport
option remote-subvolume brick # name of the remote volume
option remote-host 127.0.0.1 # IP address of the remote brick
end-volume
Auf den Server ist ein Zertifikat zu erzeugen, siehe Distributionspezifische Tools.
Unter Fedora 8 kann es wie folgt erfolgen:
# cd /etc/pki/tls/certs # make /etc/stunnel/stunnel-server.pem
; /etc/stunnel/stunnel-server.conf cert = /etc/stunnel/stunnel-server.pem pid = [glusterfsd] accept = 7996 connect = 127.0.0.1:6996
; /etc/stunnel/stunnel-client.conf ; cert = /etc/stunnel/stunnel-client.pem pid = [glusterfsd] accept = 127.0.0.1:6996 connect = 10.1.1.1:7996
# stunnel -f /etc/stunnel/stunnel-server.conf
Bzw.
# stunnel -f /etc/stunnel/stunnel-client.conf
Die Stunnel-Servern müssem sowohl auf den Server wie auf den Client gestartet werden. Gegebenfalls sind entsprechend Scripte zu erzeugen
Bei ssh ist der Zugriff primär Login basiert, dies Bedeutet. Damit es nicht zur Probleme kommt findet einer Überprüfung der IP oder Netwerkname der Rechnern statt.
Das Aufsetzen einen mit ssh gesicherten NFS Server ist ein wenig komplizieter als mit stunnel. Falls jemanden dies tun will, ist eine Beschreibung unter DE-Linux-NFS-HOWTO zu finden.
Der ssh Dämon (sshd) muss zum mindest aud der Server laufen. Dies kann mit den von der jeweiliger Distribution zur Verfügung gestellten Mitteln leicht eingestellt werden.
Damit die Eingabe des Passworts entfällt muss der öffentliche Schlüssel des Client Anwender in der Datei ~/.ssh/authorized_keys enthalten sein.
Falls die Datei ~/.ssh/id_rsa.pub nicht vorhanden ist, muss diese eruegt werden.
root@client/home-net ~ # ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 root@client.home-net
root@client.home-net ~ # cat .ssh/id_rsa.pub | ssh server.home-net 'cat >> .ssh/authorized_keys' password:
Das Tunnel mittels der Port Forwarding Möglichkeit von ssh ist eigentlich sehr einfach, gute Erläuterungen sind aber schwer zu finden.
Hier ist ein Beispiel für glusterfs (Clientseitg):
# ssh -L 6996:localhost:6996 server -f 'sleep 10; do :; done'
-L 6996:localhost:6996 bewirkt, dass einer Verbindung durch glusterfs mit den Port 6996 auf der Adresse 127.0.0.1 (localhost) über ssh an den Server server (zweite Parameter) weitergeleitet werden.
-f bewirkt, dass ssh forken (neuen Prozess erzeugen) soll . Leider geht es nur wenn ein Kommando auszuführen ist, deswegen sind als letzte Parametern 'while sleep 10; do :; done' angegeben. Dies stellt sicher, dass die Verbindung erhalten bleibt. Ssh kehrt nach dem Aufruf zurück.
Serverseitig sollten keine speziellen Vorkerungen notwendig sein. Sshd erkennt, dass er ein Port Forwarding vornehmen muss und leitet das Netwerk Verkehr von Glusterfs auf der lokale Netzwerkschnittstelle (localhost / 127.0.0.1)
Die gluster Konfigurationsdateien sind entsprechend den Beispiel für stunnel auszulegen.
Smb/cifs sowie sshfs sollten IPv6 beherrschen so, dass keine spezielle Vorkerungen notwendig sind.
Nfs und glusterfs, sind zur Zeit für den Betrieb im IPv6 Netz nicht geeignet. Ein Patch ist aber vorhanden und nach dem Einspielen des Patches sollte eine Verbindung über IPv6 problemlos funktionnieren.
Eine einfache Umsetzung (ohne gepatched glusterfs( des IPv4 Protokol auf IPv6 benötigt Helfer die diese Arbeit verrichten.
Falls eine Sicherung (Verschlüsselung) der übertragene Daten nicht notwendig ist kann 46Bouncer verwendung finden.
46Bouncer wurde um die Jahrtausendwende geschrieben und gehöhrt leider nicht zu den Komponenten die mitgeliefert werden.
46Bouncer muss heruntergeladen und kompiliert werden (46Bouncer.zip).
46Bouncer kann nach dem herunterladen wie folgt kompiliert werden:
$ unzip 46Bouncer.zip $ cd Clib $ make $ cd ../46Bouncer $ make
Die Installation sollte im Verzeeichniss /usr/local/sbin oder /usr/local/bin erfolgen. Nach dem kompilieren, als root mittels su oder sudo -s kann dies geschehen:
# cp 46Bouncer/Bouncer /usr/local/bin
Achtung, wenn <CR> in der Datei enthalten ist kommt es zu ein Segmentviolation ! Die vorhandene Beispieldatei 46bouncer.46b sollte nicht verwendet werden das sie <CR>+<LF> als Zeilenende Markierung beinhaltet.
################################################## ##### 46 Bouncer: Configuration file Example ##### ################################################## ######### TIPS ################################### # Sending/receiving interface: not yet implemented # PROTOCOL: TCP or UDP # BOUNCER TYPE: 6TO4 or 4TO6 # # NOTE: the "DESCRIPTION" line indicates the begin # of a new 46Bouncer instance ################################################## [INSTANCE] DESCRIPTION = Gluster Server IPv4 to IPv6 Configuration RECEIVING_INTERFACE = 2001:7f8:a16:1::1 SEND_TO_HOST = 127.0.0.1 RECEIVE_ON_PORT = 6996 SEND_TO_PORT = 6996 MAX_CONNECTIONS = 10 PROTOCOL = TCP BOUNCER_TYPE = 6TO4
Anstelle der Addresse kann natürlich auch den Netzwerkname der Rechnern angegeben werden.
Die Konfiguration von glusterfs ist die gleiche als im Beispiel mit stunnel.
[INSTANCE] DESCRIPTION = Gluster Client IPv4 to IPv6 Configuration RECEIVING_INTERFACE = 127.0.0.1 SENDING_INTERFACE = 2001:7f8:a16:1::2 SEND_TO_HOST = 2001:7f8:116:1::1 RECEIVE_ON_PORT = 6996 SEND_TO_PORT = 6996 MAX_CONNECTIONS = 10 PROTOCOL = TCP BOUNCER_TYPE = 4TO6
Die Konfiguration für den glusterfs Client ist die gleiche wie im Stunnel Abschnitt.
Da ssh mit IPv6 umgehen kann, ist es naheliegend, dass eine Verbindung über ssh und IPv6 eingerichtet werden kann. Die Vorhegensweise ist nicht anders al bei obigen Beispiel. Anstelle des Name kann auch wie im Beispiel die IPv6 Addresse des Server angegeben werden:
# ssh -L 6996:127.0.0.1:6996 2001:7f8:a16:1::1 -f 'sleep 10; done'
Da glusterfs kein IPv6 beherrscht ist die Addresse 127.0.0.1 als lokale Addresse für glusterfsd Bzw glusterfs zu verwenden.
Die Konfigurationsdateien für den Server und der Client können den Abschnitt Konfigurationsbeispiel anhand von Glusterfs entnommen werden.