Vier Mausklicks im Browser starten den abgestürzten Webserver neu, vier weitere schalten die Netzwerkschnittstellen des Fileservers per Bonding zusammen. Eine derart komfortable Administration von Linux-Servern ermöglicht Cockpit. Im Gegenzug müssen Piloten mit ein paar Einschränkungen leben.
Mit Cockpit lässt sich ein Linux-System bequem per Browser administrieren und fernsteuern [1]. Unter anderem wirft der Admin einen Blick in das Systemd-Journal, prüft die Auslastung, startet und stoppt Dienste. Dank Responsive Design passt sich die Benutzeroberfläche automatisch unterschiedlichen Bildschirmgrößen an, was wiederum einen komfortablen Zugriff über Smartphones ermöglicht.
Administratoren dürfen zudem jederzeit auf die Kommandozeile wechseln, dort Webserver starten und neue Benutzerkonten anlegen. Sie tauchen anschließend in der Webanwendung auf. Über die verwaltet der Admin auch mehrere Linux-Systeme. Dazu macht er Cockpit lediglich auf die übrigen Server aufmerksam, auf denen die Software allerdings ebenfalls laufen muss.
Mit diesem Funktionsumfang ähnelt das von Red Hat entwickelte Cockpit dem bekannten Webmin [2]. Die laut Eigenwerbung einfach zu benutzende und “sehr leichtgewichtige” Benutzeroberfläche spricht dabei vor allem weniger erfahrene Admins an. Cockpit eignet sich aber auch, um einen Heimserver beziehungsweise kleinere Firmennetzwerke zu verwalten. Das unter der LGPL 2.1 stehende Tool sollte der Nutzer übrigens nicht mit dem fast namensgleichen Open IT Cockpit [3] verwechseln.
All inclusive
Red Hat arbeitet seit nicht einmal ganz zwei Jahren an Cockpit. Zwar findet die Arbeit daran mittlerweile offen auf Github [4] statt, doch merkt der Beobachter dem Projekt seine Nähe zu Red Hat an, beispielsweise an der verwendeten Distribution. So installieren Fedora 21 Server, Centos Atomic und RHEL Atomic das Tool zur Serververwaltung bereits vor. Fertige Pakete gibt es lediglich noch für Fedora 21 Workstation und Arch Linux. Unter Fedora 21 Workstation installiert der Befehl
yum install cockpit
die Steuerzentrale. Nutzer von Arch Linux spielen das Paket »cockpit« über das Arch-User-Repository (AUR) ein. Die Fedora 21 beiliegende Cockpit-Version meldet sich allerdings noch mit der Nummer 0.27 vom Herbst 2014, zum Redaktionsschluss aktuell war jedoch bereits die Version 0.52. Außer im kosmetischen Bereich hat diese sich bislang allerdings nicht sonderlich verändert.
Wer eine andere Distribution verwendet, etwa Ubuntu oder Debian, muss den Quellcode selbst übersetzen. Da Cockpit jedoch stark auf Fedora und insbesondere Systemd aufsetzt, gerät die Inbetriebnahme zu einem kleinen Hürdenlauf. So muss sich der Administrator zunächst die zahlreichen Abhängigkeiten in der »cockpit.spec« -Datei zusammensuchen. Wie er die Software für Ubuntu 15.04 übersetzt, beschreibt der Kasten “Vivid Vervet” am Beispiel.
Vivid Vervet
Um Cockpit unter Ubuntu 15.04 zu installieren, spielt der Admin zunächst alle benötigten Pakete ein:
sudo apt-get install xsltproc libglib2.0-dev libjson-glib-dev libpolkit-agent-1-dev libkrb5-dev liblvm2-dev libgudev-1.0-dev libssh-dev libpam0g-dev libkeyutils-dev libpcp3-dev libpcp-import1-dev libpcp-pmda3-dev intltool xmlto libsystemd-journal-dev libsystemd-daemon-dev libxslt1-dev npm nodejs selinux-policy-dev checkpolicy selinux-policy-doc libdbus-1-dev
Anschließend angelt er sich aus dem Github-Repository [5] das ».tar.bz2« -Archiv der letzten stabilen Cockpit-Version, entpackt es und übersetzt Cockpit dann mit Hilfe des bekannten Dreisatzes:
./configure make make install
Um sich später bei Cockpit anzumelden, muss er abschließend noch über
sudo passwd root
dem allmächtigen Benutzer »root« ein Passwort spendieren.
Auf Distributionen ohne Systemd lässt sich Cockpit gar nicht erst in Betrieb nehmen. Das betrifft neben früheren Ubuntu-Versionen auch Debian-Systeme bis einschließlich Version 7. Wer Cockpit per Hand installiert hat, muss es abschließend noch über das Systemd-Tool »systemctl« starten:
systemctl enable cockpit.socket systemctl start cockpit.socket
Unter Fedora 21 Server, Centos Atomic und RHEL Atomic geschieht dies bereits automatisch.
Zugriff
Cockpit lässt sich via HTTPS über den Browser auf TCP-Port 9090 erreichen. Besitzt der Server beispielsweise die IP-Adresse 192.168.100.11, ruft der Administrator entsprechend die URL »https://192.168.100.11:9090« auf. Unter Umständen muss er noch ein Loch in die Firewall bohren. Unter Fedora 21 Workstation übernehmen das die beiden Befehle:
firewall-cmd --reload firewall-cmd --add-service=cockpit
Die Firewall in Fedora 21 Server akzeptiert bereits von Haus aus Verbindungen auf Port 9090. Das sollten Admins insbesondere dann im Hinterkopf behalten, wenn sie den Zugriff auf Cockpit verbieten möchten. Wer einen anderen Port bevorzugt, muss die Einstellung »ListenStream« in der für Systemd bestimmten Konfigurationsdatei »cockpit.socket« anpassen. Diese Datei liegt normalerweise im Ordner »/usr/lib/systemd/system/« , anschließend muss Systemd die Änderungen übernehmen:
systemctl daemon-reload systemctl restart cockpit.socket
Cockpit erzwingt eine gesicherte Verbindung via HTTPS und leitet HTTP-Anfrage automatisch um. Dabei kommt ein selbst signiertes Zertifikat zum Einsatz, das der Betreiber beim ersten Zugriff auf Cockpit im Browser akzeptieren muss. Eine Ausnahme bildet der Zugriff auf den Server selbst über »http://localhost:9090« . Hierbei erlaubt Cockpit auch unverschlüsselte Verbindungen.
Wer ein eigenes Zertifikat nutzen möchte, legt es als »cert« -File mit eben dieser Endung im Verzeichnis »/etc/cockpit/ws-certs.d« ab. Lagern dort mehrere Zertifikate, verwendet Cockpit immer die erste Datei in alphabetischer Sortierung. Das Zertifikat »a.cert« erhält folglich den Vorzug vor »z.cert« . Sofern im besagten Verzeichnis kein Zertifikat liegt, erstellt Cockpit automatisch selbst eines. Fedora 21 liegt bereits ein selbst signiertes Zertifikat »/etc/cockpit/ws-certs.d/~self-signed.cert« bei.
Die Kommunikation mit dem Browser verschlüsselt Cockpit via TLS und aktuellen Verschlüsselungsverfahren. Die als unsicher geltenden Standards SSLv3.0 und RC4 sind deaktiviert.
Klickibunti
Mit dem gleichen Gespann aus Benutzernamen und Passwort, mit dem sich der Administrator direkt auf dem Server einloggt, meldet er sich auch bei Cockpit an. Verbietet ihm das verwaltete Linux-System beispielsweise ein Benutzerkonto einzurichten, blockiert Cockpit diese Aktion ebenfalls. Für den vollen Zugriff auf das System muss der Systemverwalter folglich als Benutzer »root« bei Cockpit vorstellig werden.
Am Steuerknüppel
Auf seiner Startseite bietet Cockpit dem Admin zunächst alle ihm bekannten Server zur Auswahl an (Abbildung 1). Direkt nach der Installation ist dies nur der Server, auf dem Cockpit läuft. Neuere Cockpit-Versionen präsentieren an dieser Stelle hingegen stets Informationen über den Server.
Die Server-Auswahl versteckt sich dabei hinter dem »Dashboard« (Abbildung 2). Per »Add Host« – oder bei neueren Varianten über das Plus-Symbol – fügt der Serverbetreiber weitere Maschinen hinzu. Cockpit benötigt dazu lediglich die IP-Adresse oder den Hostnamen des Servers sowie den Benutzernamen und das Passwort des Admin. Die Software meldet sich dann mit diesen Daten auf der neuen Maschine an und befragt sie nach den benötigten Informationen. Tritt dabei ein Fehler auf, gibt es allerdings keine Fehlermeldung, der Server fehlt dann schlicht in der Liste.
Den zu steuernden Server wählt der Administrator mit einem Klick auf die entsprechende Zeile aus (in Abbildung 1 also mit einem Klick auf »localhost« ). Cockpit liefert jetzt sekündlich aktualisierte Informationen über die Auslastung der wichtigsten Hardwarekomponenten (Abbildungen 3 und 4). Das Menü auf der linken Seite erlaubt den Zugriff auf alle wichtigen Funktionen und Aktionen. Beispielsweise gewährt ein Klick auf »Journal« Einblick in das Systemd-Journal, während der Administrator unter »User Accounts« beziehungsweise »Tools | Administrator Accounts« die Benutzerkonten verwaltet.
In der schwarzen Leiste am oberen Seitenrand führt Cockpit eine Brotkrumen-Leiste: Ein Klick auf einen der Punkte führt wieder zurück zur entsprechenden Seite. Hinter »Hosts« beziehungsweise »Dashboard« wartet dabei die Liste mit allen Servern.
Funktionsstau
Die Benutzeroberfläche macht nicht immer deutlich, welche Elemente sich anklicken lassen. Ruft der Administrator im Hauptmenü etwa den Eintrag »Networking« auf, so scheint er dort nur über die entsprechenden Buttons ein Bonding, eine Bridge oder ein neues VLAN anlegen zu können.
Die restlichen Anzeigen geben Auskunft über die empfangenen und übertragenen Pakete sowie den Status der einzelnen Netzwerkschnittstellen. Die lassen sich jedoch ebenfalls in der Liste »Interfaces« anklicken. Dort kann der Administrator sie dann unter anderem deaktivieren sowie die IPv4- und IPv6-Adressen einrichten (Abbildung 5).
Die Einstellungen erklären sich allesamt von selbst, die möglichen Aktionen sind zudem stark limitiert. So dürfen Administratoren beispielsweise weder die Benutzergruppen einsehen noch Benutzerkonten gezielt Gruppen zuweisen. Inkonsequenterweise kann der Admin in solchen Fällen jedoch auf das Terminal ausweichen. Alle dort unternommenen Wartungsarbeiten schlagen sich umgehend in Cockpit nieder. Ein per »adduser« angelegtes Benutzerkonto taucht kurz danach hinter dem Eintrag »User Accounts« auf (Abbildung 6).
Will er den Server herunterfahren oder neu starten, ruft der Administrator unter Fedora 21 den Punkt »Hosts« auf, unter einer aktuellen Cockpit-Version hangelt er sich hingegen über das »Dashboard« zum entsprechenden Server durch. In jedem Fall findet er jetzt eine Dropdown-Box vor – bei Fedora 21 auf der rechten Seite, unter aktuellen Cockpit-Versionen neben »Power Options« . Über sie erreicht er die beiden Funktionen.
Rettungsanker
Bei Fedora 21 lässt sich zudem ein »Rescue Terminal« öffnen. Unter aktuellen Cockpit-Versionen muss der Administrator dazu »Tools | Terminal« aufrufen. Cockpit öffnet dann innerhalb seiner eigenen Benutzeroberfläche eine Shell, über die er direkt auf den Server zugreift. Nach seiner Arbeit sollte sich der Administrator mit einem Klick auf einen Eintrag unter seinem Benutzernamen ganz rechts oben abmelden.
Unter der Haube
Cockpit selbst besteht aus mehreren Komponenten (Abbildung 7), die zentrale stellt der von Systemd gestartete Dienst »cockpit-ws« bereit. Das »ws« steht dabei für Webserver. Er liefert die Webanwendung an die Browser aus und steuert die übrigen Tools. Dabei läuft »cockpit-ws« jedoch nicht einfach dauerhaft im Hintergrund mit, vielmehr lauscht Systemd an Port 9090 und aktiviert den Webserver erst bei einem Verbindungsversuch automatisch.
Sobald sich der Administrator anmeldet, startet »cockpit-ws« den Dienst »cockpit-bridge« . Dieser wiederum kommuniziert über die Dbus-Schnittstelle mit Systemd, dem Networkmanager und anderen Systemkomponenten. Eine Ausnahme bilden Docker und Kubernetes, die Cockpit per REST ansteuert.
Während »cockpit-ws« mit Rootrechten arbeitet, läuft die »cockpit-bridge« mit normalen Userrechten. In älteren Cockpit-Versionen kam übrigens anstelle von »cockpit-bridge« der Dienst »cockpitd« zum Einsatz. Das gilt insbesondere auch noch für die Version 0.27, die Fedora 21 beiliegt.
Neben »cockpit-ws« und »cockpit-bridge« gibt es noch einige weitere Hilfsprogramme. So nutzt Cockpit etwa »cockpit-session« und PAM, um den Benutzer zu authentifizieren und eine entsprechende Session zu starten.
Meldet der Admin in der Weboberfläche einen weiteren Server an, nimmt »cockpit-ws« mit diesem per SSH Kontakt auf. Über die gesicherte SSH-Verbindung dirigiert dann »cockpit-ws« die auf dem anderen Server laufende »cockpit-bridge« . Diese Arbeitsweise bedingt aber, dass auf jedem Server nicht nur Cockpit installiert ist, sondern stets ein SSH-Daemon auf Port 22 horcht.
Nach zehn Minuten Inaktivität beendet sich »cockpit-ws« automatisch. Erfolgt anschließend ein erneuter Zugriff auf Port 9090, startet Systemd die Webanwendung erneut. Alternativ können Admins Cockpit auch manuell aufrufen, unter Fedora 21 über »/usr/libexec/cockpit-ws« .
Des Weiteren existiert ein passender Systemd-Dienst namens »cockpit.service« . Über ihn lässt sich Cockpit kontrolliert herunterfahren oder neu starten. Stoppt der Administrator den Dienst, sollte er auch den Socket schließen, andernfalls würde Systemd bei einem (versehentlichen) Verbindungsaufbau automatisch Cockpit wieder hochfahren:
systemctl stop cockpit.socket cockpit
Wer tiefer in den Aufbau von Cockpit einsteigen und etwa die Benutzeroberfläche um weitere Funktionen ergänzen möchte, sollte sich den Developer Guide vornehmen [6]. Eine aktualisierte Version liegt dem Quellcode im Unterverzeichnis »doc« bei [4].
Fazit
Mit Cockpit verwalten Administratoren kinderleicht einen oder mehrere Server. Wer mit den Systemeinstellungen von Gnome umgehen kann, findet sich auch in Cockpit zurecht. Im Gegensatz zum Konkurrenten Webmin konzentriert sich Cockpit jedoch auf Linux-Systeme. Zusätzliche Anwendungen, etwa einen Apache-Webserver, muss der Administrator weiterhin per Hand einrichten.
Zudem ist Cockpit derzeit stark auf Fedora und insbesondere Systemd zugeschnitten. Wer es nutzen möchte, sollte sich folglich mit dem Initsystem und dessen Konzepten zumindest oberflächlich auskennen. Durch die Konzentration auf wenige Systemkomponenten kann Cockpit jedoch auch zuverlässiger arbeiten und vor allem mit einer konsistenten, aufgeräumten Benutzeroberfläche glänzen. Wie jede Webanwendung öffnet Cockpit allerdings einen neuen Port auf dem Server, was prinzipiell ein Sicherheitsrisiko darstellt.
Dringend aktualisieren und erweitern sollten die Entwickler auf jeden Fall die Dokumentation: Zum Redaktionsschluss bestand diese gerade mal aus einer lückenhaften Referenz und drei kargen Manpages.
Infos
- Cockpit: http://cockpit-project.org
- Webmin: http://www.webmin.com
- Open IT Cockpit: http://www.open-itcockpit.com
- Cockpit auf Github: https://github.com/cockpit-project/cockpit
- Cockpit-Download: https://github.com/cockpit-project/cockpit/releases
- Cockpit Developer Guide: http://files.cockpit-project.org/guide/













