Der Versuch eines BSD-Nutzers mit Alpine Linux

 (rubenerd.com)
1 Punkte von GN⁺ 2024-04-28 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Nutzer, der häufig BSD-Desktops sowie chroot und jail verwendet, testet Alpine Linux und findet, dass dessen auf Sicherheit, Einfachheit und Ressourceneffizienz ausgerichtetes Design BSD-Nutzern vertraut vorkommt
  • Dank seiner geringen Größe und begrenzten Abhängigkeiten wird Alpine nicht nur als Container-Basis-Image verwendet, sondern auch breit in eingebetteten Systemen, Routern, Mobilgeräten, Servern und auf Desktops eingesetzt
  • Die Installation erfolgt in einer Live-Umgebung durch Ausführen von setup-alpine, wobei Grundeinstellungen wie Keymap, Netzwerk, Zeitzone, SSH und NTP der Reihe nach eingerichtet werden
  • Nach dem ersten Start zeigen sich die Kombination aus OpenRC, musl und busybox; Elemente wie /etc/rc.conf und crond(8) knüpfen an BSD-typische rc-Erfahrungen an
  • Nach Prüfung der Paketverwaltung mit apk, der Repository-Konfiguration und sogar der Möglichkeit zur ZFS-Installation hinterlässt Alpine einen so guten Eindruck, dass es ernsthaft als Haupt-Linux-Distribution für Tests und Server in Betracht gezogen wird

Der Alpine-Charakter, der BSD-Nutzern vertraut ist

  • Alpine Linux ist eine unabhängige, nicht-kommerzielle, universelle Linux-Distribution für Power-User, bei der Sicherheit, Einfachheit und Ressourceneffizienz im Mittelpunkt stehen
  • Die Userland-Binärdateien werden mit PIE (Position Independent Executables) und Stack-Smashing-Protection kompiliert, um die Ausnutzung bestimmter Zero-Day-Lücken und Schwachstellen zu erschweren
  • Alpine ist ein älteres Projekt, als man vielleicht vermutet; Natanael Copa sprach bereits 2005 über die Ursprünge des Projekts
  • Wie Systeme aus der BSD-Familie wird es nicht nur in eingebetteten Systemen, Routern und Mobilgeräten, sondern auch auf allgemeinen Servern und Desktops eingesetzt
  • Wegen seiner geringen Größe und begrenzten Abhängigkeiten wird es häufig als Basis-Image für Linux-Container verwendet; es gibt auch Werkzeuge wie alpine-chroot-install, um es leicht in chroot(8) auszuführen
    • Besonders interessant ist das für Nutzer, die NetBSD-chroot(8) und FreeBSD-jails häufig zum Testen und Ausrollen verwenden

Installationserfahrung

  • Alpine bietet verschiedene Builds für ARM, PPC64, x86, x86_64 und weitere Plattformen
  • Es wurde zwar ein Xen-ISO-Image in einer VM gebootet, doch die Wahl beruhte auf einem Missverständnis, bei dem Dom0 mit DomU verwechselt wurde
    • Dom0 bezeichnet den Xen-Hypervisor und ist kein Gast
    • Trotzdem verliefen Boot und Installation wie bei einer Standard-ISO
  • Die Installation erfolgt in der Live-Umgebung, indem man sich als root mit leerem Passwort anmeldet und anschließend setup-alpine ausführt
  • Während der Installation werden grundlegende Punkte wie Keymap, Netzwerk, Zeitzone und Root-Authentifizierung nacheinander konfiguriert
  • Bereits am Anfang können SSH-Schlüssel eingebunden werden
    • Das ist später praktisch, wenn man mit Orchestrierungswerkzeugen Gruppen aus VMs oder Servern ausrollt
    • Es hilft auch in Hosting-Umgebungen ohne OOB-Konsole
  • SSH-Server und NTP-Client lassen sich auswählen; hier standen OpenSSH und openntpd zur Wahl
  • Der Installer erkannte korrekt, dass das System unter Xen lief
  • Auch eine LVM-Konfiguration ist möglich, in diesem Fall wurde jedoch die Standardkonfiguration gewählt, die Alpine als sys-Partition bezeichnet
    • Diese Konfiguration verwendet ext4

Systemaufbau nach dem ersten Boot

  • Nach dem ersten Start lässt sich in dmesg(1) erkennen, dass das System OpenRC verwendet
  • OpenRC ist ein init-System, das auf Portabilität, geringe Größe, Geschwindigkeit, Effizienz, Transparenz und Sicherheit ausgelegt ist
  • Für Nutzer, die an BSD-artige rc-Skripte gewöhnt sind, wirkt OpenRC sehr vertraut
    • Elemente wie /etc/rc.conf und crond(8) schließen an die BSD-Erfahrung an
  • Dass es Linux-Distributionen wie Devuan, Gentoo und Alpine mit OpenRC gibt, lässt Linux wieder interessant wirken
  • Alpine bringt neben OpenRC auch musl mit und verwendet busybox
    • musl und busybox sind gegenüber GCC und GNU coreutils eingeschränkter, tragen aber zur geringen Größe des Basissystems und zu einer kleineren Angriffsfläche bei
  • Auch llvm ist verfügbar
  • Die MirBSD Korn shell wird ebenfalls als Paket angeboten und gehört zu den bevorzugten interaktiven Shells

Paketverwaltung und Repositories

  • Der Standard-Paketmanager von Alpine ist apk
  • Wie unter Linux üblich aktualisiert apk Basissystem und Pakete gemeinsam, statt sie zu trennen
  • Ob es sich wie unter BSD als unprivilegierte Kopie ausführen lässt, wurde noch nicht geprüft
  • Auch pkgsrc ist nutzbar, sodass eine Alternative offenbleibt
  • Die Repository-Konfiguration befindet sich in /etc/apk/repositories
    • Wenn man den Kommentar vor der zweiten vom Installer eingetragenen URL entfernt, lässt sich das community-Repository aktivieren
    • Alpine hat außerdem ein testing-Repository, und eigene Repositories können ebenfalls hinzugefügt werden
  • Die Bedienung ist einfach, auch wenn aus Gewohnheit manchmal versehentlich apt install statt apk add eingegeben wird
  • Die offizielle Weboberfläche für Pakete ist unter pkgs.alpinelinux.org zu finden
  • Alpine-Repositories lassen sich auch über pkgs.org durchsuchen

ZFS und die Bewertung als Server-Kandidat

  • Nach der Installation einiger Pakete ließ sich eine Ausstattung mit den „unverzichtbaren Werkzeugen“ herstellen, wie sie zuvor auf einem reinen Konsolen-Laptop genutzt wurde
  • Eines der überraschendsten Pakete war ZFS
    • Installation und Laden des Kernel-Moduls waren mit zwei Befehlen möglich
# apk add zfs zfs-lts


# modprobe zfs
  • Ein Root-Dateisystem auf ZFS aufzubauen, könnte komplizierter sein
  • Wie sich eine ZFS-Konfiguration nach Upgrades verhält, wurde noch nicht geprüft
  • Schon die bisherigen Erfahrungen hinterlassen einen so guten Eindruck, dass ein ernsthafter Umstieg auf Alpine als Haupt-Linux-Distribution für Tests und Server in Betracht gezogen wird
  • Als Pluspunkte gelten die wenigen in htop(1) und lsof(1) sichtbaren Prozesse, die Nutzung von OpenRC, die unkompliziert wirkende Paketverwaltung und die einfache Konfiguration
  • Wenn es ein modernes und funktionales „Occam’s Linux“ gibt, dann kommt Alpine diesem Bild sehr nahe
  • Falls mehr Funktionen als busybox benötigt werden, könnte man uutils ausprobieren, auf Servern scheint das jedoch kaum nötig zu sein

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-28
Meinungen auf Hacker News

  • Aus Sicherheitssicht werden die meisten Linux-Binaries heutzutage mit PIE kompiliert.
    Wenn man checksec auf ein beliebiges Binary unter Ubuntu anwendet, sieht man diese Eigenschaft; checksec lässt sich mit pip install pwntools installieren.
    GLIBC dagegen hat meines Wissens die am stärksten gehärtete Heap-Implementierung und bietet mehr Gegenmaßnahmen gegen Double-Free und andere Heap-Angriffe.
    In dieser Hinsicht könnte man also sagen, dass Alpine durch die Nutzung von musl weniger sicher ist; zugleich ist ein kleines, leicht verständliches System aus Sicherheitsperspektive ein echter Vorteil.

    • Mir ist nicht ganz klar, warum ein „kleines, leicht verständliches System“ ein Argument zugunsten von glibc sein soll. Ist es nicht eher umgekehrt?
    • Auf Alpine-Nodes lasse ich immer für alles checksec laufen, und die Prozesse sehen durchweg so aus. Die vollständige Ausgabe ist lang, daher ausgelassen, aber ich habe bei von Alpine gebauten Programmen noch nie gesehen, dass diese Flags fehlen.
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • Auch OpenBSD libc ist einen Blick wert.
    • Aus Sicht der Linux-Sicherheit gilt: Wenn jemand auch nur ein wenig Code auf dem System ausführen kann, ist es im Grunde schon vorbei. Linux ist voller Löcher, und der Grund, warum es nicht so viel Malware wie unter Windows gibt, ist, dass auf dem Desktop nur wenige Leute Linux nutzen und Malware-Autoren es deshalb nicht besonders stark ins Visier nehmen.
      Ehrlich gesagt denke ich, dass modernes Windows und macOS beide eine bessere Sicherheitsarchitektur haben.

  • Ich komme ebenfalls aus der BSD-Ecke und habe zufällig diese Woche zum ersten Mal Alpine in einer VM auf bhyve laufen lassen.
    Der Schlüssel ist BusyBox. Wenn die Utilities in /bin und /sbin nicht jeweils eigenständige Binaries sein müssen, ist der Userspace sehr klein und bootet schnell. Mit Tmux und zsh installiert reichte es für die meisten Unix-Zwecke völlig aus.
    Bis zur endgültigen Umgebung musste ich zwar ziemlich viel per apk installieren, aber insgesamt war es die beste Linux-Erfahrung seit Langem. Schön wäre, wenn ZFS standardmäßig enthalten wäre und die virtio-Anbindung für ZFS-basierten Betrieb unter bhyve expliziter darauf abgestimmt wäre.

    • Ich nutze und verteile FreeBSD seit über 20 Jahren, und ehrlich gesagt widerstrebt es mir, mich auf GNU/Linux-Kisten einzuloggen. Es gibt so viele Varianten und Inkonsistenzen, dass sich das System wie ein Durcheinander anfühlt. Sich auf einen Windows-Server einzuloggen, fühlt sich fast noch „sinnvoller“ an.
      Trotzdem freut es mich zu hören, dass es vielleicht eine vernünftige Linux-Distribution gibt, und falls ich einmal eine Linux-Kiste brauche, werde ich sie ausprobieren. Das kommt allerdings ziemlich selten vor.
    • Mich würde interessieren, in welchem Umfang du dir wünschst, dass ZFS „standardmäßig eingebaut“ ist. Alpine ist eine der wenigen Distributionen, die binäre ZFS-Kernelmodule anbieten, sodass es mit einem einzigen apk-Befehl praktisch installiert ist.
      Im Alpine-Wiki gibt es auch eine recht gute Anleitung zur Installation mit ZFS als Root-Dateisystem: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS funktioniert unter Alpine sehr gut. Alpine + ZFS ist seit Jahren meine Standard-Serverkonfiguration.

  • Wenn du BSD-Nutzer bist, könnte dir auch Void Linux gefallen. Die Distribution wurde von xtraeme, einem NetBSD-Entwickler, erstellt, gibt es in glibc- und musl-Versionen und nutzt runit als Init-System.
    Mit xbps-src kann man Pakete auch aus dem Quellcode bauen.
    https://voidlinux.org/

    • Ich bin von Arch gekommen und habe schließlich Void gefunden, nachdem ich nach einer nicht-SystemD-Alternative gesucht hatte, die sich ähnlich wie Arch anfühlt. Der Grund, warum ich zu Void statt Alpine gegangen bin, war die glibc-Unterstützung, weil ich damit die NVidia-Treiber nutzen konnte. Ja, ich kenne natürlich das „Buh für NVidia“.
    • Ich mag Void sehr. Wegen der großen Paketauswahl und des Komforts von systemd ist Arch mein Hauptsystem, aber ich habe Void auf drei Geräten von Verwandten und von mir installiert, und es war hervorragend.
      Man sollte allerdings beachten, dass ich nur eine minimal angepasste xfce-Installation verwendet habe. Komplexe Multi-User-Konfigurationen können mit runit etwas umständlicher sein als mit systemd, weil weniger Funktionen standardmäßig enthalten sind.
    • Vor ein paar Jahren gab es Probleme, Rust unter voidlinux+musl zu verwenden. Zum Glück lässt sich Void leicht mit glibc neu installieren.
    • Chimera könnte ebenfalls passen. Der Userspace der Kernwerkzeuge stammt größtenteils aus der FreeBSD-Welt und dürfte sich für BSD-Nutzer recht vertraut anfühlen.
    • Es gibt auch CRUX. Das ist gewissermaßen die ursprüngliche Distribution, aus der Archlinux hervorging.

  • Ich hatte erwartet, dass jemand erwähnt, dass die man-Pages, auf die BSDs so stolz sind, bei Alpine nicht standardmäßig enthalten sind. Das war einer der Gründe, warum ich Alpine auf meinem Reise-Laptop nicht verwendet habe; inzwischen nutze ich OpenBSD.
    Habe ich bei Alpine eine Konfigurationsoption übersehen, mit der Dokumentation beim Installieren von Paketen immer mitinstalliert wird? Oder bleibt nur, jedes Mal die -doc-Pakete manuell zu installieren?

    • Wenn du Dokumentation immer haben willst, installiere das Meta-Paket docs. Danach zieht es die zu den installierten Komponenten passenden *-doc-Pakete mit herein.
    • Wie ist die Hardware-Unterstützung, wenn man OpenBSD auf einem Laptop nutzt?

  • Ehrlich gesagt verstehe ich überhaupt nicht, warum Leute so etwas wie OpenRC attraktiv finden. Alles, was auf Überwachung basiert, ist meiner Meinung nach besser als ein Ansatz, bei dem man eine PID ausgibt, sie in einer PID-Datei speichert und hofft, dass dieser Wert auch drei Wochen später noch auf den gestarteten Daemon zeigt.
    Außerdem wird in manchen Fällen einfach per pgrep nach einem bestimmten Prozessnamen gesucht, um Service-Management-Aufgaben zu erledigen. Ich kann bis zu einem gewissen Grad nachvollziehen, dass nicht alles standardmäßig automatisch neu gestartet werden sollte, aber das ist praktisch der einzige Vorteil, den diese Fraktion vorbringen kann.
    Und am Ende hängen solche Dinge zudem stark von syslog ab, was im Grunde 80er-Jahre-Technik ist. Tools wie multilog oder svlogd könnten zwar verbessert werden, um leichter eine zentrale Ansicht zu bieten, in der man die Reihenfolge von Ereignissen über mehrere Tools hinweg sieht, aber die Funktion, Logs in unscharfe Kategorien zu packen und jedem zu erlauben, unter beliebigen Namen irgendwohin zu loggen, wirkt merkwürdig.

    • Zur Einordnung: Alpine versucht seit Jahren, OpenRC zu ersetzen, hat aber keinen passenden Ersatz gefunden. Es gibt auch den Versuch, eine vom Init-System unabhängige Distribution zu werden.
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Allerdings ist die wichtigste Alternative systemd, und das ist auf eine Weise entworfen, die nicht sicherheitsfreundlich ist und immer wieder Raum für neue, interessante CVEs lässt.
      In PID1 steckt zu viel, und es ist in einer nicht speichersicheren Sprache geschrieben. Ich sehe keinen technischen Grund, warum man das nicht in ein minimales PID1 und ein paar setuid-Programme aufteilen könnte.
      Mir fällt außer der Möglichkeit, systemd in Docker-Containern laufen zu lassen, nichts ein; Red Hat/IBM dürften aber eher wollen, dass man ihre eigenen Containerisierungswerkzeuge wie systemd-nspawn verwendet, also werden sie das wohl kaum stark wünschen. In der jetzigen Struktur wird das aus Sicherheitssicht meiner Meinung nach niemals wirklich vertretbar.

  • Alpine hat einen amüsanten Vorteil. Wenn Nix-Nutzer mit deklarativem Paketmanagement angeben, kann man direkt /etc/apk/world bearbeiten und apk fix ausführen, um zu zeigen, wie das auch ohne Nix geht.

    • Normalerweise gefällt mir der Gentoo-Ansatz besser. Manuell installierte Pakete können in /var/lib/portage/world, ausgewählte Sets in /var/lib/portage/world_sets und Set-Definitionen in /etc/portage/sets/ liegen.
      So kann man Pakete nach Kategorien aufteilen, nur einen Teil davon auf den Systemen installieren, die ihn brauchen, und Dateien nach Belieben kommentieren. Das Gegenstück zu apk fix ist emerge -uDU @world && emerge -c, was allerdings etwas umständlicher ist.
      Alpine kann mit apk add -t setname pkg1 pkg2 pkg3 ebenfalls etwas Set-Ähnliches anlegen; dabei wird ein Dummy-Paket erzeugt, von dem die ausgewählten Pakete abhängen. Ich erstelle meist Shell-Skripte unter /etc/apk/sets/, um ein Gentoo-ähnliches Gefühl nachzubilden, aber es ist nicht immer dasselbe.
    • In der Zeit, die Nix braucht, um meine System-Flake auszuwerten, kann ich Alpine von Grund auf neu installieren.
    • Es ist schon cool, aber Nix/OS macht deutlich mehr als nur deklarative Paketinstallation.

  • Ich erinnere mich, dass es früher beim Einsatz von Alpine in Docker einige Performance-Artikel gab, die dazu rieten, Debian/Ubuntu zu verwenden.
    Artikel zu langsamem Alpine:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Alpine-freundlicher Artikel:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Ich frage mich, ob das heute noch gilt.

    • Viele der konkreten Beschwerden sind zumindest behoben. Wie auch ganz unten im ersten Link eingeräumt wird, gibt es inzwischen Alpine-kompatible Python-Wheels, und die DNS-Probleme wurden schon vor einiger Zeit behoben.
      Trotzdem wäre es interessant, aus Performance-Sicht Benchmarks laufen zu lassen und echte Zahlen zu sehen.

  • Unterstützt musl nicht immer noch kein pthread_attr_setaffinity_np? Dann kann manche Software nicht laufen, das größte Beispiel ist PyTorch.

    • Wenn eine performancekritische Workload gerade wegen dieser Performance von glibc abhängt, kann man diese Anwendung vermutlich „einfach“ in einem Container laufen lassen.
      In vielen Situationen sind Einfachheit oder Sicherheit wichtigere Anliegen als Performance.

  • Den passenden Mittelweg, den ich zwischen BSD und Linux gefunden habe, ist Slackware. Es ist selbstbewusst Unix-artig und unkompliziert und hat mit Slackbuilds auch einen reichhaltigen eigenen Ports-Tree.

    • Slackware hat versucht, mit Desktop-Distributionen zu konkurrieren, sich dem aber nicht wirklich verschrieben und dabei die Richtung verloren.
      Früher mochte ich es als minimale Distribution, die einem nicht im Weg steht, und sah es als auf etwas technischere Nutzer ausgerichtet.
      Wenn man Problemen auf den Grund gehen wollte, reagierte die Community aber oft feindselig, sobald man keine vollständige Installation gemacht hatte. Die Vollinstallation war eben der empfohlene Weg, und wenn man es anders machte, bekam man dumme Abhängigkeitsprobleme wie dass mplayer nicht funktionierte, weil samba fehlte.
      Meiner Meinung nach ist Alpine in jeder Hinsicht eine Verbesserung gegenüber Slackware.
    • Ich respektiere Leute, die Slackware nutzen, aber das Fehlen von Abhängigkeitsmanagement wirkt mühsam.

  • Alpine Linux war also eigentlich gar kein GNU/Linux. Das wusste ich nicht.
    Ist es dann BusyBox/Linux?

    • Man kann es einfach Alpine Linux nennen. Soweit ich weiß, hat BusyBox nichts mit dem selbstgefälligen Gehabe zu tun, das gelegentlich von RMS durchsickert, also passt das schon.