Centre Linux / Debian
Un point d’entrée pratique pour diagnostiquer un serveur Linux : services, réseau, SSH, stockage, paquets, performances, logs et sécurité locale.
Générateur de rapport express
Sélectionnez le contexte : BAOI génère un bloc de commandes en lecture seule à exécuter puis à copier dans un ticket ou un rapport.
uname -a && cat /etc/os-release
uptime
systemctl --failed
journalctl -b -p err..alert
ps aux --sort=-%cpu | head
free -h && swapon --show
ps aux --sort=-%mem | head
df -hT
df -i
du -xhd1 /var | sort -h
ip -br addr
ip route
ss -lntup
resolvectl status
dig example.com
sshd -t
journalctl -u ssh -b --no-pager
dpkg --audit
dpkg --configure -a
apt-get -f install
journalctl --since '1 hour ago'
journalctl --disk-usage
timedatectl
namei -l /chemin/fichier
nft list ruleset
docker ps -a
docker system df
Logs d’abord
Lire journalctl avant de redémarrer un service en boucle.
df -h et df -i
Un système peut manquer d’inodes avec encore beaucoup de Go disponibles.
Permissions
Éviter chmod 777 : identifier owner, groupe, ACL et contexte.
APT
Ne jamais supprimer un lock dpkg sans confirmer qu’aucun processus valide ne tourne.
Filesystem
Un remount read-only peut signaler une panne disque ou une corruption.
Load
Un load élevé peut provenir de l’I/O, pas seulement du CPU.
Mission du centre
8 playbooksQualifier un incident Linux par service, ressources, stockage, réseau, DNS, SSH, permissions et paquets en collectant d’abord l’état systemd et les journaux.
Triage rapide
- Relever uptime, charge, mémoire et espace disque.
- Identifier le service ou processus réellement impacté.
- Lire journalctl sur la fenêtre de l’incident.
- Valider IP, route et DNS avant les applications réseau.
- Conserver une copie de configuration avant modification.
Arbre de décision
systemctl status + journalctl, puis dépendances/configuration.
Charge, mémoire, I/O et espace disque avant redémarrage.
Lien, adresse, route, DNS puis firewall.
Lire dpkg/apt et comparer versions/configuration.
Playbooks d’intervention
Commencer en lecture seule, collecter les preuves, puis ne modifier qu’une variable à la fois.
01Service systemd en échecModification contrôlée
Service en failed/inactive ou redémarrages répétés.
Vérifications
- Lire status complet et exit code.
- Examiner les logs du service et ses dépendances.
- Valider syntaxe de configuration avant restart.
Commandes / preuves
systemctl status <service> --no-pagerjournalctl -u <service> -n 100 --no-pagersystemctl list-dependencies <service>Résultat attendu
La cause du failed est visible et le service reste active après correction.
Actions correctives
- Corriger configuration/dépendance puis redémarrer uniquement ce service.
- Conserver la sortie du journal avant rotation.
Escalader si
Crash binaire, corruption de données ou service critique reste instable.
02Disque ou inodes pleinsModification contrôlée
No space left on device, services incapables d’écrire ou apt en échec.
Vérifications
- Comparer occupation blocs et inodes.
- Identifier répertoires qui grossissent.
- Contrôler logs, cache, snapshots ou fichiers supprimés encore ouverts.
Commandes / preuves
df -hTdf -ihdu -xhd1 /var | sort -hlsof +L1Résultat attendu
Une consommation précise explique la saturation et une marge durable est restaurée.
Actions correctives
- Réduire rétention/nettoyer uniquement les données sûres.
- Étendre filesystem si la croissance est légitime.
Escalader si
Filesystem critique, LVM/RAID complexe ou données métier non identifiées.
03Charge CPU / mémoire élevéeLecture / sans risque
Load average élevé, swap important ou processus qui monopolise les ressources.
Vérifications
- Distinguer CPU, wait I/O et pression mémoire.
- Identifier processus/threads dominants.
- Corréler à cron, backup ou trafic.
Commandes / preuves
uptimefree -hps aux --sort=-%cpu | head -20vmstat 1 5Résultat attendu
Le goulot CPU/mémoire/I/O est clairement identifié.
Actions correctives
- Traiter le processus ou planification responsable.
- Éviter kill -9 en première action sur un service avec état.
Escalader si
OOM killer, kernel stall ou saturation persistante sans processus identifiable.
04Plus de réseauLecture / sans risque
Serveur n’atteint plus gateway ou réseau après reboot/changement.
Vérifications
- Vérifier link, adresse et interface attendue.
- Lire table de routage.
- Contrôler NetworkManager/systemd-networkd/ifupdown selon distribution.
Commandes / preuves
ip -br addrip routeip -s linkping -c 4 <gateway>Résultat attendu
Interface up, adresse correcte et route par défaut utilisable.
Actions correctives
- Corriger configuration persistante plutôt qu’un ip addr temporaire.
- Vérifier VLAN/hyperviseur si le lien OS semble correct.
Escalader si
Bond/bridge/VLAN complexe, route asymétrique ou perte amont.
05DNS en échecLecture / sans risque
Ping IP fonctionne mais noms ne se résolvent plus.
Vérifications
- Lire resolv.conf et resolver effectif.
- Tester serveur DNS explicitement.
- Vérifier search domains et systemd-resolved si utilisé.
Commandes / preuves
cat /etc/resolv.confresolvectl statusdig example.comdig @<DNS> example.comRésultat attendu
Le resolver répond sans timeout et renvoie l’adresse attendue.
Actions correctives
- Corriger source de configuration DNS (DHCP/netplan/resolved), pas seulement resolv.conf si généré.
- Tester interne et externe séparément.
Escalader si
DNS interne autoritatif indisponible ou filtrage UDP/TCP 53 hors serveur.
06SSH inaccessibleModification contrôlée
Timeout, connection refused ou authentication failed sur SSH.
Vérifications
- Distinguer port inaccessible et authentification refusée.
- Vérifier sshd, écoute et firewall.
- Lire auth.log/journal pour utilisateur/clé.
Commandes / preuves
systemctl status ssh --no-pagerss -lntp | grep :22journalctl -u ssh -n 100 --no-pagerssh -vvv <user>@<host>Résultat attendu
sshd écoute et le log explique précisément l’acceptation ou le refus.
Actions correctives
- Corriger clé/droits/configuration puis tester une seconde session avant fermer la première.
- Valider sshd -t avant reload.
Escalader si
Accès distant unique, firewall externe ou PAM/SSSD/LDAP en cause.
07Permission deniedModification contrôlée
Application ou utilisateur ne peut lire/écrire/exécuter malgré fichier présent.
Vérifications
- Lire owner, group et mode sur toute la chaîne de répertoires.
- Contrôler ACL et contexte SELinux/AppArmor si applicable.
- Identifier UID/GID réel du processus.
Commandes / preuves
namei -l <path>getfacl <path>id <user>ps -o user,group,cmd -p <pid>Résultat attendu
Une règle de permission précise explique l’échec.
Actions correctives
- Appliquer le droit minimal au bon niveau.
- Éviter chmod -R 777 comme contournement.
Escalader si
Stockage NFS/CIFS, ACL héritées complexes ou contraintes de sécurité obligatoires.
08APT / mise à jour en erreurModification contrôlée
apt update/upgrade échoue, dpkg verrouillé ou paquets non configurés.
Vérifications
- Lire erreur exacte et dépôts configurés.
- Vérifier processus apt/dpkg actifs avant supprimer un lock.
- Contrôler espace disque, DNS et heure pour TLS.
Commandes / preuves
apt updatedpkg --auditps aux | egrep "apt|dpkg"journalctl -u apt-daily.service -n 50Résultat attendu
Les dépôts sont joignables et dpkg n’a plus de paquet cassé.
Actions correctives
- Réparer configuration de paquet ou dépôt identifié.
- Ne jamais supprimer un lock si un dpkg actif travaille réellement.
Escalader si
Upgrade majeur interrompu, dépendances critiques cassées ou dépôt tiers indispensable indisponible.
Checklist de fin d’intervention
- Vérifier systemctl --failed.
- Contrôler espace disque et charge après correction.
- Retester le service depuis son client réel.
- Archiver commandes et extraits de logs utiles.
- Documenter configuration ou paquet modifié.
Aller plus loin dans BAOI
Fiche mémo associéeLinux — commandes essentielles Outils informatiquesCalculer, inspecter ou générer sans quitter le flux de diagnostic. ProcéduresSuivre une procédure de mise en œuvre contrôlée. Pannes connuesCroiser le symptôme avec les pannes et causes déjà documentées.À consulter : LVM.
À consulter : SELinux.
À consulter : chmod.