Hi Gute Sache daß . Bin mal gespannt, wann die ersten BIN Packages rauskommen. Bei meinem GLück aus den Sourcen zu installieren, geht danach wieder nix Gruß Marcus der Werner
Leider kann ich immer noch nicht verstehen, dass es Menschen gibt, die Samba nutzen für Datei-Freigaben. Das SMB-Protokoll ist mit Abstand das schlechteste, was ich je zu Gesicht bekommen habe. Die Fehleranfälligkeit des Protokolls ist fast schon legendär. Es reichen nur wenige Aussetzer an der Line um die Clients dauerhaft vom Netz abzuschneiden. Bei unseren Versuchen reichte es 10x hintereinander ein korruptes SMB-Paket zu senden und die Clients haben die Shares _dauerhaft_ verloren. Erst ein Reboot hat sie wieder zum Leben erweckt. Nicht sonderlich glücklich...
Sicherlich ist NFS eine Alternative allein schon darum weil es Benutzerrechte kennt. Aber SMB hat etwas was NFS nicht hat: Passwortschutz von Shares. Mit Usernamen und Passwort kann man NFS nicht so schützen wie dies bei SMB der Fall ist.
Von Robert Penz am Do, 25. September 2003 um 10:55 #
nimm lieber afs ... genauer gesagt open afs. wenn dich auskennst ist das teil viel viel mächster als samba und nfs zusammen (z.b. daten auf verschienden servern verteilen)
"Sicherlich ist NFS eine Alternative allein schon darum weil es Benutzerrechte kennt."
Grmbl, NFS ist ein einziges Sicherheitsloch.
Wenn Du es nicht glaubst: Gib NFS frei, sag mir Deine IP-Adresse und ich tu mich gütlich an allen non root Dateien (sofern Du zumindest root via NFS gesperrt hast).
Von Pascal Brück am Do, 25. September 2003 um 17:02 #
Ich denke Du willst auch keine SMB im Internet freigeben.
NFS ist derzeit nur sinnvoll in einem geschlossenen Netzwerk deines Vertrauens oder in Verbindung mit NIS, OpenLDAP oder Vergleichbaren.
NFS 4 wird da vielleicht Abhilfe schaffen. Sollte es trotz erhöhter Sicherheit seine Performance beibehalten dann könnte es sogar ein interessanter Ersatz für FTP sein.
Von Johanes Kalbus am Sa, 27. September 2003 um 07:09 #
Im Prinzip ja, aber es ist deutlich einfacher Samba vom Internet Abzuschirmen, als NFS. Samba braucht 2 Ports, NFS unendlich viele, da es RPC nutzt und somit wirklich ein Sicherheitsloch per se ist.
Ich schlage mal AFS vor (http://openafs.org), ohne es je benutzt zu haben. Das scheint es unter Windows und unter Linux (und andere) zu geben. Administration scheint etwas komplizierter zu sein.
AFS ist eine Alternative: Zusätzlich verschlüsselt, Kerberosauthentifizierung, Simple UnterstÚtzung von Unixsystemen (NFS-like) und Windowssystemen (DFS-like). Ausserdem unterstútzung von Caching.
Ob das Protokoll gut oder schlecht ist, mag ich nicht zu beurteilen. Deine Beobachtung hat mich aber auch schon viele Nerven gekostet. Hier ein Fall:
Ein Test eines Treibers unter NFS, FTP und anderen »Diensten« funktionierte tadellos. Bei einem Test von SMB hingen sich die Clients nach ca. 5 -10 Stunden auf. Nun, versuche mal 10 Stunden lang eine Gbit-Leitung zu sniffen
Lange Rede kurzer Sinn. Der Fehler bestand darin, dass beim Padding des Pakets die Daten im Descriptor der Karte »umgedreht« wurden und das Paket einfach zerstört wurde. Beim Client angekommen, hat _nur ein Paket_ die Clients so blockiert, dass sie die Shares verloren haben. Die Shares ließen sich nicht mehr abklemmen und nur ein Reboot des Clients hat geholfen. Hat man nicht rebootet, waren die Shares auch nach Stunden immer noch nicht zu erreichen.
Ich finde als Alternative ssh am besten und einfachsten. Wenn ich auf ein Rechner ssh-demon laufen habe, brauche ich auf der andere Seite entweder winscp, oder KDE-fish-IO. Beides sind einfach zu verwenden. sshd-läuft eh meistens (gut nicht bei Windows, aber das kann man auch ändern) und dann kann jeder mit seine Rechte auf ein Rechner zugreifen.
Warum sollte man sich das verkomplitieren? Es währe auch genauso leicht denkbar ein ssh-mount, oder ein ssh-Laufwerkbuchstabe...
eventuell wird sshfs eine alternative werden, im moment find ich es noch ein wenig buggy, aber wenns mal ausgereift ist wirds sicher eine gute alternative werden. sshfs gibts auf http://shfs.sourceforge.net/.
weiß jemand wobei ich achten muß wenn ich von samba 2.2 auf 3.0 umsteige? gibts diverse probleme, änderungen,... Ich möchte nich so viel umkonfigurieren, da ich mich damit immer etwas schwer tue.
Von Martin Steigerwald am Do, 25. September 2003 um 17:48 #
Ich hab auf einem lokalen Fileserver in der Firma unter Debian Linux 3.0/unstable Samba 2.2 auf Samba 3.0 geupdated.
Das einzige Problem war mit den Zeichensätzen. Samba 3.0 unterstützt nun UniCode und da gingen unter MacOS X die Umlaute nicht mehr, bis ich in Samba ein paar Optionen eingefügt habe und die alten MacOS-Dateinamen in ISO-8859-15 (das ich Samba als Linux-Dateisystem-Zeichensatz auf dem Server mitteilte) umgewandelt habe.
Ja, nun gehen sie unter MacOS X, Windows und Linux (dort aber nur smb:// von KDE nicht smbfs, das in Kernel 2.4.22 offenbar das UniCode noch nicht unterstützt, aber genau habe ich das noch nicht herausgefunden).
na dann werd ich wohl das ganze mal probieren. da ich nur win2000 habe betrifft mich ja das mac problem nicht so sehr. mein kernel ist schon etwas angestaubt, aber unicode brauch ich doch nicht wirklich oder?
Von magicm247 am Fr, 26. September 2003 um 13:44 #
unicode bringt schon viele vorteile, ist man unabhängig von zeichensatz wirrwar, solange man weiss, welcher unicode verwendet ist. unter nt system wird auch auf unicode gesetzt.
hängt auch von der distri ab, unter redhat ist jetzt alles mit unicode, bei manchen programmen, die es nicht sauber verwenden, hat man dafür wieder neue probleme mit umlauten.
Gute Sache daß .
Bin mal gespannt, wann die ersten BIN Packages rauskommen. Bei meinem GLück aus den Sourcen zu installieren, geht danach wieder nix
Gruß
Marcus der Werner
Ich hab nur REDHAT gesehen
MDW
Grmbl, NFS ist ein einziges Sicherheitsloch.
Wenn Du es nicht glaubst:
Gib NFS frei, sag mir Deine IP-Adresse und ich tu mich gütlich an allen non root Dateien (sofern Du zumindest root via NFS gesperrt hast).
NFS ist derzeit nur sinnvoll in einem geschlossenen Netzwerk deines Vertrauens oder in Verbindung mit NIS, OpenLDAP oder Vergleichbaren.
NFS 4 wird da vielleicht Abhilfe schaffen. Sollte es trotz erhöhter Sicherheit seine Performance beibehalten dann könnte es sogar ein interessanter Ersatz für FTP sein.
Pascal
Gruß
Johanes
Hat jemand schon Erfahrung ??
http://www.citi.umich.edu/projects/nfsv4/
Zusätzlich verschlüsselt, Kerberosauthentifizierung, Simple UnterstÚtzung von Unixsystemen (NFS-like) und Windowssystemen (DFS-like).
Ausserdem unterstútzung von Caching.
Ein Test eines Treibers unter NFS, FTP und anderen »Diensten« funktionierte tadellos. Bei einem Test von SMB hingen sich die Clients nach ca. 5 -10 Stunden auf. Nun, versuche mal 10 Stunden lang eine Gbit-Leitung zu sniffen
Lange Rede kurzer Sinn. Der Fehler bestand darin, dass beim Padding des Pakets die Daten im Descriptor der Karte »umgedreht« wurden und das Paket einfach zerstört wurde. Beim Client angekommen, hat _nur ein Paket_ die Clients so blockiert, dass sie die Shares verloren haben. Die Shares ließen sich nicht mehr abklemmen und nur ein Reboot des Clients hat geholfen. Hat man nicht rebootet, waren die Shares auch nach Stunden immer noch nicht zu erreichen.
Gruss
Wenn ich auf ein Rechner ssh-demon laufen habe, brauche ich auf der andere Seite entweder winscp, oder KDE-fish-IO. Beides sind einfach zu verwenden. sshd-läuft eh meistens (gut nicht bei Windows, aber das kann man auch ändern) und dann kann jeder mit seine Rechte auf ein Rechner zugreifen.
Warum sollte man sich das verkomplitieren? Es währe auch genauso leicht denkbar ein ssh-mount, oder ein ssh-Laufwerkbuchstabe...
bye pcm
Eine Zeit lang wurde webdav als plattformübergreifende Alternative gesehen.
Hat jemand Erfahrung dazu.
gruß
sarah
Das einzige Problem war mit den Zeichensätzen. Samba 3.0 unterstützt nun UniCode und da gingen unter MacOS X die Umlaute nicht mehr, bis ich in Samba ein paar Optionen eingefügt habe und die alten MacOS-Dateinamen in ISO-8859-15 (das ich Samba als Linux-Dateisystem-Zeichensatz auf dem Server mitteilte) umgewandelt habe.
Ja, nun gehen sie unter MacOS X, Windows und Linux (dort aber nur smb:// von KDE nicht smbfs, das in Kernel 2.4.22 offenbar das UniCode noch nicht unterstützt, aber genau habe ich das noch nicht herausgefunden).
hint2: convmv zum konvertieren der Dateinamen nach UTF-8 nehmen
hängt auch von der distri ab, unter redhat ist jetzt alles mit unicode, bei manchen programmen, die es nicht sauber verwenden, hat man dafür wieder neue probleme mit umlauten.