Bester Weg für Fileserver (samba)

Das kommt sehr darauf an, wie man die Storage einbindet. Wenn diese "roh" an den Container durchreicht, dann obliegt die komplette Rechtekontrolle dem Container, dann ist das OK. Wenn man die betreffenden Dateisysteme aber direkt unter PVE anlegt und dort auch zugreifbar haben möchte oder muss, dann ist es notwendig, die User unter PVE auch anzulegen. Will man dann einen Container nutzen, muss man entweder jeden User mappen oder den Container privilegiert machen (die User müssen in jedem Fall auch im Container angelegt werden). Im letzten Fall ist die Isolation minimal.

Man hat kurz gesagt also folgende Möglichkeiten:

1. Dateisysteme roh im LXC (oder in der VM, was noch aufwendiger ist) verwalten. Nachteil: das VM-Dateisystem wird, falls nicht die gesamte Storage durchgereicht wird, in einem bestehenden PVE-Dateisystem angelegt. Nehmen wir als Beispiel ZFS in ZFS, weil man "aus Gründen" auf dem PVE ZFS nutzt und auf dem LXC-Fileserver die Möglichkeiten für Snapshots auch haben will. Damit ergeben sich die typischen Probleme: Write Amplification und ggf. zeitgleicher Lauf von Verwaltungstasks wie ZFS Scrub "innen" und "außen".

2. Dateisysteme liegen inkl. Rechten auf dem PVE, weil man dort auch direkten Zugriff haben will oder "aus Gründen" muss. Fileserver als:
a. Unprivilegierter Container. Neben der notwendigen Anlage der User zusätzlich notwendiges Mapping der LXC-User auf PVE-User. Vorteil: LXC-Kapselung.
b. Privilegierter Container. Immer noch User doppelt verwalten, aber kein Mapping. Praktisch kaum noch Kapselung vom PVE, das LXC-User root ist, Nutzen ist also fraglich, bzw. beschränkt darauf, dass nur die gemounteten Pfade zugreifbar sind - natürlich nur, solange kein Breach auftritt.
c. VM. Vorteil: volle Kapselung. Nachteil: Durchreichen der Dateisysteme praktisch nur per NFS möglich - dann braucht man aber doch zumindest NFS mit umfassenden Zugriffsrechten auf dem PVE, das ist also eine Illusion.
d. PVE. Am einfachsten einzurichten, keine Isolation.

Ich finde, bei Betrieb im Heimnetz gibt es gute Gründe für 2d. Man muss nur darauf achten, dass falls Dienste exponiert werden, diese eben selbst eine anständige Kapselung aufweisen (also vorzugsweise VMs oder zur Not unprivilegierte LXCs mit maixmal eingeschränkten Zugriffsrechten nur auf notwendige Storage-Teilbereiche). Daneben eine Backup-Strategie mit "Pull-Charakter", also separater PBS mit "Backup only"-Rechten oder ein zusätzlicher remote-PBS, der alles nur pullt (ich empfehle Buddy-Backup).
 
Das kommt sehr darauf an, wie man die Storage einbindet. Wenn diese "roh" an den Container durchreicht, dann obliegt die komplette Rechtekontrolle dem Container, dann ist das OK. Wenn man die betreffenden Dateisysteme aber direkt unter PVE anlegt und dort auch zugreifbar haben möchte oder muss, dann ist es notwendig, die User unter PVE auch anzulegen. Will man dann einen Container nutzen, muss man entweder jeden User mappen oder den Container privilegiert machen (die User müssen in jedem Fall auch im Container angelegt werden). Im letzten Fall ist die Isolation minimal.

Man hat kurz gesagt also folgende Möglichkeiten:

1. Dateisysteme roh im LXC (oder in der VM, was noch aufwendiger ist) verwalten. Nachteil: das VM-Dateisystem wird, falls nicht die gesamte Storage durchgereicht wird, in einem bestehenden PVE-Dateisystem angelegt. Nehmen wir als Beispiel ZFS in ZFS, weil man "aus Gründen" auf dem PVE ZFS nutzt und auf dem LXC-Fileserver die Möglichkeiten für Snapshots auch haben will. Damit ergeben sich die typischen Probleme: Write Amplification und ggf. zeitgleicher Lauf von Verwaltungstasks wie ZFS Scrub "innen" und "außen".

Nein, das Problem hat man bei einen LXC eben NICHT. Das ZFS ist das gleiche ZFS, was auch auf den Host liegt, eben weil am Ende der container auch nur eine Anwendung im Userspace ist. Sprich: Keine write-Amplification. Im Grunde kann man sich (wenn man die Userverwaltung komplett im Container macht) sogar den Hassle mit den Usern und mapping auf PVE anlegen sparen, nur wenn man die gleichen Dateisets auch an andere Container durchreichen will, muss man das logischerweise. Einziger Nachteil der Variante: Funktioniert nur mit samba, nicht mit nfs (der braucht in der klassischen Variante einen auf dem Host laufenden nfs-kernel-server, theoretisch müsste es möglich sein ganesha im userspace zu betreiben, aber das scheint noch niemand in einen unpriviligierten Container geschafft zu haben und mir fehlt aktuell die Zeit für einen PoC).

b. Privilegierter Container. Immer noch User doppelt verwalten, aber kein Mapping. Praktisch kaum noch Kapselung vom PVE, das LXC-User root ist, Nutzen ist also fraglich, bzw. beschränkt darauf, dass nur die gemounteten Pfade zugreifbar sind - natürlich nur, solange kein Breach auftritt.

Jap, wobei ganesha wohl darin laufen soll und (anders als der nfs-kernel-server) bei einen Crash nicht den ganzen Host mitcrasht. Nur sicher ist das dann halt überhaupt nicht mehr.
c. VM. Vorteil: volle Kapselung. Nachteil: Durchreichen der Dateisysteme praktisch nur per NFS möglich - dann braucht man aber doch zumindest NFS mit umfassenden Zugriffsrechten auf dem PVE, das ist also eine Illusion.

Gegen VMs spricht vor allen, dass man da dann entweder tatsächlich die Problematik mit write-Amplification hat plus der Notwendigkeit (falls man TrueNas o.ä. einsetzen will) einen Storage-Controller durchreichen zu müssen.
 
Lies nochmal genau, Johannes. Nummer 1 meint "roh", also nicht die normalen Ressourcen. Das Problem mit der Write Amplification hat man nicht bei Variante 2a oder 2b.

Nummer 1 sind die Varianten mit passthru, Nummer 2 mit logischem Zugriff jedweder Art, also 2c wären NFS-Mounts. Was Du sagst, bezieht sich auf Nummer 1 bei Einsatz mit VMs.
 
Lies nochmal genau, Johannes. Nummer 1 meint "roh", also nicht die normalen Ressourcen. Das Problem mit der Write Amplification hat man nicht bei Variante 2a oder 2b.

Wie soll das "roh" mit lxcs überhaupt gehen, dass das Problem auftritt? Wenn man die devices durchreicht, hat man doch keine write-Amplification (ich würde es trotzdem nicht tun, anderes Thema), irgendwie stehe ich da gerade auf der Leitung ;) Und du hattest in deinen Post erst lxcs erwähnt, nicht VMs. Und auch bei VMs hast du mit durchgereichten Devices ja das Problem nicht, wenn man natürlich der VM virtuelle Platten zuweist (die dann in ZFS erstellt werden) und dann in der VM die dann wieder mit zfs, dann ist man auch selbst Schuld ;)
Aber darum ging es den OP ja nicht, die Frage war "lxc oder direkt auf den Host", mit Vms hat das nichts zu tun.
 
Ich wollte nur meinen Gedankengang bei der Zielsetzung: "Wie bekomme ich es möglichst sicher hin, die auf einem PVE vorhandene physische Storage an VMs, LXCs und im meinem Heimnetz vorhandene Clients freizugeben?" beleuchten. Das entspricht exakt dem Threadtitel.

Das sind m.E. alle potentiell möglichen Varianten, die ich nur aufgezählt habe, um zu zeigen, dass man einen Zielkonflikt hat, weil es die perfekte Lösung nicht gibt. Und wenn man sich das strukturiert klarmacht, kommt Variante 2d in bestimmten Kontexten gar nicht so schlecht weg. Ob jemand für höhere Sicherheit im Heimnetz den zusätzlichen Aufwand treiben will, muss er selbst wissen.
 
  • Like
Reactions: Johannes S
Alles gut, ich bin nur über "Dateisysteme roh im LXC (oder in der VM, was noch aufwendiger ist) verwalten. " gestolpert, da man diese rohe Verwaltung innerhalb eines Containers halt nicht hat, für VMs bin ich ja ganz bei dir.
 
  • Like
Reactions: meyergru
Zu 2c) noch eine Ergänzung. Mit virtiofs gibt es mittlerweile auch eine Möglichkeit Daten an VMs durchzureichen, ohne dafür NFS oder samba auf den Host laufen zu lassen. Es ist allerdings den Berichten nach deutlich langsamer, aber je nach Datenmengen und Usecase muss das ja nicht unbedingt stören:
 
  • Like
Reactions: UdoB and meyergru