6 points par GN⁺ 2023-10-17 | 2 commentaires | Partager sur WhatsApp
  • Cockpit est une interface graphique permettant de gérer des serveurs Linux depuis un navigateur, afin que les débutants comme les administrateurs expérimentés puissent vérifier rapidement l’état de chaque système et agir dessus
  • Comme il utilise les mêmes API et commandes système que la ligne de commande, Cockpit, la CLI, Ansible et les outils d’administration de serveurs existants peuvent être utilisés ensemble sans conflit dans les flux de gestion
  • Il permet de gérer, depuis un même écran, le réseau, le pare-feu, le stockage RAID·LUKS, les machines virtuelles, les conteneurs, les journaux, le matériel, les mises à jour, les performances, les comptes utilisateurs, les services systemd et un terminal distant
  • L’authentification par défaut suit les identifiants et droits des utilisateurs ordinaires du système ; le single-sign-on et d’autres méthodes d’authentification sont également pris en charge, et Cockpit n’est lancé via systemd socket activation que lorsque c’est nécessaire
  • Après installation sur les principales distributions Linux, il s’utilise depuis le navigateur d’un système d’exploitation, y compris Windows, MacOS et Android, en se connectant au port 9090 du serveur

Administration de serveurs individuels depuis le navigateur

  • Cockpit est une interface graphique web intégrée conçue pour les serveurs
  • Son public cible est large
    • Les débutants sous Linux, y compris les administrateurs Windows
    • Les utilisateurs à l’aise avec Linux, mais qui souhaitent administrer facilement leurs serveurs via une interface graphique
    • Les administrateurs expérimentés qui utilisent principalement d’autres outils, mais veulent consulter la vue d’ensemble d’un système individuel
  • Il est conçu non pas pour remplacer les méthodes d’administration existantes, mais pour permettre de gérer un même système de plusieurs façons
    • Cockpit peut être utilisé avec des utilitaires en ligne de commande
    • Ansible et d’autres outils existants peuvent continuer à être utilisés
    • Il fournit un terminal intégré utile lorsqu’on se connecte depuis un appareil non Linux
  • Sans mémoriser les commandes Linux, on peut consulter l’état d’un serveur dans un navigateur web et effectuer des actions à la souris
    • Démarrer des conteneurs
    • Gérer le stockage
    • Configurer le réseau
    • Vérifier les journaux
  • Cockpit peut être vu comme une « interface de bureau » graphique pour un serveur individuel

Authentification, intégration et extensibilité

  • Cockpit utilise les API déjà présentes sur le système et ne crée pas de nouveau sous-système ni n’ajoute sa propre couche d’outils
  • Par défaut, il utilise les identifiants et droits des utilisateurs ordinaires du système
  • Lorsqu’il n’est pas utilisé, il ne tourne pas en continu en arrière-plan : il est lancé à la demande via systemd socket activation
  • Les actions possibles sur chaque hôte Cockpit incluent :
    • Vérifier et modifier la configuration réseau
    • Configurer le pare-feu
    • Gérer le stockage, y compris les partitions RAID et LUKS
    • Créer et gérer des machines virtuelles
    • Télécharger et exécuter des conteneurs
    • Parcourir et rechercher dans les journaux système
    • Vérifier le matériel du système
    • Mettre à niveau les logiciels
    • Consulter les performances
    • Gérer les comptes utilisateurs
    • Vérifier les services basés sur systemd et interagir avec eux
    • Utiliser le terminal d’un serveur distant depuis un navigateur web local
    • Basculer entre plusieurs serveurs Cockpit
    • Étendre les fonctionnalités en installant des applications et add-ons
    • Écrire des modules personnalisés
  • Il peut aussi servir au dépannage
    • Diagnostiquer des problèmes réseau
    • Détecter une machine virtuelle défaillante et y répondre
    • Consulter les journaux SELinux et corriger les violations courantes en un clic
    • Consulter des métriques détaillées reliant charge CPU, utilisation mémoire, activité réseau et performances du stockage au journal système
  • Il prend en charge les applications optionnelles et tierces
  • Sa conception est testée et ajustée au moyen d’études d’utilisabilité, et chaque modification de code passe par des tests obligatoires avant fusion
  • Il est utilisable gratuitement et fourni sous licence GNU LGPL

Installation et accès

  • Il peut être installé sur les principales distributions et, une fois lancé, est accessible depuis les principaux navigateurs web de n’importe quel système d’exploitation
  • Cockpit suit un cycle de publication calendaire, avec une nouvelle version toutes les 2 semaines

2 commentaires

 
GN⁺ 2023-10-17
Avis de Hacker News
  • Dénigrer les interfaces graphiques d’administration et ne jurer que par la ligne de commande revient plutôt à ne voir que l’arbre qui cache la forêt
    Administrer un serveur à coups de clics n’est pas une bonne méthode, mais honnêtement, ssh n’en est pas vraiment une non plus
    L’état d’un serveur de production réel devrait être reproductible depuis le départ, et il vaut mieux ne plus y toucher après l’installation de l’OS, l’ajout des logiciels et l’application de la configuration
    Que ce soit via ssh ou Cockpit, se connecter directement augmente fortement les chances de casser quelque chose
    On ne devrait entrer directement sur un serveur que pour du travail exploratoire, et dans ce cas la supériorité entre GUI et ligne de commande n’est pas si évidente
    Une GUI offre une meilleure découvrabilité et une meilleure visibilité, ce qui aide pendant la phase d’expérimentation où l’on cherche comment configurer quelque chose

    • Les formules du type « l’exploitation par clics n’est pas une manière d’administrer un serveur » ou « l’état d’un serveur doit être reproductible depuis le départ » sont souvent présentées comme des évidences absolues, alors qu’en pratique il faut des compromis d’ingénierie
      Il faut expliquer pourquoi l’état d’un serveur devrait être reproductible depuis le départ, ce que signifie « depuis le départ », et pourquoi l’exploitation par clics serait exclue
      Il est aussi difficile de considérer que l’installation de l’OS, l’ajout de logiciels et l’application de la configuration capturent entièrement l’état d’un serveur
      Le niveau des correctifs logiciels, les données applicatives et les données utilisateur font aussi partie de l’état du serveur
      L’état d’un serveur de production peut être reproduit exactement en restaurant depuis une sauvegarde, et sauvegarde/restauration s’accorde aussi très bien avec une exploitation par clics, tout en pouvant être plus rapide et plus fiable qu’une réinstallation de l’OS suivie de scripts de configuration
      Pour un serveur qui stocke des données non volatiles, il faut de toute façon un système de sauvegarde afin de restaurer les données utilisateur après le déploiement d’un nouveau serveur
    • Cette hypothèse suppose un environnement où l’on traite les serveurs comme du bétail plutôt que comme des animaux de compagnie
      Tout le monde n’exploite pas de grandes plateformes web au-dessus d’une plateforme d’orchestration
      Cela dit, même avec des serveurs « animaux de compagnie », il faut savoir comment les restaurer ou les reconstruire ; sinon, on n’a tout simplement pas de vraie stratégie de reprise après sinistre
    • Je me demande quels outils sont envisagés pour « reproduire l’état d’un serveur de production depuis le départ »
      Dans mon homelab, j’utilise Ansible pour configurer des Raspberry Pi, et la partie installation de l’OS semble faisable en copiant bit à bit une image sur le support de démarrage puis en appliquant quelques réglages optionnels
    • Avec ce critère, on dirait presque qu’il faudrait n’utiliser que NixOS
    • Les deux sont utiles pour des raisons différentes
      Je préfère travailler dans le terminal, mais il me semble incontestable qu’une GUI est meilleure pour la visualisation
  • Ce qui est génial dans ce projet, c’est qu’il utilise l’activation par socket systemd, ce qui évite d’avoir un processus serveur lancé en permanence
    Quand on n’utilise pas Cockpit, il n’y a pas de gaspillage de ressources, et accéder à la page revient en pratique à lancer un outil en ligne de commande puis à le quitter
    La conception est vraiment élégante

    • Pour être juste, des mécanismes similaires existent depuis 1986 avec inetd de BSD4.3
      Les détails d’implémentation étaient différents, mais la grande idée était la même ; cela a été populaire un temps, puis c’est passé de mode sans raison particulière
      Un bon processus serveur devrait rester inactif quand il ne se passe rien, et son usage mémoire réel devrait être très faible, afin qu’il soit facile à swapper
      Si un serveur donné consomme beaucoup de mémoire par nature, on ne voudra pas non plus provoquer une pression mémoire intermittente en le lançant à la demande
      Cela dit, cela aide les performances au démarrage, car il devient plus facile d’éviter de rester bloqué à attendre le lancement des services pendant le boot initial
    • En cherchant à ce sujet, il semble que SSHD utilise aussi l’activation par socket systemd depuis Ubuntu 22.10
      Le processus sshd ne démarre pas tant que quelqu’un ne se connecte pas en SSH
      https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
    • Ça me donne envie d’en apprendre davantage sur systemd
      Plus je regarde, plus je découvre des fonctionnalités élégantes et utiles
    • Cockpit revient à 99 % à « faire la même chose qu’en ligne de commande », et il est assez excellent : petite GUI de terminal en JavaScript, utilisateurs et mots de passe natifs, historique de monitoring léger, et exploration de paramètres que l’on devait auparavant retrouver en mémorisant des commandes systemd complexes
      C’est une bonne idée de l’installer sur de petits Raspberry Pi
      C’est très pratique pour jeter un œil à l’état quand on n’est pas devant un terminal, ou, dans une situation où l’on n’a qu’un navigateur web, se connecter via le serveur web presque comme en SSH natif et exécuter curl ...etc... dans une vraie invite de commande
    • Malgré tout, j’imagine qu’un processus serveur doit bien être en cours d’exécution pour servir les ressources HTML/JS statiques de la webapp Cockpit
      Je me demande si l’activation par socket systemd signifie qu’elle n’est utilisée que lorsque le client web de l’utilisateur final envoie des requêtes REST/GQL, par exemple pour consulter les journaux
  • Le « porcelain » a de la valeur
    J’ai vu des startups se planter alors qu’elles avaient déjà un backend tout prêt, parce qu’elles n’arrivaient pas à pousser le développement produit jusqu’à l’UI/UX
    Dans une entreprise, j’ai montré qu’on pouvait remplacer en un week-end un backend d’orchestrateur de conteneurs entièrement custom par AWS Lambda et ECS, mais l’UI/UX et les outils de workflow auraient demandé beaucoup plus de temps
    Malgré cela, ils ont continué à gaspiller de l’argent et du temps à fabriquer un « nouveau cluster basé sur Raft »
    Entre-temps, on m’a confié l’ajout du « traitement par lots » ; comme on utilisait déjà Go, j’ai simplement branché Nomad en interne et on est passés à autre chose
    C’est agréable de travailler dans une équipe qui livre des fonctionnalités, et pas seulement de la technologie pour la technologie
    https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

  • Tous les outils de ce domaine devraient afficher une énorme bannière « espace disque insuffisant »
    Même chez les gens qui déboguent des serveurs, ce n’est étonnamment pas toujours un réflexe

    • Je ne sais pas pourquoi, mais j’ai vu la même chose
  • En 2022, 81 commentaires : https://news.ycombinator.com/item?id=31439811
    En 2021, 128 commentaires : https://news.ycombinator.com/item?id=26197510
    En 2018, 149 commentaires : https://news.ycombinator.com/item?id=16445612

    • Quand un projet mûrit et que davantage de gens le découvrent, ce genre de tendance est assez prévisible
  • Je ne pense pas que je l'utiliserais
    Ça fait un port ouvert de plus, une surface d'attaque de plus pour les bots qui scannent sans relâche les vulnérabilités, et un service de plus à maintenir constamment à jour
    Cela dit, je pense que ça peut aider à rendre les serveurs Linux plus accessibles
    C'est particulièrement utile pour les personnes qui quittent un hébergement mutualisé basé sur PHP pour passer à un vrai VPS, mais qui n'ont pas beaucoup de connaissances serveur et veulent quelque chose comme cPanel ou DirectAdmin

    • Il n'est pas nécessaire d'ouvrir un port ; on peut utiliser un VPN ou un tunnel SSH à la place
      Je ne connais pas très bien la différence entre les deux
  • Je suis réellement RHCE, et ce fil a une ambiance positive si artificielle qu'il donne l'impression d'être une ferme à clics côté Red Hat
    Cockpit est correct, mais c'est en pratique assez proche de la version Red Hat de Windows Server Manager, et il a probablement été directement influencé par Server Manager
    Pendant des années, le rythme de développement et d'amélioration a aussi été douloureusement lent
    Quelqu'un qui est à l'aise avec une session SSH n'utilise pas Cockpit, sauf peut-être lors de la création d'une nouvelle VM, et le comparer à Proxmox n'a aucun sens
    Il n'a même pas un quart des fonctionnalités de l'interface de Proxmox, les fonctions de gestion de VM n'y sont arrivées que relativement récemment, et à cause de la latence et des contraintes liées au passage par le navigateur, Virtual Machine Manager reste meilleur
    Il y a beaucoup de choses qu'on ne peut pas faire avec Cockpit, et beaucoup qu'on ne pourra toujours pas faire
    C'est plutôt un outil pour les gens qui veulent cliquer, ne savent pas écrire de boucles Bash for/while, ne comprennent pas l'enchaînement de pipes et détestent vim
    En gros, c'est le webmin de Red Hat ; c'est assez sympa, mais trop ancien, le développement a été lent, il est survendu, et je ne l'ai jamais utilisé en dehors de ce qui était nécessaire pour l'examen de certification

    • C'est un peu comme dire : « les filtres Instagram sont faits pour les gens qui ne savent pas gérer les calques Photoshop, ne comprennent même pas la composition de base des couleurs, et veulent juste swiper »
      Donc oui, c'est aussi vrai
    • Les guidelines de HN disent de ne pas publier d'insinuations du type « astroturfing, comptes de promo, mobilisation de groupe, agents étrangers », car elles dégradent la qualité des discussions et sont généralement fausses
      Si vous craignez un abus, elles indiquent d'envoyer un mail à hn@ycombinator.com, où ils examineront les données
      https://news.ycombinator.com/newsguidelines.html
    • Faut-il toujours être prêt à déployer un émulateur de terminal capable de faire du SSH ? Je ne vois pas le problème à rendre les tâches simples, simples
      Quand ma famille voyage, je fais tourner plusieurs caméras Raspberry Pi équipées de meilleurs modules caméra pour voir les animaux de compagnie
      Les flux caméra RTSP tournent comme des unités systemd sur chaque appareil, et j'ai aussi des healthchecks dans d'autres unités systemd pour vérifier que les paquets sont bien diffusés
      Chaque caméra reçoit une IP privée sur le réseau ZeroTier que je gère
      Cockpit ne s'exécute que quand on en a besoin, donc il n'y a pas de raison de ne pas l'installer pour l'administration
      De temps en temps, une caméra se met à n'envoyer que des images vides, et quand je suis en vacances, c'est bien mieux de régler ça depuis l'interface web Cockpit sur mon téléphone que de trouver un clavier, me connecter en SSH et redémarrer l'unité de streaming
      Je pourrais écrire un healthcheck qui détecte les images vides, mais pour un problème qui n'arrive que quelques fois par an, le redémarrage depuis Cockpit est beaucoup plus simple
    • Cockpit est très utile pour administrer libvirt + KVM à distance sans fouiller dans du XML mal documenté
      Il est accessible depuis n'importe quelle plateforme, y compris un iPad, et ne demande presque aucune configuration : installer le paquet et ajouter un certificat suffit à peu près
      Je l'utilise à la place de Proxmox sur des serveurs Debian qui font tourner des VM, parce qu'il est beaucoup moins intrusif et que ces machines font aussi d'autres choses, comme des conteneurs Docker
      Je l'utilise pour cet usage depuis environ 2019
      Les écrans de statistiques sont aussi utiles, mais je ne l'installerais pas uniquement pour ça
      Il existe très peu d'autres options bien maintenues qui permettent de créer des VM libvirt depuis un navigateur web sur une seule machine, sans prendre le contrôle de tout le système
    • Je le vois comme un webmin à moitié cuit
      On ne peut l'utiliser qu'avec NetworkManager, or dès que la configuration réseau pour les VM devient un peu complexe, il faut généralement désactiver NetworkManager, ce qui rend Cockpit pratiquement inutilisable
      Pour quelqu'un qui veut gérer des VM avec une interface graphique, virt-manager est bien plus puissant
      [1] https://virt-manager.org/
  • La qualité est juste « moyenne »
    Ça peut convenir à quelques usages très limités, mais si je gérais un serveur domestique, je l'éviterais
    Le plugin d'interface de serveur de fichiers de Cockpit est daté et mauvais
    Je ne vois pas vraiment à quoi ça sert ; ça peut faire un peu de monitoring simple, mais comme outil d'administration, ce n'est pas terrible

    • Exactement
      Je ne comprends pas pourquoi Red Hat pousse ce projet, et il n'a pas beaucoup d'usages pratiques
      Afficher la liste des services systemd n'aide pas plus que de tout voir en sortie de ligne de commande
  • Quand on héberge soi-même un NAS, je trouve que Cockpit est bien meilleur qu’OMV

    • Ça dépend de l’usage et de quelques conditions, et j’utilise les deux avec satisfaction sur deux NAS différents
      OMV dispose d’un plugin Docker avec prise en charge de Compose, donc pas besoin d’une GUI Docker séparée comme Portainer, et les partages SMB semblent plus stables depuis les clients Windows
      Il a une GUI et une approche plus adaptées aux débutants, ce qui le rend aussi plus facile à partager avec d’autres utilisateurs, et inclut des fonctions de base comme fail2ban et WireGuard
      Cockpit est un citoyen de premier rang sur les distributions EL/Fedora, et prend en charge Podman mais pas Docker, sans prise en charge de Compose/Quadlet non plus
      Il offre des fonctions puissantes comme la gestion des VM et le terminal, mais présente des bugs liés à Samba
    • Je me demande pourquoi
      Actuellement, j’utilise OMV pour le partage de fichiers sur le réseau local et quelques conteneurs Docker
      Ça fonctionne bien, mais je n’utilise pas 90 % de ses fonctionnalités
    • Je me demande ce que vaut Proxmox
  • Pour ceux que ça intéresse, d’après https://github.com/cockpit-project/cockpit, Cockpit est écrit dans plusieurs langages, avec C en tête, suivi de JavaScript et de Python
    src/cockpit semble probablement être la logique principale du backend, et c’est en Python

    • En tant que développeur de Cockpit, je peux dire que le serveur web est écrit en C, et que l’ancien bridge était une « API » permettant au JavaScript de communiquer, via le serveur web, avec des API système comme systemd, podman et dbus
      Le nouveau bridge est écrit en Python, et le moment venu, j’aimerais aussi réécrire le serveur web avec une approche plus moderne
    • Je me demande à quel point les gens se soucient de la stack technique utilisée quand on crée un produit destiné à tourner sur un serveur
      Des aspects comme les dépendances, ou le fait de devoir se préoccuper de vulnérabilités dans une bibliothèque de logging ou dans Curl, sont également importants
      Il est aussi intéressant de voir si le produit est écrit avec une stack clairement définie ou s’il mélange plusieurs technologies