Bitte verwenden Sie Bugzilla, um Bugs zu melden, und lesen Sie zunächst dieses Kapitel, bevor Sie einen Bug melden. Bitte prüfen Sie gleichfalls, ob sich dieser Text nach einem Releasewechsel geändert hat, da wir an einigen Punkten den Mechanismus zum Thema Bug-Report ändern.

Bitte geben Sie so viele Informationen in dem Bug-Report an, wie Sie können. Wir bekommen täglich mehr Mails, als wir beantworten können, also helfen Sie uns bitte, indem Sie Ihren Bug so „entwickler-freundlich“ wie nur eben möglich beschreiben.

Bitte gehen Sie nicht davon aus, dass wir, wenn Sie einen Bug in der Newsgroup comp.protocols.smb posten, diese Nachricht lesen. Wenn Sie vermuten, dass es weniger ein Bug als ein Konfigurationsproblem ist, wenden Sie sich bitte an die Samba-Mailingliste, da dort Tausende von anderen Benutzern evtl. in der Lage sind, Ihnen zu helfen.

Ebenfalls hilfreich ist ein Durchsuchen der Mailinglisten-Archive, die über die Samba-Webseite http://samba.org/samba/ zu erreichen sind.

Bevor Sie einen Bug-Report senden, prüfen Sie bitte Ihre Konfiguration auf Tippfehler. Sehen Sie sich auch Ihre Log-Dateien daraufhin an, ob diese ggf. eine Nachricht anzeigen, dass etwas falsch konfiguriert worden ist. Um die Syntax Ihrer Konfiguration zu prüfen, führen Sie bitte testparm aus.

Haben Sie in ??? nachgeschaut? Dies ist absolut wichtig!

Wenn Sie Teile Ihrer Log-Dateien mit dem Report senden, stellen Sie sicher, dass Sie sie entsprechend Ihrer Tätigkeit am Client kommentieren und und mitteilen, wie sich das Resultat darstellt.

Wenn der Bug etwas damit zu tun hat, dass sich Samba als Server inkorrekt verhält (etwa es ablehnt, eine Datei zu öffnen), sind die Log-Dateien sehr nützlich. Je nach Problem ist ein Log-Level zwischen 3 und 10 sehr hilfreich, um das Problem zu analysieren. Ein höherer Log Level verspricht mehr Detail-Informationen, benötigt allerdings auch mehr Speicherkapazität.

Um den Debug-Level einzustellen, verwenden Sie die Option log level in Ihrer smb.conf. Es ist nützlich, für jede Maschine eine eigene Log-Datei zu verwenden und nur für eine Maschine den Log-Level höher einzustellen. Wenn Sie dies machen möchten, fügen Sie bitte folgende Zeilen zu Ihrer smb.conf hinzu:

Erstellen Sie außerdem eine Datei /usr/local/samba/lib/smb.conf.machine, wobei machine der Name des Clients ist, den Sie debuggen wollen. In dieser Datei können Sie alle smb.conf-Optionen setzen, zum Beispiel ist das Setzen des Parameters log level nützlich. Hier können Sie auch mit verschiedenen Sicherheitsoptionen experimentieren.

Der smb.conf-Eintrag log level ist ein Synonym für debuglevel, der in älteren Versionen von Samba verwendet wurde und dazu dient, die Abwärtskompatibilität zu älteren smb.conf-Dateien zu gewährleisten.

Sobald der Wert für den log level erhöht und Samba neu gestartet worden ist, werden Sie eine signifikant größere Menge an Debug-Informationen erhalten. Für gewöhnlich werden Sie keinen Level höher als 3 benötigen. Nahezu jeder Bug kann mit einem Log-Level von 10 festgestellt werden, aber machen Sie sich auf ein großes Datenvolumen an Log-Dateien gefasst.

Wenn Sie in Ihren Log-Dateien einen „INTERNAL ERROR“ bemerken sollten, bedeutet dies, dass Samba ein nicht erwartetes Signal bekommen hat. Dies ist wahrscheinlich ein „segmentation fault“ und deutet so gut wie sicher auf einen Bug in Samba hin (vorausgesetzt, Ihre Hardware oder Systemsoftware funktioniert einwandfrei).

Sollte die Nachricht vom smbd stammen, ist es meistens so, dass vor dieser Nachricht das Log noch die letzte SMB-Meldung enthält, die der smbd erhalten hat. Diese Information ist oft sehr nützlich, um das Problem zu lokalisieren: Bitte fügen Sie daher diese Meldung Ihrem Bug-Report hinzu.

Falls möglich sollten Sie so detailliert wie möglich erklären können, wie das Problem reproduziert werden kann.

Sie werden ebenfalls eine so genannte Core-Datei in einem corefiles -Unterverzeichnis in Ihrem Log-Verzeichnis entdecken. Diese Datei ist das nützlichste Tool, um einen Bug zu verfolgen. Um es zu verwenden, machen Sie Folgendes:

$ gdb smbd core

Fügen Sie die jeweiligen Pfade zu smbd und der Core-Datei zu gdb hinzu, damit gdb sie finden kann. Wenn Sie gdb nicht haben sollten, versuchen Sie es mit dbx. Anschließend verwenden Sie innerhalb des Debuggers das Kommando where, um einen stack-Trace der Stelle zu erhalten, an der das Problem auftrat. Fügen Sie diese Information der Bug-Meldung hinzu.

Wenn Sie Kenntnisse in einer Assembler-Sprache haben, führen Sie ein disass-Kommando zu der Routine hinzu, in der das Problem auftrat (wenn es in einer Library-Routine war, disassemblieren Sie die Routine, die sie aufgerufen hat), und versuchen Sie festzustellen, an welcher Stelle das Problem liegt, indem Sie sich den Code ansehen. Selbst wenn Sie keine Kenntnisse in Assembler-Programmierung haben, sollten Sie diese Information dem Report hinzufügen, dies kann sehr hilfreich sein.

Leider lassen es einige UNIX-Varianten (zum Teil auch einige Linux-Kernel) nicht zu, einen Coredump zu erstellen, wenn der Prozess die UID ändert (was smbd oft tut). Um dies dennoch zu debuggen, könnten Sie versuchen, sich in den laufenden Prozess einzuklinken, indem Sie gdb smbd PID ausführen, wobei Sie die PID aus dem smbstatus entnehmen können. Anschließend verwenden Sie das c-Kommando, um fortzufahren und um zu versuchen, den Coredump mit Hilfe des Clients zu erzeugen. Der Debugger sollte den Fehler erfassen und Ihnen mitteilen, wo er auftrat.

Die beste Art von Bug-Reports sind die, die bereits einen Fix beinhalten! Wenn Sie uns Patches schicken, verwenden Sie bitte das diff -u-Format, wenn Ihre Version von diff dies bereitstellt. Ansonsten verwenden Sie bitte diff -c4. Stellen Sie sicher, dass Sie Ihr diff gegen eine saubere Version des Source-Codes erstellen, und lassen Sie uns wissen, welche Version genau Sie verwenden.