Einblicke in die bevorstehende Major-Release

Zum Redaktionsschluss des Linux-Magazins ist Samba 3.0 bei der zweiten Beta-Release angelangt.[1] Das Inspizieren der Anzahl der CVS-Checkins macht klar, dass das Entwicklerteam intensiv an der endgültigen Release arbeitet. Nach dem Erscheinen dieses Hefts werden vermutlich nur wenige Wochen bis zu dem Ereignis vergehen. Schon heute sind eine Menge Beta- und Alphaversionen von Samba 3.0 im Einsatz, zum Beispiel im Bundeskartellamt. Der Grund für die Ungeduld sind neue attraktive Features, mit denen die Major-Release gegenüber der etablierten Version 2.2[2] auftrumpft.

Zwei Verbesserungen sind nach außen nicht oder kaum sichtbar: Die Unterstützung von NT-Errorcodes und die Darstellung von Dateinamen im Unicode-Format. NT-Errorcodes treten für den Benutzer überhaupt nicht in Erscheinung, sie sind aber wichtig für eine zu Windows kompatible Fehlerbehandlung. Viele Windows-Anwendungen verlassen sich darauf, dass sich ein SMB-Fileserver in allen Aspekten genau wie Windows verhält, und damit bewegt sich Samba ein gutes Stück in Richtung NT.

Die Unterstützung von Unicode-Dateinamen hat als Konsequenz, dass Umlaute und andere Nicht-Ascii-Zeichen unabhängig von der Client-Version darstellbar sind: Clients in verschiedenen Länderversionen, die gemeinsam auf einem Dateiserver arbeiten, sehen die gleichen Dateinamen. Die Samba-2-Optionen »client code page« und »character set« haben sich damit erledigt.

Mit Samba 3 ist die Option »unix charset« wesentlich. Sie beschreibt, wie Dateinamen in Unix kodiert sind, und steht per Default auf »UTF8«, der 8-Bit-Variante von Unicode. Damit sind sämtliche unter Windows vorkommenden Zeichen im Unix-Dateisystem darstellbar. Diese Voreinstellung sollte der Administrator bei Neuinstallationen nicht verändern. Beim Upgrade von Samba 2.2 nach 3.0 werden die Umlaute in Dateinamen jedoch ohne Zutun nicht überleben. Die viel verwendeten Einstellungen

client code page = 850
character set = 8859-1

muss der Admin in Samba 3 mit »unix charset = CP850« anpassen, um die vorhandenen Dateinamen zu erhalten.

Die Option »dos charset« ist ausschließlich für Clients unter DOS und Windows 3.11 wesentlich. Alle Systeme ab Windows 95 benutzen Unicode für die Dateinamen, müssen also nicht länderspezifisch eingestellt werden. »display charset« legt den Zeichensatz fest, mit dem Samba seine eigenen Meldungen auf dem Bildschirm ausgibt. Für das Funktionieren als Server ist die Option daher eher unwichtig.

Eine weitere Änderung im Dateiserver-Betrieb betrifft die VFS-Module. Mit Samba 3 ist es möglich, mehr als ein Modul gleichzeitig zu laden. Damit kann man beispielsweise einen Virenscanner und den Papierkorb parallel nutzen. Entsprechend haben die Samba-Entwickler die Option »vfs object« in »vfs objects« umbenannt. Die Änderung bedeutet leider, dass nicht unmittelbar für Samba 3.0 gelieferte Module angepasst und neu kompiliert werden müssen.

Konfigurierbare Passdb-Backends

Wer SuSEs Samba-Pakete einsetzt, darf dank der Arbeit von Lars Müller zur Laufzeit auswählen, ob Samba die Datei »smbpasswd« benutzt oder ob er Samba an den LDAP-Dienst binden will. Das funktioniert bei SuSE nur, weil Samba im Wesentlichen doppelt auf der Platte liegt - einmal mit und einmal ohne LDAP kompiliert. Die Besitzer aller anderen Distributionen müssen sich bereits beim Kompilieren entscheiden: »smbpasswd« oder LDAP. Intern heißt die Schnittstelle zum Inhalt der »smbpasswd«-Datei Passdb-Interface.

Passdb-Module dynamisch konfigurieren

Samba 3 kann im Gegensatz zu Samba 2.2 »passdb«-Module dynamisch konfigurieren oder sogar als Shared Object nachladen. Der entsprechende Parameter heißt »passdb backend«. Der Defaultwert für den Parameter ist

passdb backend = smbpasswd

und liefert exakt die Funktionalität von Samba 2.2 ohne Zugriff auf LDAP. Alternative Module sind »tdbsam«, »ldapsam_compat« und »ldapsam«.

Die Variante mit der »smbpasswd«-Datei als Passdb-Backend kann die Passwörter für Samba speichern, aber nicht viel mehr. Für einen normalen Datei- und Druckserver reicht dies völlig aus. Soll Samba aber als Domänencontroller arbeiten, müssen über den Benutzer mehr Daten gespeichert werden, zum Beispiel der Ort des Server-gespeicherten Profils und der Name des verwendenden Login-Skripts. Samba kennt globale Parameter wie »logon path«, die zwar mit Makros wie »%U« pro Benutzer angepasst werden können, die aber auch ziemlich unflexibel sind.

Man könnte natürlich die »smbpasswd« um die benötigten Felder erweitern, was aber programmtechnisch sehr unschön wäre. Per Programm in einer Klartextdatei Felder unterschiedlicher Länge zu ändern, liefe darauf hinaus, die Datei bei jeder Änderung komplett neu zu schreiben. Die Passwortfelder haben die Eigenschaft, eine feste Länge zu haben. Die kann man auch in einer Klartextdatei sehr einfach überschreiben.

Mit Samba 3 gibt es eine sehr einfache Möglichkeit, die Einschränkungen beim PDC zu beheben. Mit dem Parameter »passdb backend = tdbsam« werden die Informationen der »smbpasswd«-Datei in der Datei »passdb.tdb« abgelegt. Sie lässt es zu, alle Felder für die Benutzer einzeln festzulegen, und zwar entweder mit dem Programm »pdbedit« oder in für Windows-Administratoren gewohnter Form im NT-Benutzermanager. Die MMC von Windows 2000 eignet sich übrigens nicht dafür, NT-Benutzer zu editieren, da sie ausschließlich mit Active Directory umzugehen versteht.

Bei den binären »tdb«-Dateien gibt es wie bei allen Datenbanken das Problem, dass sie während des Betriebs nicht konsistent gesichert werden können - fatal für die zentrale »passdb.tdb«. Daher gibt es das Programm »tdbbackup«, das jede »tdb«-Datei ausliest und in eine andere »tdb«-Datei konsistent kopiert. Diese Kopie wird danach nicht mehr benutzt und darf gesichert werden.