Diesen Monat feiert das OpenLDAP-Projekt seinen zwanzigsten Geburtstag! Sein Geburtsjahr ist 1998 als Kurt Zeilenga und andere beschlossen, Patches zu konsolidieren, die über Mailinglisten und Newsgroups verbreitet worden waren, um den ursprünglichen eigenständigen LDAP-Servercode der University of Michigan (slapd) zu verbessern. Nachdem Kurt Zeilenga zurückgetreten war, übernahm Howard Chu die Rolle des Chefarchitekten des Projekts. Das OpenLDAP-Projekt folgt traditionell der Unix-Design-Philosophie „One Job – One Tool“. Unter der Leitung von Kurt Zeilenga wurde die Entwicklung von OpenLDAP als Referenzimplementierung des „Lightweight Directory Access Protocol“ (LDAP) vor allem durch Internet Drafts und RFCs vorangetrieben. Dieser Fokus auf Offenheit und Interoperabilität machte das Projekt zu einem wichtigen Meilenstein in der Landschaft der Netzwerkdienste und wurde von allen großen Enterprise-Linux-Distributionen unterstützt, die OpenLDAP als gepflegte Komponente ihrer Produkte anboten.
RedHat und SUSE kündigten an, die Unterstützung für OpenLDAP zurückzuziehen
Leider wird sich dies in diesem Jahr ändern, da RedHat und SUSE angekündigt haben, die Unterstützung für OpenLDAP in ihren Enterprise-Linux-Angeboten zugunsten von RedHats eigenem 389 Directory Server (389-ds) zurückzuziehen. Diese Nachricht wurde den Kunden in den Versionshinweisen von SLE 15 mitgeteilt. Der 389 Directory Server Das Projekt basiert auf der Codebasis aus dem Jahr 1996, als Netscape den LDAP-Gründer Tim Howes und einige seiner ehemaligen Kollegen von der University of Michigan unter Vertrag nahm. Diese Codebasis wurde 2004 von RedHat erworben und als Open Source unter der Gnu Public License (GPL) veröffentlicht und erweitert.
OpenLDAP 1.0 selbst wurde 1998 aus Verbesserungen geboren, die die Community im Laufe von zwei Jahren gesammelt hatte. Der heutige Code wurde mit dem zweiten Major-Release so stark verbessert, dass er kaum noch etwas mit dem ursprünglichen Code gemein hat.
Der GPL-lizenzierte Quellcode von 389 Directory Server ist die technologische Basis zweier separater Angebote. RedHat unterscheidet zwischen der Identity Management (IdM)-Lösung FreeIPA (Identity, Policy, Audit) einerseits und dem „Red Hat Directory Server“ (RHDS) andererseits. Letzteres empfiehlt sich für allgemeine geschäftskritische Anwendungen mit besonderen Anforderungen. Weitere Informationen finden Sie unter den folgenden Links.
- https://rhelblog.redhat.com/2015/06/01/identity-management-or-red-hat-directory-server-what-one-should-i-use/
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/index#comparing
Für den Betrieb des RHDS-Produkts benötigen Sie jedoch ein separates Support-Abonnement. Die Entscheidung von RedHat, sich ausschließlich auf 389-ds zu konzentrieren, muss in diesem Zusammenhang gesehen werden. Gemäß dieser Ankündigung wird OpenLDAP in der nächsten Hauptversion von RedHat Enterprise Linux nicht mehr unterstützt und das Softwarepaket „openldap-servers“ ist in RHEL 7.4 bereits veraltet (siehe Abschnitt „Wichtig“ in dieser Ankündigung). P>
Mit diesem Schritt werden RedHat-Kunden, die OpenLDAP verwenden, in eine Situation gebracht, in der sie entweder auf 389-ds (oder RHDS) migrieren oder auf OpenLDAP-Pakete von Drittanbieterangeboten für Support zurückgreifen müssen (z. B. https://symas.com/message -president-bezüglich-red-hat-suse-removing-openldap-linux-distributions/ und https://daasi.de/en/2017/09/25/red-hat-wont-continue-openldap-support-rhel- 8-daasi-international-unterstützt-migration/). Von der Community verwaltete Pakete werden weiterhin verfügbar sein.
Univention nimmt eine andere Perspektive ein
Seit 2003 Univention unterstützt OpenLDAP für den Einsatz in Unternehmen. Es ist eine der zentralen Komponenten ihres Produkts Univention Corporate Server (UCS). Dies ist möglich, da OpenLDAP seit jeher mit einem hohen Maß an Professionalität gepflegt wird. Die gesamte Community reagiert schnell und professionell auf Fragen und eingereichte Patch-Vorschläge. Das OpenLDAP-Team liefert Feature-Releases in einem Tempo von etwa 12-18 Monaten, unterbrochen von Wartungs-Releases nach Bedarf. Die Feature-Releases reifen lange und sind nicht an den Druck von Release-Terminen gebunden. In diesem Punkt arbeitet das Projekt ähnlich wie andere Open-Source-Projekte wie Debian. Dies ist für Distributoren in Bezug auf die Produktfreigabeplanung nicht immer einfach zu handhaben, aber es ist die Freiheit solcher Projekte, in ihrem eigenen Maß zu entscheiden, wann etwas als zur Veröffentlichung bereit gilt.
All dies sind Gründe, warum Univention UCS mit OpenLDAP auch seinen Enterprise-Anwendern empfiehlt. In der größten UCS-Bereitstellung des französischen Telekommunikationsanbieters Orange bedient OpenLDAP bis zu 30 Millionen Authentifizierungskonten und bewies höchste Skalierbarkeit und Stabilität.
Zuverlässigkeit, Leistungsfähigkeit und Skalierbarkeit der Basistechnologie ist ein entscheidendes Kriterium für den Betrieb in professionellen Domänen. Aus dieser Sicht, so argumentiert Univention, sei die Entscheidung von RedHat und SUSE schwer zu rechtfertigen. 389-ds setzt aktuell noch auf ein Sleepycat Berkeley DB Backend, während OpenLDAP seit 2.4 die moderne LMDB (Lightning Memory Database) als Backend empfiehlt. Die No-SQL/Key-Value-Datenbank LMDB wurde von Howard Chu erfunden und entwickelt, der seit 2007 Chefarchitekt des OpenLDAP-Projekts ist. Das neue Datenbank-Backend zeichnet sich insbesondere durch einen lockfreien Betrieb aus und lernt aus langjährigen Problemen von Berkeley DB (BDB ). Es erreicht beispiellose Leistungssteigerungen im Vergleich zu anderen Datenbanktechnologien, insbesondere im Hinblick auf das Nutzungsprofil von LDAP-Verzeichnisdiensten, die sich oft eher auf Lese- als auf Schreiboperationen konzentrieren.
Seit 2014 hat Univention auch in ihrem Kernprodukt Univention Corporate Server (UCS) auf LMDB als OpenLDAP-Backend umgestellt. Nach den Erfahrungen von Univention hat LMDB die Türen für OpenLDAP geöffnet, um die Anforderungen von Hochleistungsprojekten großer Größe zu erfüllen. Tatsächlich ist die Robustheit und Leistungsfähigkeit von LMDB so bemerkenswert, dass Univention 2014 beschloss, seinen eigenen BDB-basierten LDAP-Replikationscache durch eine LMDB-basierte Implementierung zu ersetzen. Auch wenn der aktuelle Versionszweig von 0.9 von LMDB bereits überzeugende Stabilität bewiesen hat, wird die 1.0-Serie liefern zusätzliche Verbesserungen, die als solides Backend für OpenLDAP entscheidend sein werden.
Der nächste große Meilenstein für das OpenLDAP-Projekt selbst wird die Veröffentlichung von OpenLDAP 2.5 sein. Einige der für OpenLDAP 2.5 angekündigten Features erblickten bereits als Patchlevel-Update für die 2.4er-Serie das Licht der Welt, die nach aktueller Roadmap bis 2.4.47 finalisiert sein wird.
Ein großes Dankeschön an OpenLDAP
Univention dankt dem OpenLDAP-Projekt und seinen Entwicklern für die professionelle Arbeit und das Engagement für den Open-Source-Gedanken. Als Linux-Distributor freut sich Univention darauf, OpenLDAP auch in den kommenden Jahren in UCS-basierten Projekten einzusetzen und öffentlichen und privaten Unternehmen und Institutionen eine offene, skalierbare und professionelle Softwarelösung zu bieten und gleichzeitig Entscheidungsfreiheit und Unabhängigkeit zu ermöglichen Vendor-Lock-Ins.
Dies ist ein Gastbeitrag von Univention . Die Ansichten des Autors sind vollständig seine eigenen und spiegeln möglicherweise nicht die Ansichten von OSTechNix wider.