aim-web2.1.0rc9
This commit is contained in:
admin_rb
@@ -0,0 +1,31 @@
|
||||
# WebGUI HTTP APIv2 - Core3.3 / schema5 candidate
|
||||
|
||||
Core service/wire/event remains1.0 and is reached through fixed aimctl transport. WebGUI HTTPv2 is a separate authenticated API. All existing review, one-run, credential, grant, plan/retry/delete routes remain; unsafe requests require existing CSRF and same-origin policy. No arbitrary core-command/actor/path endpoint.
|
||||
|
||||
## Existing workflows
|
||||
|
||||
POST /api/v2/preflight takes customer,playbook,explicit targets,overrides,check,key_mode and returns private expiring review_id and normalized plan. result_contract is now preserved. POST /api/v2/runs takes review_id,confirm plus Idempotency-Key; no saved plan is required. Optional one-shot UTC scheduled_at remains unchanged. POST /api/v2/plans has an optional unique account-local name, never an upsert. POST /api/v2/runs/{id}/retry is a new requester-owned reviewed attempt; running jobs cannot be deleted.
|
||||
|
||||
Credential POST /api/v2/runs/{id}/credentials and existing jobs alias remain8KiB, requester-only reserved-window input; private FD downstream; no credential response echo. GET credential-status does not extend reservations or prove correctness. Modal and full-page fallback remain unchanged.
|
||||
|
||||
## New retained-evidence reads
|
||||
|
||||
All routes use owner-or-admin job authorization. Missing/inaccessible jobs are404, not aggregate leaks.
|
||||
|
||||
| GET | Meaning |
|
||||
|---|---|
|
||||
| /api/v2/runs/{id}/progress | Tail snapshot/checkpoint, default200 records. after/before mutually exclusive, nonnegative committed local cursors; limit1..500. |
|
||||
| /api/v2/runs/{id}/progress/stream?after=N | Replay then follow committed public metadata through SSE; Last-Event-ID overrides initial after on reconnect. |
|
||||
| /api/v2/runs/{id}/console | Compatibility alias to the durable progress SSE, not raw console output. |
|
||||
| /jobs/{id}/progress?before=N | Authorized server-rendered pagination/no-JavaScript timeline. |
|
||||
| /api/v2/runs/{id}/reports | Report header/availability/retention index; no report bodies. |
|
||||
| /api/v2/runs/{id}/report?host=HOST | One retained slot, schema/availability/mode/time/retention and bounded data. Empty host selects global scope where applicable. |
|
||||
| /jobs/{id}/reports?host=HOST&field=FIELD&page=N | Schema-aware HTML summary,50-row collection paging and lazy JSON. |
|
||||
|
||||
A journal response includes job/status/terminal, available,cursor,next_cursor,first_cursor,events,checkpoint,has_more,has_older,omitted_events,dropped_events,capture_state and capture_interrupted. Each event record has local cursor,receipt time,allowlisted Core event and derived display text. Text is rendered on reads, never stored as a console transcript.
|
||||
|
||||
SSE events: snapshot (committed metadata), line (record and legacy text), gap (retention omission), end (terminal or revoked access). Only durable records carry data cursors. Transport keepalive comments are not task activity. Final event and final response are one run, not duplicate reports. Final authoritative target facts remain in /api/v2/runs/{id}; operation_result there is a compact availability/retention projection, with bodies only in the separate report route.
|
||||
|
||||
Report states: available,missing,withheld,invalid,not_started,indeterminate. Local retention: retained,metadata_only,unavailable,not_retained_limit. Do not conflate these fields with execution success. Checkmk configuration defaults to metadata_only even with Core status available. Reports are finalization-only.
|
||||
|
||||
No browser read calls prepare/execute, opens the credential channel, probes hosts or imports terminal Core history. Deletion cascades journal/reports while audit keeps its compact event. Old jobs without evidence show unavailable; cursor replay cannot recover nonretained/uncaptured data. All evidence uses Cache-Control:no-store and is escaped for display.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Architecture - 2.1.0rc9
|
||||
|
||||
Core3.3.0rc8 owns current inventory, normalized requests/revisions, native execution, credential handling, safe progress, per-target outcomes and declared final report validation. Its API remains1.0. WebGUI owns authentication/authorization, reviewed workflows, UI and its own retained history.
|
||||
|
||||
Browser -> HTTP/queue (aim-web) -> fixed private executor socket -> executor account -> aimctl under same UID -> native Ansible. No new daemon, privilege or Core import.
|
||||
|
||||
The reviewed plan now includes a validated result_contract. Public response parsing has separate large-result limits and strict JSON parsing; secret transport stays unchanged. Core's final result event is progress only. The final response is projected against the reviewed schema/scope/targets/mode and is the sole report-persistence input.
|
||||
|
||||
During execution Capture.submit projects metadata into a bounded queue. A writer thread batches durable journal rows and a latest-observation checkpoint into SQLite transactions. HTTP reads/replay query committed rows and never connect to the process console. Browser latency cannot fill the Core credential pipe or control capture. Capture loss/limits are recorded distinctly from execution outcomes.
|
||||
|
||||
Schema5 adds job_progress_events,job_progress_state,job_operation_results and job_operation_reports; all reference jobs with ON DELETE CASCADE. Core_result keeps its small authoritative status/targets and a compact report availability summary. Analytics need not decode report bodies. Report reads lazily select one slot. Histories still use only retained WebGUI jobs, with owner/admin authorization before queries and aggregation.
|
||||
|
||||
Core reports are independent of progress. Schema-aware views render typed structured facts and a generic safe JSON alternative. Unknown supported schemas have no dynamic code/$ref/network loading. Report availability, retention and execution verdict remain separate. No global reporting operation ships with Core; generic global support is fixture-qualified only.
|
||||
|
||||
Journal/report storage uses the existing private web DB, rollback journaling and synchronous FULL. It is not an immutable or tamper-proof audit store. Bounded metadata queues plus250ms transaction busy limits separate capture pressure from task execution; persistent DB failure remains a service failure and cannot be hidden as success. Job-linked deletion is not backup/physical erasure.
|
||||
|
||||
The existing read-only Explorer/Activity/Insights remain public Core reads or authorized SQL reads. They do not modify current inventory, contact hosts or include terminal history. Host report references explicitly label date/mode; successful Ansible outcomes are not live health/compliance.
|
||||
@@ -0,0 +1,37 @@
|
||||
# Controller acceptance - WebGUI2.1.0rc9 / Core3.3.0rc8
|
||||
|
||||
**Controller prerequisite:** Core rc8 requires `ansible.windows >=3.8.0,<4.0.0` for Windows playbooks. Confirm it in the canonical collection path under the executor identity; WebGUI does not install collections.
|
||||
|
||||
Not a record of already performed managed-host tests. Use Core's SANITY.md and approved disposable targets. Preserve the actual execution UID/groups/HOME/sandbox and both staging exceptions; do not use root-shell success to certify the service.
|
||||
|
||||
1. Quiesce/backup, deploy Core independently, deploy new WebGUI preserving schema5 (or migrate older schema4), verify versions/permissions and installed executor preflight. Check terminal AIM remains independent. Confirm old prepared jobs did not replay and old history remains.
|
||||
2. Run role detection and disk usage on a small approved scope. Verify prepared report declaration/schema, existing Unlock modal, final native facts and report payloads against authorized native observation. Verify unavailable/null/false values are distinct.
|
||||
3. During a longer safe run, close the page, reopen/reload, use another authorized device and inspect the same committed timeline. Check interleaved host/task IDs, last activity and bounded internal scrolling. Manual upward scrolling stops following. No invented ETA/completion percentage.
|
||||
4. Check mixed targets (one unreachable) and separate report availability. Test a controlled required-report fixture failing validation after native exit0: job stays failed/result_validation, native targets remain visible and no automatic retry occurs. Fixture/source changes require fresh review.
|
||||
5. Verify all nine report types in separately approved scope. Patching/reboot/service-start/export/delete operations require dedicated test conditions, not a casual UI smoke. Reports change task totals; compare intended effects, outcomes and schemas, not old exact task counts.
|
||||
6. Verify default parsed Checkmk config retention excludes sections while showing file/redaction metadata. Full content opt-in is deliberate. Check report copying/rendering and narrow mobile/short landscape; values never become HTML or automatic links.
|
||||
7. Revoke session/access while streaming, check another owner's job is unavailable, and confirm admin access does not mean submitting someone else's credentials. Verify journal/report deletion cascades and Host Activity contributions disappear without recreating data from audit.
|
||||
8. In a disposable run, restart a worker/executor and confirm prior recorded metadata survives but remote execution is not automatically resumed/replayed; uncommitted metadata or missing final outcome is disclosed.
|
||||
9. Test retention with synthetic high-volume data, not unbounded production playbooks. Omissions must be visible; final Core facts remain independent. Monitor DB growth/backups and storage pressure.
|
||||
10. Test matched schema/Core rollback with historical DB warning and sessions revoked. An incompatible restored adapter must remain stopped/disabled until independent Core rollback and explicit service enablement.
|
||||
|
||||
Record actual versions, UID/group context, platform, report/mode and final result. Source/browser fixtures or success on one host do not certify all9 operations, other operating systems, physical keyboards, global reports or a different security profile.
|
||||
|
||||
## Core rc8 patch-wave and native-baseline acceptance
|
||||
|
||||
After the low-risk reporting checks above, use Core3.3.0rc8's current SANITY.md on
|
||||
separately approved disposable Windows update/reboot targets. Confirm the new catalog
|
||||
controls, false continuation hint, omitted inherited values and explicit true/false
|
||||
review. A reboot flag must not auto-enable continuation.
|
||||
|
||||
Verify a successful patch-triggered reboot can end with continuation_required=true,
|
||||
remaining_updates_known=false and no next-wave list or auto-submitted job. Verify an
|
||||
explicit continuation run uses the documented Core cycle bound. Test the final
|
||||
read-only pending discovery path, deferred reboot, pre-existing-reboot block and a
|
||||
bounded per-update failure. Distinguish unsigned/hex HRESULT plus reason/message from
|
||||
the independent pending-reboot observation. Old reports without wave fields should
|
||||
remain viewable and labeled as historical; no unknown value becomes false/zero.
|
||||
|
||||
Do not equate a Windows test with Linux or every supported Windows release. Preserve
|
||||
native result-validation failures, partial host outcomes, journal/report retention,
|
||||
modal deadlines and global SSH trust. This release does not change their policies.
|
||||
@@ -0,0 +1,90 @@
|
||||
> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.
|
||||
|
||||
> Historical core review. Current2.1 behavior is documented in README, API and READ-ONLY-EXPERIENCE; older capability limits below are not current release claims.
|
||||
|
||||
# Review of the supplied AIM 3.1.0 contract
|
||||
|
||||
Reviewed archive: AIM-Ansible-3.1.0.zip
|
||||
SHA-256: `6005cab58875cfd6eabfd18e9b388c219a02d5b0472ba50a94c78abafb637ae9` (matched the supplied checksum).
|
||||
This is source-based analysis, not live-controller verification. The core archive
|
||||
and extracted baseline are not changed by WebGUI development.
|
||||
|
||||
## Sources reviewed
|
||||
|
||||
Paths below are relative to aim-core-3.1.0 in the uploaded ZIP:
|
||||
|
||||
| Source | Load-bearing contract/findings |
|
||||
|---|---|
|
||||
| ADDON_AGENTS.md | Authoritative same-UID, independent client boundary; no private imports, argument interception or key export |
|
||||
| scripts/docs/ADDON_API.md | Public operations, RunRequest, credentials-fd framing, event/result schema, limits |
|
||||
| scripts/docs/ADDON_SUPPORT.md and addon-support-v1.json | Implemented scope versus unsupported Custom, raw output and mutable APIs |
|
||||
| scripts/docs/RELEASE_HANDOFF.md | Core 3.1/API 1.0 stability; controller results do NOT establish noninteractive execution or non-root SSH qualification |
|
||||
| scripts/docs/RC19_HANDOFF.md | Historical design intent only; newer support contract takes precedence |
|
||||
| scripts/docs/LOCAL_VALIDATION.md and CONTROLLER_ACCEPTANCE.md | Core acceptance procedure and evidence boundaries |
|
||||
| deploy/README.md and scripts/aim.yml | Independently installed aim/aimctl; operator-owned addon execution opt-in and runtime settings |
|
||||
| scripts/src/aim/services/v1/models.py | Strict RunRequest; unknown fields rejected; explicit hosts; no credential or arbitrary path/actor fields |
|
||||
| scripts/src/aim/services/v1/service.py | prepare/readiness/execute, key 0600 calling-UID policy, authoritative revisions, native inventory precedence, safe events |
|
||||
| scripts/src/aim/ctl.py | One request JSONL line; separate inherited pipe/socket secret channel; final response required |
|
||||
| scripts/src/aim/runtime/ansible.py and process.py | Native CLI discovery/execution, core-owned environment and cancellation |
|
||||
| scripts/src/aim/locking.py | Stable customer .aim.lock, shared terminal/service advisory locking |
|
||||
| scripts/src/aim/inventory and playbooks modules | Checked only to understand documented output; never imported by the add-on |
|
||||
|
||||
## Decisions derived from these sources
|
||||
|
||||
1. Replace RC18Adapter, external_presentation interception and the private Ansible
|
||||
credential strategy entirely with a bounded aimctl client. Core's private signatures
|
||||
are not the supported extension interface.
|
||||
2. `service_user` remains the remote account/key basename. `runtime.private_key_owner`
|
||||
controls new-key ownership, not automatic local UID switching. An explicitly
|
||||
pre-started add-on executor runs as the actual authorized key-owning UID. This is
|
||||
add-on infrastructure, not a claimed native core broker.
|
||||
3. prepare returns a core-owned revision and credential requirements. Save/queue/
|
||||
dispatch revalidate through prepare, not local inventory scans/hashes. No stat-only
|
||||
shortcut for protected sources. Key mode customer needs key access during prepare.
|
||||
4. Core 1.0 supports customer/catalog reads but no inventory mutations, Custom forced
|
||||
authentication or password-only verification. Native password defaults retain
|
||||
inventory precedence. The old Custom UI is removed rather than silently reinterpreted.
|
||||
5. list_hosts exposes name/address/platforms, not recursive inventory group paths.
|
||||
Bulk selection is retained for available platform groups only. This is a temporary
|
||||
feature-parity loss, not a reason to import inventory internals.
|
||||
6. Global catalog is a union of customer-scoped available catalogs; unavailable
|
||||
customer-specific playbooks are not offered. Catalog inputs remain core-typed.
|
||||
7. Events contain structured fixed statuses/counters, not raw task names/messages.
|
||||
The old raw live console becomes Execution progress. RunResult controls success;
|
||||
zero exit without final counters is not treated as successful.
|
||||
8. Optional core fields are ignored safely. The tested product is 3.1.0, service/
|
||||
wire/event1.0. Future core products need qualification even if API 1.x is stable.
|
||||
9. Core's public `readiness` performs local runtime/collection checks. It is not a
|
||||
remote connection test or guarantee that native task execution will succeed.
|
||||
10. There is no public per-browser-user actor authorization. WebGUI maintains its
|
||||
own account/grant/approval checks, but the executor UID is a trusted controller actor
|
||||
with the core permissions of that OS identity, not an isolated tenant.
|
||||
|
||||
## Explicit changes from old WebGUI
|
||||
|
||||
- Removed imports of aim.config, managers, inventory readers and old command hooks.
|
||||
- Removed TextVaultSecret/VaultSecret API adaptation, custom Ansible strategies,
|
||||
canonical-key-export sudo bridge, job-private canonical-key copies and elevated
|
||||
CAP_SETUID/CAP_SETGID worker design.
|
||||
- Ansible/version/collection interpretation now belongs to core. `/usr/bin` is no
|
||||
longer an add-on execution.ansible_bin setting.
|
||||
- Added a reviewed one-run path; saving is optional. Name collisions return 409.
|
||||
- New HTTP v2 and schema 4, independently of core API 1.0. Old APIs are not silently
|
||||
accepted with changed semantics.
|
||||
|
||||
## Useful requests for a future core release (NOT implemented here)
|
||||
|
||||
Additive HostSummary group paths would restore subgroup selection. Safe per-host
|
||||
result identifiers and explicitly bounded diagnostic categories could improve
|
||||
progress without raw logs. A separately designed forced Custom authentication mode
|
||||
would need to define native precedence, key/agent/control-socket fallback and
|
||||
approval semantics. None should be recreated in the add-on using private APIs.
|
||||
|
||||
## Qualification status
|
||||
|
||||
The tests use the real uploaded-core machine interface. Native Ansible is absent
|
||||
in this development container: controlled fake native commands verify protocol,
|
||||
result and worker integration only. Real SSH/WinRM, encrypted-key behavior, actual
|
||||
systemd sandbox deployment and reverse-proxy streaming require controller acceptance.
|
||||
See VERIFICATION.md for exact tests and limitations; no old rc9 qualification is
|
||||
claimed as qualification of this new core boundary.
|
||||
@@ -0,0 +1,20 @@
|
||||
> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.
|
||||
|
||||
> Historical core review. Current2.1 behavior is documented in README, API and READ-ONLY-EXPERIENCE; older capability limits below are not current release claims.
|
||||
|
||||
# Review of supplied AIM 3.2.1rc1
|
||||
|
||||
Reviewed archive checksum: `AIM-Ansible-3.2.1rc1.zip.sha256` matched the uploaded ZIP. Core is separately managed and was not modified.
|
||||
|
||||
## Contract adopted
|
||||
|
||||
- Product: AIM 3.2.1rc1; service/wire/event API remains 1.0 / stable_1.x.
|
||||
- Canonical Ansible Core remains 2.19.11.
|
||||
- `capabilities.execution_progress` advertises `summary` and `detail`; WebGUI opts reviewed runs into `progress_mode: detail`.
|
||||
- Detail schema `play_task_host_v1` exposes safety-filtered static play/task labels, host outcomes, fixed failure hints, retries/async polls and per-host recap. Raw stdout/stderr, module arguments/results, rendered labels, paths and variables remain unavailable.
|
||||
- `staging_check` is now a public operation and staging preflight runs before credentials and again before launch. WebGUI treats staging errors as executor deployment/access failures rather than credential failures.
|
||||
- Core 3.2.1rc1 requires a private writable controller staging directory in the executor sandbox. The release-managed executor profile provisions `/var/lib/aim-web-executor/.ansible/tmp`, adds only that path to the writable sandbox set, sets the matching executor HOME, and runs `core-staging-check` as `ExecStartPre`.
|
||||
|
||||
## UI mapping
|
||||
|
||||
WebGUI renders the detail stream into an Ansible-like live view (`PLAY`, `TASK`, host status, fixed hints, recap) but does not claim it is raw Ansible output. The stream remains memory-only and disappears after completion/navigation. Authoritative job outcome remains the Core final result/counters.
|
||||
@@ -0,0 +1,16 @@
|
||||
> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.
|
||||
|
||||
# Review of supplied AIM 3.2.1rc2
|
||||
|
||||
The uploaded SHA-256 sidecar matched the supplied Core archive. AIM Core remains separately installed and managed; this add-on does not modify it.
|
||||
|
||||
## Public additions consumed by WebGUI rc7
|
||||
|
||||
- `inventory_hierarchy_v1`: read-only customer/group/subgroup tree with direct hosts only per node. WebGUI uses Core paths for presentation and expands parent selection from Core-declared descendants, then submits explicit hosts through normal prepare/review.
|
||||
- `target_outcome_summary_v1`: authoritative final requested-target accounting from native Ansible host stats. WebGUI does not infer final host success from task events.
|
||||
- `native_defaults_preflight_v2`: separately covers process/config-home staging and passwd/NSS-home local-connection staging. WebGUI rc7 retains the rc6 release-managed writable paths and hardened systemd sandbox.
|
||||
- Service/wire/event API remains 1.0; detailed progress remains `play_task_host_v1`; raw module output remains unavailable.
|
||||
|
||||
## Presentation boundary
|
||||
|
||||
Core overall execution status remains authoritative. For a mixed result such as 24 successful targets and one unreachable target, Core may correctly return `failed`; WebGUI presents the job as `Partially succeeded` while showing the original Core status/exit code and the per-target facts.
|
||||
@@ -0,0 +1,15 @@
|
||||
> Historical integration basis for WebGUI 2.1.0rc3. For this candidate see [Core rc3 review](CORE-3.3.0RC3-REVIEW.md); historical test counts below are not new acceptance.
|
||||
|
||||
# Core 3.3.0rc1 integration basis
|
||||
|
||||
The separately supplied archive and checksum were verified. The197 source/documentation files are unchanged. Authoritative handoff material is Core ADDON_AGENTS.md and scripts/docs/{ADDON_API,ADDON_SUPPORT,OPERATION_RESULTS,DETAILED_PROGRESS,TARGET_OUTCOMES,INVENTORY_HIERARCHY,EXECUTOR_STAGING,VALIDATION,SANITY,RELEASE_HANDOFF}. The supplied ten standalone documents matched their archived versions during review.
|
||||
|
||||
Core adds operation_results capability, null or schema-resolved catalog result declarations, PreparedRun.result_contract and final RunResult.operation_result. The publisher is aim_output_v1; public wrapper aim_operation_result_v1. The final event and final response are one result. Data arrives at finalization only. Existing API/event1.0, target accounting, hierarchy and dual-home preflight remain.
|
||||
|
||||
WebGUI consumes only the public process boundary. Its consumer independently validates the published schema subset, declaration/review association, report data and response budgets. It never loads playbook schemas from the controller filesystem. Core source fixtures and schema files are used only in disposable release tests. All9 bundled schemas have registered presentation metadata and generic bounded data rendering. No Core source/config/Ansible runtime change is made by the add-on.
|
||||
|
||||
A native exit0 with required output absent/invalid is a result_validation failure. Per-target native success remains distinct, and a native failed run can have useful available reports. Missing response never becomes success from an earlier event. Payload data.complete can have a separate meaning from report-slot complete. Config sections remain an explicit retention opt-in because safe filtering is not a universal secret scanner.
|
||||
|
||||
The operation payload can total16MiB, with1MiB slot bounds. Core private native callback chunks do not imply chunked public JSONL. WebGUI therefore increased only public response frame/line/stream budgets and kept request/private-secret limits unchanged. Reports are stored separately from compact final job facts. Progress journaling is add-on-owned and not a new Core history collector.
|
||||
|
||||
Core's188 recorded upstream local tests are not WebGUI test results. Native Ansible2.19.11, Windows/Linux publishers, global publishers and hardened controller behavior remain acceptance gates. See this release's VERIFICATION.md for observed tests and limitations.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Core 3.3.0rc3 integration review
|
||||
|
||||
This is a source-based review of the user-supplied Core archive, not a native Windows
|
||||
Update qualification. AIM Core remains separately deployed and unmodified.
|
||||
|
||||
## Source basis
|
||||
|
||||
Authoritative Core topics: `ADDON_AGENTS.md`, `AGENTS.md`,
|
||||
`scripts/docs/RELEASE_NOTES.md`, `RELEASE_HANDOFF.md`, `ADDON_SUPPORT.md`, `ADDON_API.md`,
|
||||
`OPERATION_RESULTS.md`, `PLAYBOOKS.md`, `VALIDATION.md`, `SANITY.md`,
|
||||
`scripts/docs/INSTALLATION.md`, and `deploy/README.md`.
|
||||
|
||||
The supplied Core ZIP contains 200 files under `aim-core-3.3.0rc3/`. Its sidecar and
|
||||
ZIP integrity were checked before extraction. Archive hashes and unchanged-source
|
||||
comparison are in this release's verification record.
|
||||
|
||||
Compared with the supplied Core 3.3.0rc1 (the actual previous WebGUI integration),
|
||||
there are three added files: two Windows patch-cycle tasks and the Core installation
|
||||
guide. No files were removed in that comparison. The source-version/metadata,
|
||||
patch runbook/filter/catalog/schema and documentation changed. The semantic catalog
|
||||
difference is confined to `maintenance_patch_os`; eight other reporting schemas are
|
||||
byte-identical. Core's runtime, credentials, service transport, target-outcome,
|
||||
hierarchy and staging implementations are unchanged in this comparison. This is not
|
||||
an assertion that the new patch runbook was executed successfully here.
|
||||
|
||||
## Existing public boundaries retained
|
||||
|
||||
Service/wire/event API remains 1.0. Reports still use `aim_output_v1` publication and
|
||||
`aim_operation_result_v1` final results, with `result_contract` captured at review.
|
||||
Reports arrive at finalization, not as raw debug/stdout. Detailed progress remains
|
||||
`play_task_host_v1`; native target outcomes and the two-home staging preflight remain.
|
||||
No new execute-request field, credential channel, service or filesystem access is needed.
|
||||
|
||||
## New rc2/rc3 patch metadata consumed
|
||||
|
||||
Core's catalog provides reboot delay (minutes, 0..1440), reboot message and the
|
||||
Windows-only `os_patching_rescan_after_reboot` boolean. Its catalog hint is `false`.
|
||||
The WebGUI obtains these options and constraints from public discovery, not a
|
||||
parallel defaults table. Unchanged controls are omitted to preserve inventory/role
|
||||
precedence; a catalog hint is not a resolved effective inventory setting.
|
||||
|
||||
Windows now discovers a deterministic queue, installs one discovered update per
|
||||
native invocation and stops a wave at a reboot boundary. With continuation disabled,
|
||||
an AIM-performed reboot can end a successful run with `continuation_required: true`
|
||||
and `remaining_updates_known: false`. An explicitly reviewed true continuation value
|
||||
allows Core to rediscover after reboot, bounded to 12 cycles. This is within one Core
|
||||
operation, not permission for the add-on to create more jobs.
|
||||
|
||||
A wave finishing without reboot can perform a final read-only search; this does not
|
||||
extend the approved installation queue. When `remaining_updates_known` is true,
|
||||
`pending` is the recorded final discovery only. When false, the WebGUI must not show
|
||||
a pre-reboot queue or zero-length list as the established next-wave state.
|
||||
|
||||
The patch report adds pre/post reboot observations, delay, deferred state and a stop
|
||||
reason (introduced in Core rc2). Windows adds optional continuation, cycle and
|
||||
remaining-update-knowledge fields in rc3. Individual failed updates carry Core's
|
||||
unsigned/hex HRESULT, reason and bounded safe message. `install_not_allowed` is not
|
||||
proof of a pending reboot; `preexisting_reboot_required` is an independent Core
|
||||
preflight observation. The UI displays provided codes; it does not parse fatal text,
|
||||
Windows logs or native error messages.
|
||||
|
||||
## Consumer changes made
|
||||
|
||||
- Qualify exact Core 3.3.0rc3 in adapter/executor/CLI/deployment metadata, while keeping
|
||||
live capability negotiation and version rejection intact.
|
||||
- Surface all catalog-driven patch controls and platform hints, with a review note
|
||||
separating reboot from continuation and preserving explicit true/false vs inherited.
|
||||
- Add a report presentation model for continuation, deferred reboot, pre-existing
|
||||
reboot and bounded-cycle stop conditions. This never changes the job/Core verdict.
|
||||
- Present remaining updates according to the new knowledge flag; keep raw *structured
|
||||
report JSON* available separately, not unrestricted process output.
|
||||
- Preserve historical schemas and data. The same `patch_summary_v1` identifier has a
|
||||
larger closed shape now: newly added reboot fields and failure `message`/hex fields
|
||||
are required where declared. Old jobs render with their recorded schema, never
|
||||
revalidated against today's catalog or backfilled with invented false values.
|
||||
- Retain journal, reports, modal, owner/admin visibility and existing retention limits.
|
||||
|
||||
## Qualification boundary
|
||||
|
||||
Core's current VALIDATION.md records static/filter/schema and disposable deployment
|
||||
checks, not native Ansible 2.19.11/Windows Update/service-sandbox acceptance of rc3.
|
||||
WebGUI test outcomes are recorded independently in VERIFICATION.md. Source tests and
|
||||
synthetic report fixtures do not certify Windows servicing ordering, reboots, pending
|
||||
update state, Server 2012 R2, or every delegated service environment.
|
||||
@@ -0,0 +1,50 @@
|
||||
# Core 3.3.0rc8 integration review
|
||||
|
||||
This is a source/package compatibility review of the user-supplied AIM Core 3.3.0rc8
|
||||
archive against AIM WebGUI 2.1.0rc9. Core remains separately deployed and unmodified.
|
||||
|
||||
## Public contract
|
||||
|
||||
Core remains service/wire/event API 1.0 with the existing detail-progress,
|
||||
inventory-hierarchy, target-outcome and `aim_operation_result_v1` contracts. The nine
|
||||
shipped report schemas remain catalog-driven. WebGUI therefore does not add a private
|
||||
adapter or parse playbook output.
|
||||
|
||||
The release changes the required native Windows collection baseline. Live Core
|
||||
capabilities now advertise:
|
||||
|
||||
```text
|
||||
ansible.windows >=3.8.0,<4.0.0
|
||||
```
|
||||
|
||||
WebGUI 2.1.0rc9 requires that capability declaration. The actual collection remains
|
||||
Core/operator managed and must be visible to the execution identity in the canonical
|
||||
Ansible collection path. Core readiness remains authoritative for the installed runtime.
|
||||
|
||||
## Report deltas
|
||||
|
||||
`patch_summary_v1` is additive: rc8 adds optional `reboot_reasons_before`, a bounded
|
||||
array of `{source, description}` observations from `ansible.windows.win_reboot_info`.
|
||||
Existing required fields and the established patch continuation/reboot semantics remain.
|
||||
Historical reports continue to validate against their recorded result contracts.
|
||||
|
||||
`filesystem_usage_v1` remains schema-compatible, but Windows semantics now describe
|
||||
attached local storage volumes through `community.windows.win_disk_facts`; mapped/network
|
||||
drives are intentionally excluded. WebGUI updates its explanatory note accordingly.
|
||||
|
||||
Core's Checkmk script placement and Windows ACL hardening are runbook behavior, not a new
|
||||
add-on API. WebGUI does not reconstruct those paths, permissions or deployment rules from
|
||||
private source; it renders final structured reports supplied by Core.
|
||||
|
||||
## Patch behavior retained
|
||||
|
||||
The rc4 patch-wave model remains: one native `win_updates` wave per selected categories,
|
||||
AIM-owned reviewed reboot message/delay, explicit opt-in for post-reboot continuation,
|
||||
no automatic replay, and `remaining_updates_known` governing whether a final pending list
|
||||
is authoritative. `install_not_allowed` alone is not treated as proof of a reboot need.
|
||||
|
||||
## Qualification boundary
|
||||
|
||||
This review does not certify native Windows Update, Checkmk ACL changes, collection
|
||||
installation, WinRM/SSH, or the production systemd sandbox. Controller acceptance must
|
||||
use Core rc8's current SANITY/VALIDATION guidance under the actual executor identity.
|
||||
@@ -0,0 +1,66 @@
|
||||
> The behaviors below are retained from2.1.0rc2. Current candidate2.1.0rc9 targets Core3.3.0rc8/schema5 and adds reports/journal described in REPORTS.md and JOURNAL.md. Credential, read-only inventory and OS-permission boundaries here remain unchanged; old version/no-migration statements describe the earlier slice.
|
||||
|
||||
# One-run credentials through core API 1.0
|
||||
|
||||
Core 3.3.0rc8 is authoritative. WebGUI 2.1 does not decrypt Vault or read/export/copy keys.
|
||||
Use native inventory or explicit customer-key loading in New run. Existing usernames,
|
||||
Vault variables and host/group precedence are core/Ansible behavior.
|
||||
|
||||
Custom forced username/password override is NOT exposed by core and was removed
|
||||
from this adapter. A supplied connection_password, when the catalog requests it, is
|
||||
a native default and may be overridden by inventory. It is not password-only testing.
|
||||
Become-password UI, key uploads, cross-job password caching and raw task output are
|
||||
not implemented. Terminal features are not automatically API features.
|
||||
|
||||
## Where to enter a password
|
||||
|
||||
Submit the reviewed job first. With approval disabled it queues directly; otherwise
|
||||
an independent enabled administrator approves it. The running queue worker reserves
|
||||
a slot after local core readiness. Job detail then offers Unlock this run. With JavaScript and native dialog support this opens an in-page modal; its link remains an authenticated full-page fallback. Overview and Jobs also surface your eligible reservations in Needs your attention.
|
||||
Only the requesting account may use this form. All requested fields derive from
|
||||
PreparedRun. A present customer Vault is conservatively required even when the
|
||||
catalog's require_vault flag is false. An encrypted customer key can use an explicit
|
||||
key passphrase or Core's literal vault_linux_ssh_key_passphrase lookup. The grouped Use customer Vault / Enter separately choice appears only for that alternative requirement with a Vault source. A separately required key passphrase is never made optional.
|
||||
|
||||
A reservation without secrets lasts5minutes. After submission, hand-off/preparation/
|
||||
start must fit60seconds; execution has the separate bounded job timeout. An expired
|
||||
or failed attempt does not retain credentials for the next attempt. Scheduled jobs
|
||||
collect secrets only when their time/window/approval and worker are ready.
|
||||
|
||||
## Transport and processing
|
||||
|
||||
Existing verified HTTPS to NPM/backend and loopback final hop are assumed configured
|
||||
by the operator. Dedicated POST bodies, CSRF/origin/session authorization and8KiB
|
||||
body limit remain. Passwords are literal, max2048 UTF8 bytes each, no CR/LF/NUL. No
|
||||
client-side hash substitution. Browser fields clear on navigation and never enter
|
||||
HTMX history/localStorage. Raw body/error logging remains prohibited.
|
||||
|
||||
The web identity sends private bounded local frames to its worker, then to the
|
||||
executor. The executor starts aimctl with a separate inherited secret pipe FD, not
|
||||
stdin request JSON, argv, environment or a password file. Core owns its provider,
|
||||
key agent and native credential helpers. WebGUI does not reinterpret Vault values.
|
||||
|
||||
Python release of references is not guaranteed RAM erasure. Review swap/dumps,
|
||||
proxy request buffering and access to the service accounts. A compromised authorized
|
||||
web process may exercise the local core client authority; this is not tenant isolation.
|
||||
No automatic data/file-permission repair or credential fallback is performed.
|
||||
|
||||
## Qualification
|
||||
|
||||
`aim-web credential-check` now means public capability/authorized metadata checking.
|
||||
It does not test decryption or remote auth and requires no pytest in production.
|
||||
`core-check --customer ... --playbook ... --host ... --key-mode customer` additionally
|
||||
runs documented local readiness. Real SSH/WinRM acceptance remains an operator gate.
|
||||
Use the included disposable test instructions for API integration; fake native
|
||||
fixtures do not certify real Ansible or controller systemd permissions.
|
||||
|
||||
|
||||
## Dialog lifecycle and recovery
|
||||
|
||||
The dialog loads only after an explicit user action. Its form lives outside status/attention polling so typing is not discarded by an HTMX replacement. It shows the frozen customer/playbook/mode and target count. Show/Hide never changes what is submitted, and pasting is not blocked. Escape/Close/Not now clear fields, including visible-password inputs, and return focus without canceling the job. Backdrop taps do not dismiss it. A small visual viewport constrains the dialog's internal scroll area rather than growing the page.
|
||||
|
||||
Only required/supported Core fields are rendered. For the Vault/key alternative, the default sends just the Vault password; Enter separately adds a required key-passphrase field. Switching back clears that field. No source-radio name or extra scope/identity field is sent to the API. A plain HTML form with JavaScript unavailable exposes the optional separate field with its explanation and does not submit disabled source controls.
|
||||
|
||||
The countdown uses the server deadline, not a new five-minute timer on each opening. Polling does not renew it. Submission clears live form values and disables repeat clicks. A 202 accepted response means only that the existing worker claimed the handoff. Core validation and remote authentication happen later. A lost acknowledgement must not cause automatic POST retry: the client locks the form and polls owner-only status. Worker single-claim/session/scope checks remain authoritative across tabs.
|
||||
|
||||
The canonical POST route is `/api/v2/runs/{id}/credentials`; the existing `/api/v2/jobs/{id}/credentials` is kept as an alias. Both use the same five-attempts-per-minute requester throttle and existing private worker socket. `GET /api/v2/runs/{id}/credential-status` is non-secret status only. It never reports a password as correct, requests new work or extends the reservation.
|
||||
@@ -0,0 +1,131 @@
|
||||
# Deployment and recovery - AIM WebGUI 2.1.0rc9
|
||||
|
||||
Target: separately installed AIM Core **3.3.0rc8**, service/wire/event API **1.0**.
|
||||
WebGUI HTTP **v2**, SQLite **schema 5**. From WebGUI 2.1.0rc3 there is no database
|
||||
schema change or new permission/service requirement. This candidate qualifies the
|
||||
new public patch catalog/report shape; it does not upgrade Core itself.
|
||||
|
||||
## Fresh installation
|
||||
|
||||
Use [ADDON-INSTALLATION.md](../ADDON-INSTALLATION.md) after the independently supplied
|
||||
Core `scripts/docs/INSTALLATION.md`. `install` is for a new add-on; `update` is for an
|
||||
existing managed installation. The Core and WebGUI deployers have different flags.
|
||||
|
||||
## Coordinate Core and WebGUI versions
|
||||
|
||||
The previous WebGUI 2.1.0rc4 targets Core3.3.0rc3 exactly; it does not accept Core rc8.
|
||||
Finish active jobs, prevent new submissions and quiesce terminal writers. Cancellation
|
||||
is not rollback. Keep matching Core and add-on backups, including the workflow DB.
|
||||
|
||||
```bash
|
||||
sudo systemctl stop aim-web-worker.service aim-web.service aim-web-executor.service
|
||||
```
|
||||
|
||||
Deploy Core3.3.0rc8 independently with its verified source archive and its own
|
||||
|
||||
**Controller prerequisite:** Core rc8 requires `ansible.windows >=3.8.0,<4.0.0` for Windows playbooks. Confirm it in the canonical collection path under the executor identity; WebGUI does not install collections.
|
||||
preview/apply/quiesced procedure. Do not overwrite Core settings, environments,
|
||||
inventory/Vault/keys or global SSH trust. Review patch-wave changes in Core's release
|
||||
notes and complete separately approved terminal acceptance. A UI release does not
|
||||
certify the new native Windows Update flow.
|
||||
|
||||
Then extract this add-on into a fresh directory, not over the active source:
|
||||
|
||||
```bash
|
||||
cd /var/tmp
|
||||
sha256sum -c AIM-WebGUI-2.1.0rc9.zip.sha256
|
||||
unzip AIM-WebGUI-2.1.0rc9.zip
|
||||
cd aim-web-2.1.0rc9
|
||||
sudo python3 deploy/deploy.py update
|
||||
```
|
||||
|
||||
Ordinary2.x updates do not need --migrate-core. Same-version reinstall is rejected.
|
||||
The installer validates the actual manifest/required files, prepares dependencies and
|
||||
assets, checks public Core access, backs up and activates the release, writes known
|
||||
managed units and waits boundedly for socket readiness. Unknown unit drop-ins require
|
||||
operator review. Core remains unchanged by this updater.
|
||||
|
||||
## State, review and retention
|
||||
|
||||
Accounts, grants, plans, journals, reports and audit remain in schema5. Its five
|
||||
released SQL migrations are unchanged. An older schema4 install follows the existing
|
||||
schema5 migration (pending/queued work blocked, running work interrupted, old reviews
|
||||
removed). A schema5-to5 update does not rewrite job states: old prepared work is still
|
||||
subject to the existing source/revision revalidation and cannot silently execute a new
|
||||
Core revision. Quiesce first and use a fresh review after Core source/schema changes.
|
||||
|
||||
Saved plans remain presets; selecting one requires a fresh review. Historical reports
|
||||
use their stored schema and are not revalidated with the new enlarged patch schema.
|
||||
There is no backfill, terminal-history collection or automatic retry/continuation.
|
||||
|
||||
The full webgui.toml remains release-managed and overwritten with the approved site
|
||||
profile (execution enabled, existing14-playbook allowlist, no independent approval,
|
||||
credential transport attestation). Keep the independently configured Core opt-in.
|
||||
Retention defaults remain:
|
||||
|
||||
```toml
|
||||
[journal]
|
||||
max_events = 20000
|
||||
max_bytes = 8388608
|
||||
[reports]
|
||||
max_bytes = 16777216
|
||||
retain_configuration = false
|
||||
```
|
||||
|
||||
Custom local TOML edits must be incorporated into the reviewed release profile to
|
||||
survive later replacements. Job deletion removes its linked evidence; protected
|
||||
backups and physical-storage erasure have separate operator policies.
|
||||
|
||||
## Verify in the real service context
|
||||
|
||||
```bash
|
||||
aim-web --version
|
||||
aim-web config-check
|
||||
sudo systemctl status aim-web-executor.service aim-web.service aim-web-worker.service --no-pager
|
||||
sudo -u aim-web aim-web core-check
|
||||
sudo journalctl -u aim-web-executor.service -n 60 --no-pager
|
||||
```
|
||||
|
||||
Expected: AIM WebGUI2.1.0rc9 / Core3.3.0rc8. ExecStartPre remains the authoritative
|
||||
staging probe inside the executor's actual sandbox. A plain sudo -u shell lacks its
|
||||
unit-scoped aim-web group and is not an equivalent preflight. Do not loosen config or
|
||||
staging permissions to make the interactive wrapper pass.
|
||||
|
||||
The generated unit contract is unchanged: normal executor primary group plus aim-web
|
||||
supplementary group; web state0700; config root:aim-web0640; executor state and both
|
||||
staging paths0700; runtime directory executor0711; socket executor:aim-web0660;
|
||||
NoNewPrivileges, empty capabilities, ProtectSystem=strict, ProtectHome=read-only with
|
||||
only exact staging write exceptions. No new ports/services/writable paths are needed.
|
||||
|
||||
Start with a safe read-only reporting job and reload its recorded evidence. New native
|
||||
patching/reboot behavior needs Core's disposable-target acceptance, not a production
|
||||
installation used as a browser smoke test. See [PATCH-WAVES.md](PATCH-WAVES.md).
|
||||
|
||||
## Recovery and rollback
|
||||
|
||||
Record the printed /var/backups/aim-web checkpoint. After an interrupted deployment,
|
||||
investigate pending.json and use the same release deployer's recover command; do not
|
||||
manually retarget current symlinks.
|
||||
|
||||
```bash
|
||||
sudo python3 deploy/deploy.py recover
|
||||
sudo python3 deploy/deploy.py rollback --backup CHECKPOINT
|
||||
```
|
||||
|
||||
The commands above are alternative recovery actions, not a sequence to run blindly.
|
||||
An rc5->rc4 add-on rollback stays on schema5, but the older adapter still requires its
|
||||
matched Core version. The deployer tests restored compatibility; an incompatible
|
||||
restoration remains stopped/disabled until the operator separately restores the
|
||||
matching Core and deliberately enables the units.
|
||||
|
||||
Crossing schema5->4 requires --restore-auth-db and an explicit historical database
|
||||
restore. That can reinstate older password hashes and discard later users/jobs/plans/
|
||||
journals/reports; restored sessions are revoked. Back up current data first. Neither
|
||||
product rollback reverses remote installations/reboots or unrelated operator changes.
|
||||
|
||||
## Offline assets
|
||||
|
||||
This is not a full offline dependency bundle. Python and production browser pins are
|
||||
unchanged (Bootstrap5.3.8 and HTMX2.0.10 with SHA384 checks). Existing matching assets
|
||||
can be reused. --wheelhouse and --assets-dir accept independently prepared exact
|
||||
artifacts. No development/test dependency is installed into either product environment.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Reviewed execution - 2.1.0rc9
|
||||
|
||||
AIM Core3.3.0rc8 builds native commands and owns validation, credential preparation, runtime discovery, customer locking, cancellation and authoritative results. WebGUI uses only its public aimctl API1.0 and the existing non-root executor.
|
||||
|
||||
A new run needs review, not a saved plan. Select exact customer/playbook/hosts, declared typed options, check/apply and key mode. Review normalized scope, warnings, credentials and the **declared result contract**. Core source/schema changes invalidate earlier reviews; the worker never silently rebuilds and executes stale scope. Saving remains optional with collision-safe default titles.
|
||||
|
||||
WebGUI execution policy, allowlist, grants, host limits and optional approval apply independently of Core's add-on opt-in. The executor's OS access is not proof of the browser requester's authority. Native inventory precedence is unchanged. Key mode customer requires the canonical owner-only key; key mode none is not forced password authentication.
|
||||
|
||||
The worker performs local readiness before offering the owner-only credential modal. Its five-minute empty reservation and sixty-second post-handoff preparation/start window remain. Supplied values use the existing private channel, never job records, argv, environment or journals. The modal preserves deliberate opening, grouped alternative key source, paste/show controls, field clearing and lost-response reconciliation without an automatic second POST.
|
||||
|
||||
## Progress and results are separate
|
||||
|
||||
1. A bounded structured journal records approved Core metadata independently of viewers. Reopening a running or ended job replays committed events and continues after its durable cursor. IDs correlate tasks/hosts; there is no guessed task total/ETA or future task plan. Raw terminal text and module dictionaries are not retained. See JOURNAL.md.
|
||||
2. Native target outcomes and final Core status/exit remain authoritative. A final event without a final response cannot establish successful completion. A partially successful host population does not rewrite Core's overall failure.
|
||||
3. Purposeful operation reports arrive only at finalization and are separately validated against the reviewed contract. They are retained subject to explicit local limits/policy and fetched lazily. See REPORTS.md. A report can be available for a failed run. Missing/invalid required reports after native exit0 yield Core failed/result_validation while native target stats remain unchanged; this is not a password error and never triggers replay.
|
||||
|
||||
A closed browser is not cancellation. User cancellation stops owned local process groups through Core, not already completed remote changes or independently running asynchronous work. Check mode is not an unconditional no-side-effect guarantee. Trusted playbooks can run controller-local/delegated tasks; both narrow staging exceptions stay enabled.
|
||||
|
||||
Manual retry creates a new reviewed job and fresh credentials. Changes to mode, key handling, hosts or options are not edits to queued work. No automatic retry or recurring schedule is introduced; the existing explicitly UTC one-shot schedule remains.
|
||||
|
||||
Only terminal jobs can be deleted. Deletion removes their lifecycle/idempotency/progress/report records and future history contributions, while keeping a compact audit deletion fact. Saved-plan deletion does not remove existing copied job intent. Protected backups are independently retained; deletion is not a promise of physical erasure. Old jobs are not rerun or reconstructed to populate missing evidence.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Retained execution journal - 2.1.0rc9
|
||||
|
||||
## What is recorded
|
||||
|
||||
The worker captures only projected public Core metadata: job/run/sequence, source UTC time and receipt time, stage, opaque play/task IDs, approved/withheld labels, reviewed logical hosts, result/changed/ignored flags, supported retry/poll information, fixed diagnostic hints and recap counters. Unknown additive payloads, legacy duplicate progress in detail mode, raw stdout/stderr, debug bodies, credential frames and final report data are not journal entries.
|
||||
|
||||
Core labels remain withheld when Core withholds them. A missing host stays null; no inference from a nearby event. A task result can arrive interleaved with another host/task: use IDs, not last-arriving names. The result event records only that it was observed; **the final response** establishes the authoritative result and retained report.
|
||||
|
||||
The normal final Core result, targets and existing lifecycle/audit metadata remain separate. A journal does not become a second execution engine or replay operation.
|
||||
|
||||
## Browser-independent capture
|
||||
|
||||
Capture starts in the execution child after review/claim checks. An open page is not required. A 2,048-entry nonblocking queue feeds batches of up to 128 events with a normal 250 ms flush target. SQLite synchronous FULL transactions publish the event rows, bounded checkpoint and durable cursor together. The writer's busy timeout is 250 ms. Closing tries to drain within 2.5 seconds and waits up to 3 seconds for its thread.
|
||||
|
||||
Those are bounded scheduling/lock budgets, not a guarantee against slow storage or physical failure. A crash can lose queued/uncommitted events. Queue or write failures increment a loss counter on the next possible commit. Persistent storage failure or a killed writer leaves an unclosed capture, shown as interrupted when the job ends. Metadata loss does not establish a task failure or success and never triggers re-execution. If the database cannot persist the final result, the normal workflow cannot certify success from a prior event.
|
||||
|
||||
## Retention and display windows
|
||||
|
||||
```toml
|
||||
[journal]
|
||||
max_events = 20000
|
||||
max_bytes = 8388608
|
||||
```
|
||||
|
||||
The newest tail is retained. Older event rows are removed in the same commit when either limit is exceeded; a visible omission count/range remains. A bounded checkpoint retains last stage/play/task, observed task-start count, up to64 recent task contexts, and up to500 latest logical-host observations. Final Core facts do not depend on journal coverage. Limits are validated in Settings; the byte budget may be64KiB..64MiB and the event budget100..200000.
|
||||
|
||||
The initial page loads200 tail events; API pages allow1..500. The browser keeps at most2,000 displayed records, with a link to the paged timeline. Display pagination never changes retained counts. Large streams are rendered at most once per animation frame. Only the console's scrollTop changes; manual upward scrolling pauses Follow output.
|
||||
|
||||
Job deletion cascades through the journal. No terminal/Core-wide history collection and no shadow archive. Database/backup files stay in existing private storage; deletion is not secure physical erasure or deletion of prior backups. There is no silent age-pruning policy.
|
||||
|
||||
## Reopen, reconnect and authorization
|
||||
|
||||
GET the snapshot/tail, then connect SSE strictly after the committed high-water cursor. Last-Event-ID takes precedence over the initial after query on reconnection. A per-job local cursor and unique(job, Core run, Core sequence) suppress duplicates. Filtered legacy events produce ordinary Core-sequence gaps, not automatic loss claims. Retention gaps are explicit.
|
||||
|
||||
Every read uses existing owner-or-admin job authorization. Every streaming iteration rechecks live session, password-change state and job access. A cursor is not permission. Deleted/inaccessible jobs end the feed and request clearing the view. Two devices read the same committed rows and never directly attach to the executor process.
|
||||
|
||||
When the job ends, SSE drains through the available committed cursor and ends; history remains readable. Worker/service interruption does not resume Ansible. Closing a page does not cancel a job or resend a credential.
|
||||
|
||||
Progress means **last observed activity**, not a total task graph. There is no invented percentage, ETA, list of future tasks or proof of stall from silence. Host observations are not final per-host outcomes. The displayed time is localized while stored values remain UTC.
|
||||
|
||||
## Historical jobs
|
||||
|
||||
Schema migration does not fabricate progress for old jobs. They retain lifecycle and final facts but show detailed history unavailable. No terminal import or automatic rerun fills gaps. A new queued job may show waiting for capture until the execution child starts.
|
||||
@@ -0,0 +1,105 @@
|
||||
> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.
|
||||
|
||||
> Historical major-migration guide for the 1.x-to-2.x architecture. An existing 2.0.0rc8 deployment uses the ordinary 2.1 update in DEPLOYMENT.md; no schema change or migration acknowledgement is needed. Current capabilities are in API.md.
|
||||
|
||||
# Major migration: WebGUI 1.x / rc18 -> WebGUI 2.0 / AIM 3.1
|
||||
|
||||
Read CORE-3.1-REVIEW.md first. This is an explicit major migration. Core and add-on
|
||||
are separate releases with separate backups and rollback decisions.
|
||||
|
||||
## Before downtime
|
||||
|
||||
1. Let active jobs finish; cancel deliberately only if their remote effects are understood.
|
||||
2. Back up the old core using its OWN deployment procedure. Back up the WebGUI's
|
||||
source/config/units/database with its managed deployment checkpoint. Do not reset
|
||||
users or remove /var/lib/aim/webgui.
|
||||
3. Deploy AIM 3.2.1rc2 independently using its included guide. Check terminal AIM first.
|
||||
Do not copy core into the old WebGUI tree or install WebGUI into core's interpreter.
|
||||
4. Choose an existing non-root execution account, normally svc_bf-ansible. It must
|
||||
already satisfy AIM required_group, read its config/inventory/Vault, own each selected
|
||||
customer key 0600, and see native collections. The add-on does not provision these
|
||||
core permissions. `runtime.private_key_owner` does not migrate old keys or switch UID.
|
||||
5. Check aimctl as that account, not merely from a root shell:
|
||||
|
||||
```bash
|
||||
sudo -u svc_bf-ansible /usr/local/bin/aimctl --config /etc/ansible/scripts/aim.yml capabilities
|
||||
printf '%s\n' '{"api_version":"1.0","operation":"list_customers"}' | sudo -u svc_bf-ansible /usr/local/bin/aimctl --config /etc/ansible/scripts/aim.yml request
|
||||
```
|
||||
|
||||
The core config remains operator-owned. Its actual 3.1 settings include
|
||||
`addons.execution_enabled`, `runtime.ansible_playbook` and
|
||||
`runtime.private_key_owner` (NOT the earlier proposed execution_user/runtime_group
|
||||
fields). Configure/qualify those using the core guide. The add-on never edits them.
|
||||
|
||||
The core acquires a stable customer `.aim.lock` during execution. The executor needs
|
||||
access to that lock, or creation permission if it does not exist; a read-only customer
|
||||
directory without an accessible lock is not sufficient. Use the core/operator's
|
||||
permission procedure rather than widening the whole tree from WebGUI.
|
||||
|
||||
## Activation
|
||||
|
||||
Unpack the new ZIP into a fresh staging path and run:
|
||||
|
||||
```bash
|
||||
sudo python3 deploy/deploy.py update --migrate-core
|
||||
```
|
||||
|
||||
The explicit flag acknowledges: schema 4, stopped legacy pending/running work,
|
||||
retirement of old key-export sudo bridge and its known worker capability drop-in,
|
||||
HTTP API v2, a new executor service and release-config replacement.
|
||||
|
||||
The installer stages an isolated WebGUI venv/assets, probes the real public core
|
||||
metadata as the selected executor account, checkpoints old files, stops add-on
|
||||
services, migrates state, replaces source/config/units, then starts executor, web
|
||||
and the opt-in queue worker. It never stops terminal AIM or writes core files.
|
||||
Unknown systemd drop-ins block installation for deliberate operator review.
|
||||
|
||||
## What is preserved
|
||||
|
||||
Users/password hashes/sessions, named admin onboarding, grants, audit, selections,
|
||||
all old job records/events, and all saved plan payloads. Pending/queued old-core jobs
|
||||
become blocked; running ones become interrupted. Their state is not replayed.
|
||||
Historical duplicates in saved-plan names remain separate records.
|
||||
|
||||
Legacy saved plans are reusable INPUTS only: open one, use its New run link and
|
||||
review mode/key handling again. Old Custom credentials cannot silently become native
|
||||
inventory credentials. A new valid review is required; no credentials are migrated.
|
||||
|
||||
## What is retired
|
||||
|
||||
Private core imports, rc18 adapter, command rewriting, private Ansible credential
|
||||
resolver/strategy, sudo key export, CAP_SETUID/CAP_SETGID worker capability grant and
|
||||
raw console interception. Known old helper/sudoers/drop-in files are backed up and
|
||||
removed. There is no need to give aim-web canonical key read access.
|
||||
|
||||
## Rollback
|
||||
|
||||
Schema4 cannot be opened by old schema 3 WebGUI. Downgrading requires the explicit
|
||||
--restore-auth-db flag, with loss of changes since that snapshot and possible
|
||||
restoration of older passwords. Services and config/code/venv must match the snapshot.
|
||||
Restoring a 1.x WebGUI while AIM 3.1 remains installed is NOT a working rollback: the
|
||||
installer restores the files/database but leaves legacy services stopped/disabled.
|
||||
Coordinate an independent core rollback before enabling them. Core is never rolled
|
||||
back by this add-on. Interrupted remote operations are never undone automatically.
|
||||
|
||||
## Unsupported old behavior
|
||||
|
||||
There is no Custom forced credential override or password-only verification in
|
||||
core API 1.0. No raw task/host output. Platform-group selection remains; recursive
|
||||
subgroup paths are unavailable. These limitations are shown in the interface and
|
||||
are recorded for an additive core extension, not bypassed through private access.
|
||||
|
||||
## Executor HOME and host trust
|
||||
|
||||
The release profile sets `[core] home = "/var/lib/aim-web-executor"`. aimctl and
|
||||
native commands use that separate writable HOME, not /root or WebGUI's private
|
||||
SQLite home. The executor remains the configured existing UID; no identity is
|
||||
changed by HOME. Install independently verified SSH host records under
|
||||
the effective SSH UserKnownHostsFile, owned by the execution account, or the already-reviewed system /etc/ssh/ssh_known_hosts policy. Process HOME alone does not select OpenSSH's known_hosts path. Do not blindly
|
||||
trust ssh-keyscan output. Existing per-user collections under the old home are not
|
||||
automatically copied: use the core's documented runtime.ansible_collections_path
|
||||
configuration if required. System collections remain native-core-discovered.
|
||||
|
||||
The shipped systemd profile targets the documented /etc/ansible inventory layout.
|
||||
Nonstandard inventory roots require a separately reviewed ReadWritePaths service
|
||||
profile for core locks; this installer does not inspect private config to infer it.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Patch-wave options and reports - WebGUI 2.1.0rc9 / Core 3.3.0rc8
|
||||
|
||||
This guide describes add-on presentation of the Core-provided patch contract. It does
|
||||
not grant approval to install updates, reboot targets or perform repeated runs.
|
||||
|
||||
## Prepare and review
|
||||
|
||||
New run uses the public catalog for optional inputs. The Windows-only **Continue
|
||||
patching after reboot** control advertises the live catalog hint (false in this Core
|
||||
release). It starts as **Inherit**, not an explicit true override. Blank inputs stay
|
||||
omitted; inventory/role defaults are authoritative. To explicitly forbid continuation
|
||||
in a particular run, choose false and review the normalized override.
|
||||
|
||||
**Reboot when required**, **Reboot delay (minutes)** and **Reboot message** are separate
|
||||
catalog controls. Enabling reboot must not implicitly enable continuation. Delay and
|
||||
message apply only to an AIM-initiated reboot; the message is not part of the report.
|
||||
The review highlights explicit vs inherited reboot, delay and continuation values.
|
||||
Core still revalidates scope/options/schema revision before execution.
|
||||
|
||||
On Windows, each Core patch wave delegates the reviewed update categories to one native
|
||||
`ansible.windows.win_updates` install invocation with module reboot disabled. Windows
|
||||
Update and the collection own ordering inside that wave; AIM evaluates its reviewed reboot
|
||||
policy only after the native wave returns. With post-reboot continuation disabled, the run
|
||||
stops after an approved AIM reboot and another discovery requires a new reviewed run.
|
||||
Enabling continuation explicitly permits Core to rediscover and start another native wave
|
||||
after reboot within the same run, up to its 12-wave safety limit. There is no WebGUI
|
||||
follow-up scheduler or automatic replay.
|
||||
Linux keeps Core's native package-manager behavior and shared reboot-message/delay
|
||||
semantics; Windows cycle fields are not fabricated on Linux reports.
|
||||
|
||||
## Reading a report
|
||||
|
||||
| Field or condition | Meaning in the UI |
|
||||
|---|---|
|
||||
| Core succeeded + continuation_required true | Successful wave, but further patching needs review. The job is not relabeled failed. |
|
||||
| remaining_updates_known false | Remaining updates are not established. Do not show an empty pending list as zero remaining updates or reuse a pre-reboot queue. |
|
||||
| remaining_updates_known true | Pending is the final read-only discovery for the selected scope and recorded time, not current compliance or an expanded install queue. |
|
||||
| No remaining_updates_known field | Historical shape. Missing wave fields stay unestablished; no inferred post-reboot queue. |
|
||||
| reboot_deferred true | A reboot remains required with automatic reboot disabled. Installation success and reboot status remain separate. |
|
||||
| reboot_reasons_before | Bounded native reboot sources reported by `ansible.windows.win_reboot_info` before patching. These are observations from that run, not a live probe. |
|
||||
| blocked_reason preexisting_reboot_required | Core's independent preflight observed a prerequisite reboot; new patch work did not start on that path. |
|
||||
| blocked_reason cycle_limit_reached | Core stopped bounded continuation; a new decision is needed, never an automatic replay. |
|
||||
| failed_updates | Per-update title/ID, unsigned and hex HRESULT, fixed reason and safe message supplied by Core. |
|
||||
| install_not_allowed / 0x80240016 | May indicate an active installer or mandatory reboot; not proof of a pre-existing reboot by itself. |
|
||||
| Check mode | Observations/predictions, never proof of installation or an actual reboot. |
|
||||
|
||||
The normal report summary keeps the pre/post reboot observations, performed/deferred
|
||||
flags, reviewed delay, cycle count and continuation policy visible when supplied.
|
||||
Pending-list display suppression is a presentation decision when Core says the list
|
||||
is not authoritative. It does not modify stored data: the retained structured JSON
|
||||
still provides the exact approved report body for inspection.
|
||||
|
||||
Report-slot `complete` is availability, while payload `data.complete` describes update
|
||||
evidence. Neither independently proves the host is fully patched. Native target
|
||||
outcomes, Core result-validation failures and per-host reports remain separate.
|
||||
|
||||
## Historical data and permissions
|
||||
|
||||
Old reports retain their reviewed schema. No migration rewrites old patch outcomes or
|
||||
adds missing fields. Only retained WebGUI jobs contribute to host history; no terminal
|
||||
run tracking, inventory writes, raw logs or new credential storage are introduced.
|
||||
Report reads remain owner-or-admin and job deletion removes linked evidence. The
|
||||
Checkmk configuration-content retention opt-in is unchanged.
|
||||
|
||||
## Controller acceptance
|
||||
|
||||
Use Core's current SANITY.md under the actual executor context on a disposable,
|
||||
approved target. Confirm native `win_updates` wave behavior, the default stop after an AIM-performed
|
||||
reboot, explicit post-reboot continuation behavior, read-only final discovery,
|
||||
reboot-disabled/pre-existing-reboot cases and a bounded failure record. Compare actual
|
||||
effects and reported fields, not old task counts. Do not deliberately patch or reboot
|
||||
production systems merely to exercise a user-interface feature.
|
||||
@@ -0,0 +1,42 @@
|
||||
> The behaviors below are retained from2.1.0rc2. Current candidate2.1.0rc9 targets Core3.3.0rc8/schema5 and adds reports/journal described in REPORTS.md and JOURNAL.md. Credential, read-only inventory and OS-permission boundaries here remain unchanged; old version/no-migration statements describe the earlier slice.
|
||||
|
||||
# Managed permissions - WebGUI 2.1.0rc1
|
||||
|
||||
No permission change from2.0.0rc8. This document describes the existing add-on-owned contract, not instructions to recursively chown AIM.
|
||||
|
||||
| Resource | Owner/group | Mode |
|
||||
|---|---|---|
|
||||
| WebGUI source, virtualenv, units | root-owned | Release-managed |
|
||||
| webgui.toml | root:aim-web |0640|
|
||||
| /var/lib/aim/webgui |aim-web:aim-web|0700|
|
||||
| SQLite database |aim-web:aim-web|0600|
|
||||
| /var/lib/aim-web-executor and .ansible/tmp chain |executor:native primary group|0700|
|
||||
| passwd-home .ansible and .ansible/tmp |executor:native primary group|0700|
|
||||
| /run/aim-web-executor |executor:native primary group|0711|
|
||||
| /run/aim-web-executor/core.sock |executor:aim-web|0660|
|
||||
|
||||
Site executor is svc_bf-ansible. Systemd preserves its native primary group and grants aim-web as a unit-scoped SupplementaryGroups entry; numeric group IDs may appear in systemctl output. Other account memberships are resolved normally, so an empty explicit supplementary setting is not proof of an empty actual group list. The installer does not silently rewrite OS account memberships.
|
||||
|
||||
The0711 runtime directory permits traversal to the known socket path, not directory listing for unrelated users. Socket DAC and peer checks govern access. NoNewPrivileges and empty capability sets remain; no sudo or root worker. ProtectHome remains read-only with a narrow writable passwd-home .ansible/tmp exception for delegated local tasks, plus the separate process-home staging path. The installer waits for socket readiness and checks exact managed owner/mode before starting dependent services.
|
||||
|
||||
## Verification, not manual repair
|
||||
|
||||
```bash
|
||||
systemctl show aim-web-executor.service -p User -p Group -p SupplementaryGroups
|
||||
stat -c '%U:%G %a %n' \
|
||||
/var/lib/aim-web-executor \
|
||||
/var/lib/aim-web-executor/.ansible/tmp \
|
||||
/home/svc_bf-ansible/.ansible/tmp \
|
||||
/run/aim-web-executor \
|
||||
/run/aim-web-executor/core.sock \
|
||||
/etc/ansible/scripts/config/webgui.toml
|
||||
sudo journalctl -u aim-web-executor.service -n 60 --no-pager
|
||||
```
|
||||
|
||||
The release-managed ExecStartPre runs staging checks inside the real executor unit. Interactive sudo -u svc_bf-ansible alone does not reproduce unit-scoped aim-web group access to webgui.toml. Do not make that config world-readable to hide the distinction.
|
||||
|
||||
## Outside add-on ownership
|
||||
|
||||
AIM source/configuration, authorization groups, inventory/Vaults, canonical owner-only0600 private keys, /etc/ssh/ssh_known_hosts, certificates and Nginx remain Core/operator managed. The add-on does not enroll host keys or infer their trust from HOME. Keep independently verified effective SSH trust. Unknown unit drop-ins stop deployment for review; do not silently restore obsolete privilege/capability workarounds.
|
||||
|
||||
The new explorer, activity and insights pages require no new write path, group, service, port or secret permission.
|
||||
@@ -0,0 +1,96 @@
|
||||
> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.
|
||||
|
||||
# AIM WebGUI 2.1.0rc2 compared with Jenkins, Semaphore UI and Foreman
|
||||
|
||||
## Basis and limits
|
||||
|
||||
This is a documentation-based capability and product-direction comparison, not a hands-on usability benchmark, security audit, licensing quotation or performance comparison. AIM statements refer to the inspected 2.1.0rc2 source and its test evidence. Other product statements refer to the official documentation listed below, consulted for this release. Features can depend on installed plugins, edition and configuration; Foreman examples use the published 3.18 host-management guide without claiming that version is the newest stable release. Recommendations below are design judgments, not measured rankings.
|
||||
|
||||
## The products solve different problems
|
||||
|
||||
**AIM Web** is a focused operator interface over a separately managed AIM Core. It discovers Core-owned customers, hosts, groups and catalog playbooks; prepares explicit reviewed runs; requests transient credentials only when the worker is ready; and shows Core-owned results. It does not own inventory/Vault editing, arbitrary automation code, server provisioning or a general plugin execution ecosystem. Its history covers retained WebGUI jobs only. [A1]
|
||||
|
||||
**Jenkins** is primarily a Pipeline/CI/CD automation platform. Pipeline models multistage work and supports extensible execution through steps and plugins. Its Ansible plugin accepts playbooks, inventories and credential IDs. Treating Jenkins as a direct equivalent of a host inventory system would obscure that pipeline-centric design. [J1, J2]
|
||||
|
||||
**Semaphore UI** is the closest operational comparator: projects combine repositories, inventories, reusable credentials, variables and task templates, with each execution recorded as a task. Its documented scope also includes tools other than Ansible. The user guide documents schedules and workflow-related capabilities, with some capabilities edition-dependent. [S1, S2]
|
||||
|
||||
**Foreman** is broader host lifecycle management, not merely a Puppet runner. It maintains host inventory/group settings and supports provisioning and infrastructure integrations. Its documented remote-execution and Ansible workflows can operate against selected hosts through Smart Proxies; Puppet is one part of that ecosystem. [F1, F2]
|
||||
|
||||
## Functional comparison
|
||||
|
||||
| Area | AIM Web 2.1.0rc2 | Established-product reference |
|
||||
|---|---|---|
|
||||
| Inventory | Current read-only Core hierarchy; linked SVG/outline explorer; customer-scoped host pages | Semaphore manages inventory resources used by templates. Foreman manages hosts, host groups and inherited settings. Jenkins' Ansible plugin consumes inventory files/inline inventory for pipeline execution. [S3, F1, J2] |
|
||||
| Starting work | One-run review without mandatory plan; optional collision-safe saved title; existing independent approval when enabled | Semaphore starts tasks from templates and exposes user prompts. Jenkins offers Pipeline parameters/input steps. Foreman provides host selection and job-template workflows. [S2, J3, F2] |
|
||||
| Credential experience | Owner-initiated modal, Core-required fields, one-run lifetime, no add-on reusable secret store | Jenkins supports stored credentials referenced by IDs. Semaphore has a Key Store for reusable credentials. Foreman job settings include authentication/password and key-passphrase inputs where applicable. These are different operating models, not a security ranking. [J4, S4, F2] |
|
||||
| Output | Core-filtered static play/task/host labels and hints, bounded ephemeral stream; authoritative final per-target outcomes retained with the job | Jenkins' Ansible plugin supports console output; Semaphore documents live/completed logs and a raw-log view. Broader log access is useful for diagnosis but creates a different retention/exposure decision. [J2, S5] |
|
||||
| History | Host Activity and Playbook Insights over authorized retained WebGUI jobs, separating Check/Apply and host/whole-job outcomes | Semaphore exposes task/template history; Foreman is natively host-oriented. Do not equate a job log with an authoritative machine-wide history or claim a feature is absent merely because its documentation was not inspected. [S2, S5, F1] |
|
||||
| Orchestration | Existing queue, bounded targets, optional independent review and one-off UTC scheduling; no workflow DAG or recurring scheduler | Jenkins supports pipeline composition. Semaphore documents cron schedules; its documentation identifies workflows as a Pro feature. Foreman offers remote-job controls through its host-management workflow. [J1, S6, S7, F2] |
|
||||
| Access | Local accounts, customer/playbook execution grants; owner-or-admin job/history access and owner-only plans; not hostile-tenant isolation | Semaphore has project teams and built-in roles, with Enterprise extended permissions. Jenkins credential use is scoped and depends on authorization/plugin configuration. Wider identity deployments need product-specific evaluation. [S8, J4] |
|
||||
| Extensibility | Fixed public Core contract; add-on cannot import private Core managers or rewrite Ansible arguments | Jenkins has a broad Pipeline/plugin model; Foreman integrates host/provisioning components; Semaphore supports several automation applications. Flexibility also increases the scope an administrator must configure and govern. [J1, F1, S2] |
|
||||
|
||||
## What the new modal improves
|
||||
|
||||
The implemented path is now: open an existing reservation, recognize the reviewed customer/targets/mode, enter only the required credentials, submit once, then follow the job. Core-permitted key-passphrase choices use native radio buttons styled as a segmented control. Changing that presentation choice does not change reviewed scope, native inventory precedence or execution identity. [A2]
|
||||
|
||||
This intentionally avoids asking an operator to configure a reusable credential resource just to perform one reviewed run. It also preserves a cost: repetitive or unattended operations are less convenient when credentials must be resupplied. That tradeoff is part of the current requested product boundary, not evidence that all stored-credential products are unsafe. [A2, J4, S4]
|
||||
|
||||
Jenkins' input step demonstrates the value of making pending human input an explicit workflow state. Semaphore's template prompts demonstrate the value of exposing only the options a particular task needs. Our application of those lessons is the new Needs your attention section and Core-driven fields, not importing their wider parameter or credential models. [J3, S2]
|
||||
|
||||
## Where AIM Web is already well aligned with this controller
|
||||
|
||||
The strongest fit is the combination of explicit target review, customer-aware discovery, optional saved plans, per-target final results and linked host activity. Operators can inspect an inventory branch, open a host, find its last retained Checkmk result and return to the source run without moving inventory ownership out of AIM Core. The mobile header and native modal now make that narrower workflow easier to navigate. These are implemented behaviors, not evidence that our UI is universally faster or more accessible than the other products. [A1, A2]
|
||||
|
||||
The history design is unusually explicit about what it does not know: no terminal AIM runs, deleted-job reconstruction, current-health score, inferred installed version or invented success for legacy data. A partially successful parent job does not erase each target's own final outcome. Preserve that clarity as the UI grows. [A1]
|
||||
|
||||
## Where established platforms set a higher bar
|
||||
|
||||
**Operational breadth:** reusable template catalogs, external integration, distributed execution, scheduled orchestration and richer organization models are documented strengths across these platforms. AIM Web does not yet provide comparable breadth, and turning a UI preference into a rushed workflow engine would undo the modularity gained from Core. [J1, S1, S6, S7, F1]
|
||||
|
||||
**Investigative detail:** a retained full log can answer questions our ephemeral, filtered stream cannot. Semaphore explicitly exposes task logs after completion. AIM currently retains final facts, not a full transcript. A future Core-approved retention contract should be considered separately rather than quietly capturing raw stdout because it is convenient. [S5, A1]
|
||||
|
||||
**Release and deployment assurance:** our recent manifest, startup and permission failures remain evidence that packaging and controller acceptance need attention. A passing synthetic suite does not establish production-browser, systemd, SSH/WinRM, upgrade or security qualification. This report does not claim comparable maturity or measure other products' defect rates. [A3]
|
||||
|
||||
**Access administration:** project-scoped teams, federation and larger administrative structures deserve a deliberate design if the audience expands beyond the current controller. Semaphore documents built-in project roles and Enterprise extensions; those are not equivalent to our existing local execution grants. [S8, A1]
|
||||
|
||||
## Security is not a badge comparison
|
||||
|
||||
Jenkins documents encrypted stored credentials and ID-based use; its binding documentation also explains masking limitations and risks from processes sharing execution accounts. This is useful context, not a reason to claim that masking or a modal prevents all disclosure. [J4, J5]
|
||||
|
||||
AIM's transient credential path reduces intentional add-on secret retention, but authorized controller code and service accounts remain trusted. DOM clearing cannot prove physical memory erasure. Core owns execution semantics; an accepted credential handoff does not prove authentication. Foreman/Semaphore/Jenkins have different persistence, identity and deployment choices that require their own configured-environment review. [A2]
|
||||
|
||||
## Recommended direction after this RC
|
||||
|
||||
My recommendation is to borrow interaction patterns, not product scope.
|
||||
|
||||
1. **From Semaphore:** make supported playbook inputs feel like a small, well-labeled task form. Keep preflight and execution semantics in Core. Improve template/saved-plan discovery before adding arbitrary parameters.
|
||||
2. **From Foreman:** strengthen host-centric navigation and contextual actions. Add dated last-result overlays and comparisons of recorded runs, not invented live health or inventory mutation.
|
||||
3. **From Jenkins:** make stage transitions and pending human action unmistakable. Keep cancellation, acknowledgement uncertainty and dependency failures visible without turning every event into a wall of log text.
|
||||
|
||||
None of those follow-on features is claimed shipped in this RC. The immediate release contains the modal and attention surface; targeted retry preparation, history overlays, run comparisons, federation and workflow orchestration remain separate proposals. Reliability and installed-controller acceptance should remain the next gate.
|
||||
|
||||
## Official references and inspected AIM files
|
||||
|
||||
Sources are provided as exact locations so the comparison can be rechecked as products evolve.
|
||||
|
||||
- **A1** - This release: `AGENTS.md`, `docs/READ-ONLY-EXPERIENCE.md`, `docs/API.md`, `src/aim_webgui/activity.py`, `explorer.py`, `workflows.py` and `worker.py`.
|
||||
- **A2** - This release: `docs/RUN-COMFORT.md`, `docs/CREDENTIALS.md`, `credentials/presentation.py`, `credentials/service.py`, `routes/workflows.py`, credential templates and `static/js/credentials.js`.
|
||||
- **A3** - This release: `docs/VERIFICATION.md`, `docs/verification-results.json` and preserved `CHANGELOG.md` provenance.
|
||||
- **J1** - Jenkins Pipeline: `https://www.jenkins.io/doc/book/pipeline/`
|
||||
- **J2** - Official Jenkins Ansible plugin: `https://plugins.jenkins.io/ansible/`
|
||||
- **J3** - Jenkins Pipeline Input Step: `https://www.jenkins.io/doc/pipeline/steps/pipeline-input-step/`
|
||||
- **J4** - Jenkins Using credentials: `https://www.jenkins.io/doc/book/using/using-credentials/`
|
||||
- **J5** - Jenkins Credentials Binding: `https://www.jenkins.io/doc/pipeline/steps/credentials-binding/`
|
||||
- **S1** - Semaphore UI user guide: `https://semaphoreui.com/docs/user-guide`
|
||||
- **S2** - Semaphore task templates: `https://semaphoreui.com/docs/user-guide/task-templates/views` and `https://semaphoreui.com/docs/user-guide/task-templates`
|
||||
- **S3** - Semaphore inventory: `https://semaphoreui.com/docs/user-guide/inventory`
|
||||
- **S4** - Semaphore Key Store: `https://semaphoreui.com/docs/user-guide/key-store`
|
||||
- **S5** - Semaphore Tasks and log retention: `https://semaphoreui.com/docs/user-guide/tasks`
|
||||
- **S6** - Semaphore Schedules: `https://semaphoreui.com/docs/user-guide/schedules`
|
||||
- **S7** - Semaphore documentation index (Workflows Pro): `https://semaphoreui.com/docs`
|
||||
- **S8** - Semaphore Teams and Enterprise RBAC: `https://semaphoreui.com/docs/user-guide/team`
|
||||
- **F1** - Foreman introduction: `https://www.theforeman.org/introduction.html`
|
||||
- **F2** - Foreman 3.18 Managing hosts: `https://docs.theforeman.org/3.18/Managing_Hosts/index-foreman-el.html`
|
||||
- **U1** - User-provided Bootstrap4 button pattern: `https://getbootstrap.com/docs/4.0/components/buttons/#checkbox-and-radio-buttons`
|
||||
- **U2** - Bootstrap5 native check/radio toggle buttons used by this release: `https://getbootstrap.com/docs/5.3/forms/checks-radios/`
|
||||
- **U3** - WAI modal dialog interaction guidance: `https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/`
|
||||
@@ -0,0 +1,46 @@
|
||||
> The behaviors below are retained from2.1.0rc2. Current candidate2.1.0rc9 targets Core3.3.0rc8/schema5 and adds reports/journal described in REPORTS.md and JOURNAL.md. Credential, read-only inventory and OS-permission boundaries here remain unchanged; old version/no-migration statements describe the earlier slice.
|
||||
|
||||
# Read-only experience - 2.1.0rc1
|
||||
|
||||
## Mobile header
|
||||
|
||||
At <=760px the top bar is one row: AIM logo/home shortcut left, light/dark sun/moon segments to the left of the hamburger at the right edge. Navigation and account actions open in a native details dropdown beneath it. Escape returns focus to the hamburger; outside clicks, navigation and desktop resize close it. No-JavaScript details navigation remains available. There are no swipe rails or arrow instructions. Above760px the desktop sidebar remains.
|
||||
|
||||
## Inventory Explorer
|
||||
|
||||
Open Inventory explorer from navigation, then select a customer. Core's current hierarchy and flat host metadata are fetched for that request only. Desktop starts with a deterministic linked SVG map; phones start with the equivalent outline. Map/Outline links switch representation. The map shows the current branch, at most12 immediate subgroups and up to3 direct host links per subgroup. Open a group to drill down. Up to24 direct hosts are listed per page. Search pages have50 results. These display limits never change execution targets or summary totals.
|
||||
|
||||
Each group uses its full Core path, not just the leaf label. Direct customer-root hosts are shown. Repeated membership is valid; total group/root host counts use distinct logical names. A host links to one customer-scoped activity page regardless of how many branches contain it. Map lines are inventory memberships, not network links or dependencies. Empty groups and no direct members are explicit.
|
||||
|
||||
Zoom buttons and internal scrolling are optional conveniences; all nodes also have ordinary links and the outline view. A graph click never prepares or executes a job. Current inventory failures show an error, not an invented empty or offline graph. There is no persisted secondary inventory, force simulation or remote discovery. Historical outcome overlays on graph nodes are deferred; the activity link supplies dated results.
|
||||
|
||||
## Host Activity
|
||||
|
||||
Identity is `(customer, exact logical hostname)`, not a machine UUID. Current membership/platform/address is read from Core separately from history. A removed/renamed host can retain history without implying it is still targetable; no automatic merging occurs. Core outages show a current-metadata-unavailable banner while authorized retained history remains usable.
|
||||
|
||||
The page offers mode, rolling time range, playbook and target-outcome filters; playbook summaries, a25-record timeline, expandable numeric target counters and the viewer's own saved plans containing the exact hostname. A successful target remains successful even if the whole job partially succeeded. Link to the source job for overall status, Core exit and reviewed scope.
|
||||
|
||||
## Playbook Insights
|
||||
|
||||
The matrix shows the latest matching record per customer/host/playbook, with timestamp, mode and source-job link. Mobile renders host cards instead of compressing the matrix. Matrix pages have20 hosts and up to12 playbook columns; larger catalogs require filtering and disclose omitted columns. Statistics cover all matching retained records, not only the visible rows or the100-job overview. Outcome filtering means latest *matching* outcome, not necessarily latest run; the page labels that distinction.
|
||||
|
||||
## Exact data and metric scope
|
||||
|
||||
- Only jobs executed/tracked by this add-on and still retained in its workflow database contribute. No terminal AIM history, Core-wide history, scan, agent or second event collector is added.
|
||||
- Each distinct requested host contributes at most one sample per job. Group appearances, SSE reconnects and task counts do not create extra samples. Retries are separate jobs/attempts.
|
||||
- Owner-or-admin job visibility is applied in SQL before data is read/aggregated. Saved plans stay owner-only even for administrators. Filters, cells and totals obey the same scope.
|
||||
- Apply mode is the default. Check is separate; All explicitly combines labeled records. Check results are never evidence of installed changes. Rolling7/30/90/365days and All retained are available. The time axis uses finished_at or, when absent, created_at; all timestamps stay UTC internally.
|
||||
- Success rate = successful / (successful + failed + unreachable). The denominator is displayed. Not started, indeterminate, missing/legacy detail and unfinished jobs are counted separately. A zero denominator displays no rate.
|
||||
- Final outcomes come from valid Core target summaries whose host set matches the stored reviewed targets. Invalid/missing legacy facts become Detail unavailable. A nonterminal database job is Not finished even if a final response is in flight.
|
||||
- Changed values are task counts. The derived metric says host/run samples reporting changed tasks, not changed hosts. No per-host duration is inferred from job duration. No live-health, compliance or installed-version score.
|
||||
- Deleting a job removes its contribution immediately on the next query. Audit deletion events are not enough to recreate per-host outcomes and are not used to do so. No shadow results archive or materialized analytics table exists.
|
||||
|
||||
## Read services and performance
|
||||
|
||||
`activity.py` performs a consistent SQLite read snapshot, streams all matching job rows and builds only safe presentation records. Output records and matrix are paginated; all-history aggregation cost remains linear in matching retained job data. Customer/playbook/mode/time/owner predicates run in SQL. Distinct host/playbook cells are retained in memory for latest-result projection. This is suitable for the measured candidate scale, not an unbounded analytics claim. The optional synthetic benchmark is in `tests/benchmark_read_history.py`; consider indexed/materialized projections only after measured need, with deletion and authorization parity.
|
||||
|
||||
`explorer.py` performs read-only public hierarchy/host requests and computes presentation geometry; `read_views.py` registers GET routes. There is no credential/prepare/execute call or extra executor operation for these pages. UI state is request-local except non-sensitive existing theme preference. No browser inventory/history storage is added.
|
||||
|
||||
## Deliberately not in this slice
|
||||
|
||||
No saved-plan edits or inventory/Vault management, host probes, terminal-history tracking, raw output retention, automated retry or scheduling changes. The graph is branch-focused, not a full unlimited topology canvas. Account-synced density/view preferences and graph last-result overlays can follow later after this candidate is qualified.
|
||||
@@ -0,0 +1,62 @@
|
||||
# Operation reports - 2.1.0rc9 / Core3.3.0rc8
|
||||
|
||||
Core's live `operation_results` capability, catalog result declaration and prepared result_contract are validated and preserved with review. Core's public protocol is `aim_operation_result_v1`; its publisher convention is `aim_output_v1`. The API remains1.0 and no new execute flag/schema path/report body is supplied by the browser.
|
||||
|
||||
The recorded contract, not a newly fetched catalog schema, governs historical rendering. Schema changes stale preparation. No private Core imports, local inventory parsing or external schema/$ref execution is added. An independently implemented consumer validates the documented bounded JSON-schema subset. Unknown additive wrapper fields are discarded rather than stored. Unknown report identifiers using the supported schema language get a generic renderer; unsupported protocols/languages fail explicitly.
|
||||
|
||||
## Three independent facts
|
||||
|
||||
1. Core status/stage/native exit and remote_work_may_have_started.
|
||||
2. Native per-target outcomes from the final Core stats.
|
||||
3. Report-slot availability and local retention.
|
||||
|
||||
Native exit0 plus a missing required report remains **failed/result_validation/exit0**, even when all native targets are successful. An existing failure can contain useful available reports. Complete report slots do not prove execution success. No automatic retries occur; already applied changes are not rolled back. Reports require the final response; an observed final event alone is not enough.
|
||||
|
||||
Only available slots render data. Missing, withheld, invalid, not_started and indeterminate have data:null and never become zero/false/empty reports. Null versions remain unknown. Slot errors are fixed nullable codes, not arbitrary exception messages. Native target metrics in Host Activity keep their existing denominator and meaning.
|
||||
|
||||
## Views
|
||||
|
||||
| Schema | Presentation and meaning |
|
||||
|---|---|
|
||||
| host_capabilities_v1 | Eight Yes/No facts, not current inventory membership or live health. Missing is not No. |
|
||||
| filesystem_usage_v1 | Mount/drive table, observed byte counts and utilization, explicit unavailable/null. Mapped drives remain WinRM-session scoped. |
|
||||
| event_log_export_v1 | Channels, time window and target file paths; no browser download/file-read capability. Check mode reports no completed export. |
|
||||
| service_start_summary_v1 | Before/eligible/attempted/excluded/after facts and fixed failure reasons. Excluded is not a failed start; observed running does not prove sole causation. |
|
||||
| patch_summary_v1 | Linux net package/version-set changes or Windows update IDs/KBs, installed/pending/failed and reboot evidence. data.complete is separate from report complete; not an exhaustive transaction log. |
|
||||
| managed_cleanup_preview_v1 | Candidate versus actual removed managed files, with mode prominent. No unknown-file purge. |
|
||||
| checkmk_user_config_v1 | Parsed/redacted configuration or default metadata subset, not raw YAML/comments. Redacted markers are not absent settings. |
|
||||
| checkmk_agent_state_v1 | Observed installation/version/source, services and managed changes. Do not infer version from an MSI filename. |
|
||||
| checkmk_agent_config_v1 | Named section/file/check changes; not raw field diffs or a count of untouched unknown files. |
|
||||
|
||||
All nine have schema-keyed titles/semantic notes, scalar fact cards, bounded array/object sections and an escaped JSON alternative. Collection sections paginate at50 entries. Nested long values are visibly shortened in tables; the separately loaded retained JSON is not truncated. Unknown supported schemas/global scope have generic rendering. Core ships no global operation; its native qualification is separate.
|
||||
|
||||
Reports are available **when Core finalizes**, not while a publisher task is merely running. Job sections link Summary/Progress/Targets/Reports. The report page shows host, mode, recorded time, source job, execution verdict, availability and retention. Host Activity links the latest20 authorized report references for its exact customer/host across all dates and modes, separately from history filters. No current-state overlay or inventory update is implied.
|
||||
|
||||
## Persistence and confidentiality
|
||||
|
||||
```toml
|
||||
[reports]
|
||||
max_bytes = 16777216
|
||||
retain_configuration = false
|
||||
```
|
||||
|
||||
Report bodies live in job-linked tables, not the ordinary jobs.core_result payload used by status polls and analytics. The worker atomically records the compact final result and report metadata/data once. Each report read is authorized owner-or-admin, with lazy one-slot JSON retrieval. Paths/URLs remain text and never become arbitrary downloads or commands. HTML/Rich-looking strings are escaped. No browser data storage or raw-body logging.
|
||||
|
||||
The default retains validated ordinary reports, bounded by the reviewed slot cap (up to1MiB) and16MiB Core/add-on per-run caps. Lower local caps skip whole bodies with not_retained_limit rather than cutting JSON while claiming validity. Original Core availability remains separate from local retention.
|
||||
|
||||
For checkmk_user_config_v1, **full sections are NOT retained by default**. The metadata_only subset contains path, exists, size_bytes, last_write_time_utc, redacted_paths and comment_preservation. That subset is explicitly labeled, not claimed as a full schema payload. Set retain_configuration=true only after approving the extra data-retention exposure and restart/reload the relevant services; release-managed config replacements require re-review of that preference. It applies to newly finalized runs and cannot restore prior omitted sections.
|
||||
|
||||
Core filtering is not a universal secret scanner. Operational reports can disclose configuration choices. Keep private database and backup permissions, HTTPS, session/RBAC and operational source trust. Supplied secrets are checked again during public-report validation. No arbitrary debug/module output, invocation, environment or passwords are added.
|
||||
|
||||
Delete a job -> its report and journal rows disappear. Audit holds only the deletion fact. No separate archive; protected backups have their own operator retention policy. No backfill from terminal history.
|
||||
|
||||
## Transport budget
|
||||
|
||||
Large **public responses** use128MiB JSONL-line,512MiB total-process-output and32MiB canonical UTF-8 executor-frame bounds; non-execute metadata lines are bounded at32MiB. These finite transport ceilings accommodate encoding/wrappers and duplicated final event/response, not a license for report payloads beyond Core's1MiB/slot and16MiB/run limits. Structural decoding rejects excessive nesting, duplicate keys and non-finite numbers. The consumer revalidates data and reviewed target/mode/schema association. Torn/oversized responses never become partial valid JSON or success.
|
||||
|
||||
Request/secret boundaries are unchanged: normal browser bodies64KiB, credential bodies8KiB, private secret frames bounded, per-value WebGUI2048UTF-8 bytes and the existing Core credential FD. Increasing response capacity did not increase secret lifetimes, password sizes or inbound command authority.
|
||||
|
||||
|
||||
## Core rc8 patch-wave extensions
|
||||
|
||||
See [PATCH-WAVES.md](PATCH-WAVES.md) for reboot-before/after/deferred/delay fields, Windows continuation/cycle reporting, remaining-update knowledge, and supplied unsigned/hex HRESULT/reason/message fields. The patch view explains these facts without changing the Core/job verdict. Pending is not shown as a final remaining-update list when Core explicitly reports remaining_updates_known=false. Structured JSON remains available; no report data is rewritten. Old reports retain their recorded contract and missing optional values are never backfilled.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Roadmap after2.1.0rc9
|
||||
|
||||
Implemented candidate: Core3.3 reports/contract transport, schema5 retained metadata journal and job-bound report storage, reconnect/reload/multi-view replay, dated Host Activity report references and conservative configuration retention. All existing read-only/mobile/modal/workflow features remain.
|
||||
|
||||
Next gate is controller acceptance and bug fixes, not expanded execution authority. Qualify real Ansible2.19.11 publishers, report semantics and both staging locations inside installed services; browser pinned assets/HTMX/SSE/mobile keyboard; recover/rollback; load/backups and deletion policy. See VERIFICATION and CONTROLLER-PILOT.
|
||||
|
||||
Later independently approved UI work: problem-target filters, comparison of two retained host reports, optional dated map overlays, density/view preferences, and richer presentation driven by future supported schemas. Current reports are finalization-only. Do not invent live reports, monitoring/current compliance, terminal-wide history, private Core reads, arbitrary Ansible args, automated replay or a second credential store.
|
||||
@@ -0,0 +1,43 @@
|
||||
> The behaviors below are retained from2.1.0rc2. Current candidate2.1.0rc9 targets Core3.3.0rc8/schema5 and adds reports/journal described in REPORTS.md and JOURNAL.md. Credential, read-only inventory and OS-permission boundaries here remain unchanged; old version/no-migration statements describe the earlier slice.
|
||||
|
||||
# Run comfort - AIM WebGUI 2.1.0rc2
|
||||
|
||||
## Scope
|
||||
|
||||
Based on the working 2.1.0rc1 read-only release, targeting separately managed AIM Core3.3.0rc3/API1.0. This is a user-interface enhancement to the existing one-run credential path, not a password store, new authentication mode or execution engine. SQLite4, WebGUI HTTPv2, Core detail/outcome/hierarchy/staging contracts and release-managed permissions remain unchanged.
|
||||
|
||||
## Open without leaving the job
|
||||
|
||||
When the worker is ready, the job owner selects **Unlock this run** on Job detail or **Unlock run** in Needs your attention. A native modal opens over the current page, with the reviewed playbook/customer, target count and Apply/Check mode visible. It does not open automatically, move the user into a new window, or focus a password field without a deliberate action. The title gets initial focus so opening on a phone does not immediately summon the keyboard.
|
||||
|
||||
The form is fetched lazily and is not part of the HTMX-polled job or attention region. Refreshing those regions does not erase typing. Tab/Shift+Tab stay inside the dialog; Escape or the explicit Close button dismisses it and returns focus, even when polling replaced the original trigger. A backdrop tap is ignored to avoid accidental loss of input. The viewport-bounded body scrolls internally and responds to visual-viewport resize. The full-page link still works without JS or dialog support, and also when deliberately opened in another tab.
|
||||
|
||||
## Use only the fields Core requires
|
||||
|
||||
Vault-only jobs show one password field. Each input has a persistent label, Required/Optional text, Show/Hide button and Caps Lock hint. Paste is supported; the app neither stores values in browser storage nor disables a user's deliberate password-manager use. These are infrastructure passwords, not MFA/one-time-code inputs.
|
||||
|
||||
When the requirements contain both `vault_password` and `ssh_key_passphrase_or_customer_vault_value`, a native radio-button group styled as buttons offers **Use customer Vault** (default) and **Enter separately**. Choosing the latter reveals a required key-passphrase field; returning to Vault clears/disables it. When a key is explicitly required by Core, the field stays required and the alternate-source toggle is not offered. A requested connection password is labeled a default, since native inventory precedence still applies. No Vault/Custom credentials switch, forced account override, become field or private-key upload is added.
|
||||
|
||||
The user's Bootstrap4 grouped-radio example was used as visual inspiration. Implementation uses existing Bootstrap5 `btn-check` inputs with associated labels and native radio semantics, not Bootstrap4's button plugin or jQuery. Theme tokens and focus contrast remain in the established design system.
|
||||
|
||||
## Submission and deadlines
|
||||
|
||||
The timer is synchronized to the server's existing reservation deadline and advances from a monotonic browser clock. Opening, polling and typing do not extend the five-minute window. An amber near-expiry notice is displayed once; the timer is not announced every second. POST validation, not the client timer, controls eligibility. Handoff/start keeps its existing 60-second bound.
|
||||
|
||||
Submit clears the live DOM values (including revealed text inputs), disables repeat interaction and sends only supported credential fields in the authenticated/CSRF-protected JSON POST. The confirmation says **handoff accepted**, not password verified. Core validates Vault/key/connection details later, and the user can close the dialog to follow the existing job output. Closing is not a job cancellation.
|
||||
|
||||
If the HTTP response is lost or uncertain, credentials are cleared and the form locks. It reads owner-only job status rather than resending the password automatically. Reopening that job on the same page preserves only the uncertainty marker/job ID, never secrets. The worker's existing atomic claim prevents reuse; refreshing a page is not a way to replay a claimed handoff. A 400 field-validation failure can allow another explicit corrected submission; throttles, revoked permission, expiry and ended jobs remove the input opportunity. No error echoes credential values or raw Core exceptions.
|
||||
|
||||
Clearing references is not physical memory erasure. The browser, network stack and operating system may have other transient copies. Infrastructure administrators must still manage TLS, proxy buffering/logging, dumps, swap and the trust of service identities.
|
||||
|
||||
## Needs your attention
|
||||
|
||||
Overview shows up to eight actionable jobs; Jobs shows up to100 and discloses any remaining total. The query scans current actionable jobs rather than only the newest100 history entries. Your own live credential reservations come first. Administrators see other owners' jobs needing independent approval as review links, not automatically approved jobs and not another requester's credential form. Ended/expired/canceled jobs leave the action list. Ordinary failed jobs stay in history rather than masquerading as pending input.
|
||||
|
||||
## Retained functionality
|
||||
|
||||
Inventory map/outline, Host Activity, Playbook Insights, mobile hamburger/theme controls, customer-scoped histories, one-run review, unique saved-plan names, partial-result presentation, manual fresh retry and terminal-only deletion remain. History continues to include only retained WebGUI jobs. No terminal Core history, inventory writes, secrets cache or live host probing is introduced.
|
||||
|
||||
## Operator acceptance
|
||||
|
||||
Use a disposable authorized job and test both Vault-only and a customer-key requirement. Verify fields against Core, focus/keyboard/mobile viewport behavior, a live HTMX refresh while typing, close/expiry/revocation clearing and an accepted handoff followed by the actual run. Test an ambiguous response only on a safe disposable operation and confirm no automatic POST repetition. Verify fallback form and owner/admin policy. Source/browser fixture evidence and untested production boundaries are in VERIFICATION.md.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Security boundaries - 2.1.0rc9
|
||||
|
||||
Preserve the established web/auth/queue/executor separation: non-root web and existing non-root executor, fixed Core executable/config, Unix peer checks, normal service groups, both narrow staging exceptions and no new sudo/capability/key-export path. This is a trusted-controller execution service, not a hostile-tenant or malicious-playbook sandbox.
|
||||
|
||||
Argon2id, opaque server sessions, Secure/HttpOnly/SameSite cookies under HTTPS, CSRF/origin/trusted-proxy policy, throttles, current grants, explicit scope/revision review and last-admin checks remain. One-run credentials are collected only for the owning reservation and travel via private frames/FD. No password in job data, reports, journal, browser storage, logs, argv, environment or files. Keep existing deadlines, no automatic retry/POST replay and honest handoff-accepted wording. Reference cleanup is not physical memory erasure.
|
||||
|
||||
## Approved persistence boundary
|
||||
|
||||
This release intentionally replaces ephemeral-only progress with a **bounded structured journal**. It does not store raw Ansible stdout/stderr, debug values, rendered terminal transcripts, invocation/module dictionaries or decrypted Vault data. Only validated public detail metadata/fixed hints is retained; unknown additional event fields are dropped. Core's withheld labels/hosts remain withheld. A rejected/missing final response cannot be promoted from an earlier event.
|
||||
|
||||
Operation reports are explicitly declared Core data, not automatically harmless content. Validate the recorded public schema, request host/mode association, scope, limits and availability. Supplied-secret checks are defense in depth. Static labels and unknown configuration values can still disclose information; Core filtering is not universal secret detection. Full parsed Checkmk sections therefore require explicit retention opt-in, defaulting to availability/file/redaction metadata only.
|
||||
|
||||
All replay/report reads and statistics enforce the same owner/admin access as jobs; plan references remain owner-only. Session/job access is rechecked during streams. Cursors are not bearer authorization. Auth revocation ends live views; already displayed/downloaded/copied information cannot be recalled from a user.
|
||||
|
||||
Only textContent/escaped templates render report strings. No arbitrary URLs, file downloads, source paths, HTML/Rich markup, schema references or executable validators are followed. JSON is bounded and fetched one slot on demand. No report/graph/history data is placed in browser localStorage. Copy JSON is a deliberate user clipboard action, not an automatic export.
|
||||
|
||||
Delete a job -> remove journal/report rows and its statistical contribution; leave only compact audit deletion metadata. No shadow archive. Protected backups, browser transient memory, SQLite free pages and storage remnants require independent operator policy; deletion is not certified erasure. Audit is local, not tamper-proof.
|
||||
|
||||
## Failures and qualification
|
||||
|
||||
Core verdict, native target stats, report availability and journal coverage remain distinct. Native exit0/result_validation is not success and must not auto-replay. Queue overflow or journal write loss does not independently prove task failure. An interrupted stream remains unknown where Core cannot establish a final result.
|
||||
|
||||
No native/systemd/proxy/browser-security qualification is claimed from source fixtures. See VERIFICATION.md and run CONTROLLER-PILOT.md with approved disposable scope. Maintain native Ansible2.19.11, Core's declared dependency range, validated TLS/global SSH trust and current operational-source review.
|
||||
@@ -0,0 +1,57 @@
|
||||
# Verification - AIM WebGUI 2.1.0rc9
|
||||
|
||||
Date: 2026-09-22. Target: independently managed AIM Core **3.3.0rc8**, public
|
||||
service/wire/event **1.0**; WebGUI HTTP **v2**; SQLite **schema 5**.
|
||||
|
||||
## Scope
|
||||
|
||||
This candidate reconciles the add-on release surface with the supplied Core 3.3.0rc8
|
||||
archive and packages the result as 2.1.0rc9. It does not claim native Windows/Linux or
|
||||
production-systemd acceptance merely because local source/contract checks pass.
|
||||
|
||||
The supplied Core ZIP SHA-256 observed during this build is:
|
||||
|
||||
```text
|
||||
76733be206b14c8a822126dfdd67ee3ad3667cdb88d3db925dd57859dd322ea0
|
||||
```
|
||||
|
||||
No independent publisher sidecar was supplied, so this is an observed digest rather
|
||||
than a publisher-authentication claim. ZIP extraction/integrity succeeded.
|
||||
|
||||
## Contract findings checked
|
||||
|
||||
- Core rc8 reports product version `3.3.0rc8` and service/wire/event API `1.0`.
|
||||
- Live capabilities advertise `collection_baselines.ansible.windows` as
|
||||
`>=3.8.0,<4.0.0`; WebGUI requires that declaration and does not manage collections.
|
||||
- Existing public detail-progress, inventory-hierarchy, target-outcome, staging and
|
||||
structured operation-result contracts remain the integration boundary.
|
||||
- `patch_summary_v1` accepts rc8's additive optional `reboot_reasons_before` data while
|
||||
historical report contracts remain independently validated.
|
||||
- No WebGUI database migration, Core mutation, new privilege bridge or private Core
|
||||
import is introduced by rc9.
|
||||
|
||||
## Automated evidence observed for rc9
|
||||
|
||||
- Python compilation of `src`, `tests` and `deploy`: **passed**.
|
||||
- `tests/test_deployment_v2.py`: **10 passed**.
|
||||
- `test_core_contract.py::test_real_core_capabilities_and_customers` against the supplied
|
||||
rc8 tree: **1 passed**.
|
||||
- Targeted rc8 patch checks completed before the bounded native-finalization fixture:
|
||||
public catalog/options and new-report-schema/old-Core-gate checks **passed**.
|
||||
- The full `test_core_rc8_patch.py` file and the release-wide bounded runner did not
|
||||
complete inside this execution environment's command window. Their interrupted runs
|
||||
are **not** counted as passes and no rc4/rc5 test totals are carried forward.
|
||||
|
||||
The final extracted rc9 ZIP is verified with the release's own `deploy.verify_release`
|
||||
manifest checker before delivery.
|
||||
|
||||
## Not qualified here
|
||||
|
||||
This build does **not** establish production installation of
|
||||
`ansible.windows >=3.8.0,<4.0.0`, native `win_reboot_info`, Windows Update, Checkmk ACL
|
||||
normalization/script placement, real WinRM/SSH, reboot behavior, production proxy/CSP/
|
||||
HTMX/EventSource traffic, or the actual systemd sandbox.
|
||||
|
||||
Core rc8's current SANITY/VALIDATION guidance remains the operator acceptance source.
|
||||
Use a low-risk reporting operation first, then qualify Windows patching and changed
|
||||
Checkmk workflows separately on approved disposable targets.
|
||||
@@ -0,0 +1,64 @@
|
||||
{
|
||||
"release": "2.1.0rc9",
|
||||
"core": "3.3.0rc8",
|
||||
"core_service_api": "1.0",
|
||||
"http_api": 2,
|
||||
"database_schema": 5,
|
||||
"core_archive_sha256": "76733be206b14c8a822126dfdd67ee3ad3667cdb88d3db925dd57859dd322ea0",
|
||||
"automated_tests": {
|
||||
"python_compilation": {
|
||||
"status": "passed",
|
||||
"paths": [
|
||||
"src",
|
||||
"tests",
|
||||
"deploy"
|
||||
]
|
||||
},
|
||||
"completed": [
|
||||
{
|
||||
"test": "tests/test_deployment_v2.py",
|
||||
"passed": 10,
|
||||
"failed": 0
|
||||
},
|
||||
{
|
||||
"test": "tests/test_core_contract.py::test_real_core_capabilities_and_customers",
|
||||
"passed": 1,
|
||||
"failed": 0
|
||||
},
|
||||
{
|
||||
"test": "tests/test_core_rc8_patch.py::test_rc8_public_catalog_options_not_hardcoded_defaults",
|
||||
"status": "passed"
|
||||
},
|
||||
{
|
||||
"test": "tests/test_core_rc8_patch.py::test_new_report_schema_and_old_core_gate",
|
||||
"status": "passed"
|
||||
}
|
||||
],
|
||||
"interrupted_not_counted": [
|
||||
"full tests/test_core_rc8_patch.py run",
|
||||
"release-wide tests/run_release_tests.py run",
|
||||
"test_real_core_rc8_patch_finalization_through_fake_native in combined targeted run"
|
||||
],
|
||||
"native_managed_hosts_tested": false
|
||||
},
|
||||
"contract": {
|
||||
"core_version": "3.3.0rc8",
|
||||
"api_version": "1.0",
|
||||
"collection_baseline_ansible_windows": ">=3.8.0,<4.0.0",
|
||||
"detail_progress_schema": "play_task_host_v1",
|
||||
"inventory_hierarchy_schema": "inventory_hierarchy_v1",
|
||||
"target_outcome_schema": "target_outcome_summary_v1",
|
||||
"staging_profile": "native_defaults_preflight_v2",
|
||||
"operation_result_protocol": "aim_operation_result_v1"
|
||||
},
|
||||
"final_archive": {
|
||||
"manifest_verified": true,
|
||||
"archive_sha256": null
|
||||
},
|
||||
"limitations": [
|
||||
"No native managed-host qualification",
|
||||
"No real systemd installation or recovery",
|
||||
"No production browser HTTPS/CSP/cookies/proxy/HTMX/SSE acceptance",
|
||||
"Full release suite did not complete within the execution environment command window"
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user