Conformance updates.
This commit is contained in:
+108
-11
@@ -4,7 +4,7 @@ Live state of the Mechanical Compiler staging instance on `srv-b`.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| Updated | 2026-08-17, after work order 003 (monitoring, SMTP egress) |
|
||||
| Updated | 2026-08-18, after repository seeding and container standardisation |
|
||||
| Instance | Staging / development |
|
||||
| Specification | `ENVIRONMENT.md` revision 5 |
|
||||
| Failure log | `FAILURES.md` |
|
||||
@@ -329,7 +329,10 @@ work. None is a defect.
|
||||
the four members, so drive age is a known quantity rather than an
|
||||
assumption. `smartctl -d cciss,N -A /dev/sda`. Read-only, one command.
|
||||
- [ ] **Backup infrastructure, entirely.** Postponed 2026-08-16 because the
|
||||
strategy may change: `vzdump` job, archive sizing, retention, free-space
|
||||
strategy may change, and reaffirmed 2026-08-18 on stronger grounds: a
|
||||
backup of an unverified configuration restores the confusion along with
|
||||
the data. **Entry condition: `ct-baseline.sh` exits 0.** Scope when
|
||||
resumed: `vzdump` job, archive sizing, retention, free-space
|
||||
guard, host-side pull, `mechcomp-backup`, backup alerting, gold media,
|
||||
3+ TB redundancy.
|
||||
|
||||
@@ -348,6 +351,91 @@ hold the only instance with no monitoring, no alerting and no backup.
|
||||
|
||||
---
|
||||
|
||||
## 3b. Container baseline
|
||||
|
||||
**`ct-baseline.sh` is the definition of "standard configuration" on this host.**
|
||||
It changes nothing, runs any time, and exits 0 only when every container
|
||||
conforms.
|
||||
|
||||
```
|
||||
last run 2026-08-18
|
||||
result 62 passed, 0 failed, 3 informational
|
||||
scope srv-b, CT 100, CT 101, CT 102
|
||||
```
|
||||
|
||||
**A property not checked by that script is not part of the standard.** That is
|
||||
what makes it terminate. Divergence used to be discovered by asking, one
|
||||
property at a time, whenever something behaved oddly — which never finishes,
|
||||
because nothing stated what "the same" meant. If a property should be uniform,
|
||||
it belongs in the script rather than in someone's memory.
|
||||
|
||||
What it asserts, per container: `onboot`, unprivileged, `nesting=1`, a single
|
||||
interface on the service bridge, systemd `running` with zero failed units, one
|
||||
interface stanza, Debian 12, timezone, **generated** locale, `curl`,
|
||||
`ca-certificates`, `openssh-server`, sshd active, admin account with
|
||||
`authorized_keys` at `0600`, **no mail agent**, SMTP egress blocked, LAN
|
||||
gateway unreachable. Host-level: systemd health, both firewall rules, `smartd`
|
||||
device count, bastion key.
|
||||
|
||||
Each failure cites the failure entry that established the requirement, so the
|
||||
reason survives the person.
|
||||
|
||||
### The mail standard
|
||||
|
||||
**Containers do not send mail.** Only `srv-b` does, and only its own alerts,
|
||||
through `[10.110.0.1]:25`. A container with a mail agent installed but SMTP
|
||||
egress blocked is the worst case: it queues forever and delivers nothing.
|
||||
|
||||
CT 100 and CT 101 were in exactly that state until 2026-08-18 (F-031).
|
||||
|
||||
### Ownership
|
||||
|
||||
The script checks containers belonging to two projects and encodes host
|
||||
requirements neither owns alone (F-032). It is **host-level**, not Mechanical
|
||||
Compiler property. Suggested home: `/usr/local/sbin/ct-baseline.sh` on `srv-b`,
|
||||
with the canonical copy outside this repository.
|
||||
|
||||
### Relationship to backup
|
||||
|
||||
**Conformance is a precondition for backup, not a companion to it.** A backup
|
||||
taken before 2026-08-18 would have preserved two containers that queue mail
|
||||
forever, and a restore would have faithfully returned them to that state.
|
||||
|
||||
Backing up an unverified configuration does not preserve a system; it preserves
|
||||
a state of confusion. The entry condition for backup work is `ct-baseline.sh`
|
||||
exiting 0 — and it becomes part of restore verification.
|
||||
|
||||
---
|
||||
|
||||
## 3a. Parallel project on this host
|
||||
|
||||
**Kane Fabric** is a separate project sharing `srv-b`. It is where SASE, HOA
|
||||
Diagnostics, the Mechanical Compiler and other SASE-consuming projects are
|
||||
implemented.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| Repository | `github.com/git64bit/Kane-Fabric` |
|
||||
| Container | CT 102 `kane-fabric` |
|
||||
| Address | `10.20.0.12/24` on `vmbr1`, gateway `10.20.0.1` |
|
||||
| Ownership | Separate project. Not Mechanical Compiler infrastructure. |
|
||||
| Baseline | Conforms as of 2026-08-18, verified by `ct-baseline.sh` |
|
||||
|
||||
Recorded here for two operational reasons only.
|
||||
|
||||
**It shares the service network.** CT 102 sits on `vmbr1` alongside CT 100 and
|
||||
CT 101, so host-level rules scoped to `10.20.0.0/24` apply to it. In particular
|
||||
it **inherits the SMTP egress block** (F-025) — if Kane Fabric ever needs to
|
||||
send mail, that will present as a Postfix failure with a non-obvious cause.
|
||||
|
||||
**Host resources are shared, not pooled.** Neither project consumes or
|
||||
repurposes the other's containers. Any integration is through an explicit
|
||||
contract, not through co-location on `srv-b`.
|
||||
|
||||
No interface between the two projects exists today, and none is assumed.
|
||||
|
||||
---
|
||||
|
||||
## 4. Access model
|
||||
|
||||
Confirmed: no workstation access from the home LAN is required.
|
||||
@@ -374,25 +462,31 @@ entire address space.
|
||||
Repository state:
|
||||
|
||||
```
|
||||
HEAD e85c4f4e5bab9a4f032230c99aa6784ace4c80e2
|
||||
top level .git LICENSE README.md venv
|
||||
git status ?? venv/
|
||||
absent requirements-base.txt, requirements-cad.txt, service units
|
||||
HEAD c7e32d8e0772d89d1117bab7ff08d61e5b2a497e
|
||||
top level .gitignore LICENSE Makefile README.md docs/ fixtures/ legacy/
|
||||
pyproject.toml requirements-*.txt src/ tests/ tools/ venv/
|
||||
remote ssh://git@gitea.barternetwork.us:42022/TheRON/mechanical-compiler.git
|
||||
deploy key srv-b-ct100, read/write
|
||||
venv Python 3.11.2, shapely 2.1.2, cadquery 2.8.0, mechcomp editable
|
||||
tests 3 passed, 236 skipped
|
||||
oracle ddd0f154... verified in-container
|
||||
absent the Shapely port itself
|
||||
```
|
||||
|
||||
None of the following can be honestly completed, and none may be fabricated by
|
||||
provisioning:
|
||||
|
||||
- [ ] Dependency install from committed manifests
|
||||
- [x] ~~Dependency install from committed manifests~~ — done 2026-08-18
|
||||
- [ ] `mechcomp.service`, `mechcomp-worker.service`
|
||||
- [ ] Reference toolchain image `mechcomp/reference-toolchain:8.0.0`
|
||||
- [ ] Fixture reproduction against `ddd0f154...`
|
||||
- [ ] Application-runtime acceptance
|
||||
- [ ] Replacing the placeholder with the real service
|
||||
|
||||
**Architect decision:** `venv/` belongs in `.gitignore` — it is a legitimate
|
||||
artifact inside `install_dir` per YunoHost convention, it simply should not be
|
||||
tracked. Applied with the first application commit.
|
||||
**Applied 2026-08-18:** `venv/` is in `.gitignore`, along with `.cache/`,
|
||||
`.local/`, `.ssh/`, `.gitconfig` and `.lesshst` — the service user's home is
|
||||
`install_dir`, so anything writing to `$HOME` writes into the working tree
|
||||
(F-029).
|
||||
|
||||
The Shapely port gates all of the above.
|
||||
|
||||
@@ -425,4 +519,7 @@ All three need CIVICVS.
|
||||
| Why did delivery fail downstream? | `mx1` relay trust. Proven and corrected (F-023). |
|
||||
| Where does Postfix log on this host? | journald. No `rsyslog`, no `/var/log/mail.log` (F-024). |
|
||||
| Should container SMTP egress be blocked? | Yes. Implemented and reboot-proven (F-025 project-local half). |
|
||||
| Do the containers autostart? | Yes, `onboot: 1` on both, proven by host reboot (F-026). |
|
||||
| Do the containers autostart? | Yes, `onboot: 1` on all three, proven by host reboot (F-026). |
|
||||
| How do files reach a container? | Upload to `/root/incoming` on `srv-b`, then `pct push` / `pct exec`. See `PROCESS.md`. |
|
||||
| How does CT 100 push to Gitea? | Deploy key `srv-b-ct100`, SSH on port **42022**, read/write. |
|
||||
| Do containers send mail? | **No.** Only `srv-b` does. See section 3b. |
|
||||
|
||||
Reference in New Issue
Block a user