Steward 0.16.0 for OpenVMS x86-64 and IA64 (early test): licences, products, monitoring and the error log

Steward manages OpenVMS from a web browser. This is 0.16.0, an early test release, the first with kits for both x86-64 and IA64 (Integrity). It is for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New since 0.9

IA64

• Kits for OpenVMS IA64 V8.4-2L3, built from the same sources as x86-64. Fewer checks have been run on IA64 so far; see Tested and docs/IA64.md.

Licences

• What is loaded, as SHOW LICENSE/FULL, and the unit charge, as SHOW LICENSE/UNIT_REQUIREMENTS: anyone may see these.
• The licence database, as LICENSE LIST/FULL: each PAK's authorization number, status and who last changed it, where OpenVMS lets you read LMF$LICENSE (SYSPRV, READALL or BYPASS switched on, or a system UIC). Read-only.

Installed products

• PCSI's products and history, as PRODUCT SHOW PRODUCT/FULL and PRODUCT SHOW HISTORY/FULL, for accounts authorized for SYSLCK; and VMSINSTAL's history, which anyone may read.
• Install and remove products through PCSI. You type a kit directory on the node; Steward lists its kits (PRODUCT FIND). An install or removal runs as a batch job under your own username, with the privileges switched on in your session, and the page follows the job's log to its end. PCSI needs CMKRNL, and a kit's own procedures may need more. Steward refuses to remove itself or the operating system.

Monitoring

• CPU by mode, process states, memory, paging, I/O and disks, as MONITOR shows them, live in the browser, with the busiest processes of those OpenVMS lets you see.
• History on the node: a small recorder process, started and stopped with the pool, runs with every privilege but TMPMBX and NETMBX switched off. It takes a reading every 60 s and keeps 7 days in a file of fixed size (about 15 MB), so the page shows the last 6 h, 24 h and 7 days as well as live. The interval and the days kept are settings, and 0 turns the recorder off.

Error log

• Each device's error count; the events in ERRLOG.SYS, one line each and each in full, as ANALYZE/ERROR_LOG/ELV translates them; CLUE's crash summaries; and OPCOM's log. Each is shown where OpenVMS lets you read it (SYSPRV for most).
• Start a new error log by renaming ERRLOG.SYS to a dated name (ERRFMT creates a new one; the old one stays readable), and delete crash listings you choose or those older than a date. Confirmed in the page and audited.

The pool

• The pool purges its own logs: each start keeps the newest 10 versions of each process's log (STEWARD_LOG_KEEP, 1 to 100). Before this nothing removed them.

Security fixes

Found by probes on the node and by independent reviews of each phase. The record is in docs/security.md.

• A helper process could be left running. Your own login procedure could write the end marker or a message into the helper's termination mailbox and stay running, leaving one detached process of yours per request. Now only OpenVMS's own termination message for the helper's PID counts, and otherwise the helper is deleted on every path.
• Event flags were not given back when taking one of three failed.
• The licence view blamed privilege for every refusal of the database. It now says so only for RMS-F-PRV.

What it does

• Users: create, copy and delete (as AUTHORIZE ADD, COPY and REMOVE); list and filter; read and modify everything AUTHORIZE SHOW shows; set passwords.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke.
• Access history: who reached the system, when, from where and by which route.
• Logical names: the tables and names as SHOW LOGICAL shows them to you; define, modify and deassign.
• Processes (list, show, stop), queues (list, show; hold, release and delete jobs; stop and start queues) and system parameters (read-only).
• Licences, installed products, monitoring and the error log, as above.
• A dashboard of the system, and your session: switch your authorized privileges on and off, change your own password.
• An audit log of every sign-in, privilege switch and change. Passwords and logical-name values are never recorded.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

[STEWARD.DOC]README.VMS explains each step: the service account and why it holds what it holds, the gateway secret shared with lighttpd, starting at boot, running STEWARD$CONFIGURE again, a reverse proxy in front, and the audit log. Keep Steward's service account in a UIC group of its own. (The README.VMS in these kits still says "x86-64 only for now", which is out of date; the repository's copy is current.)

Requires: OpenVMS x86-64 V9.2-x or OpenVMS IA64 V8.4-2L3, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd for the same platform, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Upgrading from 0.9.x: PRODUCT INSTALL the new kit over the old one, then @STEWARD$ROOT:[COM]STEWARD$CONTROL RESTART. The settings, sessions and audit log are kept. The recorder starts with the pool, using the defaults. To change them, run STEWARD$CONFIGURE again or edit STEWARD_SETTINGS.COM.

Tested

On OpenVMS x86-64 E9.2-4:

• 528 unit checks run natively on OpenVMS.
• Each new area was checked against the system's own commands, from a privileged work account and under test accounts:
  • licences (phase11_live.py): the same licences as SHOW LICENSE and LICENSE LIST, and the database refused without privilege;
  • installed products (phase12_live.py, 8 checks; phase12b_live.py, 12): a demo kit found, installed and removed through Steward; its own product and the operating system refused;
  • monitoring (phase13_live.py; phase13b_live.py): against MONITOR and the recorder's file;
  • error log (phase14_live.py, 19; phase14b_live.py, 16): against ELV run by hand; the changes on copies.
• Every earlier phase's live tests were run again. The pages were checked in a browser, and each test kit was installed over the one before.

On OpenVMS IA64 V8.4-2L3 (an HP rx2660):

• The same 528 unit checks.
• The live tests of every phase through Steward's dispatcher on the node. For installing and removing products, only finding kits and the refusals were tested; no product was installed.
• The kit is installed and in service there, and pages and API responses through lighttpd match x86's. One problem (large responses cut short between lighttpd and the browser) was reported cleared but has not been re-tested (docs/IA64.md).

On Linux, every push runs:

• the unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the FastCGI, JSON, logical-name, SYSGEN, licence and product parsers (the error-log parsers are unit-tested on lines captured from the node, not yet fuzzed);
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks;
• tests of the pages in a headless DOM (make ui-test).

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0016-0-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)
ISSINOHO-I64VMS-STEWARD-T0016-0-1.PCSI	OpenVMS IA64 (built and tested on V8.4-2L3)

T0.16-0 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of each kit:

b405a2d29c6d42ff89062afd0f802a870045385ac041c4d5c369344d41d0e993  ISSINOHO-I64VMS-STEWARD-T0016-0-1.PCSI
7d5b09427ba06c5432f8fa6a38264086da402577c3ed23af46154ad5d52ee25a  ISSINOHO-X86VMS-STEWARD-T0016-0-1.PCSI

Steward 0.9.0 for OpenVMS x86-64 (early test): processes, queues and system parameters

Steward manages OpenVMS from a web browser. This is 0.9.0, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New since 0.6

Processes

• The list, as SHOW SYSTEM shows it to you: your own processes; your group's with GROUP switched on; everyone's with WORLD. Filter by process name or username.
• One process, as SHOW PROCESS/ALL: state, priorities, image, CPU and I/O, owner and master, working set, privileges, rights, and every quota with what is left.
• Stop a process, as STOP/ID, with OpenVMS deciding who may. You type the process name to confirm. Steward refuses, whatever privileges you hold, to stop its own pool or any system process (UIC group up to MAXSYSGROUP: OPCOM, JOB_CONTROL, the ACPs).

Batch and print queues

• Every queue, as SHOW QUEUE; a queue's jobs, as SHOW QUEUE/ALL/FULL; one job, as SHOW ENTRY/FULL, with its files. A job you may not read is listed by entry and status only, "inaccessible", as at a terminal.
• Hold, release and delete a job; stop and start a queue, with the queue manager deciding who may. Steward never stops SYS$BATCH or the queues it feeds: its pool is started there at boot. If it cannot tell which queues those are, it refuses every stop rather than guess.

System parameters

• Every active parameter, as SYSGEN SHOW/ALL prints it: current, default, minimum, maximum, unit, and whether it is dynamic, with values off their default marked. Read-only. OpenVMS has no service for this, so SYSGEN runs in a short-lived process that is you, as listing logical names does.

Security fixes

Found by probes on the node and by independent reviews of each phase. The record is in docs/security.md.

• A busy pool worker could be stopped. While a pool process serves a request it holds that user's identity, and OpenVMS reports it under their name, so a guard by username missed it. Steward now also refuses any process running its own program.
• The start-up-queue guard failed open if the queue manager did not answer; it now fails closed.
• A process ID of FFFFFFFF, OpenVMS's wildcard, was accepted; it is now refused.
• A logical-name listing could be blocked by a member of your UIC group creating the helper process's name ahead of time; the name now carries a random part. A listing that would exceed 4 MB now stops at 3.5 MB and says so, rather than failing.

What it does

• Users: create, copy and delete (as AUTHORIZE ADD, COPY and REMOVE); list and filter; read and modify everything AUTHORIZE SHOW shows; set passwords.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke.
• Access history: who reached the system, when, from where and by which route.
• Logical names: the tables and names as SHOW LOGICAL shows them to you; define, modify and deassign.
• Processes, queues and system parameters, as above.
• A dashboard of the system, and your session: switch your authorized privileges on and off, change your own password.
• An audit log of every sign-in, privilege switch and change. Passwords and logical-name values are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

[STEWARD.DOC]README.VMS explains each step: the service account and why it holds what it holds, the gateway secret shared with lighttpd, starting at boot, running STEWARD$CONFIGURE again, a reverse proxy in front, and the audit log. Keep Steward's service account in a UIC group of its own.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Upgrading from 0.6.x: PRODUCT INSTALL the new kit over the old one, then @STEWARD$ROOT:[COM]STEWARD$CONTROL RESTART. The settings, sessions and audit log are kept. From 0.5.x, also add the Cache-Control line described in the 0.6.2 notes to your STEWARD.CONF, or run STEWARD$CONFIGURE again.

Tested

On OpenVMS x86-64 E9.2-4:

• 375 unit checks run natively on OpenVMS.
• Each area was checked against the system's own commands, from a privileged work account and under test accounts with and without GROUP, WORLD and SYSPRV:
  • processes (phase8_live.py, 10 checks): the same processes as F$PID/F$GETJPI, with their names, usernames, UICs and base priorities;
  • stopping (phase8b_live.py, 11 checks): on batch jobs submitted for the purpose; the pool and system processes refused;
  • queues (phase9_live.py, 9; phase9b_live.py, 14): on held jobs and a test queue created and deleted for it; SYS$BATCH and the queue it feeds refused;
  • system parameters (phase10_live.py, 7): the same 317 parameters as SYSGEN SHOW/ALL, none differing;
  • logical names (phase7_live.py, 22; phase7b_live.py, 24), including a helper that dies at once and one that floods its mailbox.
• The pages were checked in a browser, and each test kit was installed over the one before.

On Linux, every push runs:

• the unit tests and an API suite, both under AddressSanitizer;
• fuzzing of every parser, the new SYSGEN SHOW parser included;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

Also new: tests of the logical names, processes, queues and system parameters pages in a headless DOM (make ui-test).

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0009-0-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.9-0 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

e298c82fec8511f3731ded41b7f9b3f88d78d59a9d6d5f25c426d44cebdad52c  ISSINOHO-X86VMS-STEWARD-T0009-0-1.PCSI

Steward 0.6.2 for OpenVMS x86-64 (early test): define and deassign logical names

Steward manages OpenVMS from a web browser. This is 0.6.2, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New in 0.6: define and deassign logical names

Logical names are no longer read-only:

• Define a name in any table you can list, at user, supervisor or executive mode, with its attributes (confine, no_alias) and up to 16 equivalences, each concealed or terminal as you choose. As DEFINE does.
• Modify a name at the mode you pick. A name defined at several modes gets a button for each; SHOW LOGICAL shows only the outermost.
• Deassign it, as DEASSIGN does: at that mode and every outer one.

It runs as you, with the privileges you have switched on, and OpenVMS decides: SYSNAM or SYSPRV for the system table, GRPPRV or GRPNAM for your group's. Steward adds to that only where OpenVMS would quietly do something else:

• No silent mode change. Without SYSNAM, OpenVMS turns a supervisor- or executive-mode define into a user-mode one, replacing a user-mode name you never mentioned. Steward refuses it instead and changes nothing.
• Asked first. Replacing an existing name, a no_alias that would remove the name at outer modes, and a deassign that takes outer modes with it are all named in the dialog before anything is sent.
• Audited, without the values. Every change goes in the audit log with the table, name and mode, never the equivalence strings, which sometimes hold passwords.

Security fix

Listing logical names could run someone else's procedure (since 0.5.0). The short-lived process that lists a table for you looked up its own procedure's path through your group's logical names. Someone able to write your group's table (GRPNAM, or GRPPRV in your group) could have made your listings run their procedure, as you, with the privileges you had switched on. Steward now resolves the path once at start-up to a physical disk and directory, which no logical name can redirect. It was found by a probe written for this release's review. The record is in docs/security.md.

Keep Steward's service account in a UIC group of its own (README.VMS): names in its own group, and outer-mode system names, still apply when it starts.

What it does

• Users: create (as AUTHORIZE ADD), copy (as COPY) and delete (as REMOVE); list and filter; read everything AUTHORIZE SHOW shows. Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• Access history: who reached the system, when, from where and by which route, in one list.
• Logical names: the tables, the names in each and what a name translates to, as SHOW LOGICAL shows them to you; define, modify and deassign them.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

[STEWARD.DOC]README.VMS explains each step: the service account and why it holds what it holds, the gateway secret shared with lighttpd, starting at boot, running STEWARD$CONFIGURE again, a reverse proxy in front, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Upgrading from 0.5.x: PRODUCT INSTALL the new kit over the old one, then @STEWARD$ROOT:[COM]STEWARD$CONTROL RESTART. The settings, sessions and audit log are kept. Also add one line to your [STEWARD_DATA.CONF]STEWARD.CONF, in the setenv.add-response-header list, and restart lighttpd:

            "Cache-Control" => "no-cache",

Without it, a browser can keep an old script from the earlier version beside new ones, and a page breaks until it is reloaded with the cache bypassed. Running STEWARD$CONFIGURE again writes the line for you, keeping your earlier answers.

Tested

On OpenVMS x86-64 E9.2-4:

• 289 unit checks run natively on OpenVMS.
• Defining and deassigning were checked against DCL (tests/vms/phase7b_live.py, 24 checks). After each change, SHOW LOGICAL/FULL and F$TRNLNM at every mode were compared with what Steward reported:
  • in the system and cluster tables with SYSNAM, and in a group table with GRPPRV;
  • refused for a user without the privilege, as at a terminal; executive mode without SYSNAM refused, with the user-mode name left untouched;
  • the audit log recording each change and refusal, and no equivalence.
• The read-only half was checked again (tests/vms/phase7_live.py, 20 checks).
• The security fix was shown with a decoy procedure in a group table: it ran before the fix, and was ignored after.
• The pages were checked in a browser. Each test kit was installed over the one before as an upgrade, from 0.5.1 to 0.6.2.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

New is a test of the logical-names page in a headless DOM (make ui-test): it renders the page and walks through Modify and Deassign.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0006-2-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.6-2 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

38d0e3663f03158d19949adad6c40de45fd8054a5a86c21b7b7b8d2a08e63817  ISSINOHO-X86VMS-STEWARD-T0006-2-1.PCSI

Steward 0.5.1 for OpenVMS x86-64 (early test): logical names

Steward manages OpenVMS from a web browser. This is 0.5.1, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New in 0.5.1: logical names

Browse logical names as SHOW LOGICAL shows them to you:

• The tables, grouped: system, cluster, your group's, other groups', jobs and the rest, as SHOW LOGICAL/STRUCTURE lists them.
• The names in a table, with their access mode, attributes and every equivalence. Filter with a DCL pattern (SYS$S*) or any part of a name.
• One name, followed through. Click a name to see what each equivalence translates to in turn: SYS$SYSROOT → SYS$COMMON → the disk.

As always, it runs as you. OpenVMS has no service that lists a table, so Steward runs SHOW LOGICAL in a short-lived process that is you, with the privileges you have switched on. A table you could not read at a terminal is not shown here either. Steward sends that process data only, never a command, and always ends it within 30 seconds. Process and job tables are never offered: under your persona they would be Steward's own, not yours.

This is the read-only half. Defining and deassigning names come next.

Also in this release:

• The fixes from the Phase 5 review, which were never released on their own.

• The fixes from an independent review of the new code. It found no way to read what OpenVMS would not show you. It did find, and this release fixes:

  • the helper's path could be redirected by someone holding GRPNAM in the service account's group;
  • a user's own login procedure could hold a server process past its deadline.

  Details are in docs/security.md.

What it does

• Users: create (as AUTHORIZE ADD), copy (as COPY) and delete (as REMOVE); list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• Access history: who reached the system, when, from where and by which route, in one list.
• Logical names: the tables, the names in each, and what a name translates to, as SHOW LOGICAL shows them to you.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Upgrading from 0.4.x: PRODUCT INSTALL the new kit over the old one, then @STEWARD$ROOT:[COM]STEWARD$CONTROL RESTART. The settings, sessions and audit log are kept.

Tested

On OpenVMS x86-64 E9.2-4:

• 251 unit checks run natively on OpenVMS.
• Logical names were checked against the system's own commands (tests/vms/phase7_live.py, 22 checks):
  • the system table name for name as SHOW LOGICAL/FULL lists it (341 names), and SYS$SYSROOT's equivalences as F$TRNLNM gives them;
  • the tables as SHOW LOGICAL/STRUCTURE lists them;
  • an unprivileged user refused another group's table, as at a terminal, and a user with SYSPRV switched on allowed it;
  • hostile table names and patterns refused before OpenVMS is asked;
  • a helper that dies is noticed in 2 seconds, and one that floods its mailbox is stopped at 30, with none left behind.
• The pages were checked in a browser.
• The kit was installed over 0.5.0 as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers, the new SHOW LOGICAL parser included;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including how the listing process is kept to the viewer's own rights, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0005-1-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.5-1 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

3b390f3a078d90c2fb5672b59d23d82c35e7a64f0713e9fcdb884f76a9a348b3  ISSINOHO-X86VMS-STEWARD-T0005-1-1.PCSI

Steward 0.4.0 for OpenVMS x86-64 (early test)

Steward manages OpenVMS from a web browser. This is 0.4.0, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New in 0.4.0: access history

One page answers "who got in, when, from where, and how". Steward merges the system's own records:

• Accounting gives every finished session: interactive, network and batch. LOGINOUT's failures are there too.
• The live process list shows who is on now.
• OpenSSH's logs give each SSH connection's sign-in method and key type.
• The security audit journal has failed sign-ins and break-ins, including password failures that never reach accounting.
• Steward's own log has sign-ins to Steward, with the browser's address.

Routes are SSH, TELNET, DECnet (SET HOST), LAT, local and console, batch, other network, and Steward. Filter by time window, user, route and outcome.

One event is shown once. An SSH connection's server process, its log, its commands and its session are joined into a single row. A wrong password, which OpenVMS can record in three places, is a single failure. Bursts of short connections from one user and address, such as a script, fold into one row that opens to list them.

As always, it runs as you. The files are protected, so you need SYSPRV or READALL switched on to read them. A source OpenVMS refuses is named, with its message, and the rest are still shown. Nothing runs in the background and the service account gains no privilege.

Also: pages no longer overflow a phone's screen.

What it does

• Users: create (as AUTHORIZE ADD), copy (as COPY) and delete (as REMOVE); list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• Access history: who reached the system, when, from where and by which route, in one list.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 223 unit checks run natively on OpenVMS.
• Access history was checked against the system's own records (tests/vms/phase6_live.py, 11 checks):
  • a day read in 0.69s;
  • every SSH connection among ACCOUNTING's, by PID;
  • a deliberate wrong password shown once;
  • an unprivileged user refused each file by OpenVMS.
• The user-management changes were confirmed in AUTHORIZE (phase3_live.py, phase4_live.py).
• The pages were checked in a browser through nginx proxy manager.
• The kit was installed over 0.3.1 as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what Phase 6 reads and why that is safe, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0004-0-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.4-0 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

ea0c5b85262328491a1f9b27dd4c05063a1c2868440c969ded588169e256220e  ISSINOHO-X86VMS-STEWARD-T0004-0-1.PCSI

Steward 0.3.1 for OpenVMS (early test)

Steward manages OpenVMS from a web browser. This is 0.3.1, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

Changes since 0.3.0

• New user no longer suggests the DEFAULT account's UIC group, which on many systems belongs to real users. You enter the group, as AUTHORIZE ADD makes you choose a UIC, and Steward suggests the next free member. Copy still starts in the source's group.
• Create, copy and delete passed their browser checks against the installed kit, and an account made by Steward was shown to sign in through SYS$ACM.

New in 0.3.0: create, copy and delete users

Steward now covers the whole of a user's life, as AUTHORIZE does:

• New user, as AUTHORIZE ADD: starts from the DEFAULT account's settings with a new name, UIC and password.
  • Enter a UIC group and the dialog suggests the next free member; the directory follows the username as you type.
  • One tick clears the DISUSER flag that DEFAULT carries.
  • The password is pre-expired by default.
  • It can also create the home directory, owned by the new account.
• Copy, as AUTHORIZE COPY: every setting of an existing user, with a new name, UIC and password. You can also grant it the identifiers the original holds.
• Delete, as AUTHORIZE REMOVE: the account, its UIC identifier and its identifier holdings. Files and directories are left alone. You type the name to confirm. Steward won't delete the account you're signed in as, or its own.

As always, it runs as you, so OpenVMS requires SYSPRV and refuses anyone else. A create either completes or leaves nothing behind: if OpenVMS refuses the password after the record is written, the record and identifier are removed again. Every step was checked against AUTHORIZE on the x86 test system (23 checks).

0.2.0 added the dashboard: the system at a glance, read as you.

What it does

• Users: create (as AUTHORIZE ADD), copy (as COPY) and delete (as REMOVE); list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 206 unit checks run natively on OpenVMS.
• The changes were made through the real code and confirmed in AUTHORIZE (tests/vms/phase3_live.py and phase4_live.py, 23 checks each). OpenVMS refused them for a user without SYSPRV switched on.
• Sign-in, privilege switching, expired and disabled accounts, and the read-only views were checked in a browser through nginx proxy manager.
• The kit was installed, configured and run with its own procedures, and each release since was installed over the last as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what each review found and fixed, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0003-1-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.3-1 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

8056ae37467f9c22cd642e85e324b94ecb1fb2f8aca54767afcd47aa391ba65e  ISSINOHO-X86VMS-STEWARD-T0003-1-1.PCSI

Steward 0.3.0 for OpenVMS (early test): create, copy and delete users

Steward manages OpenVMS from a web browser. This is 0.3.0, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New in 0.3.0: create, copy and delete users

Steward now covers the whole of a user's life, as AUTHORIZE does:

• New user, as AUTHORIZE ADD: starts from the DEFAULT account's settings with a new name, UIC and password.
  • The dialog suggests the next free UIC in the group, and the directory follows the username as you type.
  • One tick clears the DISUSER flag that DEFAULT carries.
  • The password is pre-expired by default.
  • It can also create the home directory, owned by the new account.
• Copy, as AUTHORIZE COPY: every setting of an existing user, with a new name, UIC and password. You can also grant it the identifiers the original holds.
• Delete, as AUTHORIZE REMOVE: the account, its UIC identifier and its identifier holdings. Files and directories are left alone. You type the name to confirm. Steward won't delete the account you're signed in as, or its own.

As always, it runs as you, so OpenVMS requires SYSPRV and refuses anyone else. A create either completes or leaves nothing behind: if OpenVMS refuses the password after the record is written, the record and identifier are removed again. Every step was checked against AUTHORIZE on the x86 test system (23 checks).

0.2.0 added the dashboard: the system at a glance, read as you.

What it does

• Users: create (as AUTHORIZE ADD), copy (as COPY) and delete (as REMOVE); list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 206 unit checks run natively on OpenVMS.
• The changes were made through the real code and confirmed in AUTHORIZE (tests/vms/phase3_live.py and phase4_live.py, 23 checks each). OpenVMS refused them for a user without SYSPRV switched on.
• Sign-in, privilege switching, expired and disabled accounts, and the read-only views were checked in a browser through nginx proxy manager.
• The kit was installed, configured and run with its own procedures, and each release since was installed over the last as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what each review found and fixed, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0003-0-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.3-0 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

7ad0c9b97f8485a634f8691a095f66bd723721262fe359568bf2f90507e27bc6  ISSINOHO-X86VMS-STEWARD-T0003-0-1.PCSI

Steward 0.2.0 for OpenVMS (early test): the dashboard

Steward manages OpenVMS from a web browser. This is 0.2.0, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

New in 0.2.0: the dashboard

Steward now opens on the system at a glance:

• the node, OpenVMS version and hardware, uptime and boot time;
• a CPU gauge;
• memory and paging;
• processes and interactive sessions;
• queues and jobs, cluster membership, and every disk's capacity.

The figures are the ones vms-fastfetch shows, read with the same system services. Like everything in Steward, they are read as you. If OpenVMS would hide other users' processes from you (no GROUP or WORLD), the dashboard says how many it can't show, and why.

It refreshes every 10 seconds, and not while the tab is hidden. Those refreshes don't keep your session alive, so a dashboard left open still signs out when idle. On the x86 test system it matched SHOW MEMORY, SHOW DEVICE and the boot time exactly.

What it does

• Users: list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• A dashboard of the system: OS, hardware, uptime, CPU, memory, paging, disks, processes, queues and cluster.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

Not yet: creating, copying and deleting users. IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 178 unit checks run natively on OpenVMS.
• The changes were made through the real code and confirmed in AUTHORIZE (tests/vms/phase3_live.py, 23 checks). OpenVMS refused them for a user without SYSPRV switched on.
• Sign-in, privilege switching, expired and disabled accounts, and the read-only views were checked in a browser through nginx proxy manager.
• The kit was installed, configured and run with its own procedures, and each release since was installed over the last as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what each review found and fixed, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0002-0-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.2-0 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

6bca09e8856e6c2a4a3586d97e8538db48aff268cad00c5b20dcab82d147f263  ISSINOHO-X86VMS-STEWARD-T0002-0-1.PCSI

Steward 0.1.2 for OpenVMS (early test)

Steward manages OpenVMS from a web browser. This is 0.1.2, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

Changes since 0.1.1

• Changes are now fully checked in the browser: modify, set password, the expired-password change at sign-in, and creating, granting and deleting identifiers all passed against the installed kit. The "Save did nothing" report from an earlier test did not recur.
• STEWARD$CONFIGURE now removes old copies of the account's LOGIN.COM and of lighttpd's gateway file when run again. Before, a copy of the gateway secret was left behind each time. It also deletes its temporary FDL file.

0.1.1 added the theme switch (Auto, Light or Dark).

What it does

• Users: list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

Not yet: creating, copying and deleting users. IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 170 unit checks run natively on OpenVMS.
• The changes were made through the real code and confirmed in AUTHORIZE (tests/vms/phase3_live.py, 23 checks). OpenVMS refused them for a user without SYSPRV switched on.
• Sign-in, privilege switching, expired and disabled accounts, and the read-only views were checked in a browser through nginx proxy manager.
• The kit was installed, configured and run with its own procedures, and each release since was installed over the last as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what each review found and fixed, is in docs/security.md.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0001-2-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.1-2 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

3dab36253ff56c1bddf075bb2b299c17f101db73278051573cdabe036435c5a2  ISSINOHO-X86VMS-STEWARD-T0001-2-1.PCSI

Steward 0.1.1 for OpenVMS (early test)

Steward manages OpenVMS from a web browser. This is 0.1.1, an early test release for OpenVMS x86-64, for people willing to try it on a test system and say what they find. It is not a port: Steward is written for OpenVMS from scratch, as a C99 FastCGI service with a plain-JavaScript front end, served by lighttpd for OpenVMS. Part of the same family as lighttpd, MariaDB, curl, fastfetch and the other ports for OpenVMS.

Every request runs as you. You sign in with your OpenVMS username and password, checked by SYS$ACM, so expiry, DISUSER, login hours and break-in evasion all apply. Each request then runs under your own OpenVMS identity (a persona). OpenVMS decides what you may see and change, exactly as at a terminal. Steward has no permissions model of its own.

Changes since 0.1.0

• A theme switch in the top bar and on the sign-in page: Auto (follow the browser), Light or Dark, remembered per browser.

What it does

• Users: list and filter; read everything AUTHORIZE SHOW shows (flags, days and the access-hour grid, privileges, quotas, identifiers held). Modify them, as AUTHORIZE MODIFY does, with a check that nobody else changed the record since you opened it. Set passwords, optionally pre-expired.
• Rights identifiers: list with holders; create, rename, set attributes, delete; grant and revoke, with holding attributes.
• Your session: switch your authorized privileges on and off, as SET PROCESS/PRIVILEGE does. Change your own password, including from the sign-in page when it has expired.
• An audit log of every sign-in, privilege switch and change, with the client's address. Passwords are never recorded.

Not yet: creating, copying and deleting users. IA64 kits will follow.

Installing

$ PRODUCT INSTALL STEWARD /SOURCE=dev:[dir]
$ @STEWARD$ROOT:[COM]STEWARD$CONFIGURE        ! once, as SYSTEM
$ ! add the include line it prints to lighttpd's LIGHTTPD.CONF, then:
$ @STEWARD$ROOT:[COM]STEWARD$CONTROL START
$ @VMSLIGHTTPD$ROOT:[COM]VMSLIGHTTPD$CONTROL RESTART

STEWARD$CONFIGURE creates the service account: batch access only, with IMPERSONATE, TMPMBX and NETMBX. SYSPRV is authorized but off; Steward switches it on only for the instant it creates your persona, and checks after every request that it is off again. It also sets up the data directory and a gateway secret shared with lighttpd, so no other process on the system can talk to Steward directly. [STEWARD.DOC]README.VMS explains each step, running behind a reverse proxy such as nginx proxy manager, and the audit log.

Requires: OpenVMS x86-64 V9.2-x, VSI TCP/IP Services, VSI SSL3 (OpenSSL 3.0), vms-lighttpd 1.4.85-vms2, and HTTPS at the browser (a TLS proxy in front, or TLS in lighttpd).

Tested

On OpenVMS x86-64 E9.2-4:

• 170 unit checks run natively on OpenVMS.
• The changes were made through the real code and confirmed in AUTHORIZE (tests/vms/phase3_live.py, 23 checks). OpenVMS refused them for a user without SYSPRV switched on.
• Sign-in, privilege switching, expired and disabled accounts, and the read-only views were checked in a browser through nginx proxy manager.
• The kit was installed, configured and run with its own procedures, and 0.1.1 was installed over 0.1.0 as an upgrade.

On Linux, every push runs:

• the same unit tests and an API suite, both under AddressSanitizer;
• fuzzing of the parsers;
• GCC's analyzer, cppcheck, flawfinder, Semgrep and gitleaks.

The security record, including what each review found and fixed, is in docs/security.md.

Since publishing: the browser checks for changes (modify, set password, the expired-password change at sign-in, and grant, create and delete identifiers) all passed against this kit. A "Save did nothing" report from an earlier test did not recur. If you see it, please open an issue with what the browser console (F12) shows.

Kit	Platform
ISSINOHO-X86VMS-STEWARD-T0001-1-1.PCSI	OpenVMS x86-64 (built and tested on E9.2-4)

T0.1-1 is PCSI's field-test version. SHA256SUMS lists the SHA-256 of the kit:

e7213e75f800955604c45319d7b391e1ef0e11e1a51838fb582c1746862d2d7b  ISSINOHO-X86VMS-STEWARD-T0001-1-1.PCSI