The formal release of the ReOpenLDAP LDAP server version 1.2.0 has been published, aimed at reviving the project after its repository on GitHub was blocked. In April, GitHub deleted the accounts and repositories of many Russian developers linked to companies that fell under U.S. sanctions, including the ReOpenLDAP repository. Due to the renewed interest of users in ReOpenLDAP, the project has been decided to be revived.
The ReOpenLDAP project was initiated in 2014 to address issues that arose from using the OpenLDAP package within the infrastructure of PJSC 'MegaFon', where the LDAP server was used in one of the subsystems (NGDR serves as a UDR (User Data Repository), according to the 3GPP 23.335 standard, and is a centralized node for storing data about all types of services for subscribers in the IT infrastructure of the telecom operator). This application implied industrial operation of a specific LDAP directory, sized between 10-100 million records, operating 24/7 in a high-load scenario (10K updates and 50K reads per second), in a multi-master topology.
Symas Corp, as the primary developers, committers, and owners of the OpenLDAP code, were unable to resolve the existing issues, so it was decided to attempt to tackle it independently. As it turned out, there were significantly more errors in the code than could have been presumed. Therefore, more effort was required than initially planned, and ReOpenLDAP still holds certain value and (according to available information) is the only LDAP server that fully and reliably supports multi-master topology for RFC-4533, including in high-load scenarios.
By 2016, the project goals were achieved, and support and development for the project directly in the interests of PJSC 'MegaFon' were completed. After that, ReOpenLDAP was actively developed and maintained for another three years, but gradually this became meaningless:
- Technologically, 'MegaFon' migrated from ReOpenLDAP to Tarantool, which is architecturally correct;
- There were no clearly interested users of ReOpenLDAP;
- No developers joined the project, both due to a high entry barrier and low demand for ReOpenLDAP itself;
- The development and maintenance have taken too much time from the remaining (main) developer, as he has professionally distanced himself from the industrial operation of ReOpenLDAP.
In an inactive state, the ReOpenLDAP repository lasted until April 2022, when GitHub administration deleted associated accounts and the repository itself without any warnings or explanations. Recently, the author received several inquiries about ReOpenLDAP, including the location of the repository and the state of the codebase. Therefore, it was decided to minimally refresh the project, create a technical release, and use this news to inform all interested parties.
Current project status, including regarding OpenLDAP:
- Imports of improvements and fixes from OpenLDAP have not been conducted since December 2018. For responsible applications, all corrections in OpenLDAP need to be analyzed and relevant ones imported.
- Current versions of OpenLDAP are now being formed based on the 2.5 branch. Thus, the improvements described below were made only in the 'devel' branch (which corresponded to OpenLDAP 2.5), and then merged into 'master' (which prior to merging corresponded to OpenLDAP 2.4).
- In 2018, inherited issues from OpenLDAP with the config-backend persisted. Specifically, when changing server configuration through config-backend (configuring LDAP via LDAP), race conditions or recursive issues including deadlocks occur.
- There are presumably build issues with current versions of OpenSSL/GnuTLS;
- A basic set of its own tests is conducted, excluding those requiring TLS/SSL;
Latest improvements:
- The libmdbx library has been updated to the latest version with all identified incompatibility issues arising from the library's development resolved. However, some outdated information may remain in the man pages.
- The current version of autotools 2.71 has been utilized.
- Minor adjustments have been made following some warnings from the current gcc 11.2 compiler.
Source: opennet.ru
