LINUX:Cockpit
→ retour à la gestion distante
But
Cockpit est un interface WEB qui permet quelques opérations basiques de gestion du système.
Installation
Il faut installer quelques modules mais il en existe d'autres:
dnf install cockpit dnf install cockpit-dashboard
Activer et lancer le service (socket)
Le service à lancer est COCKPIT via son socket. La première commande active le service pour qu'à chaque démarrage du serveur, le service se lance. La seconde lance directement le service. La troisième relance le service.
systemctl enable cockpit.socket systemctl start cockpit.socket systemctl restart cockpit.socket
Si on désire que l'écoute du service n'écoute que sous IPV4, nous vous reportons à l'article Paramétrage personnalisé de Systemd. Nous créons le répertoire "/etc/systemd/system/cockpit.socket.d" qui fait le pendant du fichier de lancement "cockpit.socket". Dans celui-ci, créons un fichier que l'on peut nommer "listen.conf" dont voici le contenu:
[Socket] ListenStream= ListenStream=0.0.0.0:9090
Elle concerne la section "[Socket]". La seconde ligne permet d'annuler toute autre configuration existante dans le fichier "cockpit.socket" qui définit le même port d'écoute. Ensuite on définit le nouvel interface d'écoute qui écoute sur tout interface IPV4 de la machine avec le port TCP 9090.
Si on a plusieurs interfaces réseaux, on peut restreindre cette écoute à un seul interface:
[Socket] ListenStream= ListenStream=192.168.1.100:9090 FreeBind=yes
Remarquez qu'ici, vous pouvez changer le n° du port (9090).
Ensuite il faut recharger cette modification et relancer le service:
systemctl daemon-reload systemctl restart cockpit.socket
Configurer le mur de feu ou FireWall
Vous avez sûrement activé le FireWall du serveur. Comme c'est un service proposé, il faut ouvrir une porte. Le port TCP à ajouter est 9090. Dans l'exemple, l'adressage de notre LAN est 192.168.1.0 avec un masque de 255.255.255.0 ou de 24 bits. Nous utilisons IPTABLES; voici la ligne à ajouter:
-A INPUT -p tcp -m tcp --dport 9090 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
Recommandation: Je conseille de ne pas l'installer et encore moins de l'activer sur un serveur visible d'Internet. Un serveur, surtout visible d'Internet, doit avoir une surface d'attaque minimale, c'est-à-dire, avec un minimum de logiciels installés et un minimum de services, strictement nécessaires.
Certificat personnel
Cet interface WUI utilise HTTPS et donc un certificat auto-signé. Quand on lance un browser, ce type de certificat pose souvent problème. Pour contourner ce problème, on utilisera un certificat dont le certificat parent est un d'une autorité de certification (CA) connu de votre browser.
Soit vous avez obtenu un certificat officiel pour votre machine et dans ce cas, le nom de machine doit être connu d'Internet, ce qui n'est pas souhaitable.
Il est préférable de créer votre propre autorité de certification (CA) que vous ferez reconnaitre par votre browser. L'article Sécurité via les certificats vous y aidera, aussi bien pour sa création, la création d'un certificat pour votre serveur (Création d'une CA privée (V1) ou Extension de la CA privée (V3)) que pour son implémentation dans votre browser.
A ce stade, il faut spécifier au logiciel Cockpit quel certificat utiliser.
Dans le répertoire "/etc/cockpit/ws-certs.d", nous commençons par effacer tout fichier dont l'extension est ".cert" et ".key".
Ensuite nous créons deux fichiers portant le même nom (par exemple: "serverdb.home"), l'un avec l'extension ".cert" et l'autre ".key". Ils vont contenir les différentes clés de votre machine:
- le fichier "serverdb.home.key" contient la clé privée de votre machine, pas celle de votre autorité de certification
- le fichier "serverdb.home.cert" contient au minimum le certificat publique de votre machine et le certificat publique de votre autorité de certification, l'un en dessous de l'autre.
Si le fichier "serverdb.home.key" n'existe pas, son contenu doit se retrouver dans le fichier "serverdb.home.cert".
Il suffit ensuite de redémarrer le service "cockpit.socket".
On peut vérifier cette configuration avec la commande:
/usr/libexec/cockpit-certificate-ensure --check
qui vous donnera:
Would use certificate /etc/cockpit/ws-certs.d/serverdb.home.cert
Sécurité Utilisateur
Par défaut, l'accès à Cockpit est refusé à l'utilisateur "root". Cet interdit est repris dans le fichier "/etc/cockpit/disallowed-users". Si vous voulez modifier cette liste, modifiez-le avec un éditeur de texte. Vous pouvez même effacer ce fichier.
Notons que l'utilisateur utilisé doit avoir un accès SSH à cette machine sinon l'accès vous sera refusé. Peu importe le port d'écoute (service "sshd.service").
Si tout est correct mais que vous l'accès vous est refusé, regardez dans le fichier "/var/log/secure". Si vous remarquez le message, lié à votre problème, du style: "polkitd[3190]: Unregistered Authentication Agent for unix-session", activez le service "systemd-homed.service".
Lancer l'interface WEB
Enfin, nous allons l'utiliser. A partir d'un navigateur WEB (firefox, chrome,...), on lance la commande suivante pour une machine nommée dans notre exemple "serverdb.home.dom":
https://serverdb.home.dom:9090/
Vous accédez à un menu de login; l'utilisateur est "root" et le login Linux de ce système.
Après login, vous accédez à l'interface. En cliquant sur "Tableau de bord", vous aurez accès à différents onglets généraux:
- CPU
- Disque
- Réseau
A gauche, un menu donne quelques possibilités. Ces options permettent d'aller plus loin et d'effectuer des consultations et configurations: matériel, journaux, disques, réseau, mis-à-jour, utilisateurs, services et surtout l'accès à l'interface de ligne de commandes. Cette dernière option est dangereuse pour la laisser via un accès aussi facile.
→ retour à la gestion distante