Implements Unit 2 "Offerings" (backend module, admin CRUD UI with
drag-and-drop reordering, public GET /api/v1/offerings endpoint) and
executes the feature's D-15 CI/CD cutover, switching the deploy
pipeline's build/publish target from SlpModularCms.Api to
SlpModularCms.Api.SlpSoftware.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
actions/setup-node@v4's Post step attempts a cache-save that fails hard on
this self-hosted Gitea Actions runner (no GHES cache API support), marking
frontend-prepare as failed and blocking its dependents even though the
actual install/build work succeeds. v3's older cache implementation doesn't
hit this. Also cleans up two stale comments left over from the /admin
MSBuild-target removal.
Also updates the documented backup script to skip cleanly (exit 0) when the
target database doesn't exist yet (MariaDB error 1049) rather than failing
the whole deploy - expected on a brand-new environment's first production
run, before migrations have ever had a chance to create it. Still fails hard
on any other error, so a real backup failure against an existing database
still blocks the deploy as intended.
ModuleOrchestrator already discovers SlpModularCms.Modules.*.dll from disk at
startup via reflection, so this needed no code change — only a persistent
location (mirroring shared/wwwroot-web) that survives release swaps, and a
deploy-scp.yaml step to symlink its contents into each new release before
restart.
Monitoring Setup: operations/plans/monitoring-setup-plan.md and
operations/monitoring/monitoring-instructions.md, covering Sentry alert
rules on the security_event tag, UptimeRobot's 6 liveness monitors, and
the two new Umami website entries for the admin SPA.
deployment-instructions.md gains a missing Observability__Environment
host var (without it, both environments would tag Sentry events as
"Production"), the nginx client_max_body_size fix for the 413 seen on
publish-test/production artifact uploads, and two troubleshooting notes
on Gitea Actions re-run behaviour: re-running deploy-test/production
alone loses the run's uploaded artifact, and re-running all jobs on an
existing (rather than a brand new) run can replay stale secrets.
deploy-scp.yaml: step names no longer show literal unresolved
${{ inputs.* }} text (Gitea doesn't interpolate that context in step
names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD
length plus a username equality check to diagnose a persistent
Permission denied during the SSH steps, without ever logging the
secret values themselves.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
backup-slpmodularcms-db.sh named the CMS; this backs up slpsoftware
specifically, same as every other instance-scoped path already does.
Hardcoded in deploy-scp.yaml itself, so this is the actual pipeline
code, not just docs describing it.
Four contexts got tangled together across the doc as it grew: pi-main
as root, pi-main as gitea-workflow, the separate proxy Pi, and Gitea's
own web UI. Added a legend up front and tagged every single command
block so it's no longer something the reader has to infer.
The backend already serves /sentry-tunnel itself with its own rate
limit, payload cap, and DSN-derived destination - exactly what that
nginx block exists to avoid needing. Proxying the same path at nginx
intercepts it first and silently drops all three protections.
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.
SluijsensandClaude Sonnet 5