Lightwhale 3: Linux-Server wieder spannend machen

 (lightwhale.asklandd.dk)
4 Punkte von GN⁺ 3 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Linux-Server-OS, das ausschließlich für Docker-Container konzipiert ist: Nach dem Booten der ISO landet man sofort in einer Docker-Engine-Umgebung
  • Das Kernsystem bleibt unveränderlich und zustandslos, während /etc, /var, /home sowie Docker-Daten in getrennte beschreibbare Bereiche ausgelagert werden, wodurch der Aufwand für Installation und Ersteinrichtung deutlich sinkt
  • Das Standard-Daten-Dateisystem ist ein flüchtiger, auf tmpfs basierender Speicher; bei aktivierter Persistenz werden separate Speichermedien automatisch erkannt, partitioniert, formatiert und eingehängt und bei Bedarf auch als Btrfs RAID1 eingerichtet
  • Mit einem schreibgeschützten Root auf Basis von squashfs und einer Minimalzusammenstellung wird die Angriffsfläche für Malware oder unbeabsichtigte Änderungen reduziert, zugleich sinken Ressourcenverbrauch und Strombedarf
  • Nur für x86-64 und lauffähig auf Bare Metal sowie in virtuellen Maschinen, damit man sich statt auf Serververwaltung direkt auf Container-Betrieb und Self-Hosting konzentrieren kann

Überblick

  • Ein Linux-Server-OS, das ausschließlich für Docker-Container ausgelegt ist; beim Live-Boot per ISO landet man sofort in einer Docker-Engine-Umgebung
  • Um den Aufwand für Installation und Ersteinrichtung zu reduzieren, bleibt das Kernsystem unveränderlich, während Daten und Benutzeranpassungen in getrennte Speicherbereiche ausgelagert werden
  • Gedacht für Homelabs, Bare Metal, Virtualisierungsumgebungen, Edge-Knoten und Cluster, jedoch auf die Architektur x86-64 beschränkt
  • Priorisiert Minimalaufbau und Benutzerfreundlichkeit, damit der Fokus eher auf dem Ausführen und Betreiben von Containern als auf der Serververwaltung liegt

Wichtige Merkmale

  • Plug-and-Play: ISO herunterladen, booten, und Docker Engine mitsamt den benötigten Tools ist sofort einsatzbereit
  • Minimale Komponenten, damit die Einstiegshürde sinkt und sich das Systemverhalten schnell erfassen lässt
  • Ein unveränderlicher, zustandsloser Kern reduziert die Angriffsfläche für Malware und unbeabsichtigte Änderungen und bootet jedes Mal in denselben Zustand
  • Bietet optionale Persistenz; das Standard-Daten-Dateisystem ist das flüchtige tmpfs im RAM, und bei aktivierter Persistenz werden separate Speichermedien automatisch erkannt, partitioniert, formatiert und eingehängt
  • Reduziert unnötige Prozesse, um Ressourcenverbrauch und Strombedarf zu senken und ältere oder leistungsschwächere Hardware länger nutzbar zu machen
  • Erleichtert Self-Hosting, um sich von Big-Tech-Abhängigkeiten zu lösen und Daten sowie Privatsphäre selbst zu verwalten

Erste Schritte

  • Das neueste ISO herunterladen oder ein Image aus dem Download-Bereich auf einen USB-Stick schreiben und davon booten
  • Auf manchen Systemen muss vor dem Booten im BIOS möglicherweise Safe Boot deaktiviert werden
  • Standard-Login ist Benutzername op, Passwort opsecret; bevor das System ins Internet exponiert wird, sollte mindestens das Passwort geändert werden
  • Wi-Fi kann optional mit setup-wifi eingerichtet werden
  • Das Ausführen von Containern entspricht normalem Docker-Gebrauch, z. B. mit docker run -it --rm busybox ps
  • Beim Aktivieren der Persistenz muss der magic header auf ein Blockgerät und nicht auf eine Partition geschrieben werden; dabei werden vorhandene Daten gelöscht

Boot- und Laufzeitarchitektur

  • Die ISO kann auf Bare Metal und in virtuellen Maschinen booten und unterstützt sowohl UEFI als auch klassisches BIOS
  • Der Startvorgang nutzt ein SysV-ähnliches Init-System, um einen einfachen und transparenten Boot-Ablauf zu erhalten
  • Der Bootloader lädt den Linux-Kernel und das Root-Dateisystem in den Speicher, danach initialisiert der Kernel die Hardware und übergibt die Kontrolle an /init
  • init liest /etc/inittab, hängt tmpfs für /tmp und /run ein und führt dann die Skripte in /etc/init.d aus
  • Früh im Ablauf wird das data filesystem eingehängt, das Docker-Daten sowie die oberen Overlay-Layer für /etc, /var und /home bereitstellt
  • Sobald alle Dateisysteme und Overlays vorbereitet sind, werden die übrigen Dienste gestartet; ab diesem Zeitpunkt können Container bereitgestellt werden

Unveränderlichkeits-Design

  • Das Root-Dateisystem wird als komprimiertes statisches squashfs-Image bereitgestellt und ist von sich aus nicht veränderbar
  • Dadurch sind essenzielle Software und Konfiguration bereits enthalten, sodass ein autarkes Image entsteht, das ohne Installationsprozess bootfähig ist
  • Paketmanager, Abhängigkeitsverwaltung und das Wettrüsten klassischer System-Updates werden vermieden; statt etwas Funktionierendes erneut zu installieren, reicht ein Reboot
  • Dateien des Root-Dateisystems können nicht versehentlich gelöscht oder durch Viren verändert werden, und anders als bei traditionellen Systemen sind Kernel und grundlegende Binärdateien nicht vollständig als beschreibbar exponiert
  • Der schreibgeschützte Root verhindert die Ansammlung von Ballast, die sich im Langzeitbetrieb auf Backup, Performance und Aufgeräumtheit negativ auswirken kann
  • Man kann frei auf lokalen VMs oder anderen Rechnern experimentieren und Änderungen per Reboot wieder zurücksetzen
  • Das Boot-Medium enthält keine wichtigen Informationen, und durch die Unveränderlichkeit bleibt das auch so; selbst bei Beschädigung oder Verlust lässt sich das System mit einer neuen Kopie wiederherstellen

Persistenzarchitektur

  • Für Container-Installation und -Ausführung, Konfigurationsänderungen und Datenspeicherung wird ein beschreibbares Dateisystem benötigt; soll dies nach einem Reboot erhalten bleiben, ist Persistenz nötig
  • Ein in einer frühen Boot-Phase automatisch arbeitendes Subsystem hängt das data filesystem unter /mnt/lightwhale-data ein
  • Von Lightwhale geschriebene Daten landen unter /mnt/lightwhale-data/lightwhale-state; dieses Verzeichnis bildet den beschreibbaren oberen Layer von overlayfs
  • Standardmäßig wird das flüchtige tmpfs verwendet; bei aktivierter Persistenz liegt das data filesystem stattdessen auf einem separaten Speichermedium
  • Statt den gesamten Root zu überlagern, werden nur /etc, /var und /home selektiv per Overlay behandelt, um den Zweck der Unveränderlichkeit zu erhalten
    • /etc dient für die Anpassung von Systemkonfigurationen wie Netzwerk, Passwörtern und sshd
    • /var wird für Logs und andere Anwendungsdaten genutzt
    • /home dient für Benutzeranpassungen wie SSH authorized keys, das Klonen von Git-Repositories und die Verwaltung von Docker- und Swarm-Stacks
  • Das Docker-Data-Root liegt direkt unter /mnt/lightwhale-data/lightwhale-state/docker und speichert Images, Container, Volumes und Netzwerkstatus

Persistenz aktivieren und automatische Verarbeitungsschritte

  • Persistenz muss explizit aktiviert werden, indem ein magic header auf ein Speichermedium geschrieben wird, z. B. mit echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdx
  • Der magic header kann auf mehrere Speichermedien geschrieben werden; in diesem Fall werden sie zu einem Btrfs-RAID1-Volume kombiniert
  • Beim nächsten Boot erkennt das System die magic disks, formatiert sie und verwendet sie als data filesystem
  • Das persistence subsystem wird aus /etc/init.d/S11persistence gestartet

  • Erkennung des Daten-Dateisystems

    • Alle Datenträger werden geprüft, um Partitionen mit dem Dateisystem-Label lightwhale-data zu finden
    • Wenn eine gefunden wird, wird sie als data filesystem verwendet und die nachfolgenden Mount-Schritte werden übersprungen

  • Erkennung von magic disks und Partitionsanlage

    • Eine magic disk wird erkannt, indem die Byte-Sequenz lightwhale-please-format-me am Anfang des Datenträgers gesucht wird
    • Auf jeder magic disk wird eine Swap-Partition mit dem Label lightwhale-swap und eine Linux-Partition mit dem Label lightwhale-data angelegt, die den gesamten verbleibenden Platz nutzt

  • Erstellen des Dateisystems

    • Magic-Swap-Partitionen werden formatiert und mit dem Label lightwhale-swap versehen
    • Gibt es nur eine magic data partition, wird sie mit btrfs --data single --metadata dup formatiert
    • Bei mehreren werden sie als RAID1 zusammengeführt und mit btrfs --data raid1 --metadata raid1cn formatiert
    • Es werden die Subvolumes @lightwhale-data, @lightwhale-state, @lightwhale-state-snapshots angelegt

  • Mounts und Overlay-Konfiguration

    • Wenn ein data filesystem vorhanden ist, wird @lightwhale-data nach /mnt/lightwhale-data eingehängt, andernfalls stattdessen tmpfs
    • Der unveränderliche untere Layer bind-mountet /etc nach /run/lightwhale/overlay/lower/etc und spiegelt die Verzeichnisstruktur des Root-Dateisystems zur Vorbereitung
    • Der beschreibbare obere Layer wird unter Pfaden wie /mnt/lightwhale-data/lightwhale-state/overlay/upper/etc vorbereitet
    • Anschließend werden beide Layer per overlayfs zusammengeführt und auf /etc eingehängt; dasselbe wird für /var und /home wiederholt

Einschränkungen und FAQ-Kernpunkte

  • Unterstützte Hardware ist ausschließlich x86-64; BIOS und EFI werden beide unterstützt
  • Raspberry Pi wird derzeit nicht unterstützt und steht im Backlog
  • Apple-M-Serien werden nicht auf Bare Metal unterstützt, virtueller Betrieb ist jedoch möglich
  • Läuft in virtuellen Umgebungen wie VMWare/ESX/Proxmox/Cloud und enthält Guest Agents für QEMU/KVM sowie VMware ESXi
  • Es kann nur Docker-Container-Software installiert werden; eine direkte Installation ins Root-Dateisystem ist nicht möglich
  • Das Kernsystem ist unveränderlich, aber Konfigurationen, Anpassungen und Container-Daten werden standardmäßig im Speicher abgelegt und bleiben erst bei aktivierter Persistenz über Reboots hinweg erhalten
  • Der Standard-Hostname enthält zur Vermeidung von Netzwerkkonflikten eine Machine-ID; bei Änderung mit setup-hostname wird dies sofort wirksam, außer in der aktuellen Shell
  • Es gibt keine Gewährleistung; die Verantwortung für die Nutzung und ihre Folgen liegt beim Benutzer
  • Das Ziel ist nicht, bevorzugte Tools wie wget oder nano ins Root-Dateisystem aufzunehmen; die Beschränkung als zweckoptimiertes minimales Server-OS soll erhalten bleiben
  • Laut TL;DR der Datenschutzrichtlinie werden keine personenbezogenen Daten erhoben; nur bei Zustimmung zur Telemetrie werden anonyme Daten gesammelt, deren Inhalt ebenfalls einsehbar ist
  • Die Einhaltung altersbezogener Vorschriften ist nicht Aufgabe des OS selbst, sondern liegt in der Verantwortung der vom Nutzer darauf bereitgestellten Dienste

Verwandte Links

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 일 전
Hacker-News-Kommentare

  • Es ist auf jeden Fall etwas, tatsächlich etwas veröffentlicht zu haben, aber warum man das unbedingt verwenden sollte, ist für mich noch nicht wirklich ersichtlich
    Es gibt bereits Alternativen mit ähnlichen Zielen wie Flatcar Container Linux, Fedora CoreOS, Talos Linux und IncusOS, und diese wirken auch bei Community oder kommerzieller Unterstützung solider aufgestellt
    Es müsste klarer erklärt werden, was hier anders ist, damit es überzeugend wirkt

    • Ich nutze IncusOS im Homelab, und das Einrichtungs- und Nutzungserlebnis ist wirklich gut
      Ich bin von Proxmox umgestiegen und verwalte jetzt alle VMs damit; außerdem nutze ich Coding-Assistenten intensiv, um Dinge wie die Automatisierung der IncusOS-CLI-Konfiguration, das Umwandeln von Docker-Compose-Images nach Incus oder das Schreiben von bash-Skripten zum Starten neuer Container zu erledigen, sodass selbst --dangerously-skip-permissions kein Problem ist
      Das Beste daran ist, dass sich alles über deklarative Dateien verwalten lässt, sodass Netzwerkaufbau und Ressourceneinstellungen immer gut sichtbar sind
      Für einen ähnlichen Einsatzzweck lohnt sich ein Blick auf IncusOS
    • Solche Tools brauchen normalerweise mehrere Stunden Konfiguration, während dieses hier einfach bootet und sofort läuft

  • Solange es Software gibt, kann man Wartung nicht überspringen
    Nichts ist fehlerfrei, und wenn man behauptet, dass keinerlei Upgrades, Patches oder Verwaltung nötig seien, ist das oft der direkte Weg zu einem kompromittierten System

    • Niemand sagt, dass dieses OS keine Wartung braucht
      Eher reduziert es einen großen Teil der Wartung, um die man sich bei einem traditionellen Basissystem kümmern müsste, und zwar weil 1) fast nichts installiert ist und 2) Basis-Upgrades einfach sind, da man nur neu booten und die Container wieder hochfahren muss
      Natürlich braucht die Software darauf weiterhin Upgrades, aber bei einem Docker-basierten Setup wird diese Ebene meist anderweitig verwaltet, sodass man einfach neue Container zieht und neu startet; das OS sorgt eher dafür, dass die Daten wieder an derselben Stelle eingebunden werden
      Wenn es für einen okay ist, sämtliche Software in Docker laufen zu lassen, wirkt das wie eine Stufe über Debian oder Redhat und zugleich weniger prozedural komplex als CoreOS
      Wie bequem es in der Praxis wirklich ist, vor allem beim Storage-Management, ist für mich noch etwas fraglich, aber zumindest ist sehr klar, was verkauft werden soll
    • Das sage ich seit Jahren
      Self-Hosting ist zwar machbar, aber man übernimmt damit außerhalb der Arbeitszeit faktisch auch ein SLA
      Deshalb habe ich alles mit mehr als einem Nutzer schon vor langer Zeit abgeschafft
    • Natürlich ist nichts vollständig fehlerfrei
      Trotzdem gibt es einen Grund, warum Projekte wie Talos existieren
      Wenn es kein Terminal, kein SSH, keinen Paketmanager, ein schreibgeschütztes Dateisystem und nicht einmal systemd gibt und die Zahl der Binärdateien minimiert wird, dann verringert sich die Angriffsfläche ganz eindeutig
      Ich spreche hier nicht speziell über das vorgestellte Projekt, aber sicherere Systeme mit weniger Wartungsaufwand existieren tatsächlich
      Nur weil sowieso nie 100 % Sicherheit erreichbar ist, heißt das nicht, dass man einfach YOLO-mäßig npm-Pakete übernehmen sollte, die vor drei Minuten zuletzt geändert wurden

  • Klingt interessant, aber ich frage mich, wie Patches, Upgrades und der eigene ISO-Build gehandhabt werden
    Selbst im Quell-Repository ist dazu fast nichts zu sehen

    The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.

    https://bitbucket.org/asklandd/lightwhale/src/master/

    • Das Repository wirkt veraltet
      Der letzte Commit ist zwei Jahre alt, und der Quellcode für Version 3.0 scheint nicht vorhanden zu sein

  • Ist das nicht eher eine Linux-Distribution als ein OS?

    • Wenn es keine Linux-Distribution ist, was wäre dann überhaupt ein OS?

  • Ich habe das Gefühl, in diesem Bereich noch fast ein Anfänger zu sein, obwohl ich seit über 10 Jahren Self-Hosting betreibe und etwa seit 2019 auf Unraid gewechselt bin
    Wegen des Fokus auf ein Web-Portal war es leicht zu bedienen und angenehm zu warten
    Ich frage mich, wie man mit diesem Home-Server-OS interagiert
    Da auf der Website keine Bilder zu sehen sind, wirkt es so, als würde alles vollständig terminalbasiert ablaufen

  • Ich habe gerade eben auf Ubuntu Server Docker mit einer einzigen Zeile installiert und sofort losgelegt; deshalb ist mir nicht klar, was hier genau anders ist und worin das Wertversprechen besteht
    Mich würde auch interessieren, was mit der erwähnten Wartung konkret gemeint ist und ob es einfach ein schlankerer Server für weniger leistungsfähige Hardware sein soll
    Ich habe erst kürzlich mit dem Aufbau eines Home-Servers angefangen und möchte ehrlich verstehen, welche Vorteile das bringt

    • Ich mache im Grunde dasselbe
      Der Vorteil des immutable-Ansatzes soll angeblich bei Updates liegen: Wenn es mit einer neuen Image-Version Probleme gibt, kann man einfach wieder die alte booten und zurückrollen
      Funktional habe ich aber auch das Gefühl, dass Ubuntu Server für mich völlig ausreicht
      Ich mache ein paar Mal im Jahr apt update und Upgrades und greife nur lokal bzw. über Tailscale darauf zu
      Solche immutable Betriebssysteme wirken auf mich auf Laptops oder Desktops attraktiver als auf Home-Servern
      Wenn nur das Home-Verzeichnis beschreibbar ist, sollte das OS stabiler sein und sich nicht so leicht kaputtkonfigurieren lassen

  • Ich frage mich, welche Methode für regelmäßige Backups der Container-Daten unter Lightwhale empfohlen wird

  • Ich verstehe es nicht ganz
    Wenn ich sowieso nur Docker laufen lasse, sehe ich nicht, warum ich immutable brauche, und auch nicht, warum ich statt Debian oder Ubuntu, auf denen Docker in wenigen Minuten läuft, eine spezielle Debian-Variante verwenden sollte
    Wartung ist doch ohnehin etwas, das man über das Paketmanagement der Distributions-Repositories oder des offiziellen Docker-Repositories erledigt
    Ich wünschte, dieser immutable-Hype würde etwas abflauen; für flatpak und snap gilt für mich dasselbe
    Linux konnte das, was solche Lösungen angeblich erst ermöglichen, eigentlich schon immer
    Ohne root können Benutzer das Basissystem ohnehin nicht anfassen, und Anwendungen können ihre Abhängigkeiten einfach unter /usr/lib installieren

    • Für mich ist Debian stable mit podman/Docker schon hinreichend immutable
      Dass man bei Problemen leicht Hilfe bekommt, ist dabei auch eine wichtige Absicherung
      Man kann es bestimmt noch kleiner machen, aber wenn es bereits auf schwacher Hardware wie einem BananaPi oder günstiger RISC-V-Hardware gut läuft, sehe ich kaum einen Grund für etwas anderes

  • So etwas scheint ziemlich gut zu einem Swarm-Mode-Cluster zu passen
    Ich weiß nicht, ob der Fokus nur auf Home-Servern liegt, aber ich werde es weiter beobachten
    Das Projekt sieht auch wirklich gut aus

    • Im Moment wird es nur im Bereich Home-Server beworben, weil Menschen dort am unkompliziertesten experimentieren
      Aber Lightwhale läuft bereits in Produktion und eignet sich auch sehr gut für Swarm-Cluster

  • Sieht extrem sauber aus
    Aus Sicht von Anfängern ist so ein Ansatz genau richtig, weil er davor schützt, die Konfiguration zu zerschießen, daher werde ich es auf jeden Fall ausprobieren