- Cockpit ist eine grafische Oberfläche zur Verwaltung von Linux-Servern im Browser, mit der Einsteiger und professionelle Administratoren den Zustand einzelner Systeme schnell prüfen und steuern können
- Da es dieselben System-APIs und Befehle wie die Kommandozeile nutzt, geraten Verwaltungsabläufe nicht in Konflikt, auch wenn Cockpit, CLI, Ansible und bestehende Server-Management-Tools gemeinsam verwendet werden
- Netzwerk, Firewall, RAID-/LUKS-Storage, virtuelle Maschinen, Container, Logs, Hardware, Updates, Performance, Benutzerkonten, systemd-Services und ein Remote-Terminal lassen sich auf einer Oberfläche verwalten
- Die Standardauthentifizierung folgt den normalen Benutzer-Logins und Berechtigungen des Systems; Single-Sign-on und andere Authentifizierungsverfahren werden ebenfalls unterstützt, und Cockpit wird per systemd socket activation nur bei Bedarf gestartet
- Nach der Installation auf gängigen Linux-Distributionen kann man über einen Browser auf Betriebssystemen einschließlich Windows, MacOS und Android über Port 9090 des Servers darauf zugreifen
Verwaltung einzelner Server im Browser
- Cockpit ist eine integrierte webbasierte grafische Oberfläche für Server
- Die Zielgruppe ist breit gefächert
- Linux-Einsteiger, einschließlich Windows-Administratoren
- Nutzer, die mit Linux vertraut sind, Server aber einfacher grafisch verwalten möchten
- professionelle Administratoren, die hauptsächlich andere Tools verwenden, aber einen Überblick über einzelne Systeme erhalten wollen
- Es ist nicht als Ersatz für bestehende Verwaltungsweisen gedacht, sondern so konzipiert, dass dasselbe System auf mehrere Arten verwaltet werden kann
- Cockpit kann zusammen mit Kommandozeilen-Utilities verwendet werden
- Ansible und andere bestehende Tools können weiterhin genutzt werden
- Es bietet ein integriertes Terminal, das beim Zugriff von Nicht-Linux-Geräten nützlich ist
- Auch ohne Linux-Befehle auswendig zu kennen, kann man den Serverstatus im Webbrowser einsehen und Aufgaben per Maus erledigen
- Container starten
- Storage verwalten
- Netzwerkeinstellungen konfigurieren
- Logs prüfen
- Cockpit lässt sich als grafische „Desktop-Oberfläche“ für einzelne Server betrachten
Authentifizierung, Integration und Erweiterbarkeit
- Cockpit nutzt bereits im System vorhandene APIs und erstellt keine neuen Subsysteme und keine eigene Tool-Schicht
- Standardmäßig verwendet es die normalen Benutzer-Logins und Berechtigungen des Systems
- Netzwerkweites Login wird über Single-Sign-on und andere Authentifizierungs-Verfahren unterstützt
- Wenn es nicht verwendet wird, läuft es nicht dauerhaft im Hintergrund, sondern wird per systemd socket activation bei Bedarf gestartet
- Auf jedem Cockpit-Host lassen sich unter anderem folgende Aufgaben ausführen
- Netzwerkeinstellungen prüfen und ändern
- Firewall konfigurieren
- Storage einschließlich RAID- und LUKS-Partitionen verwalten
- virtuelle Maschinen erstellen und verwalten
- Container herunterladen und ausführen
- System-Logs durchsuchen und filtern
- Systemhardware prüfen
- Software-Upgrades durchführen
- Performance überprüfen
- Benutzerkonten verwalten
- systemd-basierte Services prüfen und mit ihnen interagieren
- ein Terminal eines entfernten Servers im lokalen Webbrowser nutzen
- zwischen mehreren Cockpit-Servern wechseln
- den Funktionsumfang durch Installation von Apps und Add-ons erweitern
- benutzerdefinierte Module schreiben
- Es kann auch zur Fehlerbehebung genutzt werden
- Netzwerkprobleme diagnostizieren
- fehlerhaft arbeitende virtuelle Maschinen erkennen und darauf reagieren
- SELinux-Logs prüfen und gängige Verstöße mit einem Klick beheben
- detaillierte Metriken zu CPU-Last, Speichernutzung, Netzwerkaktivität und Storage-Performance im Zusammenhang mit dem System-Journal ansehen
- Optionale und Drittanbieter-Anwendungen werden unterstützt
- Das Design wird durch Usability-Studien getestet und angepasst, und jede Codeänderung durchläuft Tests, die vor dem Merge bestanden werden müssen
- Cockpit ist kostenlos nutzbar und wird unter der GNU LGPL bereitgestellt
Installation und Zugriff
- Cockpit lässt sich auf den wichtigsten Distributionen installieren und nach dem Start von den gängigen Webbrowsern beliebiger Betriebssysteme aus aufrufen
- einschließlich Windows, MacOS und Android
- Nach Installation und Aktivierung greift man auf Port 9090 des Servers zu
- Im Browser derselben Maschine ist der Zugriff über
https://localhost:9090/möglich
- Cockpit hat einen zeitbasierten Release-Zyklus; neue Versionen erscheinen alle zwei Wochen
2 Kommentare
Cockpit - integrierte Weboberfläche zur Verwaltung von Linux-Servern
Meinungen auf Hacker News
Grafische Verwaltungsoberflächen zu verteufeln und ausschließlich die Kommandozeile zu bevorzugen, ist eher eine Haltung, bei der man den Wald vor lauter Bäumen nicht sieht
Einen Server per Klicks zu betreiben, ist keine gute Methode, aber ehrlich gesagt gilt das für
sshals Betriebsweise genausoDer Zustand eines echten Produktionsservers sollte von Anfang an reproduzierbar sein, und nach OS-Installation, Hinzufügen von Software und Anwenden der Konfiguration sollte man ihn möglichst nicht mehr anfassen
Ob
sshoder Cockpit: Wenn man direkt hineingeht, ist die Wahrscheinlichkeit groß, etwas kaputtzumachenDirekt auf den Server gehen sollte man nur für explorative Arbeiten, und dann ist die Überlegenheit von GUI oder Kommandozeile nicht so eindeutig
Eine GUI hat eine gute Auffindbarkeit und Sichtbarkeit und hilft daher in der Experimentierphase, in der man herausfindet, wie etwas konfiguriert wird
Man muss erklären, warum der Serverzustand von Anfang an reproduzierbar sein muss, was „von Anfang an“ bedeutet und warum Klickbetrieb nicht funktionieren soll
Es ist auch schwer zu behaupten, dass der Serverzustand allein durch OS-Installation, Hinzufügen von Software und Anwenden von Konfiguration vollständig erfasst ist
Patchstand der Software, Anwendungsdaten und Nutzerdaten gehören ebenfalls zum Serverzustand
Den Zustand eines Produktionsservers kann man durch Wiederherstellung aus einem Backup exakt reproduzieren, und Backup/Restore passt auch gut zum Klickbetrieb; es kann schneller und zuverlässiger sein als OS-Neuinstallation plus Konfigurationsskripte
Wenn ein Server nichtflüchtige Daten speichert, braucht man nach dem Deployment eines neuen Servers ohnehin ein Backup-System, um die Nutzerdaten wiederherzustellen
Nicht jeder betreibt eine große Webplattform auf einer Orchestrierungsplattform
Allerdings sollte man auch bei Haustier-Servern wissen, wie man sie wiederherstellt oder neu aufbaut; andernfalls hat man keine ordentliche Disaster-Recovery-Strategie
In meinem Homelab nutze ich Ansible für die Konfiguration von Raspberry Pis; der OS-Installationsanteil scheint machbar zu sein, weil dabei ein Image bitweise auf ein Bootmedium kopiert und einige optionale Einstellungen vorgenommen werden
Ich bevorzuge Terminalarbeit, aber dass eine GUI für Visualisierung besser ist, halte ich nicht einmal für umstritten
Das Tolle an diesem Projekt ist, dass es systemd Socket Activation nutzt und deshalb kein dauerhaft laufender Serverprozess nötig ist
Wenn man Cockpit nicht verwendet, werden keine Ressourcen verschwendet, und der Seitenzugriff ist im Grunde dasselbe, als würde man ein Kommandozeilentool starten und wieder beenden
Das Design ist wirklich schön
inetdim Jahr 1986 ähnliche Ansätze gabDie Detailimplementierung war anders, aber die große Idee dieselbe; eine Zeit lang war sie beliebt, kam dann aber ohne besonderen Grund aus der Mode
Ein guter Serverprozess sollte im Leerlauf sein, wenn nichts passiert, und nur sehr wenig tatsächlichen Speicher belegen, sodass er leicht ausgelagert werden kann
Wenn ein bestimmter Server seinem Zweck nach viel Speicher verwendet, will man wahrscheinlich auch nicht durch On-Demand-Starts gelegentlichen Speicherdruck erzeugen
Allerdings hilft es der Boot-Performance, weil man leichter vermeidet, beim frühen Booten auf den Start von Diensten warten zu müssen
Der
sshd-Prozess wird erst gestartet, wenn sich jemand per SSH verbindethttps://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
Je mehr man hineinschaut, desto mehr coole und nützliche Funktionen tauchen auf
Es ist gut, es auf kleinen Raspberry Pis installiert zu haben
Es ist sehr nützlich, wenn man nicht vor dem Terminal sitzt und kurz den Status überfliegen will oder in einer Situation mit nur einem Webbrowser über den Webserver praktisch nativ per SSH zugreifen und am echten Kommando-Prompt
curl ...etc...ausführen kannIch frage mich, ob systemd Socket Activation nur dann verwendet wird, wenn der Webclient des Endnutzers REST/GQL-Anfragen wie Log-Abfragen sendet
„Porcelain“ hat Wert
Ich habe Startups gesehen, die trotz vorhandener Standard-Backends eingegangen sind, weil sie die Produktentwicklung nicht bis zu UI/UX vorangetrieben haben
In einem Unternehmen habe ich gezeigt, dass man ein Backend aus einem vollständig maßgeschneiderten Container-Orchestrator innerhalb eines Wochenendes durch AWS Lambda und ECS ersetzen konnte, aber UI/UX und Workflow-Tools hätten viel länger gedauert
Trotzdem verschwendeten sie weiter Geld und Zeit darauf, einen „neuen Raft-basierten Cluster“ zu bauen
Währenddessen bekam ich die Aufgabe, „Batch Processing hinzuzufügen“, und weil bereits Go im Einsatz war, hängte ich intern Nomad dran und beließ es dabei
Es ist gut, in einem Team zu arbeiten, das nicht nur Technologie um der Technologie willen betreibt, sondern Features ausliefert
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
Jedes Tool in diesem Bereich sollte ein riesiges Banner mit „Zu wenig Speicherplatz auf der Festplatte“ haben
Selbst für Leute, die Server debuggen, ist das überraschend oft keine Selbstverständlichkeit
2022, 81 Kommentare: https://news.ycombinator.com/item?id=31439811
2021, 128 Kommentare: https://news.ycombinator.com/item?id=26197510
2018, 149 Kommentare: https://news.ycombinator.com/item?id=16445612
Ich glaube nicht, dass ich das verwenden würde
Ein offener Port mehr, eine Angriffsfläche mehr für Bots, die unablässig nach Schwachstellen scannen, ein Dienst mehr, den man ständig aktuell halten muss
Allerdings dürfte es helfen, Linux-Server zugänglicher zu machen
Besonders nützlich ist es für Leute, die von PHP-basiertem Shared Hosting auf einen vollwertigen VPS umziehen, aber nicht viel Serverwissen haben und etwas wie cPanel oder DirectAdmin wollen
Den Unterschied zwischen beidem kenne ich nicht genau
Ich bin tatsächlich RHCE, und dieser Thread wirkt so künstlich positiv, dass er sich fast wie eine Clickfarm von Red Hat anfühlt
Cockpit ist okay, aber im Grunde eher die Red-Hat-Version des Windows Server Manager und wurde wahrscheinlich direkt vom Server Manager beeinflusst
Über Jahre hinweg waren Entwicklung und Verbesserungen auch schmerzhaft langsam
Wer mit SSH-Sessions vertraut ist, nutzt Cockpit kaum, außer vielleicht beim Erstellen neuer VMs, und der Vergleich mit Proxmox ergibt keinen Sinn
Es hat nicht einmal ein Viertel der UI-Funktionen von Proxmox, die VM-Verwaltung ist erst vergleichsweise kürzlich dazugekommen, und wegen der Latenz und Einschränkungen über den Browser ist Virtual Machine Manager immer noch besser
Es gibt vieles, was man mit Cockpit nicht tun kann, und vieles, was man auch künftig nicht damit tun können wird
Es ist eher ein Tool für Leute, die klicken wollen, keine Bash-
for-/while-Schleifen schreiben können, Pipe-Chaining nicht verstehen undvimhassenAnders gesagt: Es ist webmin für Red Hat; zwar etwas schicker, aber zu alt, die Entwicklung war langsam, es wird übertrieben gelobt, und ich habe es außer für das Nötige bei Zertifizierungsprüfungen nie genutzt
Also ja, es stimmt auch
Wenn man sich Sorgen über Missbrauch macht, soll man an hn@ycombinator.com schreiben; dort heißt es, man sehe sich die Daten an
https://news.ycombinator.com/newsguidelines.html
Wenn meine Familie verreist, lasse ich mehrere Raspberry-Pi-Kameras mit besseren Kameramodulen laufen, um nach den Haustieren zu sehen
Die RTSP-Kamerastreams laufen jeweils als systemd-Unit auf den Geräten, und Healthchecks, die prüfen, ob Pakete gestreamt werden, sind ebenfalls als separate systemd-Units eingerichtet
Jede Kamera bekommt in einem von mir verwalteten ZeroTier-Netzwerk eine private IP
Cockpit läuft nur bei Bedarf, also gibt es keinen Grund, es nicht für die Verwaltung installiert zu haben
Manchmal beginnt eine Kamera nur noch leere Frames auszugeben; das über die Cockpit-Weboberfläche auf dem Handy zu beheben ist im Urlaub viel besser, als eine Tastatur zu suchen, sich per SSH einzuloggen und die Stream-Unit neu zu starten
Man könnte auch einen Healthcheck bauen, der leere Frames erkennt, aber für etwas, das nur ein paar Mal im Jahr passiert, ist ein Neustart in Cockpit deutlich einfacher, als so etwas zu schreiben
Es ist von praktisch jeder Plattform aus erreichbar, einschließlich iPad, und braucht kaum Einrichtung, im Wesentlichen nur Paketinstallation und Zertifikat hinzufügen
Ich nutze Cockpit statt Proxmox auf Debian-Servern, auf denen VMs laufen, weil es deutlich weniger invasiv ist und diese Maschinen nebenbei auch andere Dinge wie Docker-Container erledigen
Für diesen Zweck nutze ich es seit etwa 2019
Die Statistikansichten sind ebenfalls nützlich, aber allein dafür würde ich es wohl nicht installieren
Es gibt kaum andere gut gepflegte Optionen, mit denen man auf einer einzelnen Maschine per Webbrowser libvirt-VMs erstellen kann, ohne das gesamte System zu übernehmen
Es lässt sich nur mit NetworkManager verwenden, aber sobald die Netzwerkkonfiguration für VMs auch nur etwas komplexer wird, muss man NetworkManager meist deaktivieren, wodurch Cockpit praktisch unbrauchbar wird
Für Leute, die VMs per GUI verwalten wollen, ist virt-manager deutlich leistungsfähiger
[1] https://virt-manager.org/
Die Qualität ist „gerade so okay“
Für eine sehr kleine Auswahl an Einsatzzwecken ist es brauchbar, aber wenn ich einen Homeserver betreiben würde, würde ich es meiden
Das Fileserver-Interface-Plugin von Cockpit ist veraltet und nicht gut
Ich weiß nicht so recht, wofür man es überhaupt verwenden soll; einfaches Monitoring geht vielleicht, aber als Verwaltungstool taugt es wenig
Ich verstehe nicht, warum Red Hat dieses Projekt pusht, und es gibt kaum praktische Anwendungsfälle
Eine Liste von systemd-Diensten anzuzeigen ist nicht hilfreicher, als die komplette Ausgabe auf der Kommandozeile zu sehen
Wenn man ein NAS selbst hostet, halte ich Cockpit für deutlich besser als OMV
OMV hat ein Docker-Plugin mit Compose-Unterstützung, sodass man keine separate Docker-GUI wie Portainer braucht, und SMB-Shares wirken von Windows-Clients aus irgendwie stabiler
Es hat eine einsteigerfreundliche GUI und Herangehensweise, lässt sich daher auch leicht mit anderen Nutzern teilen, und bringt außerdem Funktionen wie fail2ban und WireGuard standardmäßig mit
Cockpit ist auf EL-/Fedora-Distributionen ein First-Class Citizen und unterstützt Podman, aber nicht Docker; auch Compose-/Quadlet-Unterstützung gibt es nicht
Es hat leistungsfähige Funktionen wie VM-Verwaltung und Terminal, aber es gibt Bugs im Zusammenhang mit Samba
Aktuell nutze ich OMV für Dateifreigaben im lokalen Netzwerk und ein paar Docker-Container
Es funktioniert gut, aber 90 % der Funktionen nutze ich nicht
Für alle, die neugierig sind: Laut https://github.com/cockpit-project/cockpit ist Cockpit in mehreren Sprachen geschrieben, wobei C den größten Anteil hat, gefolgt von JavaScript und Python
src/cockpitsieht vermutlich nach der zentralen Backend-Logik aus und ist in Python geschriebenDie neue Bridge ist in Python geschrieben, und wenn die Zeit reif ist, würden wir auch den Webserver gern auf modernere Weise neu schreiben
Wichtig ist auch, welche Abhängigkeiten es gibt und ob man sich etwa um Schwachstellen in Logging-Bibliotheken oder Curl kümmern muss
Es ist auch interessant zu sehen, ob ein Produkt in einem klar definierten Stack geschrieben wurde oder ob mehrere Technologien gemischt wurden