Inhaltsverzeichnis
Diese Dokumentation enthält detaillierte Informationen und einen Leitfaden dazu, wie man das Browsing über mehrere Subnetze und/oder Arbeitsgruppen (oder Domänen) hinweg implementiert. WINS ist das beste Werkzeug, um NetBIOS-Namen in IP-Adressen aufzulösen. WINS hat nichts mit Browse-Listen zu tun, außer bei der Auflösung von Namen in Adressen.
Anmerkung
MS Windows 2000 und neuere Windows-Versionen können so konfiguriert werden, dass sie ohne NetBIOS über TCP/IP arbeiten, wozu Samba ab Version 3 ebenfalls in der Lage ist. Ist die Benutzung von NetBIOS über TCP/IP deaktiviert, werden die MS Windows-Maschinen über DNS und Active Directory aufgelöst. Die folgenden Informationen gehen davon aus, dass ein Netz mit NetBIOS über TCP/IP betrieben wird.
Jemand bezog sich einst auf die Vergangenheit mit den Worten „Es war die beste aller Zeiten, es war die schlechteste aller Zeiten.“ Je mehr wir zurückblicken, umso mehr sehnen wir uns nach dem, was war, und hoffen, dass es nie wiederkehrt.
Diese Aussage beschreibt präzise die Gefühle vieler MS Windows Netzwerk-Administratoren in Hinblick auf NetBIOS. Diejenigen, die NetBIOS gemeistert haben, wussten, was sie erwartet. Denjenigen, die es nie geschafft haben, seine Eigenschaften zu zähmen, erscheint NetBIOS wie Pattersons Fluch.
Für diejenigen, die nicht mit den botanischen Problemen Australiens vertraut sind: Pattersons Fluch, Echium plantagineum, wurde Mitte des 19. Jahrhunderts eingeführt. Seitdem hat es sich schnell ausgebreitet. Die hohe Samenproduktion der Pflanze mit einer Dichte von Tausenden Samen pro Quadratmeter, ihre Lebensdauer von mehr als sieben Jahren und ihre Fähigkeit, unter guten Voraussetzungen über das ganze Jahr hinweg zu keimen, sind einige der Eigenschaften, die sie zu einem solch hartnäckigen Unkraut machen. (Frank Patterson war einer der gefürchtetsten Gesetzlosen Australiens. Nachdem er wegen eines Diebstahls von vier Dollar am Galgen landete, verfluchte er die Stadt Ironbark und die australische Regierung. Seine Familie pflanzte eine lilafarbene, aus England stammende Pflanze auf sein Grab, die sich rasch im ganzen Land ausbreitete. Aufgrund der Giftigkeit der Pflanze kostet ihre Vernichtung die Viehzüchter Australiens ca. 30 Mill. Dollar pro Jahr, Anm. d. Übersetzers.)
In diesem Kapitel erfahren wir die grundlegenden Aspekte der Server Message Block-(SMB-)Vernetzung mit einem besonderen Blick auf SMB als Implementation in einer NetBIOS-über-TCP/IP-Umgebung (NetBIOS = Network Basic Input/Output System). Da Samba SMB oder NetBIOS nicht über ein anderes Protokoll implementiert, ist es wichtig zu wissen, wie man die Netzwerkumgebung konfiguriert, und sich schlicht daran zu erinnern, nichts anderes als TCP/IP auf allen MS Windows-Clients im Netzwerk zu benutzen.
Samba bietet die Möglichkeit, WINS (Windows Inter-networking Name Server) samt der Systemerweiterungen von Microsofts WINS zu implementieren. Diese Systemerweiterungen helfen Samba dabei, stabile WINS-Operationen - über den herkömmlichen Anwendungsbereich von MS WINS hinaus - zu ermöglichen.
WINS wirkt sich ausschließlich auf Systeme aus, die mit NetBIOS-über-TCP/IP laufen. MS Windows 200x/XP können NetBIOS abschalten. In so einem Fall spielt WINS keine Rolle mehr. Samba unterstützt dies ebenfalls.
In Netzwerken, in denen NetBIOS deaktiviert ist, d.h. wo WINS nicht mehr benötigt wird, ist der Einsatz eines DNS für die Namensauflösung unabdingbar.
Für die meisten bedeutet Browsing, dass sie die MS Windows- und Samba-Server in der Netzwerkumgebung sehen können und dass, wenn man auf das Icon eines bestimmten Servers klickt, ein Fenster geöffnet wird, in dem man die verfügbaren Freigaben und Drucker des Servers sehen kann.
Was so einfach klingt, ist in Wirklichkeit eine komplexe Interaktion verschiedener Technologien. Die dabei involvierten Technologien (oder Methoden) beinhalten Folgendes:
- MS Windows-Maschinen melden ihre Präsenz im Netzwerk an.
- Maschinen kündigen sich anderen Maschinen im Netzwerk an.
- Eine oder mehrere Maschinen fassen diese Ankündigungen lokal zusammen.
- Der Client findet die Maschine, die diese Liste von Maschinen gesammelt hat.
- Der Client ist in der Lage, den Namen der Maschine in eine IP-Adresse aufzulösen.
- Der Client ist in der Lage, sich mit einer anderen Maschine zu verbinden.
Die Samba-Anwendung, die die Verwaltung des Browsings und die Namensauflösung kontrolliert, heißt nmbd. Die dabei verwendeten Konfigurationsparameter sind:
Browsing-Optionen: os level(*), lm announce, lm interval, preferred master(*), local master(*), domain master(*), browse list, enhanced browsing.
Namensauflösungsmethoden: name resolve order(*).
WINS-Optionen: dns proxy, wins proxy, wins server(*), wins support(*), wins hook.
Für Samba sind der WINS-Server und die WINS-Unterstützung zwei einander ausschließende Optionen. Die mit (*) markierten Optionen sind die einzigen Optionen, die im Allgemeinen verändert werden müssen. Sogar wenn keiner dieser Parameter gesetzt ist, tut nmbd nach wir vor seinen Job.
Die gesamte MS Windows-Netzwerk-Technologie verwendet „SMB Messaging“. Dieses kann mit oder ohne NetBIOS implementiert werden. MS Windows 200x unterstützt NetBIOS-über-TCP/IP, um Rückwärtskompatibilität zu gewährleisten. Microsoft scheint zu planen, die NetBIOS-Unterstützung auslaufen zu lassen.
Samba implementiert NetBIOS, wie es auch MS Windows NT/200x/XP tut, indem es dieses Protokoll in TCP/IP einbettet. NetBIOS-basierendes Netzwerke verwenden Broadcasts, um die Verwaltung der Browse-Listen zu regeln. Wenn man NetBIOS-über-TCP/IP ausführt, verwendet dieses das UDP-Messaging. Diese UDP-Nachrichten können Broadcasts oder Unicasts sein.
Normalerweise können nur Unicast-UDP-Messages von Routern weitergeleitet werden. Der Parameter remote announce in smb.conf hilft dabei, die Ankündigungen und Aktualisierungen der Browse-Listen über Unicast-UDP an entfernte Netzwerksegmente weiterzugeben. In ähnlicher Weise implementiert der Parameter remote browse sync in smb.conf die Sammlung und Zusammenfügung von Browse-Listen mit Unicast-UDP.
Außerdem sollte nmbd in jenen Netzen, in denen Samba die einzige SMB-Server-Technologie ist, nach Möglichkeit auf einer Maschine als der WINS-Server konfiguriert werden. Das macht es einfach, die Browsing-Umgebung zu verwalten. Wenn jedes Netzwerk-Segment mit seinem eigenen Samba-WINS-Server konfiguriert ist, dann besteht der einzige Weg, das Browsing über mehrere Segmente zu ermöglichen, in der Verwendung der Parameter remote announce und remote browse sync in Ihrer smb.conf.
Wenn nur ein WINS-Server für ein gesamtes Multi-Segment-Netzwerk verwendet wird, dann sollte die Verwendung der Parameter remote announce und remote browse sync nicht erforderlich sein.
Seit Samba-3 wird an der Replikation von WINS gearbeitet. Der Großteil des Codes wurde bereits ins Samba-SVN übernommen, muss aber noch „reifen“. Diese Replikation ist kein unterstütztes Feature der Samba-3.0.0-Release. Hoffentlich wird es in einer der folgenden Samba-3-Releases zu einem unterstützten Feature.
Derzeit unterstützt das Samba-WINS keine MS-WINS-Replikation. Das bedeutet: Wenn Sie einen Samba-Server als WINS-Server einrichten, darf nur ein nmbd als WINS-Server im Netzwerk konfiguriert sein. Manche Installationen haben mehrere Samba-WINS-Server aus Gründen der Redundanz eingesetzt (ein Server pro Subnetz) und dann remote announce und remote browse sync verwendet, um die Sammlung und Zusammenführung der Browse-Listen über alle Segmente zu erzielen. Beachten Sie, dass dies bedeutet, dass Clients nur lokale Namen auflösen, und so konfiguriert werden müssen, dass sie DNS zur Auflösung von Namen anderer Subnetze verwenden, um es ihnen zu ermöglichen, die IP-Adressen der Server anderer Subnetze aufzulösen. Dieses Setup wird nicht empfohlen, wird aber aus Gründen der Vollständigkeit und aus praktischen Überlegungen aufgeführt (d.h. als Szenario für den Moment, „wenn alles andere schief geht“).
Zuletzt sollten Sie noch beachten, dass Browse-Listen eine Sammlung von unzuverlässigen Broadcast-Nachrichten sind, die in Intervallen von nicht mehr als 15 Minuten wiederholt werden. Das bedeutet, dass es Zeit braucht, eine Browse-Liste zu bilden, und dass es bis zu 45 Minuten dauern kann, bis diese sich stabilisiert, speziell über verschiedene Netzwerk-Segmente hinweg.
Alle TCP/IP-fähigen Systeme verwenden verschiedene Formen der Namensauflösung. Die primären Methoden für die TCP/IP-Namensauflösung sehen entweder eine statische Datei (/etc/hosts) vor oder DNS (Domain Name System). DNS ist die Technologie, die das Internet benutzbar macht. Die DNS-basierende Namensauflösung wird von fast allen TCP/IP-fähigen Systemen unterstützt, nur ein paar wenige „embedded“ TCP/IP-Systeme unterstützen kein DNS.
Wenn ein MS Windows 200x/XP-System versucht, einen Hostnamen zu einer IP-Adresse aufzulösen, folgt es einem definierten Pfad:
Prüfung der Datei hosts. Diese befindet sich in C:\Windows NT\System32\Drivers\etc.
Ausführung einer DNS-Abfrage
Prüfung des NetBIOS-Namens-Cache
Abfrage des WINS-Servers
Ausführung einer Broadcast-Abfrage über UDP
Überprüfung der Datei LMHOSTS, in C:\Windows NT\System32\Drivers\etc
Windows 200x/XP kann seinen Hostnamen an einem „Dynamic DNS Server“ registrieren. Sie können dies erzwingen: ipconfig /registerdns.
Wenn Sie Active Directory (ADS) verwenden, brauchen Sie unbedingt einen korrekt funktionierenden DNS-Server. Fehlt ein korrekt funktionierender und arbeitender DNS-Server, sind die MS Windows-Clients und Server nicht mehr imstande, einander gegenseitig zu finden. Daher werden in der Folge auch die Netzwerkdienste ernsthaft geschädigt.
Die Verwendung von „Dynamic DNS“ mit Active Directory wirdwärmstens empfohlen, wobei auch der Einsatz von BIND9 vorzuziehen ist (wegen seiner Fähigkeit zur adäquaten Unterstützung der SRV-Einträge, die für Active Directory benötigt werden).
Gelegentlich hören wir von UNIX-Netzwerk-Administratoren, die einen UNIX-basierenden Dynamic-DNS-Server anstatt des MS-DNS-Servers einsetzen wollen. Dies mag zwar für manche wünschenswert sein, aber der MS Windows 200x-DNS-Server ist für die Zusammenarbeit mit Active Directory automatisch vorkonfiguriert. Es ist möglich, BIND in der Version 8 oder 9 einzusetzen, aber es wird fast mit Sicherheit notwendig sein, SRV-Einträge anzulegen, damit MS Active-Directory-Clients Hostnamen auflösen können, um essenzielle Netzwerkdienste lokalisieren können. Im Folgenden sehen Sie einige der Standard-SRV-Einträge, die Active Directory benötigt:
- _ldap._tcp.pdc._msdcs.Domain
Gibt die Adresse des Windows NT-PDC für die Domäne an.
- _ldap._tcp.pdc._msdcs.DomainTree
Löst die Adressen der „Global Catalog Server“ in der Domäne auf.
- _ldap._tcp.site.sites.writable._msdcs.Domain
Gibt eine Liste der Domänen-Controller an, die auf den Sites basiert.
- _ldap._tcp.writable._msdcs.Domain
Listet Domänen-Controller auf, die eine schreibberechtigte Kopie des Active Directory führen.
- _ldap._tcp.GUID.domains._msdcs.DomainTree
Eintrag, der von MS Windows-Clients verwendet wird, um Maschinen mit dem „Global Unique Identifier“ zu lokalisieren.
- _ldap._tcp.Site.gc._msdcs.DomainTree
Wird von MS Windows-Clients verwendet, um den „Global Catalog Server“ zu lokalisieren, der von der Site-Konfiguration abhängig ist.
Spezifische Einträge, die von MS Windows-Clients verwendet werden, um essenzielle Dienste für eine Beispiel-Domäne namens quenya.org zu lokalisieren. Sie beinhalten:
_kerberos._udp.quenya.org Wird verwendet, um den KDC-Server über UDP zu kontaktieren. Dieser Eintrag muss für jeden KDC den Port 88 auflisten.
_kpasswd._udp.quenya.org Wird verwendet, um den kpasswd-Server zu lokalisieren, wenn die Änderung eines Benutzerpassworts bearbeitet werden soll. Dieser Eintrag muss den Port 464 auf dem Master-KDC auflisten.
_kerberos._tcp.quenya.org Wird verwendet, um den KDC-Server via TCP zu lokalisieren. Dieser Eintrag muss für jeden KDC den Port 88 auflisten.
_ldap._tcp.quenya.org Wird verwendet, um den LDAP-Dienst auf dem PDC zu lokalisieren. Dieser Eintrag muss den Port 389 des PDCs enthalten.
_kpasswd._tcp.quenya.org Wird verwendet, um den kpasswd-Server zu lokalisieren, um Änderungen von Benutzerpasswörtern zu erlauben. Dieser Eintrag muss den Port 464 enthalten.
_gc._tcp.quenya.org Wird verwendet, um den „Global Catalog Server“ für die Domäne zu lokalisieren. Dieser Eintrag muss den Port 3268 auflisten.
Die folgenden Einträge werden auch vom Windows Domain-Member-Client verwendet, um wichtige Dienste auf den Windows ADS-Domänencontrollern zu finden.
_ldap._tcp.pdc._msdcs.quenya.org
_ldap.gc._msdcs.quenya.org
_ldap.default-first-site-name._sites.gc._msdcs.quenya.org
_ldap.{SecID}.domains._msdcs.quenya.org
_ldap._tcp.dc._msdcs.quenya.org
_kerberos._tcp.dc._msdcs.quenya.org
_ldap.default-first-site-name._sites.dc._msdcs.quenya.org
_kerberos.default-first-site-name._sites.dc._msdcs.queyna.org
SecID._msdcs.quenya.org
Das Vorhandensein der korrekten DNS-Einträge kann so validiert werden:
root# dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org ; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;_ldap._tcp.dc._msdcs.quenya.org. IN ANY ;; ANSWER SECTION: _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org. _ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org. ;; ADDITIONAL SECTION: frodo.quenya.org. 3600 IN A 10.1.1.16 noldor.quenya.org. 1200 IN A 10.1.1.17 ;; Query time: 0 msec ;; SERVER: frodo#53(10.1.1.16) ;; WHEN: Wed Oct 7 14:39:31 2004 ;; MSG SIZE rcvd: 171
MS Windows-Maschinen registrieren ihre NetBIOS-Namen (d.h. den Maschinen-Namen für jeden laufenden Dienst) beim Start. Die genaue Methode, mit der diese Registrierung stattfindet, ist davon abhängig, ob der MS Windows-Client/Server eine WINS-Server-Adresse erhalten hat oder nicht, ob die LMHOSTS-Abfrage aktiviert ist, ob DNS für die Auflösung von NetBIOS-Namen aktiviert ist etc.
Falls es keinen WINS-Server gibt, werden alle Namensregistrierungen wie auch Namensabfragen mit UDP-Broadcasts durchgeführt. Dies beschränkt die Namensauflösung auf das lokale Subnetz, es sei denn, LMHOSTS wird zur Listung aller Namen und IP-Adressen verwendet. In solchen Situationen bietet Samba eine Möglichkeit, mit der der Samba-Server zwangsweise in die Browse-Liste eines fernen MS Windows-Netzwerks eingetragen werden kann (durch den Parameter remote announce).
Wo ein WINS-Server eingesetzt wird, wird der MS Windows-Client einen UDP-Unicast verwenden, um sich am WINS-Server zu registrieren. Solche Pakete können geroutet werden, und daher erlaubt WINS die Namensauflösung über geroutete Netzwerke.
Während des Startvorgangs wird eine Wahl stattfinden, um einen „Local Master Browser“ zu bestimmen, wenn nicht bereits ein solcher existiert. In jedem NetBIOS-Netzwerk wird eine Maschine ausgewählt, um als der „Domain Master Browser“ zu fungieren. Dieses Domänen-Browsing hat nichts mit dem MS Domänen-Controlling zu tun. Stattdessen übernimmt der Domain Master Browser die Rolle, jeden LMB („Local Master Browser“) zu kontaktieren (er wird entweder über WINS oder LMHOSTS ausfindig gemacht), und die Browse-Listen auszutauschen. Auf diese Weise erhält jeder Master Browser eine komplette Liste aller Maschinen im Netzwerk. Alle 11 bis 15 Minuten wird eine Wahl abgehalten, um zu bestimmen, welche Maschine der Master Browser sein soll. Nach den Kriterien dieser Wahl wird die Maschine mit der größten Uptime, der höchsten Protokoll-Version oder anderen Kriterien die Wahl zum „Domain Master Browser“ gewinnen.
Clients, die das Netzwerk durchsuchen wollen, verwenden diese Liste, aber sind auch abhängig von der korrekten Namensauflösung in die entsprechenden IP-Adresse(n).
Jede Konfiguration, die die Namensauflösung und/oder die Browsing-Funktionalitäten verletzt, wird die Benutzer verärgern, da sie dann immer wieder damit konfrontiert sind, die Netzwerkdienste nicht verwenden zu können.
Samba unterstützt ein Feature, das die erzwungene Synchronisation von Browse-Listen über geroutete Netzwerke mit dem Parameter remote browse sync in der Datei smb.conf erlaubt. Dies veranlasst Samba, den LMB in einem fernen Netzwerk zu kontaktieren und dort die Synchronisation der Browse-Listen zu erfragen. Dies überbrückt effektiv zwei durch Router getrennte Netzwerke. Die beiden entfernten Netzwerke können entweder eine broadcast-basierende oder eine WINS-basierende Namensauflösung verwenden, aber Sie sollten beachten, dass der Parameter remote browse sync die Browse-Listen-Synchronisation anbietet, und diese ist etwas anderes als Namensauflösung. Mit anderen Worten: um das „Cross-Subnetz-Browsing“ korrekt arbeiten zu lassen, ist es unbedingt notwendig, dass ein Mechanismus zur Auflösung von Namen in Adressen vorhanden ist. Dieser Mechanismus kann via DNS, /etc/hosts usw. funktionieren.
Um das „Cross-Subnetz-Browsing“ in einem Netzwerk zu konfigurieren, das Maschinen in einer ARBEITSGRUPPE enthält, nicht solche einer NT Domäne, müssen Sie einen Samba-Server als Domain Master Browser (DMB) einrichten (beachten Sie, dass dies nicht dasselbe wie ein primärer Domänencontroller ist, obwohl in einer NT-Domäne dieselbe Maschine beide Funktionen übernimmt). Die Aufgabe eines Domain Master Browsers ist es, die Browse-Listen von den lokalen Master-Browsern all der Subnetze zu sammeln und zusammenzufügen, die eine Maschine beinhalten, die Teil der Arbeitsgruppe ist. Wäre keine Maschine als Domain Master Browser konfiguriert, würde jedes Subnetz eine isolierte Arbeitsgruppe sein, die unfähig wäre, irgendwelche Maschinen in einem anderen Subnetz zu sehen. Es ist das Vorhandensein eines Domain Master Browsers, das das Cross-Subnetz-Browsing für eine Arbeitsgruppe ermöglicht.
In einer ARBEITSGRUPPEN-Umgebung muss der Domain Master Browser ein Samba-Server sein, und es darf nur einen DMB pro Arbeitsgruppen-Name geben. Um einen Samba-Server als DMB einzurichten, setzen Sie folgende Option im Abschnitt [global] der Datei smb.conf:
| domain master = yes |
Der Domain Master Browser sollte vorzugsweise auch der lokale Master-Browser für sein eigenes Subnetz sein. Um dies zu erreichen, setzen Sie die Optionen im Abschnitt [global] der Datei smb.conf wie im folgenden Beispiel:
Beispiel 10.1. smb.conf für einen Domain Master Browser
| [global] |
| domain master = yes |
| local master = yes |
| preferred master = yes |
| os level = 65 |
Der Domain Master Browser kann dieselbe Maschine wie der WINS-Server sein, sollte es erforderlich sein.
Als Nächstes sollten Sie sicherstellen, dass jedes der Subnetze eine Maschine enthält, die als der lokale Master- Browser für die Arbeitsgruppe arbeiten kann. Jede MS Windows NT/200x/XP-Maschine sollte imstande sein, dies zu tun, genauso wie Windows 9x/Me-Maschinen (obwohl diese dazu neigen, öfter Neustarts zu brauchen; also ist es keine allzu gute Idee, diese dafür zu verwenden). Um einen Samba-Server zu einem lokalen Master-Browser zu machen, setzen Sie die Optionen im Abschnitt [global] der Datei smb.conf wie im folgenden Beispiel:
Beispiel 10.2. smb.conf für einen lokalen Master-Browser
| [global] |
| domain master = no |
| local master = yes |
| preferred master = yes |
| os level = 65 |
Machen Sie das nicht für mehr als einen Samba-Server pro Subnetz, oder diese Rechner werden gegeneinander darum kämpfen, wer denn der lokale Master-Browser sein soll.
Der Parameter local master erlaubt es Samba, als lokaler Master- Browser zu arbeiten. Der Parameter preferred master veranlasst nmbd dazu, bei seinem Start eine Browser-Wahl zu erzwingen, und os level stuft Samba so hoch ein, dass es jede Wahl gewinnen sollte.
Wenn Sie eine NT-Maschine im Subnetz haben, die Sie zum lokalen Master-Browser machen wollen, können Sie es Samba „verbieten“, ein lokaler Master-Browser zu werden, indem Sie folgende Optionen im Abschnitt [global] der Datei smb.conf wie im folgenden Beispiel setzen:
Beispiel 10.3. smb.conf für einen Samba-Server, der kein Master-Browser ist
| [global] |
| domain master = no |
| local master = no |
| preferred master = no |
| os level = 0 |
Wenn Sie Samba-Server einer Windows-NT-Domäne hinzufügen, dann dürfen Sie keinen Samba-Server als Domain Master Browser einrichten. Standardmäßig ist der Windows NT-PDC einer Domäne auch gleichzeitig der Domain Master Browser für diese Domäne. Das Netzwerk-Browsing kann zusammenbrechen, wenn sich ein Samba-Server mit dem NetBIOS-Namen des Domain Master Browsers zusätzlich zum PDC am WINS-Server anmeldet (DOMÄNE<1B>).
Für andere Subnetze als jenes, das den Windows NT PDC enthält, können Sie wie beschrieben Samba-Server als lokale Master-Browser einrichten. Um einen Samba-Server zu einem lokalen Master-Browser zu machen, setzen Sie folgende Optionen im Abschnitt [global] der Datei smb.conf wie im folgenden Beispiel:
Beispiel 10.4. smb.conf für einen lokalen Master-Browser
| [global] |
| domain master = no |
| local master = yes |
| preferred master = yes |
| os level = 65 |
Wenn Sie wollen, dass ein Samba-Server mit anderen Maschinen im Subnetz um den Sieg in der Browsing-Wahl kämpft, können Sie den Parameter os level auf niedrigere Werte setzen. Damit können Sie die Reihenfolge feintunen, in der die Maschinen zum lokalen Master-Browser werden, wenn sie laufen. Mehr Details dazu finden Sie im Abschnitt Wie man Samba dazu zwingt, der Master zu sein.
Wenn Sie Windows NT-Maschinen haben, die Domänenmitglieder auf allen Subnetzen sind, und Sie sich sicher sind, dass diese Maschinen immer laufen werden, können Sie Samba von der Teilnahme an Browsing-Wahlen ausnehmen. Auf diese Weise deaktivieren Sie, dass Samba jemals ein lokaler Master-Browser wird, indem Sie folgende Optionen im Abschnitt [global] der Datei smb.conf wie im folgenden Beispiel setzen:
Beispiel 10.5. smb.conf für einen Samba-Server, der nie Master-Browser wird
| [global] |
| domain master = no |
| local master = no |
| preferred master = no |
| os level = 0 |
Wer der Master-Browser wird, hängt von einem Wahlvorgang ab, der Broadcasts verwendet. Jedes Wahl-Paket enthält eine Anzahl von Parametern, die bestimmen, welchen Rang ein Host bei der Wahl einnimmt. Standardmäßig verwendet Samba einen niedrigen Rang und verliert daher die Wahlen gegen so gut wie jeden Windows-Netzwerk-Client oder -Server.
Wenn Sie wollen, dass Samba Wahlen gewinnt, setzen Sie die globale Option os level in smb.conf auf einen höheren Wert. Der Standard ist 20. Die Verwendung von 34 ließe Samba alle Wahlen gegen jedes andere System gewinnen (außer gegen andere Samba-Systeme).
Ein os level von 2 würde Samba Windows for Workgroups und Windows 9x/Me schlagen lassen, aber nicht MS Windows NT/200x-Server. Ein MS Windows NT/200x-Server-Domänencontroller verwendet level 32. Das Maximum für os level ist 255.
Wenn Sie wollen, dass Samba bei seinem Start eine Wahl erzwingt, setzen Sie die globale Option preferred master in smb.conf auf yes. Samba hat dann einen leichten Vorteil gegenüber anderen potenziellen Master-Browsern, die keine „Preferred Master Browser“ sind. Verwenden Sie diesen Parameter vorsichtig, denn wenn Sie zwei Hosts (egal ob diese Windows 9x/Me oder NT/200x/XP oder Samba ausführen) im selben Subnetz haben, bei denen preferred master auf yes gesetzt ist, werden diese beiden periodisch und kontinuierlich eine Wahl erzwingen, um lokaler Master-Browser zu werden.
Wenn Sie wollen, dass Samba ein Domain Master Browser wird, dann ist es zu empfehlen, dass Sie auch preferred master auf yes setzen, da Samba nicht zum Domain Master Browser für Ihr gesamtes LAN oder WAN wird, wenn es nicht auch ein lokaler Master-Browser in seinem eigenen broadcast-isolierten Subnetz ist.
Es ist möglich, zwei Samba-Server so zu konfigurieren, dass sie versuchen, Domain Master Browser für eine Domäne zu werden. Der erste Server, der startet, wird der Domain Master Browser. Alle anderen Samba-Server werden alle fünf Minuten versuchen, zum Domain Master Browser zu werden. Sie werden herausfinden, dass ein anderer Samba-Server bereits der Domain Master Browser ist, und scheitern. Dies gewährt automatisch Redundanz, wenn der aktuelle Domain Master Browser ausfallen sollte.
Der Domänen-Master ist für die Sammlung und Zusammenführung der Browse-Listen von mehreren Subnetzen verantwortlich, so dass ein Browsing über Subnetze hinweg stattfinden kann. Sie können Samba zum Domänen-Master machen, indem Sie in der Datei smb.conf den Parameter domain master = yes setzen. In der Voreinstellung ist Samba kein Domänen-Master.
Machen Sie Samba nicht zum Domänen-Master für eine Arbeitsgruppe, die denselben Namen wie eine NT/200x-Domäne hat. Wenn Samba als Domänen-Master für eine Arbeitsgruppe konfiguriert ist, die sich im selben Subnetz wie eine gleichnamige Windows NT/200x-Domäne befindet, werden mit Sicherheit Browsing-Probleme auftreten.
Wenn Samba Domänen-Master und Master-Browser ist, wird es auf Master-Verlautbarungen (die ca. alle 12 Minuten stattfinden) von lokalen Master-Browsern in anderen Subnetzen hören und diese dann kontaktieren, um die Browse-Listen zu synchronisieren.
Wenn Sie wollen, dass Samba der Domänen-Master ist, sollten Sie auch den Wert für os level ausreichend hoch setzen, um sicherzustellen, dass Samba Browsing-Wahlen gewinnt, und preferred master auf yes setzen, um beim Start von Samba eine solche Wahl zu erzwingen.
Alle Server (inklusive Samba) und Clients sollten einen WINS-Server zur NetBIOS-Namensauflösung verwenden. Wenn Ihre Clients nur Broadcasting zur NetBIOS-Namensauflösung verwenden, werden zwei Dinge geschehen:
Die lokalen Master-Browser werden nicht mehr imstande sein, einen Domain Master Browser zu finden, da sie nur noch im lokalen Subnetz suchen können.
Wenn ein Client doch eine domänen-weite Browse-Liste erhascht und ein Benutzer versucht, auf einen Host in dieser Liste zuzugreifen, wird er nicht imstande sein, den NetBIOS-Namen dieses Hosts aufzulösen.
Wenn jedoch sowohl Samba als auch Ihre Clients einen WINS-Server verwenden, dann gilt Folgendes:
Lokale Master-Browser kontaktieren den WINS-Server, und - sofern Samba sich als Domain Master Browser am WINS-Server registriert hat - der lokale Master-Browser empfängt die IP-Adresse des Samba-Servers als die seines Domain Master Browsers.
Wenn ein Client eine domänen-weite Browse-Liste erhält und ein Benutzer versucht, auf einen Host in dieser Liste zuzugreifen, kontaktiert der Client den WINS-Server, um den NetBIOS-Namen dieses Hosts aufzulösen. Sofern dieser Host seinen eigenen NetBIOS-Namen am selben WINS-Server registriert hat, wird der Benutzer diesen Host auch sehen können.
Wenn Ihr Netzwerk eine auf 0 basierende Broadcast-Adresse verwendet (zum Beispiel, wenn diese auf 0 endet), dann werden Sie Probleme bekommen. Windows for Workgroups scheint keine 0-Broadcasts zu unterstützen, und Sie werden wahrscheinlich herausfinden, dass das Browsing und die Namensauflösung nicht funktionieren.
Samba unterstützt Maschinen mit mehreren Netzwerk-Interfaces. Wenn Sie mehrere Interfaces haben, müssen Sie die Option interfaces in smb.conf setzen, um sie zu konfigurieren.
Mit dem Parameter remote announce in smb.conf können Sie erzwingen, dass all die NetBIOS-Namen eines Netzwerks in einem entfernten Netzwerk bekannt gegeben werden. Die Syntax des Parameters remote announce ist:
| remote announce = a.b.c.d [e.f.g.h] ... |
oder
| remote announce = a.b.c.d/ARBEITSGRUPPE [e.f.g.h/ARBEITSGRUPPE] ... |
wobei Folgendes gilt:
- a.b.c.d und e.f.g.h
ist entweder die IP-Adresse des LMB (lokalen Master-Browsers) oder die Broadcast-Adresse des entfernten Netzwerks, d.h., der LMB ist unter 192.168.1.10 erreichbar, oder die Adresse wird als 192.168.1.255 angegeben, wobei ein 24-Bit-Netzwerk angenommen wird (255.255.255.0). Wenn die Bekanntgabe an die Broadcast-Adresse des entfernten Netzwerks erfolgt, wird jeder Host diese empfangen. Das macht ziemlich viel „Lärm“ im Netz und ist daher nicht erstrebenswert, kann aber erforderlich sein, wenn wir die IP-Adresse des entfernten LMBs nicht kennen.
- ARBEITSGRUPPE
ist optional und kann entweder unsere eigene Arbeitsgruppe oder die des entfernten Netzwerks sein. Wenn Sie den Arbeitsgruppen-Namen des entfernten Netzwerks verwenden, werden unsere NetBIOS-Maschinen-Namen so aussehen, als ob sie jener Arbeitsgruppe gehörten. Dies kann zu Problemen bei der Namensauflösung führen und sollte vermieden werden.
Der Parameter remote browse sync in smb.conf wird verwendet, um einem anderen LMB mitzuteilen, dass er seine NetBIOS-Namensliste mit unserem Samba-LMB synchronisieren muss. Dies funktioniert nur, wenn der Samba-Server, der diese Option gesetzt hat, gleichzeitig der LMB in seinem Netzwerk-Segment ist.
Die Syntax des Parameters remote browse sync ist:
| remote browse sync = a.b.c.d |
wobei a.b.c.d entweder die IP-Adresse des entfernten LMBs ist oder die Netzwerk-Broadcast-Adresse des entfernten Netzwerk-Segments.
Die Verwendung von WINS (entweder als Samba-WINS oder als MS Windows NT-Server-WINS) wird wärmstens empfohlen. Jede NetBIOS-Maschine registriert seinen Namen zusammen mit einem „name_type“-Wert für jeden der Dienste, die sie zur Verfügung stellt. Die Maschine registriert ihren Namen direkt als eindeutigen Namen (Typ 0x03). Sie registriert ihren Namen auch, wenn sie den LanManager-kompatiblen Server-Dienst ausführt (er wird zur Freigabe von Dateien und Druckern verwendet), indem sie den Server-Namen (Typ 0x20) registriert.
Alle NetBIOS-Namen sind bis zu 15 Zeichen lang. Die Variable „name_type“ wird an den Namen angehängt, daher entsteht ein 16-Zeichen-Name. Jeder Name, der kürzer als 15 Zeichen ist, wird mit Leerzeichen bis zum 15. Zeichen aufgefüllt. Daher sind alle NetBIOS-Namen 16 Zeichen lang (inklusive der „name_type“-Information).
WINS kann diese 16-Zeichen-Namen bei ihrer Registrierung speichern. Ein Client, der sich am Netzwerk anmelden will, kann den WINS-Server nach einer Liste aller registrierten Namen befragen. Das spart Broadcast-Netzwerkverkehr und beschleunigt die Bearbeitung von Anmeldungen deutlich. Da die Broadcast-Namensauflösung nicht über Netzwerk-Segmente hinweg verwendet werden kann, kann diese Art von Information nur über WINS bereitgestellt werden oder über eine statisch konfigurierte lmhosts-Datei, die beim Fehlen von WINS auf allen Clients vorhanden sein muss.
WINS erfüllt auch den Zweck, die Synchronisation von Browse-Listen auf allen LMBs zu erzwingen. Die LMBs müssen ihre Browse-Listen mit dem DMB (Domain Master Browser) synchronisieren, und WINS hilft den LMBs, ihren zugehörigen DMB zu identifizieren. Per Definition funktioniert dies nur innerhalb einer einzelnen Arbeitsgruppe. Beachten Sie, dass der Domain Master Browser nichts mit dem zu tun hat, was als MS Windows NT-Domäne bezeichnet wird. Letzteres ist die Bezeichnung für eine Sicherheitsumgebung, während sich die Bezeichnung DMB nur auf den Master-Controller der Browse-Listen-Informationen bezieht.
WINS arbeitet nur korrekt, wenn der TCP/IP-Protokoll-Stack jedes Clients für die Verwendung der WINS-Server konfiguriert ist. Jeder Client, der nicht für die Verwendung des WINS-Servers konfiguriert ist, verwendet weiterhin eine Broadcast-Namensauflösung, und es kann sein, dass WINS gar nicht von diesem Client erfährt. In jedem Fall werden die Namen von Maschinen, die nicht im WINS registriert sind, nicht von anderen Clients aufgelöst werden können und daher zu Zugriffsproblemen und Fehlern führen.
Um Samba als WINS-Server zu konfigurieren, fügen Sie wins support = yes zum Abschnitt [global] ihrer smb.conf hinzu.
Um Samba so zu konfigurieren, dass es sich an einem WINS-Server registriert, fügen Sie wins server = a.b.c.d zum Abschnitt [global] ihrer smb.conf hinzu.
Wichtig
Verwenden Sie niemals wins support = yes gemeinsam mit wins server = a.b.c.d, besonders nicht mit der eigenen IP-Adresse. Wenn beide Parameter so angegeben werden, wird nmbd den Start verweigern!
Sie können entweder einen Samba-Server oder einen Windows NT-Server als WINS-Server einrichten. Um einen Samba-Server als WINS-Server einzurichten, müssen Sie auf dem gewählten Server folgende Zeile zum Abschnitt [global] der smb.conf hinzufügen:
| wins support = yes |
Samba-Versionen vor 1.9.17 hatten diesen Parameter standardmäßig auf „yes“ gesetzt. Wenn Sie irgendwelche älteren Samba-Versionen in Ihrem Netzwerk haben, ist es sehr ratsam, diese Installationen auf eine aktuelle Version zu updaten oder zumindest auf all diesen Maschinen den Parameter auf „no“ zu setzen.
Maschinen, die mit wins support = yes konfiguriert sind, führen eine Liste aller auf ihnen registrierten NetBIOS-Namen und arbeiten damit als DNS für NetBIOS-Namen.
Es wird wärmstens empfohlen, nur einen WINS-Server einzurichten. Setzen Sie die Option wins support = yes nicht auf mehr als einem Samba-Server.
Um einen Windows NT/200x-Server als WINS-Server einzurichten, installieren und konfigurieren Sie den WINS-Dienst. Konsultieren Sie die Windows NT/200x-Dokumentation für mehr Details zu diesem Thema. Windows NT/200x-WINS-Server können sich untereinander replizieren, was es erlaubt, mehr als einen solchen Server in einer komplexen Subnetz-Umgebung einzurichten. Da Microsoft sich weigert, die Replikationsprotokolle zu dokumentieren, kann Samba derzeit nicht an diesen Replikationen teilnehmen. Es ist möglich, dass zukünftig ein Samba-zu-Samba-WINS-Replikationsprotokoll definiert werden kann, was bedeuten würde, dass mehr als nur eine Samba-Maschine als WINS-Server eingerichtet werden könnte. Derzeit sollte jedoch nur auf einem Samba-Server der Parameter wins support = yes gesetzt sein.
Nachdem der WINS-Server konfiguriert worden ist, müssen Sie sicherstellen, dass alle Maschinen im Netzwerk mit der Adresse dieses WINS-Servers konfiguriert werden. Wenn Ihr WINS-Server eine Samba-Maschine ist, tragen Sie die IP-Adresse der Samba-Maschine im Feld Primärer WINS Server der Dialoge Systemsteuerung->Netzwerk->Protokolle->TCP->WINS Server von Windows 9x/Me oder Windows NT/200x ein. Um einem Samba-Server die Adresse des WINS-Servers mitzuteilen, fügen Sie die folgende Zeile zum Abschnitt [global] ihrer smb.conf hinzu:
| wins server = <Name oder IP-Adresse> |
wobei <Name oder IP-Adresse> entweder der DNS-Name oder die IP-Adresse des WINS-Servers ist.
Diese Zeile darf nicht in der Datei smb.conf des Samba-Servers enthalten sein, der als WINS-Server arbeitet. Wenn Sie sowohl wins support = yes als auch wins server = <name> setzen, wird nmbd nicht starten.
Es gibt zwei mögliche Szenarios, um ein Cross-Subnetz-Browsing einzurichten. Das erste behandelt Details der Einrichtung des Cross-Subnetz-Browsings in einem Netzwerk, das Maschinen mit Windows 9x/Me, Samba und Windows NT/200x enthält, die nicht als Mitglieder einer Windows NT-Domäne konfiguriert sind. Das zweite Szenario behandelt die Details der Einrichtung von Cross-Subnetz-Browsing in einem Netzwerk, das NT-Domänen enthält.
Samba-3 erlaubt eine WINS-Replikation, wenn dazu das Utility wrepld verwendet wird. Dieses kann derzeit nicht eingesetzt werden, da es sich nach wie vor in der Entwicklung befindet. Sobald es einigermaßen funktioniert, werden wir dazu Manpages erstellen und diesen Abschnitt der Dokumentation erweitern, um Ihnen entsprechende Details zur Verwendung und zu den technischen Hintergründen zur Verfügung zu stellen.
Das Hinzufügen von statischen Einträgen zu Ihrem WINS-Server ist tatsächlich ziemlich einfach. Alles, was Sie tun müssen, ist, eine Zeile zur Datei wins.dat hinzuzufügen, üblicherweise in /usr/local/samba/var/locks oder /var/run/samba.
Einträge in wins.dat haben die Form:
"NAME#TYPE" TTL ADDRESS+ FLAGS
Dabei ist NAME der NetBIOS-Name, TYPE der NetBIOS-Typ, TTL die „time-to-live“ als Absolut-Zeit in Sekunden und ADDRESS+ eine oder mehrere Adressen, die mit der Registrierung zusammenhängen; und FLAGS sind die NetBIOS-Flags für die Registrierung.
Ein typischer dynamischer Eintrag sieht so aus:
"MADMAN#03" 1055298378 192.168.1.2 66R
Um ihn statisch zu machen, muss nur der Wert für TTL auf 0 gesetzt werden:
"MADMAN#03" 0 192.168.1.2 66R
Obwohl diese Methode nur mit frühen Samba-3-Versionen funktioniert, ist es möglich, dass sie sich in zukünftigen Samba-Versionen verändert, wenn WINS-Replikation hinzugefügt wird.
Achten Sie auf die folgenden Hinweise, da diese Punkte bereits für viele Netzwerk-Administratoren zu Stolpersteinen geworden sind.
Eine verbreitete Ursache von Browsing-Problemen ist, dass mehrere Netzwerk-Protokolle auf einer MS Windows-Maschine installiert werden.
Warnung
Verwenden Sie nicht mehr als ein Protokoll auf MS Windows-Clients.
Jede NetBIOS-Maschine nimmt alle 15 Minuten an der Wahl des LMB (und des DMB) teil. Eine Anzahl von Auswahl-Kriterien wird verwendet, um die Rangfolge der Maschinen zum Gewinnen dieser Wahl zu bestimmen. Eine Maschine, die Samba ausführt, oder Windows NT, wird bevorzugt, so dass die am ehesten passende Maschine voraussichtlich gewinnen und damit diese Rolle übernehmen wird.
Der Auswahlprozess wird sozusagen über jedes NetBIOS-Netzwerk-Interface „ausgefochten“. Im Fall einer Maschine mit Windows 9x/Me, die sowohl TCP/IP als auch IPX installiert hat und NetBIOS über beide Protokolle aktiviert hat, wird die Wahl über beide Protokolle entschieden. Falls, wie es oft passiert, die Maschine mit Windows 9x/Me die einzige mit beiden Protokollen ist, kann der LMB auf dem NetBIOS-Netzwerk-Interface über das IPX-Protokoll gewonnen werden. Samba verliert dann seine LMB-Rolle, da Windows 9x/Me darauf beharrt zu wissen, wer der LMB ist. Samba wird dann seine Funktion als LMB beenden, und daher werden ab da die Browse-Listen-Operationen auf allen Maschinen scheitern, die nur über TCP/IP arbeiten.
Auf Windows 95, 98, 98SE und ME bezieht man sich generell als Windows 9x/Me. Windows NT4, 200x und XP verwenden gemeinsame Protokolle. Diese Systeme werden grob als die Windows-NT-Familie bezeichnet, aber Sie sollten wissen, dass Windows 2000 und XP/2003 neue Protokoll-Erweiterungen einführen, wodurch sich das Verhalten dieser Systeme vom Verhalten von MS Windows NT4 unterscheidet. Allgemein gilt, dass ein Server zur Verwendung der NT4-Protokolle zurückkehrt, wenn er nicht das neuere oder erweiterte Protokoll unterstützt.
Die sicherste Regel von allen, die es zu befolgen gilt, ist: Verwenden Sie nur ein Protokoll!
Die Auflösung von NetBIOS-Namen in IP-Adressen kann mit vielen Methoden erfolgen. Die einzigen Methoden, die NetBIOS-Informationen vom Typ „name_type“ bereitstellen können, sind:
- WINS das beste Werkzeug.
- LMHOSTS statisch und schwierig zu warten.
- Broadcast verwendet UDP und kann keine Namen über Segmente hinweg auflösen.
Alternative Möglichkeiten der Namensauflösung sind:
- Statische /etc/hosts schwierig zu warten; fehlende „name_type“-Information.
- DNS ist eine gute Wahl, jedoch fehlt die name_type-Information.
Viele Installationen wollen DNS-Lookups verbieten und den Netzwerk-Verkehr vermeiden, der durch die Broadcast-Namensauflösung entsteht. Der Parameter name resolve order ist hier von großer Hilfe. Die Syntax des Parameters name resolve order ist:
| name resolve order = wins lmhosts bcast host |
oder
| name resolve order = wins lmhosts (eliminiert bcast und host) |
Der Standard ist:
| name resolve order = host lmhost wins bcast |
wobei „host“ sich auf die nativen Methoden bezieht, die vom UNIX-System zur Implementation des Funktionsaufrufs gethostbyname() verwendet werden. Dies wird normalerweise über die Dateien /etc/host.conf, /etc/nsswitch.conf und /etc/resolv.conf gesteuert.
SMB-Netzwerke bieten einen Mechanismus, mit dem Clients auf eine Liste von Maschinen in einem Netzwerk zugreifen können, eine so genannte Browse-Liste. Diese Liste enthält Maschinen, die andere Maschinen im Netzwerk Datei- und/oder Druckdienste anbieten. Daher umfasst diese Liste keine Maschinen, die momentan nicht imstande sind, Serveraufgaben zu erfüllen. Die Browse-Liste wird von allen SMB-Clients intensiv benutzt. Die Konfiguration des SMB-Browsings war für manche Samba-Benutzer problematisch, daher gibt es jetzt dieses Dokument.
MS Windows 2000 und spätere Versionen von Windows, genauso wie Samba-3 und dessen spätere Versionen, können so konfiguriert werden, dass sie NetBIOS-über-TCP/IP nicht verwenden. Wenn sie auf diese Art konfiguriert sind, ist es unumgänglich, dass die Namensauflösung (mittels DNS/LDAP/ADS) korrekt konfiguriert und arbeitsfähig ist. Das Browsing funktioniert nicht, wenn die Namensauflösung von SMB-Maschinen-Namen in IP-Adressen nicht korrekt funktioniert.
Wo NetBIOS-über-TCP/IP aktiviert ist, wird der Einsatz eines WINS-Servers unbedingt empfohlen, um die Namensauflösung zu unterstützen. WINS erlaubt es Clients in anderen Netzwerk-Segmenten, NetBIOS-name_type-Informationen zu beziehen, die von keiner anderen Methode der Namensauflösung bereitgestellt werden können.
Samba unterstützt Browsing. Das Browsing wird von nmbd bereitgestellt und wird auch von Optionen in der Datei smb.conf gesteuert. Samba kann als lokaler Master-Browser für eine Arbeitsgruppe arbeiten, und die Fähigkeit, Domänenanmeldungen und Domänenskripts zu unterstützen, ist jetzt verfügbar.
Samba kann auch als Domain Master Browser für eine Arbeitsgruppe arbeiten. Das bedeutet, dass es die Listen der lokalen Master-Browser sammelt und sie zu einer Serverliste für ein gesamtes WAN zusammenfügt. Um es den Clients zu ermöglichen, die Namen, die sie in der Liste finden, auch aufzulösen, wird empfohlen, dass sowohl Samba als auch die Clients einen WINS-Server verwenden.
Konfigurieren Sie Samba nicht als Domänen-Master für eine Arbeitsgruppe, die denselben Namen wie eine NT-Domäne hat. In jedem WAN dürfen Sie immer nur einen Domain Master Browser pro Arbeitsgruppe haben, egal ob es NT, Samba oder sonst ein Typ von Domänen-Master ist, der diesen Dienst anbietet.
Anmerkung
nmbd kann als WINS-Server konfiguriert werden, aber es ist nicht notwendig, Samba im Speziellen als WINS-Server zu verwenden. MS Windows NT4, Server oder Advanced Server 200x können als Ihr WINS-Server eingerichtet werden. In einer gemischten NT/200x-Server- und Samba-Umgebung in einem WAN wird empfohlen, dass Sie die MS WINS-Server-Fähigkeiten einsetzen. In einem reinen Samba-Umfeld wird empfohlen, einen und nur einen Samba-Server als WINS-Server zu verwenden.
Um das Browsing zu aktivieren, müssen Sie nmbd wie üblich ausführen, aber müssen auch die Option workgroup smb.conf verwenden, um zu bestimmen, welcher Arbeitsgruppe Samba angehören soll.
Samba hat auch eine nützliche Option, um es einem Samba-Server zu ermöglichen, sich selbst für das Browsing in einem anderen Subnetz anzubieten. Es wird empfohlen, diese Option nur für „ungewöhnliche“ Zwecke einzusetzen: für Verlautbarungen über das Internet, zum Beispiel. Lesen Sie zu der Option remote announce in der Manpage zu smb.conf nach.
Wenn etwas nicht funktioniert, hilft Ihnen die Datei log.nmbd, das Problem zu lokalisieren. Testen Sie einen log level von 2 oder 3, um Probleme zu finden. Beachten Sie auch, dass die aktuelle Browse-Liste üblicherweise in Textform in einer Datei namens browse.dat gespeichert wird.
Wenn es nicht funktioniert, sollten Sie noch immer den Servernamen als \\SERVER im Dateimanager eingeben können, und dieser sollte eine Liste der dort verfügbaren Freigaben anzeigen.
Manche Anwender haben beobachtet, dass das Browsing scheitert, weil sie die globale Option guest account nicht auf ein gültiges Konto gesetzt haben. Erinnern Sie sich, dass die IPC$-Verbindung, die die Freigaben auflistet, als „guest“ hergestellt wird, und dafür brauchen Sie den gültigen guest account.
MS Windows 2000 und spätere Versionen (wie auch Samba) können so konfiguriert werden, dass sie anonymen Zugriff (also mit dem guest account) auf die IPC$-Freigabe verbieten. In diesem Fall verwendet die MS Windows 2000/XP/2003-Maschine den Namen des gerade angemeldeten Benutzers zur Verbindung mit der IPC$-Freigabe. MS Windows 9x/Me-Clients können das nicht und werden dann auch nicht die Ressourcen des Servers browsen können.
Das andere große Problem, das viele Leute haben, ist, dass ihre Broadcast-Adresse, Netmask oder IP-Adresse falsch ist (sie wird mit der Option interfaces in smb.conf angegeben).
Seit der Veröffentlichung von Samba 1.9.17 (alpha1) unterstützt Samba die Replikation von Browse-Listen über die Subnetz-Grenzen hinweg. Dieser Abschnitt beschreibt, wie man diese Replikation auf verschiedene Arten einrichtet.
Um Browse-Listen zu sehen, die TCP/IP-Subnetze umspannen (d.h. Netzwerke, die von Routern getrennt sind, die keinen Broadcast-Verkehr weiterleiten), müssen Sie zumindest einen WINS-Server einrichten. Der WINS-Server fungiert als DNS für NetBIOS-Namen. Dies erlaubt die Auflösung von NetBIOS-Namen in IP-Adressen durch eine direkte Abfrage des WINS-Servers. Dies geschieht mittels eines gerichteten UDP-Pakets auf Port 137 der WINS-Server-Maschine. Mit einem WINS-Server ist keine Standard-Namensauflösung erforderlich, die mittels UDP-Broadcasts von der Client-Maschine aus geschehen würde. Das bedeutet, dass Maschinen in einem Subnetz nicht imstande sind, die Namen von Maschinen in einem anderen Subnetz aufzulösen, solange sie keinen WINS-Server verwenden.
Denken Sie daran: Um das Browsing über Subnetze hinweg korrekt funktionieren zu lassen, müssen alle Maschinen, egal ob Windows 95, Windows NT oder Samba, die IP-Adresse einen WINS-Servers mittels DHCP-Server oder manueller Konfiguration erhalten (für Windows 9x/Me und Windows NT/200x/XP erfolgt die Konfiguration in den TCP/IP-Eigenschaften unter den Netzwerkeinstellungen); für Samba erfolgt die Konfiguration in der Datei smb.conf.
Das Cross-Subnetz-Browsing ist ein „komplizierter Tanz“, mit vielen bewegten Teilen. Es hat Microsoft einige Jahre gekostet, den Code dafür korrekt zu erstellen, und Samba hängt in einigen Bereichen nach. Samba ist jedoch bei korrekter Konfiguration zum Cross-Subnetz-Browsing imstande.
Nehmen wir an, ein Netzwerk sei so konfiguriert wie im folgenden Cross-Subnetz-Browsing-Beispiel.
Unser Beispielnetz besteht aus drei Subnetzen (1, 2, 3), die durch zwei Router (R1, R2)verbunden sind, die keine Broadcasts weiterleiten. Subnetz 1 enthält fünf Maschinen, Subnetz 2 vier Maschinen und Subnetz 3 vier Maschinen. Nehmen wir an, dass alle Maschinen so konfiguriert sind, dass sie in der gleichen Arbeitsgruppe sind (der Einfachheit halber). Die Maschine N1_C im Subnetz 1 ist als der Domain Master Browser konfiguriert (d.h., diese Maschine sammelt die Browse-Listen für die Arbeitsgruppe). Die Maschine N2_D ist als der WINS-Server eingerichtet, und alle anderen Maschinen sind so konfiguriert, dass sie ihre jeweiligen NetBIOS-Namen an diesem WINS-Server registrieren.
Wenn diese Maschinen gebootet werden, finden die Wahlen zum Master-Browser in jedem der drei Subnetze statt. Nehmen wir an, dass die Maschine N1_C im Subnetz 1 gewinnt, N2_B im Subnetz 2 und N3_D im Subnetz 3. Diese Maschinen sind sodann als lokale Master-Browser in ihrem jeweiligen Subnetz bekannt. N1_C hat einen Vorteil bei der Wahl zum lokalen Master-Browser im Subnetz 1, da sie als der Domain Master Browser konfiguriert ist.
In jedem der drei Netzwerke werden Maschinen, auf denen Freigaben eingerichtet sind, durch einen Broadcast mitteilen, dass sie diese Dienste anbieten. Der lokale Master-Browser in jedem Subnetz wird diese Broadcasts empfangen und in einem Eintrag festhalten, dass die Maschine diesen Dienst anbietet. Die Liste dieser Einträge ist die Grundlage für die Browse-Liste. Nehmen Sie für diesen Fall an, dass alle Maschinen eingerichtete Freigaben haben, so dass alle Maschinen in der Browse-Liste sind.
Für jedes Netzwerk wird der lokale Master-Browser als „autoritativ“ für all die Namen betrachtet, die er durch lokale Broadcasts empfängt. Das rührt daher, dass eine Maschine, die vom LMB über einen lokalen Broadcast gesehen wird, im selben Netzwerk wie der LMB sein muss und daher eine „vertrauenswürdige“ und „überprüfbare“ Ressource ist. Maschinen in anderen Netzwerken, von denen die LMBs beim Sammeln der Browse-Listen erfahren, wurden nicht direkt gesehen; diese Einträge werden als „nicht autoritativ“ bezeichnet.
An diesem Punkt sehen Browse-Listen wie im nächsten Beispiel aus (dies sind die Maschinen, die Sie in Ihrer Netzwerkumgebung sehen würden, wenn Sie jetzt in einem einzelnen Netzwerk nachsehen würden).
Tabelle 10.1. Subnetz-Browsing Beispiel 1
| Subnetz | Browse-Master | Liste |
|---|---|---|
| Subnetz1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E |
| Subnetz2 | N2_B | N2_A, N2_B, N2_C, N2_D |
| Subnetz3 | N3_D | N3_A, N3_B, N3_C, N3_D |
An diesem Punkt sind alle Subnetze separat, und keine Maschine wird über die Grenzen eines Subnetzes hinweg gesehen.
Sehen Sie sich nun Subnetz 2 an. Sobald N2_B zum lokalen Master-Browser geworden ist, sucht diese Maschine nach einem DMB, mit dem sie ihre Browse-Liste synchronisieren kann. Das tut sie, indem sie auf dem WINS-Server (N2_D) nach der IP-Adresse fragt, die mit dem NetBIOS-Namen ARBEITSGRUPPE<1B> assoziiert ist. Dieser Name wurde vom DMB (N1_C) auf dem WINS-Server registriert, als der DMB gestartet wurde.
Sobald N2_B die Adresse des DMB kennt, teilt diese Maschine dem DMB mit, dass sie der LMB für das Subnetz 2 ist, indem sie ein MasterAnnouncement-Paket als UDP-Paket an den Port 138 sendet. Dann synchronisiert sie sich mit dem DMB, indem sie einen Aufruf namens NetServerEnum2 durchführt. Das weist den DMB an, all die Servernamen zu senden, über die er Bescheid weiß. Bei Empfang des MasterAnnouncement-Pakets setzt der DMB eine Synchronisations-Abfrage an den Absender dieses Pakets ab. Nachdem beide Synchronisationen vollständig erfolgt sind, sehen die Browse-Listen so aus wie in folgender Tabelle:
Tabelle 10.2. Subnetz-Browsing Beispiel 2
| Subnetz | Browse-Master | Liste |
|---|---|---|
| Subnetz1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
| Subnetz2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
| Subnetz3 | N3_D | N3_A, N3_B, N3_C, N3_D |
Server mit einem folgenden (*) sind nicht-autoritative Namen.
An diesem Punkt sehen die Benutzer, die in ihre Netzwerkumgebungen schauen, im Subnetz 1 oder 2 alle Server auf beiden Subnetzen; Benutzer im Subnetz 3 sehen nach wie vor nur die Server in ihrem eigenen Subnetz.
Dieselbe Abfolge von Ereignissen, die für N2_B geschehen ist, läuft nun für den LMB im Subnetz 3 ab (N3_D). Wenn dieser seine Browse-Liste mit dem DMB (N1_A) synchronisiert, erhält er sowohl die Server-Einträge im Subnetz 1 als auch die im Subnetz 2. Nachdem N3_D sich mit N1_C synchronisiert hat und vice versa, sehen die Browse-Listen wie im folgenden Beispiel aus.
Tabelle 10.3. Subnetz-Browsing Beispiel 3
| Subnetz | Browse-Master | Liste |
|---|---|---|
| Subnetz1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnetz2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
| Subnetz3 | N3_D | N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
Server mit einem folgenden (*) sind nicht-autoritative Namen.
An diesem Punkt sehen die Benutzer, die in ihre Netzwerkumgebungen schauen, im Subnetz 1 oder 3 alle Server auf allen Subnetzen; und Benutzer im Subnetz 2 sehen nur die Server in den Subnetzen 1 und 2, aber nicht die im Subnetz 3.
Abschließend wird sich der LMB des Subnetzes 2 (N2_B) mit dem DMB (N1_C) synchronisieren und die fehlenden Server-Einträge erhalten. Wenn dann ein stabiler Zustand erreicht ist (sofern keine Maschinen entfernt oder abgeschaltet werden), sehen die Browse-Listen so aus wie in dieser Tabelle.
Tabelle 10.4. Subnetz-Browsing Beispiel 4
| Subnetz | Browse-Master | List |
|---|---|---|
| Subnetz1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnetzz2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
| Subnetz3 | N3_D | N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
Server mit einem folgenden (*) sind nicht-autoritative Namen.
Synchronisationen zwischen dem DMB und den LMBs werden weiter passieren, aber dies sollte ein Vorgang sein, der einen gleich bleibenden Status aufrechterhält und keine Veränderungen herbeiführt.
Wenn Router R1 oder R2 ausfällt, passiert Folgendes:
Die Namen von Rechnern auf beiden Seiten der unerreichbaren Netzwerk-Fragmente werden bis zu 36 Minuten lang in den Netzwerkumgebungslisten weitergeführt.
Versuche, sich mit diesen unerreichbaren Rechnern zu verbinden, werden scheitern, aber deren Namen werden nicht aus den Netzwerkumgebungslisten entfernt.
Wenn eines der Fragmente vom WINS-Server abgeschnitten wird, ist es nur noch fähig, auf Server seines eigenen lokalen Subnetzes zuzugreifen, und zwar über eine subnetz-isolierte, auf Broadcasts beruhende Namensauflösung. Die Auswirkungen ähneln denen beim Verlust der Verbindung zu einem DNS-Server.
In den Mailing-Listen werden viele Fragen zum Browsing gestellt. Der Großteil der Browsing-Probleme rühren von fehlerhafter Konfiguration der NetBIOS-Namensauflösung her. Manche bedürfen besonderer Beachtung.
Sambas nmbd-Prozess verwaltet den gesamten Umgang mit Browse-Listen. Unter normalen Umständen ist es sicher, den Prozess nmbd neu zu starten. Dies wird den Samba NetBIOS-Name-Cache effektiv leeren und dessen Neuaufbau initiieren. Wenn nmbd außer Betrieb genommen wird, wird eine andere Maschine im Netzwerk zum Browse-Master. Diese neue Liste kann nach wie vor den fehlerhaften Eintrag beinhalten. Wenn Sie wirklich eine fehlerhafte Maschine aus der Liste entfernen wollen, muss jede Maschine im Netzwerk heruntergefahren und neu gestartet werden, nachdem alle Maschinen abgeschaltet worden sind. Wenn kein kompletter Neustart möglich ist, besteht die einzige andere Möglichkeit darin zu warten, bis der betreffende Eintrag seine Ablaufzeit erreicht hat und aus der Liste entfernt wird. Dies kann in manchen Netzwerken lange dauern (vielleicht Monate ...).
„Mein Client meldet ‚This server is not configured to list shared resources‘“
.Wahrscheinlich ist Ihr Gastzugang aus irgendeinem Grund ungültig. Samba verwendet den guest account in smbd für das Browsing. Überprüfen Sie, dass Ihr guest account gültig ist.
Sehen Sie sich auch den Abschnitt zu guest account in der Manpage zu smb.conf an.
Dieser Fehler kann viele Gründe haben:
Es gibt keinen lokalen Master-Browser. Konfigurieren Sie nmbd oder irgendeine andere Maschine als lokalen Master-Browser.
Sie können sich nicht am lokalen Master-Browser anmelden. Können Sie sich dort als „guest“ anmelden?
Es gibt keine IP-Verbindung zum lokalen Master-Browser. Können Sie ihn mittels Broadcast erreichen?
„ Es gibt nur zwei Maschinen in einem Test-Netzwerk. Eine Maschine ist ein Samba-Server, die andere eine Windows XP-Maschine. Authentifikation und Anmeldungen funktionieren perfekt, aber wenn ich versuche, die Freigaben am Samba-Server zu durchsuchen, wird der Windows XP-Client unbrauchbar. Manchmal reagiert er für einige Minuten nicht. Manchmal antwortet der Windows Explorer und zeigt Dateien und Verzeichnisse ohne Probleme.“
„ Aber die Freigabe ist von der Befehlszeile (cmd) aus unverzüglich verfügbar. Ist das ein Samba-Problem oder ein Windows-Problem? Wie kann ich es lösen? “
Hier sind ein paar Möglichkeiten:
- Schlechte Netzwerk-Hardware
Die meisten Probleme mit defekter Hardware haben mit billigen oder defekten Hubs, Routern, Netzwerkkarten (NICs) und schlechter oder fehlerhafter Verkabelung zu tun. Wenn ein Stück Hardware defekt ist, kann das ganze Netzwerk darunter leiden. Schlechte Netzwerk-Hardware kann Datenverluste verursachen. Die meisten Probleme mit Netzwerk-Hardware, jedoch nicht alle, gehen mit auffällig hohem Netzwerk-Verkehr einher.
- Der Windows XP WebClient
Eine Reihe von Administratoren haben von ähnlichen Problemen mit langsamem Browsing berichtet und herausgefunden, dass das Problem verschwindet, wenn der Dienst WebClient abgeschaltet wird. Dies sollte auf jeden Fall überprüft werden, weil es eine simple Lösung ist, wenn es funktioniert.
- Inkonsistente WINS-Konfiguration
Diese Art von Problem ist gängig, wenn ein Client so konfiguriert worden ist, dass er einen WINS-Server verwenden soll (dies ist eine Einstellung der TCP/IP-Konfiguration) und es keinen WINS-Server im Netzwerk gibt. Dieses Problem kann auch auftreten, wenn es zwar einen WINS-Server gibt, aber Samba nicht zu dessen Verwendung konfiguriert ist. Die Verwendung von WINS wird wärmstens empfohlen, wenn das Netzwerk das NetBIOS-über-TCP/IP-Protokoll verwendet. Wenn die Verwendung von NetBIOS-über-TCP/IP auf allen Clients deaktiviert ist, sollte Samba weder als WINS-Server konfiguriert werden noch zur Verwendung eines solchen.
- Falsche DNS-Konfiguration
Dieser Fehler tritt auf, wenn die Verwendung von NetBIOS-über-TCP/IP deaktiviert ist, Active Directory verwendet wird und der DNS-Server fehlerhaft konfiguriert ist. Lesen Sie dazu DNS and Active Directory.