Files
TheRON bac6120605 deploy: the running configuration, and the identity contract
STAGING-STATE recorded mechcomp.service as delivered at deploy/mechcomp.service
on 11 SEP. The unit was real; the directory was not. It existed only on CT 100,
so the repository claimed to hold something it did not, and the only way to
answer a question about the service was to read the container. The nginx vhost
had never been committed at all.

Both imported verbatim as they ran on 12 SEP, with their host checksums proven
equal at import. A first commit of a configuration file records reality, not
intentions -- every later improvement is then a diff against a known-good
starting point rather than a rewrite nobody can check.

mechcomp.env is deliberately absent. It is the one file that is supposed to
differ between instances, it is root:mechcomp 0640 because a deployment's
bindings belong to the deployment, and a committed copy would create a second
source of truth for exactly the wrong file. ENVIRONMENT.md documents the keys.
Certificates and keys likewise.

IDENTITY-CONTRACT.md is the boundary between this application and the
membership system, and the only document here written to be read by someone who
does not work on this repository. Two systems that must agree on an interface
need it written once, somewhere both can point at.

The compiler does not authenticate anyone; it is told. CT 101 decides, against
the membership system, and sets X-Kane-Auth-Email and X-Kane-Auth-Method. They
map onto Author.email and Author.method, which already exist and are tested. The
parser's refusal to recover `verified` from text was built for this: a record
read back is always self-declared, because a file cannot attest to its own
verification.

The decision belongs at CT 101 and never at wg-pk. The hub carries twenty peers
and is estate infrastructure this project does not own, so authorisation there
would make every future adjustment an escalation and would teach a shared
transport about one project's membership roll. CT 101 already shares the service
bridge with CT 100 and CT 102.

One gated prefix, /m/. nginx gets one location block, written once. Gating a new
endpoint afterwards is choosing a URL in Python -- no proxy change, no
escalation. That cheapness makes the placement of the line reversible rather
than structural. Today it sits at export: the catalogue and composer are open,
and what requires membership is producing an artifact whose design record names
an author.

Section 6 is the part most likely to erode and is written hardest. The compiler
must never learn what a building is, what a membership level is, or that group
names exist -- including as a configuration value, which is how the leak arrives
by the side door. The test is that the membership system can rename every level
and replace its storage without a line of this repository being read.

Section 9 deletes the ACL from the roadmap rather than deferring it. The
compiler will not have a user table, a login form or a session.

Recorded openly rather than assumed: the service is world-reachable and
unauthenticated, /m/ is not yet gated, and STL export will therefore ship open.
Same posture the whole service already has. The earlier justification --
"acceptable for a development name" -- was wrong and is corrected separately:
dev.mechcomp.kane-il.us is production, dev abbreviates Mechanical Compiler
Developers, and the name is on printed material.

The inbound header strip depends on none of this and should land on its own. It
costs one directive and removes a forgery that becomes possible the moment the
headers mean anything.
2026-09-12 06:58:14 -05:00

57 lines
1.8 KiB
Desktop File

[Unit]
# The real service. Replaces mechcomp-placeholder.service, which existed only to
# prove the nginx chain on CT 101 independently of the application
# (STAGING-STATE.md, "Placeholder backend"). That proof is done and the
# application now exists, so the placeholder is removed rather than left
# competing for 10.20.0.10:8770.
Description=Mechanical Compiler composer
Documentation=https://gitea.barternetwork.us/TheRON/mechanical-compiler
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=mechcomp
Group=mechcomp
# Binding, base URL and everything else come from here. The unit deliberately
# passes no --host or --port: the deployment declares those, not the command
# line, and a flag here would silently outrank the file the operator edits.
EnvironmentFile=/etc/mechcomp/mechcomp.env
WorkingDirectory=/var/www/mechcomp
ExecStart=/var/www/mechcomp/venv/bin/python -m mechcomp.web
Restart=on-failure
RestartSec=3
# Hardening, matching the set the placeholder already carried.
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
RemoveIPC=yes
# ProtectSystem=strict makes everything read-only except what is named here.
# The composer writes nothing today; the data directory is listed because the
# design record and any future artifact belong there and not in the working
# tree, which is also the service user's home (F-029).
ReadWritePaths=/var/lib/mechcomp
StandardOutput=journal
StandardError=journal
SyslogIdentifier=mechcomp
[Install]
WantedBy=multi-user.target