From bfa79aa76381b0353cd99c9c467bc6ca6ec935c8 Mon Sep 17 00:00:00 2001 From: Mario Fetka Date: Tue, 2 Jun 2026 06:33:10 +0000 Subject: [PATCH] docs: add directory storage redesign notes --- REDESIGN.md | 121 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) diff --git a/REDESIGN.md b/REDESIGN.md index 5a3442e..763ee3b 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -473,6 +473,127 @@ Use new processes only where shared state, isolation, and lifecycle justify the extra IPC complexity. ``` + +## Future NetWare 4.x directory, LDAP, and storage direction + +NetWare 4.x support should not be added by letting `nwbind` grow into a second +large catch-all service. The long-term directory design should keep the legacy +Bindery, the future NDS compatibility layer, and the LDAP protocol frontend as +separate logical layers above one shared directory store. + +The intended naming model is: + +```text +libflaim + persistent embedded database engine + +directory core/store + mars-nwe object model, schema, indexes, ACL/auth primitives + persists its data through libflaim + +nwdirectory + mars-nwe service name for the integrated tinyldap-derived LDAP service + owns LDAP/LDAPS/StartTLS protocol handling + uses wolfSSL only at the LDAP network/TLS edge + calls the directory core/store, not Bindery or NDS packet handlers + +nwnds + future NetWare 4.x/NDS compatibility layer + owns NDS/NCP directory semantics, contexts, tree-oriented operations, + NetWare-specific rights/auth behavior, and later compatibility glue + calls the directory core/store directly + +nwbind + legacy NetWare 2.x/3.x Bindery compatibility layer + maps Bindery objects, properties, sets, security, and login-visible behavior + onto the shared directory core/store where possible +``` + +In this model, `nwdirectory` is not a separate design from tinyldap. It is the +mars-nwe integration name for the tinyldap-derived LDAP directory service, so +that the installed binary/module follows the existing `nw*` naming scheme. The +upstream tinyldap code can provide the LDAP protocol implementation, but the +project-facing component should be named `nwdirectory`. + +`nwnds` should remain a separate layer because LDAP is only one protocol view of +the directory. NDS has NetWare-specific semantics that should not be forced into +the LDAP frontend. Conversely, LDAP clients should not be required to pass +through the NDS/NCP compatibility handler just to reach the directory database. +The preferred relationship is sibling frontends above one core: + +```text + +----------------------+ + | directory core/store | + | backed by libflaim | + +----------+-----------+ + ^ + +---------------+---------------+ + | | + nwdirectory nwnds + tinyldap-based LDAP/LDAPS NetWare 4.x/NDS semantics + frontend, wolfSSL TLS edge NCP/NDS compatibility layer + ^ ^ + | | + LDAP clients NetWare/NDS clients +``` + +The legacy Bindery service should also move toward this shared store over time: + +```text +NetWare 3.x client -> Bindery NCP -> nwbind -> directory core/store -> libflaim +LDAP client -> LDAP/LDAPS -> nwdirectory -> directory core/store -> libflaim +NetWare 4.x client -> NDS/NCP -> nwnds -> directory core/store -> libflaim +``` + +That means `nwbind` should become a compatibility mapping over directory objects +and attributes instead of maintaining a completely separate long-term identity +truth. This is especially important once NetWare 4.x/NDS support exists, because +Bindery compatibility can then be implemented as a legacy view of the same +underlying users, groups, properties, and rights data. + +The internal path should not be: + +```text +nwbind -> LDAP protocol -> nwdirectory -> directory store +nwnds -> LDAP protocol -> nwdirectory -> directory store +``` + +Using LDAP as the mandatory internal storage API would mix protocol concerns into +server internals, make old Bindery behavior harder to preserve, and add needless +encoding/search semantics between tightly coupled modules. LDAP should remain an +external protocol frontend. `nwbind`, `nwnds`, and `nwdirectory` should all use a +shared directory-core API or a clearly defined IPC protocol to the directory +store. + +FLAIM should therefore be treated as the long-term persistent storage engine for +the directory core, not as an LDAP-only database. The directory core owns the +schema, object model, indexes, transactions, ACL checks, and authentication +primitives that the protocol/provider layers need. `nwdirectory` exposes those +objects through LDAP; `nwnds` exposes them through NDS semantics; `nwbind` exposes +them through legacy Bindery calls. + +Kerberos should not be part of this initial design. Classic NetWare 4.x/NDS +compatibility should focus on native NDS-style authentication and directory +semantics. If a later eDirectory/NMAS compatibility effort ever needs Kerberos, +it should be considered a separate future authentication-provider topic, not a +requirement for the `nwdirectory`/`nwnds`/`nwbind` split. + +The migration path should be conservative: + +1. add the design boundary and naming notes first; +2. import or integrate tinyldap under the project-facing `nwdirectory` name; +3. keep wolfSSL confined to the LDAP/LDAPS/StartTLS network edge; +4. introduce a directory-core abstraction before making Bindery depend on it; +5. map selected `nwbind` objects/properties to the directory core only after the + legacy behavior is documented; +6. add `nwnds` later as an NDS semantic layer, not as an LDAP wrapper; +7. only then consider replacing private Bindery persistence with libflaim-backed + directory storage. + +This keeps the future NetWare 4.x work aligned with the provider/process split: +`nwdirectory`, `nwnds`, and `nwbind` may be separate processes or modules, but +they should not be separate sources of truth for identity and directory data. + ## Logging connection The dispatch redesign also supports the desired log cleanup. If every request