Best-Practice: mehrere Services auf einem Server

Hallo zusammen,

ich bin kein Fan von Docker und Co. und habe daher auf meinem Debian-Server (11) im Heimnetz mehrere Services nativ installiert und spreche diese mit nginx als Reverse-Proxy an. Die lokalen Domains (z.B. nextcloud.raspi4.fritz.box, matrix.raspi4.fritz.box,…) werden von meinem Pihole über „Local DNS Records“ aufgelöst.

Das funktioniert ganz gut, ich würde jedoch gerne die Services besser isolieren und das ganze Setup dadurch sicherer machen.

Mein grundsätzliches Vorgehen für einen zusätzlichen Dienst:

  1. eigener User anlegen mit eigenem Home-Verzeichnis, ohne Login-Möglichkeit
  2. Dienst installieren, Datenbank aufsetzen etc., Konfig-Dateien usw. ins Homeverzeichnis des Users
  3. Dienst per unix:socket oder localhost&Port an den Reverse-Proxy (nginx) weiterleiten. TLS-Zertifikat pro Dienst verwenden.
  4. Dienst per systemd als service starten. User in der Service-Datei angeben.

Wie kann ich das Vorgehen optimieren oder gibt es Best-Practices?
Freu mich über Hinweise!

Grüße Jim

1 „Gefällt mir“

Auch wenn Du Container und VMs nicht zu mögen scheinst wären Linux-Container vielleicht einen Blick wert.

https://linuxcontainers.org/

Das von Dir angedachte Verfahren klingt ungewöhnlich. Normalerweise würde man virtualisieren - entweder mit LXC - Link wurde schon genannt - oder mit libvirt/KVM. Geht beides mit Debian von Haus aus und hat mit Docker nix zu tun. Ich finde libvirt mit virtmanager bequemer, aber die Meinungen variieren. Viele Leute nehmen auch proxmox als Oberfläche, dann kann man je nach Bedarf beides verwalten, libvirt und lxc.

2 „Gefällt mir“

LXC hört sich gut an bzw. scheint auch nicht allzu komplex zu sein. Danke euch Zwei!

Wenn ich es richtig lese besitzt jeder Container seinen eigenen Anwendungen.
LXC bringt also zusätzlichen overhead mit, welcher bei knappen Ressourcen wie einem Raspberry Pi Probleme zu weniger Leistung führt? (bei VM vermutlich noch mehr)

Wenn ich alles nativ installieren habe ich ja gerade den Vorteil, dass ich z.B. einmal MariaDB installieren und mehrere Anwendungen es nutzen können als Datenbanksystem. (das gleiche für einen Proxy, PHP usw.)??

oh ok, es ist ein RasPi - dann scheidet libvirt/KVM aus, würde ich sagen. LXC bringt weniger overhead, weil es den kernel mit dem darunterliegenden System teilt. Anstelle von Proxmox gibt es dafür Pimox. Wahlloser Griff ins Internet: https://www.veuhoff.net/proxmox-auf-den-raspberry-pi-4-pimox-7-installation-tutorial/

okay ich bin überzeugt :wink:

d.h. ich installiere auf meinem Host firewall, fail2ban,… + nginx. Erzeuge dann pro Service einen „LXC-Container“, installiere dort den Hauptdienst plus alle Abhängigkeiten und leite dann per nginx (vom host) zu den containern?

nene. lxc teilt sich nur den kernel. Alles andere (firewall, fail2ban,… + nginx) kommt einzeln und der container verhält sich dann wie eine VM.

Hast Du Dir Pimox mal angeschaut? Ich weiß nicht, wie gut Dein terminal-fu ist …

Das ist überhaupt nicht ungewöhnlich. Unixer machen das schon seit vielen Jahrzehnten so. Früher hätte man noch ein chroot pro Dienst angelegt. Auf etwas altmodischeren Unixen wie OpenBSD ist das auch weiterhin noch üblich und bisher hat niemand behauptet, OpenBSD wäre nicht sicher. :grinning: Also chroot kann man gerne weiterhin benutzen, aber unter Linux ist systemd-nspawn eine interessante Alternative und bietet ähnliche Vorteile wie LXC & Co, soll aber einfacher aufzusetzen sein (habe es selbst noch nicht probiert).

Ja, vielleicht ist der Vorschlag von @elfchen besser. ich kenne mich mit den begrenzten Ressourcen beim Pi nicht so aus.

nspawn hört sich auch sehr interessant an und wirkt im Wiki von Debian recht intuitiv.

@elfchen hat du auch eine Empfehlung für das grobe Setup? Strikt die Services in Container packen, oder z.b. gemeinsam die Firewall des Hosts nutzen,…?

Das „Containern“ wirkt schon sehr sinnhaftig, aber es macht halt alles schon auch komplexer (jeder Gast muss separat konfiguriert werden, d.h. mehr Konfigs → mehr Fehler, jeder Gast muss unabhängig auf dem aktuellen Stand gehalten werden, usw.)

Ich würde möglichst nah an den von nspawn gewählten Voreinstellungen bleiben, aber zur Netzwerkkonfiguration kann ich mangels Erfahrung auch nichts sagen.

Ich werde es am WE einfach mal ausprobieren, Danke!

Parallel dazu schau ich mir nochmal die Doku von uberspace an:

Wenn ich es richtig verstehe, bekommt dort ein neuer Acccount ein eigenes home-Verzeichnis auf der Serverinstanz (readonly vom user selbst). Getrennt bzw. isoliert werden die Accounts dann per network-namespaces. Systemd-services werden als user aus dem user-Verzichnis ausgeführt.

Erscheint mir auch als ein schönes Konzept… wobei, wenn man sich den manuellen Aufwand mit network-namespaces macht, man gleich auf lxc oder systemd-nspawn setzen kann :confused:

Hallo @thomasmerz
Ich hoffe mal ich verstoße hier nicht gegen eine Regel dieses Forums wenn ich mich hier mit einer Frage an Dich dranhänge…
Auf Deiner Website beschreibst Du sehr schön wie man mit dem Skript padd.sh zusätzliche Information zum Pihole Status abfragen bzw. anzeigen lassen kann. Allerdings setzt Du dabei eine Docker basierte Installation von Pihole voraus.
Ich habe Pihole in einer Debian VM (Minimalinstallation ohne GUI) ohne Docker laufen. Das padd.sh Skript funktioniert auch in dieser VM. Die beiden von Dir beschriebenen Ergänzungen bzw. Dateien „pihole-live-output.service“ und „pihole-padd.service“ habe ich ebenfalls unter „/etc/systemd/system“ eingefügt und jeweils mit systemctl start gestartet. Dann allerdings passiert …nichts…keine Anzeige im Terminal.
Kann es sein, dass es für die Anzeigefunktion zwingend erforderlich ist, dass Pihole in Docker läuft ?

Hallo @anon92514140,

Es passt zwar wirklich nicht mehr zum ursprünglichen Thread-Thema, aber mal schauen ob es geduldet wird :man_shrugging:

Im offiziellen Pi-hole Docker Container kommt padd.sh schon mit, aber du kannst dir das auch direkt von https://github.com/pi-hole/PADD runterladen und direkt auf deiner VM auch ganz ohne Container-Krams nutzen.

Wenn du die von mir beschriebenen Ergänzungen „pihole-live-output.service“ und „pihole-padd.service“ gestartet hast, siehst Du auf der jeweiligen Text-Console deren Live-Output indem du mit STRG+ALT+F10/F11 dorthin schaltest. Ich finde das mega-praktisch für meine Cloudserver (und auch zuhause), so dass ich jederzeit mal schnell dort rein-/draufschauen kann :slight_smile:

Und mit STRG+ALT+F7 solltest du wieder in deine gewohnte grafische Oberfläche kommen.

Danke für die schnelle Antwort…
Ich logge mich von meinem MacBook aus mit dem Terminal über eine SSH-Verbindung auf den pihole-server (VM) ein.
Das von Dir beschriebene Umschalten (STRG-ALT-F10/F11) klappt aber leider nicht mit der Mac-Tastatur. Einen Terminalbefehl hierfür habe ich bislang nicht gefunden. Suche weiter…

Wenn du dich per ssh anmeldest bekommst du nicht die Consolen („tty“) zu Gesicht, auf die du sowohl den Input als auch den Output umgeleitet hast. Wenn du zuhause ein Linux hast (hast du?), dann kannst du ja mal STRG+ALT+F1…12 drücken und dich durch die verschiedenen (lokalen) Consolen schalten (F7 sollte die grafische Oberfläche („dein Desktop“) sein, F12 das Systemlog und F1-F6 sind für normale Anmeldungen gedacht. F10-11 sind i.d.R. nicht belegt und daher bietet es sich an sie mit was Sinnvollem zu aktivieren :slight_smile:

ssh läuft auf einem sog. Pseudoterminal („pts“), womit wir schon den Unterschied erkannt haben. tty = lokale session, pts = remote-session.

Um dir aber nicht den schönen Output vorzuenthalten kannst Du folgendes machen:

systemctl status pihole-* sollte dir u.a. diese Zeilen zeigen:

/usr/bin/sh -c "/usr/bin/docker exec -it pihole pihole -t > /dev/tty10 < /dev/tty10"
bzw.
/usr/bin/sh -c "/usr/bin/docker exec --tty pihole padd -xoff 0 -yoff 0 > /dev/tty11 < /dev/tty11"

Diese kannst du in den Dateien „pihole-live-output.service“ und „pihole-padd.service“ wie folgt ändern:

/pfad/zu/pihole -t
bzw.
/pfad/zu/padd.sh -xoff 0 -yoff 0

Nun kannst du nach systemctl daemon-reloadmittels journalct -u pihole-live-output.service bzw. journalctl -u pihole-padd.service den Output sehen. Oder du startest padd.sh einfach direkt dann, wenn du es „brauchst“.

Have fun! :+1:

@thomasmerz , danke Dir für diese ausführliche Anleitung. Habe ich heute ausprobiert und klappt einwandfrei !