SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity

Makes the deploy account generic instead of per-project

Browse Source 
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.
This commit is contained in:
Sluijsens
2026-07-28 19:46:58 +02:00
parent 2f243f23c3
commit 960760c24e
3 changed files with 36 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md
+19 -13
View File
@@ -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-<env>/`), so one generic account can serve multiple
projects without their release trees colliding.
The rest of this document uses `<deploy-user>` — 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 `<deploy-user>` — 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 | `<deploy-user>` — the new dedicated account (§ 1.2), **not** `webadmin` |
| `PI_MAIN_USERNAME` | secret | `<deploy-user>` — the generic, host-wide deploy account (§ 1.2), **not** `webadmin`; reuse the reference project's if it already has one |
| `PI_MAIN_PASSWORD` | secret | `<deploy-user>`'s password |
| `DEPLOY_PATH_TEST` | variable | `/home/<deploy-user>/apps/slpmodularcms-test` |
| `DEPLOY_PATH_PRODUCTION` | variable | `/home/<deploy-user>/apps/slpmodularcms-production` |
aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-plan.md
+6 -4
View File
@@ -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