Administration système : users, services, cron

Tu sais naviguer dans Linux et écrire des scripts Bash. Maintenant on passe au vrai boulot d’ops : maintenir un serveur fonctionnel. Installer des logiciels proprement, gérer les processus qui dérapent, configurer des services qui redémarrent tout seuls, et automatiser les tâches récurrentes. C’est ce chapitre qui te rend autonome sur un serveur de production.

Gestion des paquets

Sous Linux, on n’installe pas de .exe téléchargés depuis des sites douteux. Tout passe par un gestionnaire de paquets — un système centralisé qui gère installation, mises à jour, dépendances et suppression propre.

En DevOps, deux gestionnaires dominent : apt (Debian/Ubuntu, 90% des serveurs cloud) et dnf (RHEL/Rocky/Alma, banques et grandes entreprises).

# Le classique qu'on tape à chaque connexion
sudo apt update && sudo apt upgrade -y

# Installer plusieurs paquets d'un coup
sudo apt install -y curl wget git vim htop tree jq

# Supprimer un paquet ET sa configuration
sudo apt purge nginx && sudo apt autoremove -y

# Chercher un paquet / voir ses infos
apt search redis
apt show nginx

# Quel paquet a fourni ce binaire ?
dpkg -S /usr/bin/curl

Pour dnf, la syntaxe est quasi identique : dnf install, dnf remove, dnf search. La différence principale : dnf n’a pas besoin d’un update séparé avant d’installer.

⚠️ En prod, jamais de apt upgrade -y à l’aveugle. Tu testes d’abord sur un staging. Les équipes sérieuses utilisent unattended-upgrades pour les patches de sécurité automatiques et gardent les mises à jour majeures pour des fenêtres de maintenance planifiées.

Dépôts tiers

Tu auras souvent besoin de logiciels absents des dépôts officiels (Docker, Grafana, HashiCorp). L’ajout d’un dépôt tiers implique toujours deux étapes : la clé GPG pour vérifier l’authenticité, puis l’URL du dépôt.

# Exemple : ajouter le dépôt Grafana
wget -qO- https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | \
    sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana

💡 apt-key add est déprécié depuis Ubuntu 22.04. La méthode moderne utilise /etc/apt/keyrings/ avec gpg --dearmor. Tu verras les deux syntaxes dans la doc des projets — la nouvelle est plus sécurisée car elle lie la clé à un dépôt spécifique.

Processus : comprendre et contrôler

Un processus, c’est un programme en cours d’exécution. Chaque processus a un PID unique, un propriétaire, un état (running, sleeping, zombie) et une consommation CPU/mémoire.

# Tous les processus du système
ps aux

# Chercher un processus spécifique (mieux que grep)
pgrep -a nginx

# Top 10 par mémoire
ps -eo pid,user,%cpu,%mem,cmd --sort=-%mem | head -10

# Monitoring interactif (ton premier réflexe quand ça rame)
htop

Pour tuer un processus, commence toujours par SIGTERM (arrêt propre) avant de sortir SIGKILL :

# Arrêt propre — laisse le temps de nettoyer
kill 12345

# Arrêt forcé — dernier recours uniquement
kill -9 12345

# Par nom
pkill -f "python3 mon_script"

# Reload config sans redémarrer (nginx, haproxy...)
kill -HUP $(pgrep nginx)

🔥 kill -9 ne devrait jamais être ton premier réflexe. SIGKILL ne laisse pas au processus le temps de fermer ses fichiers, ses connexions réseau ou ses transactions en base. Un kill simple (SIGTERM), puis 5 secondes d’attente. Le -9 c’est uniquement si le processus refuse de mourir.

systemd : le chef d’orchestre

systemd est le système d’init de toutes les distributions modernes. C’est lui qui démarre le système, lance les services, gère les dépendances et surveille que tout tourne.

# Les commandes quotidiennes
sudo systemctl start nginx          # Démarrer
sudo systemctl stop nginx           # Arrêter
sudo systemctl restart nginx        # Redémarrer
sudo systemctl reload nginx         # Recharger config (graceful)
sudo systemctl enable --now nginx   # Activer au boot + démarrer

# Diagnostic
systemctl status nginx              # État détaillé
systemctl --failed                  # Services en erreur
journalctl -u nginx -f              # Logs en temps réel

La différence entre enable et start est fondamentale. start lance le service maintenant. enable le configure pour démarrer au boot. Ce sont deux actions indépendantes — enable --now fait les deux d’un coup.

Créer ton propre service

Au lieu de lancer ton app avec nohup dans un screen (l’approche amateur), crée un fichier unit systemd :

# /etc/systemd/system/monapp.service
[Unit]
Description=Mon application Python
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/monapp
ExecStart=/opt/monapp/venv/bin/python3 app.py
Restart=always
RestartSec=5
Environment=ENV=production

# Sécurité : limiter les dégâts si l'app est compromise
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/monapp/data

[Install]
WantedBy=multi-user.target

Puis active-le : sudo systemctl daemon-reload && sudo systemctl enable --now monapp.

Restart=always + RestartSec=5 : si l’app crash, systemd la relance automatiquement après 5 secondes. Les directives de sécurité (NoNewPrivileges, ProtectSystem) sont souvent ignorées par les débutants — ne fais pas cette erreur, c’est de la défense en profondeur.

🎯 En entreprise, tu ne crées pas ces fichiers à la main sur chaque serveur. Tu utilises Ansible pour les déployer sur des dizaines de machines. Mais comprendre la structure est indispensable pour diagnostiquer quand ça ne marche pas.

Surveillance des ressources

Quand un client appelle en disant “le serveur est lent”, voici ton trio de diagnostic :

# Mémoire — la colonne qui compte c'est "available", pas "free"
free -h

# Disque — un disque plein = services qui crashent
df -h
df -ih   # Inodes (piège vicieux : espace dispo mais plus d'inodes)

# CPU — load average vs nombre de cœurs
uptime   # load > nproc = surcharge
nproc    # Nombre de cœurs

💡 Linux utilise la RAM libre comme cache disque — c’est intelligent et voulu. Si free est bas mais available est confortable, tout va bien. C’est available qui indique la mémoire réellement disponible pour les applications.

⚠️ Le problème des inodes est vicieux. Tu peux avoir de l’espace disque disponible mais ne plus pouvoir créer de fichiers. Ça arrive avec des millions de petits fichiers (sessions PHP, cache). df -ih te montre ça — surveille-le aussi.

Pièges fréquents et ce qu’il faut retenir

Le systemctl enable oublié. Tu installes nginx, tu fais start, tout marche. Le serveur reboot un mois plus tard : nginx ne démarre pas. L’oubli le plus fréquent en prod — toujours enable --now.

Les crons silencieux. Un backup qui échoue pendant 3 mois sans que personne ne le sache. Solution : redirige les sorties vers un log ET alerte en cas d’échec. Un simple || curl -X POST https://hooks.slack.com/... suffit.

Le disque plein par les logs. Les logs non rotés remplissent le disque. C’est le problème numéro 1 en production. Configure logrotate dès le premier jour.

Les dépôts tiers non vérifiés. Ne fais jamais confiance aveuglément à un dépôt. Vérifie que l’URL vient de la documentation officielle du projet. Un dépôt compromis = un serveur compromis.

L’administration système se résume à quelques réflexes. apt pour les paquets, systemctl pour les services, htop pour le diagnostic, journalctl pour les logs. Le vrai talent, c’est de combiner ces outils pour diagnostiquer un problème en 2 minutes au lieu de 2 heures. Et la règle d’or : quand un service ne marche pas, journalctl -u ton-service -f — les logs te disent toujours ce qui ne va pas. Ne devine jamais, lis les logs.

Dans le prochain chapitre, on attaque le réseau sous Linux : configuration IP, firewall, SSH et transferts de fichiers.