Gerätemanagement für den Linux-Desktop: Die Lücke, die wir selbst schließen

Nennt mir eine Plattform, und ich nenne euch ihr Gerätemanagement. Windows? Microsoft Intune — und davor SCCM, das jetzt MECM heißt und niemand richtig ausspricht. macOS? Jamf — so selbstverständlich, dass Mac-Administratoren gar nicht anders können. iPhones und iPads? MobileIron, MaaS360, Workspace ONE, ein ganzer Zoo von MDM-Lösungen, die alle denselben Apple-Protokoll sprechen. ChromeOS? Die Google-Admin-Konsole, elegant bis zur Langeweile. Android? Überhaupt kein Problem — jede Knox-Fleet, jeder Handyvertrag kommt mit Management daher.

Und Linux?

Stille.

Genau diese Stille ist die Behauptung dieses Textes: Das Betriebssystem, das die anspruchsvollste Infrastruktur der Welt trägt — Banken, Telekommunikation, Krankenhäuser, Industrie — ist dasselbe, für das niemand ernsthaft ein Gerätemanagement für den Desktop gebaut hat. Nicht kommerziell. Nicht frei. Nirgends mit dem Ernst, den Jamf für Apple aufbringt.

Das ist nicht peinlich. Das ist eine Gelegenheit.

Was Gerätemanagement eigentlich ist

Reden wir nicht über Buzzwords. Gerätemanagement ist eine Disziplin mit klarer Form: Ein Gerät wird angemeldet — Enrollment. Es bekommt Policies — was darf, was muss, was ist verboten. Es bekommt Software — automatisch, still, ohne dass der Nutzer suchen muss. Es wird inventarisiert — wer hat welches Gerät, in welchem Zustand, mit welcher Revision. Es wird aktualisiert — zentral gesteuert, nicht dem guten Willen des Nutzers überlassen. Es wird überwacht — ist es online, gesund, compliant? Und irgendwann wird es zurückgezogen — sicher, sauber, mit allem, was dazugehört.

Das Ganze mit einer Oberfläche, die so selbstverständlich ist, dass der Administrator Flotten von tausend Geräten lenkt, ohne pro Gerät nachzudenken. Apple hat diesen Maßstab mit Jamfs Self-Service-App gesetzt: Der Nutzer sieht eine App, tippt, sie ist da. Konsistent. Freundlich. Aufgeräumt.

An diesem Maßstab messen wir. Nicht an einem niedrigeren.

Der Markt, den es gibt

Schauen wir ehrlich hin. Die kommerziellen Produkte sind nicht schlecht — sie sind erfolgreich, weil sie etwas leisten.

Im Windows-Lager herrscht Intune, cloud-nativ, MDM über Protokoll, zunehmend an Stelle des klassischen SCCM/MECM, das On-Premises und Agent-basiert daherkommt und seinen eigenen Schwergewichts-Charme hat. Beide zusammen — Co-Management — sind die Realität vieler Häuser.

Für Apple ist Jamf der Standard, flankiert von jüngeren Herausforderern wie Kandji, Mosyle und Addigy, alle cloudbasiert, alle ausschließlich auf Apple fokussiert. Wer Macs im Unternehmen betreibt, kommt an diesem Ökosystem kaum vorbei.

Darüber thront das, was heute Unified Endpoint Management heißt: Workspace ONE (einst AirWatch, mittlerweile bei Omnissa), IBMs MaaS360, Ivanti (das MobileIron und Pulse Secure vereint), ManageEngine Endpoint Central, Hexnode. Alle versuchen, alles zu verwalten — Windows, Mac, Mobil, manchmal Linux-Server, selten den Linux-Desktop. Und ChromeOS regiert die Google-Admin-Konsole, für Chromebooks schlicht ideal.

Das Gemeinsame: Diese Welt dreht sich um Windows, Apple und Mobil. Der Linux-Desktop ist in ihr eine Fußnote — wenn er überhaupt erwähnt wird.

Die seltsame Blindstelle

Hier wird es interessant. Für den Linux-Desktop existiert nichts Vergleichbares.

Canonical bietet Landscape an — aber das verwaltet Ubuntu, primär Server, und ist in der Tiefe dünn. SUSE Manager basiert auf Salt, ist aber infrastrukturnah gedacht. Foreman mit Katello provisioniert und konfiguriert, doch sein Herzschlag ist der Serverraum, nicht der Schreibtisch. osquery, gepaart mit Fleet, liefert Sichtbarkeit und Compliance — aber es fragt Zustand ab, es erklärt ihn nicht. Chef und Puppet haben Server-DNA; sie können den Desktop erreichen, aber niemand hat ihnen beigebracht, wie Jamf sich anfühlt.

Keines dieser Werkzeuge liefert das, was ich oben als Maßstab gesetzt habe: eine Gerätemanagement-Erfahrung, die den Desktop ernst nimmt — Profile, Anwendungszuweisung, Nutzereinstellungen, Default-Apps, MIME-Handler, Display-Layouts — und das Ganze mit einer Oberfläche, die Freude macht.

Das ist keine Klage. Das ist eine Diagnose. Die Lücke existiert, weil Linux niemandem gehört — und deshalb niemand ein Produkt dafür baut, das er verkaufen kann. Aber genau das ist auch der Grund, warum wir sie selbst schließen können.

Zurück zum Open Source, auf die harte Tour

Man könnte warten, bis ein Anbieter die Lücke erkennt. Man könnte ein proprietäres UEM kaufen und hoffen, dass es Linux irgendwann ernst nimmt. Beides ist unrealistisch. Wer auf Lieferanten wartet, liefert die Definition seines Werkzeugs aus der Hand — und mit ihr die Souveränität über die eigene Flotte.

Also bauen wir es. Offen. Mit Ansible als Fundament, einer relationalen Datenbank als Quelle der Wahrheit und einem Plugin, das beides verbindet. Auf die harte Tour — weil die harte Tour die einzige ist, auf der man wirklich versteht, was man da baut.

Warum Ansible das Fundament ist

Ansible brauche ich hier nicht groß zu erklären. Agentenlos, SSH, idempotent, beschreibt Zustand statt Vorgang — das habe ich anderswo ausführlich getan. Für Gerätemanagement ist es dennoch nennenswert: Es ist die einzige verbreitete Automation, die nicht voraussetzt, dass auf dem Ziel ein Dienst läuft, den man erst verwalten muss. Ein Rechner, der SSH spricht, ist verwaltbar. Punkt.

Aber Ansible ist das Fundament, nicht die Decke. Es beschreibt Zustand wunderbar — es modelliert ihn nicht. Und genau da beginnt das eigentliche Problem.

Wo YAML an seine Grenzen gerät

Eine kleine Flotte verträgt YAML. Zehn Geräte, ein Inventar, ein paar Gruppen-Variablen — fertig. Aber eine echte Flotte ist nicht linear. Sie ist ein Gefüge aus Geräten, Besitzern, Rollen, Profilen, Standorten, Abteilungen, Ausnahmen, Anwendungsbündeln und Konfigurationsfragmenten, die alle miteinander in Beziehung stehen. Dieselbe App auf drei Profil-Typen, aber nur an zwei Standorten, außer für das eine Gerät, das eine Sonderrolle braucht.

YAML-Anker und -Referenzen sind hübsch. Sie sind aber kein Ersatz für referentielle Integrität, Joins, Constraints, Normalisierung und Transaktionen. Eine flache YAML-Inventarisierung knickt unter ihrem eigenen Gewicht zusammen, sobald die Matrix aus Geräten mal Profilen mal Ausnahmen dreidimensional wird.

Hier braucht es eine echte relationale Datenbank. PostgreSQL. Mit einem durchdachten Schema: Geräte, Besitzer, Profil-Klassen, Anwendungen, Konfigurationsschnipsel, Standorte, Ausnahme-Grants, Enrollment-Zustand. Fremdschlüssel, die Beziehungen erzwingen. Views, die komplexe Fragen in einer Abfrage beantworten. Und ein selbstgeschriebenes Lookup-Plugin, das diese Zeilen beim Lauf in Variablen übersetzt, die Ansible versteht — Relationen, die zu Jinja2-Templates werden.

Die Wahrheit lebt an einem Ort. Templates leiten sich aus Beziehungen ab, nicht aus Kopien. Das ist der Unterschied zwischen einem Inventar und einem Modell.

Warum nicht einfach NetBox erweitern?

Ein berechtigter Einwand — und ich kenne ihn, weil meine eigene Werkzeugsammlung bereits NetBox-Rollen enthält. NetBox ist im Grunde das, was ich gerade beschreibe: PostgreSQL im Rücken, eine Weboberfläche, ein Plugin-System, Custom Fields, Tags, Relationships, REST und GraphQL. Ein Single Source of Truth, geliebt von Netzwerkern, und völlig zu Recht.

Aber NetBox hat einen Rahmen — DCIM und IPAM — und sein Maintainer wahrt diesen Rahmen mit beneidenswerter Konsequenz. Feature-Requests, die nicht ins Netz- und Rechenzeitbild passen, fallen routinemäßig durchs Raster. Das ist kein Makel. Es ist der Grund, warum NetBox exzellent bleibt, statt zu wuchern.

Desktop-Lebenszyklus ist aber eine andere Domäne. Profilzuweisung, Application-Bundles, Nutzereinstellungen, MIME-Defaults, Display-Layouts, Enrollment-State — das modelliert sich nicht natürlich auf Tenant, Site, Rack und VLAN. Zwei Wege bleiben: Entweder ein eigenständiges Schema, gebaut für den Desktop, das sich später eine eigene Weboberfläche gibt. Oder ein NetBox-Plugin, das die Desktop-Modelle mitbringt, ohne den Core zu berühren. Beides legitim. Auf Akzeptanz im Upstream-Core zu hoffen, wäre naiv. Mein Instinkt sagt: Erst die eigenständige, zweckgebaute Wahrheit — und falls die Domänen sich eines Tages versöhnen lassen, wandert sie als Plugin dorthin, wo sie hingehört.

Die Weboberfläche, die irgendwann kommt

Gestehe ich offen: Am Anfang gibt es kein glänzendes Portal. Es gibt SQL, die Kommandozeile und das Plugin. Das reicht für den, der baut — und für den, der weiß, was er tut. Aber Gerätemanagement soll irgendwann von Menschen bedient werden, die kein YAML lesen wollen. Also kommt irgendwann die Weboberfläche: CRUD über dem Schema, Drag-and-Drop-Profilzuweisung, eine Sicht pro Gerät, eine Sicht pro Nutzer, eine Sicht pro Flotte. Bis dahin ist das Schema die Wahrheit — und die Wahrheit ist gut genug strukturiert, dass jede zukünftige Oberfläche nur noch darauf aufsetzen muss.

Alles in Dateien — warum Linux prädestiniert ist

Jetzt der tiefere architektonische Punkt, und der ist der eigentliche Hebel.

Linux ist konfiguriert in Dateien. Dotfiles im Home-Verzeichnis. /etc für das System. systemd-Units als Text. MIME-Handler als Text. Foot, Kitty, Waybar — Text. Und Sway, der Tiling Window Manager, den ich in meiner eigenen Ansible-Rolle mit ausrolle: reine Textkonfiguration. Wer einmal erlebt hat, wie ein Moduswechsel, ein Vollbild, ein Tile sich mit einer Tastenkombination fügt, der versteht, warum das nicht nur effizient ist — es ist schön. Magisch fast. Plötzlich rutscht ein Fenster zur Seite, eins tilen sich daneben, und alles passt, ohne Maus, ohne Menü.

Ich will hier nicht zu lange bei Sway verweilen. Der Punkt ist größer. Bei GNOME leben Einstellungen in dconf, einem binär-affinen Store, der sich templatisch nur widerwillig fügen will. KDE nutzt ini-artige Dateien, aber mit Eigenheiten rund um kded und kwriteconfig. Sway indessen ist purer Text — und purer Text ist Jinja2-Territorium. Eine Rolle, ein Template, ein Rendern — fertig. Genau deshalb ist der Sway-/Wayland-Stack für Ansible so attraktiv: Alles, was definiert ist, ist eine Datei, und jede Datei ist ein Template.

Das ist kein Zufall. Das ist die architektonische Voraussetzung, die Linux für Gerätemanagement mitbringt, die proprietäre Systeme nur teilweise bieten.

Der Manage-My-Network-Werkzeugkasten

Ich rede nicht aus der Theorie. Unter imp1sh auf GitHub liegt meine Ansible-Sammlung ansible_managemynetwork — offen, Debian- und OpenWrt-seitig, gewachsen über Jahre. Dort finden sich Rollen für Sway und Waybar, aber eben auch für den Zabbix-Agenten, SNMPD, Restic und Borgmatic für Backups, Patchday, SSH-Keys, Nutzer und Gruppen, MOTD, Chrony, DNS, Firewall. Das Beweisstück: Das Muster funktioniert. Nichts davon ist theoretisch. Alles ist im Einsatz gewesen — oft genug unter Druck.

Diese Sammlung ist der Same. Das Gerätemanagement, das ich hier skizziere, ist der Baum.

Liebe zum Detail — besser als bei Apple

Jetzt wird es mutmaßlich. Jetzt wird es ehrlich.

Wir reden nicht davon, Funktionalität nachzubauen. Wir reden davon, die Erfahrung zu übertreffen. Konsistent, freundlich, aufgeräumt — so wie Apple es vormachte, aber ohne die Bevormundung. Defaults, die den Nutzer respektieren. Eine Flotte, die sich so leicht lenken lässt, dass der Administrator tausend Geräte verwaltet, ohne pro Gerät nachzudenken. Integration ins Monitoring, die mitwächst: Jedes Gerät rollt automatisch seinen Node Exporter, seinen Zabbix-Agenten, seinen SNMPD aus — die Flotte wird beobachtbar, ohne dass jemand manuell anmeldet.

Das eigentliche Projekt ist nicht, eine Distribution zu erfinden. Es ist, eine bestehende Publikation fortlaufend zu veredeln. Feinschliff. Immer wieder. So konstant, dass irgendwann niemand mehr ehrlich wünscht, er hätte lieber macOS oder Windows. Lol — aber ernst gemeint.

Die Distrowahl

Welche Publikation? Hier wird es konkret, und ich will nicht ausweichen.

Debian ist der natürliche Anker — meine Sammlung zielt darauf, es ist felsengrundsolide, und genau diese Beständigkeit ist ein Geschenk für eine Flotte, die Stabilität verdient. Der Preis: Stable kann für einen glänzenden Desktop zu brav sein. Die Lösung ist pragmatisch — Backports, Flatpaks für aktuelle Anwendungen, selektiv Testing. Kein Dogma, sondern Mischung.

Fedora ist die Lockung: frischer Wayland, aktueller Sway, PipeWire auf dem neuesten Stand, Upstream-nah. Wer den schnellen Desktop will, findet hier wenig zum Meckern. Der Preis ist höhere Taktung — Churn, der eine Flotte ermüden kann, wenn man nicht aufpasst.

openSUSE und Arch-Derivate stehen ebenfalls im Raum; NixOS ist intellektuell reizvoll, aber wartungsmäßig eine eigene Sprache. Wer ehrlich bilanziert: Für kontinuierlichen Feinschliff ohne Brände ist Debian der Boden, auf dem man am ruhigsten baut. Fedora bleibt die Probe für die, die Frische über Stille stellen. Ich tendiere zu Debian — und ich sage es offen, weil die Sammlung es bereits vorgegeben hat.

Integration, die mitwächst

Eine Flotte, die sich selbst anmeldet, ist nur halb fertig. Die andere Hälfte ist Beobachtbarkeit. Sobald ein Gerät onboarded ist, erhält es seinen Exporter, seinen Agenten, seine Backup-Konfiguration — alles aus dem Schema, alles templatisiert. Prometheus kratzt, Zabbix zeichnet, Uptime Kuma pingt. Backups laufen mit Restic oder Borgmatic, verschlüsselt, dedupliziert, ohne dass jemand daran denkt. Retirement zieht sauber zurück: Schlüssel weg, Inventar archiviert, Monitoring stillgelegt. Der ganze Lebenszyklus, gewired.

Wie das Enrollment funktioniert — ehrlich gesagt

Damit das keine Illusion ist: Ansible schiebt von Haus aus vom Controller zum Host — SSH, Push. Roaming-Laptops sind aber selten erreichbar, wenn man sie braucht. Also braucht es Pull-Modus. ansible-pull, getrieben von einem systemd-Timer oder Cron, holt den gewünschten Zustand periodisch vom Repository. Eine leichtgewichtige Steuerung — sei es AWX, sei es ein kleiner Runner — koordiniert, was anliegt. Enrollment ist dann schlicht: ein Gerät, ein Token, ein erster Pull. Kein Zauber. Nur Konsequenz.

Das ist ehrlicher als das Versprechen klassischer MDM-Check-Ins — und für eine Open-Source-Flotte ausreichend robust.

Warum das Sinn ergibt

Vielleicht fragt sich jemand: Baut ihr Jamf für Linux nach? Ja und nein. Ja, weil der Anspruch derselbe ist — Flottenverwaltung, die den Desktop ernst nimmt. Nein, weil der Weg ein anderer ist: nicht ein Produkt, das man kauft, sondern ein Modell, das man besitzt. Quelloffen, relational, textgetrieben, mit Liebe zum Detail.

Die Lücke existiert, weil Linux niemandem gehört. Genau deshalb können wir sie schließen — ohne Erlaubnis, ohne Roadmap eines anderen, ohne Angst, dass ein Vendor den Stecker zieht. Das ist kein Nachteil. Das ist die Bedingung der Möglichkeit.

Wenn Sie eine Linux-Desktop-Flotte betreiben — oder eine planen — und sich gefragt haben, wie das gehen soll, ohne auf proprietäre UEM angewiesen zu sein: Lassen Sie uns reden. Ohne Verkaufsdruck, mit Blick aufs Langfristige. Schreiben Sie an contact@libcom.de. Wir nehmen Bestand auf, ehrlich, nachvollziehbar — und überlegen gemeinsam, ob und wie dieser Ansatz zu Ihrer Flotte passt.