makearmy/le-app
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add Phase 2B contained runtime artifacts

Browse source
This commit is contained in:
makearmy 2026-07-12 21:01:17 -04:00
parent a9fec0d83d
commit 82e64cec43
35 changed files with 5177 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/le-app-database-migration/environment-parity.md
View file

@ -152,22 +152,22 @@ Current host observation and planning checkpoint:
- the default Docker context does not provide a usable daemon/security result to this user;
- no enabled user-level rootless Docker service was detected;
- no persistent `le-app-codex` namespace or project nftables policy is deployed;
- approved DNS remains unresolved; the host resolver currently includes `192.168.10.1`, which is an observation rather than approval;
- root inventory is complete; Quad9 IPv4 `9.9.9.9` and `149.112.112.112` are approved, while observed LAN resolver `192.168.10.1` remains denied with no LAN exception;
- numerous existing Docker IPv4 and IPv6 bridge ranges must be dynamically inventoried and denied rather than represented only by a stale list.
Therefore a `sol6_vi`-owned daemon is rejected: it could bind-mount those readable production secrets. Milestone 0 requires the isolated account and host changes described in `host-runtime-plan.md`, and work must stop before performing them. An administrator must approve/provision:
1. dedicated `le_app_codex` identity and restricted filesystem ACLs;
2. an explicitly selected package path: scheduled full host maintenance or a clean-chroot/current-system-compatible investigation, never a partial Arch upgrade;
2. the completed and verified Phase 2A package-maintenance baseline, without rerunning that transaction;
3. a checksum-pinned Moby rootless launcher matched to the installed Docker release, not the unmodified AUR extras package or its global sysctl hook;
4. instance-specific containment on `user@1200.service`, the proposed `user-1200.slice` resource limits, and no lingering;
5. a root-created IPv4-only namespace with default-deny egress and dynamic denial of host, LAN, WireGuard, metadata, private, loopback, Docker bridge, SMTP, and IPv6 access;
6. inert acceptance tests before starting the user manager, Docker, or Codex;
7. deterministic CPU BGBye first; optional GPU access only after core acceptance;
8. user/browser-profile-scoped development CA trust;
9. a separately approved disk-growth limit for images, caches, snapshots, media, PostgreSQL, and test artifacts.
9. deferred hard disk-growth enforcement for images, caches, snapshots, media, PostgreSQL, and test artifacts; this is not a Phase 2B installation blocker and existing visibility/resource controls are not a hard quota.
Lingering must remain disabled. No production socket forwarding, Docker-group membership, broad sudo rule, daemon TCP exposure, system-service `dockerd`, or bind mount into production paths is acceptable. See `host-runtime-plan.md` for the approval-gated lifecycle and unresolved DNS, address-inventory, authentication, package, and disk-quota decisions.
Lingering must remain disabled. No production socket forwarding, Docker-group membership, broad sudo rule, daemon TCP exposure, system-service `dockerd`, or bind mount into production paths is acceptable. See `host-runtime-plan.md` for the approval-gated lifecycle, deferred nonblocking storage quota, and unresolved authentication decision.
## One-command workflows