From 666d3a6a8a7a1d4f27dbc569cb64ea533ea6a620 Mon Sep 17 00:00:00 2001 From: Mario Fetka Date: Sat, 13 Jun 2026 10:21:23 +0000 Subject: [PATCH] 0469 docs: record LDAPv2-first directory and console nwsetup order --- AI.md | 40 +++++++++++++++++++++---------------- REDESIGN.md | 13 ++++++++---- TODO.md | 20 ++++++++++++------- doc/DIRECTORY_STACK_PLAN.md | 39 ++++++++++++++++++++++++++---------- 4 files changed, 74 insertions(+), 38 deletions(-) diff --git a/AI.md b/AI.md index 1b4ff40..281ef2b 100644 --- a/AI.md +++ b/AI.md @@ -47,7 +47,7 @@ unfinished work out of `TODO.md` merely because its architecture is documented. Latest patch marker expected in an up-to-date bundle: -- `0468 docs: record nwdirectory flatfile-first and storage-swap plan` +- `0469 docs: record LDAPv2-first directory and console nwsetup order` When a later chat receives a new `mars-nwe-master` bundle, compare `git log -1` with this marker. If the uploaded bundle already contains this commit subject, @@ -67,20 +67,23 @@ The active line is expected to include: Last generated patch: -- `0468 docs: record nwdirectory flatfile-first and storage-swap plan` +- `0469 docs: record LDAPv2-first directory and console nwsetup order` Purpose of that patch: -- Record the directory-service layering before touching TinyLDAP code: first - make the tinyldap-derived `nwdirectory` server pass LDAPv2/LDAPv3 and schema - import tests on its existing flatfile/mmap/journal storage. -- Keep the later FLAIM conversion as a separate storage-engine swap: add - FLAIM-backed source files next to the current `mstorage_*`/`mduptab_*` files - and select one backend from CMake, while preserving the same exported storage - function names so the LDAP/server code does not change in the same patch. -- Clarify that future `libnwds` sits above `libnwdirectory`, while - `libnwdirectory` later uses `libnwflaim`; the `nwdirectory` name itself is the - server/binary. +- Refine the directory roadmap before touching TinyLDAP code: LDAPv2 support is + the first code block, with OpenLDAP 1.0.3 used only as the historical LDAPv2 + behaviour/reference tree. +- Keep the current `libnwdirectory` flatfile/mmap/journal backend active while + adding LDAPv2/LDAPv3 TCP CTests and NetWare/NDS schema handling. Schema work + may be native `.sch` import or a reviewed `.sch` to LDIF conversion path. +- Add `libnwds` and the first `nwsetup` implementation together, but keep that + first setup path console/CLI-only so CTest can exercise initial provisioning + before the future `nwtui` frontend exists. +- Keep the FLAIM backend and interactive TUI setup as later, separate changes: + only after LDAPv2, schema handling, `libnwds`, and console `nwsetup` work on + flatfile storage should `libnwdirectory` gain the CMake-selected + `flaimstorage_*` backend below the existing storage function names. Directory/NDS work order before any FLAIM storage conversion: @@ -92,11 +95,14 @@ Directory/NDS work order before any FLAIM storage conversion: start `nwdirectory` on `127.0.0.1:` with a temporary flatfile workdir and test LDAPv2/LDAPv3 bind/search/unbind against test LDIF/schema data. -- Later, when the flatfile LDAP path is stable, add FLAIM storage as parallel - backend source files selected by CMake. For example, `flaimstorage_add_bin.c` - may provide the same exported `mstorage_add_bin()` function as the flatfile - file when the FLAIM backend is selected. Do not break upstreamable flatfile - TinyLDAP code while adding the mars-nwe FLAIM backend. +- Add `libnwds` and console-only `nwsetup` together after LDAPv2/schema flatfile + behavior is testable. Do not make the first setup path depend on the TUI or + on acting as an LDAP client. +- Later, when the flatfile LDAP/setup path is stable, add FLAIM storage as + parallel backend source files selected by CMake. For example, + `flaimstorage_add_bin.c` may provide the same exported `mstorage_add_bin()` + function as the flatfile file when the FLAIM backend is selected. Do not break + upstreamable flatfile TinyLDAP code while adding the mars-nwe FLAIM backend. Rejected or superseded patches that must not be reused as-is: diff --git a/REDESIGN.md b/REDESIGN.md index 043f5be..acb0013 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -1470,9 +1470,12 @@ not make LDAP the canonical internal representation. Do not combine the LDAP compatibility work and the FLAIM storage conversion in one patch series. The tinyldap-derived `nwdirectory` server should first be made testable and compatible while it still uses its current flatfile/mmap/journal -storage. LDAPv2 support, LDAPv3 behaviour that already works, schema import -under `opt/schema`, and `nwsetup`-driven provisioning should all be proven on the -flatfile backend before the storage engine changes. +storage. LDAPv2 support comes first, using OpenLDAP 1.0.3 as the historical +LDAPv2 server reference. LDAPv3 behaviour that already works, NetWare/NDS schema +import or `.sch` to LDIF conversion, and the first `libnwds` plus console-only +`nwsetup` provisioning path should all be proven on the flatfile backend before +the storage engine changes. The interactive `nwtui` setup frontend comes later, +after the flatfile path and the FLAIM storage backend are both stable. This keeps changes upstreamable to the tinyldap-derived code line: LDAPv2 work is generally useful, while the FLAIM storage backend is mars-nwe-specific. The @@ -1529,7 +1532,9 @@ before FLAIM is introduced. Prefer existing tinyldap test clients and helpers where they are suitable. A test should allocate a temporary workdir, start `nwdirectory` on `127.0.0.1:`, load or prepare test LDIF/schema data, run LDAPv2 or LDAPv3 bind/search/unbind checks, stop the server, and remove the -workdir. +workdir. The first `nwsetup` tests should be console/CLI tests that call the +new `libnwds` API directly; they should not require a terminal UI and should not +act as LDAP clients to bootstrap local directory state. ### NetWare 4.11 LDAP compatibility baseline diff --git a/TODO.md b/TODO.md index 4298f9a..73cbfcb 100644 --- a/TODO.md +++ b/TODO.md @@ -27,7 +27,7 @@ why it matters, and where the work belongs. | External file reconciliation | P1 | Planned next | Add libnwfs watcher/scanner support so Samba, rsync and host-created files receive `netware.metadata` and namespace records. | | Terminal UI/toolbox and curses replacement | P2 | Planned / pre-implementation | Use `doc/TUI_TOOLBOX_PLAN.md`; replace direct `curses.h` use with `nwtui`, add `nwi18n`, and keep future setup/filer/salvage tools as multi-call `nwtoolbox` applets. | | Shared libnwcore INI reader/writer | P1 | Planned / pre-implementation | Use `doc/NWCORE_INI_PLAN.md`; provide one robust parser/writer for server config, `nwsetup`, `nwtoolbox` and optional `nwi18n` catalogs instead of hiding config parsing inside the TUI layer. | -| nwdirectory LDAP flatfile compatibility | P2 | Planned / flatfile first | Add LDAPv2/LDAPv3 CTests against the current tinyldap flatfile backend before any FLAIM storage swap. | +| nwdirectory LDAPv2 flatfile compatibility | P2 | Planned / flatfile first | Add LDAPv2 support and LDAPv2/LDAPv3 CTests against the current tinyldap flatfile backend before any FLAIM storage swap. | ## nwdirectory LDAP and storage-backend staging @@ -35,20 +35,26 @@ Do not make the tinyldap-derived `nwdirectory` work solve LDAP compatibility and FLAIM storage at the same time. Keep the sequence explicit: 1. keep the existing flatfile/mmap/journal backend active; -2. add LDAPv2 and LDAPv3 CTests over TCP using isolated workdirs and free local +2. add LDAPv2 support first, using OpenLDAP 1.0.3 only as the historical LDAPv2 + server reference for behaviour and wire layout; +3. add LDAPv2 and LDAPv3 CTests over TCP using isolated workdirs and free local ports; -3. use existing tinyldap test/client helpers where they are suitable, rather than +4. use existing tinyldap test/client helpers where they are suitable, rather than adding a mandatory OpenLDAP client dependency; -4. make `opt/schema` import and flatfile-backed provisioning work before storage - changes; -5. only after that, add a FLAIM backend as a CMake-selected replacement source +5. make NetWare/NDS schema handling work on flatfile storage, either through + native `.sch` import or a reviewed `.sch` to LDIF conversion path; +6. add `libnwds` together with a console/CLI-only `nwsetup` path that CTest can + exercise without the future TUI frontend; +7. only after that, add a FLAIM backend as a CMake-selected replacement source set that exports the same storage function names as the flatfile files. The later FLAIM backend should live beside the current storage files, not replace them in-place. For example, a future `flaimstorage_add_bin.c` can implement `mstorage_add_bin()` when the FLAIM backend is selected. The flatfile backend must remain buildable and testable so generally useful LDAPv2 work can stay -upstreamable to the tinyldap-derived component. +upstreamable to the tinyldap-derived component. Interactive `nwtui` setup comes +after the flatfile and FLAIM paths are proven; the first `nwsetup` path is a +console/CLI test target. ## NCP provider handoff cleanup diff --git a/doc/DIRECTORY_STACK_PLAN.md b/doc/DIRECTORY_STACK_PLAN.md index 2c2c4e5..19d351a 100644 --- a/doc/DIRECTORY_STACK_PLAN.md +++ b/doc/DIRECTORY_STACK_PLAN.md @@ -55,19 +55,37 @@ and any NetWare-facing directory policy code. ## Implementation order -Do not combine the LDAP work and the storage-engine swap. +Do not combine LDAP protocol compatibility, NetWare schema import, setup tooling +and the storage-engine swap. The first directory implementation phase is +flatfile-only. 1. Keep `libnwdirectory` on the current flatfile/mmap/journal backend. -2. Add LDAPv2 CTests over TCP against `nwdirectory` with isolated temporary +2. Add LDAPv2 support to the TinyLDAP-derived server first. TinyLDAP is + currently treated as the LDAPv3-era baseline; the uploaded OpenLDAP 1.0.3 + tree is the historical LDAPv2 server reference for bind/search/result/BER + behaviour, not a source tree to import wholesale. +3. Add LDAPv2 CTests over TCP against `nwdirectory` with isolated temporary workdirs and free loopback ports. -3. Add LDAPv3 CTests for behaviour that is already present or intentionally - supported. -4. Make schema import under `opt/schema` work on the flatfile backend. -5. Add `nwsetup`/tooling flows against the flatfile-backed directory state. -6. Only after those tests are stable, add a FLAIM storage backend. +4. Keep/add LDAPv3 CTests for behaviour that is already present or intentionally + supported, but do not make LDAPv3 the NetWare 4.11 compatibility baseline. +5. Make NetWare/NDS schema handling work on the flatfile backend. Prefer native + `.sch` import if practical; otherwise add a reviewed `.sch` to LDIF + conversion path. +6. Add `libnwds` and the first `nwsetup` path together. The first `nwsetup` + implementation should be console/CLI-only so CTest can exercise initial + setup without the future `nwtui` frontend. It should call `libnwds`, and + `libnwds` should call `libnwdirectory`; it should not bootstrap by acting as + an LDAP client to `nwdirectory`. +7. Only after LDAPv2, LDAPv3 smoke coverage, schema import, `libnwds` and the + console `nwsetup` path are stable on flatfile storage, add a FLAIM storage + backend. +8. After the FLAIM backend is working, add the interactive `nwtui`/`nwtoolbox` + setup frontend and the certificate/TLS directory-storage work as separate + follow-up changes. -This keeps LDAPv2 improvements generally useful to the TinyLDAP-derived code and -keeps the later FLAIM backend as a clearly mars-nwe-specific storage change. +This keeps LDAPv2 improvements generally useful to the TinyLDAP-derived code, +keeps `nwsetup` testable before the UI exists, and keeps the later FLAIM backend +as a clearly mars-nwe-specific storage change. ## Future storage-backend swap @@ -128,7 +146,8 @@ Suggested future test names: ```text nwdirectory.ldap.v2.bind-search-flatfile nwdirectory.ldap.v3.bind-search-flatfile -nwdirectory.schema.import-flatfile +nwdirectory.schema.sch-import-flatfile +nwds.setup.console-flatfile nwdirectory.storage.flatfile.smoke nwdirectory.storage.flaim.smoke # later, after the backend swap ```