From 960760c24e90c70357dd551d1a186cbedfdb9765 Mon Sep 17 00:00:00 2001 From: Sluijsens Date: Tue, 28 Jul 2026 19:46:58 +0200 Subject: [PATCH] Makes the deploy account generic instead of per-project 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. --- .../gitea-deployment-workflow/audit.md | 11 +++++++ .../deployment/deployment-instructions.md | 32 +++++++++++-------- .../operations/deployment/deployment-plan.md | 10 +++--- 3 files changed, 36 insertions(+), 17 deletions(-) diff --git a/aidlc-docs/features/gitea-deployment-workflow/audit.md b/aidlc-docs/features/gitea-deployment-workflow/audit.md index 7323591..ef7ae7c 100644 --- a/aidlc-docs/features/gitea-deployment-workflow/audit.md +++ b/aidlc-docs/features/gitea-deployment-workflow/audit.md @@ -1279,3 +1279,14 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an **Context**: OPERATIONS — Deployment Setup artifacts corrected before final approval --- +## Deployment Setup — Generic Deploy Account + +**Timestamp**: 2026-07-28T04:00:00Z + +**User Input**: "het deploy/pipeline-account mag een generieke zijn voor op de pi. die hoeft niet specifiek voor dit project" + +**AI Response**: "Renamed the suggested account from project-specific (slpmodularcms-deploy) to generic/host-wide (pi-deploy), noting it should serve multiple projects' deploy pipelines and that the reference project's existing account should be checked and reused if it already has SSH shell access, rather than creating a duplicate. Deploy paths stay namespaced per project under that shared account's home directory, so this doesn't change the directory layout, only the account's identity/scope." + +**Context**: OPERATIONS — Deployment Setup, small correction before final approval + +--- diff --git a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md index e4fbe90..e258455 100644 --- a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md +++ b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md @@ -25,21 +25,27 @@ role) — it cannot SSH in, and should **stay** SFTP-only. `deploy-scp.yaml` nee (for `mkdir`, `ln -sfn`, `systemctl --user restart`, the backup script), which is a different kind of access than FileZilla uses. -**Preferred**: create a separate, dedicated account for the deploy pipeline — e.g. -`slpmodularcms-deploy` (rename freely; nothing in the workflow hardcodes this name, it only reads -`PI_MAIN_USERNAME`). This keeps the two roles cleanly apart, matching your stated preference. +**Preferred**: a separate account for the deploy pipeline, but a **generic, host-wide** one — not +named after this project, since it may end up deploying other projects on this Pi too (the reference +`SlpSoftware` project's own pipeline may already have exactly this kind of account; check its +`PI_MAIN_USERNAME` secret first and reuse it directly if it already has SSH shell access, rather than +creating a second one). Example name: `pi-deploy`. ```bash -sudo useradd -m -s /bin/bash slpmodularcms-deploy -sudo passwd slpmodularcms-deploy +sudo useradd -m -s /bin/bash pi-deploy +sudo passwd pi-deploy ``` -**Fallback, only if a new account genuinely isn't feasible** (e.g. a hosting provider that doesn't -allow arbitrary new system accounts): grant `webadmin` SSH shell access instead -(`sudo usermod -s /bin/bash webadmin`, plus enabling SSH password/key auth for it if currently -blocked at the `sshd_config` level). This merges the two roles onto one account — acceptable as a -fallback, but worth revisiting later, since it means a website-workspace author's FTP credential -would also be able to run shell commands on the Pi. +Each project deploying through this account gets its own subdirectory under its home (§ 1.4 already +namespaces by project: `~/apps/slpmodularcms-/`), so one generic account can serve multiple +projects without their release trees colliding. -The rest of this document uses `` — substitute whichever of the two you actually use. +**Fallback, only if no SSH-capable account exists at all and creating one genuinely isn't feasible** +(e.g. a hosting provider that doesn't allow arbitrary new system accounts): grant `webadmin` SSH +shell access instead (`sudo usermod -s /bin/bash webadmin`, plus enabling SSH password/key auth for +it if currently blocked at the `sshd_config` level). This merges the FTP and deploy roles onto one +account — acceptable as a fallback, but worth revisiting later, since it means a website-workspace +author's FTP credential would also be able to run shell commands on the Pi. + +The rest of this document uses `` — substitute the generic account's actual name. ### 1.3 Enable Lingering (INFRA-U6-01 — do this first, easy to forget) ```bash @@ -193,7 +199,7 @@ change: |---|---|---| | `PI_MAIN_ADDRESS` | secret | the Pi's address | | `PI_MAIN_PORT` | secret | SSH port | -| `PI_MAIN_USERNAME` | secret | `` — the new dedicated account (§ 1.2), **not** `webadmin` | +| `PI_MAIN_USERNAME` | secret | `` — the generic, host-wide deploy account (§ 1.2), **not** `webadmin`; reuse the reference project's if it already has one | | `PI_MAIN_PASSWORD` | secret | ``'s password | | `DEPLOY_PATH_TEST` | variable | `/home//apps/slpmodularcms-test` | | `DEPLOY_PATH_PRODUCTION` | variable | `/home//apps/slpmodularcms-production` | diff --git a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-plan.md b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-plan.md index a25513a..daefee8 100644 --- a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-plan.md +++ b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-plan.md @@ -28,10 +28,12 @@ Same physical host for both (per `infrastructure-design.md` § 1) — separated **Account model (revised at Deployment Setup)**: the Pi's existing `webadmin` account is FileZilla/ SFTP-only, used by website-workspace authors uploading customer sites under `/mnt/storage1/www/html/` (`WEBSITE_WORKSPACE.md`'s role) — it cannot SSH in and stays that way. The -deploy pipeline uses a **separate, dedicated** SSH-capable account instead -(`deployment-instructions.md` § 1.2), so the two roles never overlap on one credential. Deploy paths -live under that account's own home directory, not under `html/` — this was a deliberate choice to -avoid the CMS's release/current/shared structure interfering with the other websites hosted there. +deploy pipeline uses a **separate, generic, host-wide** SSH-capable account instead +(`deployment-instructions.md` § 1.2) — not one created specifically for this project, since it may +serve other projects' deploy pipelines on the same Pi too (reuse the reference project's existing +account if it already has SSH access). Deploy paths live under that account's own home directory, +namespaced per project, not under `html/` — this was a deliberate choice to avoid the CMS's +release/current/shared structure interfering with the other websites hosted there. ## Rationale for What's Documented Here vs. Already Decided