Cockpit auf Ubuntu Server installieren – der Server im Browser

Mit Cockpit verwaltest du deinen Ubuntu-Server bequem über den Browser – ohne dass du dafür auf die Kommandozeile verzichten musst.

In der Serie zum eigenen Linux-Webserver haben wir alles über die Kommandozeile erledigt: Ubuntu installiert, Apache eingerichtet, MariaDB konfiguriert, mehrere PHP-Versionen parallel betrieben und zum Schluss die Firewall abgesichert. Das funktioniert bestens – aber es gibt Situationen, in denen ein Blick in eine grafische Oberfläche einfach schneller geht. Zum Beispiel wenn du wissen willst, warum ein Dienst nicht startet, wie voll die Festplatte gerade ist oder was in den letzten Stunden an Fehlern im Systemprotokoll gelandet ist.

Genau dafür gibt es Cockpit. In diesem Beitrag richten wir Cockpit auf einem Ubuntu-Server ein, schauen uns die wichtigsten Bereiche an – und ich zeige dir auch die zwei Stellen, an denen Cockpit unter Ubuntu nicht so funktioniert, wie man es erwarten würde. Die verschweigen die meisten Anleitungen nämlich.

Als Beispielsystem dient der Server aus der Serie mit Ubuntu 24.04 LTS. Unter 22.04 LTS und 26.04 LTS funktioniert alles genauso – dort muss lediglich der Versions-Codename in den apt-Befehlen angepasst werden, worauf ich an der entsprechenden Stelle hinweise.

Dieser Beitrag knüpft an Teil 1 – Installation Ubuntu 24.04 LTS Server an.

Was Cockpit ist – und was nicht

Cockpit ist eine Weboberfläche zur Serververwaltung, die vom Red-Hat-Umfeld entwickelt wird. Du rufst sie im Browser auf und siehst dort den Zustand deines Servers: Auslastung, Speicherplatz, laufende Dienste, Benutzerkonten, Systemprotokolle.

Der entscheidende Unterschied zu klassischen Verwaltungsoberflächen wie Webmin oder Plesk ist die Art, wie Cockpit arbeitet: Cockpit pflegt keine eigene Konfigurationsdatenbank. Es liest und schreibt direkt die Bordmittel des Systems – systemd für die Dienste, journald für die Protokolle, die normalen Benutzerkonten des Betriebssystems.

Warum das wichtig ist: Du kannst dich jederzeit weiterhin per SSH anmelden und Dateien von Hand bearbeiten, ohne dass Cockpit dir dazwischenfunkt oder deine Änderungen beim nächsten Aufruf überschreibt. Cockpit ist eine zusätzliche Sicht auf den Server, kein zweiter Verwalter, der eigene Vorstellungen hat.

Umgekehrt heißt das aber auch: Cockpit ersetzt die Kommandozeile nicht. Einen Apache-VirtualHost oder eine php.ini wirst du dort nicht konfigurieren. Cockpit ist gut im Beobachten und im schnellen Eingreifen – nicht im Einrichten.

Voraussetzungen

Du brauchst einen laufenden Ubuntu-Server mit SSH-Zugang und einem Benutzer, der sudo verwenden darf. Wenn du der Serie gefolgt bist, ist das genau der Server aus Teil 1 – in den Beispielen dieses Beitrags heißt er demosrv und hat im lokalen Netzwerk die feste IP-Adresse 192.168.0.55. Passe beides einfach an deine eigene Umgebung an.

Falls du eine Firewall betreibst – etwa UFW aus Teil 6 der Serie – brauchen wir die später noch, um den Zugriff auf Cockpit freizugeben.

Vor der Installation

Cockpit liegt bei Ubuntu im universe-Repository und lässt sich ganz normal per apt installieren. Zuerst aktualisieren wir die Paketlisten:

sudo apt update

sudo apt update

Bevor wir den Installationsbefehl absetzen, klären wir aber zwei Punkte – beides Dinge, die man besser vorher weiß als hinterher.

Welche Pakete installiert werden

cockpit selbst ist nur eine Art Sammelpaket. Es zieht drei Bestandteile zwingend mit:

Dazu kommen drei weitere Pakete, die als „empfohlen“ eingetragen sind. Empfohlene Pakete installiert apt standardmäßig ebenfalls gleich mit:

Die ersten beiden sind unproblematisch. Beim dritten kommt es darauf an, welche Ubuntu-Variante du einsetzt, denn cockpit-networkmanager setzt zwingend das Paket network-manager voraus.

Auf Ubuntu Desktop ist das unkritisch: Dort verwaltet NetworkManager das Netzwerk ohnehin, und die Netzwerk-Seite in Cockpit funktioniert wie vorgesehen.

Auf Ubuntu Server läuft das Netzwerk dagegen über netplan mit systemd-networkd. Hier würdest du dir mit dem Modul einen zweiten Netzwerk-Verwaltungsdienst einhandeln. Genau daraus entstehen die beiden Probleme, die weiter unten im Abschnitt „Zwei Stolpersteine“ beschrieben sind.

Wichtiger Hinweis, bevor wir weitermachen: Auf einem Server ist es deshalb die ruhigere Variante, die Netzwerk-Seite gar nicht erst zu installieren. Dann bekommst du zwar keine Netzwerk-Übersicht in Cockpit – aber die brauchst du auf einem Server mit fester IP-Adresse ohnehin nur selten.

Standard-Paketquellen oder Backports?

Eine zweite Vorüberlegung, dann installieren wir. Die Cockpit-Version, die Ubuntu mitliefert, ist bei einer LTS-Version nicht die neueste:

Das ist so gewollt: Ubuntu friert die Versionsstände zum Release ein und liefert danach nur noch Sicherheitsupdates. Dadurch bleibt ein LTS-System über Jahre berechenbar. Bei einem Programm wie Cockpit, das sich schnell weiterentwickelt, bedeutet es aber, dass du unter 24.04 mit einer rund zwei Jahre alten Fassung arbeitest – ohne einige Funktionen, die inzwischen dazugekommen sind.

Deshalb bietet Ubuntu für solche Fälle die Backports an: neuere Versionen, für die aktuelle LTS-Version nachgebaut. Diese Paketquelle ist bei Ubuntu bereits aktiviert, du musst nichts einrichten. Sie wird allerdings nie von selbst verwendet – du musst sie bei jedem Befehl ausdrücklich anfordern. Das Cockpit-Projekt selbst empfiehlt die Backports-Version, und wir folgen dieser Empfehlung in diesem Beitrag.

Cockpit unter Ubuntu installieren

Jetzt haben wir alles beisammen. Je nachdem, ob du Ubuntu Server oder Ubuntu Desktop einsetzt, unterscheidet sich der Befehl etwas.

Auf einem Ubuntu Server

Hier lassen wir die Netzwerk-Seite bewusst weg und geben die gewünschten Module ausdrücklich an. Der Befehl sieht auf den ersten Blick sperrig aus, wird darunter aber Stück für Stück erklärt:

sudo apt install -t noble-backports --no-install-recommends cockpit cockpit-storaged cockpit-packagekit cockpit-files pcp

sudo apt install -t noble-backports --no-install-recommends cockpit cockpit-storaged cockpit-packagekit cockpit-files pcp

Wichtig, wenn du eine andere Ubuntu-Version einsetzt: In noble-backports steckt der Codename der Ubuntu-Version. noble steht für 24.04, das wir hier verwenden. Nutzt du eine andere Version, ersetze ihn:

Das gilt für alle Befehle in diesem Beitrag, in denen noble-backports vorkommt. Ansonsten bleiben sie unverändert. Welchen Codenamen dein System hat, verrät dir:

lsb_release -c

lsb_release -c

Wenn du die Netzwerk-Seite auf dem Server trotzdem haben möchtest, lässt du --no-install-recommends einfach weg. Lies in dem Fall aber unbedingt den Abschnitt „Zwei Stolpersteine“ weiter unten.

Auf einem Ubuntu Desktop

Auf dem Desktop kannst du es dir einfacher machen. Weil NetworkManager dort ohnehin das Netzwerk verwaltet, spricht nichts gegen die Standardinstallation – die empfohlenen Module dürfen also ganz normal mitkommen:

sudo apt install -t noble-backports cockpit cockpit-files pcp

sudo apt install -t noble-backports cockpit cockpit-files pcp

Die Pakete cockpit-storaged, cockpit-packagekit und cockpit-networkmanager installiert apt hier automatisch als empfohlene Pakete mit. Der Abschnitt „Zwei Stolpersteine“ betrifft dich damit nicht.

Was die Backports-Installation bedeutet

Die folgenden zwei Punkte gelten für beide Varianten, Server wie Desktop.

Alle Cockpit-Pakete landen damit auf demselben, neueren Versionsstand – unter 24.04 also auf 362 statt 314. Welche Version bei dir installiert ist, kannst du dir jederzeit anzeigen lassen:

apt list --installed 'cockpit*'

apt list --installed 'cockpit*'

Ein Punkt für später: Ein normales sudo apt upgrade aktualisiert Cockpit nicht mehr mit, weil apt Backports nie von sich aus heranzieht. Zum Aktualisieren nimmst du einfach denselben Befehl wie bei der Installation noch einmal:

sudo apt install -t noble-backports cockpit

sudo apt install -t noble-backports cockpit

Cockpit starten

Nach der Installation läuft Cockpit in der Regel schon. Prüfen können wir das so:

sudo systemctl status cockpit.socket

sudo systemctl status cockpit.socket

Dir fällt vielleicht auf, dass hier cockpit.socket steht und nicht cockpit.service, wie du es von Apache oder MariaDB kennst. Das hat einen Grund: Cockpit läuft nicht dauerhaft als Hintergrunddienst. Stattdessen horcht systemd selbst auf dem Netzwerk-Port und startet den eigentlichen Cockpit-Dienst erst dann, wenn tatsächlich jemand die Weboberfläche aufruft.

Das nennt sich Socket-Aktivierung und ist der Grund, warum Cockpit im Leerlauf praktisch keine Ressourcen verbraucht. Für einen kleinen lokalen Server ist das ein echter Vorteil.

Falls der Socket noch nicht aktiv sein sollte, aktivierst du ihn – und sorgst gleichzeitig dafür, dass er auch nach einem Neustart wieder da ist:

sudo systemctl enable --now cockpit.socket

sudo systemctl enable --now cockpit.socket

Firewall-Freigabe einrichten

Cockpit ist über Port 9090 erreichbar. Wenn du UFW aus Teil 6 – Einrichtung der Firewall aktiv hast, blockiert die Firewall diesen Port bislang – wir müssen ihn also freigeben:

sudo ufw allow 9090/tcp

sudo ufw allow 9090/tcp

Da unser Server ausschließlich im lokalen Netzwerk steht und im Router keine Portweiterleitung auf ihn zeigt, ist damit alles Nötige getan. Von außen ist der Port ohnehin nicht erreichbar.

Falls du die IP-Adresse deines Servers gerade nicht zur Hand hast:

hostname -I

hostname -I

Anschließend kontrollieren wir, ob die Regel angekommen ist:

sudo ufw status numbered

sudo ufw status numbered

Der erste Aufruf im Browser

Jetzt rufst du Cockpit im Browser auf. Ersetze die IP-Adresse durch die deines Servers – in unserem Beispiel hat demosrv die Adresse 192.168.0.55:

https://192.168.0.55:9090

https://192.168.0.55:9090

Achte auf das https am Anfang – Cockpit ist ausschließlich verschlüsselt erreichbar.

An dieser Stelle wird dein Browser eine Sicherheitswarnung anzeigen. Das ist kein Fehler und kein Grund zur Sorge: Cockpit erzeugt bei der Installation automatisch ein selbstsigniertes Zertifikat. Die Verbindung ist damit verschlüsselt, aber es gibt keine offizielle Stelle, die bestätigt, dass der Server auch wirklich der ist, für den er sich ausgibt. Bei einem Server im eigenen Netzwerk, dessen IP-Adresse du selbst eingetippt hast, kannst du die Warnung bedenkenlos bestätigen.

Danach kommt der Anmeldebildschirm. Hier meldest du dich mit deinem normalen Benutzerkonto vom Server an – dasselbe, mit dem du dich auch per SSH anmeldest. Cockpit verwaltet keine eigenen Benutzer.

Nach der Anmeldung siehst du oben links den Schalter „Administrativen Zugriff aktivieren“ (englisch: „Turn on administrative access“). Standardmäßig arbeitest du in Cockpit nämlich mit ganz normalen Benutzerrechten und kannst nur lesen. Erst wenn du auf diesen Schalter klickst und dein Passwort erneut eingibst, bekommst du Schreibrechte – das ist praktisch dasselbe wie ein sudo auf der Kommandozeile.

Ein Rundgang durch die Oberfläche

Links findest du die Navigation. Die wichtigsten Bereiche im Überblick:

Das Terminal ist übrigens keine Notlösung, sondern eine echte Shell mit deiner normalen Benutzerumgebung. Wenn du gerade sowieso in Cockpit bist, sparst du dir damit den Umweg über einen separaten SSH-Client.

Zwei Stolpersteine unter Ubuntu

Cockpit stammt aus dem Red-Hat-Umfeld, und an zwei Stellen merkt man das auf einem Ubuntu Server deutlich. Auf Ubuntu Desktop treten beide Probleme nicht auf. Beide setzen voraus, dass cockpit-networkmanager installiert ist. Wenn du oben die empfohlene Server-Variante mit --no-install-recommends genommen hast, betreffen sie dich also nicht – lies sie trotzdem, damit du sie einordnen kannst, falls du das Modul später doch nachrüstest.

Die Netzwerk-Seite kennt netplan nicht

Ubuntu Server konfiguriert das Netzwerk über netplan mit systemd-networkd als Renderer. Cockpit erwartet dagegen NetworkManager. Beide Systeme wissen nichts voneinander. Auf Ubuntu Desktop ist das anders – dort ist NetworkManager der Renderer, weshalb die Netzwerk-Seite in Cockpit dort problemlos funktioniert.

Das bedeutet: Was du auf der Netzwerk-Seite in Cockpit siehst, muss nicht dem entsprechen, was tatsächlich in /etc/netplan/ konfiguriert ist. Und schlimmer noch – wenn du dort eine IP-Adresse änderst, landet diese Änderung nicht in der netplan-Konfiguration. Spätestens nach dem nächsten Neustart ist sie wieder weg. Im ungünstigsten Fall ist der Server dann gar nicht mehr erreichbar.

Wichtiger Hinweis: Ändere die Netzwerkkonfiguration eines laufenden Servers nicht über Cockpit. Bleib bei netplan auf der Kommandozeile. Die Netzwerk-Seite in Cockpit taugt allenfalls zum Draufschauen – und selbst dabei solltest du ihr nicht blind vertrauen.

Es gibt zwar Anleitungen, die empfehlen, netplan auf NetworkManager als Renderer umzustellen. Auf einem Server, der bereits läuft und den du nur über das Netzwerk erreichst, würde ich davon abraten. Der mögliche Gewinn – eine Netzwerk-Seite, die du auf einem Server mit fester IP praktisch nie brauchst – steht in keinem Verhältnis zum Risiko, dich auszusperren.

Software-Updates melden „offline“

Der zweite Punkt hängt direkt mit dem ersten zusammen. Die Seite „Software-Updates“ nutzt im Hintergrund PackageKit, und PackageKit fragt bei NetworkManager nach, ob überhaupt eine Netzwerkverbindung besteht. Da die Netzwerkschnittstellen unter Ubuntu aber von systemd-networkd verwaltet werden, weiß NetworkManager nichts von ihnen und meldet: offline.

Das Ergebnis ist eine Fehlermeldung wie „packagekit cannot refresh cache whilst offline“ – obwohl der Server selbstverständlich online ist.

Das Cockpit-Projekt beschreibt dieses Problem in der eigenen FAQ und sagt dort ausdrücklich, dass es sich nicht auf Cockpit-Seite lösen lässt: Der Fehler entsteht weiter unten im Zusammenspiel von netplan, systemd-networkd, NetworkManager und PackageKit. Es gibt Workarounds mit einer Dummy-Netzwerkschnittstelle, aber das ist Bastelei.

Mein pragmatischer Rat: Updates weiterhin auf der Kommandozeile einspielen. Der Befehl ist ohnehin kurz genug:

sudo apt update && sudo apt upgrade

sudo apt update && sudo apt upgrade

Nützliche Zusatzmodule

Cockpit lässt sich um weitere Seiten erweitern. Denk dabei an den -t-Schalter, damit die Module zu deiner Backports-Installation passen:

sudo apt install -t noble-backports cockpit-podman

sudo apt install -t noble-backports cockpit-podman

Eine Auswahl:

Beide Container- und Virtualisierungsmodule sind nur sinnvoll, wenn du Podman beziehungsweise KVM auch tatsächlich einsetzt – sie bringen jeweils die komplette Laufzeitumgebung mit.

Welche Module deine Ubuntu-Version anbietet, zeigt dir übrigens:

apt search ^cockpit-

apt search ^cockpit-

Ein kleiner Lesetipp dazu, der auch außerhalb von Cockpit nützlich ist: Hinter dem Paketnamen steht nach einem Schrägstrich die Paketquelle. cockpit-podman/noble kommt aus dem Standard-Repository von Ubuntu 24.04, cockpit-files/noble-backports aus den Backports.

Sollte eine Modulinstallation einmal mit einer Meldung über „unerfüllte Abhängigkeiten“ abbrechen, hast du mit ziemlicher Sicherheit den -t-Schalter vergessen. Setz ihn davor und der Befehl läuft durch.

Neu installierte Module erscheinen übrigens erst nach einem Neuladen der Seite im Browser.

Was schon dabei ist

Zwei Seiten, nach denen häufig gefragt wird, musst du gar nicht nachrüsten – sie sind mit dem Installationsbefehl von oben bereits abgedeckt.

Die Speicher-Seite

Die Speicher-Seite brauchst du nicht extra zu installieren – wir haben cockpit-storaged oben im Installationsbefehl ausdrücklich mit angegeben.

Verlaufsgrafiken auf der Metrik-Seite

Performance Co-Pilot haben wir oben schon mitinstalliert. Er zeichnet die Systemauslastung fortlaufend auf, sodass die Metrik-Seite nicht nur den Momentanwert zeigt, sondern auch, wie es gestern Abend um 23 Uhr aussah. Ein eigenes Cockpit-Modul braucht es dafür nicht mehr – seit Version 317 steckt die Unterstützung fest in cockpit-bridge.

Falls die Verlaufsgrafiken bei dir nicht erscheinen, prüfe, ob der Aufzeichnungsdienst läuft:

sudo systemctl status pmlogger

sudo systemctl status pmlogger

Cockpit im Alltag

Der eigentliche Nutzen zeigt sich beim Fehlersuchen. Ein typisches Beispiel: Eine Website antwortet nicht mehr.

Statt dich per SSH anzumelden und systemctl status apache2 einzutippen, öffnest du in Cockpit die Seite Dienste und filterst nach apache2. Du siehst dort auf einen Blick, ob der Dienst läuft, seit wann, und – wenn er abgestürzt ist – die letzten Zeilen aus dem Protokoll direkt darunter. Über die Schaltflächen kannst du ihn sofort neu starten.

Dasselbe funktioniert für die anderen Bestandteile aus der Serie:

Wenn du wie in Teil 4 – Mehrere PHP-Versionen parallel mehrere PHP-Versionen parallel betreibst, siehst du hier alle FPM-Dienste nebeneinander und erkennst sofort, welche laufen und welche nicht.

Der zweite Alltagsnutzen ist die Protokoll-Seite. Ein Fehler von vorgestern um 23 Uhr ist dort in ein paar Klicks gefunden – über journalctl bräuchtest du dafür Zeitfilter, die man sich selten merkt.

Cockpit absichern

Zum Schluss noch der wichtigste Punkt. Cockpit gibt jedem, der sich anmeldet, faktisch vollen Zugriff auf den Server – inklusive einer Shell. Eine über das Internet erreichbare Cockpit-Instanz ist damit ein sehr attraktives Ziel.

Für unseren Server ist das unkritisch: Er steht ausschließlich im lokalen Netzwerk, und im Router zeigt keine Portweiterleitung auf ihn. Solange das so bleibt, ist die Freigabe von Port 9090 in der Firewall völlig ausreichend – von außen ist der Port gar nicht erst erreichbar.

Zwei Dinge solltest du trotzdem im Hinterkopf behalten:

• Richte im Router keine Portweiterleitung auf Port 9090 ein. Wer Cockpit aus dem Internet erreichbar machen möchte, braucht dafür eine ganz andere Absicherung – etwa einen VPN-Zugang oder einen Reverse Proxy mit echtem Zertifikat.
• Verwende starke Passwörter für alle Benutzerkonten, die sich an Cockpit anmelden dürfen. Ein schwaches Passwort auf einem Serverkonto wiegt mit Cockpit deutlich schwerer als vorher.

Und falls du Cockpit später doch nicht mehr brauchst, deaktivierst du es einfach wieder:

sudo systemctl disable --now cockpit.socket

sudo systemctl disable --now cockpit.socket

Abschluss Cockpit

Damit hast du Cockpit auf deinem Ubuntu-Server eingerichtet, den Zugriff in der Firewall freigegeben und weißt, welche Bereiche der Oberfläche unter Ubuntu Server zuverlässig funktionieren – und welche beiden du besser meidest.

Mein Fazit nach längerer Nutzung: Cockpit ist ein sehr gutes Beobachtungswerkzeug und eine bequeme Fernbedienung für Dienste. Zum Einrichten und Konfigurieren bleibt die Kommandozeile das bessere Werkzeug. Genau so ist Cockpit aber auch gedacht – und mit dieser Erwartung wirst du viel Freude daran haben.