Umami self-hosted setup: draai onder eigen dedicated user i.p.v. hoofdaccount
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
@@ -5,15 +5,65 @@ webserver-Pi (Pi Main, `192.168.1.103`) met Podman, en bereikbaar te maken via
|
||||
`analytics.slpsoftware.nl`. Dit vult het "Analytics/uptime dashboard" open item uit
|
||||
`operations/production-readiness-checklist.md` in voor het analytics-gedeelte.
|
||||
|
||||
Umami draait onder een **eigen dedicated Linux-user** (`umami`) in plaats van onder het
|
||||
bestaande hoofdaccount, zodat elke self-hosted service (nu en in de toekomst) netjes
|
||||
geïsoleerd blijft — zie "Waarom een dedicated user" hieronder. Dit patroon kan hergebruikt
|
||||
worden voor volgende self-hosted diensten op dezelfde Pi('s).
|
||||
|
||||
## Vereisten
|
||||
- Podman is al aanwezig op de Pi (bevestigd door de gebruiker).
|
||||
- `podman-compose` geïnstalleerd: `pip3 install --user podman-compose` (of via de package
|
||||
manager van je distro, indien beschikbaar).
|
||||
- Podman is al aanwezig op de Pi (bevestigd door de gebruiker) — systeembreed geïnstalleerd,
|
||||
dus beschikbaar voor elke user, ook een nieuw aangemaakte.
|
||||
- `podman-compose` geïnstalleerd voor de `umami`-user: `pip3 install --user podman-compose`
|
||||
(of via de package manager van je distro, indien beschikbaar) — zie stap 0 hieronder.
|
||||
- DNS: een A-record voor `analytics.slpsoftware.nl` dat naar het publieke IP van de
|
||||
reverse-proxy-Pi wijst (dezelfde Pi die ook `test.slpsoftware.nl` afhandelt).
|
||||
|
||||
## 1. Umami + database opzetten (op de webserver-Pi)
|
||||
1. Maak een map aan, bv. `~/umami/`, en kopieer daarin:
|
||||
## Waarom een dedicated user
|
||||
Podman zelf hoeft niet per user geïnstalleerd te worden (het is een systeembreed pakket),
|
||||
maar rootless Podman-containers erven wél de rechten van de user die ze start. Door Umami
|
||||
onder een eigen `umami`-user te draaien in plaats van je eigen hoofdaccount:
|
||||
- kan een kwetsbaarheid in de Umami-container (zelfs bij een container-escape binnen de
|
||||
rootless-namespace) geen bestanden van je persoonlijke account lezen/schrijven;
|
||||
- houd je containerstorage, systemd user-services en logs van verschillende self-hosted
|
||||
diensten netjes gescheiden per user, ook als je Pi qua rekenkracht beperkt is;
|
||||
- kun je dit patroon straks 1-op-1 hergebruiken voor een volgende self-hosted dienst (bv.
|
||||
een eigen `uptime`-user, `git`-user, etc.), zonder dat diensten elkaars bestanden kunnen
|
||||
benaderen.
|
||||
|
||||
## 0. Dedicated `umami`-user aanmaken (op de webserver-Pi)
|
||||
1. Maak de user aan (zonder wachtwoord-login is prima, we loggen in via `sudo -iu umami` of
|
||||
`su - umami`):
|
||||
```bash
|
||||
sudo useradd --create-home --shell /bin/bash umami
|
||||
sudo passwd -l umami # login met wachtwoord blokkeren, sudo -iu blijft werken
|
||||
```
|
||||
2. Controleer dat er een subuid/subgid-range is toegewezen (nodig voor rootless Podman).
|
||||
Op de meeste moderne distributies (incl. Raspberry Pi OS) gebeurt dit automatisch bij
|
||||
`useradd`:
|
||||
```bash
|
||||
grep umami /etc/subuid /etc/subgid
|
||||
```
|
||||
Zie je geen output, voeg dan handmatig een range toe (pas de startwaarde aan als die al
|
||||
in gebruik is door een andere user):
|
||||
```bash
|
||||
sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 umami
|
||||
```
|
||||
3. Zorg dat de `umami`-sessie blijft "linger-en", zodat rootless Podman-services ook
|
||||
actief blijven zonder dat de user is ingelogd (nodig voor stap 2 hieronder):
|
||||
```bash
|
||||
sudo loginctl enable-linger umami
|
||||
```
|
||||
4. Log in als de nieuwe user om de rest van de setup uit te voeren:
|
||||
```bash
|
||||
sudo -iu umami
|
||||
```
|
||||
|
||||
## 1. Umami + database opzetten (als de `umami`-user, op de webserver-Pi)
|
||||
0. Installeer `podman-compose` voor deze user, indien nog niet systeembreed aanwezig:
|
||||
```bash
|
||||
pip3 install --user podman-compose
|
||||
```
|
||||
1. Maak een map aan, bv. `~/umami/` (dit is nu `/home/umami/umami/`), en kopieer daarin:
|
||||
- `operations/deployment/umami/podman-compose.yml.example` → `~/umami/podman-compose.yml`
|
||||
- `operations/deployment/umami/.env.example` → `~/umami/.env`
|
||||
2. Vul in `~/umami/.env` een echte `POSTGRES_PASSWORD` en `APP_SECRET` in (bv. via
|
||||
@@ -31,13 +81,12 @@ webserver-Pi (Pi Main, `192.168.1.103`) met Podman, en bereikbaar te maken via
|
||||
|
||||
## 2. Automatisch starten na reboot (systemd user service)
|
||||
Podman-compose start niet vanzelf op na een herstart van de Pi, tenzij je dit expliciet
|
||||
instelt. Omdat rootless Podman hier al gebruikt wordt, is een systemd **user**-service de
|
||||
eenvoudigste aanpak:
|
||||
instelt. Omdat rootless Podman hier al gebruikt wordt, is een systemd **user**-service —
|
||||
gekoppeld aan de `umami`-user — de eenvoudigste aanpak. De `loginctl enable-linger umami`
|
||||
uit stap 0.3 is hiervoor al gezet, dus deze service blijft ook draaien zonder dat de
|
||||
`umami`-user zelf is ingelogd.
|
||||
|
||||
1. Zorg dat de gebruiker-sessie blijft "linger-en" na uitloggen/reboot:
|
||||
```bash
|
||||
sudo loginctl enable-linger $(whoami)
|
||||
```
|
||||
1. Log in (of blijf ingelogd) als de `umami`-user: `sudo -iu umami`.
|
||||
2. Maak `~/.config/systemd/user/umami.service` aan:
|
||||
```ini
|
||||
[Unit]
|
||||
@@ -53,7 +102,7 @@ eenvoudigste aanpak:
|
||||
[Install]
|
||||
WantedBy=default.target
|
||||
```
|
||||
3. Activeer en start de service:
|
||||
3. Activeer en start de service (nog steeds als de `umami`-user):
|
||||
```bash
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user enable --now umami.service
|
||||
@@ -102,9 +151,19 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
|
||||
`.env.example`) én verwijder tijdelijk de `import.meta.env.DEV`-check.
|
||||
|
||||
## Openstaande handmatige stappen
|
||||
- [ ] `podman-compose up -d` daadwerkelijk draaien op Pi Main.
|
||||
- [ ] Systemd user-service instellen voor auto-start na reboot.
|
||||
- [ ] Dedicated `umami`-user aanmaken op Pi Main (incl. subuid/subgid-check en `loginctl enable-linger`).
|
||||
- [ ] `podman-compose up -d` daadwerkelijk draaien als de `umami`-user op Pi Main.
|
||||
- [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot.
|
||||
- [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
|
||||
- [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.
|
||||
- [ ] Website aanmaken in Umami en het Website ID overnemen.
|
||||
- [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen.
|
||||
|
||||
## Vervolgstappen voor toekomstige self-hosted diensten
|
||||
Dit dedicated-user-patroon (stap 0 hierboven) is bewust generiek gehouden zodat het
|
||||
hergebruikt kan worden: een volgende self-hosted dienst op dezelfde of een andere Pi kan
|
||||
op dezelfde manier zijn eigen user krijgen (bv. `useradd --create-home`, subuid/subgid
|
||||
controleren, `loginctl enable-linger <user>`, eigen `~/.config/systemd/user/<dienst>.service`),
|
||||
zodat diensten onderling geïsoleerd blijven zonder dat dit ten koste gaat van de
|
||||
al beperkte rekenkracht van een Raspberry Pi (rootless Podman zelf blijft immers
|
||||
systeembreed gedeeld, alleen de user-context verandert per dienst).
|
||||
|
||||
Reference in New Issue
Block a user