Beitragstitel: Samba Status Report Samba als Verbindungselement zwischen Windows und Unix entwickelt sich ständig weiter. Der Vortrag richtet sich an Anwender von Samba, die sich über den aktuellen Entwicklungsstand informieren wollen. Im wesentlichen können diese Informationen durch Studium der Samba-Mailinglisten und Release Notes von Samba gewonnen werden. Wem das zu unübersichtlich ist, oder wer Rückfragen hat, ist in diesem Vortrag richtig. * Active Directory Samba stellt seit der Version 4.0 einen Domänencontroller für Active Directory zur Verfügung. Die erste Version des AD-Controllers hatte deutliche Schwächen, insbesondere bei der Eignung für größere Umgebungen. Samba benutzt als Benutzerdatenbank die Trivial Database tdb. Tdb wurde ursprünglich als Mechanismus entwickelt, temporäre Daten zwischen smbd-Prozessen auszutauschen. Transaktionen, die für eine verlässliche Benutzerdatenbank nötig sind, wurden später hinzugefügt. Eine wesentliche Beschränkung bleibt jedoch: tdb-Dateien sind auf 4GB Größe beschränkt, was in großen Active Directory Umgebungen zu wenig ist. Mit Samba 4.9 kann man optional die LMDB-Datenbank aus dem OpenLDAP-Projekt benutzen. Diese Datenbank ist speziell für den Einsatz als Backend für große LDAP-Verzeichnisse konzipiert und unterliegt nicht mehr der 4GB-Beschränkung. Die ersten Versionen des AD-Controllers waren nicht in der Lage, Vertrauensstellungen zwischen Active Directories aufzubauen. Mit Samba 4.9 ist diese Beschränkung im wesentlichen aufgehoben worden. Für viele Umgebungen kann man jetzt mehrere Active Directories per Vertrauensstellung verbinden. In einigen Umgebungen ist ein detailiertes Protokoll sämtlicher Änderungen an der AD-Benutzerdatenbank und sämtlicher Anmeldevorgänge gefordert. Seit Version 4.7 können Anmeldevorgänge, und seit Samba 4.9 Änderungen der Datenbank im json-Format protokolliert werden, um Compliance-Anforderungen zu erfüllen. * Clustering ctdb, die zentrale Komponente, die Samba im Cluster verfügbar macht, hat mit Samba 4.9 einige wesentliche Änderungen erfahren. Historisch war ctdb ein monolithischer Prozess, der sämtliche Aufgaben zentral erledigt hat. Angefangen mit der Verwaltung der Cluster-Mitgliedschaft über die Dienste-Überwachung und zuteilung von IP-Adressen bis hin zur eigentlichen Aufgabe von ctdb, der Bereitstellung von tdb-Daten im Cluster war alles in einem Dämon implementiert. In der jüngeren Vergangenheit haben die ctdb-Entwickler darauf hingearbeitet, diese unterschiedlichen Aufgaben in separate Dämonen auszulagern. Ein Ergebnis dieser Arbeit ist, daß sich die Konfiguration von ctdb grundlegend geändert hat. Anstatt alles über Kommandozeilenparameter einzustellen, gibt es für ctdb jetzt eine eigene Konfigurationsdatei, deren Syntax an die smb.conf angelehnt ist. Auch hat sich geändert, wie Dienste von ctdb überwacht werden. Mit dem Umstieg von 4.8 nach 4.9 muß der Administrator auf jeden Fall seine ctdb-Konfiguration anpassen. * SMB2-Unix Extensions SMB als Windows-zentriertes Protokoll eignet sich nur begrenzt als Basis für Unix-Dateisysteme. Symlinks, Unix-Domain Sockets und Posix-Zugriffsrechte sind Beispiele, die durch das reine SMB-Protokoll nicht übertragen werden können. Damit ist es nicht möglich, NFS durch SMB für alle Anwendungen zu ersetzen. In der veralteten Protokollversion SMB1 gab es Erweiterungen, durch die ein voller Ersatz von NFS möglich war. Von Symlinks über Device Nodes, Sockets und ACLs konnte die komplette Unix-Semantik durch das Linux cifsfs mit Samba als Server benutzt werden. SMB2 ist inzwischen auch schon einige Jahre alt, und seit seiner Entwicklung diskutiert die Samba-Gemeinde die notwendigen Erweiterungen. Inzwischen gibt es Patches für das Linux cifsfs und für den Samba-Server, um die Posix Erweiterungen für SMB2 zu implementieren. Diese Patches befinden sich zu Ende Dezember 2018 im Review und möglicherweise zum Zeitpunkt des Vortrags bereits im Code.