Proxmox VE: Ubuntu Server als Linux Container (LXC) installieren und einrichten

Proxmox Logo

In den letzten Artikeln ging es um die Installation und Grundeinrichtung von Proxmox Virtual Environment und die Installation eines Ubuntu Servers als virtuelle Maschine. Neben der „normalen“ Virtualisierung mittels virtueller Maschinen unterstützt Proxmox VE darüber hinaus auch noch LXC-Container: Die Virtualisierung mittels LXC ist dabei viel ressourcenschonender als die Nutzung von virtuellen Maschinen – man kann sich eine LXC-Maschine also als „VM light“ denken. Ebenso bietet dieses Format auch weitere Vorteile, aber auch ein paar Nachteile, auf die ich näher im Artikel eingehen werde.

In diesem Beitrag soll nun die Einrichtung eines Ubuntu Servers als LXC-Containers auf Proxmox VE gezeigt werden.

Update-Historie (letztes Update: 13.01.2023)
  • 13.01.2023:
    • Hinweis für Update der Container-Templates mittels Konsolenbefehl hinzugefügt.

LXC vs virtuelle Maschinen

Zunächst soll kurz auf die Unterschiede zwischen einem LXC-Container und einer virtuellen Maschine eingegangen werden.

Wie der Name schon sagt, handelt es sich bei LXC um eine Art der Virtualisierung, die auf Containern basiert. Bei diesem Begriff wird der eine oder andere sicherlich gleich an Docker denken, denn dadurch hat das Konzept der Container erst richtig Fahrt aufgenommen. Ziel dieser (Docker-)Container ist es meistens, eine spezielle Anwendung auf eine einfache Art und Weise deployen zu können.
Einen LXC-Container kann man sich nun in etwa wie einen Docker-Container vorstellen, nur dass LXC das Betriebssystem an sich nicht so strikt wegkapselt. Das Arbeiten per SSH auf einer LXC-Maschine ist im Gegensatz zu einem Docker-Container ganz normal und fühlt sich an wie auf einer echten Maschine – man arbeitet quasi direkt auf dem Betriebssystem des LXC-Containers. Dies grenzt diese Technologie von Docker ab.

Im Vergleich zu einer „echten“ VM ist ein LXC-Container sehr leichtgewichtig. Dies ist darin begründet, weil diese Container nativ auf dem Host-Betriebssystem laufen. D.h. vereinfacht ausgedrückt: Ein LXC-Container nutzt den Kernel des Host-Systems und bringt daher keinen eigenen Kernel mit. Für einen LXC-Container muss daher auch keine Hardware aufwändig emuliert werden (wie dies bei einer VM notwendig ist). Durch dieses Konzept entsteht kaum Overhead durch die Virtualisierung und ein LXC-Container benötigt viel weniger Ressourcen als eine schwergewichtige VM.

Warum virtualisiert man dann nicht gleich alle Maschinen über LXC?
Der VM-Host stellt für jeden LXC-Container eine Isolierte Umgebung bereit, jedoch ist der Grad der Isolation nicht so vollständig wie bei einer VM. Hier wird zunächst zwischen privilegierten und unprivilegierten LXC-Containern unterschieden. Bei unprivilegierten Containern ist die Isolationsstufe zwar höher, allerdings sind einige Features nicht verfügbar: Alle Komponenten, die bestimmte Kernel-Module benötigen sind auf einem unprivilegierten Container nicht lauffähig. Beispielsweise ist es bei hier nicht möglich, einen NFS-Server aufzusetzen, da das benötigte Paket (nfs-kernel-server) ein Kernel-Modul darstellt. Um hier z.B. trotzdem einen NFS-Server aufsetzen zu können, muss es sich um einen privilegierten LXC-Container handeln. Dies bricht allerdings die Isolation zwischen Host und LXC-Container etwas auf.

Wem also gerade die Isolierung des Systems wichtig ist, sollte eher eine virtuelle Maschine einsetzen.

Zu guter Letzt ist man bei der Nutzung von LXC-Containern – wie der Name ja bereits andeutet – auf die Linux-Welt beschränkt. Ein Windows lässt sich nicht mittels LXC virtualisieren.

Nach diesem kleinen Exkurs über die Unterschiede zwischen LXC-Container und virtuellen Maschinen soll es nun an die Praxis gehen.

Vorbereitung: Container-Template herunterladen

Für eine LXC-Maschine benötigt man zunächst ein Container-Template. Diese Templates sind nichts anderes als tar-Archive, die alles beinhalten, um einen Container in Betrieb nehmen zu können.

Dazu wählen wir in der Weboberfläche von Proxmox einfach einen Storage, der zum Speichern von Templates genutzt werden kann. Hier findet man dann den Eintrag Container-Templates.
Mehr zum Thema Storages und wie diese angelegt und genutzt werden können, wurde bereits im Artikel über die Proxmox VE Installation behandelt.

Proxmox: Verwaltung von LXC-Container-Templates auf dem lokalen Storage
Proxmox: Verwaltung von LXC-Container-Templates auf dem lokalen Storage

Mit einem Klick auf Templates kann man sich die verfügbaren Templates anzeigen lassen. Zur Auswahl stehen hier verschiedene Templates, die auf den unterschiedlichsten Distributionen basieren. Da wir einen Ubuntu Server (20.04 LTS) als LXC-Container betreiben wollen, wählen wir hier den Eintrag ubuntu-20.04-standard:

Proxmox: Download des Templates für Ubuntu 20.04 LTS
Proxmox: Download des Templates für Ubuntu 20.04 LTS

Der Download geht dabei recht schnell, da das Template lediglich ca. 200 MB groß ist. Das Fenster mit der Fortschrittsanzeige des Downloads kann man auch schließen, der Download läuft dann im Hintergrund weiter.
Anschließend wird dieses Template dann in der Template-Übersicht angezeigt.

Diese Container-Templates werden von Zeit zu Zeit auch aktualisiert. Um die Liste mit den Templates zu aktualisieren, ist auch dem Proxmox-Host folgender Befehl in der Kommandozeile einzugeben:

pveam update

Danke an den Leser John für diesen Hinweis!

LXC-Maschine erstellen

Da nun ein LXC-Template verfügbar ist, können wir die Maschine nun anlegen. Der Einrichtungsprozess unterscheidet sich hierbei deutlich von der Einrichtung einer virtuellen Maschine und gestaltet sich viel einfacher.

Rechts oben findet man dazu den Button Erstelle CT:

Proxmox: Eine neue LXC-Maschine erstellen
Proxmox: Eine neue LXC-Maschine erstellen

Beim Erstellen einer LXC-Maschine gibt es wieder einige Optionen zu beachten. Im Folgenden werden wieder sämtliche relevanten Funktionen erklärt und ggf. eine Empfehlung genannt.

Im ersten Schritt werden die allgemeinen Einstellungen festgelegt. Hier sollten wieder die erweiterten Optionen (unten rechts) eingeschaltet werden:

Proxmox: LXC erstellen (Allgemein)
Proxmox: LXC erstellen (Allgemein)
  • Knoten: Gibt die Proxmox-Instanz im Rechenzentrum an, auf dem die Maschine laufen soll.
  • CT ID: Die ID des LXC-Containes. Diese kann beliebig gesetzt werden, muss aber eindeutig sein.
  • Hostname: Der Hostname des LXC-Systems.
  • Unprivilegierter Container: Dies ist ein Sicherheits-Feature, welches dafür sorgt, dass UID des Users root (im Container) auf einen unprivilegierten Benutzer (am Host) gemappt wird. Damit wird generell verhindert, dass der LXC-Gast auf irgendeine Art auf das Host-System zugreifen kann. Diese Option sollte eigentlich immer aktiviert werden, es sei denn, ein Programm/Feature innerhalb des Containers ist in einem solchen unprivilegierten Container nicht lauffähig.
    Hinweis: Diese Option ist einer der wenigen, die nach der Einrichtung eines LXC-Containers nicht mehr geändert werden kann. Weiter unten zeige ich allerdings eine Möglichkeit, wie man einen unprivilegiertem in einen privilegierten Container umwandeln kann.
  • Nesting: Erlaubt es, im Container selbst wiederum Virtualisierungs-Features zu nutzen. Dies ist in der Regel nur sinnvoll, wenn man innerhalb eines LXC-Containers z.B. Docker-Container betreiben möchte. Hier wäre dann eine VM vermutlich aber die bessere Wahl, daher kann diese Option in den meisten Fällen deaktiviert werden.
  • Kennwort: Das Passwort des root-Users der LXC-Maschine.
  • Öffentlicher SSH-Schlüssel: Wenn man einen SSH-Key zum verbinden auf den Container nutzen möchte, kann man diesen hier angeben.

Anschließend wird das zu verwendende Template angegeben:

Proxmox: LXC erstellen (Template)
Proxmox: LXC erstellen (Template)

Hier wählt man einfach den Storage, auf dem das gewünschte Template gespeichert ist und wählt anschließend das Template selbst aus.

Im nächsten Schritt werden die Festplatten des Systems konfiguriert:

Proxmox: LXC erstellen (Disks)
Proxmox: LXC erstellen (Disks)
  • Storage: Gibt den Storage an, auf dem die virtuelle Festplatte gespeichert werden soll.
  • Disk-Größe: Die Größe der Festplatte. Hier können sehr viel kleinere Größen als bei VMs gewählt werden, da die Grundinstallation eines LXC-Containers meist sehr klein ist.
    Hinwies: Die Disk-Größe kann auch nach der Erstellung des LXC-Containers ganz einfach angepasst werden (s.u.).
  • Mount Optionen: Legt die Optionen fest, mit der die Festplatte im LXC-Container gemountet wird. Hier spielt das Speichermedium, auf dem die virtuelle Festplatte gespeichert ist, eine entscheidende Rolle. Handelt es sich dabei um einen Flash-Speicher (SSD, MVMe, etc.), dann kann man hier die Option noatime setzen. Dies reduziert in der Theorie deutlich die Schreibzugriffe auf das Medium, da die Zugriffszeiten nicht bei jedem Dateizugriff gespeichert sind. Jedoch funktionieren damit u.U. einige Programme nicht richtig. Meine Empfehlung ist hier die Option lazytime, bei der Zugriffe gespeichert werden, dies allerdings im RAM geschieht und damit den Flash-Speicher nicht belasten sollte.
    Die dritte Option nosuid sorgt dafür, dass SUID und SGID nicht berücksichtigt werden. Diese Option wird meistens nicht benötigt.
  • ACLs: Wenn ACLs (Access Control Lists) im Container zum Einsatz kommen sollen, kann diese Option hier explizit aktiviert werden.

Anschließend werden die CPU-Optionen festgelegt:

Proxmox: LXC erstellen (CPU)
Proxmox: LXC erstellen (CPU)

Hier ist eigentlich nur die Anzahl der virtualisierten CPU-Kerne wichtig. Dies ist in den meisten Fällen von den Anforderungen der LXC-Maschine abhängig.

Es folgt die Festlegung des Speichers des LXC-Systems:

Proxmox: LXC erstellen (Speicher)
Proxmox: LXC erstellen (Speicher)

Hier wird die Größe von Speicher und Swap-File angegeben. Dies ist wiederum sehr vom Einsatzzweck des Systems abhängig. Dennoch gilt auch hier: Ein LXC-Container benötigt in der Regel sehr viel weniger Systemressourcen, daher kann der Speicher hier auch eher knapp bemessen werden. Bei Bedarf kann der zur Verfügung stehende Speicher jederzeit erhöht werden.

Nun werden die Netzwerk-Einstellungen konfiguriert:

Proxmox: LXC erstellen (Netzwerk)
Proxmox: LXC erstellen (Netzwerk)

Hier gibt es im Normalfall auch nicht viel zu beachten, es sollte lediglich eine statische IPv4-Adresse vergeben werden. Diese muss hier in der CIDR-Notation angegeben werden. Ebenfalls muss die IP des Gateways hinterlegt werden (meist die IP des Routers).
Alternativ kann man hier DHCP verwenden, was aber dafür sorgen kann, dass die IP-Adresse des Systems nach einem Neustart ändert (für Webanwendungen o.ä. eher nicht zu empfehlen).
Die Einstellungen für IPv6 können im Allgemeinen einfach leer gelassen werden, es sei denn, man braucht für den LXC-Container eine IPv6-Adresse.

Im letzten Schritt können noch DNS-Einstellungen festgelegt werden:

Proxmox: LXC erstellen (DNS)
Proxmox: LXC erstellen (DNS)

Hier ist die Voreinstellung verwende Werte vom Host meist schon korrekt. Man kann hier aber auch einen anderen DNS-Server eintragen, um beispielsweise einen im Netzwerk verfügbaren Pi-hole explizit nicht zu verwenden.

Ganz am Ende werden die gewählten Einstellungen des Containers noch einmal aufgelistet und man kann die Erstellung mit einem Klick auf Abschließen fertig stellen.

Proxmox: LXC erstellen (Bestätigen)
Proxmox: LXC erstellen (Bestätigen)

Nun werden die Inhalte des LXC-Templates extrahiert und nach einer kurzen Wartezeit ist der LXC-Container verfügbar.

Sämtliche Optionen können (wie auch schon bei VMs) noch nachträglich in den Optionen des LXC-Containers geändert werden.

Start des LXC-Containers und Zugriff per SSH

Nach der Einrichtung kann der LXC-Container auch gleich gestartet werden. Dies funktioniert wieder analog zu virtuellen Maschinen mit einem Klick auf Start:

Start des LXC-Containers
Start des LXC-Containers

Der Button Konsole öffnet nach dem Start eine Konsole in einem neuen Browser-Fenster:

SSH-Zugriff auf den LXC-Container (Browser)
SSH-Zugriff auf den LXC-Container (Browser)

Der Benutzername lautet hier übrigens immer root (diesen konnten wir ja beim Erstellen des LXC-Containers gar nicht explizit angeben).

Da man aber nicht immer über die „Browser-Konsole“ gehen, sondern die SSH-Verbindung direkt im Terminal aufbauen möchte, ist hier noch etwas Nacharbeit notwendig. Denn beim Versuch, sich direkt per SSH mit der Maschine zu verbinden, erhalten wir eine Fehlermeldung „Permission denied“.

Fehlermeldung "Permission denied" beim direkten Zugriff per SSH
Fehlermeldung „Permission denied“ beim direkten Zugriff per SSH

Begründet liegt dies darin, dass der SSH-Zugriff mit dem User root standardmäßig unterbunden wird. Hier haben wir nun zwei Möglichkeiten (beides muss zunächst über die Browser-Konsole durchgeführt werden):
Empfohlen ist die Anlage eines neuen Benutzers und ggf. das Hinzufügen dieses Users in die sudo-Gruppe.

adduser jan

Nach der Festlegung des User-Passworts werden noch einige Informationen zum User abgefragt.
Anschließend kann der User dann noch in die „sudoers“ mit aufgenommen werden, damit dieser dann Befehle mit Root-Rechten ausführen kann:

usermod -aG sudo jan

Anschließend kann sich der User „jan“ auch über das Terminal mit dem LXC-Container verbinden.

Alternativ kann man den SSH-Zugriff für den User root zulassen. Dazu muss die Konfiguration des SSH-Dienstes angepasst werden:

nano /etc/ssh/sshd_config

Hier wird die Option PermitRootLogin folgendermaßen angepasst:

PermitRootLogin yes

Es fehlt noch ein Neustart des SSH-Dienstes, anschließend kann man sich auch direkt per root-User auf der Maschine anmelden:

service sshd restart

Nun kann man ganz gewohnt per SSH auf der Maschine arbeiten, ganz so, als wäre es eine echte virtuelle Maschine – eben nur mit den eingangs erwähnten Unterschieden.

Das Arbeiten mit LXC-Containern

Wir haben nun einen ersten LXC-Container erfolgreich in Betrieb genommen. Es folgen nun ein paar Punkte, die man beim Arbeiten mit LXC-Containern beachten sollte. Ebenso werden einige Tätigkeiten beschrieben, die beim Umgang mit LXC-Containern interessant sein könnten.

Update des LXC-Containers

Nach der Installation und dem Start des Containers sollte dieser erst einmal mit Updates versehen werden. Die wird genau so wie bei einer normalen Ubuntu-Installation durchgeführt:

apt update && apt upgrade -V && apt autoremove

Das erste Update dürfte dabei etwas länger dauern, da vermutlich viele Pakete ein Update bereits stellen.

Wenn ein Distributions-Update ansteht (z.B. von Ubuntu 20.04 auf 22.04), kann dieses Update auch auch die gewohnt Art und Weise durchgeführt werden:

do-release-upgrade

Da es sich „nur“ im einen LXC-Container handelt, laufen diese Updates in der Regel auch deutlich schneller als auf einer echten Maschine ab.

Festplatte eines LXC-Containers nachträglich vergrößern

Wie weiter oben bereits erwähnt, kann man die Größe der Festplatte eines LXC-Containers nachträglich noch anpassen. Daher ist es auch nicht weiter schlimm, wenn man sich bei der initialen Festplatten-Größe etwas verschätzt hat und der Container nun deutlich mehr Platz brauchen sollte.
Das Ganze funktioniert übrigens im laufenden Betrieb, d.h. die LXC-Maschine muss dazu nicht einmal herunter gefahren werden.

Dazu geht man einfach in die Ressourcen-Übersicht eines LXC-Containers:

Festplatten-Einstellungen eines LXC-Containers
Festplatten-Einstellungen eines LXC-Containers

Hier wählt man nun die zu ändernde Festplatte aus und Klick anschließend auf Resize Disk. Im daraufhin erscheinenden Dialog kann man nun die Größe wählen, um die die Festplatte geändert werden soll:

Vergrößerung der Festplatte bei einem LXC-Container
Vergrößerung der Festplatte bei einem LXC-Container

Mit der Bestätigung der Größen-Änderung ist der Prozess auch schon abgeschlossen und die Maschine verfügt sofort über mehr Platz auf der Festplatte.

Einen unprivilegierten LXC-Container in einen privilegierten Container umwandeln

Wie gesagt sollte man einen LXC-Container eigentlich immer als unprivilegierten Container laufen lassen. Nun kann es aber vorkommen, dass man nachträglich nun doch z.B. einen NFS-Server auf den Container betreiben möchte. Hier braucht man normalerweise nur das Paket nfs-sever installieren:

apt install nfs-server

Wenn man dies jedoch in einem unprivilegiertem Container versucht, bekommt man die recht seltsame Fehlermeldung „Dependency failed for RPC security service for NFS client and server“ (oben sieht man noch den Inhalt des Syslogs):

Fehler beim Ausführen eines NFS-Servers auf einem unprivilegiertem LXC-Container
Fehler beim Ausführen eines NFS-Servers auf einem unprivilegiertem LXC-Container

Dies liegt nun einfach daran, dass der NFS-Server über ein Kernel-Modul bereit gestellt wird. Und dies ist bei einem unprivilegiertem Container nun mal nicht möglich.

Als müsste man auf diesem Container nun einen privilegierten Container machen. Das Flag unprivilegiert/privilegiert kann allerdings nicht einfach in den Optionen eines LXC-Container umgestellt werden.
Es gibt allerdings doch eine Möglichkeit, diese Umwandlung vorzunehmen. Diese ist jedoch nicht gerade einleuchtend, daher möchte ich euch die Schritte zeigen, die dazu notwendig sind.

Dazu muss zunächst ein Backup des umzuwandelnden Containers erstellt werden. Der Storage, auf dem dieses Backup angefertigt wird, ist dabei egal.
Nun kann bei der Wiederherstellung des Backups die Privilegienstufe ausgewählt werden:

Wiederherstellung als privilegierter LXC-Container
Wiederherstellung als privilegierter LXC-Container

Auf diese Weise kann man einen unprivilegierten Container schnell und einfach einen privilegierten Container umwandeln.

Hat man nun einen privilegierten Container, kann man hier nun einfach in den Optionen unter Features die Option NFS setzen und schon kann auch auf einem LXC-Container ein NFS-Server installiert werden (s.o. – hier wird nun aber keine Fehlermeldung mehr erscheinen).

Hinzufügen des Features NFS bei einem privilegiertem Container
Hinzufügen des Features NFS bei einem privilegiertem Container

Eigene LXC-Templates erstellen

Wenn man nun häufiger LXC-Container mit einem bestimmten Feature-Umfang benötigt, besteht die Möglichkeit, eigene LXC-Templates zu erstellen. Als Beispiel nehme ich hier den oben genutzten Container mit Ubuntu 20.04 als Basis. Auf diesen wurde nun ein LEMP-Stack (Linux, nginx, MariaDB, PHP) installiert, damit verschiedene Webanwendungen schnell deployt und getestet werden können.
Nun gibt es zwei Möglichkeiten, aus diesem Container ein Template zu erzeugen, welches als Basis von weiteren Containern dienen kann.

Variante 1: Der bestehende Container kann über einen Rechtsklick einfach in ein Template umgewandelt werden.

LXC-Container in Template umwandeln
LXC-Container in Template umwandeln

Das so erzeugte Template bleibt im Rechenzentrum bestehen und sieht hier erst einmal aus wie ein normaler LXC-Container. Jedoch kann man das Template nicht mehr starten, da es nun ja kein Container mehr ist.
Um aus diesem Template nun einen neuen Container zu erstellen, kann man dieses Template klonen (wieder mit einem Rechtsklick auf das Template).

LXC-Container per Klon aus einem Template erstellen
LXC-Container per Klon aus einem Template erstellen

Hier wird dann hauptsächlich eine neue ID und ein Hostname für den zu erstellenden LXC-Container vergeben. Unter Modus kann man wählen, ob es sich um einen komplett unabhängigen Klon handelt (Option vollständiger Klon), oder um einen verknüpften Klon. Ein verknüpfter Klon ist in der Regel schneller erstellt, denn es müssen nicht sämtliche Daten kopiert werden. Wenn man den neuen Container allerdings auf einem anderen Storage speichern möchte, sollte man die Option vollständiger Klon wählen.

Variante 2: Das gezeigte Vorgehen unterscheidet sich nun ein wenig von der Erstellung eines LXC-Containers auf einem „offiziellen Template“. Jedoch kann man auch ein eigenständiges Template erstellen, was sich dann wie ein normales Template verhält.

Dazu muss von einem bestehenden LXC-Container zunächst ein Backup erstellt werden. Dazu wählt man mit aktiviertem LXC-Container die Option Backup. Wichtig ist hier unter Kompression die Option GZIP zu wählen. Da man das Backup anschließend herunter laden muss, habe ich hier der Einfachheit halber das Backup auf einem Samba-Share erstellt, welches zuvor in Proxmox als Storage eingebunden wurde. Hier ist es aber auch möglich, das Backup aus Proxmox selbst herunter zu laden. Dies kann man z.B. mit SFTP bewerkstelligen (der konkrete Speicherort des Backups wird während der Erstellung des Backups angezeigt).

Backup eines LXC-Container auf einen Samba-Share erstellen
Backup eines LXC-Container auf einen Samba-Share erstellen

Da ich das Backup hier auf einem NAS erstellt habe, kann ich dieses nun einfach von hier herunter laden.
Nun wählt man in Proxmox einen Storage, auf dem Templates gespeichert werden können. Hier gibt es nun einfach Hochladen und gibt das heruntergeladene Backup an. An dieser Stelle kann man gleich noch einen individuellen Dateinamen vergeben.

Proxmox: Template hochladen
Proxmox: Template hochladen

Nun befindet sich das Template in der Liste der bekannten Templates und kann einfach beim Erstellen eines LXC-Containers gewählt werden:

LXC-Container aus einem eigenen Template erstellen
LXC-Container aus einem eigenen Template erstellen

Mit beiden gezeigten Varianten kann man nun schnell und einfach neue LXC-Container aus eigenen Templates erstellen. Die zweite Variante ist zwar etwas aufwändiger, fügt sich aber nahtlos in den Prozess der Erstellung von LXC-Containern ein.

Fazit

Oftmals benötigt man für kleinere Aufgaben/Programme keine eigenständige virtuelle Maschine, sondern kann dazu einen leichtgewichtigen LXC-Container in Proxmox VE aufsetzen. Durch den äußerst geringen Ressourcenverbrauch einer LXC-Maschine können auch auf einem kleineren Host-System eine große Anzahl LXC-Container gleichzeitig betrieben werden.

Der Artikel hat nun am Beispiel eines Ubuntu Servers gezeigt, wie man einen solchen LXC-Container schnell aufsetzen und konfigurieren kann. Ebenfalls wurden ein paar Tipps und Tricks beim Umgang mit LXC-Containern gezeigt.

Was sind eure Erfahrungen zu LXC-Containern auf einem Proxmox VE? Habt ihr vielleicht noch entscheidende Hinweise, die euch in diesem Artikel noch fehlen? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

17 Kommentare zu „Proxmox VE: Ubuntu Server als Linux Container (LXC) installieren und einrichten“

  1. Hallo Jan,

    wieder eine tollte Anleitung.
    Ich überlege meine Nextcloud Instanz auf eine Proxmox Umgebung umzuziehen, da auch der Versionssprung auf Ubuntu 22.04 ansteht.
    Auf dem Server betreibe ich sonst noch ShellInaBox und Netdata. Lohnt sich das zu virtualisieren?
    Würde man da mit einer VM oder mit einem Container arbeiten? Kann man Deine Nextcloud Anleitung 1:1 bei einer Virtualisierung nutzen?

    Viele Grüße
    Hans

    1. Hi Hans,

      Virtualisierung lohnt sich eigentlich immer, wenn man mehrere Dienste/Anwendungen auf verschiedenen Maschinen haben möchte, aber physikalisch nur eine Maschine dafür her nehmen möchte. Wenn es bei dir also nur um NC, ShellInABox und Netdata geht, dann ist eine Virtualisierung eigentlich überflüssig. Wenn du dann aber z.B. noch ein WordPress auf einer weiteren (virtuellen) Maschine betreiben möchtest, dann würde es wieder Sinn ergeben.

      Für NC reicht prinzipiell ein LXC-Container aus. Die NC-Anleitung solltest du 1:1 übernehmen können, von der Bedienung ist eine VM/LXC ja genau wie ein Ubuntu, welches auf „Bare Metal“ installiert wurde.

      Gruß,
      Jan

      1. Hallo Jan,

        Danke Dir für die Antwort.
        Inzwischen habe ich mich für eine Virtualisierung mit Proxmox entschieden, allerdings warte ich noch, dass benötigte Hardware billiger wird.
        Beim Rumstöbern bzgl. Proxmox und Homeserver bin ich immer wieder auf Nginx Proxy Manager gestoßen. Was hälst Du denn davon?

        Viele Grüße
        Hans

        1. Hi Hans,

          ganz ehrlich? Mit dem nginx Proxy Manager (NPM) hatte ich auch schon zu tun. Ist denke ich eher für die Leute gedacht, die nicht manuell die nginx-vHosts „schreiben“ wollen, sondern eher eine UI brauchen. Prinzipiell kann man damit schon viel machen, aber oftmals muss man sich in der UI einen abbrechen, wenn man Dinge erledigen will, die mit der manuellen Methode (also blanker nginx) in ein paar Minuten erledigt wären. Daher ist mir persönlich hier ein normaler nginx lieber.

          Gruß,
          Jan

          1. Hallo Jan,
            für den Reverse Proxy auf nginx Basis würde man dann wohl einen weiteren LXC Container erstellen, oder? Dann ist der getrennt von den anderen Anwedndungen und ggf. leichter geändert werden.
            Ist dafür ein Ubuntu Template notwendig order reicht auch eine kleinere Distribution, z.B, Alpine ausreichend?

            Eine weitere Frage habe ich noch bzgl. einer Proxmox Umgebung.
            Ich habe eine Festplatte mit privaten Daten. Diese möchte ich einerseits in Nextcloud als auch im Netzwerk per Samba zur Verfügung stellen. Darauf sollen keine VMs gespeichert oder als Proxmox Backup Platte dienen.
            Die Frage stellt sich jetzt, ob ich in einer VM dies per OMV mache oder als LXC Container mit Ubuntu? und händisch Samba einrichte und zur Verfügung stelle. Was ist sinnvoller?

            Gruß Hans

          2. Hi Hans,

            genau, das packe ich in Normalfall auf einen eigenen LXC-Container. Welche Art des Containers hier verwendet wird (Distribution) ist vollkommen unerheblich. Da LXCs aber immer sehr leichtgewichtig sind, sollte es keinen großen Unterschied machen, ob das nun ein Debian/Ubuntu oder ein Apline o.ä. ist.

            Zu der Platte: Das kannst du denke ich so oder so machen. OMV ist halt mit GUI, LXC wäre leichtgewichtiger (OMV läuft meines Wissens nach nicht auf LXC). Wenn du OMV bereits im Einsatz hast, würde ich vermutlich das nehmen, ansonsten LXC.
            Aufpassen musst du nur, dass du am Ende nicht „zwei Endpunkte“ (NC/SMB) hast. Gemeint ist hier, dass Daten nicht „hinten herum“ an NC vorbei über SMB geändert werden dürfen, da NC von diesen Änderungen meistens nichts mitbekommt. Wenn der Samba-Share erst einmal steht, würde ich diesen als external Storage in NC einbinden. Hier muss dann die Option aktiviert werden, dass bei jedem Direktzugriff auf Änderungen geprüft wird.
            Die sauberste Lösung wäre aber wohl, die Daten ausschließlich über NC zur Verfügung zu stellen. Wenn du unter Windows unterwegs bist, dann bekommst du damit allerdings ein Problem mit der Einbindung in den Explorer (unsaubere WebDAV-Implementierung seitens Microsoft). Hier kenne ich eigentlich nur die Software MountainDuck, die das anständig hinbekommt (allerdings kostenpflichtig).

            Gruß,
            Jan

  2. Hallo Jan,
    Danke Dir für die Antwort- Jetzt, wo ich proxmox aufgesetzt habe und die NC installieren will, kommen mir Fragen auf. Von der Aufteilung der einzelenen Container stelle ich mir folgendes vor.
    LXC 1 (Reverse Proxy):
    phb
    nginx mit allen .conf Dateien für die verschiedenen Hosts/ssl/Header
    acme.sh
    LXC 2 (Nextcloud):
    PostgreSQL
    Nextcloud
    ImageMagick
    Fail2Ban

    Jetzt stellt sich mir die Frage, wo und wem ich die IP von dem LXC2 mitgeben muss?
    Reicht das nur im virtuellen Host von NC auf LXC1:
    ——–
    # Path to the root of your installation
    root IP_von_LXC2/var/www/nextcloud;
    ——-
    Oder muss php das irgendwie wissen?

    Danke und viele Grüße
    Hans

    1. Hi Hans,

      ne, die beiden nginx Instanzen wissen nichts voneinander (v.a. weiß der Proxy nichts von Verzeichnissen auf dem NC-Server). D.h. auf dem Proxy machst du die SSL-Termination (hier muss kein PHP installiert sein) und hier musst du dann einen proxy_pass auf den NC-Server vornehmen. Also mit einem „catch all“ location Block.
      Wichtig bei NC: Hier müssen die well-known URLs vom Proxy bedient werden (mit den richtigen Weiterleitungen), dies kann nicht am „NC-Backend“ passieren, dann bekommst du in der NC-Admin-UI eine Warnung.

      Wegen fail2ban ist es wichtig, dass die echte (externe!) IP-Adresse auch den den NC-LXC weitergeschleift wird. Ansonsten bannt fail2ban den Proxy und dann geht erst einmal nichts mehr.

      Darüber hinaus bietet es sich an, auf dem NC-LXC selbst signierte Zertifikate zu verwenden, damit auch der Netzwerk-interne Traffic zu jeder Zeit verschlüsselt ist. Der proxy_pass muss dann natürlich auch mittels HTTPS stattfinden.

      Gruß,
      Jan

      1. Hallo Jan,
        das hört sich ja recht kompliziert an – gerade die well-known URLs richtig hinzubekommen.
        Vielleicht installiere ich erstmal alles wieder auf einem LXC und suche mir Anleitungen im Netz, wie eine Trennung von Reverse Proxy und der NC Instanz inkl. Let’s Encrypt geht. Hast Du da einen Tip?

        Gruß
        Hans

        1. Hi Hans,

          eigentlich gar nicht so kompliziert.
          Die well-known URLs von NC kannst du 1:1 übernehmen aus dem NC-Artikel. Nur, dass diese nicht auf dem NC-LXC sind, sondern am Proxy direkt.
          Eines hatte ich noch vergessen. Die Header-Config darf nur einmal angewendet werden, diese sollte daher nur am Proxy implementiert werden, nicht am NC-Backend.

          Einen guten Artikel habe ich hierfür leider nicht. Weil solche Anfragen aber häufiger kommen, kann ich es ja mal auf meine Todo-Liste packen.

          Gruß,
          Jan

          1. Hey Jan,
            Für mich wäre das auch interessant. Hatte erst Nextcloud nach deiner Anleitung in einem LXC installiert und nun nachträglich den R-Proxy auf einer anderen LXC. Habe bis jetzt nur die SSL Erstellung auf der NC-LXC deaktiviert, der Proxy hat nun das SSL Zertifikat bekommen und leitet und die NC Anfragen über HTTPS über Port 443 weiter und nicht wie normal über HTTP 80.
            Wäre mal interessant wie man NC und den Proxy für das optimale sichere Ergebnis konfigurieren kann.

            Grüße
            Lars

          2. Hi Hans,

            die „Snakeoil-Zertifikate“ sind auch echte Zertifikate die können theoretisch hier auch zum Einsatz kommen, denn an diese Zertifikate hinter dem Reverse Proxy „kommt ja keiner ran“. Trotzdem könnte man diese noch durch selbst signierte Zertifikate ersetzen. Die werden dann genau so eingebunden, müssen aber vorher noch schnell generiert werden.

            Gruß,
            Jan

      1. Hi Jan,

        Vielen Dank. Da ich mir auch nicht ganz sicher bin, lasse ich es lieber auf Standard (nichts ausgewählt).
        Man findet hierfür nämlich leider keine Dokumentation im Netz.

        1. Hi Max,

          meines Erachtens nach sind diese Einstellungen auch nicht sonderlich wichtig. Das sind nur kleinere Optimierungen, die man im Normalfall gar nicht merken sollte.
          Alles auf Standard lassen ist sicher auch eine gute Option.

          Gruß,
          Jan

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert