Um Netbios kommt kaum jemand herum, der Windows und seine Protokolle einsetzt oder mittels Samba heterogene Systeme verbindet. Auch heute noch ist die einstige Programmierschnittstelle hauptsächlich dafür verantwortlich, Namen in solchen Netzen aufzulösen, auch wenn es damit in Konkurrenz zu offenen Standards wie DNS steht. Clients finden so ihre Anmeldeserver, und Verzeichnisdienste gleichen auf diesem Wege ab, wer welche Dienste anbietet.
Andere Auskünfte
Um Namen aufzulösen oder Dienste zu reservieren, verwendet Netbios normalerweise Broadcasts an den UDP-Port 137. Dieser Ansatz hat neben Broadcast-Stürmen den Schönheitsfehler, dass er in gerouteten Netzen nicht funktioniert. Router leiten Broadcasts einfach nicht weiter, die Anfragen verbleiben daher in den Subnetzen, aus denen sie kamen.
Abhilfe schafft hier die Windows-Implementierung des Netbios-Namenservers Wins (Windows Internet Name Service), der Netbios-Namen in einer Datenbank dynamisch pflegt. Die Namensreservierung und die Auflösung bewerkstelligen die Clients dann nicht per Broadcast, sondern durch UDP-Pakete an den Wins-Server (siehe Abbildung 1). Die IP-Adresse des Wins-Servers stellt der Administrator bei allen Windows-Versionen in den Eigenschaften des TCP/IP-Protokolls im Reiter »Wins« in den erweiterten Einstellungen ein (siehe Abbildung 2). Samba teilt der Admin die Adresse des Wins-Servers mit dem Parameter »wins server = IP-Adresse« im Abschnitt »[global]« der »smb.conf« mit.
Abbildung 1: Der Rechner »SABAKI« registriert seinen Namen und seine IP mit dem Resource-Typ 0x20 beim Wins-Server (1) und erhält eine Bestätigung (2). Auch aus einem anderen Subnetz erhält »OKAWANGO« per gerichteter UDP-Anfrage (3) nach »SABAKI« eine Antwort (4). Das ist per Broadcast nicht möglich.
Abbildung 2: Auch Windows-Clients dürfen von dem unter Samba betriebenen Wins-Server profitieren.
Router leiten gerichtete UDP-Pakete an den Wins-Server weiter. Gleichzeitig hat dessen Einsatz den angenehmen Effekt, dass weniger Broadcast-Stürme im Netz toben und sich dadurch die Wartezeit aller Clients verkürzt.
Um auch Anwender freier Betriebssysteme in den Genuss dieses Dienstes zu bringen, hat der bei Samba stark involvierte Dienstleister Sernet das Projekt Samba4Wins aufgesetzt [1]. Die Software ersetzt einen Wins-Server von Microsoft funktional und ist darüber hinaus in der Lage, die Daten auch auf andere Server zu replizieren. Das ist auch dringend notwendig, da von dem Namensdienst fast alle anderen Services abhängen.
Neue Version 1.0.7
Projektleiter Stefan Metzmacher hat diese Funktionalität in der Mitte Januar erschienenen Version 1.0.7 implementiert und gleich noch ein paar Speicherlecks geschlossen. Samba4Wins hat er aus Samba 4 kopiert, jedoch alle Features deaktiviert, die ein Wins-Server nicht benötigt, beispielsweise die Integration in eine Active-Directory-Umgebung. Wenn das Team Samba 4 eines Tages veröffentlicht, lösen dessen Pakete das separate Samba4Wins ab.
Bis dahin darf der Admin den Daemon parallel zu Samba 3 ab Version 3.0.21 einsetzen. So betreibt er mehrere Wins-Server mit freier Software, die untereinander ihre Datenbestände abgleichen. Zwar erlaubt auch Samba 3 einen Wins-Server ohne Samba4Wins zu starten. Der lässt sich bislang aber nicht mit anderen Wins-Servern abgleichen - das ist jedoch in vielen komplexen Netzwerken notwendig. Wählt der Admin eine aktuelle Samba-3-Release als Wins-Server, stehen die Anwender im Regen, wenn der Server abstürzt oder nicht erreichbar ist. In gerouteten Netzen wäre dann der Netbios-Namensraum verloren, da die Subnetze vom Wins-Server getrennt werden.
Die Anwender können dann einzig auf die lokalen Server zugreifen, da nur noch Broadcasts ihre Netbios-Namen auflösen. Die sind bekanntlich nicht in der Lage, Subnetz-Grenzen zu überschreiten. Bislang hatte nur Microsoft das Protokoll für die Replikation einer Wins-Datenbank mit anderen Wins-Servern implementiert - für manchen Admin der letzte Grund, in seinen Netzen überhaupt noch Windows-Server mitlaufen zu lassen.