Final configuration
This commit is contained in:
+50
-17
@@ -4,7 +4,7 @@ Live state of the Mechanical Compiler staging instance on `srv-b`.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| Updated | 2026-08-17, after work order 002 (mail) |
|
||||
| Updated | 2026-08-17, after work order 003 (monitoring, SMTP egress) |
|
||||
| Instance | Staging / development |
|
||||
| Specification | `ENVIRONMENT.md` revision 5 |
|
||||
| Failure log | `FAILURES.md` |
|
||||
@@ -37,7 +37,7 @@ and must not be represented as either hidden failures or completed work:
|
||||
| Subsystem | Status |
|
||||
|---|---|
|
||||
| Mail alert delivery | **Accepted 2026-08-17.** Delivered end to end, twice, headers captured. |
|
||||
| `smartd` monitoring | Deferred. Now unblocked — mail works. |
|
||||
| `smartd` monitoring | **Accepted 2026-08-17.** Four members monitored, four alerts received. |
|
||||
| Backup infrastructure | **Postponed by operator decision** — strategy may change |
|
||||
|
||||
---
|
||||
@@ -77,6 +77,7 @@ template local:vztmpl/debian-12-standard_12.12-1_amd64.tar.zst
|
||||
| rootfs | 40 GiB `local-lvm` | 8 GiB `local-lvm` |
|
||||
| `mp0` | 60 GiB → `/var/lib/mechcomp`, `backup=0` | — |
|
||||
| `net0` | `eth0` on `vmbr1`, `10.20.0.10/24`, gw `10.20.0.1` | `eth0` on `vmbr1`, `10.20.0.11/24`, gw `10.20.0.1` |
|
||||
| `onboot` | `1` | `1` |
|
||||
| Debian | 12 bookworm, fully upgraded | 12 bookworm, fully upgraded |
|
||||
| systemd | running, zero failed units | running, zero failed units |
|
||||
|
||||
@@ -108,6 +109,8 @@ nat POSTROUTING
|
||||
-s 10.20.0.0/24 -o vmbr0 -j MASQUERADE # containers -> internet
|
||||
|
||||
filter FORWARD
|
||||
-s 10.20.0.0/24 -d 10.110.0.0/22 -p tcp
|
||||
-m multiport --dports 25,465,587 -j DROP # SMTP egress blocked
|
||||
-s 10.20.0.0/24 -d 10.20.0.0/24 -j ACCEPT # container <-> container
|
||||
-s 10.20.0.0/24 -d 10.0.0.0/24 -j DROP # LAN blocked
|
||||
```
|
||||
@@ -115,6 +118,39 @@ filter FORWARD
|
||||
Rule order is load-bearing. `RETURN` must precede both service-network
|
||||
masquerades. Live and persisted states match.
|
||||
|
||||
### Disk monitoring — accepted 2026-08-17
|
||||
|
||||
`DEVICESCAN` finds nothing behind the P410i. Members are addressed explicitly:
|
||||
|
||||
```
|
||||
/etc/smartd.conf
|
||||
DEFAULT -a -m root -M exec /usr/share/smartmontools/smartd-runner
|
||||
/dev/sda -d cciss,0
|
||||
/dev/sda -d cciss,1
|
||||
/dev/sda -d cciss,2
|
||||
/dev/sda -d cciss,3
|
||||
|
||||
before: Monitoring 0 ATA/SATA, 0 SCSI/SAS and 0 NVMe devices
|
||||
after: Monitoring 0 ATA/SATA, 4 SCSI/SAS and 0 NVMe devices
|
||||
unit: smartmontools.service (smartd.service is an alias with no journal)
|
||||
alerts: 4 test alerts generated and received; headers captured
|
||||
-M test reverted; permanent config restored and reboot-proven
|
||||
```
|
||||
|
||||
**Physical identity of the four members.** This is how a future SMART alert is
|
||||
matched to a caddy:
|
||||
|
||||
| Member | Model | Serial |
|
||||
|---|---|---|
|
||||
| `cciss,0` | `EG0146FAWHU` | `6SD0LETK0000B05009W1` |
|
||||
| `cciss,1` | `EG0146FAWHU` | `3SD3K5P00000905094UN` |
|
||||
| `cciss,2` | `EG0146FAWHU` | `3SD3GHJ600009047RRRG` |
|
||||
| `cciss,3` | `EG0146FAWHU` | `3SD3GVP800009045X79B` |
|
||||
|
||||
**Not yet captured:** power-on hours and grown-defect counts. On 2010-vintage
|
||||
drives holding the only instance, those numbers say how much runway remains.
|
||||
`smartctl -d cciss,N -A /dev/sda` for each member.
|
||||
|
||||
### TLS
|
||||
|
||||
```
|
||||
@@ -232,6 +268,9 @@ Each line was demonstrated by command output, not inferred.
|
||||
- [x] NAT and FORWARD rules present live **and** persisted, in correct order
|
||||
- [x] Host: `running`, zero failed units
|
||||
- [x] **Mail delivered end to end from `root` on `srv-b`, twice, headers captured**
|
||||
- [x] **`smartd` monitoring 4 devices; 4 test alerts delivered and received**
|
||||
- [x] **Container SMTP egress blocked; internet egress and host mail intact**
|
||||
- [x] **Both containers autostart after a host reboot** (`onboot: 1`)
|
||||
|
||||
### CT 100
|
||||
|
||||
@@ -278,19 +317,12 @@ Nothing. The infrastructure boundary is accepted.
|
||||
Recorded here so they are visually distinct from failures and from forgotten
|
||||
work. None is a defect.
|
||||
|
||||
- [ ] **SMTP egress block for the container network** (F-025). The containers
|
||||
have no reason to originate mail. A `FORWARD` DROP on ports 25/465/587
|
||||
from the service network to `10.110.0.0/22` is local, precise, and touches
|
||||
no estate policy. `srv-b`'s own alerts are unaffected — they originate
|
||||
locally and take OUTPUT, never FORWARD.
|
||||
- [ ] **`wg-pk` `mynetworks` scope** (F-025). Estate decision: whether every
|
||||
tunnel peer should originate mail as `kane-il.us` infrastructure, or only
|
||||
the hosts that legitimately do. Not this project's to change unilaterally.
|
||||
- [ ] **`smartd` explicit four-member configuration.** The package is installed
|
||||
and the service is active, but `DEVICESCAN` currently monitors **zero
|
||||
devices**; the P410i members are visible only through explicit
|
||||
`-d cciss,N`. Active is not the same as monitoring. **Now unblocked** —
|
||||
mail is accepted, so `-M test` gives a real end-to-end acceptance.
|
||||
- [ ] **SMART attribute baseline.** Power-on hours and grown-defect counts for
|
||||
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
|
||||
guard, host-side pull, `mechcomp-backup`, backup alerting, gold media,
|
||||
@@ -365,12 +397,11 @@ The Shapely port gates all of the above.
|
||||
|
||||
| # | Question | Blocks |
|
||||
|---|---|---|
|
||||
| 1 | Should container SMTP egress be blocked at `srv-b`? | F-025, ours to fix |
|
||||
| 2 | Should `wg-pk` `mynetworks` narrow to explicit hosts? | F-025, estate decision |
|
||||
| 3 | What is the backup strategy? | all backup work |
|
||||
| 4 | Where is the 3+ TB USB disk attached? | gold redundancy step |
|
||||
| 1 | Should `wg-pk` `mynetworks` narrow to explicit hosts? | F-025 estate half |
|
||||
| 2 | What is the backup strategy? | all backup work |
|
||||
| 3 | Where is the 3+ TB USB disk attached? | gold redundancy step |
|
||||
|
||||
All four need CIVICVS.
|
||||
All three need CIVICVS.
|
||||
|
||||
---
|
||||
|
||||
@@ -388,3 +419,5 @@ All four need CIVICVS.
|
||||
| `MECHCOMP_BIND` semantics | Scalar, service address only. Loopback not bound. |
|
||||
| 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). |
|
||||
|
||||
Reference in New Issue
Block a user