Was bei NFS3 am meisten nervt, dass nur bestimmt viele Gruppen-IDs zum Rechte-Check beim Server ankommen. (Waren es 12 IDs?) Steckt man in mehr Gruppen, gehen einem dadurch unter Umständen Rechte verloren beim Zugriff auf den Server.
Daher hatte ich schonmal mit WebDAV geliebäugelt. Taugt das als NFS-Ersatz?
Eines der interessanten Features von remotefs scheint der Zugriff über Username statt UserID zu sein.
WebDAv ist nicht wirklich ein Netwerk Datei System. Rechte usw. sind nur auf den Server implementiert und erlauben nicht vieles. Eigentümer ist immer das Prozess auf den Server, mit ein Login erhält man der Berechtigung alles anzustellen oder bestenfalls nur zu lesen. Das Protokoll Overhead ist zudem recht groß.
Wenn du schon vom 21. Jahrhundert sprichst, dann solltest du auch die NFS Version aus dem 21. Jahrhundert nehmen und die ist nunmal Version 4.
NFS4 behebt all die von dir bemängelten Probleme:
- Sicherheit auf Account und Rechnerebene inklusive Single-Sign-On, dank Kerberos. - Einfache Installation, wenn man bereits einen Kerberos Server hat. - NFSACLs, ein Rechtekonzept welches dem von Windows gleicht.
Darüberhinaus ist auch NFS4 immernoch eines der schnellsten Netzwerkdateisysteme auf dem Markt. Natürlich ist NFS kein Protokoll, um mal eben schnell Dateien zwischen zwei Rechnern auszutauschen, aber das war es noch nie - dafür gibt es CIFS. NFS ist und bleibt ein Protokoll für größere Netzwerke und das ist auch gut so. Es gibt schon genug Möglichkeiten um mal kurz Dateien auszutauschen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2010 um 14:17.
NFS 4 hat ein Nachteil, die NFS4-ACL. Für den Austausch mit der Windows Welt mag es gut sein, wenn das eigentliches Dateisystem (ext#,XFS,...) nur POSIX-ACL beherrscht, sind die NFS4-ACL eher störend. Für den Heim Gebrauch oder in kleine Netzwerke reichen normalerweise die POSIX-ACL die dazu noch leicht zu erlernen sind. Ansonsten ist NFS4 eine schöne Sache.
Das NFS4-ACL Posix-ACL Mapping funktioniert eigentlich ganz gut.
Ich sehe das Problem aber eher in den Posix-ACLs an sich - die sind nämlich eine Katastrophe und im wesentlichen völlig nutzlos, weil man keine Rechte-Vererbung erzwingen kann. Man kann zwar Gruppen- und User-Rechte vererben, diese aber nicht erzwingen.
Folgendes Beispiel: Gemeinsames Firmen-Network-Share auf das alle Nutzer zugreifen. Jeder Nutzer soll die Daten des anderen lesen und schreiben können. Bei Posix-ACLs gibt es nun keine Möglichkeit einzustellen, dass automatisch Schreibrechte für eine Gruppe erzwungen werden. Jetzt kann man natürlich für jeden Nutzer eine eigene Gruppe erstellen und dann die umask für die User auf 002 setzen. Schreibt ein Nutzer auf das Firmen-Share wird in diesem Fall die gemeinsame Gruppe via Posix-ACL vererbt und aufgrund der umask auch die Rechte korrekt gesetzt. Soweit der Idealfall.
Ein Problem entsteht genau dann, wenn der User eine Datei auf das Netzlaufwerk kopiert (z.B. von CD-Rom, USB-Stick,...), bei der die Gruppe keine Schreibrechte gesetzt hat. Da beim Kopieren via GUI in der Regel die Rechte der Datei übernommen werden, haben die anderen Mitarbeiter keine Schreibrechte mehr auf die Datei. Im schlimmsten Fall hat nichtmal der User selbst Schreibrechte, weil er das File, z.B. von CD-Rom kopiert hat. Und jetzt erklär mal einem normalen Mitarbeiter, dass er sich selbst und auch den anderen Mitarbeitern Schreibrechte geben muss.
Fazit: Posix-ACLs sind eine komplette Fehlkonstruktion und gehören abgeschafft. Das ist auch einer der Gründe, warum NFS diesen Posix-ACL-Mist nicht verwendet, sonder was eigenes.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Jun 2010 um 23:38.
Das eigentliches Problem ist, dass die gängige Dateisysteme unter Linux nur POSIX-ACL beherrschen. Eine Abbildung POSIX-ACL NFS4-ACL ist laut Meinungen von Leute die sich damit befasst haben (z.B. Grünbacher) unzureichend machbar und auf jeden Fall Problem behaftet. Das Probleme mit den fehlenden Rechte ist tatsächlich ein Problem, ob es mit NFS4-ACL und ein Serverseitigen ext3/4, XFS, ... Dateisystem gelöst ist, ist fraglich. Vielleicht sollte die FAT Treiber für der Gruppe, anstelle von keine Rechte für die Gruppe, das gleiches wie für den Eigentümer vorsehen.
> Das eigentliches Problem ist, dass die gängige Dateisysteme unter Linux nur > POSIX-ACL beherrschen.
Ganz genau, das ist das Problem. Posix-ACLs sind, für das von mir geschilderte Szenario (was ja durchaus nicht konstruiert, sondern ein allerwelts Problem ist), völlig unzureichend.
Damit auch Mitarbeiter mit wenig Computerkenntnissen UNIX Dateisysteme gemeinsam nutzen können, braucht es eine Vererbung ähnlich der, die Windows NTFS bietet. Bei NTFS kann man Rechte auf einen Ordner setzen und diese Rechte werde vererbt, komme was da wolle. Man muss die Vererbung manuell aufheben, wenn man spezielle Rechte auf einen Unterordner haben möchte. Das ist die wesentlich bessere Strategie. Ansonsten ist man als Admin ständig nur am korrigieren der Rechte.
Ein temporärer Workaround wäre möglich, wenn man beim Mounten von UNIX-Dateisystemen eine feste Gruppe und Umask angeben könnte. Dann könnte man wenigstens pro Partition die Rechte erzwingen.
> Eine Abbildung POSIX-ACL NFS4-ACL ist laut Meinungen von Leute die sich > damit befasst haben (z.B. Grünbacher) unzureichend machbar und auf jeden > Fall Problem behaftet.
Ganz klar, NFS4-ACLs können wesentlich mehr als Posix-ACLs. Daher ist die Abbildung natürlich problembehaftet. Es ist aber sehr gut, dass sich NFS4 nicht auf diesen Posix-ACL-Mist eingelassen hat, sondern hier schon für die Zukunft gewappnet ist. Auf die Dauer muss ein Ersatz für Posix-ACLs her. Ansonsten kann man UNIX-Dateisysteme nur für /home-Ordner verwenden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Jun 2010 um 21:25.
die POSIX ACL sind für den Gebrauch im Heimbereich durchaus geeignet. Im Firmenumfeld, sind diese besser als nur die reine UNIX Rechte, aber nicht ausreichend, zumal den Anzahl an Einträge begrenzt ist. Das Problem mit den UNIX-Rechte die beim Kopieren von CD oder FAT-Systeme entsteht ist nicht ein Problem der POSIX-ACL. Ob eine direkte Rechte Vererbung aus der ACL Einträge des Vater-Directory (mehr Rechte als der Quelle-Datei) sinnvoll ist, ist vom Einsatzgebiet und Präferenzen des Anwender abhängig.
AFS sollte sich schnell füllen, viele Daten werden local gespeichert.
Aus: http://www.pro-linux.de/artikel/2/change/1197/comm/450012/1,re4-afs.html AFS ist zu NFS kompatibel, da die AFS-Server das NFS-Protokoll für den Dateitransfer untereinander verwenden.
Die Performance dürfte, bei Dateien die noch nicht auf den Client gelandet sein, ähnlich wie für NFS sein.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2010 um 14:43.
Aber AFS und NFS sind mit Sicherheit nicht kompatibel. Natürlich gibt es für AFS Translatoren, die den AFS-Verzeichnisraum auch NFS-Clienten (oder auch CIFS-Clienten) zugänglich machen. Aber von einem kompatiblen Protokoll kann man bei weitem nicht sprechen.
Vielleicht meint der Autor aber auch, dass beide auf einer Art von UDP-basierten RPC basieren. Das stimmt, aber am Ende sind es ja alles nur elektromagnetische Schwingungen.
AFS ist ein absolut geniales Projekt und ein Traum für jeden Admin. Wenn man die Konzepte mal verstanden hat, wird man verstehen, wieso jeder AFS-Admin die armen NTFS- oder NFS-Admins einfach nur bedauert.
AFS in einem Seriosität beanspruchenden Vergleich nicht einmal zu benennen, zeugt nicht wirklich von Kompetenz. Da helfen auch die buntesten Bildchen nix.
Ansonsten fand ich eben diese schöne Studienarbeit zum Thema: http://www.ks.uni-freiburg.de/download/studienarbeit/SS05/08-05-PVerglNWDS-OHaller/Netzwerkdateisysteme.pdf
Das zitierte Dokument kenne ich. Be den Vergleich ging es um gängige Systeme (cifs/nfs) und 2 Fuse basierte Systeme (glusterfs und remotefs). Diese Systeme sollten leicht von den nicht IT-Spezialist eingerichtet werden können. AFS, Code und co. überfordern den gewöhnlichen Anwender.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jun 2010 um 08:19.
Wenn "leichtes Einrichten" ein Kriterium war, dann mag die Auswahl wohl angemessen sein. Allerdings stand von dieser Anforderung nichts im Artikel. Das sollte man aber reinschreiben, wenn das der Grund ist, die Technologieführer auszuschließen. Am Ende beruft sich noch jemand auf das Dokument und behauptet, dass es nur diese 4 Netzfilesysteme für Linux gäbe. Ich würde auch behaupten, dass die Einrichtung eines samba-Servers einen normalen Anwender überfordert. Mich überfordert es zumindest erheblich mehr als die Einrichtung von AFS.
Es wirde nie behauptet, dass es nur diese 4 Netzwerkdateisysteme für Linux gibt. Auf Linux Rechner sind NFS und SMB standardmäßig vorhanden. Cifs ist auch enthalten, bedarf aber wie NFS ein gewissen Administrationsaufwand. Alle andere Netzwerk Dateisysteme müssen extra installiert und konfiguriert werden. Glusterfs wurde als Vertreter einen FUSE basierte Dateisystem genommen, die Konfiguration ist einfach. Ich hätte auch XtreemFS oder andere Netzwerk Dateisysteme installieren können, der Aufwand war mir aber zu groß. Remotefs ist für den Einsatz im Heimbereich entwickelt und soll auf Hardware mit geringe Performance seine Dienste bieten können.
Das eigentlich getesteten Netzwerk Datei System ist für den Einsatz auf "Krüppelhardware" gedacht. Die verbrauchte CPU Leistung spielt hier ein nicht unermessliche Rolle. Auf Leistungsfähige Hardware kann natürlich die Sache anders aussehen.
Kaum zu glauben aber heute hat man einigen Streß mit einfachen und sicheren Netzwerkfilesystemen unter Unix.
NFS steht ja bekanntlich für No-File-Security:
-Sicherheit nicht auf Account- sondern Rechnerebene - im 21. Jahrhundert total überholt.
-Endlos komplizierte Installation einer abgesicherten Umgebung - in der Zeit habe ich locker zehnmal Windows Server 2008 aufgesetzt.
-Immer wieder Probleme mit ACLs oder anderen erweiterten Rechtekonzepten.
Ja, NFS raw ist schnell und einfach - aber auch extrem leistungsreduziert und unsicher.
Was bei NFS3 am meisten nervt, dass nur bestimmt viele Gruppen-IDs zum Rechte-Check beim Server ankommen. (Waren es 12 IDs?) Steckt man in mehr Gruppen, gehen einem dadurch unter Umständen Rechte verloren beim Zugriff auf den Server.
Daher hatte ich schonmal mit WebDAV geliebäugelt. Taugt das als NFS-Ersatz?
Eines der interessanten Features von remotefs scheint der Zugriff über Username statt UserID zu sein.
WebDAv ist nicht wirklich ein Netwerk Datei System. Rechte usw. sind nur auf den Server implementiert und erlauben nicht vieles. Eigentümer ist immer das Prozess auf den Server, mit ein Login erhält man der Berechtigung alles anzustellen oder bestenfalls nur zu lesen. Das Protokoll Overhead ist zudem recht groß.
Wenn du schon vom 21. Jahrhundert sprichst, dann solltest du auch die NFS Version aus dem 21. Jahrhundert nehmen und die ist nunmal Version 4.
NFS4 behebt all die von dir bemängelten Probleme:
- Sicherheit auf Account und Rechnerebene inklusive Single-Sign-On, dank Kerberos.
- Einfache Installation, wenn man bereits einen Kerberos Server hat.
- NFSACLs, ein Rechtekonzept welches dem von Windows gleicht.
Darüberhinaus ist auch NFS4 immernoch eines der schnellsten Netzwerkdateisysteme auf dem Markt. Natürlich ist NFS kein Protokoll, um mal eben schnell Dateien zwischen zwei Rechnern auszutauschen, aber das war es noch nie - dafür gibt es CIFS. NFS ist und bleibt ein Protokoll für größere Netzwerke und das ist auch gut so. Es gibt schon genug Möglichkeiten um mal kurz Dateien auszutauschen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2010 um 14:17.NFS 4 hat ein Nachteil, die NFS4-ACL. Für den Austausch mit der Windows Welt mag es gut sein, wenn das eigentliches Dateisystem (ext#,XFS,...) nur POSIX-ACL beherrscht, sind die NFS4-ACL eher störend. Für den Heim Gebrauch oder in kleine Netzwerke reichen normalerweise die POSIX-ACL die dazu noch leicht zu erlernen sind.
Ansonsten ist NFS4 eine schöne Sache.
Das NFS4-ACL Posix-ACL Mapping funktioniert eigentlich ganz gut.
Ich sehe das Problem aber eher in den Posix-ACLs an sich - die sind nämlich eine Katastrophe und im wesentlichen völlig nutzlos, weil man keine Rechte-Vererbung erzwingen kann. Man kann zwar Gruppen- und User-Rechte vererben, diese aber nicht erzwingen.
Folgendes Beispiel:
Gemeinsames Firmen-Network-Share auf das alle Nutzer zugreifen. Jeder Nutzer soll die Daten des anderen lesen und schreiben können. Bei Posix-ACLs gibt es nun keine Möglichkeit einzustellen, dass automatisch Schreibrechte für eine Gruppe erzwungen werden. Jetzt kann man natürlich für jeden Nutzer eine eigene Gruppe erstellen und dann die umask für die User auf 002 setzen. Schreibt ein Nutzer auf das Firmen-Share wird in diesem Fall die gemeinsame Gruppe via Posix-ACL vererbt und aufgrund der umask auch die Rechte korrekt gesetzt. Soweit der Idealfall.
Ein Problem entsteht genau dann, wenn der User eine Datei auf das Netzlaufwerk kopiert (z.B. von CD-Rom, USB-Stick,...), bei der die Gruppe keine Schreibrechte gesetzt hat. Da beim Kopieren via GUI in der Regel die Rechte der Datei übernommen werden, haben die anderen Mitarbeiter keine Schreibrechte mehr auf die Datei. Im schlimmsten Fall hat nichtmal der User selbst Schreibrechte, weil er das File, z.B. von CD-Rom kopiert hat. Und jetzt erklär mal einem normalen Mitarbeiter, dass er sich selbst und auch den anderen Mitarbeitern Schreibrechte geben muss.
Fazit: Posix-ACLs sind eine komplette Fehlkonstruktion und gehören abgeschafft. Das ist auch einer der Gründe, warum NFS diesen Posix-ACL-Mist nicht verwendet, sonder was eigenes.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Jun 2010 um 23:38.Das eigentliches Problem ist, dass die gängige Dateisysteme unter Linux nur POSIX-ACL beherrschen. Eine Abbildung POSIX-ACL NFS4-ACL ist laut Meinungen von Leute die sich damit befasst haben (z.B. Grünbacher) unzureichend machbar und auf jeden Fall Problem behaftet. Das Probleme mit den fehlenden Rechte ist tatsächlich ein Problem, ob es mit NFS4-ACL und ein Serverseitigen ext3/4, XFS, ... Dateisystem gelöst ist, ist fraglich. Vielleicht sollte die FAT Treiber für der Gruppe, anstelle von keine Rechte für die Gruppe, das gleiches wie für den Eigentümer vorsehen.
> Das eigentliches Problem ist, dass die gängige Dateisysteme unter Linux nur
> POSIX-ACL beherrschen.
Ganz genau, das ist das Problem. Posix-ACLs sind, für das von mir geschilderte Szenario (was ja durchaus nicht konstruiert, sondern ein allerwelts Problem ist), völlig unzureichend.
Damit auch Mitarbeiter mit wenig Computerkenntnissen UNIX Dateisysteme gemeinsam nutzen können, braucht es eine Vererbung ähnlich der, die Windows NTFS bietet. Bei NTFS kann man Rechte auf einen Ordner setzen und diese Rechte werde vererbt, komme was da wolle. Man muss die Vererbung manuell aufheben, wenn man spezielle Rechte auf einen Unterordner haben möchte. Das ist die wesentlich bessere Strategie. Ansonsten ist man als Admin ständig nur am korrigieren der Rechte.
Ein temporärer Workaround wäre möglich, wenn man beim Mounten von UNIX-Dateisystemen eine feste Gruppe und Umask angeben könnte. Dann könnte man wenigstens pro Partition die Rechte erzwingen.
> Eine Abbildung POSIX-ACL NFS4-ACL ist laut Meinungen von Leute die sich
> damit befasst haben (z.B. Grünbacher) unzureichend machbar und auf jeden
> Fall Problem behaftet.
Ganz klar, NFS4-ACLs können wesentlich mehr als Posix-ACLs. Daher ist die Abbildung natürlich problembehaftet. Es ist aber sehr gut, dass sich NFS4 nicht auf diesen Posix-ACL-Mist eingelassen hat, sondern hier schon für die Zukunft gewappnet ist. Auf die Dauer muss ein Ersatz für Posix-ACLs her. Ansonsten kann man UNIX-Dateisysteme nur für /home-Ordner verwenden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Jun 2010 um 21:25.die POSIX ACL sind für den Gebrauch im Heimbereich durchaus geeignet. Im Firmenumfeld, sind diese besser als nur die reine UNIX Rechte, aber nicht ausreichend, zumal den Anzahl an Einträge begrenzt ist. Das Problem mit den UNIX-Rechte die beim Kopieren von CD oder FAT-Systeme entsteht ist nicht ein Problem der POSIX-ACL. Ob eine direkte Rechte Vererbung aus der ACL Einträge des Vater-Directory (mehr Rechte als der Quelle-Datei) sinnvoll ist, ist vom Einsatzgebiet und Präferenzen des Anwender abhängig.
Andrew File System wo?
Das ist hier keine Suchmaschine. Da musst Du Dich vertan haben.
Er fragt berechtigterweise warum AFS nicht gemessen wurde.
Installation zu kompliziert, ...
schade, ich wollte schon immer wissen wie sich AFS schlägt..
AFS sollte sich schnell füllen, viele Daten werden local gespeichert.
Aus: http://www.pro-linux.de/artikel/2/change/1197/comm/450012/1,re4-afs.html
AFS ist zu NFS kompatibel, da die AFS-Server das NFS-Protokoll für den Dateitransfer
untereinander verwenden.
Die Performance dürfte, bei Dateien die noch nicht auf den Client gelandet sein, ähnlich wie für NFS sein.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jun 2010 um 14:43.Den Link krieg ich nicht angezeigt.
Aber AFS und NFS sind mit Sicherheit nicht kompatibel. Natürlich gibt es für AFS Translatoren, die den AFS-Verzeichnisraum auch NFS-Clienten (oder auch CIFS-Clienten) zugänglich machen. Aber von einem kompatiblen Protokoll kann man bei weitem nicht sprechen.
Vielleicht meint der Autor aber auch, dass beide auf einer Art von UDP-basierten RPC basieren. Das stimmt, aber am Ende sind es ja alles nur elektromagnetische Schwingungen.
Also das letzte mal, als ich AFS installiert habe, war das eine Sache von einer halben Stunde.
Aber da war ich auch noch in der Übung. Mag sein, dass das heute ein wenig komplexer ist, weil man besser ein Kerberos KDC einsetzt.
Vor fast 10 Jahren habe ich darüber auch schon einen Vortrag gehalten:
http://www.clug.de/oldpage/stammtisch/2001-11-09.html
Und wer Zugriff auf die Archive der iX hat, findet darin auch einen Artikel von mir. Dürfte so von 2002 oder 2003 sein.
Das war auch meine allererste Frage.
AFS ist ein absolut geniales Projekt und ein Traum für jeden Admin. Wenn man die Konzepte mal verstanden hat, wird man verstehen, wieso jeder AFS-Admin die armen NTFS- oder NFS-Admins einfach nur bedauert.
AFS in einem Seriosität beanspruchenden Vergleich nicht einmal zu benennen, zeugt nicht wirklich von Kompetenz. Da helfen auch die buntesten Bildchen nix.
Ansonsten fand ich eben diese schöne Studienarbeit zum Thema:
http://www.ks.uni-freiburg.de/download/studienarbeit/SS05/08-05-PVerglNWDS-OHaller/Netzwerkdateisysteme.pdf
Das zitierte Dokument kenne ich. Be den Vergleich ging es um gängige Systeme (cifs/nfs) und 2 Fuse basierte Systeme (glusterfs und remotefs). Diese Systeme sollten leicht von den nicht IT-Spezialist eingerichtet werden können. AFS, Code und co. überfordern den gewöhnlichen Anwender.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jun 2010 um 08:19.Wenn "leichtes Einrichten" ein Kriterium war, dann mag die Auswahl wohl angemessen sein. Allerdings stand von dieser Anforderung nichts im Artikel. Das sollte man aber reinschreiben, wenn das der Grund ist, die Technologieführer auszuschließen. Am Ende beruft sich noch jemand auf das Dokument und behauptet, dass es nur diese 4 Netzfilesysteme für Linux gäbe.
Ich würde auch behaupten, dass die Einrichtung eines samba-Servers einen normalen Anwender überfordert. Mich überfordert es zumindest erheblich mehr als die Einrichtung von AFS.
Es wirde nie behauptet, dass es nur diese 4 Netzwerkdateisysteme für Linux gibt. Auf Linux Rechner sind NFS und SMB standardmäßig vorhanden. Cifs ist auch enthalten, bedarf aber wie NFS ein gewissen Administrationsaufwand. Alle andere Netzwerk Dateisysteme müssen extra installiert und konfiguriert werden. Glusterfs wurde als Vertreter einen FUSE basierte Dateisystem genommen, die Konfiguration ist einfach. Ich hätte auch XtreemFS oder andere Netzwerk Dateisysteme installieren können, der Aufwand war mir aber zu groß. Remotefs ist für den Einsatz im Heimbereich entwickelt und soll auf Hardware mit geringe Performance seine Dienste bieten können.
wie wurden die graphen erstellt? sehen super aus.
Anhand der Farben und der sonstigen Erscheinung tippe ich auf OpenOffice Calc
Schade, dass der Test mit solcher Krüppelhardware durchgeführt wurde. Server mit 128 MB RAM, 100Mbit-Schnittstellen...
Das eigentlich getesteten Netzwerk Datei System ist für den Einsatz auf "Krüppelhardware" gedacht. Die verbrauchte CPU Leistung spielt hier ein nicht unermessliche Rolle. Auf Leistungsfähige Hardware kann natürlich die Sache anders aussehen.
Selten einen so lieblos aus dem Englischen ins Deutsch übersetzten Text gelesen. Das macht echt keinen Spaß.
ins Deutsche
Der Text wurde nicht übersetzt, eine englische Fassung gibt es auch nicht!