cabbage/rvbox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test: reset Windows native runs from clean baseline

Browse Source
This commit is contained in:
cabbage
2026-09-09 07:13:14 +00:00
parent 665901afcd
commit 985a2c2422
5 changed files with 170 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/testing-vm.md
+50 -33
View File
@@ -6,7 +6,9 @@ Windows release matrix. Keep the values here in sync with the VM before adding
or changing native test automation.
Last configuration check: 2026-09-09 UTC. The VM was observed powered off with
`baseline-disk-first` selected. A test run must still perform its own identity,
`baseline-disk-first` selected. The native harness now targets `baseline-clean`;
the fixture must be rechecked and its current snapshot returned to that clean
baseline before native runs resume. A test run must still perform its own identity,
snapshot, readiness, and exclusive-lease checks rather than relying on that
observation.
@@ -25,7 +27,7 @@ observation.
| Guest OS | Windows 10 Pro 22H2, build `19045.2006`, en-US, BIOS boot |
| Guest account | Local `rvboxtest`; split-token local administrator; console session 1 was observed during provisioning |
| Guest Additions | `7.2.16r174877`; readiness requires published Guest Additions version and Windows OS-release properties (this build does not publish a RunLevel property) |
| Last observed state | `poweroff`; current snapshot `baseline-disk-first` |
| Last observed state | `poweroff`; current snapshot `baseline-disk-first` (must be restored to `baseline-clean` before native runs) |
The Guest Control credential is test-only. The account name is safe to record,
but the password value is intentionally not committed to this repository. On
@@ -84,7 +86,9 @@ and collection. Do not expose the VM's RDP endpoints beyond the test LAN.
## Snapshots and reset contract
Two clean snapshots exist and must be retained:
Two clean snapshots exist and must be retained. `baseline-clean` is the only
reset target: it contains no `RVBoxClient` SCM service, RVBox tray Run-key
registration, RVBox state, logs, or staged binaries.
| Snapshot | UUID | Description |
| --- | --- | --- |
@@ -95,12 +99,12 @@ Restore only while the VM is powered off. Every destructive or potentially
stateful run must:
1. Acquire the run lease and verify the VM name, UUID, and snapshot UUID.
2. Restore `baseline-disk-first` if the current state is not the baseline.
2. Restore `baseline-clean` if the current state is not the baseline.
3. Start headless and wait for `VMState=running` plus Guest Additions readiness.
4. Run the bounded test, collect redacted artifacts, and close every Guest
Control process that was opened by the run.
5. Request a graceful guest shutdown and wait for `VMState=poweroff`.
6. Restore `baseline-disk-first` again and leave the VM powered off.
6. Restore `baseline-clean` again and leave the VM powered off.
Use `controlvm ... poweroff` only for a hung, disposable test; it can lose
guest state. Never delete either clean snapshot, unregister the VM, or alter
@@ -112,7 +116,7 @@ The canonical adapter is the POSIX controller script
[`scripts/windows/test-host`](../scripts/windows/test-host). It runs from the
Linux controller and invokes `VBoxManage` only through SSH on Helium; the
fixture host is Arch Linux and does not provide PowerShell. Its actions are
`status`, `prepare`, `stage`, `run`, `collect`, `stop`, `reset`, and `recover`.
`status`, `prepare`, `stage`, `install`, `run`, `collect`, `stop`, `reset`, and `recover`.
The legacy [`test-host.ps1`](../scripts/windows/test-host.ps1) is retained only
as a reference for a future Windows-hosted fixture and is not the Helium lane.
@@ -122,8 +126,8 @@ The adapter takes identity and credentials only from its environment:
export RVBOX_TEST_VBOX_HOST=helium-remote
export RVBOX_TEST_VBOX_VM=rvbox-win10-test
export RVBOX_TEST_VBOX_VM_UUID=6cdc114f-71e5-4167-a394-e922e14e6f5c
export RVBOX_TEST_VBOX_SNAPSHOT=baseline-disk-first
export RVBOX_TEST_VBOX_SNAPSHOT_UUID=9430a9a4-754a-4b22-beaa-8dfd90043f5b
export RVBOX_TEST_VBOX_SNAPSHOT=baseline-clean
export RVBOX_TEST_VBOX_SNAPSHOT_UUID=5e79176a-3e56-4c5d-bb61-a405a6dcdd59
export RVBOX_TEST_GUEST_USER=rvboxtest
export RVBOX_TEST_GUEST_PASSWORD_FILE=/home/cabbage/.local/share/rvbox-secrets/rvbox-win10-test.password
```
@@ -145,34 +149,47 @@ the single `/c` payload are preserved.
`stage` accepts one versioned non-secret test bundle and copies it first to an
exact host staging directory, then to
`C:\\ProgramData\\RVBox\\test-runs\\<run-id>`. `run` never directly executes the
GUI-subsystem `rvbox.exe` through Guest Control. It uses `sc.exe` and other
console-safe management tools to start/query/stop the installed RVBox service,
then checks the service's real health endpoint, named-pipe response, durable
state, and agent-server results. Before a WSS scenario it performs a bounded
guest-to-nginx connectivity and CA-trust probe. The resulting service and
artifact paths are recorded in the run report and reclaimed by the snapshot
reset rather than broad guest deletion.
`C:\\ProgramData\\RVBox\\test-runs\\<run-id>`. `install` performs the one
purposeful direct Guest Control launch of the staged GUI-subsystem executable,
using only the fixture provisioner's high token; because this VirtualBox build
cannot reliably report that process's exit, SCM `RUNNING` is the completion
proof. After installation, `run` uses `sc.exe` and other console-safe management
tools to reconfigure/start/query/stop the installed RVBox service, then checks
the service's real health endpoint, named-pipe response, durable state, and
agent-server results. Before a WSS scenario it performs a bounded guest-to-nginx
connectivity and CA-trust probe. The resulting service and artifact paths are
recorded in the run report and reclaimed by the snapshot reset rather than broad
guest deletion.
### Required one-time service bootstrap
### Clean baseline and non-interactive installation
Guest Control launches `rvboxtest` with its filtered, medium-integrity UAC
token: the Administrators SID is deny-only. The harness must not bypass UAC to
create services. Before native service tests can run, an operator must use a
trusted interactive elevated session to install one test-only `RVBoxClient`
service in the baseline and grant only `rvboxtest` the service rights required
by the harness: query status/configuration, change its image/configuration,
start, and stop. The test account also needs write access only to the dedicated
`C:\\ProgramData\\RVBox\\test-runs` subtree; SYSTEM retains ownership of normal
RVBox state and logs. Record the resulting service SDDL and subtree ACL in this
document before taking a new reset snapshot.
`rvboxtest` deliberately remains a split-token administrator. Guest Control
therefore launches it at medium integrity and it must never be used to create
or modify machine-wide SCM state. The reset snapshot has no RVBox installation.
Each run then stages an exact bundle, changes the bootstrapped service image to
that run's explicit `--service --config` command line, and starts it through
SCM. The one-time bootstrap is fixture administration, not a second RVBox
process, runtime elevation broker, or Task Scheduler mechanism. Native tests
for the production installer/UAC flow remain a separately interactive test;
they cannot be automated through this filtered Guest Control token.
To automate the real install path, provision one separate **fixture-only**
full-token local administrator and retain its username/password solely in the
Helium secret store. It must be a genuinely high-integrity Guest Control token;
do not globally disable UAC or change `rvboxtest` into an always-elevated user.
The normal harness receives it only through these environment variables:
```sh
export RVBOX_TEST_PROVISIONER_USER=FIXTURE_ONLY_FULL_ADMIN
export RVBOX_TEST_PROVISIONER_PASSWORD_FILE=/home/cabbage/.local/share/rvbox-secrets/rvbox-win10-test-provisioner.password
```
Both files remain mode `0600` on Helium and neither value is recorded in run
reports or artifacts. `test-host install` first verifies that the reset guest
has no `RVBoxClient`, checks the provisioner's High Mandatory Level, invokes
the actual staged `rvbox.exe --install-service --config ...`, and polls SCM for
`RUNNING`. `run` may then exercise reconfigure/start/restart paths. Snapshot
reset removes the installed service and all RVBox data again.
The provisioner is fixture administration only: it is not shipped with RVBox,
not a product service/broker, not a Task Scheduler dependency, and never
participates in command-context selection. The separately interactive UAC
prompt route remains a small manual test because an invisible Guest Control
session cannot safely approve a consent prompt.
## Scope and known limitations