Hallo, ich weiss, dass diese Liste hier keine spezielle Samba-Liste ist. Dennoch -und das geht aus den vielen Samba-Fragen, die hier immer wieder auftauchen, hervor- setzen hier viele Leser Samba ein, sodass ich hoffe, dass mir vielleicht der eine oder andere einen Tip bzgl. meiner Frage geben kann. In den Samba-Listen und -Newsgroup habe ich leider bisher noch keinen brauchbaren Hinweis bekommen. Wir setzen Win9x-Clients zusammen mit "samba-2.0.6" (auf Linux 2.2.14) in zwei Netzwerksegmenten ein. In Segment 1 (192.168.1.0) befinden sich 13 Win95-Clients. Der "samba"-Server in diesem Segment ist "WINS", "Local Master Browser" und "Domain Master Browser". In Segment 2 (192.168.3.0) befinden sich zusammen 30 Win95- und Win98-Clients. Ebenso steht dort ein "samba-2.0.6"-Server, der auf den WINS aus Segment 1 zugreift und innerhalb des Segments 2 der "Local Master Browser" ist. Bei allen Win9x-Clients habe ich die Browsing-Funktion deaktiviert, sodass die Browsing-Aufgaben stets bei den "samba"-Maschinen liegen. Auf allen Win9x-Clients kommt ausschliesslich das TCP-/IP-Protokoll zum Einsatz, d.h. Browsing-Konflikte durch andere Protokolle, wie z.B. "NetBEUI" oder "IPX" sind ausgeschlossen. Die beiden Netz-Segmente sind ueber einen separaten Linux-Router (dort laeuft kein Samba) miteinander verbunden. Alle Win9x-Maschinen nutzen zur NetBIOS-Namensaufloesung den "WINS", der sich in Segment 1 befindet. Das Browsing (d.h. Sichtbarwerden der einzelnen Rechner in der Netzwerkumgebung) funktioniert soweit einwandfrei. Alle Rechner "sehen" sich gegenseitig, auch wenn sie sich im jeweils anderen Netzwerksegement befinden. Der einzige Schoenheitsfehler, der auftritt ist, dass die Win9x-Rechner aus Segment 2 grundsaetzlich nicht mehr aus den Browselists verschwinden, auch wenn sie mehrere Tage ausser Betrieb sind. Sie werden immer angezeigt. Hingegen verschwinden die Win9x-Rechner aus Segment 1 nach dem Herunterfahren (wie gewuenscht) von den Listen der Netzwerkumgebung. Das ist zwar kein erhebliches Problem (zumal die Rechner ja ordnungsgemaess in der Netzwerkumgebung erscheinen), aber es stoert dann doch ein wenig, wenn die Browselist unnoetig durch abgeschaltete Rechner "aufgeblaeht" wird. Daher meine Frage: Hat jemand ein solches Problem bereits gehabt und eine Loesung gefunden? Handelt es sich evtl. um einen Bug im Browsing-System? Oder liegt eher ein Fehler in meiner "samba"-Konfiguration? Bei Bedarf kann ich gerne die relevanten Ausschnitte der "smb.conf" posten. Sobald ich das naechste Mal wieder "vor Ort" bin, werde ich ggf. auch mal den LogLevel ein wenig hoeher setzen - vielleicht finde ich ja dann weitere Informationen bzgl. dieses Problems. Ich freue mich auf jeden Hinweis! Viele Gruesse, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Moser wrote:
Hallo,
Hi Steffen! Irgendwie interessant, das Problem. Solltest Du aus der Newsgroup oder der Samba-Liste eine Loesung bekommen, waere ich daran auch interessiert. Ich habe bisher auch noch nichts mit Browsing ueber mehrere Subnets gemacht.
... Wir setzen Win9x-Clients zusammen mit "samba-2.0.6" (auf Linux 2.2.14) in zwei Netzwerksegmenten ein. In Segment 1 (192.168.1.0) befinden sich 13 Win95-Clients. Der "samba"-Server in diesem Segment ist "WINS", "Local Master Browser" und "Domain Master Browser".
In Segment 2 (192.168.3.0) befinden sich zusammen 30 Win95- und Win98-Clients. Ebenso steht dort ein "samba-2.0.6"-Server, der auf den WINS aus Segment 1 zugreift und innerhalb des Segments 2 der "Local Master Browser" ist. Die beiden WINS-Server sind auch jeweils "preferred master" ihrer Segmente?
Bei allen Win9x-Clients habe ich die Browsing-Funktion deaktiviert, sodass die Browsing-Aufgaben stets bei den "samba"-Maschinen liegen.
Kannst Du anhand der /var/log/log.nmb nachvollziehen, ob das auch Dein Netz so sieht (auch mit hoeherem Debug-Level)? Insbes., ob der LMB von Segment 2 sich auch an den Domain-Master aus Segment 1 wendet?
... Die beiden Netz-Segmente sind ueber einen separaten Linux-Router (dort laeuft kein Samba) miteinander verbunden. Dazu finde ich folgenden Abschnitt aus der BROWSING-Config.txt interessant: ... ' Normally, only unicast UDP messaging can be forwarded by routers. The "remote announce" parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the "remote browse sync" parameter of smb.conf implements browse list collation using unicast UDP.' ... Vielleicht kannst Du mal an Deinem Router ueberpruefen, ob er die Unicast-UDP-Pakete routed?
Und noch folgendes (ebenfalls aus BROWSING-Config.txt): ... ' Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time to establish a browse list and it can take up to 45 minutes to stabilise, particularly across network segments. ' ... Vielleicht musst Du "nur" laenger warten...? (Das kann sicher keine Loesung sein, aber vielleicht funktioniert ja in Deiner Config doch alles). Der Eintrag "wins hook" kann vielleicht in Deinem Fall auch nuetzlich sein... Wenn alles nichts hilft, so die BROWSING-Config.txt, soll man dann doch den Weg ueber "remote announce"/"remote browse sync" gehen... Rgds. Heiko. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, ich danke fuer die Antwort! Heiko Degenhardt wrote:
Irgendwie interessant, das Problem.
Und vor allem noch nicht geloest. ;-) Ich habe aber ueber die Samba-Mailingliste "samba@samba.org" mittlweile drei weitere Leute gefunden, die dasselbe Problem haben - auch die haben es bisher noch nicht geloest...
Solltest Du aus der Newsgroup oder der Samba-Liste eine Loesung bekommen, waere ich daran auch interessiert.
Ja...
Ich habe bisher auch noch nichts mit Browsing ueber mehrere Subnets gemacht.
Daher vielleicht nochmals kurz die Zusammenfassung, vielleicht interessiert es ja den einen oder anderen: - In jedem IP-Netz-Segment sind alle Rechner mittels Broadcast erreichbar. Broadcasts koennen IP-Netzwerk-Grenzen nicht ueberschreiten, da sie in der Regel von Routern nicht weitergeleitet werden. - In jedem IP-Netz-Segment wird pro Domaene ein lokaler Master Browser (LMB) gewaehlt. Entscheidend sind hier die Wahlkriterien (u.a. "OS Level", "uptime", usw.). - Jeder LMB sammelt in seinem Netz-Segment die anderen Windows-/Samba-Rechner. Das geht ueber Broadcasts. Damit gibt es in jedem Segment einen LMB, der alle Rechner des Segments kennt und damit die Browselists verwaltet. - Nun soll aber das Browsing segmentuebergreifend funktionieren. Daher gibt es pro Domaene einen Domaenen Master Browser (DMB). Alle LMBs liefern bei dieser einen Maschine ihre jeweilige Browselist ab. Der DMB bastelt daraus eine Browselist, die alle Rechner aus allen Netz-Segmenten enthaelt. Die LMBs holen beim DMB die komplette Browselist ab und geben sie an die einzelnen Workstations in den Netz-Segmenten weiter. Der DMB kann natuerlich nicht per Broadcast gefunden werden (wegen der Netz-Segment-Grenze). Daher braucht man hier WINS: - einerseits zur einfachen Aufloesung von NetBIOS-Rechnernamen zu IP-Adressen - andererseits damit die LMBs den DMB finden. Alternativ waere hier eine Konfiguration ueber "LMHOSTS" moeglich. Ist aber in einem grossen Netz aeusserst schwierig zu pflegen. Alle Maschinen muessen auf einen einzigen WINS zugreifen, sonst klappt es natuerlich nicht.
Die beiden WINS-Server sind auch jeweils "preferred master" ihrer Segmente?
Es gibt nur einen WINS-Server, dort registrieren sich alle Maschinen im Netz. Diese Maschine ist auch DMB. Die beiden Samba-Maschinen sind als "preferred master" konfiguriert.
Kannst Du anhand der /var/log/log.nmb nachvollziehen, ob das auch Dein Netz so sieht (auch mit hoeherem Debug-Level)?
Ja, der "fsa01" (Samba-Server in Segment 1) ist in seinem lokalen Netz-Segment mit Sicherheit LMB. Darueber hinaus ist er DMB und WINS (fuer alle Maschinen im Netz). Der "fsc01" (Samba-Server in Segment 2) ist in seinem lokalen Netz-Segment definitiv LMB. Ich hatte daher z.B. einen ganzen Tag den "log level" auf 3 und 4 gesetzt (und entsprechend viele Log-Informationen erhalten). Aber darin fand ich eigentlich nichts, was irgendwie auf die Ursache hindeuten koennte. Die Wahl zum LMB laeuft problemlos ab, da keine Konkurrenz vorhanden. Der Abgleich "LMB <---> DMB" funktioniert laut "log.nmb" problemlos. Nur scheint werden die Maschinen aus Segment 2 auch nach dem Ausschalten in den Browselists auf "fsa01" und "fsc01" gehalten. Die Maschinen aus Segment 1 verschwinden nach einer gewissen Zeit. In der "wins.dat" bleiben alle Maschinen drin - aber das stoert ja nicht, da die fuer die Browselist ja die "browse.dat" zustaendig ist.
Insbes., ob der LMB von Segment 2 sich auch an den Domain-Master aus Segment 1 wendet?
Ja, das tut er. Der LMB in Segment 2 tauscht mit dem DMB in Segment 1 die Browselist aus. Es sehen sich ja dann auch alle Rechner. Der LMB in Segment 2 findet den DMB in Segment 1 ueber den speziellen DMB-Record (<1B>) in der WINS-Datenbank. Eigenartigerweise klappt ja der Aufbau der Browselist problemlos. Spaetestens nach einigen Minuten sehen sich alle Rechner gegenseitig. Nur verschwinden die heruntergefahrenen Maschinen eben nicht nach einiger Zeit.
Dazu finde ich folgenden Abschnitt aus der BROWSING-Config.txt interessant: ... ' Normally, only unicast UDP messaging can be forwarded by routers. The "remote announce" parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the "remote browse sync" parameter of smb.conf implements browse list collation using unicast UDP.' ... Vielleicht kannst Du mal an Deinem Router ueberpruefen, ob er die Unicast-UDP-Pakete routed?
Ja, wobei in der "browsing.txt" auch steht, dass bei sauberer Konfiguration ueber WINS eigentlich die Parameter "remote browse sync" und "remote announce" nicht noetig sind: If only one WINS server is used then the use of the "remote announce" and the "remote browse sync" parameters should NOT be necessary.
Und noch folgendes (ebenfalls aus BROWSING-Config.txt): ... ' Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time to establish a browse list and it can take up to 45 minutes to stabilise, particularly across network segments. ' ... Vielleicht musst Du "nur" laenger warten...?
Der Aufbau der Browselist (d.h. bis eben alle Rechner von ueberall aus sichtbar sind) funktioniert. Nur verschwinden die ausgeschalteten Maschinen aus Subnetz 2 auch nach mehreren Tagen (Schulferien) nicht.
(Das kann sicher keine Loesung sein, aber vielleicht funktioniert ja in Deiner Config doch alles).
Ich denke eben, dass die Rechner spaetestens nach einigen Stunden verschwunden sein muessten. Ich sage nochmals dazu, dass das Problem nicht besonders tragisch ist, weil die Rechner ja angezeigt werden. ;-) Es ist nur etwas laestig, wenn dann die Rechner nicht wieder verschwinden, denn dann muss man immer durch Draufklicken testen, ob die Rechner wirklich noch am Netz sind oder nicht.
Der Eintrag "wins hook" kann vielleicht in Deinem Fall auch nuetzlich sein...
Das muss ich mir noch anschauen.
Wenn alles nichts hilft, so die BROWSING-Config.txt, soll man dann doch den Weg ueber "remote announce"/"remote browse sync" gehen...
Hatte ich schon ausprobiert, ohne dass ich eine Veraenderung bemerkt habe. Ich habe aber jetzt einen weiteren Tip bekommen, evtl. die "WINS ttl"-Parameter zu aendern bzw. zu setzen. Auch wenn mir das auf den ersten Blick nicht einleuchtet (weil ja WINS nur indirekt etwas mit dem Aufbau der Browselist zu tun hat), werde ich es mal ausprobieren und dann meine Erfahrungen hier wieder schildern... Gruss, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
heiko.degenhardt＠sentec-elektronik.de -
moser＠egu.schule.ulm.de