Nur 103 MB – Alpine Linux getestet: Kleine, simple und sichere Linux-Distribution für den Raspberry Pi

Im Rahmen meiner Beitragsreihe zu Alternativen Betriebssystemen für den Raspberry Pi möchte ich euch heute Alpine Linux vorstellen. „Klein, simpel und sicher“ – mit diesen drei Worten beschreibt sich die seit 2010 existierende Distribution. Sie wurde vor allem im Zusammenhang mit Docker bekannt: Ein Alpine Basisimage ist nur wenige MB groß und damit deutlich kleiner als Debian, Ubuntu und andere Alternativen. Ich habe Alpine Linux auf dem Raspberry Pi getestet und zeige euch sowohl die Vor- als auch Nachteile auf.

Eine Linux-Distribution in 103 MB

Das Erste was einem auffällt: Alpine Linux ist sehr klein. Das gepackte Tar-Gz-Archiv umfasst lediglich etwa 90 MB. Auspackt sind es 97 MB und installiert auf einem Raspberry Pi belegt es auf der Speicherkarte ungefähr 103 MB. Zum Vergleich: Bei der Light-Edition des Raspberry Pi OS werden etwa 1.200 MB belegt, DietPi benötigt immerhin noch knappe 700 MB.

Diese Angaben sind natürlich immer als ungefähre Werte zu verstehen. Mit Updates und anderen Änderungen werden die Betriebssysteme schon in wenigen Wochen ein paar MB größer oder kleiner sein.

Deutliche Unterschiede zu DietPi und dem Raspberry Pi OS

Installation

Die Installation ist etwas aufwändiger, da Alpine Linux den Raspberry Pi zwar offiziell unterstützt. Jedoch werden keine vorgefertigten Abbilder angeboten, die sich etwa mit Etcher oder dem Imager einfach flashen lassen. Stattdessen muss man die Partitionierung von Hand übernehmen. Wie dies unter Windows mit der grafischen Datenträgerverwaltung funktioniert, habe ich im vorherigen Beitrag bereits aufgezeigt. Alternativ lässt sich diskpart auf der Kommandozeile verwenden. Unter Linux ist die Partitionierung natürlich ebenfalls möglich.

(Erste) Einrichtung

Über den Befehl setup-alpine kann ein Skript gestartet werden, welches die wichtigsten Einrichtungsschritte übernimmt: Etwa das Festlegen des Tastaturlayouts, der Zeitzone, Verbindung per Kabel bzw. WLAN herstellen oder die Installation eines SSH-Servers. Ein grafisches Menü existiert eben so wenig wie eine Erklärung zu den einzelnen Fragen des Skriptes. Ein Anfänger wird ohne Anleitung bzw. Hintergrundwissen wahrscheinlich überfordert sein.

Weitere Standardeinstellungen gibt es nicht. Es liegt daher in der Verantwortung des Anwenders, sich beispielsweise einen normalen Benutzer ohne Administratorrechte anzulegen – standardmäßig existiert nur root. Alpine Linux richtet sich damit ähnlich wie Arch eher an erfahrene Anwender, die sich mit Linux auskennen und ihr System individuell einrichten können und möchten.

Installation von Paketen: APK statt APT

Unter Alpine kommt nicht der Paketmanager APT zum Einsatz, den das Raspberry Pi OS von Debian übernommen hat. Stattdessen bringt die Distribution ihre eigene Paketverwaltung namens APK mit. Und der ist extrem schnell: In 0,7 Sekunden wurde die Paketliste mit derzeit rund 4.800 Paketen aktualisiert. Der Prozessmanager htop (13 MB) ist in rund 0,5 Sekunden auf dem Pi, beim Apache2 Webserver (16 MB) dauert es eine gute Sekunde.

apk update      # 0.65s
apk add htop    # 0,47s (13 MB)
apk add apache2 # 1,21s (16 MB)
apk add curl    # 1,36s (18 MB)

Das entfernen ist noch schneller: 0,43 Sekunden um Apache2 mit dem Befehl apk del apache2 zu deinstallieren. Zum Vergleich: Die Paketlisten zu aktualisieren, kann unter dem Raspberry Pi OS schon mal 10 Sekunden dauern. Apache2 wird dort in 15,3s installiert und in 14 Sekunden entfernt. Jeweils mit 150 Mbit Download-Geschwindigkeit, sodass die Internetverbindung nicht der Flaschenhals ist.

Vielfalt und Aktualität der Pakete

Ich habe für ein paar bekannte, verbreitete Pakete die Versionen verglichen. Wie man sieht, ist Alpine fast überall auf der aktuellsten stabilen Version und zieht Updates zeitnah nach.

PHP ist über das Community-Repository erhältlich. Darin erhältliche Pakete werden in Zusammenarbeit mit dem Alpine-Team gepflegt, aber sind möglicherweise nicht dauerhaft verfügbar, wenn der Verantwortliche die Arbeit einstellt. Dafür muss man das Repo in /etc/apk/repositories aktivieren.

Alpine Linux pflegt die Haupt- bzw. Nebenversion eines Paketes für eine bestimmte Betriebssystem-Version: Alpine v3.15 erhält z.B. NodeJS 16, während Alpine v3.15 die Vorgänger-LTS-Version 14.18 bereitstellt. Wahlweise kann man seine Pakete aber auch auf Rolling Release umstellen, d.H. man bekommt immer die aktuellste stabile Version. Dazu in /etc/apk/repositories die Betriebssystemversion (z.B. 3.14) durch edge ersetzen.

Rein von der Anzahl her gewinnt das Raspberry Pi OS: Zum 31.12.2021 sind dort über 59.000 Pakete enthalten, bei Alpine Linux dagegen „nur“ rund 4.800 Stück im Main sowie 15.400 zusammen mit dem Community-Repository.

Kein Systemd: Alpine setzt auf OpenRC

Systemd hat sich in den letzten Jahren als Init-System in vielen Linux-Distributionen durchsetzen können Debian, Ubuntu und Red Hat nutzen es beispielsweise, daher auch das von Debian abstammende Raspberry Pi OS. Alpine verwendet stattdessen OpenRC, ein vergleichsweise eher leichtgewichtiges Init-System.

Standardmäßig landen installierte Programme nicht im Autostart und werden nach der Installation nicht gestartet. Wer das z.B. beim Webserver Nginx einrichten möchte, muss diesen händisch starten und in das Standard-Runlevel eintragen:

rc-service nginx start
rc-update add nginx default

Das erfordert etwas Eingewöhnung, wenn man bisher nur Systemd kennt.

Ein Betriebssystem vollständig im Arbeitsspeicher

Ungewöhnlicher ist dagegen, dass sich Alpine Linux beim Starten in den RAM lädt. Alle Schreibvorgänge werden dort ausgeführt – statt auf das Systemlaufwerk. Für den Raspberry Pi ist das optimal: Speicherkarten sind nicht für all zu viele Schreibvorgänge ausgelegt und zudem nicht besonders schnell. Alpine wird dadurch besonders resistent gegen z.B. Festplattenausfälle oder im Falle des Raspberry dem direkten Ziehen des Netzsteckers ohne sauberes Herunterfahren.

Dadurch ist es notwendig, seine Änderungen abzuspeichern. Dafür gibt es das (Alpine) Linux Backup Utility, kurz LBU. Wenn man etwas an seinem Pi verändert hat, muss man mit LBU diese Änderung permanent auf die Karte in eine sogenannte Overlay-Datei schreiben:

lbu commit
# Bzw. mit -d, um vorherige Overlay-Dateien zu entfernen
lbu commit -d

Vergisst man das Speichern per commit, sind diese nach einem Neustart weg. Das kann aber auch hilfreich sein, um etwas auszuprobieren.

Wichtig: Standardmäßig schließt LBU nur Ordner und Dateien innerhalb von /etc ein! Weitere Pfade lassen sich einschließen, dies muss aber händisch vorgenommen werden.

Fokus auf Sicherheit

Alpine nutzt einen gehärteten Kernel. Außerdem werden alle Pakete mit Schutz vor Pufferüberlauf kompiliert, um die Auswirkungen von Schwachstellen zu reduzieren. Der minimalistische Ansatz kommt der Sicherheit ebenfalls zugute: Je weniger (nicht benötigte) Software man auf dem System installiert hat, um so weniger Angriffsfläche ist vorhanden.

Einsatz von Musl statt glibc kann Probleme bereiten

Viele Programme sind in C oder C++ geschrieben. Die GNU-C-Bibliothek ist eine freie Implementierung von Standardfunktionen für C und wird von vielen Programmen genutzt. Sie steht allerdings in der Kritik, aufgebläht zu sein, wodurch damit entwickelte Programme unnötig größer werden. Alpine Linux hat sich daher für Musl entschieden. Musl ist teilweise mit glibc Binärkompatibel, also kein 1:1 Ersatz.

In der Praxis heißt das: Programme müssen für Musl neu kompiliert werden. Nicht alle laufen unter Alpine Linux. Ein persönliches Beispiel ist das IBM.Data.DB2.Core-lnx NuGet-Paket. Es ermöglicht .NET Core, sich mit einer DB2 zu verbinden. Unter Alpine stürzt die Bibliothek mit Fehlercode 139/Segmentation fault ab. Gerade wenn Binaries in Bibliotheken verwendet werden, kann dies eine Fehlerquelle sein. Ob Probleme auftreten oder nicht, hängt am Ende davon ab, welche Software genutzt wird, was diese genau macht und ob sie mit Musl kompatibel ist.

Stromverbrauch

Da Alpine besonders leichtgewichtig ist, fand ich es interessant, einen Blick auf den Stromverbrauch zu werfen. Im Leerlauf liegt dieser zwischen 1,6 und 1,7 Watt bei einem Raspberry Pi 4. Das ist minimal weniger als beim Raspberry Pi OS in seiner Standard-Konfiguration, dies hatte ich in der Vergangenheit bereits getestet. Allerdings liegt dieser Unterschied im Bereich der Messtoleranz und ist ohnehin derart gering, dass er selbst im 24/7 Dauerbetrieb nicht ins Gewicht fallen würde.

Fazit

Alpine Linux ist eine sehr schlanke Distribution, die sich zudem auf Einfachheit und Sicherheit spezialisiert hat. Sie bietet deutlich weniger Pakete als Debian bzw. das Raspberry Pi OS. Dafür sind die vorhandenen deutlich aktueller. Standardmäßig liegt das komplette Betriebssystem im Arbeitsspeicher. Optional kann dies deaktiviert werden. Aber gerade für den Pi ist es optimal, um Zugriffe auf die Speicherkarte zu vermeiden. Damit muss man jedoch umgehen können, sonst gehen Änderungen ungewollt verloren. Für Anfänger ist Alpine weniger geeignet – schon für die Einrichtung ist eine gewisse Erfahrung notwendig.

Auch für Fortgeschrittene Anwender bleibt dennoch ein größerer Nachteil: Die nicht 100%tige Kompatibilität zur verbreiteten glibc. Zwar sind die Gründe für den Einsatz von musl nachvollziehbar. Als Nutzer bleibt jedoch ein Risiko. Im Zweifel kann man nur testen.

Beachten sollte man hierbei: Falls es jetzt oder in Zukunft Probleme gibt, muss man den Pi mit einem anderen Betriebssystem neu installieren. Das ist aufwändiger als mit Docker: In einem Container-Image wechselt man das Basis-Image, passt die Befehle an und nutzt eben wieder Debian oder etwas anderes. Gerade durch Docker entsteht teils aber auch offizielle Unterstützung, da einige Images zumindest eine Alpine-Variante als Alternative anbieten. Durch Containerisierung kann man solche Probleme lösen und bei Bedarf eine Software, die nicht mit Musl kompatibel ist, in einem Container mit z.B. Debian und glibc laufen lassen. Bei nativen Installationen gibt es diese Möglichkeit nicht, da musl und glibc nicht parallel installiert werden können.

Dennoch ist der Ansatz von Alpine Linux sehr interessant und die Bedienung v.a. vom Paketmanager APK angenehm schnell. Vor allem dort, wo die Ressourcen knapp sind – etwa auf einem Zero oder Zero 2 mit nur 512 MB Arbeitsspeicher. Als Webserver mit PHP kann Alpine z.B. gute Dienste leisten, sofern keine exotischen PHP-Module verwendet werden, die hier nicht laufen.

Wer möglichst uneingeschränkt alles ausprobieren möchte und zudem vielleicht auch noch nicht so erfahren mit Linux ist, der sollte nicht unbedingt mit Alpine einsteigen – sondern zunächst DietPi oder Raspberry Pi OS ausprobieren. Dort erzielt man auch leichter und damit schneller Erfolgserlebnisse. Zudem ist die Unterstützung dafür nach wie vor am größten, wenngleich Alpine mittlerweile auch eine beachtliche Anzahl an recht aktuellen Paketen besitzt.

Quellen und weiterführende Informationen

https://wiki.alpinelinux.org/wiki/Raspberry_Pi
https://wiki.alpinelinux.org/wiki/Create_a_Bootable_Device#Format_USB_stick
https://wiki.alpinelinux.org/wiki/Alpine_local_backup
https://www.alpinelinux.org/about/
https://wiki.alpinelinux.org/wiki/Enable_Community_Repository
https://wiki.alpinelinux.org/wiki/Xfce
https://wiki.alpinelinux.org/wiki/Upgrading_Alpine#Upgrading_Alpine_Linux_on_other_removable_media_.28such_as_CF.2FUSB.29
http://www.etalabs.net/compare_libcs.html
https://wiki.musl-libc.org/functional-differences-from-glibc.html