Samba 4: Wenn der WLAN-Router zum Domänencontroller mutiert
Golem.de: Die kommende Samba-Version 4 wird eine komplette Neuentwicklung mit ambitionierten Zielen. Wie ist der aktuelle Status der Entwicklung?
Golem.de: Wird denn Samba 4 alle Funktionen unterstützen, die Samba 3 mitbringt?
Lendecke: Prinzipiell schon, aber Samba 3 enthält viele kleine Hacks, die zum Teil daraus resultieren, dass wir einst bestimmte Protokollfunktionen noch nicht vollständig umsetzen konnten. Ein kleines Beispiel sind die Optionen 'remote announce' und 'remote browse sync'. Damals hatten wir das Browsing-Protokoll noch nicht verstanden, heute aber beherrschen wir diese Dinge vollständig. Letztendlich stellt sich nun die große Frage, welche dieser Funktionen man wieder übernimmt.
Golem.de: Wird dies Auswirkungen für die Nutzer von Samba haben?
Lendecke: Nein, allerdings unterstützen wir einige hundert Konfigurationsparameter, die sicher irgendjemand auf der Welt auch benutzt. Ich bezweifle, dass wir wirklich alle portieren können. Es kann also durchaus sein, dass es irgendwo auf der Welt jemanden geben wird, der seine Lieblingsfunktion nicht wieder findet.
Golem.de: Die Fertigstellung von Samba 4 war für Ende 2005 angepeilt. Ist der Termin zu halten?
Lendecke: Ende 2005 ist ein Ziel. Ich würde sage, im Moment sieht es noch gut aus, vorausgesetzt, die Entwicklung schreitet so voran wie bisher.
Golem.de: Heißt das, man wird Samba 4 schon Anfang 2006 produktiv einsetzen können?
Lendecke: Schwer zu sagen. Das hängt auch davon ab, welche Teile man einsetzt. Es hat in der Entwicklung von Samba als NT4-Domänencontroller einige Verzweigungen gegeben, beispielsweise Samba TNG. Damals war es durchaus üblich, Samba 3 als reinen Domänencontroller oder Samba TNG einzusetzen, für Datei- und Druckdienste aber auf der gleichen Maschine ein Samba 2 als Domänenmitglied aufzusetzen. So ein Modell – zwei Samba-Instanzen parallel auf einer Maschine – wäre auch heute denkbar. Letztendlich kommt es darauf an, welche Teile von Samba 4 man schon nutzen muss und welche Teile man von Samba 3 noch weiter nutzen kann.
Golem.de: Andrew Tridgell verspricht für Samba 4 eine vollständige Protokoll-Unterstützung. Wo hat Samba Nachholbedarf?
Lendecke: Samba 3 unterstützt beispielsweise die Access Control Lists (ACLs) von Windows NT nicht vollständig und beherrscht auch keine NTFS Data Streams. Zudem ist Samba 3 kein Active-Directory-Domänencontroller.
Golem.de: Wie werden denn die NTFS Data Streams implementiert, schließlich gibt es unter Unix oder Linux kein Äquivalent?
Lendecke: Dazu wurde mit Samba 4 eine API geschaffen, mit der erst einmal kleine Data-Streams in Extended Attributes abgelegt werden – Word-Meta-Informationen werden so beispielsweise in den Extended Attributes gespeichert. Alternativ gibt es eine Implementierung, die sämtliche Data-Streams in einer großen Datenbank ablegt. Allerdings werden wir das noch ändern und die Daten in Unterverzeichnissen speichern – ein Unterverzeichnis pro Verzeichnis. Für Windows werden diese Unterverzeichnisse nicht sichtbar sein.
Golem.de: Es soll unter anderem eine eigene LDAP-Implementierung geben, warum?
Lendecke: OpenLDAP ist für Programmierer intern ziemlich schwierig zu handhaben. Zudem hat die OpenLDAP-Entwicklergemeinde eine gewisse Aversion gegen Nicht-RFC-konforme Erweiterungen durch Microsoft. Das Samba-Team müsste sowohl auf Netzwerkseite als auch im Datenbank-Backend von OpenLDAP umfangreiche Module bauen, um vollständig konform zu Active-Directory zu werden. Was darüber hinaus noch bleibt, ist nicht mehr so schrecklich viel.
Golem.de: Handelt es sich dabei um eine allgemeine LDAP-Implementierung oder um eine Speziallösung für Samba?
Lendecke: Im Prinzip wird man unsere LDAP-Implementierung als Ersatz für OpenLDAP verwenden können, vielleicht nicht mit allen Funktionen, die OpenLDAP bietet, aber es wird ein genereller LDAP-Server werden.
Golem.de: Wo liegen die Probleme konkret?
Lendecke: Wir müssen einerseits in Bezug auf die Authentifizierungsmechanismen Erweiterungen auf Protokollseite machen. Andererseits müssen wir den Datenbankbereich von OpenLDAP erweitern, denn wir müssen immer exakt mit dergleichen Datenbasis sprechen. Ändert ein Microsoft-Client mit einem Mechanismus ein Passwort, erwartet er, dass diese Passwortänderungen auch auf einem anderen Mechanismus sofort sichtbar werden. Replikationsgeschichten können wir uns nicht erlauben.
Daher kommen wir nicht daran vorbei, ein eigenes Datenbank-Backend zu schreiben, das mit unserer LDB-Datenbank spricht. Wenn man also auf der Protokollseite (Port 389) Änderungen machen muss, sogar auf Seiten des Datenmodells, dann bleibt von OpenLDAP nicht mehr so viel übrig, als dass man es nicht ersetzen könnte.
Golem.de: Welche anderen Vorteile wird die LDAP-Implementierung des Samba-Teams gegenüber OpenLDAP haben?
Lendecke: Wir behaupten, das Aufsetzen unserer Implementierung wird im Vergleich zu OpenLDAP sehr viel einfacher sein, aber das ist sicherlich unsere Sicht der Dinge. Das OpenLDAP-Team sagt ganz klar, es bietet eine Software von Entwicklern für Entwickler an. Der Bedarf aus der realen Welt ist für sie nachrangig, würde ich sagen.
Das zeigt sich insbesondere daran, dass sie nicht bereit sind, Microsofts Erweiterungen mitzugehen, beispielsweise was "Range Retrievals" von Attributen betrifft. Dies wird OpenLDAP so nicht unterstützen. Will man aber Active-Directory-konform sein, muss man das unterstützen. Es ist keine schöne Implementierung, löst aber ein reales Problem.
Obendrein ist der OpenLDAP-Code intern im Wesentlichen komplett undokumentiert. Es ist sehr anstrengend, Erweiterungen dafür zu schreiben.
Wir werden OpenLDAP aber immer unterstützen, wenn auch nicht unbedingt im ersten Release. Es wird definitiv möglich sein, ein existierendes LDAP-Directory als Datenbank-Backend zu nutzen. Wer also in der Firma schon eine umfangreiche Installation aufgesetzt hat, wird unsere Daten auch immer dort ablegen können.
Golem.de: Was das Thema Directory-Server betrifft, hat SerNet aber auch einiges in Richtung Novell bewegt.
Lendecke: Wir haben das gewaltig vorangetrieben und jeden Kontakt und jede Veranstaltung genutzt, um Novell dazu zu bringen, die Passwörter herauszugeben. Will man Samba mit einem Novell Directory Server (NDS) im Hintergrund betreiben, benötigt Samba im Wesentlichen Lesezugriff auf die Klartext-Passwörter. Nicht, dass wir diese selbst benötigen, aber aus den Klartext-Passwörtern lassen sich die Windows-konformen Passwort-Hashes leicht generieren. Novell hatte das lange Zeit aus Sicherheitsgründen verweigert.
Letztendlich hat Novell den Code aber selbst geschrieben, schließlich verfügt nur Novell über die dafür notwendigen Informationen. Mittlerweile ist der Code auch eingecheckt, so dass wir nun Lesezugriff auf die Klartext-Passwörter im NDS haben, wenn wir diesen ganz normal über SSL ansprechen.
Golem.de: Samba 4 soll nicht länger an POSIX gebunden sein, sondern auch mit anderen Backends arbeiten können. Welche Anwendungsszenarien hat man hier im Auge?
Lendecke: Zum Beispiel einen WLAN-Router, der nebenbei auch noch Active-Directory-Domänencontroller spielt.
Golem.de: Sind hier denn schon Router-Hersteller in den Startlöchern?
Lendecke: Nein, das ist erstmal nur eine Idee. Wir bewegen uns mit Samba 4 einfach ein gutes Stück von der POSIX-Gebundenheit weg – von Unix in Richtung Windows. Samba 3 ist, was die ganze Authentifizierung angeht, sehr an das gebunden, was Unix liefert. Wir brauchen immer nummerische UIDs und GIDs.
In Samba 4 wurde das sehr viel besser gekapselt. Zwar kann Samba 4 als Unix-Client mit allen Rechten und Pflichten laufen, man ist aber sehr viel freier, wenn es darum geht, native Backends zu schreiben. Wozu benötigt Samba 3 letztendlich Unix-Rechte? Um während eines Dateizugriffs nachschauen zu können, ob ein Nutzer über die erforderlichen Berechtigungen verfügt.
All das ist bei Samba 4 im so genannten "virtuellen POSIX-Dateisystem" gekapselt. Man könnte Samba nun theoretisch als Root mit einem NTFS-Backend laufen lassen. Auch könnte Samba direkt NTFS sprechen oder auf eine Datenbank mit der NTFS-Semantik zugreifen. Dieser Datenbank ist es völlig egal, ob der Unix-Nutzer nun Root ist oder nicht, sie will eine Liste von SIDs sehen.
Golem.de: Ursprünglich war Samba nur dafür gedacht, eine Brücke zwischen Windows und Linux zu schlagen. Künftig soll die Software aber auch für Unix-zu-Unix-Verbindungen eingesetzt werden. Welche Vorteile bietet Samba hier im Vergleich zu anderen Protokollen, insbesondere NFS?
Lendecke: Es gibt im Unix-zu-Unix Bereich schlicht nichts, was wirklich skaliert, sicher und obendrein einfach zu administrieren ist. Liest man die NFSv4-RFCs, so hat man als Samba-Entwickler ein Déjà-vu nach dem anderen.
So löst NFSv4 einige Probleme, die NFSv2 und NFSv3 haben, z.B. sauberes Caching durch Clients sowie Probleme hinsichtlich Locking und Access Control Lists. All diese Dinge sind in irgendeiner Form an Windows angenähert, insbesondere die NFSv4-ACLs sind nach den Windows-ACLs modelliert.
NFSv4 ist zumindest unter Linux auch noch nicht wirklich fertig, für CIFS gibt es bereits einen sehr gut eingeführten Server und ständig verbesserte Clients. Warum sollte man CIFS also nicht ein wenig um POSIX-Funktionen aufbohren?
Im Übrigen gilt das auch im Hinblick auf andere Funktionen: Was bei NFS Leases heißt, nennt Samba Oplocks. Zudem hat NFS nun auch Byterange Locks, die NFSv2 noch gar nicht kannte. Gleiches gilt für die Authentifizierung pro Nutzer. All dies muss ein Samba-Server ebenso wie ein NFSv4-Server unterstützen. Nun mag das CIFS-Protokoll hässlich sein, aber er verfügt bereits über all die Funktionen, die in NFSv4 dicht an die Windows-Semantik angelehnt sind.
Letztendlich muss man sich die Frage stellen, wozu es noch eines NFSv4-Servers bedarf, wenn man auch einen um POSIX-Funktionen aufgebohrten Samba-Server – in großen Teilen sind diese Funktionen schon vorhanden – zusammen mit einem sauber implementierten CIFS-Client nutzen kann.
Golem.de: Komplett umgestaltet wird auch das Prozessmodell. Ein einzelner Prozess soll künftig alle Client-Verbindungen verarbeiten können und auch eine Thread-gestützte Variante ist geplant. Inwiefern wird dies die Skalierbarkeit beeinflussen?
Lendecke: Die Thread-Variante wird nicht mehr aktiv gepflegt, da Threads prinzipbedingt langsamer sind als Prozesse. Das Ein-Prozess-Modell hingegen hat große Vorteile beim Debugging sowie für Embedded-Systeme. Das Standardmodell von Samba 4 wird jedoch dem Modell von Samba 3 sehr ähneln.
Golem.de: Was bedeutet das für die Skalierbarkeit des Ganzen?
Lendecke: Wir haben keine Probleme mit der Skalierbarkeit, zumindest nicht, was die Anzahl der Prozesse angeht. Die ganze Thread-Diskussion kommt letztendlich aus der Solaris-Ecke. Der Fork-Systemaufruf war unter Solaris jämmerlich implementiert, wie auch unter vielen anderen kommerziellen Unixen, so dass dort auf Threads gesetzt wurde.
Bei Threads muss man aber zusätzliche Arbeit im Userspace leisten, die normalerweise die CPU und die MMU übernimmt. Bestimmte Systemressourcen sind von Natur aus Single-Threaded – Speicher zum Beispiel. Fordern zwei Applikationen gleichzeitig Speicher an, gibt es ein Chaos. Es muss im Userspace also irgendeine Art von Locking implementiert werden und auch eine Koordinierung stattfinden. Dafür ist aber eigentlich die MMU einer CPU gedacht, was bedeutet, dass bei Threads Dinge in Software erledigt werden, die normalerweise die Hardware übernimmt.
Da unter Linux die Prozessunterstützung aber optimal ist, können Threads definitiv nicht schneller sein als Prozesse, das lässt sich mit Tests belegen. Andrew Tridgell hat einige Tests unter Solaris, Irix und AIX durchgeführt und dabei festgestellt, dass Prozesse auch unter AIX für bestimmte Aufrufe deutlich schneller sind.
Golem.de: Das Samba-Team drängt im Rahmen des EU-Kartellverfahrens gegen Microsoft auf die Herausgabe von Protokoll- und Verschlüsselungsinformationen durch Microsoft. In welcher Hinsicht könnte die Verfügbarkeit der entsprechenden Informationen die Samba-Entwicklung beeinflussen?
Lendecke: Eine entsprechende Lizenz, die die Nutzung der Informationen in freier Software erlaubt, könnte die Entwicklung von Samba deutlich beschleunigen. Im Moment hinken wir viele Jahre hinterher, weil wir einen ungleich höheren Aufwand treiben müssen, um allein aus dem Abhören des Netzwerkverkehrs die Protokollinformationen herauszubekommen.
Golem.de: Welchen Anteil hat die eigentlich "unnötige" Analyse des Netzwerkverkehrs?
Lendecke: Das variiert stark. Laufen Netzwerkaufrufe unverschlüsselt über das Netz, geht es relativ flott. Man bekommt schnell Übung darin, diesen Hex-Dump-Output zu lesen.
Richtig haarig wird es bei Microsofts Kryptographiegeschichten: Erweiterungen für Kerberos oder Erweiterungen für andere NTLM-Authentifizierungsmethoden, bei denen der Datenstrom verschlüsselt ist. Das ist viel Arbeit und man muss lange "draufstarren". Es ist eher einer Frage der Intuition, daher lässt sich nicht abschätzen, wie groß der Anteil ist.
Golem.de: Samba ist eine der wichtigsten Komponenten, wenn es um eine Windows-Linux-Migration geht. Oft ist die Umstellung der Server auf Linux/Samba ein erster Schritt, zumal viele Nutzer gezwungen sind, bestehende NT4-Systeme zu ersetzen. Wo sind dieser Kombinationen Grenzen gesetzt, so dass kein Weg an Software von Microsoft vorbeiführt?
Lendecke: Schwierig wird es immer dann, wenn Server-Komponenten wirklich Windows-Systeme voraussetzen. Applikations-Server sind in der Regel nicht wirklich zu ersetzen. Bei Datei- und Druck-Servern und Domänencontrollern gibt es eigentlich kaum noch Probleme.
Golem.de: Vom 2. bis 4. Mai 2005 findet wieder einmal die internationale Samba-Konferenz SambaXP in Göttingen statt. Dort wird auch "Linux auf dem Desktop" ein Thema sein. Wie stellt sich der konkrete Zusammenhang mit Samba dar?
Lendecke: Die Frage ist: Wie verwalte ich die Benutzer auf den Clients und wie verteile ich die Home-Verzeichnisse? NIS und NFS sind zu unsicher, AFS als Dateisystem zu komplex. Wir sehen in cifsfs/Samba eine Alternative. LDAP ist für viele als NIS-Ersatz ebenfalls Overkill. In vielen Umgebungen ist ohnehin bereits Samba als Domänencontroller im Einsatz. Es wird in der Zukunft Erweiterungen von Samba geben, die eine absolut nahtlose Integration eines Linux-Clients in eine Samba-Domäne ermöglichen. Auch hier: Wieder eine Alternative, die aber zumindest aus unserer Sicht viele Vorteile bietet.
Samba muss sich letztendlich um die gesamte Verwaltung von Arbeitsplatzmaschinen kümmern. Das sind zwar erst einmal Windows-Maschinen, aber dieses Protokoll ist so flexibel, dass sich letztendlich damit auch Linux-Arbeitsplätze verwalten lassen.
Golem.de: Das heißt, Linux-Clients können sich an einer Domäne ebenso anmelden wie ihre Windows-Pendants und auch ihre Heimatverzeichnisse mounten? Wann wird man das nutzen können?
Lendecke: Das ist die Idee dahinter. Wir sind zwar noch nicht ganz so weit, aber da wollen wir hin, durchaus schon mit Samba 3.