Extending Server Profiles
Relevant source files
The following files were used as context for generating this wiki page:
Extending Server Profiles is the mechanism within FLEXT-LDIF that allows the library to support diverse LDAP server implementations (such as OID, OUD, OpenLDAP, and Active Directory) while maintaining a consistent internal representation. This is achieved through a registry-based architecture where specific "Server Servers" provide logic for parsing, writing, and validating server-proprietary LDIF extensions, ACL formats, and schema nuances.
The system relies on a unified facade (FlextLdif) that orchestrates specialized services via Method Resolution Order (MRO). Developers can extend the library's capabilities by registering new server types that implement defined protocols for schema management, entry transformation, and metadata preservation.
Sources: src/flext_ldif/api.py:32-48, src/flext_ldif/constants.py:202-243
Architecture and Registry Flow
The core of server profile extension is the ServerRegistry, which manages the lifecycle and lookup of server-specific components. When an LDIF operation is initiated, the system resolves a "Server Bundle" containing specialized servers for Schema, ACLs, and Entries.
The diagram shows how the FlextLdif facade uses the registry to resolve a bundle of specialized servers, all of which typically inherit from RFC-compliant base implementations.
Sources: src/flext_ldif/api.py:112-125, src/flext_ldif/_protocols/base.py:100-135
Key Registry Methods
The FlextLdif facade provides several methods to interact with the server profile registry:
| Method | Description |
|---|---|
resolve_server_bundle(server_type) | Returns a mapping of Schema, ACL, and Entry servers for a specific type. |
list_registered_servers() | Provides a sequence of all currently supported server type identifiers. |
summarize_registry() | Returns metadata and statistics regarding registered profiles. |
resolve_server_constants(server_type) | Retrieves the ServerConstants protocol implementation for a specific profile. |
Sources: src/flext_ldif/api.py:145-175, src/flext_ldif/_protocols/base.py:120-135
Implementing a Schema Server
To extend a server profile's schema handling, developers inherit from FlextLdifServersBaseSchema (or FlextLdifServersRfcSchema). This allows for specialized parsing of attributeTypes and objectClasses that may contain proprietary extensions like X-ORIGIN.
Schema Parsing Pipeline
The parsing process involves identifying the server type and then delegating to the specific implementation's parse hooks.
This sequence illustrates the delegation from the parser to the specialized RFC schema server, which utilizes core utilities before applying server-specific hooks.
Sources: src/flext_ldif/servers/_rfc/schema.py:280-315
Critical Parsing Logic
Specific server profiles handle proprietary OID patterns and attribute name prefixes (e.g., ads- for ApacheDS or nsslapd- for 389ds) to determine handling eligibility.
Sources: src/flext_ldif/constants.py:202-243, src/flext_ldif/servers/_rfc/schema.py:240-255
Metadata Preservation and Extensions
A primary goal of extending profiles is ensuring "zero data loss" during round-trip conversions. This is handled by the ServerMetadata model, which stores original formatting details and conversion history.
Metadata Components
The ServerMetadata container (defined in FlextLdifModelsDomainMetadata) includes:
- FormatDetails: Preserves original DN line formatting, syntax, and spacing.
- SchemaFormatDetails: Captures original field order and
X-ORIGINvalues for schema definitions. - Conversion History: An audit trail of every transformation step applied to an entry.
- Minimal Differences: A tracking map that records character-level differences (e.g., spacing changes) between original and converted LDIF strings.
The class diagram shows the composition of ServerMetadata, highlighting its role in preserving original formatting and schema details.
Sources: src/flext_ldif/_models/domain_metadata.py:88-150
Server-Specific Detection and Scoring
The FlextLdifDetector service uses profile-specific constants to auto-detect the LDAP server type of an input file. This is based on a scoring system that looks for unique OIDs and attribute patterns.
| Server Type | Detection Markers | Weighting |
|---|---|---|
| OID | OID pattern 2.16.840.1.113894.*, orclaci attribute | High |
| AD | OID pattern 1.2.840.113556.*, samaccountname | High |
| OpenLDAP | olc* attribute prefix | Medium |
| 389DS | nsslapd-, nsds5, nsuniqueid prefixes | Medium |
Sources: src/flext_ldif/constants.py:145-243
Conclusion
Extending Server Profiles allows FLEXT-LDIF to scale across the complex landscape of LDAP implementations. By implementing the SchemaServer, AclServer, and EntryServer protocols and utilizing the ServerMetadata preservation system, developers can ensure that server-proprietary data is handled with RFC-level rigor and auditability.
Sources: src/flext_ldif/api.py:32-48, src/flext_ldif/_protocols/base.py:35-85