Linux concept: distributie

Niemand installeert "Linux". Je installeert Ubuntu, Debian, Fedora, Arch of Alpine, en elk daarvan geeft je dezelfde kernel, verpakt in een andere set programma's, een andere pakketbeheerder, een ander updateritme en een ander idee van hoe een af systeem eruitziet. Vraag twee beheerders hoe je een webserver installeert en je kunt twee verschillende commando's krijgen, die allebei kloppen. Wat bepaalt welk commando op jouw machine het juiste is, is de Linux-distributie. Zodra je begrijpt wat een distributie eigenlijk is, valt de helft van de verwarrende verschillen tussen Linux-systemen ineens op zijn plek.

2. Waar komt de naam vandaan?

Het woord distributie beschrijft de oorspronkelijke taak vrij letterlijk. Begin jaren negentig betekende "Linux installeren" dat je de kernel op de ene plek ophaalde, de GNU-tools op een andere, een C-bibliotheek, een shell en tientallen kleine programma's weer ergens anders, dat je ze compileerde en zelf op elkaar liet aansluiten. Een distributie was iemand die dat werk al had gedaan en het resultaat als kant-en-klare set schijfimages verspreidde. Je kreeg geen ander besturingssysteem, je kreeg een levering.

Dat is nog steeds de kern van het woord. Een distributie schrijft heel weinig van de software die ze meelevert. Haar echte product is de selectie, de integratie, het verpakken en de belofte om fixes te blijven leveren. De korte vorm distro is informeel, maar zo gangbaar dat je hem ook in officiële documentatie tegenkomt.

De namen van individuele distributies hebben vaak een eigen verhaal:

• Debian is een samentrekking van de namen van Debra en Ian Murdock, die het project oprichtten. Het project spreekt het uit als "Deb-ee-en" (Debian FAQ).
• Ubuntu is, in de woorden van het project zelf, "an ancient African word meaning 'humanity to others'" (ubuntu.com/about).
• Release-codenamen zijn een gewoonte van distributies, niet van Linux. Debian vernoemt zijn releases naar personages uit Toy Story (Debian 13 is trixie), Ubuntu gebruikt een allitererend bijvoeglijk naamwoord met een dier (24.04 is "Noble Numbat", codenaam noble). Je ziet die codenamen in de configuratiebestanden van repositories veel vaker dan de versienummers.

4. Eenvoudige toepassingen

De eerste vragen op elke nieuwe server zijn altijd dezelfde: wat is dit, welke versie, en hoe lang wordt het ondersteund? De antwoorden staan allemaal in een paar bestanden en commando's.

4.1 os-release lezen

Je zag /etc/os-release hierboven al. Het is het standaardantwoord, en het bestaat net zo goed op Debian, Ubuntu, Fedora, AlmaLinux, Arch als Alpine. Zelfs een minimale container-image heeft het:

$ cat /etc/os-release        # inside an Alpine container
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.23.3
PRETTY_NAME="Alpine Linux v3.23"
...

Als een server zo oud is dat hij geen /etc/os-release heeft, vertelt alleen dat al je iets belangrijks: hij is in heel lange tijd niet geüpgraded.

4.2 hostnamectl en lsb_release

Op een systeem dat systemd draait, toont hostnamectl de distributie samen met de kernel en de hardware, een snel overzicht van de hele machine:

$ hostnamectl
 Static hostname: xps
...
Operating System: Ubuntu 24.04.5 LTS
          Kernel: Linux 7.0.0-34-generic
    Architecture: x86-64

Oudere handleidingen gebruiken lsb_release, waarbij de vlag -a (kort voor "all") alles toont wat het weet. Het werkt op Ubuntu, maar het is een apart pakket dat op minimale installaties en in containers vaak ontbreekt, dus vertrouw er in scripts niet op:

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.5 LTS
Release:        24.04
Codename:       noble

4.3 Distributieversie is geen kernelversie

Dit zorgt voortdurend voor verwarring. De distributie heeft een versie, en de kernel heeft een volledig aparte versie:

$ grep VERSION_ID /etc/os-release
VERSION_ID="24.04"

$ uname -r
7.0.0-34-generic

24.04 is de release van Ubuntu, genoemd naar het jaar en de maand: april 2024. 7.0.0 is de Linux-kernel, die op deze laptop veel nieuwer is dan de distributie, omdat Ubuntu LTS-releases nieuwere kernels aanbiedt voor nieuwere hardware. Als een leverancier vraagt "welke Linux-versie?", wil hij bijna altijd beide nummers.

4.4 Uitzoeken hoe lang je release wordt ondersteund

Elke vaste release heeft een einddatum, waarna hij geen beveiligingsupdates meer krijgt. Die datum is het allerbelangrijkste feit over het besturingssysteem van een server, en de termijnen verschillen sterk per distributie:

Zoek de datum voor jouw exacte release op de eigen site van de distributie op, en noteer hem naast de naam van de server. Een server die die datum ongemerkt passeert, blijft prima draaien; hij wordt alleen niet meer gerepareerd.

4.5 Naar de volgende release

De uitweg uit een aflopende release is een upgrade ter plekke naar de volgende, en elke familie heeft daar een eigen procedure voor. Op Ubuntu is het één commando, en de documentatie van Ubuntu voegt eraan toe: "you can only upgrade from one LTS release directly to the next sequential LTS release". Of de tool überhaupt niet-LTS-releases aanbiedt, staat in een klein configuratiebestand:

$ grep Prompt /etc/update-manager/release-upgrades
Prompt=lts

$ sudo do-release-upgrade          # Ubuntu: upgrade to the next release

Debian heeft zo'n tool niet. De release notes zeggen dat je de codenaam in je APT-bronnen aanpast (bookworm wordt trixie), en daarna apt update, apt upgrade --without-new-pkgs en ten slotte apt full-upgrade uitvoert. Fedora gebruikt een dnf-commando dat eerst alles downloadt en het tijdens een herstart installeert:

$ sudo dnf system-upgrade download --releasever=45   # Fedora: fetch the next release
$ sudo dnf system-upgrade reboot                      # install it during a restart

Welke familie het ook is: lees eerst de release notes en maak een back-up. Een release-upgrade vervangt honderden pakketten tegelijk, en dat is het riskantste moment in het leven van een systeem met vaste releases.

6. Gevorderde toepassingen

De paragrafen hierboven gingen over lezen. Deze gaat over de plekken waar verschillen tussen distributies pijn doen: scripts die overal moeten draaien, versiestrings die je moet ontcijferen, containers, en programma's die weigeren te starten.

6.1 Scripts die de distributie kennen

/etc/os-release is gemaakt om door scripts te worden gelezen. Het formaat bestaat uit eenvoudige shellvariabelen, dus een script kan het laden met het commando . en daarna de variabelen testen:

#!/bin/sh
. /etc/os-release

case "$ID" in
    debian|ubuntu)  pkg="apt-get install -y" ;;
    fedora|almalinux|rhel) pkg="dnf install -y" ;;
    opensuse-leap)  pkg="zypper install -y" ;;
    arch)           pkg="pacman -S --noconfirm" ;;
    alpine)         pkg="apk add" ;;
    *)              echo "Unknown distribution: $ID" >&2; exit 1 ;;
esac

Dat werkt tot iemand je script draait op een distributie waar je nog nooit van hebt gehoord. Daar is ID_LIKE voor. De handleiding van os-release zegt dat buildscripts "should check this variable if they need to identify the local operating system and the value of ID= is not recognized". AlmaLinux noemt bijvoorbeeld drie verwanten, de naaste eerst:

$ grep -E '^(ID|ID_LIKE)=' /etc/os-release    # inside an AlmaLinux 9 container
ID="almalinux"
ID_LIKE="rhel centos fedora"

Een robuust script controleert dus eerst ID en loopt daarna ID_LIKE af. Een distributie die van Ubuntu is afgeleid, zet meestal ubuntu of debian in ID_LIKE, en je apt-tak werkt gewoon. Merk op dat het formaat bewust geen shellfuncties ondersteunt behalve gewone toewijzingen, zodat andere programma's het bestand zonder shell kunnen lezen. De volledige lijst velden staat in man os-release en op de documentatiesite van systemd.

6.2 De versiestring van een distributie lezen

Een pakketversie op een distributie is niet de upstream-versie. Het is de upstream-versie plus de eigen wijzigingsgeschiedenis van de distributie. Neem de SSH-client op Ubuntu 24.04:

$ dpkg -l openssh-client | tail -1
ii  openssh-client 1:9.6p1-3ubuntu13.19 amd64        secure shell (SSH) client, ...

Lees 1:9.6p1-3ubuntu13.19 van links naar rechts:

Die ene string vertelt het hele familieverhaal uit paragraaf 3.1: upstream-code, verpakt door Debian, opnieuw aangepast door Ubuntu. Distributies op basis van RPM coderen hetzelfde idee anders; coreutils-9.10-5.fc44 betekent upstream 9.10, de vijfde build van Fedora, voor Fedora 44.

6.3 Distributies in containers

Als je FROM debian of FROM alpine in een Dockerfile schrijft, kies je een distributie. Een container-image bevat de userland van een distributie, haar pakketbeheerder en haar /etc/os-release, maar geen kernel. Elke container op een host gebruikt de kernel van de host:

$ uname -r                                   # the Ubuntu host
7.0.0-34-generic

$ docker exec web uname -r                   # an Alpine container on it
7.0.0-34-generic

$ docker exec web grep PRETTY /etc/os-release
PRETTY_NAME="Alpine Linux v3.23"

Deze Alpine-container is geen demo: het is de Apache-container uit mijn eigen lokale Joomla-ontwikkelomgeving, die op deze Ubuntu-laptop draait. De container meldt zich eerlijk als Alpine, en draait eerlijk op de kernel van Ubuntu. Allebei waar, want een distributie en een kernel zijn verschillende lagen. Dit is het praktische bewijs van de stapel uit paragraaf 1.2. Het artikel over Docker legt uit welke kernelfuncties dit mogelijk maken.

Een virtuele machine is het omgekeerde geval. Die emuleert een hele computer, dus de gast start zijn eigen kernel, en een Debian-VM draait echt een Debian-kernel. Heb je een andere kernelversie of andere kernelinstellingen nodig dan de host, dan heb je een VM nodig, geen container.

Een container-image is ook niet altijd een complete distributie. Basis-images zijn flink uitgekleed, en de kleinste hebben soms geen init-systeem, geen shell of helemaal geen pakketbeheerder. Dat is normaal: een image hoeft maar één applicatie te draaien, geen machine op te starten.

6.4 Als een programma niet wil starten: glibc versus musl

Bijna elke distributie gebruikt de GNU C-bibliotheek, glibc. Alpine is anders: het is "built around musl libc and busybox". De C-bibliotheek is de laag die bijna elk programma aanroept voor basiszaken zoals bestanden openen, dus een programma dat tegen glibc is gecompileerd, verwacht dat glibc er is. Kopieer het programma ls van Ubuntu naar een Alpine-container en probeer het te starten:

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, ... interpreter /lib64/ld-linux-x86-64.so.2 ...

$ docker run --rm -v /usr/bin/ls:/tmp/ls:ro httpd:alpine sh -c '/tmp/ls /'
sh: /tmp/ls: not found

"Not found" voor een bestand dat er duidelijk staat, is een van de verwarrendste foutmeldingen in Linux. Het bestand is er. Wat ontbreekt, is de interpreter die erin wordt genoemd, /lib64/ld-linux-x86-64.so.2, de programmalader van glibc, en die heeft Alpine niet. Alpine heeft zijn eigen lader, die van musl:

$ docker exec web sh -c 'ls /lib/ld-musl*'
/lib/ld-musl-x86_64.so.1

Hetzelfde gebeurt met een gedownload programma dat voor de ene familie is gebouwd en op een andere draait, of met een kant-en-klaar taalpakket (een PHP-extensie, een Python-wheel, een Node-module) dat voor glibc is gecompileerd. De oplossing is het eigen pakket van de distributie installeren, of een build die voor musl is gemaakt. Dat is precies wat de PHP-image van mijn eigen Joomla-ontwikkelomgeving doet: hij begint bij php:8.3.26-fpm-alpine, installeert g++, make en de -dev-headers van ImageMagick, en compileert de extensie imagick met pecl in de image zelf, zodat het resultaat tegen musl linkt en niet tegen glibc. Een programma is alleen overdraagbaar tussen distributies die dezelfde C-bibliotheek gebruiken.

6.5 De commando's van Alpine zijn BusyBox

Het antwoord van apk info --who-owns in paragraaf 5.2 verraadde het al: op Alpine is ls helemaal geen GNU ls. Het is een symbolische link naar BusyBox, één enkel programma dat zich gedraagt als ls, cp, sh en honderden andere commando's, afhankelijk van de naam waarmee het wordt aangeroepen:

$ docker exec web ls -l /bin/ls /bin/sh
lrwxrwxrwx    1 root     root            12 Jan 28  2026 /bin/ls -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Jan 27  2026 /bin/sh -> /bin/busybox

$ docker exec web ls --version
ls: unrecognized option: version

Daarom zijn Alpine-images zo klein, en daarom kunnen vlaggen die alleen GNU kent, uit een handleiding, erin falen. Ook de standaardshell verschilt per distributie: op Debian en Ubuntu is /bin/sh dash; op Fedora is het bash; op Alpine is het BusyBox. Een script dat begint met #!/bin/sh krijgt op elk ervan een andere shell. Het artikel over POSIX legt uit hoe je scripts schrijft die dat overleven.

6.6 Software die de distributie omzeilt

Niet alles op een modern systeem komt via de eigen repositories van de distributie binnen. Formaten zoals snap en Flatpak leveren een applicatie samen met de bibliotheken die ze nodig heeft, zodat hetzelfde pakket op veel distributies draait. Ubuntu 24.04 gaat nog verder en levert Firefox op deze manier. Het Firefox-.deb is alleen een plaatshouder die naar de snap verwijst:

$ dpkg -l firefox | tail -1
ii  firefox        1:1snap1-0ubuntu5 amd64        Transitional package - firefox -> firefo...

$ snap list firefox
Name     Version  Rev   Tracking         Publisher  Notes
firefox  157.0-1  8995  latest/stable/... mozilla**  -

Kijk naar de kolom Publisher: deze Firefox wordt gebouwd en bijgewerkt door Mozilla, niet door Ubuntu. Dat verandert wie verantwoordelijk is voor de fixes. Alles wat paragraaf 7.1 zegt over beheerders van een distributie die beveiligingspatches backporten, geldt voor de pakketten uit de repositories van de distributie. Een snap, een Flatpak, een container-image of een programma dat je hebt gedownload, wordt gepatcht door wie het heeft gepubliceerd, op hun eigen schema, en apt upgrade raakt het niet aan. Houd op een server bij wat waar vandaan komt, en controleer elke bron apart.

8. Beste werkwijzen

• Lees eerst /etc/os-release. Weet op elke onbekende server de distributie, de release en de familie voordat je ook maar één installatiecommando typt.
• Kies voor servers een distributie met vaste LTS-releases. Voorspelbare versies en jarenlange beveiligingsupdates wegen op een productiemachine veel zwaarder dan de nieuwste software.
• Noteer de einddatum van de ondersteuning. Zet hem naast de naam van de server en plan de upgrade ruim van tevoren. Een server voorbij die datum draait nog; hij wordt alleen niet meer gerepareerd.
• Installeer software uit de repositories van de distributie. Die pakketten zijn ondertekend, samen getest en krijgen gebackporte beveiligingsfixes. Een programma dat je zelf compileert of downloadt, is een programma dat je zelf moet patchen.
• Beoordeel beveiliging op de pakketversie, niet op de upstream-versie. Controleer de beveiligingsberichten van de distributie of de changelog van het pakket voordat je een scanner gelooft die alleen het upstream-nummer leest.
• Gebruik ID en ID_LIKE in scripts. Lees nooit PRETTY_NAME of /etc/issue uit; die zijn voor mensen en veranderen van vorm.
• Let op de C-bibliotheek als je programma's kopieert of images bouwt. Een glibc-programma draait niet op Alpine, en een "not found" voor een bestand dat bestaat, betekent meestal precies dat.
• Houd waar het kan dezelfde familie aan op al je servers. Eén pakketbeheerder, één set paden, één set gewoontes: minder verrassingen om drie uur 's nachts.
• Lees de documentatie. man os-release beschrijft elk veld, en het eigen handboek of de wiki van elke distributie is de naslag voor haar tools.

$ man os-release        # every field of the identity file
$ man hostnamectl       # system identity on systemd distributions
$ man dpkg              # Debian family packages (rpm, pacman, apk elsewhere)

10. Samenvatting

Een Linux-distributie is het complete besturingssysteem rond de kernel: de userland, de C-bibliotheek, de pakketbeheerder en repositories, het init-systeem, de standaardinstellingen, en de belofte om het allemaal een vastgesteld aantal jaren te patchen. De kernel wordt gedeeld. Alles wat je in je dagelijkse werk opmerkt, de commando's, de versies, het updateritme, is de distributie.

• Een distributie (of distro) bundelt de Linux-kernel met upstream-software, verpakt die en onderhoudt die; de naam komt van het letterlijk verspreiden van die bundel.
• /etc/os-release identificeert het systeem: ID en VERSION_ID voor scripts, ID_LIKE voor de familie, PRETTY_NAME voor mensen.
• Er zijn zoveel distributies omdat elke een ander evenwicht kiest tussen stabiliteit, versheid, formaat, duur van de ondersteuning en bestuur.
• De meeste distributies horen bij een familie: Debian (apt, .deb), Red Hat (dnf, .rpm), SUSE (zypper, .rpm), of een onafhankelijke zoals Arch of Alpine.
• Distributies kiezen ook de beveiligingsmodule: AppArmor op Ubuntu, SELinux op Red Hat Enterprise Linux.
• Slackware en Debian begonnen allebei in 1993; Ubuntu volgde in 2004, gebouwd op Debian; AlmaLinux en andere herbouwde versies vulden het gat nadat CentOS Linux 8 in 2021 stopte.
• Vaste releases bevriezen versies en backporten fixes; rolling releases zoals Arch werken continu bij en hebben geen versienummer; image-gebaseerde systemen zoals Fedora Silverblue en NixOS vervangen het hele systeem in één stap en houden het vorige opstartbaar.
• Elke vaste release loopt af; do-release-upgrade, de codenaamwissel van Debian plus apt full-upgrade, en dnf system-upgrade brengen je naar de volgende.
• De distributieversie en de kernelversie zijn verschillende nummers; meestal heb je ze allebei nodig.
• Elk bestand hoort bij een pakket: dpkg -S, rpm -qf, pacman -Qo, apk info --who-owns.
• Een pakketversie zoals 1:9.6p1-3ubuntu13.19 bevat de upstream-versie plus de eigen revisies van de distributie, dus een oud upstream-nummer kan nog steeds volledig gepatcht zijn.
• Containers bevatten de userland van een distributie maar gebruiken de kernel van de host; een virtuele machine start haar eigen kernel.
• Snaps, Flatpaks, container-images en gedownloade programma's omzeilen de distributie, dus hun uitgever, niet de distributie, is verantwoordelijk voor het patchen.
• Programma's zijn gebonden aan hun C-bibliotheek: een glibc-programma meldt "not found" op Alpine, dat musl gebruikt en waarvan de commando's BusyBox zijn.

Dit is de handige naslag om te bewaren:

cat /etc/os-release                 which distribution, release and family
. /etc/os-release; echo "$ID"       the distribution ID inside a script
hostnamectl                         distribution, kernel and hardware at once
uname -r                            the kernel version (not the distro version)
cat /etc/debian_version             Debian family: the parent release
dpkg -S FILE                        Debian/Ubuntu: which package owns a file
rpm -qf FILE                        Fedora/RHEL/SUSE: which package owns a file
pacman -Qo FILE                     Arch: which package owns a file
apk info --who-owns FILE            Alpine: which package owns a file
apt-cache policy PKG                Debian/Ubuntu: installed version and its repository
cat /sys/kernel/security/lsm        active security modules (apparmor, selinux)
snap list                           software that bypasses the distribution
sudo do-release-upgrade             Ubuntu: move to the next release
file BINARY                         which loader (glibc or musl) a program expects
man os-release                      every field explained

En als een beveiligingsscan een server als gevaarlijk verouderd markeert terwijl elke update is geïnstalleerd, is het antwoord vaak een distributie die de fixes stilletjes heeft gebackport en het oude versienummer heeft gehouden.