[Kapitel 1] 1.3 Mit einem SMB/CIFS-Netzwerk vertraut werden

1.3 Mit einem SMB/CIFS-Netzwerk vertraut werden

Nachdem du dich nun kurz in Samba umgesehen hast, nehmen wir uns Zeit, Samba's angenommene Umgebung kennen zu lernen: ein SMB/CIFS Netzwerk. Netzwerken mit SMB ist signifikant anders als die Arbeit mit einem Unix TCP/IP Netzwerk, weil es einige neue Begriffe zu lernen und eine Menge Information zu merken gibt. Zuerst wollen wir die Grundbegriffe hinter einem SMB-Netzwerk diskutieren, gefolgt von einigen Microsoft-Anwendungen darin, und schließlich wollen wir dir zeigen, wo (und wo nicht) ein Samba-Server ins Bild passen kann.

1.3.1 NetBIOS verstehen

Zu Beginn lass uns in der Zeit zurückspringen. 1984 brachte IBM ein einfaches Application Programming Interface (API) zum Vernetzen seiner Computer heraus, das Network Basic Input/Output System (NetBIOS) hieß. Das NetBIOS API lieferte einen rudimentären Entwurf für eine Anwendung, sich mit anderen Computern zu verbinden und Daten mit ihnen zu teilen.

Es ist hilfreich, sich das NetBIOS API als Netzwerk-Erweiterungen zu den Standard-BIOS API-Aufrufen vorzustellen. Mit dem BIOS ist jeder Low-Level-Aufruf auf die Hardware der lokalen Maschine beschränkt und braucht keine Hilfe, um zu seinem Ziel zu kommen. NetBIOS jedoch muss ursprünglich Befehle mit Computern über IBM PC oder Token Ring-Netzwerke austauschen. Deshalb brauchte es ein Low-Level-Transport-Protokoll, um seine Anfragen von einem Computer zum nächsten zu befördern.

Ende 1985 brachte IBM ein solches Protokoll heraus, welches es mit dem NetBIOS API kombinierte; daraus entstand das NetBIOS Extended User Interface (NetBEUI). NetBEUI wurde für kleine Local Area Networks (LANs) entworfen, und es ließ jeder Maschine einen Namen (bis zu 15 Zeichen) beanspruchen, das war auf Netzwerken noch nicht üblich. Bei einem "kleinen LAN," wir meinen weniger als 255 Nodes im Netzwerk - welches 1985, wenn man es überlegt, eine praktische Beschränkung war!

Das NetBEUI Protokoll war sehr verbreitet in Netzwerk-Anwendungen, eingeschlossen solche, die unter Windows für Workgroups liefen. Später tauchten ebenfalls Ausführungen von NetBIOS in Novell's IPX Netzprotokollen auf, welche mit NetBEUI konkurrierten. Egal wie, die Netzwerk-Protokolle der Wahl für die aufblühende Internet-Gemeinde waren TCP/IP und UDP/IP, und die NetBIOS APIs auf diesen Protokollen anzuwenden, wurde bald eine Notwendigkeit.

Erinnere dich, dass TCP/IP Nummern gebraucht, um Computeradressen darzustellen, so wie 192.168.220.100, dagegen NetBIOS nur Namen verwendet. Das war eine bedeutende Angelegenheit, als man versuchte, die beiden Protokolle zu kombinieren. 1987 veröffentlichte die Internet Engineering Task Force (IETF) eine Reihe von Norm-Dokumenten, betitelt RFC 1001 and 1002, die umrissen, wie NetBIOS über einem TCP/UDP Netzwerk arbeiten würde. Dieses Bündel von Dokumenten beeinflusst noch alle Anwendungen, die heute existieren, eingeschlossen solche, die von Microsoft mit seinen Windows-Betriebssystemen als auch von der Samba-Suite geliefert werden.

Seither ist der dieses Dokument bestimmende Standard als NetBIOS over TCP/IP oder kurz NBT bekannt. Der NBT Standard (RFC 1001/1002) umfasst momentan 3 Dienste auf einem Netzwerk:

Ein Namensdienst
Zwei Kommunikationsdienste:
- Datagrammme
- Sessions

Der Namensdienst löst das "Name-zu-Adresse"-Problem, das vorher erwähnt wurde; es erlaubt jedem Computer, einen spezifischen Namen im Netzwerk festzulegen, der in eine von der Maschine lesbare IP-Adresse übersetzt werden kann, soviel wie die heutige DNS im Internet. Das Datagramm und der Session-Dienst sind beide sekundäre Kommunikations-Protokolle, die verwendet werden, um Daten von NetBIOS-Maschinen über das Netzwerk hin und her zu senden.

1.3.2 Einen Namen bekommen

Als Mensch bekommt man leicht einen Namen. Für eine Maschine in einem NetBIOS Netzwerk dagegen kann es ein wenig komplizierter sein. Schauen wir uns einige Ergebnisse an.

Wenn in der NetBIOS-Welt eine Maschine online geht, will sie einen Namen für sich beanspruchen; dies nennt man name registration. Aber keine zwei Maschinen in derselben Arbeitsgruppe sollten denselben Namen fordern dürfen; das würde endlose Verwirrung für jede Maschine verursachen, die mit einer Maschine kommunizieren wollte. Es gibt zwei verschiedene Ansätze, um sicherzustellen, dass dies nicht passiert:

Verwende einen NetBIOS Name Server (NBNS), um zu verfolgen, welche Hosts sich einen NetBIOS Namen eingetragen haben.
Erlaube jeder Maschine im Netzwerk, ihren Namen zu verteidigen im Falle, dass eine andere Maschine versucht, ihn zu verwenden.

Figur 1.8 zeigt eine (fehlgeschlagene) Name Registration, mit und ohne NetBIOS Name Server.

Figur 1.8: NBNS gegenüber einer Nicht-NBNS Name Registration

Außerdem muss es einen Weg geben, einen NetBIOS-Namen in eine bestimmte IP-Adresse aufzulösen, wie weiter oben erwähnt wurde; das ist unter name resolution bekannt. Es gibt hier ebenfalls zwei verschiedene Ansätze mit NBT:

Lass jede Maschine ihre IP-Adresse rückmelden, wenn sie einen Broadcast-Request nach ihrem NetBIOS-Namen "hört".
Verwende NBNS als Hilfe beim Auflösen von NetBIOS-Namen nach IP-Adressen.

Figur 1.9 zeigt die zwei Arten der Namensauflösung.

Figur 1.9: NBNS gegenüber einer Nicht-NBNS Namensauflösung

Wie du erwarten konntest, ein NBNS auf deinem Netzwerk kann dir gewaltig aushelfen. Um genau anzuschauen, warum, sehen wir uns die Nicht-NBNS-Methode an.

Wenn hier eine Client-Maschine bootet, wird sie eine Broadcast-Meldung mit der Erklärung absetzen, dass sie einen bestimmten NetBIOS Namen für sich zu registrieren wünscht. Sollte nach mehrfachen Anmeldungsversuchen niemand gegen die Verwendung des Namens protestieren, behält sie den Namen. Wenn dagegen eine andere Maschine im lokalen Subnetz gerade den verlangten Namen verwendet, wird sie eine Meldung zum urgierenden Client zurücksenden, dass der Name schon vergeben ist. Das ist als defending (Verteidigung) des Hostnamens bekannt. Dieser Systemtyp kommt gelegen, wenn ein Client unerwartet vom Netz geht - ein anderer kann seinen Namen unangefochten übernehmen - aber es zieht eine unmäßige Menge Netzverkehr nach sich für etwas so Einfaches wie eine Namensanmeldung.

Mit einem NBNS ereignet sich dasselbe, außer dass die Kommunikation auf die anfragende Maschine und den NBNS Server beschränkt ist. Es geschieht kein Broadcasting, wenn die Maschine den Namen anmelden will; die Registrier-Meldung wird einfach direkt vom Client zum NBNS Server gesendet, und der NBNS Server antwortet, ob der Name schon verwendet wird oder nicht. Das nennt man point-to-point communication, und es ist von Vorteil auf Netzwerken mit mehr als einem Subnetz. Und zwar deswegen, weil Router oft vorkonfiguriert sind, eingehende Pakete zu sperren, die an alle Maschinen im Subnetz gesendet werden.

Dieselben Prinzipien gelten für die Namensauflösung. Ohne einen NBNS würde die NetBIOS Namensauflösung ebenfalls mit einem Broadcast-Mechanismus abgewickelt. Alle Request-Pakete würden zu jedem Computer im Netzwerk gesendet, in der Hoffnung, dass eine Maschine, die betroffen wäre, der fragenden Maschine antworten wird. An diesem Punkt ist es klar, dass bei Verwendung eines NBNS Servers und Point-to-Point-Kommunikation für diesen Zweck das Netzwerk weit weniger strapaziert wird, als wenn das Netzwerk mit Übertragungen, die nach jeder Namensauflösung fragen, überflutet wird.

1.3.3 Node-Typen

Wie kannst du voraussagen, welche Strategie jeder Client auf deinem Netzwerk verfolgen wird, wenn er die Namensregistrierung und -auflösung durchführt? Jede Maschine auf einem NBT-Netzwerk verdient eine der folgenden Bezeichnungen, abhängig davon, wie sie Namensregistrierung und -auflösung handhabt: b-node, p-node, m-node, and h-node. Die Verhaltensweisen jeder Node-Type sind in Tabelle 1.1 zusammengefasst.

Tabelle 1.1: NetBIOS Node-Typen
Rolle	Wert
b-node	Verwendet nur Broadcast-Anmeldung und -Auflösung.
p-node	Verwendet nur Point-zu-Point-Anmeldung und -Auflösung.
m-node	Verwendet Broadcast zur Anmeldung. Bei Erfolg benachrichtigt er den NBNS Server vom Resultat. Verwendet Broadcast zur Anmeldung; nützt den NBNS Server, wenn Broadcast fehlschlägt.
h-node (hybrid)	Verwendet den NBNS Server für Anmeldung und Auflösung; verwendet Broadcast, wenn der NBNS Server unansprechbar oder außer Betrieb ist.

Windows Clients wirst du gewöhnlich als h-nodes oder hybrid nodes vorfinden. Übrigens wurden h-nodes von Microsoft später erfunden, als ein Weg mit mehr Fehlertoleranz, sie scheinen nicht im RFC 1001/1002 auf.

Du kannst den Node-Typ von Windows-Maschinen herausfinden, indem du das Kommando ipconfig /all eingibst und die Zeile mit Node Type suchst.

C:\> ipconfig /all

Windows 98 IP Configuration
...
  Node Type .  .  .  .  .  .  .  .  .  .  : Hybrid
...

1.3.4 Was steckt in einem Namen?

Die NetBIOS-Verwendungen der Namen sind ganz verschieden von den DNS-Hostnamen, die du gewohnt bist. Erstens existieren NetBIOS-Namen in einem flachen Namensraum. Mit anderen Worten, es gibt keine Bestimmungswörter wie ora.com oder samba.org, um Hostnamen abzutrennen; es gibt nur einen einzigen Namen, um jeden Computer darzustellen. Zweitens, NetBIOS-Namen dürfen nur bis zu 15 Zeichen lang sein, nicht mit einem Asterix (*) beginnen und können nur Standard-alphanumerische Zeichen (a-z,A-Z,0-9) und die nachfolgenden enthalten:

! @ # $ % ^ & ( ) - ' { } . ~

Obschon du in einem NetBIOS-Namen einen Punkt (.) verwenden darfst, sprechen wir uns dagegen aus, weil für die Arbeit mit solchen Namen in zukünftigen Versionen von NetBIOS auf TCP/IP nicht garantiert werden kann.

Es ist kein Zufall, dass alle gültigen DNS-Namen auch gültige NetBIOS-Namen darstellen. Tatsächlich wird oft der DNS-Name eines Samba-Servers als sein NetBIOS-Name wieder verwendet. Wenn du z.B. eine Maschine phoenix.ora.com hättest, würde ihr NetBIOS-Name wahrscheinlich PHOENIX (gefolgt von 8 Leerzeichen) sein.

1.3.4.1 Resource-Namen und -Typen

Eine Maschine mit NetBIOS kündigt nicht nur ihre Anwesenheit an, sondern teilt ebenso anderen mit, welche Typen von Diensten sie anbietet. Phoenix z.B. kann anzeigen, dass er nicht bloß eine Arbeitsstation, sondern auch ein Fileserver ist und WinPopup-Messages empfangen kann. Dies geschieht durch das Anhängen eines 16. Bytes an das Ende des Maschinen- (resource) Namens, resource type genannt, und durch das mehrmalige Registrieren des Namens. Siehe Figur 1.10.

Figur 1.10: Die Struktur von NetBIOS-Namen

Der 1-Byte-Resource-Typ enthält einen einzigen Dienst, den die genannte Maschine bietet. In diesem Buch wirst du den Resource-Typ öfter in Spitzklammern (<>) nach dem NetBIOS-Namen erblicken, wie folgt:

PHOENIX<00>

Du kannst beobachten, welche Namen für eine teilweise NBT-Maschine registriert sind, wenn du das Windows-Kommandozeilen-Utility NBTSTAT verwendest. Weil diese Dienste einmalig sind (d.h., hier kann nicht mehr als eine angemeldet sein), wirst du sie als Typ UNIQUE in der Ausgabe angezeigt sehen. Die folgende Teil-Ausgabe beschreibt z.B. den hydra Server:

D:\> NBTSTAT -a hydra

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
HYDRA          <00>  UNIQUE      Registered
HYDRA          <03>  UNIQUE      Registered
HYDRA          <20>  UNIQUE      Registered
...

Dies sagt aus, der Server hat den NetBIOS-Namen hydra als Maschinen-Namen (Arbeitsstation), als einen Empfänger von WinPopup-Messages und als einen Fileserver registriert. Ein paar mögliche Attribute, die ein Name haben kann, werden in Tabelle 1.2 aufgezählt.

Tabelle 1.2: NetBIOS Unique Resource Typen
Benannte Resource	Hexadezimal Byte Wert
Standard Workstation Service	00
Messenger Service (WinPopup)	03
RAS Server Service	06
Domain Master Browser Service (vereinigt mit primary domain controller)	1B
Master Browser name	1D
NetDDE Service	1F
Fileserver (eingeschlossen printer server)	20
RAS Client Service	21
Network Monitor Agent	BE
Network Monitor Utility	BF

Beachte, dass die Entwickler absichtlich den Hexadezimalwert 20 (ASCII-Leerzeichen) als Voreinstellung für den Typ bei einem Fileserver gesetzt haben, weil DNS-Namen keine Resource-Typen besitzen.

1.3.4.2 Gruppennamen und -typen

SMB unterstützt auch das Konzept von Gruppen, womit Maschinen sich anmelden können. Weiter oben erwähnten wir, dass die Maschinen in unserem Beispiel zu einer workgroup gehören, welche eine Aufteilung von Maschinen auf demselben Netzwerk darstellt. Ein Geschäft z.B. dürfte gut und gerne eine Arbeitsgruppe für BUCHHALTUNG und eine für VERKAUF haben, jede mit eigenen Servern und Druckern. In der Windows-Welt sind eine Workgroup und eine SMB-Gruppe dasselbe.

Wir setzen unser NBTSTAT-Beispiel fort: der hydra Sambaserver ist auch ein Mitglied der Arbeitsgruppe SIMPLE (das GROUP-Attribut hex 00) und steht für die Wahl als Master-Browser (GROUP-Attribut hex 1E). Hier ist der Rest der Ausgabe vom NBTSTAT-Utility:

       NetBIOS Remote Machine Name Table, fortgesetzt
   Name               Type         Status
---------------------------------------------
SIMPLE           <00>  GROUP       Registered
SIMPLE           <1E>  GROUP       Registered
..__MSBROWSE__.  <01>  GROUP       Registered

Die möglichen Gruppen-Attribute, die eine Maschine haben kann, sind in Tabelle 1.3 aufgezeigt. Mehr Information findest du in Windows NT in a Nutshell von Eric Pearce, ebenfalls bei O'Reilly veröffentlicht.

Tabelle 1.3: NetBIOS Group Resource Typen
Benannte Resource	Hexadezimal Byte Wert
Standard Workstation group	00
Logon Server	1C
Master Browser name	1D
Normal Group name (für die Browserwahlen)	1E
Internet Group name (administrativ)	20
`<01><02>__MSBROWSE__<02>`	01

Der letzte Eintrag, __MSBROWSE__, wird verwendet, um anderen Master-Browsern eine Gruppe bekannt zu geben. Die nicht druckbaren Zeichen im Namen scheinen als Punkte in einem NBTSTAT-Ausdruck auf. Verzweifle nicht, wenn du nicht alle Resource- oder Gruppen-Typen verstehst. Einige von ihnen brauchst du nicht mit Samba, und andere wirst du dir aneignen, wenn du dich durch den Rest des Kapitels bewegst. Was man sich als Wichtigstes hier merken soll, sind die Zusammenhänge des Benennungs-Mechanismus.

1.3.5 Datagramme und Sessions

An diese Stelle lasst uns abschweifen, um eine andere Aufgabe von NBT vorzustellen: für Verbindungsdienste zwischen zwei NetBIOS-Maschinen zu sorgen. Tatsächlich werden zwei Dienste von NetBIOS auf TCP/IP angeboten: der session service und der datagram service. Zu verstehen, wie diese zwei Dienste arbeiten, ist bei der Verwendung von Samba nicht notwendig, aber es gibt dir eine Idee davon, wie NBT arbeitet und wie man bei Samba Troubleshooting betreibt, wenn es nicht funktioniert.

Der datagram service hat keine dauerhafte Verbindung zwischen einer Maschine und einer anderen. Datenpakete werden einfach von einer Maschine zur anderen gesendet oder über Broadcast verschickt, ohne Rücksicht auf die Reihenfolge ihres Eintreffens am Ziel oder ob sie überhaupt ankommen. Der Gebrauch von Datagrammen ist nicht so Netzwerk-intensiv wie Sessions, obwohl sie ein Netzwerk lahmlegen können, wenn sie unklug angewendet werden (erinnerst du dich an die Broadcast-Namensauflösung weiter oben?). Daher nimmt man Datagramme für schnelles Senden einfacher Datenblöcke zu einer oder mehreren Maschinen. Der datagram service kommuniziert, indem er die einfachen Kurzbefehle in Tabelle 1.4 verwendet.

Tabelle 1.4: Datagramm-Kurzbefehle
Kurzbefehl	Beschreibung
Send Datagram	Sende ein Datagrammpaket an eine Maschine oder Maschinengruppe.
Send Broadcast Datagram	Broadcast-Datagramm zu einer Maschine, die mit einem Receive Broadcast Datagram wartet.
Receive Datagram	Empfange ein Datagramm von einer Maschine.
Receive Broadcast Datagram	Warte auf ein Broadcast-Datagramm.

Der session service ist komplexer. Sessions sind eine Kommunikationsmethode, die theoretisch die Möglichkeit bietet, problematische oder inoperable Verbindungen zwischen zwei NetBIOS-Anwendungen aufzuspüren. Sie hilft, an eine NBT-Session in Hinsicht auf einen Telefonanruf zu denken.[5] Eine Voll-Duplex-Verbindung wird zwischen einer rufenden und einer anzurufenden Maschine geöffnet und muss die ganze Dauer ihrer Konversation offen bleiben. Jede Seite weiß, welche die rufende und welche die gerufene Maschine ist, und kann sich mittels der einfachen Kurzbefehle in Tabelle 1.5 verständigen.

[5] Wie du in der RFC 1001 sehen kannst, war die Telefon-Analogie bei der Schaffung des NBT-Service stark sichtbar.

Tabelle 1.5: Session-Kurzbefehle
Kurzbefehl	Beschreibung
Call	Eine Session mit einer Maschine einleiten, die auf einen bestimmten Namen hört.
Listen	Auf einen Anruf eines bekannten oder irgendeines Anrufers warten.
Hang-up	Auflegen.
Send	Daten zur anderen Maschine senden.
Receive	Daten von der anderen Maschine erhalten.
Session Status	Information auf gewünschten Sessions bekommen.

Sessions sind das Rückgrat beim Sharing von Ressourcen in einem NBT-Netzwerk. Sie werden typischerweise gebraucht, um stabile Verbindungen von Client-Maschinen zu Disk- oder Printer-Shares auf einem Server zu schaffen. Der Client "ruft" den Server und beginnt den Informationsaustausch wie zum Beispiel, welche von ihm gewünschte Datei zu öffnen ist, welche gewünschten Daten auszutauschen sind u.s.w. Diese Anrufe können lange dauern - Stunden, sogar Tage - und all das geschieht innerhalb des Kontexts einer Einzelverbindung. Falls ein Fehler auftritt, wird die Software (TCP) eine Rückmeldung machen, bis die Daten richtig angekommen sind, im Gegensatz zum "abschlagen-und-beten"-Ansatz des Datagramm-Service (UDP).

Während Sessions angeblich fähig sein sollen, problematische Mitteilungen zu handhaben, tun sie das in Wahrheit oft nicht. Wie du vielleicht beim Benützen von Windows-Netzwerken schon entdeckt hast, ist das ein ernster Nachteil, NBT-Sessions zu verwenden. Sollte die Verbindung aus irgendeinem Grund unterbrochen sein, kann die Session-Information, die zwischen den beiden Computern offen ist, leicht vernichtet werden. Wenn das passiert, ist der einzige Weg für diese beiden Computer, die Session-Information wiederzuerlangen, sich gegenseitig wieder anzurufen und nochmals zu starten.

Wenn du mehr Information über jeden dieser Dienste möchtest, empfehlen wir dir, in die RFC 1001 zu schauen. Nun, hier an dieser Stelle erinnern wir an zwei wichtige Dinge:

Sessions geschehen immer zwischen zwei NetBIOS-Maschinen - nicht mehr und nicht weniger. Wenn ein Session-Service unterbrochen wird, soll der Client genügend Information über seinen Zustand speichern, um die Verbindung wieder herzustellen. In der Praxis ist das selten der Fall.
Datagramme können über Broadcast an viele Maschinen gesendet werden, aber sie sind unzuverlässig. Mit anderen Worten, es gibt keine Möglichkeit für die Quelle zu wissen, ob die gesendeten Datagramme tatsächlich an ihren Zielen angekommen sind.

Using Samba