Mise en place de Cocckpit et du module cockpit-zfs

Mise en place de Cockpit et du module cockpit-zfs

Objectif

Voir aussi : Installation_de_eole3_avec_stockage_ZFS_et_migration_FTP_vers_SFTP

Ajouter une interface web d’administration afin de :

• visualiser l’état global du serveur ;
• suivre les pools et datasets ZFS ;
• disposer d’une vue plus simple que la ligne de commande pour les opérations de contrôle.

Le serveur cible est eole3.

---

Installation de Cockpit

Installation du paquet principal :

apt update
apt install -y cockpit

Cockpit est ensuite accessible sur :

https://IP_DU_SERVEUR:9090

Exemple :

https://51.178.110.230:9090

Remarques :

• le certificat est auto-signé par défaut ;
• un avertissement navigateur est donc normal ;
• l’accès peut se faire avec un compte administrateur du serveur.

---

Installation du module cockpit-zfs

Le module ZFS utilisé est le projet 45Drives/cockpit-zfs.

Clonage

cd /opt
git clone https://github.com/45Drives/cockpit-zfs.git
cd cockpit-zfs

Premier échec : dépendance manquante

Lors du premier make install, l’erreur suivante a été obtenue :

Missing 'sponge'. Please install moreutils.

Correction :

apt update
apt install -y moreutils

Deuxième échec : yarn manquant

Au lancement suivant, l’erreur suivante a été obtenue :

Missing 'yarn'. Please install yarn.

Sous Ubuntu/Debian, le paquet à installer est :

apt install -y yarnpkg

Puis création d’un lien symbolique pour fournir la commande attendue :

ln -s /usr/bin/yarnpkg /usr/local/bin/yarn

Vérification :

which yarn
yarn --version

Exemple de résultat :

/usr/local/bin/yarn
4.13.0

Installation du module

Une fois les dépendances présentes :

cd /opt/cockpit-zfs
make install
systemctl restart cockpit

---

Problème d’interface web qui boucle

Après installation, l’interface Cockpit a présenté un comportement anormal :

• chargement de la page ;
• effacement ;
• rechargement en boucle.

La cause la plus probable était le cache navigateur.

Correction

• faire un rechargement forcé de la page ;
• vider le cache navigateur ;
• éventuellement tester en navigation privée.

Après purge du cache, l’interface a fonctionné normalement.

---

Installation de PCP pour l’historique des métriques

Cockpit proposait l’installation de composants supplémentaires pour afficher des métriques historiques.

Le paquet utile est :

apt install -y cockpit-pcp pcp
systemctl enable --now pmcd

Message observé à l’installation :

Synchronizing state of pmcd.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable pmcd

Ce message est normal et confirme l’activation du service.

PCP = Performance Co-Pilot Il sert à fournir à Cockpit :

• l’historique CPU ;
• l’historique mémoire ;
• l’historique réseau ;
• l’historique disque.

---

Problèmes cockpit-zfs sous Ubuntu

Au départ, l’interface ZFS affichait mal ou incomplètement les informations :

• un seul disque visible ;
• pas de datasets ;
• erreurs dans le journal Cockpit.

Erreurs observées :

ERROR: libzfs import failed: No module named 'libzfs'
ERROR: Exception in get_lsdev_disks: [Errno 2] No such file or directory: 'lsdev'
ERROR: smartctl exception: [Errno 2] No such file or directory: 'smartctl'

Ces erreurs ne signifiaient pas que ZFS était cassé, mais que le plugin Cockpit n’avait pas toutes ses dépendances.

---

Correction des dépendances manquantes

smartctl

Le plugin cockpit-zfs essaie d’interroger les disques via SMART.

Installation :

apt install -y smartmontools

Cela permet de supprimer les erreurs liées à :

smartctl

libzfs Python

Le plugin cockpit-zfs attend également une bibliothèque Python ZFS.

Installation :

apt install -y python3-libzfs

Après installation des dépendances manquantes, l’interface Cockpit ZFS a commencé à afficher correctement :

• les 6 disques ;
• le vdev raidz2 ;
• les datasets ;
• les quotas.

---

Vérification CLI de l’état ZFS

La source de vérité reste la ligne de commande.

Vérification des pools

zpool status
zpool list

Vérification détaillée des datasets

zfs list -o name,used,avail,refer,quota,mountpoint

Exemple de résultat :

NAME                               USED  AVAIL  REFER  QUOTA  MOUNTPOINT
data                               275M  87.1T   384K   none  /var/data
data/clients                       269M  87.1T   192K   none  none
data/clients/ad44-data             192K  87.1T   192K   none  /var/data/ad44-data
data/clients/ad53-data             192K  10.0T   192K    10T  /var/data/ad53-data
data/clients/ad64-data             192K  32.0T   192K    32T  /var/data/ad64-data
data/clients/apbp-data             192K  1024G   192K     1T  /var/data/apbp-data
data/clients/module-pleade-data   39.4M  87.1T  39.3M   none  /var/data/module-pleade-data
data/clients/test-ajlsm-data       226M  87.1T   226M   none  /var/data/test-ajlsm-data

Ce résultat confirme :

• l’existence des datasets clients ;
• la bonne prise en compte des mountpoints ;
• la présence des quotas déjà définis sur certains datasets.

---

Interprétation des valeurs affichées dans Cockpit

Cockpit peut afficher des tailles disponibles différentes selon les datasets.

C’est normal si certains datasets ont un quota.

Exemples :

• ad53-data : quota 10T, donc disponible affiché ≈ 10T ;
• ad64-data : quota 32T, donc disponible affiché ≈ 32T ;
• apbp-data : quota 1T, donc disponible affiché ≈ 1T.

Les valeurs apparemment “bizarres” dans l’interface Cockpit sont donc liées aux quotas ZFS, et non à une anomalie disque.

---

Remarque sur realmd dans Cockpit

Cockpit proposait également l’installation de paquets supplémentaires avec des messages du type :

Installer le logiciel
Error: Cannot refresh cache whilst offline
realmd sera installé

realmd sert à joindre une machine à un domaine (Active Directory / LDAP / Kerberos). Dans le cadre de eole3, ce paquet n’est pas nécessaire.

La recommandation est donc :

• ignorer cette proposition ;
• utiliser apt en ligne de commande pour les installations utiles.

---

Conclusion sur Cockpit / cockpit-zfs

À l’issue de cette étape :

• Cockpit fonctionne correctement ;
• l’historique système est disponible via PCP ;
• le plugin cockpit-zfs fonctionne suffisamment pour le confort d’exploitation ;
• la ligne de commande reste la source de vérité pour les vérifications critiques.

Cockpit permet désormais de visualiser :

• le pool data ;
• le vdev raidz2 ;
• les 6 disques ;
• les datasets ZFS par client ;
• les quotas sur les datasets concernés.

Cette étape prépare l’exploitation courante du serveur avant le démarrage de la synchronisation rsync.

Problèmes et solutions

Voir aussi : Supprimer un service non utilisé : iipsrv.service

Cockpit - gestion des mises à jour (PackageKit)

Cockpit utilise PackageKit pour gérer les mises à jour.

Sur Ubuntu 24.04, PackageKit peut être défaillant et retourner l’erreur :

Cannot refresh cache whilst offline

Même lorsque :

• le réseau est fonctionnel
• apt update fonctionne correctement

Dans ce cas, le problème vient de PackageKit lui-même.

Solution retenue :

• ne pas utiliser la gestion des mises à jour via Cockpit
• utiliser directement apt

Désactivation du service :

systemctl disable packagekit
systemctl mask packagekit

Résultat :

• plus d’erreur dans Cockpit
• gestion des mises à jour fiable via apt

Cockpit : page "Services" qui ne charge pas

Symptôme

• La page "Services" de Cockpit ne se charge pas ou reste bloquée
• Interface partiellement inutilisable

Cause

• Un service systemd en état "failed" peut bloquer l'affichage
• Cockpit interroge systemd → un état incohérent peut provoquer un blocage

Diagnostic

systemctl list-units --type=service --state=failed

Solution

Réinitialiser l'état du service en échec :

systemctl reset-failed NOM_DU_SERVICE

Exemple :

systemctl reset-failed unattended-upgrades.service

Puis redémarrer Cockpit :

systemctl restart cockpit

Remarque

• Cette opération ne corrige pas la cause du problème mais permet de rétablir l'affichage
• Si le problème revient, analyser le service concerné :

systemctl status NOM_DU_SERVICE
journalctl -u NOM_DU_SERVICE

Cockpit : gestion des mises à jour inactive (PackageKit)

Symptôme

• Impossible de gérer les mises à jour via Cockpit
• Onglet "Mises à jour" vide ou non fonctionnel
• Messages d’erreur liés à PackageKit

Cause

• Le service PackageKit a été arrêté ou supprimé
• Cockpit utilise PackageKit pour afficher et gérer les mises à jour

Diagnostic

systemctl status packagekit

Solution

Relancer le service :

systemctl start packagekit
systemctl enable packagekit

Si PackageKit n’est pas installé :

apt install packagekit

Remarque

• PackageKit est uniquement nécessaire pour l’interface Cockpit
• Les mises à jour système restent possibles en ligne de commande :

apt update && apt upgrade

Choix d’exploitation

• Serveur administré en CLI → PackageKit non indispensable
• Serveur administré via Cockpit → PackageKit recommandé

Symptôme

Failed to start packagekit.service: Unit packagekit.service is masked.

Cause

• Le service a été explicitement désactivé (mask)
• Impossible de le démarrer tant qu’il est masqué

Solution

systemctl unmask packagekit
systemctl start packagekit
systemctl enable packagekit

Remarque

• Le masquage est une désactivation forte
• Utilisé pour empêcher totalement le lancement d’un service

Particularité de PackageKit

• PackageKit ne s’active pas avec "systemctl enable"
• Service démarré à la demande (D-Bus)

Comportement normal

• Peut apparaître comme "inactive (dead)"
• Se lance automatiquement lors d’un appel (ex : Cockpit)

Conclusion

• Aucun problème si le service n’est pas actif en permanence

Cockpit : partition EFI non montée

Symptôme

• Alerte dans Cockpit sur la partition EFI
• Message :

Le système de fichiers n’est pas monté.
Montage incohérent

Cause

• La partition /boot/efi n’est pas montée
• Mais elle est configurée pour être montée au démarrage

Impact

• Risque de blocage au démarrage
• Problème potentiel avec le bootloader (GRUB / EFI)

Diagnostic

Vérifier si la partition est montée :

mount | grep efi

Solution

Monter la partition :

mount /boot/efi

Vérifier :

df -h | grep efi

Vérification configuration

Fichier :

/etc/fstab

Exemple :

UUID=XXXX /boot/efi vfat defaults 0 1

Recommandation

Ajouter l’option nofail pour éviter un blocage au boot :

UUID=XXXX /boot/efi vfat defaults,nofail 0 1

Remarque

• Une partition EFI non montée peut passer inaperçue
• Mais peut poser problème lors des mises à jour du système ou du boot

Symptôme

• Partition EFI montée de manière incohérente
• Alerte Cockpit
• Risque de boot instable

Cause

• Plusieurs partitions EFI avec le même LABEL
• Utilisation de LABEL dans /etc/fstab

Diagnostic

blkid | grep EFI

Solution

Identifier la partition réellement utilisée :

mount | grep efi

Modifier /etc/fstab pour utiliser UUID :

UUID=C6E8-223E /boot/efi vfat defaults,nofail 0 1

Recommandation

• Ne jamais utiliser LABEL pour EFI si plusieurs disques
• Utiliser UUID
• En cas de RAID, prévoir une synchronisation des partitions EFI

Symptôme

• Page "Comptes" ne charge pas
• Déconnexion après refresh
• Fonctionne sur Chrome mais pas Firefox

Cause

• Cache navigateur corrompu
• Session Cockpit invalide (WebSocket)

Solution

Vider le cache Firefox :

Ctrl + Shift + R

Ou supprimer les données du site.

Tester en navigation privée.

Recommandation

• Tester avec un autre navigateur avant diagnostic serveur

SFTPGo : accès admin perdu

Symptôme

• Interface web admin inaccessible
• SFTP fonctionne toujours

Cause

• Mot de passe admin perdu ou invalide

Solution

systemctl stop sftpgo
sftpgo resetpwd --admin admin --config-dir /etc/sftpgo
systemctl start sftpgo

Bonnes pratiques

• Créer plusieurs comptes admin
• Sauvegarder la base SQLite