CRE097 File & Print Sharing

Veröffentlicht am von

Eine Reise durch die etablierten und kommenden Netzwerkprotokolle

Episode image forCRE097 File & Print Sharing

Die gängigen Betriebssysteme haben sich über die Zeit auf viele Protokolle und Formate geeinigt, aber im Bereich des File und Print Sharing herrschen auch nach Jahrzehnten Alleingänge und Abgrenzung. Während sich die DOS/Windows-Welt mit einem erst seit jüngster Zeit dokumentierten Wildwuchs rund um SMB gegenseitig Dateien, Drucker und Programmsteuerung feilbietet setzte Apple zunächst auf die Eigenkreationen AFP und PAP. Die restliche UNIX-Welt verstand sich Lange Zeit nur auf NFS und simple Druckerprotokolle. Im Zuge einer durch das Internet getriebenen, zaghaften Standardisierung gewinnen aber WebDAV und IPP zunehmend an Bedeutung.

Im Gespräch mit Tim Pritlove erläutert Jens-Uwe Mager die geschichtlichen Hintergründe, Design-Motivationen und technischen Details der zahlreichen File und Print Sharing Protokolle. Im Fokus stehen vor allem die am meisten verbreiteten Protokolle AFP, SMB und NFS. Zur Sprache kommen im weiteren die Abhängigkeiten der Protokolle von Dateisystemen und Betriebssystem-Eigenschaften, Kompatibilität der Abstraktionen, Unterstützung von Metadaten, Darstellung und Interoperabilität von Dateinamen, Authentifizierungsmethoden, Sicherheitsaspekte, Performance und Wide-Area-Tauglichkeit von Netzwerkprotokollen, Stateless und Stateful Protokolle, Versioniertes File Sharing im Internet mit WebDAV und Subversion und Zugriff auf Drucker über Netzwerkprotokolle.

avatar
Tim Pritlove
Twitter Icon @timpritlove@mastodon.social Icon Website Icon Spenden via PayPal Icon
avatar
Jens-Uwe Mager
Twitter Icon
Shownotes

Links:

38 Gedanken zu „CRE097 File & Print Sharing“

  3. letztes jahr hab ich für meine Arbeitsgruppe ein file und authentication server aufsetzen müssen. wir verwenden ubuntu. Ich kann es immer noch nicht glauben dass es für ein homogenes linux Netzwerk noch immer keine einfache und elegante Lösung gibt die man mit ein paar Konfigurationsfiles zum laufen bringt.
    letztlich bei nis, nfs hängengeblieben aber das muss doch nicht sein oder?

    Antworten ↓

  4. Ich weiß nicht ob das hier dazu passt, aber bei KDE gibt’s so genannte kio slaves. Das läuft im userspace, ist als ähnlich wie FUSE aber als library. Die Applikationen müssen also die KDE libs zum Dateizugriff verwenden. Dann ist es aber möglich einfach mit dem Texteditor eine http:// Adresse zu öffnen. Die aber nur read-only. Aber was auch geht, und ich genial finde ist fish://. Das geht mit jedem Rechner der ssh kann, somit mit Authentifizierung und Verschlüsselung. Mit meinen Rechner zuhause kann ich somit ganz einfach auf die Dateien auf meinen Uni-Account zugreifen. Sehr praktisch. Das funktioniert aber leasing artig (Datei wird runter kopiert und dann wieder rauf kopiert) und überprüft garkein locking oder so. Ist eigentlich ein quick hack, aber für sehr viele Anwendungsfälle durchaus ausreichend. Damit kann ich also auch ohne Probleme auf einen Mac zugreifen, hat ja auch ssh.

    Antworten ↓

  5. Also es gibt auch noch einen großen Vorteil von NFS. Bei halbduplexen Netzwerken (Ethernet, WLAN) hat man da deutlich mehr Durchsatz als bei TCP-basierten Protokollen.

    Antworten ↓

  7. … ist schon seltsam. Jedes halbe Jahr hält ein neues Dateisystem Einzug in den Linux Kernel. Aber ein vernünftiger platformunabhängiger Ersatz für NFS/NIS, CIFS/SMB/AD und AFP ist nirgends in Sicht … vielleicht steckt da ja ’ne nette kleine Verschwörung dahinter. Just my 2c ;-)

    Antworten ↓

  8. bin mir nicht ganz sicher ob mein gedanke zu eurem problem passt, aber in der fonterstellung werden die unicodes ja auch verwendet um in den zeichensätzen zu navigieren, da ich natürlich nicht alle glyphen mit entsprechenden diakritics einzeln machen will verwende ich composites. also ich mach ein a ein o ein u und ein dieresis, die entsprechenden adieresis, odieresis und udieresis generieren sich dann selber. ist sehr wichtig wenn du einen akzent änderst damit der font consistent bleibt.

    Antworten ↓

  9. Ich kann mich nur Markus Hubig anschließen. Ich habe zwar mit dem Sicherheitsaspekt in meinen Anwendungsfällen kein Problem, aber das steinzeitliche Limit auf 16 ‚group-ids‘ ist eine Lachnummer. Seit die Distributionen mit Systemgruppen um sich werfen kann man NFS nicht mehr benutzen.

    Gibt es wirklich keine leichtgewichtige Alternative?

    Was macht man eigentlich, wenn man NFS+NIS auf Notebooks oder Netbooks betreiben will? Kann man sich eigentlich bei fehlendem NIS-Server überhaupt noch am Notebook einloggen?

    Wie sieht hier mit Alternativen aus?

    Antworten ↓

  12. @joede
    Ist schon ein Weilchen her, dass ich mit NIS beschäftigt habe. Ich habe aber in Erinnerung, dass es im Verzeichnis /etc eine Datei gibt, in der die Reihenfolge der Authentifizierungsmethoden festgelegt wird. ZB wenn NIS fehlschlägt, dann passwd.

    Antworten ↓

  14. @piercyha: Danke für die Info. So weit war ich schon. Nur setzt dieser Weg dann wieder voraus, dass die UID/GID die mit NIS verwaltet werden, mit denen in /etc/passwd übereinstimmen. Ich muss dann doch wieder Hand anlegen und selbst dafür sorgen, dass die UID/GID auf allen PCs stimmt.
    Oder sehe ich das was falsch?

    Zusammen mit der Einschränkung auf 16 Gruppen würde ich NFS/NIS als „nicht tragbar“ einstufen (böse wie ich bin). ;-)

    Ich provoziere jetzt mal ein bisschen. Soll das nun bedeuten, das Linux ohne brauchbaren Netzfilesystem leben muss?

    Antworten ↓

  15. @tim: wenn ftp’s (glorreiche) Zeiten schon 15 Jahre her sind, was soll man dann zu NFS/NIS sagen. ;-) Im Podcast habt ihr es ja schon angesprochen, aber was bedeutet das dann für *nix? In Ermangelung einer brauchbaren Alternative schweigen alle das Problem alle tot?

    Antworten ↓

  17. Vielleicht sollten wir die Kirche einfach nur im Dorf lassen?!

    NFS ist und bleibt das Fileserversystem für UNIX basierende Computer. Wer nach dem Vorteil fragt, der sollte nur mal Files im LAN austauschen. Die Performance von NFS ist unerreicht. Wurde das Thema Performance im Beitrag überhaupt angesprochen?

    Einfach nur mal verschiedene Server und Clients mit NFS oder SAMBA verbinden und read/write Zeiten messen. Exemplarisch kann man sich mal die Performancetests auf
    http://pvs.informatik.uni-heidelberg.de/Teaching/DASY-07/krempel.pdf
    ansehen.
    Mit AFP hab ich keine Erfahrung. Durch die Mac OS X Zentrierung aber auch für Interoperabilität im UNIX Umfeld nicht zu empfehlen.

    Desweiteren ist NFS nicht mit NIS verheiratet. Es waren nur gute Freunde aus dem gleichem Umfeld, bei denen sich nur einer weiterentwickelte – NIS ist durch LDAP quasi abgelöst worden.

    Bei einer detaillierteren Bewertung von NFS sollte zuerst abgegrenzt werden wo es eingesetzt werden soll.
    Im SOHO Bereich, existiert oft keine zentralisierte Benutzerverwaltung. Wenn jeder Computer eigene Accounts bekommt, sollte man sich vorher eben auf bestimmte UID’s/GID’s festlegen. Das ist, wie übrigens auch eine nachträgliche Änderung der ID’s – kein grosser Act, bei wenigen Rechnern ist der Aufwand vertretbar. Wer dennoch diesen Aufwand im SOHO vehement ablehnt, der muss eben konsequent zu NFSv4 greifen, der Benutzerstrings kennt und mappt. NFSv4 ist unter Sun Solaris und Linux – im Gegensatz zu falsch lautetenden Bemerkungen im Podcast – funktionsfähig implementiert. Der NFS Client auf Mac OS X 10.5 ist prinzipiell NFSv4 fähig, befindet sich aber im nicht dokumentierten Nirvana zwischen Alpha und Beta.
    Die 16 Gruppen Beschränkung taucht in Beschreibungen seltenst auf, weil es so wenige tangiert. Ich würde mal behaupten, dass im SOHO Bereich so gut wie niemand daran scheitert, auf openSuSE ist ein Standardbenutzer in 2-4 Systemgruppen, da kann man ja nicht von „um sich werfen“ reden.
    Die Begrenzung kann mit NFSv4 und Kerberos (s.u.) umgangen werden.

    Wo sind also die Nachteile im Trusted LAN? Richtig – NIRGENDS

    Also zum Sicherheitsproblem, das v.a. in Enterprise Umgebungen auftritt. Zuerstmal NFSv3 – die heute mit Abstand meist genutzte Variante – ist ein stateless Protokoll auf TCP Basis mit Backward-Kompabilität zu UDP. Natürlich kann man TCP mit SSL tunneln um den ganzen Verkehr zu verschlüsseln. Wer dass braucht muss im klaren sein, dass sein Flirt mit der Performance beendet ist.

    Eine Authentifizierung findet nicht statt, da der UID/GID Vergleich nur eine Autorisierung durchführt. Wer ersteres braucht muss wieder zu NFSv4 mit Kerberos greifen.
    NFSv4 ist zudem Firewall freundlicher, da alles über den NFS Port 2049 geht, da NFS nun den Traffic, dass Locking und das Mounting in einem Dienst vereint.

    Alles in allem wird im Enterprise Bereich der Druck einfach höher sein auf NFSv4 zu migrieren. Das generelle NFS Fazit lauten aber: The sun is shining

    In diesem Podcast wurde im Bezug auf NFS die Gegenwart nur kurz gestreift und stattdessen der Komödienstadel der 80er/90er aufgeführt. Exemplarisch könnte man anmerken dass ACL’s mit NFSv4 vor AFP (dort erst mit 3.2) eingeführt wurden. Es kam aber genau andersrum rüber. Die Bsp. dazu würden nicht aufhören..

    Die Chaosradio Express Reihe ist zwar technisch gut gemacht aber natürlich gefärbt. Bei jeder Sendung ist Mac OS X der Musterschüler, bei Windows hält man sich lieber dezent zurück und Linux kriegt sein Fett weg.
    Das hält mich natürlich nicht ab, ihn trotzdem zu abonnieren auch wenn man als Linux Fan beim zuhören lieber eine Packung Betablocker in Griffnähe haben sollte.

    Antworten ↓

  18. Da mein letzter Kommentar verschollen ist …

    – Die 16 GID Beschränkung ist mit NFSv4 kein Thema mehr, wenn man es einzurichten weiß. Google hilft.
    – AFP gibt es auch als Server und Client für Linux. Google hilft.
    – Im Gegensatz zum ausführlich behandelten WebDAV ist FTP ein Protokoll, dass sich auch außerhalb von Versioningsystemen und einer Hand voll Homepagefrickler antreffen lässt

    Zumal wäre die Frage angebracht gewesen, warum sich Filesharingprotokolle nie im Internet durchgesetzt haben. Eine kurze Überlegung, wie sich ein LAN vom Internet und ein NFS-Server von Bittorrent unterscheidet liefert erste Erkenntnisse.

    Und ja, die Sendung kam mir vor wie ein Werbeblättchen für AFP. Aber die Hurra-Apple-Stimmung muss bei den technischen Themen ja sein um potentielle Switcher zu entmutigen und der Gast hatte dort seine primäre Expertise (in NFSv4 scheint er hingegen nicht groß reingesehen zu haben)

    Antworten ↓

  19. Also, soweit ich das mitbekommen habe, glaube ich, dass das nicht ganz stimmt was ihr da wegen unicode vorgetragen habt. Also soweit ich weiß ist „decomposed“ und „composed“, zwei von vier normalisierungsformen, die sehrwohl richtig dargestellt werden können wenn die Unicode-implementierung einigermaßen vollständig ist. Wobei hier auch die Darstellung auf Windows und Linux gut funktioniert. Also es ist eigendlich egal in welcher normalisierungsform übertragen wird, man muss nur neu normalisieren, wenn es um stringvergleiche oder ähnliches geht… Und das sollte ein jedes Kernelmodul, machen das den zugriff aud ein Dateisystem möglich macht, solange das Dateisystem ein encoding spezifiziert.

    Antworten ↓

  21. Eine kurze Anmerkung zu decomposed Unicode bei AFP: Ich vermute, daß Apple sich entschieden hat, den Grundbuchstaben und das diakritische Zeichen (also Akzent, Umlaut-Punkte usw.) separat zu speichern, weil sich so Strings wesentlich einfacher sortieren lassen. Schließlich sollen a, ä, á, à etc. beim Sortieren gleich behandelt werden. Das wäre etwas schwieriger zu implementieren, wenn diese Zeichen alle ganz unterschiedliche Codes hätten (Wikipedia listet über 20 verschiedene diakritische Zeichen).

    Antworten ↓

  22. @Joerg: Das mit dem Sortieren hörte ich auch mal als Hauptargument für Form D – decomposed.

    Das dumme an der Geschichte ist, dass es v.a. im Bezug auf NFS mit den Dateinamen Probleme gibt. Während laut Apple Developer Doku, SMB klar auf precomposed Unicode setzt – gibt es bei NFS keinen Standard für das Decoding. Dateien auf einem NFS Mount von Mac OS X aus durchlaufen daher keine Konvertierungsroutine.

    Das würde dazu führen, dass im NFS Bereich unterschiedliche UTF-8 Dateinamen existieren – einmal Form C (vom Linux Client erzeugt) oder Form D, dann vom Mac OS X Client.

    Während Linux aber mit beiden Dateinamensarten zurechtkommt (jetzt eigentlich alle – mit KDE3 wurde im Konqueror das Decomposing falsch angezeigt) akzeptieren manche Apple Programme (z.B. iPhoto – zumindest in früheren Versionen ganz sicher) keine Form C Dateinamen, wenn Sie diakritische Zeichen enthalten.

    Daher muss mal wieder der klügere Nachgeben und mit einem cron Befehl

    convmv -r -f utf8 -t utf8 –nfd –notest /mein-performanter-NFS-Bereich

    der ganze Salat permanent auf Form D gehalten werden.

    Ich bin trotz (an)lesens der neuesten RFC von NFSv4 nicht schlau geworden, ob es Zukunft möglich ist NFS einem Pflichtzeichensatz mitzugeben.

    Vielleicht gibt’s neue Erkenntnisse ab 02.10. – Das Titelthema vom nächsten Linux-Magazin ist NFS.

    Antworten ↓

  23. Hallo Gemeinde,

    ich fand die Sendung sehr informativ.
    Mich interessieren beim Radeln zur Arbeit auch eher die Histroie als das auseinanderdröseln der neusten Version, da es dabei viel mehr AHA-Effekte gibt und das Hören kurzweiliger bleibt.
    Die Abstiege in die verschiedenen Bereiche muss ich mir jedoch noch einmal vor Ohren führen, wenn ich einen konkreten Anwendungsfall / ein konkretes Problem habe.
    Ich markiere den Podcast glaube ich erst einmal als angehört… :)

    Vielen Dank und weiter so.
    kniepbert
    PS: Ich mag die technischen Podcast lieber, die philosophisch angehauchten sind mir besonders morgens zu anstrengend. hehe…

    Antworten ↓

  25. Apropos Dateiversionen in WebDAV eine kurze Anmerkung: Vor langer Zeit hatte u.a. VMS ein versioniertes Dateisystem und die Dateisystemabstraktion (Pathnames) in Common Lisp hatte für solche Systeme auch Support. Es ist schade, daß die UNIX-Welt Versionierung abgesägt hat…

    Antworten ↓

  26. @Julian: Ja, das VMS-Dateisystem wäre in dem Zusammenhang erwähneswert gewesen. Ich denke allerdings nicht, dass Versionierung abgesägt wurde, es ist nur so, dass man mit Konventionen, die letztlich über SCCS zu CVS und SVN geführt haben besser gefahren ist, zumal man Versionierung auch gleich mit verteiltem Arbeiten zusammengeführt hat.

    Abgesehen davon kommt mit ZFS eine neue Art der Versionierung: Snapshots sind quasi globale, explizite Versionen, die sehr viel einfacher zu benutzen sind und das eigentliche Bedürfnis für Versionen (Backup) letztlich besser bedienen.

    Antworten ↓

  27. @Tim: Apropos Snapshots… das was ZFS mit den Snapshots populär macht, ist bei anderen Filesystemen schon seit langer Zeit die Regel. WAFL von NetApp würde mir hier einfallen :-)

    Antworten ↓

  29. @resmo: Kann ja sein, dass ihr es benutzt, aber ihr solltet es vielleicht besser nicht tun. FTP mit TLS ist in Clients und Server-Setups kaum verbreitet und das normale FTP ist schlicht unsicher und ist durch seine komische Nutzung von Ports nicht selten problematisch. Da sollte man auch gleich auf WebDAV oder SFTP setzen. Das meinte ich mit „ist vorbei“.

    Antworten ↓

  30. @Tim
    Nicht, dass ich unbedingt Fan von FTP bin und es _unbedingt_ benutzen will. :) Man passt sich halt an den Bedürfnissen von zahlenden Kunden an, wenn’s nicht grad hochsensible Daten sind.

    Antworten ↓

  31. Nachdem ich den Podcast nun zum zweiten Mal angehört habe, kann ich nachvollziehen, warum einige so begeistert davon waren. Beim ersten Mal war ich zunächst etwas erschlagen von den vielen Informationen und auch die Ausrichtung war etwas anders, als ich es mir vorgestellt hätte.

    Alles in allem hat mir die Sendung ganz gut gefallen. Gerne hätte ich noch etwas mehr zum aktuellen praktischen Einsatz (Implementierungen) der Protokolle auf den verschiedenen Betriebssysteme gehört. Außerdem würde mich auch noch das Verhältnis zwischen den angesprochenen Protokollen und Dingen wie FTP und sshfs interessieren.
    Beim Hören fand ich teilweise etwas verwirrend, dass immer nur vom „Mac“ gesprochen wurde und ich mir nicht sicher war, ob nun Mac OS <=9, OS X oder beides gemeint war.

    Antworten ↓

  32. Danke für den Podcast.

    Das war selbst für mich als Netzwerktechniker echt harter Stoff aber auch echt guter Stoff. Einiges hatte ich früher schon gelernt, aber nicht verstanden ;)

    Diese Ausgabe verdient echt 10 von 10 Nerdpunkten und den Hinweis: Achtung jetzt wird’s echt technisch.

    Danke Tim.

    Antworten ↓

  34. Hallo zusammen,

    erst mal danke für die gelungene Sendung, war sehr informativ.
    Bei einem Thema, bei dem es um NTFS ging bin ich aufmerksam geworden.
    Ich hatte den Beitrag so verstanden, das physisch bei ntfs noch mit
    kurzen Dateinamen gespeichert wird.
    Der lange Dateiname ist quasie nur ein Alias. Hab ich das so richtig
    verstanden??
    Sollte das so stimmen wäre ich an Infos zu dem Thema interessiert.
    Speziell würde mich interessieren wie ich aus Programmen heraus den
    kurzen Pfad / Dateinamen auslesen kann. Leider hat Google bis jetzt noch nichts brauchbares geliefert.

    Gruß
    Dirk

    Antworten ↓

  35. Wenn du nicht zwanghaft versuchen würdest Apple gut zu machen, obwohl es das nicht ist, könnten deine Podcasts auch sehr interessant werden.

    Antworten ↓

  36. @dirk: Unter Windows kannst Du Dir die kurzen Dateinamen einfach mit dem Befehl „dir /X“ in der Eingabeaufforderung (cmd.exe) anzeigen lassen.

    Oder von Unix aus mit dem Programm „smbclient“ und dem Kommando „altname“.

    $ smbclient //mypc/myshare
    Domain=[mypc] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
    smb: > altname Programme
    PROGRA~1
    smb: > exit

    Antworten ↓

  37. Zum Punkt ACL bei WebDAV. Ich denke, daß das Design von DAV diese Aufgabe beim HTTP-Server ansiedelt. Der Apache bietet über seine AuthN/AuthZ-Module dann fast alles, was man die IT kennt: flat File, RDBMS, LDAP, Kerberos, Radius.

    Antworten ↓

  38. Dass kein Mensch NFD verwendet, ist so nicht richtig. In Bibliotheksdatenbanken ist das Standard. Ich glaube sogar, in Datenbanken generell. Hat unteranderem Sortiergründe.

    Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.