OpenLDAP, DS389, and Apache
Relevant source files
The following files were used as context for generating this wiki page:
In the flext-ldif project, OpenLDAP, DS389, and Apache refer to specialized server implementations that extend the base RFC-compliant LDIF processing logic. These implementations provide server-specific detection, schema handling, and Access Control List (ACL) processing, ensuring that LDIF files exported from or targeted at these platforms maintain their proprietary extensions and unique syntaxes during migration or transformation workflows.
These server modules are integrated into the library's infrastructure layer, allowing the Application Layer to orchestrate complex operations such as server-to-server migration while preserving critical metadata. Each server type is identified by a canonical name and a set of aliases used by the Detector service to automatically identify the source platform of an LDIF input.
Sources: [src/README.md:27-38], [examples/04_server_migration.py], [src/flext_ldif/servers/openldap.py:20-40]
Architecture and Integration
The server implementations follow a nested class structure, inheriting from base RFC or generic server protocols. This architecture allows each server to override specific behaviors for Schema, Acl, and Entry processing.
Server Implementation Structure
The following diagram illustrates the relationship between the base RFC server and the specialized implementations for OpenLDAP, DS389, and Apache.
This class hierarchy ensures that standard RFC 2849 behavior is the default, while specific server logic is only applied when the server type is detected or explicitly requested.
Sources: [src/flext_ldif/servers/openldap.py:16-19], [tests/constants.py:30-40]
OpenLDAP 2.x Implementation
The OpenLDAP implementation focuses on the olc (Online Configuration) syntax and specific ACL patterns defined via olcAccess. It includes a heavy emphasis on detecting operational attributes like entryUUID and contextCSN.
Key Features and Constants
OpenLDAP-specific logic is driven by constants that define its detection weights and proprietary attributes.
| Constant | Value / Description |
|---|---|
SERVER_TYPE | openldap2 |
ACL_FORMAT | olcAccess |
DETECTION_WEIGHT | 8 |
DETECTION_PATTERN | `\b(olc[A-Z][a-zA-Z]+ |
Sources: [src/flext_ldif/servers/openldap.py:23-45]
OpenLDAP ACL Processing
The OpenLDAP ACL server parses the complex to <what> by <who> <access> strings. It supports index preservation (e.g., {0}to * by * read) which is common in OpenLDAP configurations.
# Internal OpenLDAP ACL parsing logic
def _parse_openldap_acl(self, acl_line: str) -> p.Result[m.Ldif.Acl]:
acl_content = self._strip_acl_prefix_and_index(acl_line)
what, attributes = self._parse_what_clause(acl_content)
# ... logic for parsing "by" clauses and permissions
Sources: [src/flext_ldif/servers/openldap.py:163-180]
DS389 and Apache Directory Servers
These implementations focus on identifying entries and schema elements associated with Red Hat Directory Server (DS389) and Apache Directory Server (ApacheDS).
DS389 Specifics
DS389 is identified through attributes like nsslapd-suffix and nsuniqueid, as well as object classes like nscontainer.
Sources: [tests/constants.py:340-355]
Apache Directory Specifics
ApacheDS is identified by the ads- prefix for attributes and object classes (e.g., ads-directoryService, ads-enabled).
Sources: [tests/constants.py:300-315]
Server Detection and Metadata Preservation
During processing, the ServerMetadata model tracks which server implementation was used and stores server-proprietary data that cannot be mapped directly to RFC standards.
The ServerMetadata class contains fields such as server_specific_data and original_server_type to ensure that even if an entry is migrated to a different target, its source origins are preserved for audit trails or reverse conversions.
Sources: [src/flext_ldif/_models/domain_metadata.py:127-160], [tests/constants.py:270-285]
Summary
The implementations for OpenLDAP, DS389, and Apache provide the necessary specialized logic to handle real-world LDAP environments that deviate from pure RFC standards. By overriding the Schema, Acl, and Entry handlers, the project ensures high fidelity in data transformation, particularly regarding proprietary configuration attributes and access control syntax. These modules are critical for enterprise migration scenarios where data loss in configuration or security settings is unacceptable.
Sources: [src/README.md:100-110], [examples/04_server_migration.py]