Camelot Service account

Split “tux” (interactive) from “camelot-svc” (service)

(Production pattern or when Camelot hosts multiple services)

sudo useradd -r -s /sbin/nologin camelot-svc
sudo mkdir -p /srv/music_service
sudo chown -R camelot-svc:camelot-svc /srv/music_service

• camelot-svc runs the daemon via systemd (User=camelot-svc).
• tux develops, deploys, and restarts it with sudo systemctl restart music_service.
• Files, logs, and ports belong only to the service user.
• Much cleaner for audit and eventual handoff.

💡 Use this when: Camelot grows into a multi-service node (wiki, fileman, music, etc.) or when you need to harden boundaries.

🧠 The integrator’s philosophy

“Start rootless, isolate when it matters.”

You can absolutely begin with tux as your active service account — it’s practical, safe in your environment, and gets things running.
If Camelot ever becomes a shared or production node, introduce service accounts then.

🪶 Recommendation for now

✅ Keep /home/tux/music_service
✅ Use systemctl --user (rootless systemd)
✅ Bind to port 8081 or 5000
✅ Let Nginx proxy for it
No need to make tux a service account yet — but when Camelot gains more daemons, create one (camelot-svc) to inherit your Integrator’s Pattern.

Would you like me to show the exact rootless systemd unit that keeps your current tux setup persistent and reboot-safe?