Das wird kein politischer Artikel, aber weil dieser Begriff derzeit in aller Munde ist - fiel mir dieser philosophisch klingende Titel ein. Schon immer beschäftigt Migration die IT Spezialisten.
Mein Wireguard Server Knoten soll auf den Proxmox umziehen, das ist eigentlich ganz einfach.
Auf meinem bisherigen KVM/Libvirt Host habe ich ein paar SMB und NFS Shares sowie ISCSI Platten. Ich hielt das bisher für einfacher, als extra eine NAS als virtuellen Server aufzusetzen. Aber: ein GUI macht die Bedienung und Wartung etwas einfacher und bringt auch immer wieder einen Lerneffekt, vor allem wenn man sich nicht tagtäglich mit der Thematik beschäftigt. Durch die Proxmox VE Helper-Scripts bin ich auf etwas mir bis dahin unbekanntes gestoßen: Turnkey Appliances eine Seite mit gut gewarteten VMs und LXC Templates für diverse Anwendungsfälle.
Die erste Idee war, einfach das Helper-Script zu nehmen, der eine Turnkey Appliance als LXC installiert (bzw. Storage/local/CT Templates/Templates). Der zweite Blick offenbarte den entscheidenden Unterschied: zu VMs kann man die Festplatte direkt durchreichen (nur qm set ...) zu LXC geht das leider nicht. Ich wollte gerne meine existierenden HDDs einfach umhängen.
Alle machen Proxmox, ich habe mich bisher etwas dagegen gesträubt. Bisher habe ich mich mit der Basis von Proxmox (KVM/QEMU) beschäftigt. Aber diese Verwaltungsoberfläche sieht natürlich gut aus und macht alles sicher einfacher. Also einen neuen passenden Mini-PC NAD9 geholt (später könnte man Clustern) und Proxmox vom ISO Image direkt installiert. Für schnelle und unkomplizierte Beispiele ist diese Seite mit zahlreichen Scripts hervorragend: https://tteck.github.io/Proxmox/
vor allem große Freemail Provider verschärfen systematisch die Regeln welche Post sie noch annehmen und welche sie verweigern. Die Devise lautet: SPAM gar nicht erst annehmen und dann filtern, sondern die Annahme verweigern. Dazu muss der Absender authentifiziert werden. Es gibt drei Methoden zur Erhöhung der Email Sicherheit: SPF, DKIM, DMARC.
Der Artikel hat erstmal nur den Status: Notizzettel.
Im ersten Teil habe ich die Installation einer LXD Umgebung beschrieben. Im zweiten Teil soll es um die weitere Konfiguration und den Umgang mit LXD Containern gehen:
Es gibt eine gute grundlegende Doku, ich will nur ein paar praktische Versuche dokumentieren.
aber diesmal mit viel mehr Tiefe. 😉
Ich bin ein Fan von Virtualisierung, habe mich schon mit Containern (docker) beschäftigt und habe irgendwann von LXC gelesen.
Ubuntu wirbt mit LXD, seit ein paar Monaten gibt es einen Fork von LXD mit dem Namen Incus. - was verbirgt sich dahinter? Ursprünglich wollte ich auf einem Host Libvirt und LXC parallel betreiben und die Möglichkeit für Docker haben.
Ich meine, ich habe nach einigen Wochen lesen folgendes verstanden: Virtualisierung emuliert und isoliert Hardware und schafft eine Umgebung für jedes OS, LXC schafft eine isolierte Linux System Umgebung, Docker schafft eine isolierte Linux Applikationsumgebung, LXD ist eine Verwaltungsumgebung für LXC. Der Unterschied zwischen LXC und docker Container: für den Anwender ist docker eine Black Box, die Applikation wird vom Entwickler gewartet und vom Anwender angewendet. LXC ist für den Anwender ein "fertiges" Linux System in dem er seine Applikation installieren und es warten muss.
Was mich eine Weile verwirrt hat: Für LXC gibt es 2 (oder mehr?) Verwaltungssysteme: lxc-utils und LXD. Bei LXD heißt das führende Verwaltungskommando lxc. Während ich immer weiterlese, beschleicht mich das ungute Gefühl, dass es alles Schnee von gestern wird, was ich hier aufschreibe.
In meinem Beitrag "Verbundene Netzwerke" hatte ich mit PiVPN begonnen.
PiVPN wird eventuell nicht mehr weiterentwickelt -> Zeit eine eigene, möglichst zeitlose Konfiguration zu beschreiben!
Die Idee: irgendwo im Internet (oder an einem Standort in der DMZ) befindet sich ein Einwahlknoten und alle Peers verbinden sich zu diesem Knoten. Es gibt zwei Sorten Peers:
Der Knoten ist möglichst isoliert. Die Peers müssen keine Port öffnen, am eigenen Netzwerk nichts verändern.
Ausgangspunkt für meine Beschreibung ist ein aktualisiertes, minimales Debian (Bookworm) System, 1-2 CPUs, 1-2GB RAM, 10-20 GB Disk, eine Netzwerkkarte, Internet Zugang. Wahrscheinlich braucht man noch weniger (Container). Kein Desktop, kein Gnome, nur sshd und Standard Systemwerkzeuge.
Hier kommt noch ein Diagramm, bis dahin muss der Link hier genügen.
