Document ufw rule needed for Umami port 3001 (fixes connection reset by peer)

Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
2026-07-25 23:15:15 +02:00
co-authored by Junie
parent 3ec22f4b9e
commit 00a80cccbb
2 changed files with 31 additions and 2 deletions
@@ -612,3 +612,15 @@
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, clarifying the deployment steps before the Umami container has successfully started on the Pi. Documentation-only change (no code/build impact). **Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, clarifying the deployment steps before the Umami container has successfully started on the Pi. Documentation-only change (no code/build impact).
--- ---
## Post-Completion Follow-up: ufw Firewall Rule Missing for Port 3001 (Connection Reset by Peer)
**Timestamp**: 2026-07-25T23:05:00Z
**User Input**: "ik krijg nu: curl http://192.168.1.103:3001/api/heartbeat curl: (56) Recv failure: Connection reset by peer"
**AI Response**: "Diagnosed via `podman ps`/`podman logs`/`ss -tlnp` that the Umami container and rootlessport forwarder were both healthy and correctly listening on `192.168.1.103:3001`, ruling out an application/container issue. Root cause found in `sudo ufw status verbose`: an explicit `ALLOW` rule exists for `3000/tcp` from `192.168.1.102` (the reverse-proxy Pi), but no equivalent rule exists for `3001/tcp`, and ufw's default incoming policy is `deny` — so the request is blocked even when curled from Pi Main itself, since it targets the real host IP rather than loopback. Added a new firewall step to `umami-setup.md` (`sudo ufw allow from 192.168.1.102 to any port 3001 proto tcp` + `ufw reload`), inserted before the heartbeat-check step, plus a troubleshooting tip to test via `localhost:3001` (bypasses the firewall) to isolate firewall vs. container issues. Added the missing ufw rule to the outstanding manual steps list."
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, resolving a connectivity blocker discovered while the user was testing the Umami container on Pi Main. Documentation-only change (no code/build impact); the actual `ufw allow` command still needs to be run by the user on Pi Main.
---
@@ -73,14 +73,30 @@ onder een eigen `umami`-user te draaien in plaats van je eigen hoofdaccount:
cd ~/umami cd ~/umami
podman-compose up -d podman-compose up -d
``` ```
4. Controleer dat Umami draait en bereikbaar is op het interne netwerk. Let op: de 4. **Firewall (ufw) openzetten voor poort 3001.** Pi Main gebruikt `ufw` met als default
policy `deny incoming` — net als poort `3000` (Gitea) al een expliciete regel heeft
voor het interne IP van de reverse-proxy-Pi, heeft `3001` (Umami) dezelfde regel nodig,
anders krijg je bij het testen `curl: (56) Recv failure: Connection reset by peer`
(ook wanneer je *op Pi Main zelf* naar het publieke IP `192.168.1.103` curl't — dat
gaat namelijk nog steeds via de firewall-INPUT-chain, in tegenstelling tot
`localhost`/`127.0.0.1`):
```bash
sudo ufw allow from 192.168.1.102 to any port 3001 proto tcp
sudo ufw reload
```
Controleer met `sudo ufw status verbose` dat er nu een regel voor `3001/tcp` staat,
analoog aan de bestaande regel voor `3000/tcp`.
5. Controleer dat Umami draait en bereikbaar is op het interne netwerk. Let op: de
**externe** poort is `3001`, niet het gebruikelijke `3000` — die poort is op deze Pi al **externe** poort is `3001`, niet het gebruikelijke `3000` — die poort is op deze Pi al
in gebruik door Gitea (`bind: address already in use` bij het opstarten van de in gebruik door Gitea (`bind: address already in use` bij het opstarten van de
container als je toch `3000` gebruikt): container als je toch `3000` gebruikt):
```bash ```bash
curl http://192.168.1.103:3001/api/heartbeat curl http://192.168.1.103:3001/api/heartbeat
``` ```
Dit zou een JSON-antwoord met `"ok"` moeten teruggeven. Dit zou een JSON-antwoord met `"ok"` moeten teruggeven. Krijg je toch een
`Connection reset by peer`, controleer dan eerst of `curl http://localhost:3001/api/heartbeat`
(dus via loopback, buiten de firewall om) wél werkt — zo ja, dan zit het probleem
zeker in de ufw-regel hierboven en niet in Umami/Podman zelf.
> **Let op — na een wijziging aan `podman-compose.yml`/`.env` (bv. een andere poort):** > **Let op — na een wijziging aan `podman-compose.yml`/`.env` (bv. een andere poort):**
> `podman-compose up -d` update alléén containers waarvan de configuratie is gewijzigd, > `podman-compose up -d` update alléén containers waarvan de configuratie is gewijzigd,
@@ -174,6 +190,7 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
## Openstaande handmatige stappen ## Openstaande handmatige stappen
- [ ] Dedicated `umami`-user aanmaken op Pi Main (incl. subuid/subgid-check en `loginctl enable-linger`). - [ ] 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. - [ ] `podman-compose up -d` daadwerkelijk draaien als de `umami`-user op Pi Main.
- [ ] ufw-regel toevoegen voor poort `3001/tcp` (analoog aan de bestaande `3000/tcp`-regel) op Pi Main.
- [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot. - [ ] 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. - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
- [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login. - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.