nginx and certbot were designed assuming they lived on the same host
as the app. They don't - a dedicated proxy Pi terminates TLS and
forwards plain HTTP over the LAN. Kestrel now binds 0.0.0.0 instead
of localhost, the whole certbot procedure moved to the proxy Pi's
side, and pi-main gets a firewall rule restricting the backend ports
to just the proxy Pi's address - otherwise binding all interfaces
would let anything on the LAN skip the proxy's TLS entirely.
New section walks through adding any domain from nothing - plain
HTTP block first (certbot's nginx plugin needs one to validate
against), then the certbot command, then a verification step. The
existing slpsoftware.nl blocks stay as the worked result of that
procedure rather than a separate one-off.
Traced live on the actual Pi: su - gitea-workflow left XDG_RUNTIME_DIR
unset even with the user manager already running and the bus socket
already there. None of su/sudo -i/sudo -u reliably go through
pam_systemd on Debian - only a real SSH login or sshd itself does,
which is what the deploy workflow already uses.
Enabling lingering doesn't start the user manager retroactively, and
sudo -u often drops XDG_RUNTIME_DIR - both produce the same "Failed
to connect to bus" error when setting this up by hand.
The target Pi only has MariaDB, and SQL Server has no ARM64 build at
all - not a config problem, a real gap discovered during deployment
setup. Swapped the EF Core provider, regenerated every migration,
updated connection strings and the backup script everywhere they
appear.
Took two tries to land on a provider that actually works: Pomelo
builds fine against this project's EF Core 10 packages but fails at
runtime (it's compiled against 9's internal API surface, which moved
in 10 wherever Identity/DataProtection force the newer packages).
Oracle's official provider builds and migrates fine but has a real
MariaDB bug in its own migration-lock code, reproduced against a live
database. Kept Oracle's provider and worked around just that one
broken method - everything else it does is correct - rather than
give up more of the stack to chase a workaround.
Verified against a real local MariaDB end to end: all three
migrations applied, both hosts start clean, full suite still green.
AllowedConnectOrigins had a sentry-ingest-origin placeholder that
was simply incorrect - the Sentry tunnel exists precisely so that
exception is never needed. Both SecurityHeaders fields are Umami-only
now, with inline comments on when to set them versus leave them out,
and a note that MasterModule__MasterUrl degrades to a warning rather
than a startup failure when unset.
SlpModularCms is the product; slpsoftware.nl is the customer running
it - the first one, and a fine stand-in for what a real deployment
looks like. Renamed the directories, systemd units, and backup paths
accordingly. Left the backup script's own filename alone since the
already-committed deploy-scp.yaml calls it by that exact name.
Applies to both the app's own release tree and the website upload
path - slpmodularcms/test and slpmodularcms/production side by side
under one parent, not two separately-named directories. Service unit
names stay hyphenated; those aren't folders.
No reason to mint a new system account for every project on the
same Pi - one shared, host-wide account works, namespaced by
directory per project underneath it.
webadmin turned out to be FTP-only and belongs to whoever uploads
customer websites, not to this pipeline. Switched to a separate
deploy account with its own home-directory paths, well away from
where the other sites live, and made the persistent website symlink
cross into webadmin's territory instead of the other way around.
Host setup checklist, real domains and ports, the database backup
script the deploy workflow only ever invokes, and a rollback plan.
Also drafted the FTPS switch procedure for whenever production moves
off the Pi, with a note that shared hosting is likely IIS-based -
that's a bigger change than swapping the transport.
Sluijsens