292 lines
15 KiB
Markdown
292 lines
15 KiB
Markdown
# nwAdmin and nwConsole roadmap
|
|
|
|
`mars-nweadmin` is useful as a historical workflow reference, but the old
|
|
Pascal program must not become the architecture for new administrator clients.
|
|
The current source is a Delphi/VCL Windows 3.x style program which depends on a
|
|
running NetWare client. Its bundled NwTP Pascal units call old DOS/Windows
|
|
NetWare client mechanisms such as VLM/NETX/DPMI helpers. That makes the code a
|
|
reference for screens and operations, not a portable Linux/macOS/Windows client
|
|
library.
|
|
|
|
The first new admin path is the NetWare 3.x path. Directory/NDS management is a
|
|
later extension, but the design should keep a ConsoleOne-like direction in mind:
|
|
one administrator application can grow from bindery/server administration into
|
|
directory administration when the directory stack is ready.
|
|
|
|
## Product names
|
|
|
|
Use distinct user-facing names for the two frontend families:
|
|
|
|
- `nwAdmin` is the remote administrator client family. It may start as a
|
|
console/CTest client and later gain a desktop GUI.
|
|
- `nwConsole` is the web administration surface. Its small web listener process
|
|
may still be named `nwwebui` internally, but the UI, page titles and user
|
|
documentation should call the browser interface `nwConsole`.
|
|
|
|
The names intentionally separate the remote client from the server-local web
|
|
console even when both share the same icon catalog, navigation vocabulary and
|
|
admin operation model.
|
|
|
|
## Client/server boundary
|
|
|
|
Administrator tools are remote clients. They must talk to a mars-nwe server
|
|
through NCP or later directory protocols instead of linking directly to server
|
|
implementation libraries.
|
|
|
|
The boundary is therefore:
|
|
|
|
```text
|
|
admin GUI or console command
|
|
-> portable admin client library
|
|
-> platform NCP transport adapter
|
|
-> mars-nwe server over NCP/IPX/TCP-backed client stack
|
|
```
|
|
|
|
They must not call local server libraries such as `libnwdirectory`,
|
|
`libnwflaim`, or server-private `libnwds` internals to modify a running server's
|
|
state. Those libraries belong on the server/setup side. The administrator
|
|
client library may expose similar high-level operations, but it should perform
|
|
those operations by sending NCP requests to the selected server.
|
|
|
|
## Platform transport plan
|
|
|
|
The transport layer should be behind an adapter interface so the GUI and common
|
|
admin logic do not know which platform backend is used.
|
|
|
|
Initial direction:
|
|
|
|
- Linux: prefer the existing ncpfs client library where it can provide the 3.x
|
|
NCP operations needed by the admin client.
|
|
- Windows: expect the Novell Client to be the practical first backend. A
|
|
Windows administrator workstation normally needs that client stack anyway for
|
|
authentic NetWare access, so `nwAdmin` should wrap a Windows Novell Client
|
|
backend through the same transport adapter instead of reviving the old Pascal
|
|
VLM/NWTP layer. A project-owned NCP backend can remain a later fallback only
|
|
if the native client path is unavailable or too limited.
|
|
- Classic/PPC macOS: treat the historical Novell NetWare Client for Macintosh as
|
|
a compatibility reference for old systems where it is available, not as a
|
|
modern portable dependency.
|
|
- Modern macOS: plan for either an ncpfs client-library port or a small
|
|
project-owned NCP transport behind the adapter, because the old Macintosh
|
|
client does not solve current macOS targets.
|
|
|
|
The GUI must call only the portable admin client API. Platform-specific NCP
|
|
attachment, login, request framing, timeouts, reconnect behaviour, and native
|
|
client integration belong below that API.
|
|
|
|
## GUI direction
|
|
|
|
A cross-platform GUI is allowed, but it must remain a frontend over the portable
|
|
admin client library.
|
|
|
|
Possible frontends:
|
|
|
|
- Lazarus LCL / FreePascal, if the Pascal route is still wanted.
|
|
- Another cross-platform GUI toolkit, if it gives a cleaner long-term result.
|
|
- A console/CLI frontend for tests and recovery should exist regardless of the
|
|
GUI toolkit.
|
|
|
|
If Lazarus LCL is used, treat the old Delphi forms as a workflow/screen reference
|
|
only. Do not try to preserve the old VCL/NwTP implementation as the new runtime
|
|
transport layer.
|
|
|
|
|
|
## GUI and web frontend dependency policy
|
|
|
|
Keep the first client simple. The portable admin client API and the console/CLI
|
|
frontend are more important than a rich desktop framework. A graphical frontend
|
|
can be Lazarus LCL/FreePascal or another cross-platform toolkit, but the selected
|
|
toolkit must not pull a large runtime stack into the server or common libraries.
|
|
|
|
Evaluate heavier Pascal GUI/web stacks only after the 3.x NCP admin API is
|
|
proven. Custom-drawn Lazarus/Delphi libraries such as Cross.Codebot can be
|
|
looked at for a later modern desktop UI, and browser-oriented Pascal stacks such
|
|
as TMS WEB Core or uniGUI can be compared for a later web UI, but none of them is
|
|
a first-pass dependency. The first-pass rule is: common admin logic stays in the
|
|
portable client library, and every frontend remains replaceable.
|
|
|
|
## Server-local web administration / nwConsole
|
|
|
|
A server-local web admin path is allowed and may eventually replace the old
|
|
SMArT role. Treat it as a separate frontend, not as the architecture for the
|
|
common admin client library.
|
|
|
|
Preferred shape:
|
|
|
|
```text
|
|
service manager / nwserv supervisor role
|
|
-> starts/supervises nwserv service family
|
|
-> nwserv / ncpserv / nwconn / nwdirectory / nwftp / ...
|
|
-> starts/supervises nwwebui independently when configured
|
|
-> owns HTTP/HTTPS, TLS offload, sessions and static assets only
|
|
-> forwards authenticated web-admin requests to nwadmin
|
|
-> owns web/config plugin dispatch and admin operation routing
|
|
-> calls the portable admin API
|
|
-> localhost/server NCP transport or explicit server-control IPC
|
|
-> mars-nwe service being managed
|
|
```
|
|
|
|
In this shape `nwwebui` is deliberately small. It is the stable web listener
|
|
and SSL offloader that can remain alive while server services restart.
|
|
`nwadmin` is the management process behind it. Web modules, configuration
|
|
modules and later service-specific extensions belong to `nwadmin`, not to the
|
|
TLS/HTTP frontend. The connection between both processes should be an explicit
|
|
local IPC socket/protocol, not the old SMArT-style subprocess stdout/console
|
|
scraping model.
|
|
|
|
`nwwebui` may reuse the existing SMArT-derived web service direction as a
|
|
feature reference, but new implementation work should replace local ad-hoc socket,
|
|
HTTP and TLS helpers with the project's normal bundled dependencies. Socket and
|
|
buffer/event-loop code should prefer `libowfat` helpers where they fit the
|
|
project style. TLS/HTTPS must go through the project TLS facade backed by
|
|
MatrixSSL/`libnwssl`, not through another SSL library or a private web-server TLS
|
|
stack.
|
|
|
|
Login must not remain primarily PAM-based. For the 3.x path, the first
|
|
authentication choice is the mars-nwe server's bindery login state over localhost
|
|
NCP or an explicit server-control authentication path. PAM is only a fallback
|
|
for emergency/local host policy when bindery authentication is not available or
|
|
is explicitly disabled. For the later 4.x/directory path, user authentication
|
|
should switch to the directory service path through `libnwds` or the equivalent
|
|
server-side directory authentication API, with PAM still only a fallback.
|
|
|
|
Management operations should move behind the same portable admin API used by
|
|
console and GUI frontends. `nwwebui` should forward to the `nwadmin` process,
|
|
and `nwadmin` should perform the plugin dispatch and admin API calls. Neither
|
|
process may call local storage libraries such as `libnwdirectory`, `libnwflaim`,
|
|
or private storage internals directly to manage a running server.
|
|
|
|
For the first server-local web UI, prefer simple generated HTML, small static
|
|
assets and normal forms. Avoid making a large single-page-application framework
|
|
or a Pascal-to-JavaScript compiler a required dependency for a server admin tool.
|
|
A richer browser UI can be added later if the small web UI and admin API prove
|
|
insufficient.
|
|
|
|
`nwwebui` and `nwserv` have separate lifecycle rules depending on who requested
|
|
the restart. A host-level restart of the MARS-NWE service through systemd, an
|
|
init script or a package/service manager may restart the whole service family,
|
|
including `nwwebui`, because that is an explicit server-side service restart.
|
|
A restart requested from the web UI must not restart the web listener itself as a
|
|
side effect. In that case `nwwebui` should keep its HTTP/HTTPS listener alive,
|
|
report the selected backend as restarting or temporarily unavailable, and
|
|
reconnect or refresh its backend IPC/server session after the backend comes back.
|
|
Restarting `nwwebui` should be an explicit service-manager action, not an
|
|
implicit side effect of restarting `nwserv`, `nwadmin`, `nwconn`, `nwbind`,
|
|
`ncpserv`, `nwdirectory`, `nwftp` or another managed backend from nwConsole.
|
|
|
|
Because `nwwebui` remains up during web-requested backend restarts, nwConsole
|
|
needs embedded static/status pages that do not depend on a live `nwadmin`
|
|
backend. Those pages should use the same nwConsole visual language and be able
|
|
to show messages such as `Restarting nwadmin`, `Restarting ncpserv`,
|
|
`Restarting nwconn`, `Restarting nwbind`, `Restarting nwdirectory`, `Service
|
|
unavailable`, and `Reconnect pending`.
|
|
|
|
## Shared visual language and plugins
|
|
|
|
The nwConsole web UI and the nwAdmin desktop/client frontends should share the same visual vocabulary.
|
|
Use an open-source icon set or project-owned icons, but keep a common icon ID
|
|
catalog so the desktop UI and web UI show the same symbols for users, groups,
|
|
volumes, trustees, server status, restart actions and later directory objects.
|
|
Do not copy proprietary Novell artwork; use an iManager/ConsoleOne-inspired
|
|
layout and project-owned assets.
|
|
|
|
`nwadmin`, not `nwwebui`, owns the plugin system. A first plugin interface can
|
|
be simple and static: each plugin declares an ID, title, icon ID, navigation
|
|
section, required server capability, and command handlers for read-only views or
|
|
configuration changes. Later plugins can cover optional services such as NFS,
|
|
FTP, WebDAV, directory/schema tools, certificate management or other server
|
|
modules. The same plugin metadata should drive both the web navigation tree and
|
|
a future desktop/client navigation tree.
|
|
|
|
The split keeps dependencies small:
|
|
|
|
```text
|
|
nwwebui
|
|
-> HTTP/HTTPS/TLS/session/static frontend
|
|
-> local IPC socket client/server boundary to nwadmin
|
|
|
|
nwadmin
|
|
-> plugin registry
|
|
-> web/config module dispatch
|
|
-> portable admin API / server-control client
|
|
```
|
|
|
|
When `nwserv` gains service-management awareness, it may support targeted
|
|
restarts such as restarting only `nwadmin`, only `nwconn`, only `ncpserv`, only
|
|
`nwbind`, only the directory server, only `nwftp`, or another optional service.
|
|
For a host-level systemd/init restart of the MARS-NWE service, restarting the
|
|
whole service family including `nwwebui` is allowed. For a restart requested
|
|
through nwConsole, the frontend must keep running unless the operator explicitly
|
|
chooses to restart the web frontend itself. If `nwadmin` or another backend is
|
|
restarted, `nwwebui` should keep the listener and sessions alive, reconnect to
|
|
the IPC socket when the backend comes back, and show an embedded nwConsole
|
|
`restarting` or `backend unavailable` page meanwhile.
|
|
|
|
## Work order
|
|
|
|
1. Audit `mars-nweadmin` workflows for the 3.x feature set: users, passwords,
|
|
bindery object operations, server information, connections, messages and
|
|
other admin calls that the old tool exposes.
|
|
2. Define a portable admin client API over NCP for the 3.x path.
|
|
3. Implement a Linux backend using ncpfs where practical, with the backend hidden
|
|
behind the transport adapter.
|
|
4. Add a Windows transport adapter that wraps the installed Novell Client where
|
|
practical, because that is the expected first Windows backend.
|
|
5. Audit the old Macintosh NetWare client as a Classic/PPC reference only, then
|
|
decide whether modern macOS needs an ncpfs port or a project-owned NCP
|
|
transport.
|
|
6. Add a console/CLI test frontend so CTest can exercise the client API without a
|
|
GUI.
|
|
7. Add a simple server-local nwConsole (`nwwebui`) plus `nwadmin` pair only after the API is
|
|
stable enough: `nwwebui` handles HTTP/HTTPS/TLS/session/static frontend work,
|
|
while `nwadmin` owns plugin dispatch and management operations.
|
|
8. Add a desktop GUI frontend only after the admin client API and transport
|
|
behaviour are stable and the toolkit choice does not force large dependencies
|
|
into the common/server side.
|
|
9. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and
|
|
the FLAIM-backed directory stack are ready, extend the admin client toward
|
|
directory administration in a ConsoleOne-like direction.
|
|
|
|
## Non-goals for the first pass
|
|
|
|
- Do not port the old Delphi program line-for-line to FreePascal as the first
|
|
step.
|
|
- Do not make the admin GUI link to local server libraries to manage a remote
|
|
server.
|
|
- Do not combine the 3.x admin-client transport work with the later Directory/NDS
|
|
management work.
|
|
- Do not make modern macOS depend on the old Classic/PPC Novell Client. Use it
|
|
only as a compatibility/reference path; modern macOS needs either an ncpfs port
|
|
or a project-owned NCP transport adapter.
|
|
- Do not revive the old Pascal VLM/NWTP runtime layer for Windows. Prefer the
|
|
installed Novell Client backend first, hidden behind the portable transport
|
|
adapter.
|
|
- Do not make Cross.Codebot, TMS WEB Core, uniGUI, or any other large GUI/web
|
|
framework a required first-pass dependency.
|
|
- Do not merge HTTP/HTTPS/session handling into `nwserv`; keep `nwwebui` or an
|
|
equivalent frontend process responsible for the web surface.
|
|
- Do not add new local socket, HTTP or TLS helper stacks to `nwwebui` when the
|
|
project-owned path can use bundled `libowfat` helpers and MatrixSSL/`libnwssl`.
|
|
The first code step may move the existing SMArT-derived listener to libowfat
|
|
socket helpers and `nwlog` while leaving the old Perl subprocess bridge in
|
|
place; the explicit `nwwebui` <-> `nwadmin` IPC socket comes later.
|
|
- Do not keep PAM as the primary `nwwebui` login path. Bindery/server
|
|
authentication is primary for 3.x; later directory authentication through
|
|
`libnwds` or the matching server-side directory API is primary for 4.x.
|
|
`nwwebui` may keep a minimal PAM-only recovery login for the break-glass case
|
|
where `nwadmin` is down and the web frontend must ask `nwserv` to start or
|
|
restart it, but that recovery path must not grow into normal administration.
|
|
- Do not make web-requested backend restarts restart `nwwebui` as a side
|
|
effect. A host-level systemd/init restart of the MARS-NWE service may restart
|
|
the whole service family, including `nwwebui`; nwConsole-requested backend
|
|
restarts must keep the web listener alive unless the operator explicitly
|
|
restarts the web frontend itself. `nwserv` or a service manager may restart
|
|
backend services such as `nwadmin`, `nwconn`, `ncpserv`, `nwbind`, directory,
|
|
FTP or other optional daemons individually.
|
|
- Do not put the web/config plugin system into `nwwebui`. Keep `nwwebui` as
|
|
the HTTP/HTTPS/TLS/session/static frontend and put plugin dispatch into the
|
|
`nwadmin` backend process.
|
|
- Replace the old SMArT-style subprocess/console-output coupling with an
|
|
explicit local IPC socket between `nwwebui` and `nwadmin`, with reconnect and
|
|
backend-unavailable handling in the frontend.
|