Noem een platform, en ik noem het apparaatbeheer. Windows? Microsoft Intune — en daarvoor SCCM, inmiddels MECM, dat niemand met zekerheid uitspreekt. macOS? Jamf — zo vanzelfsprekend dat Mac-beheerders niet anders zouden kunnen. iPhone en iPad? MobileIron, MaaS360, Workspace ONE — een hele dierentuin van MDM-suite, allemaal hetzelfde Apple-protocol sprekend. ChromeOS? De Google Admin-console, elegant tot vervelens toe. Android? Helemaal geen probleem — elke Knox-fleet, elk abonnement komt met beheer ingebakken.
En Linux?
Stilte.
Die stilte is de stelling van dit stuk: het besturingssysteem dat de meest veeleisende infrastructuur ter wereld draagt — banken, telecommunicatie, ziekenhuizen, industrie — is hetzelfde waarvoor niemand serieus bureaublad-apparaatbeheer heeft gebouwd. Niet commercieel. Niet vrij. Nergens met de ernst die Jamf aan Apple geeft.
Dat is niet gênant. Dat is een kans.
Wat apparaatbeheer eigenlijk is
Laten we ons niet achter modepraat verstoppen. Apparaatbeheer is een discipline met een vaste vorm. Een apparaat wordt ingeschreven. Het krijgt beleid — wat mag, wat moet, wat verboden is. Het krijgt software — automatisch, stil, zonder dat de gebruiker zoekt. Het wordt geïnventariseerd — wie heeft welk apparaat, in welke staat, in welke revisie. Het wordt bijgewerkt — centraal gestuurd, niet overgelaten aan de goede wil van de gebruiker. Het wordt bewaakt — is het online, gezond, compliant? En ooit wordt het teruggetrokken — veilig, netjes, met alles erbij.
Alles verpakt in een interface die zo vanzelfsprekend is dat een beheerder vloten van duizend apparaten stuurt zonder per apparaat na te denken. Apple legde die lat met Jamfs Self Service-app: de gebruiker ziet een app, tikt, hij is er. Consequent. Vriendelijk. Netjes.
Aan die maatstaf meten we. Niet aan een lagere.
De markt die er is
Laten we eerlijk kijken. De commerciële producten zijn niet slecht — ze slagen omdat ze leveren.
In het Windows-kamp regeert Intune, cloud-native, MDM over protocol, het klassieke SCCM/MECM steeds meer verdringend, dat on-premises en agent-gebonden komt met zijn eigen zware charme. Beide samen — co-management — is de realiteit in vele huizen.
Voor Apple is Jamf de standaard, geflankeerd door jonge uitdagers — Kandji, Mosyle, Addigy — allemaal cloud-geboren, allemaal uitsluitend Applegericht. Beheer je Macs in een bedrijf, dan ontkom je nauwelijks aan dit ecosysteem.
Daarboven zit wat nu Unified Endpoint Management heet: Workspace ONE (ooit AirWatch, inmiddels onder Omnissa), IBM’s MaaS360, Ivanti (dat MobileIron en Pulse Secure verenigde), ManageEngine Endpoint Central, Hexnode. Elk probeert alles te beheren — Windows, Mac, mobiel, soms Linux-servers, zelden de Linux-bureaublad. En ChromeOS heerst over de Google Admin-console, voor Chromebooks gewoonweg ideaal.
De gemene deler: deze wereld draait om Windows, Apple en mobiel. De Linux-bureaublad is er een voetnoot — als-ie genoemd wordt.
De vreemde blinde vlek
Hier wordt het interessanter. Niets vergelijkbaars bestaat voor de Linux-bureaublad.
Canonical biedt Landscape — maar het beheert Ubuntu, hoofdzakelijk servers, en dun qua diepgang. SUSE Manager rust op Salt, nabij de infrastructuur gedacht. Foreman met Katello provisieert en configureert, maar diens hartslag ligt in de serverruimte, niet op het bureau. osquery, gepaard met Fleet, levert zichtbaarheid en compliance — maar het ondervraagt toestand, verklaart hem niet. Chef en Puppet dragen server-DNA; ze kunnen het bureaublad bereiken, maar niemand leerde hen hoe Jamf voelt.
Geen levert wat ik hierboven als meetlat zette: een apparaatbeheer-ervaring die het bureaublad serieus neemt — profielen, app-toewijzing, gebruikersvoorkeuren, standaardapps, MIME-afhandelaars, schermindelingen — verpakt in een interface die plezier doet.
Dit is geen klacht. Het is een diagnose. De kloof bestaat omdat Linux aan niemand toebehoort — dus bouwt niemand er een verkoopbaar product voor. Maar precies daarom kunnen we hem zelf dichten.
Terug naar open source, op de harde manier
Men kon wachten tot een leverancier de kloof opmerkte. Men kon een propriëtaire UEM kopen en hopen dat hij Linux ooit serieus nam. Beide zijn onrealistisch. Wie op leveranciers wacht, besteedt de definitie van zijn eigen instrument uit — en daarmee de soevereiniteit over zijn eigen vloot.
Dus bouwen we het. Open. Met Ansible als fundament, een relationele database als bron van waarheid, en een plugin die beide verbindt. Op de harde manier — want de harde is de enige waarbij je werkelijk begrijpt wat je bouwt.
Waarom Ansible het fundament is
Ik hoef Ansible hier niet breed uit te leggen. Zonder agent, SSH, idempotent, toestand declarerend eerder dan procedure — elders heb ik dat bepleit. Voor apparaatbeheer valt toch te benoemen: het is de enige wijdverspreide automatisering die niet veronderstelt dat er een beheerde daemon op het doel draait. Een doos die SSH spreekt, is beheerbaar. Punt.
Maar Ansible is het fundament, niet het plafond. Het declareert toestand prachtig — het modelleert hem niet. En daar begint het eigenlijke probleem.
Waar YAML zijn grenzen raakt
Een kleine vloot verdraagt YAML. Tien dozen, één inventaris, enkele groepsvariabelen — klaar. Maar een echte vloot is niet lineair. Hij is een weefsel van apparaten, eigenaars, rollen, profielen, locaties, afdelingen, uitzonderingen, applicatiebundels en configuratiefragmenten, die allemaal met elkaar in verband staan. Dezelfde app over drie profieldypes, maar enkel op twee locaties, behalve dat ene apparaat dat een speciale uitzondering verdient.
YAML-ankers en -aliassen zijn leuk. Ze zijn geen vervanging voor referentiële integriteit, joins, constraints, normalisatie en transacties. Een plat YAML-inventaris buigt door zijn eigen gewicht zodra de matrix apparaten × profielen × uitzonderingen driedimensionaal wordt.
Dit vraagt een echte relationele database. PostgreSQL. Met een doordacht schema: apparaten, eigenaars, profielklassen, applicaties, configuratieknipsels, locaties, uitzonderingstoekenningen, inschrijfstaat. Vreemde sleutels die relaties afdwingen. Views die complexe vragen in één bevraging beantwoorden. En een zelfgeschreven lookup-plugin die die rijen, tijdens de run, vertaalt in variabelen die Ansible begrijpt — relaties die Jinja2-sjablonen worden.
De waarheid leeft op één plaats. Sjablonen leiden af van relaties, niet van kopieën. Dat is het verschil tussen een inventaris en een model.
Waarom niet gewoon NetBox uitbreiden?
Een terecht bezwaar — en ik ken het, want mijn eigen gereedschapskist bevat al NetBox-rollen. NetBox is in essentie wat ik net beschreef: PostgreSQL eronder, een web-GUI erop, een pluginsysteem, custom fields, tags, relationships, REST en GraphQL. Eén bron van waarheid, geliefd bij netwerkens, en terecht.
Maar NetBox heeft een kader — DCIM en IPAM — en diens beheerder bewaakt dat kader met benijdenswaardige strengheid. Feature-verzoeken die niet in het netwerk-en-datacenterbeeld passen, vallen routinematig door de zeef. Dat is geen gebrek. Het is de reden dat NetBox uitstekend blijft in plaats van te woekeren.
Bureaublad-levenscyclus is echter een ander domein. Profieltoewijzing, applicatiebundels, gebruikersvoorkeuren, MIME-standaarden, schermindelingen, inschrijfstaat — dat modelleert niet natuurlijk op tenant, site, rack en VLAN. Twee wegen blijven: een zelfstandig schema, gebouwd voor het bureaublad, dat op termijn zijn eigen web-GUI krijgt. Of een NetBox-plugin die de bureaubladmodellen meebrengt zonder de kern aan te raken. Beide legitiem. Rekenen op acceptatie in de upstream-kern zou naïef zijn. Mijn instinct zegt: eerst de zelfstandige, doelgebouwde waarheid — en mochten de domeinen zich ooit verzoenen, migreer als plugin naar waar hij hoort.
De web-GUI die ooit komt
Ik geef het ronduit toe: in het begin is er geen glimmend portaal. Er is SQL, de opdrachtregel en de plugin. Dat volstaat voor wie bouwt — en voor wie weet wat hij doet. Maar apparaatbeheer moet ooit bediend worden door mensen die liever geen YAML lezen. Dus komt de web-GUI op termijn: CRUD over het schema, sleep-en-los profieltoewijzing, een weergave per apparaat, per gebruiker, per vloot. Tot dan is het schema de waarheid — en de waarheid is goed genoeg gestructureerd dat elke toekomstige interface er enkel bovenop hoeft te liggen.
Alles in bestanden — waarom Linux voorbestemd is
Nu het diepere architecturale punt, en dat is de ware hefboom.
Linux configureert in bestanden. Dotfiles in de thuismap. /etc voor het systeem. systemd-units als tekst. MIME-afhandelaars als tekst. Foot, Kitty, Waybar — tekst. En Sway, de tiling-windowmanager die ik via mijn eigen Ansible-rol uitrol: pure tekstconfiguratie. Wie ooit een moduswissel, een volledig scherm, een tegel op zijn plek voelde vallen met een toetskombinatie, begrijpt waarom dat niet alleen efficiënt is — het is mooi. Bijna magisch. Plotseling glipt een venster opzij, een ander tegelt ernaast, en alles past — zonder muis, zonder menu.
Ik wil hier niet te lang bij Sway vertoeven. Het punt is groter. In GNOME leven instellingen in dconf — een binair-achtige opslag die zich slechts schoorvoetend laat templeren. KDE gebruikt ini-achtige bestanden, maar met zijn eigenheden rond kded en kwriteconfig. Sway daarentegen is pure tekst — en pure tekst is Jinja2-territorium. Eén rol, één sjabloon, één render — klaar. Juist daarom is de Sway/Wayland-stack zo aantrekkelijk voor Ansible: alles wat gedefinieerd is, is een bestand, en elk bestand is een sjabloon.
Dat is geen toeval. Het is de architecturale voorwaarde die Linux meebrengt voor apparaatbeheer, die propriëtaire systemen slechts gedeeltelijk bieden.
De Manage-My-Network-gereedschapskist
Ik betoog niet vanuit theorie. Onder imp1sh op GitHub ligt mijn Ansible-collectie ansible_managemynetwork — open, Debian- en OpenWrt-gericht, gegroeid over jaren. Erop zitten rollen voor Sway en Waybar, maar evengoed Zabbix-agent, SNMPD, Restic en Borgmatic voor backups, patchday, SSH-keys, gebruikers en groepen, MOTD, Chrony, DNS, firewall. Het bewijsstuk: het patroon werkt. Niets theoretisch. Alles ingezet — vaak onder druk.
Deze collectie is het zaad. Het apparaatbeheer dat ik hier schets is de boom.
Oog voor detail — beter dan Apple
Nu wordt het vermoedelijk. Nu wordt het eerlijk.
We hebben het niet over functionaliteit nasjouwen. We hebben het over de ervaring overtreffen. Consequent, vriendelijk, netjes — zoals Apple het voordeed, maar zonder betutteling. Standaarden die de gebruiker respecteren. Een vloot die zo licht te sturen is dat een beheerder duizend apparaten bestuurt zonder per apparaat na te denken. Monitoringintegratie die meegroeit: elk apparaat rolt automatisch zijn node-exporter, zijn Zabbix-agent, zijn SNMPD uit — de vloot wordt observeerbaar zonder dat iemand handmatig inschrijft.
Het eigenlijke project is niet een distributie uitvinden. Het is een bestaande publicatie voortdurend verfijnen. Fijnslijpen. Telkens weer. Zo consequent dat uiteindelijk niemand oprecht wenst dat hij macOS of Windows terughad. Lol — maar gemeend.
De distro-keuze
Welke publicatie? Hier wordt het concreet, en ik ga niet uit de weg.
Debian is de natuurlijke anker — mijn collectie richt zich erop, het is rotsvast, en die bestendigheid is een geschenk voor een vloot die stabiliteit verdient. De prijs: stable kan te braaf zijn voor een glanzend bureaublad. De oplossing is pragmatisch — backports, Flatpaks voor actuele applicaties, selectief testing. Geen dogma, menging.
Fedora is de verleiding: frisser Wayland, actueel Sway, PipeWire op peil, upstream-nabij. Wie een vlot bureaublad wil vindt hier weinig te mopperen. De prijs is hogere kadans — beweging die een vloot kan vermoeien als je niet oplet.
openSUSE en Arch-derivaten staan ook in de kamer; NixOS is intellectueel lonend maar qua onderhoud een taal apart. Eerlijk balanceren: voor doorlopend fijnslijpen zonder brandjes is Debian de grond waarop je het rustigst bouwt. Fedora blijft de proef voor wie versheid boven stilte stelt. Ik neig naar Debian — en zeg het open, omdat de collectie het al koos.
Integratie die meegroeit
Een vloot die zichzelf inschrijft is slechts half klaar. De andere helft is observeerbaarheid. Zodra een apparaat onboard is, krijgt het zijn exporteur, zijn agent, zijn backup-configuratie — alles uit het schema, alles gesjabloond. Prometheus schraapt, Zabbix noteert, Uptime Kuma pingt. Backups draaien met Restic of Borgmatic — versleuteld, gedupliceerd, zonder dat iemand eraan denkt. Terugtrekking gebeurt netjes: sleutels weg, inventaris gearchiveerd, monitoring stil. De hele levenscyclus, bedraad.
Hoe inschrijven werkelijk werkt — eerlijk gezegd
Opdat het geen illusie zij: Ansible pusht standaard — controller naar host over SSH. Zwervende laptops zijn zelden bereikbaar als je ze wilt. Dus pull-modus. ansible-pull, aangedreven door een systemd-timer of cron, trekt periodiek de gedeclareerde toestand uit de repository. Een lichtgewicht controller — AWX of een kleine runner — coördineert wat openligt. Inschrijven komt dan neer op: een apparaat, een token, een eerste pull. Geen tovenarij. Slechts consequentie.
Dat is eerlijker dan de belofte van klassieke MDM-check-ins — en voor een open-source-vloot robuust genoeg.
Waarom dit zinvol is
Iemand moge zich afvragen: bouwen jullie Jamf voor Linux na? Ja en nee. Ja, want de ambitie is dezelfde — vlootbeheer dat het bureaublad serieus neemt. Nee, want de weg verschilt: geen product dat je koopt, maar een model dat je bezit. Open source, relationeel, tekstgedreven, met oog voor detail.
De kloof bestaat omdat Linux aan niemand toebehoort. Precies daarom kunnen we hem dichten — zonder toestemming, zonder andermans roadmap, zonder angst dat een leverancier de stekker eruit trekt. Dat is geen nadeel. Dat is de voorwaarde van mogelijkheid.
Als je een Linux-bureaublad-vloot beheert — of er een plant — en je hebt je afgevraagd hoe dat moet zonder op propriëtaire UEM te leunen: laten we spreken. Zonder verkoopdruk, met oog op de lange termijn. Schrijf naar contact@libcom.de. We nemen inventaris op — eerlijk, navolgbaar — en bedenken samen of en hoe deze aanpak bij jouw vloot past.