© hxdyl, 123RF

Mit den richtigen Werkzeuge verwalten Admins ihre Infrastruktur nicht nur automatisch, sondern auch effektiv. Sogar das Thema Devops macht vor der Netzwerkinfrastruktur nicht halt, auch wenn es sich gerade dort erst zögerlich durchsetzt.

Die Art und Weise, mit der Admins die Infrastruktur im Rechenzentrum verwalten, hat sich in den letzten Jahren deutlich verändert: Während die meisten Setups noch vor Kurzem echte Handaufzuchten waren, hat sich im Rechenzentrum mittlerweile Automatisierung flächendeckend etabliert. Dennoch bleiben auch hier blinde Flecke zurück – also Hardware, die nicht automatisiert verwaltet wird, obwohl das grundsätzlich möglich wäre. Netzwerkinfrastruktur ist dafür ein umfangreiches Beispiel, denn Netzwerkadmins pflegen die Hardware von Juniper, Cisco oder den anderen etablierten Herstellern oft noch in mühevoller Kleinarbeit.

Mit steigender Größe des Setups wird es allerdings zunehmend schwierig, die manuelle Pflege des Setups aufrechtzuerhalten. Clouds und alle Installationen, die massiv in die Breite skalieren sollen, haben spezifische Anforderungen, und eine davon ist, in kurzer Zeit viel Hardware ausrollen zu können. Wer dann noch mit händischem Deployment anfängt, schiebt entweder Nachtschichten oder gibt gleich auf.

Die gute Nachricht ist, dass gar keine Notwendigkeit mehr besteht, die Netzwerkinfrastruktur von Hand zu pflegen. Gerade weil Werkzeuge für die Automatisierung der Rechenzentren so verbreitet sind, bieten sich auch dem Netzwerkadmin entsprechende Möglichkeiten.

Der folgende Artikel beschreibt die Optionen, aus denen er sich nach Gutdünken bedienen kann. Dabei liegt das Hauptaugenmerk auf Puppet. Daneben kommt auch Netbox zur Sprache. Das Tool von Digital Ocean, das erst vor ein paar Wochen veröffentlicht worden ist, dreht sich zwar nicht primär um Automatisierung – es leistet aber dennoch einen wichtigen Beitrag in Sachen effizienter RZ-Organisation.

Der Branchenprimus: Puppet

Puppet gehört mit Abstand zu den verbreitetsten Werkzeugen für die Automatisierung unter Linux. Für nahezu jede gängige Applikation existiert mindestens ein Puppet-Modul, für viele große buhlen gar mehrere Module um die Gunst der Nutzer. Klassisch teilen sich Puppet-Module in zwei Kategorien auf: Solche, die aus der Community kommen, und solche, die von Hersteller Puppetlabs offiziell abgesegnet sind.

Dass in echten Devops-Umgebungen auch die Automatisierung von Hardware für Netzwerkaufgaben ein Thema ist, hat man bei Puppetlabs bereits vor Jahren gemerkt. 2014 verkündete der Hersteller deshalb eine Kooperation mit mehreren großen Netzwerkfirmen, darunter neben Cisco auch Arista, Brocade und Huawei. Für deren Geräte stehen seitdem fertige Puppet-Modul bereit. Das Cisco-Modul bietet dabei Cisco selbst in seinem Github-Verzeichnis [1] an. Die anderen Anbieter verfahren genauso.

Unkonventionelle Umsetzung

Weil klassische Netzwerkgeräte keine offenen Plattformen sind, mutet die Umsetzung der Puppet-Integration dort bisweilen seltsam an. Bei Cisco gibt es zum Beispiel die Puppet-Integration für mehrere Modelle der eigenen Nexus-Serie. Auf dem Gerät muss das Puppet-NX-OS-Environment installiert sein, das vorrangig aus dem Puppet-Agenten besteht. Passende Pakete für die Linux-Umgebungen der Cisco-Geräte beziehen Admins direkt von Puppet selbst [2].

Das Setup muss einen Puppet-Masterserver enthalten – der Serverless-Modus, den viele Admins aus Performance-Gründen wählen, funktioniert also nicht. Auf jenem Master ist zwingend das Puppet-Modul von Cisco vorgeschrieben, weil sich nur mit diesem entsprechende Konfigurationen anlegen lassen. Dann folgt eine Routine, die erfahrene Puppet-Benutzer bereits kennen: Der laufende Agent auf dem betreffenden Gerät registriert dieses zunächst beim Master, bevor er sich die dort hinterlegte Konfiguration abholt und das Gerät entsprechend einstellt (Abbildung 1).

Abbildung 1: Cisco bietet für seine NX-OS- und IOS-Geräte umfassenden Puppet-Support über eigens bereitgestellte Geräte.

Der Funktionsumfang des Cisco-Moduls für Puppet ist beachtlich: Es ist in der Lage, praktisch alle wichtigen Konfigurationsoptionen an die Wünsche des Admin anzupassen. Das umfasst neben klassischen Netzwerkparametern wie BGP-Konfigurationen auf Routern etwa auch die SNMP-Konfiguration, sodass sich der Switch im nächsten Schritt automatisch via SNMP abfragen lässt. Selbstredend funktionieren grundlegende Operationen wie Zuweisungen einzelner Ports zu VLANs oder die Konfiguration von Netzwerk-Trunks. Alles in allem hinterlässt die Cisco-Integration für Puppet einen guten Eindruck.

Andere Hersteller auf Augenhöhe

Tatsächlich hat die Kooperation von Puppetlabs mit den Herstellern dazu geführt, dass auch für Geräte von Huawei, Arista und Brocade funktionierende Puppet-Integration zur Verfügung steht. Die unterscheidet sich zum Teil nur in Details wie dem Setup, das der Admin abwickeln muss. Network OS von Brocade braucht auf dem Puppet-Master etwa einen eigenen Brocade-Provider, auf den Brocade-Switches selbst läuft aber kein Puppet-Agent. Dieser muss auf einem separaten Host ausgeführt werden und verbindet sich dann aus der Ferne mit den Switches, um ihnen eine Konfiguration unterzuschieben. Das ist sicher nicht elegant, es erfüllt aber seinen Zweck.

Puppetlabs und Juniper haben zumindest bisher nicht öffentlich kundgetan, Partner zu sein. Das tut der Sache aber keinen Abbruch, denn Juniper kümmert sich für Junos-OS gleich selbst um die ordentliche Integration in Puppet.

Dazu stellt der Anbieter sowohl ein Modul für den Puppet-Master bereit als auch einen auf den Namen »jpuppet« getauften Puppet-Agent (Abbildung 2), der sich auf aktuellen Junos-OS-Releases installieren lässt. Der Rest ist bekannt: Eine entsprechende Konfiguration auf dem Puppet-Master sorgt dafür, dass der Agent der Junos-OS-Geräte diese anhand der Vorgaben des Admin konfiguriert. Genauere Informationen finden Admins unter [3].

Abbildung 2: Auch auf Junos-OS-Geräten von Juniper lässt sich ein Agent für Puppet installieren.

Cisco mit Chef und Ansible

Die schönste Puppet-Integration hilft jenen Admins wenig, die schon eine andere Automatisierung einsetzen. Zwar ist es theoretisch denkbar, die vorhandenen Lösung um Puppet zu ergänzen. Doch müsste im Unternehmen dann Know-how für den Umgang mit beiden Ansätzen bei mehreren Mitarbeitern vorhanden sein. Zum Glück ist Puppet aber nicht die einzige Lösung, die kommerzielles Interesse für Netzkomponenten-Deployment auf sich gezogen hat. Chef unterstützen mehrere Anbieter ebenfalls.

Cisco geht mit gutem Beispiel voran: Quasi analog zur Puppet-Umsetzung für Nexus-Switches bietet das Unternehmen auch ein Chef-Cookbook an. Damit dieses funktioniert, muss auf den Linux-Instanzen der Zielgeräte das Chef-Client-NX-OS-Environment installiert sein, das die benötigten Komponenten enthält [4]. Das passende Chef-Cookbook liefert Cisco ebenfalls mit.

In die Arbeit am Chef-Cookbook hat Cisco jedoch offensichtlich nicht so viel Zeit investiert, wie in das Puppet-Modul geflossen ist. Denn in Sachen Funktionalität ist das Chef-Werkzeug dem Puppet-Kollegen klar unterlegen. Die wichtigsten Parameter lassen sich auf Nexus-Geräten aber auch mit Chef über das von Cisco angebotene Modul steuern.

Sogar für Ansible hat Cisco etwas zu bieten: Aktuelle NX-OS-Versionen mit dem NX-API lassen sich über das »nxos-ansible« -Modul steuern, das auf Github [5] zur Verfügung steht. Das NX-API bieten alle Geräte der Nexus-9000-Serie sowie einige ausgewählte Geräte der Nexus-3000-Serie.

Juniper hält mit

Weil sich Cisco und Juniper als die großen zwei der Netzwerkszene seit Jahren ein Kopf-an-Kopf-Rennen liefern, wundert es nicht weiter, dass sich auch Juniper in Sachen Chef und Ansible nicht lumpen lässt. Für Ansible steht in der Ansible-Galaxy ein eigenes Junos-OS-Modul zur Verfügung [6], über das sich diverse Parameter der Konfiguration modifizieren lassen. Wer stattdessen auf Chef setzt, kann in seinem Junos freilich auch die für Chef benötigten Komponenten installieren und ein entsprechendes, von Juniper bereitgestelltes Cookbook nutzen. Alle Chef-Komponenten hält der Hersteller unter [7] bereit.

Dass Cisco und Juniper sich große Mühe bei der Integration in die gängigen Automatisierungs-Frameworks machen, hängt auch mit der Verbreitung der Geräte dieser Hersteller zusammen. Die Geräte kleinerer Hersteller lassen im Hinblick auf ihren Support für Chef oder Ansible keine generelle Aussage zu; hier wird sich der Admin beim Hersteller wie in der Community selbst nach fertigen Lösungen umsehen müssen.

Die bisher erwähnten Geräte der verschiedenen Hersteller sind in einem Punkt gleich: Es handelt sich um geschlossene Architekturen, also um proprietäre Firmware, die einzig der Anbieter des Geräts binär bereitstellt und die der Admin höchstens so erweitern darf, wie der Anbieter es zulässt. In Sachen Puppet wäre sowohl bei Cisco wie auch bei Juniper kein Weiterkommen, böten die Hersteller für ihre Umgebungen den Puppet-Agent nicht an. Das entspricht der klassischen Vorgehensweise, der viele Netzwerkarchitekturen bis heute folgen und die einen Lock-in-Effekt zur Folge hat.

Wer ein skalierbares Setup auf der grünen Wiese neu plant, hat in dieser Beziehung einen entscheidenden Vorteil: Er kann sich auch gegen den konventionellen Weg entscheiden und von Anfang an auf Hardware setzen, die vom Hersteller mit Software für Devops-Umgebungen ausgerüstet ist.

Offene Firmware folgt Devops-Grundsätzen

Dell hat Anfang des Jahres in Form von OS 10 ein Betriebssystem vorgestellt, das im Kern auf Debian basiert und sich wie ein ganz normaler Linux-Server verwalten lässt (siehe auch den Artikel zu OS 10 in diesem Heft). Der Primus in Sachen Switch-Linux ist allerdings unangefochten Cumulus: Seit Jahren schon propagiert das Unternehmen Netzwerkinfrastruktur, die sich zusammen mit den anderen Hosts eines Setups automatisiert verwalten lässt.

Auch Cumulus baut im Kern auf Linux und bietet dem Admin auf Wunsch die gewohnten Konfigurations-Schnittstellen, vornehmlich also Shellzugriff per SSH. Eine Abstraktionsschicht in der Firmware der Geräte mit dem Namen Switch Abstraction Layer exponiert zur Linux-Seite hin eine normale Netlink-Schnittstelle und redet auf der anderen Seite mit dem verbauten Chipsatz des Switch.

Ein »ip a« auf einem solchen Switch zeigt dem Admin also mindestens so viele Interfaces an, wie der Switch physische Ports hat (Abbildung 3). Weil Cumulus mit Debian kompatibel ist, lässt sich auf den Cumulus-Geräten obendrein fast jedes Debian-Paket installieren.

Abbildung 3: Auf Cumulus-Switches steht ein normales Linux zur Verfügung. Die Ports des Geräts tauchen als normale Netzwerkschnittstellen auf.

Freie Wahl bei Automatisierung

Ein solches Setup bietet in vieler Hinsicht Vorteile: Zunächst kann der Admin den Switch natürlich deutlich vielseitiger nutzen, als es mit typischen proprietären Lösungen möglich ist. Soll ein Switch etwa L3-Routing per BGP für Leaf-Spine-Architekturen ausführen, lassen sich Quagga oder Bird einfach per »apt-get« nachinstallieren. Viel wichtiger ist aber, dass sich ein ganz normales Linux in jede Automatisierungslösung problemlos integrieren lässt. Hier muss der Admin also nicht mehr schauen, ob es seitens der Firma, die den Switch gebaut hat, eine passende Integration in Puppet, Chef oder eine andere Lösung gibt. Stattdessen verwaltet er die jeweilige Hardware mit den Standardwerkzeugen.

Das L3-Routing ist dafür ein passendes Beispiel: Hier muss jeder Port des Switch mit einer IP-Konfiguration versehen sein, und ein BGP-Daemon muss sich um das Announcement der Routen ins Netz kümmern. Ansible erledigt die Konfiguration der Netzwerkschnittstellen über die dafür ohnehin bereits vorhandenen Funktionen. Die Anbindung von Quagga oder Bird geschieht über Playbooks aus dem Netz, die mannigfaltig existieren. Mehr als ein paar Hundert Zeilen Code kommen selbst bei einem vollautomatischen Deployment eines Switch nicht zusammen. Ähnlich verhält es sich mit Puppet oder Chef, in die Linux-Switches sich ebenso integrieren.

Die Verbreitung von Cumulus hat in den letzten Jahren stetig zugenommen. Passende Geräte muss man längst nicht mehr mit der Lupe suchen. Dell führt einige Switches mit vorinstalliertem Cumulus, und auch die Ethernet-Serie von Mellanox (SN2700/SN2410) ist mit Cumulus-Hardware zu haben. Diverse Whitelabel-Switches liefern deren Hersteller ebenfalls mit Cumulus aus.

IPAM und DCIM mit Netbox

Das nächste Tool in der Sammlung richtet sich nicht nur an Admins von Netzwerkinfrastruktur. Netbox [8] verspricht IP-Adressen-Management (IPAM, Abbildung 4) und Management von Infrastruktur im Rechenzentrum (Data Center Infrastructure Management, kurz DCIM, Abbildung 5). Das Werkzeug kommt von Digital Ocean: Der amerikanische Hostinganbieter hat Netbox eine Weile lang im stillen Kämmerlein entwickelt und stellt das Programm nun öffentlich zur Verfügung.

Abbildung 4: Zusätzlich zur DCIM-Funktionalität bietet Netbox auch echte IPAM-Qualitäten. Es ermöglicht also die Verwaltung von Netzwerken.

Unter der Haube arbeitet Netbox mit Python; für das Webinterface kommt Django zum Einsatz, das im Hintergrund mit einer PostgreSQL-Datenbank redet, in der die Netbox-Metadaten liegen. Für den Betrieb der Software ist obendrein ein WSGI-kompatibler Webserver nötig, etwa UWSGI oder der Standard-Apache mit aktiviertem »mod_wsgi« .

Abbildung 5: Netbox ist ein DCIM-System und kann Racktables als Lösung vollständig ersetzen.

Welche Dienste bietet Netbox konkret an? IPAM ist noch relativ klar: In Netbox lassen sich IP-Adressblöcke eintragen, aus denen anschließend einzelne IP-Adressen bestimmten Hosts zuzuweisen sind. Auch die Hosts trägt der Admin zu diesem Zweck in Netbox ein.

Auf der IPAM-Seite steht dem Admin also stets eine Liste der verbauten Hardware samt den IPs zur Verfügung, die aktuell vergeben sind. Doch lassen sich pro Host auch mehrere IPs definieren, etwa wenn ein Host eine offizielle IPv4, eine offizielle IPv6 sowie eine Management-IP auf der BNC-Schnittstelle hat. Die Angabe der IPs lässt sich bis auf die Ebene der Interfaces in Netbox genau angeben. Per Webinterface erfährt der Admin also nicht nur, welche IP-Adressen ein Host gerade besitzt, sondern auch, welches Interface auf dem Host zu welcher Adresse gehört.

Dass ein solches Programm von Digital Ocean kommt, wundert nicht: Als einer der ersten Public-Cloud-Provider sehen die Digital-Ocean-Admins sich mit einer riesigen Menge von Hosts konfrontiert, die sie verwalten wollen. Netbox richtet sich demnach bevorzugt an die Betreiber von großen Infrastrukturumgebungen mit Hunderten Hosts. Hier erfüllt das IPAM nicht nur organisatorische Zwecke, sondern dient im Cluster auch verschiedenen Diensten als Single Source of Truth: Das Deployment von neuen Servern lässt sich erheblich besser automatisieren, wenn die IP für den neuen Host zentral festgelegt und automatisch abfragbar ist.

DCIM als Racktables-Ersatz

Weil für diese Funktionalität ohnehin die Möglichkeit gegeben sein muss, Abhängigkeiten zwischen IP-Adressen, Interfaces in Hosts und Standorten abzubilden, haben die Netbox-Entwickler bei Digital Ocean diese Features gleich mit implementiert – und so quasi als Nebeneffekt ihrer Arbeit gleich auch ein komplettes DCIM geschaffen. Netbox wildert folglich auch im Revier von Racktables: Dort lassen sich zwar Hosts samt enthaltener Hardware verwalten und sogar mit IP-Adressen versehen, dafür fehlt bei Racktables aber wieder die IPAM-Komponente.

Im Grunde ersetzt Netbox also zwei Tools gleichzeitig, nämlich Racktables [9] sowie Nipap [10]. Mit dem Unterschied, dass Netbox auch Abhängigkeiten zwischen Hosts aus dem DCIM und IP-Adressen aus der Adressverwaltung problemlos abbildet. Löscht der Admin etwa einen Host, erkennt Netbox automatisch, dass die diesem Host zugewiesenen IP-Adressen nun wieder frei sind.

Was Netbox noch kann

Stolz heben die Netbox-Autoren hervor, dass sie lange über die Art und Weise nachgedacht haben, wie sie in Netbox Daten verwalten. Heraus gekommen ist schließlich ein feingliedriges Datenmodell, das zwischen Objekten unterschiedlichen Typs unterscheidet. Für jede Ressource, die Netbox verwalten kann, gibt es einen Typ: Beispielhaft erwähnt seien Rechenzentren beziehungsweise Standorte, Racks, Geräte (Server oder Switches), Netzwerkschnittstellen, IP-Adressen oder VLANs. Auch die Verbindungen zwischen zwei Punkten sind ein eigener Objekt-Typ namens Circuit. Die Verwaltung von IP-Adressen und das Verwalten von Hardware im Rack garniert Netbox mit zusätzlichen Funktionen, die alle um das Thema Infrastrukturverwaltung angesiedelt sind.

So bringt das schönste Rechenzentrum wenig, wenn es keine Anbindung zur Außenwelt hat. Die Darstellung eben dieser Anbindung stellt bisherige DCIM- und IPAM-Systeme allerdings vor Herausforderungen, besonders wenn der Datensatz mehrere Rechenzentren umfasst und die Links zwischen diesen Rechenzentren ebenfalls abgebildet sein sollen.

Netbox definiert für diesen Zweck die schon genannten Circuits: Für diese lassen sich unterschiedliche Typen definieren. Neben Internet Transit und Out-of-Band-Connectivity existieren auch die Typen Peering und Private Backhaul. Netbox bietet so also sogar die Möglichkeit für ISPs, bestehende Peerings hin zu anderen Anbietern abzubilden.

Mandantenfähigkeit

Ein Killerfeature in Netbox ist die schon ab Werk eingebaute Mandantenfähigkeit. Es lassen sich damit Organisationslevel festlegen, denen Organisationen zuzuordnen sind. Zwischen diesen Organisationen kann Netbox dann Abhängigkeiten darstellen. Auf diese Weise lässt sich beispielsweise der Umstand abbilden, dass ein Teil der Fläche eines Rack an einen Kunden vermietet ist, der seinerseits als Reseller auftritt und den Platz im Rack ebenfalls gegen Bares bereitstellt.

Alle Objekte in Netbox lassen sich Mietern (so genannten Tenants) zuweisen. Außerdem bietet Netbox die Möglichkeit, die Tenants zu gruppieren. Das ist allerdings eher eine logische Einteilung aus Gründen der Übersichtlichkeit: Wer in Netbox beispielsweise Kunden und Partner getrennt darstellen möchte, erreicht auf diesem Weg sein Ziel.

Ausdrücklich weisen die Netbox-Entwickler darauf hin, dass sie bei ihrer Arbeit dem Pareto-Prinzip folgen. Das besagt – bezogen auf das konkrete Beispiel –, dass sich mit 20 Prozent des Codes 80 Prozent der erwünschten und benötigten Funktionalität realisieren lassen. Oder anders formuliert: Netbox beherrscht nicht jede Funktion, die im IPAM- und DCIM-Kontext möglicherweise wünschenswert wäre. Anstelle von PostgreSQL lässt sich etwa kein bereits vorhandenes MySQL nutzen. Dafür ist die Codebase von Netbox aber auch klein und übersichtlich und der Admin bekommt es nicht mit einem aufgeblähten Monstrum zu tun. Der Performance von Netbox ist das schlanke Design ebenfalls sehr zuträglich.

Export-Templates

Weil DCIM und IPAM bei Providern eine immer größere Rolle spielen, wird früher oder später auch der Austausch von Daten mit anderen Diensten notwendig sein. In dieser Disziplin bietet Netbox gleich mehrere Möglichkeiten. Die wichtigste basiert auf den so genannten Export Templates: Pro Objekttyp legt der Admin dabei Templates an, die ein spezifisches Ausgabeformat vorschreiben. Netbox setzt in dieser Beziehung auf die Template-Sprache von Django, die ihrerseits wiederum stark an die Sprache Jinja2 angelehnt ist – also jene Template-Sprache, die Ansible nutzt. Über vorher festgelegte Parameter greift der Admin in diesen Templates dann auf Objekte in Ansible zu.

Alle zu einem Objekt gespeicherten Werte sind in den Netbox-Export-Templates nutzbar. Der Export selbst geschieht letztlich über die entsprechenden Seiten im Webinterface. So ist es beispielsweise problemlos möglich, Konfigurationsdateien für Nagios automatisiert aus Netbox heraus zu erstellen.

Wer es bunt mag, findet bei Netbox in den zahlreichen Zusatzfunktionen ebenso nützliche Hilfen. Über externe Links ist es möglich, Graphen in die Netbox-Oberfläche zu integrieren – RRD-Daten aus einem bestehenden Monitoringsystem lassen sich auf diese Weise zum Beispiel in einer grafischen Oberfläche in unmittelbarer Nähe zu den Switches anzeigen, zu denen sie gehören.

Mindestens ebenso praktisch sind auch die Topologie-Karten, die Netbox generieren kann: Über ein Suchfeld gibt der Admin dabei diejenigen Geräte ein, die in einer solchen Karte auftauchen sollen. Danach generiert Netbox automatisch ein ansehnliches Schaubild, aus dem klar ersichtlich ist, wie die einzelnen Geräte miteinander verbunden sind – das reicht sogar bis hinunter auf die Ebene von einzelnen Interfaces.

Natürlich auch ein API

Dass Netbox eine Entwicklung des Cloud-Zeitalters ist, zeigt sich auch beim Thema API: Schon jetzt hat Netbox ein Restful-API, über das sich Werte aus der Netbox-Datenbank automatisch und über eine standardisierte Schnittstelle abfragen lassen. Auf diese Weise ist also problemlos möglich, den Inhalt aus Netbox auch in andere Anwendungen zu integrieren, sofern diese das Restful-API abfragen und die dort vorhandenen Daten integrieren können.

Einen Pferdefuß hat die Angelegenheit zwar, denn das API war bei Redaktionsschluss ausschließlich für lesenden Zugriff zu gebrauchen. Laut Aussage der Entwickler soll sich das in absehbarer Zeit aber noch ändern – das API wird also auch schreibende Zugriffe unterstützen. Wer den lesenden Zugriff schon jetzt ausprobieren will, findet unter [11] einen in Go geschriebenen Client für die Kommunikation mit Netbox. Wenn Netbox eine weitere Verbreitung erreicht, dürften Clients in anderen Skriptsprachen aber bald folgen; allen voran freilich die Sprache Python.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.