DerLinkman
30f3e9a4c6
- replace inventory/dmc12.yml with cloudlorean.yml (+ group_vars) and update all README/AGENTS call examples and the inventory table - move admin_password hash into encrypted vault.yml; remove plaintext copies from roles/bootstrap/defaults and group_vars/external.yml - bootstrap.yml loads vault.yml via vars_files (same pattern as monitoring) - monitoring: PSK config/registration updates, docker role defaults, os-updates logging/reboot refinements, ansible.cfg/execute.sh tweaks - add .project-wiki knowledge base and .github agent instructions
111 lines
3.3 KiB
Markdown
111 lines
3.3 KiB
Markdown
---
|
|
id: OPEN-QUESTIONS
|
|
type: note
|
|
status: active
|
|
title: Open Questions
|
|
created: '2026-09-09'
|
|
updated: '2026-09-09'
|
|
tags:
|
|
- requirements
|
|
- open-questions
|
|
related:
|
|
- SCAN-20260909
|
|
- ALERT-20260909-001
|
|
- ALERT-20260909-002
|
|
source_paths:
|
|
- AGENTS.md
|
|
- README.md
|
|
- inventory/group_vars/external.yml
|
|
confidence: confirmed
|
|
---
|
|
|
|
# Open Questions
|
|
|
|
Reconciliation state after the 2026-09-09 scan (workflow: Open Questions
|
|
Reconciliation). Anchors are stable; statuses follow the schema
|
|
(`open`, `partially-resolved`, `resolved`, ...).
|
|
|
|
<a id="oq-001"></a>
|
|
|
|
## OQ-001 - Who are the stakeholders/owners of this repository?
|
|
|
|
Status: partially-resolved
|
|
Updated: 2026-09-09
|
|
Related: [SCAN-20260909]
|
|
|
|
Resolution (partial): Operators appear to be "Niklas" and "Dennis"
|
|
(SSH key comments in `roles/bootstrap/defaults/main.yml`,
|
|
`confidence: inferred`). Formal ownership and roles remain undocumented.
|
|
|
|
Remaining question: Who formally owns and operates the playbooks, and who
|
|
approves changes?
|
|
|
|
<a id="oq-002"></a>
|
|
|
|
## OQ-002 - What are the explicit success criteria?
|
|
|
|
Status: partially-resolved
|
|
Updated: 2026-09-09
|
|
Related: [SCAN-20260909], MOD-005
|
|
|
|
Resolution (partial): For update runs, success is defined by the
|
|
`healthcheck` quality gate (all Docker containers running; fails the play
|
|
only when `healthcheck_fail_on_unhealthy` is true). No success criteria for
|
|
the overall project are documented.
|
|
|
|
Remaining question: What defines success beyond a passing update-run gate?
|
|
|
|
<a id="oq-003"></a>
|
|
|
|
## OQ-003 - Is `AGENTS.md`/`README.md` stale regarding `inventory/dmc12.yml`?
|
|
|
|
Status: resolved
|
|
Updated: 2026-09-09
|
|
Related: [ALERT-20260909-002], SCAN-20260909
|
|
|
|
Resolution: Yes. Git status shows `D inventory/dmc12.yml` (uncommitted) and
|
|
untracked `inventory/cloudlorean.yml`; `dmc12` is now a Proxmox host inside
|
|
the `cloudlorean` site. `README.md` (inventory table, examples) and
|
|
`AGENTS.md` still reference `dmc12.yml`. Documentation updates and the
|
|
commit of the rename are tracked in ALERT-20260909-002.
|
|
|
|
<a id="oq-004"></a>
|
|
|
|
## OQ-004 - Is the external site's Zabbix passive server correct?
|
|
|
|
Status: open
|
|
Created: 2026-09-09
|
|
Related: [SCAN-20260909], MOD-003
|
|
|
|
`inventory/group_vars/external.yml` sets
|
|
`monitoring_zabbix_passive_servers: ["2a01:4f8:1c1e:62dd::1"]`, which is the
|
|
`healthcheck` host's own address. Is a Zabbix server/proxy intentionally
|
|
running on that host, or is this a misconfiguration? (`confidence: unknown`)
|
|
|
|
<a id="oq-005"></a>
|
|
|
|
## OQ-005 - Which Docker template name exists on the Zabbix server?
|
|
|
|
Status: open
|
|
Created: 2026-09-09
|
|
Related: [SCAN-20260909], MOD-003
|
|
|
|
Role default `monitoring_zabbix_docker_templates: ["Docker by Zabbix agent2"]`
|
|
(no space) vs group_vars `["Docker by Zabbix agent 2"]` (with space). One of
|
|
the two will fail host linking at registration. Which name does the Zabbix
|
|
server actually use? (`confidence: unknown`)
|
|
|
|
<a id="oq-006"></a>
|
|
|
|
## OQ-006 - Is the committed `admin_password` hash intended or a policy violation?
|
|
|
|
Status: resolved
|
|
Updated: 2026-09-09
|
|
Related: [ALERT-20260909-001], NFR-002
|
|
|
|
Resolution: Policy violation. Decrypting `vault.yml` during the alert
|
|
resolution confirmed it did not define `admin_password` (no override); the
|
|
hash existed only as plaintext in role defaults and group_vars. Resolved with
|
|
[ALERT-20260909-001]: hash moved into encrypted `vault.yml`, plaintext copies
|
|
removed, `bootstrap.yml` loads the vault via `vars_files`.
|