Der Alpine-Linux-Versuch eines BSD-Nutzers

 (rubenerd.com)
1 Punkte von GN⁺ 2024-04-28 | 1 Kommentare | Auf WhatsApp teilen

  • Die Geschichte von Alpine Linux

    • Alpine Linux ist eine unabhängige, nicht-kommerzielle Linux-Distribution für den allgemeinen Einsatz, die für Power-User entwickelt wurde, denen Sicherheit, Einfachheit und Ressourceneffizienz wichtig sind
    • Alle Userland-Binärdateien werden als PIE (Position Independent Executables) kompiliert und mit Stack-Smashing-Protection versehen, wodurch ganze Klassen von Exploits wie bei Zero-Day-Schwachstellen im Voraus verhindert werden
    • 2005 diskutierte Natanael Copa den Start des Projekts, und wie BSD wird es nicht nur auf Embedded-Systemen, Routern und Mobilgeräten, sondern auch auf allgemeinen Servern und Desktops eingesetzt
    • Aufgrund seiner kompakten Größe und begrenzten Abhängigkeiten ist es auch als Basis für Linux-Container beliebt
    • Es bietet außerdem eine Toolchain, die sich leicht in chroot(8) ausführen lässt, was für Menschen interessant ist, die NetBSD chroots(8) und FreeBSD Jails intensiv nutzen

  • Installation von Alpine Linux

    • Es ist in mehreren Varianten verfügbar, darunter Builds für ARM, PPC64, x86 und x86_64
    • Der Installationsprozess ist sehr einfach: In der Live-Umgebung als root anmelden und setup-alpine ausführen
    • Man wird nach grundlegenden Dingen wie Keymap, Netzwerk, Zeitzone und Root-Authentifizierung gefragt; außerdem lassen sich SSH-Schlüssel von Anfang an einspielen, was nützlich ist, wenn man per Orchestrierungs-Tool VMs oder Serverfarmen ausrollt oder bei Hosting-Anbietern ohne bereitgestellte Medien deployt
    • Man kann aus einigen SSH-Servern und NTP-Clients wählen, darunter bevorzugt OpenSSH und openntpd, und auch die Ausführung unter Xen wird korrekt erkannt
    • Man kann auch LVM einrichten, vorerst bleibt man aber bei der Standard-sys-Partition von Alpine mit ext4

  • Erkundung nach der Installation

    • Beim ersten Start von Alpine wird klar, warum es besonders ist: dmesg(1) teilt mit, dass OpenRC läuft
    • Es ist portabel, klein, schnell, effizient, transparent und sicher
    • Für BSD-Nutzer, die mit dem Schreiben von rc-Skripten vertraut sind, fühlt es sich sehr vertraut an
    • Die Existenz von /etc/rc.conf und crond(8) sorgt für Freude
    • Es ist sehr erfreulich, das in Linux-Distributionen wie Devuan, Gentoo und Alpine zu sehen, und es macht Linux wieder spaßig
    • Zusammen mit OpenRC werden musl und busybox mitgeliefert, was die Größe des Basissystems und die Angriffsfläche weiter reduziert
    • Auch llvm und eine der bevorzugten interaktiven Shells, die MirBSD Korn Shell, sind verfügbar

  • Pakete

    • Alpines Standard-Paketmanager ist apk; wie unter Linux üblich kümmert er sich um Updates, ohne zwischen Basissystem und allen Paketen zu unterscheiden
    • Man möchte wie unter BSD prüfen, ob sich eine unprivilegierte Kopie ausführen lässt, hat das aber noch nicht getestet; außerdem gibt es pkgsrc, sodass das kein Problem ist
    • Die Konfiguration befindet sich in /etc/apk/repositories; man kann das Community-Repository aktivieren, indem man die zweite vom Installer eingetragene URL auskommentiert
    • Alpine hat außerdem ein testing-Repository, und man kann eigene Repositories hinzufügen
    • Die Nutzung ist einfach, aber aus alter Gewohnheit tippt man immer noch versehentlich apt install statt apk add
    • Es gibt eine offizielle Weboberfläche, und die Alpine-Repositories sind auf pkgs.org zu finden
    • Das Überraschendste war das zfs-Paket: Zum Installieren und Laden des Kernel-Moduls waren nur zwei Befehle nötig (Root auf ZFS wäre wohl komplizierter)

  • Fazit

    • Es wurde nur an der Oberfläche gekratzt, aber es gibt genug gute Gründe, ernsthaft über einen Wechsel zu Alpine als primäre Linux-Distribution für Tests und Server nachzudenken
    • Gefällt daran, dass htop(1) und lsof(1) nur eine kleine Liste erkennbarer Prozesse anzeigen, OpenRC verwendet wird, die Paketverwaltung einfach wirkt und die Konfiguration sehr schlicht ist
    • Man hat sich gefragt, wie ein modernes und funktionales „Occam’s Linux“ aussehen würde, und genau das ist es
    • Wenn mehr als busybox nötig ist, würde man gern prüfen, ob uutils läuft, bei Servern ist man aber skeptisch

Meinung von GN⁺

  • Alpine Linux ist für containerbasierte Deployments optimiert und wird daher auf Container-Plattformen wie Docker breit eingesetzt. Als Distribution ist es bei der Umsetzung von Microservices-Architekturen mit Containern definitiv einen Blick wert.

  • Dass standardmäßig musl libc verwendet wird, kann zugleich Vor- und Nachteil sein. musl ist gegenüber glibc leichtergewichtig und hat Vorteile bei der Sicherheit, kann aber bei manchen Anwendungen zu Kompatibilitätsproblemen führen. Deshalb sollte man die Kompatibilität der eingesetzten Anwendungen vorab prüfen.

  • Auch die Verwendung von ash als Standard-Shell ist bemerkenswert. ash bietet im Vergleich zu bash weniger Funktionen, ist aber sehr leicht und schnell und dürfte in ressourcenbeschränkten Umgebungen wie Embedded-Systemen nützlich sein. Für allgemeine Nutzer könnte sie dagegen etwas unbequem sein.

  • Wer hauptsächlich BSD-artige Betriebssysteme nutzt, dürfte Alpine Linux wegen der vertrauten Umgebung attraktiv finden. Allerdings wirkt die Unterstützung für Desktop-Umgebungen noch etwas unausgereift, sodass es eher für Server oder Embedded-Zwecke geeignet scheint.

  • Insgesamt scheint Alpine Linux als leichtgewichtige und sicherheitsoptimierte Distribution durchaus ein eigenes Profil zu haben. Allerdings ist das eigene Ökosystem noch nicht besonders groß, sodass bei Problemen die Community-Unterstützung etwas begrenzt sein könnte. Dennoch ist zu erwarten, dass Alpine Linux mit der Zeit durch seine Stärken immer mehr Nutzer gewinnen wird.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-28
Hacker-News-Kommentar

Zusammenfassung:

  • Linux-Binärdateien werden als PIE (Position Independent Executable) kompiliert und sind dadurch sicherer

  • GLIBC hat die am stärksten gehärtete Heap-Implementierung und bietet mehr Schutzmaßnahmen gegen Heap-Schwachstellen wie Double Free

  • Alpine verwendet musl und ist daher im Vergleich zu GLIBC weniger sicher. Ein kleines, leicht verständliches System hilft der Sicherheit

  • Illumos (OpenSolaris) wird nach jahrzehntelanger Linux-Nutzung als insgesamt deutlich einfacher empfunden

  • Das meiste, was unter Solaris 10 funktionierte, lässt sich mit kleinen Anpassungen bis heute weiterverwenden

  • Zones sind Docker-Containern 10-mal überlegen, und ZFS-Unterstützung ist integriert

  • Dienstverwaltung mit SMF. Der einzige Nachteil ist die Konfiguration per XML

  • Geteilte Erfahrungen mit Servern auf OmniOS und SmartOS

  • Als BSD-Nutzer wurde Alpine erstmals auf bhyve ausprobiert

  • Dank BusyBox müssen die Dienstprogramme in /bin und /sbin nicht als getrennte Binärdateien vorliegen; der User-Space ist klein und der Bootvorgang schnell

  • Mit tmux und zsh reicht es für die meisten Unix-Anwendungsfälle

  • Es mussten viele apk-Pakete installiert werden, aber insgesamt war es die beste Linux-Erfahrung überhaupt

  • Wünschenswert wären integriertes ZFS und Virtio-Bindings für bhyve

  • Void Linux wird BSD-Nutzern ebenfalls empfohlen. Es wurde von einem NetBSD-Entwickler erstellt, es gibt glibc- und musl-Versionen, und runit wird als Init-System verwendet

  • Mit xbps-src lassen sich Pakete aus dem Quellcode bauen

  • Manche meiden Alpine, weil standardmäßig keine man-Pages enthalten sind

  • Es wird gefragt, ob es eine Option gibt, bei der Paketinstallation Dokumentation automatisch mitzuinstallieren

  • Es gab Beiträge zur Alpine-Performance in Docker. Empfohlen werden Debian/Ubuntu

    • Gründe, warum Alpine langsam sei: geringere Python-Performance, 50 % langsamer als ein Ubuntu-Image
    • Ein Beitrag zur Verteidigung von Alpine: Performance-Benchmarks im Vergleich zu Debian

  • Es wird gefragt, ob das noch aktuell ist

  • Es ist nicht nachvollziehbar, was an OpenRC usw. so attraktiv sein soll. Auf Supervision basierende Optionen werden als besser angesehen als die Verwaltung über PID-Dateien

  • Es wird eingeräumt, dass fehlender automatischer Neustart ein Vorteil sein kann

  • Auch die starke Abhängigkeit von syslog wirkt wie Technik aus den 80ern

  • Zustimmung dazu, dass eine bessere zentrale Sicht nötig ist, um die Ereignisreihenfolge verschiedener Tools zu verstehen

  • Ein Vorteil von Alpine: Auch ohne Nix ist deklarative Paketverwaltung möglich, indem man /etc/apk/world bearbeitet und danach apk fix ausführt

  • Slackware ist ein Kompromiss zwischen BSD und Linux. Es ist Unix-artig und nicht unnötig komplex. Slackbuilds bietet einen umfangreichen Port-Baum

  • Manche Software wie PyTorch läuft nicht, weil musl pthread_attr_setaffinity_np nicht unterstützt