© AlexeyPetrov, 123RF

Cockpit ermöglicht, eine kleine Server-Farm bequem im Webbrowser zu verwalten. Die Software entwickelt sich permanent weiter und kommt mittlerweile auch mit virtuellen Maschinen und der Docker-Alternative Podman zurecht.

Cockpit [1] bietet eine grafische Oberfläche zum Verwalten von Servern, die sich unter anderem um die Netzwerkkonfiguration, die Server-Auslastung, das Starten und Stoppen von Systemdiensten, eine Benutzerverwaltung und so weiter kümmert. All diese Tasks lassen sich bequem im Webbrowser erledigen. Der Funktionsumfang von Cockpit eignet sich ideal, um einzelne Server oder Server-Farmen in Firmenumgebungen zu verwalten.

Anders als vergleichbare Produkte wie Webmin [2], das über Perl-Skripte auf das Basissystem zugreift, arbeitet Cockpit ausschließlich und direkt mit Systemd. Das zeigt schon die Versionierung der Software, die an jene von Systemd erinnert: Aktuell ist die Version 217. Ein Blick in das Blog [3] verrät zudem, dass ungefähr alle zwei Wochen neue Versionen von Cockpit erscheinen.

In einem Artikel von 2015 [4] hat das Linux-Magazin bereits die Administration von Linux-Servern mit Cockpit vorgestellt; seitdem hat sich einiges getan. Das von Red Hat gesponserte Projekt ist außer für Fedora, Red Hat Enterprise Linux (RHEL) und CentOS mittlerweile auch für Debian (ab Version 9) und Ubuntu (ab 17.04) verfügbar. Die Server-Images von CentOS und Fedora haben Cockpit bereits vorinstalliert im Gepäck. Welche Prozessoren zum Einsatz kommen, spielt dabei kaum eine Rolle: Cockpit läuft sowohl auf x86_64-Architekturen als auch auf 32-Bit-ARMv7 und 64-Bit-ARMv8 (»aarch64«).

Schnellstart

Unter CentOS und Fedora installiert der Admin Cockpit über den Befehl »dnf install cockpit«. Den zugehörigen Systemd-Socket aktivieren und starten dann die Kommandos »systemctl enable cockpit.socket« und »systemctl start cockpit.socket«.

Diese Kommandos erwecken einen Webserver zum Leben, den der Anwender im lokalen Netzwerk über die IP-Adresse des Cockpit-Rechners auf dem Port 9090 erreicht. Eine komplette URL für den Server könnte also »https://192.168.2.3:9090« lauten, wobei Cockpit ein Zertifikat für verschlüsselte HTTPS-Verbindungen automatisch generiert.

Damit alle Admins im Netzwerk den Cockpit-Server erreichen, muss der Installateur unter Umständen noch die lokale Firewall anpassen. Dies klappt auf Fedora und CentOS über die folgenden Befehle:

# firewall-cmd --add-service=cockpit
# firewall-cmd --reload

Wer ein eigenes Zertifikat erzeugen möchte oder bereits über eine passende »*.cert«-Datei verfügt, legt diese alternativ unter »/etc/cockpit/ws-certs.d/« ab.

Sicher anmelden

Die Anmeldung am System erfolgt üblicherweise als Benutzer mit administrativen Rechten (root oder admin) und mit einem Passwort. Als einfacher Benutzer ist eine Anmeldung zwar ebenfalls möglich, jedoch lassen sich in diesem Fall keine Systemeinstellungen ändern. Für eine Single-Sign-on-Authentifizierung lässt sich Cockpit mit Kerberos verheiraten. Seit Cockpit 118 gibt es zudem die Möglichkeit, eine Zwei-Faktor-Authentisierung einzusetzen, auch über Yubikeys.

Die erste Sicht auf das System nach dem Anmelden ist die Systemübersicht, die Informationen über den Server liefert. Die Weboberfläche erlaubt es auch, darüber weitere Server zu administrieren. Dabei gibt es stets einen primären Server [5], auf dem ein SSH-Daemon und der Cockpit Web Service (»cockpit-ws«) laufen. Dieser Rechner steuert und überwacht dann über SSH-Verbindungen gegebenenfalls weitere Maschinen.

Auf diesen sekundären Servern läuft wiederum jeweils eine Cockpit Bridge, die der primäre Rechner über die erwähnten SSH-Verbindungen ansteuert. Die Bridges reichen die Kommandos und Nachrichten, die der Admin im Web-UI aufruft, an die Server weiter. Dabei machen sie umfangreichen Gebrauch von Dbus sowie den zahlreichen Systemd-Diensten.

Server ergänzen

Die Konfiguration weiterer Server erfolgt dann wahlweise über die grafische Oberfläche oder über Textdateien im JSON-Format [6]. Die legt der Admin im Verzeichnis »/etc/cockpit/machines.d/« ab. Eine solche Datei würde in etwa so aussehen wie in Listing 1. Hinter »address« verbergen sich wahlweise die IP-Adressen oder DNS-Namen der Rechner, die Cockpit verwaltet. Diese Einträge sind notwendig, alle weiteren optional.

So bestimmt der boolesche Parameter »visible«, ob ein Server in Cockpit sichtbar ist. Der Eintrag »user« verweist, wie bereits erwähnt, üblicherweise auf »root« oder »admin«. Weil Cockpit die zusätzlichen Maschinen über SSH erreicht, ist Port 22 voreingestellt. Auch diesen ändert der Admin bei Bedarf.

Um die Rechner voneinander zu unterscheiden, besteht zudem die Möglichkeit, ihnen unterschiedliche Farben zuzuweisen, in denen sie dann in Cockpit erscheinen. Das bietet auch eine Gelegenheit, Subnetze farbig zu markieren, wodurch sie der Admin einfacher unterscheiden kann.

{
  "fedora-hc1.reschke.lan": {
    "address": "192.168.2.17",
    "visible": true,
    "color": "green",
    "user": "root"
  },
  "web server": {
    "address": "192.168.2.4",
    "visible": true,
    "color": "rgb(100,**200,**0)",
    "user": "admin"
  }
}

Systemeinblicke

Über das Dashboard (Abbildung 1) erhält der Admin einen schnellen Überblick über die CPU-Auslastung, den Speicherverbrauch und den Zustand anderer Hardware-Komponenten. Hier ergänzt er über das Plus-Symbol weitere Server oder bearbeitet die vorhandenen. Zwischen den eingerichteten Servern wechselt er anschließend recht zügig hin und her. Ist kein Username angegeben, fragt Cockpit beim Anmeldeprozess danach. Treten Fehler auf, erscheint eine entsprechende Meldung.

Abbildung 1: Über Cockpit behält der Admin mehrere Server und deren Hardware-Komponenten im Blick.

Auf der linken Seite listet die grafische Weboberfläche von Cockpit die vorhandenen beziehungsweise installierten Dienste und Anwendungen auf. Dabei bekommt der Admin ganz unterschiedliche Parameter zu Gesicht. Unter Protokolle tauchen die Fehlermeldungen der angeschlossenen Maschinen auf. Der Admin filtert hier nach Schweregrad; zur Wahl stehen etwa Alles, Kritisch, Hinweis oder Debug. Beim Klick auf eine solche Meldung erscheinen dann zusätzliche Details.

Hinter dem Eintrag Speicher verbirgt sich unter anderem eine Anzeige, über die der Admin die Lese- und Schreibgeschwindigkeit der Festplatten im Auge behält. Er überblickt hier aber auch die eingehängten Massenspeicher, die Partitionen und deren Belegungsgrad. Ein weiterer Bereich zeigt Daten zu vorhandenen NFS-Mounts an. Nicht zuletzt liefert dieser Bereich Protokolldateien, die vom angebundenen Storage stammen.

Im Bereich Netzwerk informiert Cockpit nicht nur über den aktuellen Netzwerkdurchsatz auf einem Server, sondern auch über die konfigurierten Firewall-Regeln. Die darf der Admin bearbeiten. Ebenso tauchen hier die konfigurierten Netzwerkschnittstellen auf, mitsamt Details zu MTUs oder dem IPv4- und IPv6-Support.

Neu: Virtuelle Maschinen

Einer der seit dem letzten Linux-Magazin-Artikel neu hinzugekommenen Bereiche in Cockpit heißt Virtual Machines. Hier erzeugt und verwaltet der Cockpit-Nutzer virtuelle Maschinen. Unter der Haube greift Cockpit auf KVM/Qemu sowie die Libvirt zurück. Um das Feature zu nutzen, muss der Admin zusätzlich das Paket »cockpit-machines« nachinstallieren und den Libvirt-Daemon einrichten (Listing 2).

# dnf install libvirt cockpit-machines
# systemctl enable libvirtd --now
# systemctl enable cockpit.socket --now

Läuft der Dienst, richtet der Admin über den Button Create VM einen neuen virtuellen Rechner ein. Diesen über Cockpit zu verwalten, bietet gegenüber dem Einsatz von Virt-Manager einen zentralen Vorteil: Der Admin braucht keine grafische Oberfläche auf dem Server. Wohl auch deshalb ersetzt Cockpit in Fedora, RHEL und CentOS den besagten Virt-Manager [7].

Alles im Pod

Wo sich virtuelle Maschinen tummeln, sind Container meist nicht weit. Unter dem Punkt Podman-Container versammelt Cockpit verschiedene Optionen für Red Hats Variante von Docker. Podman verzichtet im Gegensatz zu Docker auf den Betrieb mit Root-Rechten und auch auf einen zentralen Daemon, ist aber ansonsten zu Docker kompatibel.

Die Oberfläche von Cockpit erleichtert den Podman-Einsatz noch ein Stück weiter. Über den Button Get new image bezieht der Admin fertige Docker-Images aus dem offiziellen Repository. Im Beispiel aus Abbildung 2 hat der Autor das Nextcloud-Image von Ownyourbits installiert.

Abbildung 2: Anstelle von Docker setzt Cockpit als Container-Verwaltung auf Podman.

Darüber hinaus lassen sich diverse Dienste über den gleichnamigen Punkt starten und stoppen. Über Aktualisierungen prüft der Admin, ob es Updates für die Pakete gibt, die Cockpit ausmachen. Daneben lassen sich unter Anwendungen weitere Module für Cockpit installieren. Dazu zählt unter anderem ein Werkzeug namens Image builder [8], mit dem der Admin bei Bedarf Abbilddateien erzeugt, wie etwa ein Anaconda-Boot-Image oder Live-CDs. Im Test funktionierte dieses Feature allerdings aus unbekannten Gründen nicht.

Auch wenn der Admin über die intuitiv aufgebaute Oberfläche einiges erledigen kann, muss er dennoch ab und zu auf ein Terminal ausweichen. Praktischerweise bindet Cockpit auch ein solches ein, das der Admin unter dem Punkt Terminal im linken Bereich der Weboberfläche antrifft.

Fazit

Cockpit entpuppt sich als eine praktische Sammlung von Werkzeugen zur Server-Verwaltung und weiß die Fähigkeiten von Distributionsstandards wie Dbus und Systemd auszunutzen. Die Software ist schon länger ausgereift; das Entwicklerteam dahinter baut sie jedoch permanent weiter aus und ergänzt neue Features. Den Quellcode zum Projekt gibt es auf Github [9].

Die Lokalisierung weist an einigen Stellen noch Lücken auf: Auch bei einer deutschen Spracheinstellung der Oberfläche erscheinen manche Einträge auf Englisch. Aber da Server ohnehin häufig nur in englischer Sprache vorliegen, fällt dieser Mangel nicht allzu stark ins Gewicht.