admin_rb
50 lines
3.4 KiB
Markdown
50 lines
3.4 KiB
Markdown
# AIM 3.3.0rc8 support matrix
|
|
|
|
Service/wire/event 1.0 is stable and additive. Implementation status and controller
|
|
qualification are different. Use live capabilities; the JSON file alongside this guide
|
|
is only a default capability snapshot. [VALIDATION.md](VALIDATION.md) is the sole current
|
|
evidence record.
|
|
|
|
| Capability | Implementation | Activation/qualification |
|
|
|---|---|---|
|
|
| Discovery/catalog/explicit prepare | Supported | Required OS group/filesystem access |
|
|
| Inventory hierarchy v1 | Supported, read-only | No independent inventory semantics in add-ons |
|
|
| Staging preflight v2 | Supported | Test both applicable homes inside the real sandbox |
|
|
| Native execution | Supported same-UID profile | Explicit config opt-in; ansible-core 2.19.11 and ansible.windows >=3.8.0,<4.0.0 |
|
|
| Private credentials | Supported one-run provider/FD | Not generic request JSON; no native prompt automation |
|
|
| Detailed progress v1 | Supported opt-in | Canonical callback/target acceptance required |
|
|
| Per-target outcomes v1 | Supported summary/detail | Native final stats, not application-completion inference |
|
|
| Purposeful operation reports v1 | Implemented candidate | Nine per-host schemas; native acceptance pending |
|
|
| Global operation report transport | Implemented candidate | No shipped global publisher; separate native qualification |
|
|
| Parsed Checkmk user config | Implemented candidate | Restricted basename/size; recognized secrets and commands redacted |
|
|
| Custom credentials / password-only verification | Unsupported | Supplied passwords remain native defaults |
|
|
| Cross-UID broker, key export, automatic owner migration | Unsupported | Independent execution identity must already be authorized |
|
|
| API inventory/Vault mutation or bootstrap | Unsupported | Existing terminal workflows remain available |
|
|
| Arbitrary debug/stdout/stderr/results | Unsupported | Only explicitly declared validated report data |
|
|
| Automatic replay after launch | Unsupported | Explicit new operator decision required |
|
|
|
|
A structured result is operational data and can reveal host inventory/configuration
|
|
choices even after credential redaction. Add-ons must restrict access, safely render
|
|
text and bound retention. Core does not implement their browser RBAC/CSRF/session policy.
|
|
|
|
## OS patch presentation in 3.3.0rc8
|
|
|
|
Add-ons obtain reboot delay/message and Windows post-reboot continuation from normal catalog
|
|
metadata; no private UI contract is required. The `os_patching_rescan_after_reboot` default
|
|
is false. A normal Windows patch run submits one selected update wave to native
|
|
`ansible.windows.win_updates` with `reboot: false`, then applies AIM reboot policy after the
|
|
wave returns. Show `continuation_required: true` as a request for
|
|
a new operator-approved run, not as a Core failure and not as permission to submit another
|
|
job automatically.
|
|
|
|
If `remaining_updates_known` is false, do not infer the post-reboot patch state from the
|
|
pre-reboot queue. If true, `pending` is a read-only final discovery. For Windows Update
|
|
failures, render the bounded `failed_updates` fields; do not parse raw task/event text.
|
|
`install_not_allowed` can mean an active installer or mandatory reboot, while
|
|
`preexisting_reboot_required` is a distinct AIM preflight result.
|
|
|
|
|
|
## Veeam O365 plugin relocation
|
|
|
|
The Checkmk Veeam O365 script destination changed in Core 3.3.0rc8, but this is not an add-on API change. Consumers continue to use Core catalog/execution/results and must not reconstruct Checkmk filesystem paths independently.
|