Linux — Configuration système pour développeurs

Les commandes et fichiers système que tout développeur rencontre tôt ou tard : résolution DNS, paramètres noyau, logs systemd, variables d’environnement.

Résolution DNS — /etc/hosts

Le fichier /etc/hosts résout les noms avant toute requête DNS. Très utile pour les services locaux ou le mock de dépendances externes.

# Développement local
127.0.0.1   mon-app.test
127.0.0.1   api.mon-app.test
::1         mon-app.test

# Migration progressive : publier l'IP du nouveau serveur
10.0.0.5    api.backend.exemple

Vérifier l’ordre de résolution

Le fichier /etc/nsswitch.conf détermine l’ordre :

hosts:          files mdns4_minimal [NOTFOUND=return] dns

files avant dns signifie que /etc/hosts prime sur le résolveur DNS.

Résolveur DNS — /etc/resolv.conf

Ce fichier indique les serveurs de noms utilisés et les domaines de recherche par défaut.

nameserver 1.1.1.1
nameserver 8.8.8.8
search interne.exemple.com

Serviteurs DNS alternatifs pour le débogage

# Vérifier la résolution d'un nom via un serveur précis
dig @1.1.1.1 api.mon-app.test
 
# Lister tous les serveurs connus
resolvectl status | grep -A2 "DNS Servers"

Paramètres noyau — sysctl

/etc/sysctl.conf (et les fichiers dans /etc/sysctl.d/) modifie les paramètres du noyau au démarrage. Un développeur backend ou DevOps en croise régulièrement.

Paramètres courants

# Augmenter la file d'attente TCP (défaut souvent 128)
net.core.somaxconn = 4096

# Réutiliser les sockets fermées rapidement (évite "address already in use")
net.ipv4.tcp_tw_reuse = 1

# Limites de descripteurs de fichiers (doublon utile en sysctl)
fs.file-max = 2097152

# Désactiver IPv6 si non nécessaire (réduit le bruit de connexion)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

# Logs noyau en mode console uniquement (réduit les traces inutiles)
kernel.printk = 3 3 3 3

Appliquer sans redémarrage

# Charger tous les fichiers sysctl.d + le fichier principal
sudo sysctl --system
 
# Vérifier la valeur effective d'un paramètre
sysctl net.core.somaxconn

Logs systemd — journalctl

systemd-journald centralise tous les logs système et applicatifs. Il remplace avantageusement tail -f /var/log/syslog pour le débogage de services.

Commandes de base

# Logs du service mon-app
journalctl -u mon-app
 
# Suivis en temps réel
journalctl -u mon-app -f
 
# Dernières 100 lignes
journalctl -u mon-app -n 100
 
# Logs de la session de débogage actuelle uniquement
journalctl -p err -n 50 --no-pager

Filtres utiles

# Période horaire précise (depuis hier 14h)
journalctl --since "2026-07-05 14:00:00" -u mon-app
 
# Suivie avec horodatage complet
journalctl -f -u mon-app --output=verbose
 
# Journal précédent (avant dernier reboot)
journalctl -u mon-app -b -1
 
# Restriction aux entrées d'un programme spécifique
journalctl _COMM=java -n 200
 
# Recherche textuelle dans les logs
journalctl -u mon-app -g "OutOfMemoryError"

Variables d’environnement

Plusieurs niveaux cohabitent. Bien les distinguer évite les surprises quand un service ne “voit” pas une variable pourtant dans .bashrc.

/etc/environment

Chargé au login (PAM), pas interprété par le shell (pas d’expansion de variables, pas de $HOME).

JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64"
EDITOR="vim"

/etc/profile et /etc/profile.d/*.sh

Variables exportées pour tous les shells login. Préférer /etc/profile.d/mon-service.sh aux ajouts directs dans /etc/profile (plus maintenable, pas de conflits lors des mises à jour du package base-files).

# /etc/profile.d/maven.sh
export MAVEN_HOME="/opt/maven"
export PATH="$MAVEN_HOME/bin:$PATH"

~/.profile (shell login)

Variables personnelles pour le shell login :

# ~/.profile — chargé au login (SSH, TTY)
export LANG="fr_FR.UTF-8"
export LC_ALL="fr_FR.UTF-8"
 
# Charger .bashrc si shell bash (pas chargé par défaut)
if [ "$(basename "$SHELL")" = "bash" ]; then
    [ -f "$HOME/.bashrc" ] && source "$HOME/.bashrc"
fi

Relations entre les fichiers

PAM (login) → /etc/environment
              /etc/profile → /etc/profile.d/*.sh
              ~/.profile (si présent) → source ~/.bashrc (bash)

Shell interactif non-login → ~/.bashrc uniquement

Variables d’environnement dans systemd

Exemple concret pour ajouter des variables à un service :

# Créer le répertoire d'override
sudo mkdir -p /etc/systemd/system/mon-app.service.d
 
# Créer le fichier d'override
sudo tee /etc/systemd/system/mon-app.service.d/override.conf << 'EOF'
[Service]
Environment="APP_ENV=production"
Environment="DATABASE_URL=postgres://app:***@db:5432/appdb"
EnvironmentFile=-/etc/default/mon-app
EOF
 
# Recharger et redémarrer
sudo systemctl daemon-reload
sudo systemctl restart mon-app

Vérifier les variables d’un service en cours

# Afficher toutes les variables d'un service par son PID
sudo cat /proc/<PID>/environ | tr '\0' '\n'
 
# Ou via systemd
systemctl show mon-app --property=Environment

Pièges fréquents

• /etc/environment vs /etc/profile : le premier ne supporte pas l’expansion de variables. JAVA_HOME=/usr/lib/jvm/java-$VERSION fonctionne dans /etc/profile.d/ mais pas dans /etc/environment.

• Service systemd muet sur .bashrc : un script ou un daemon lancé par systemd ne voit jamais les aliases ni les variables de .bashrc. Passer par Environment= ou EnvironmentFile=.

• Éditer /etc/resolv.conf à la main : la plupart des distros modernes (Ubuntu 18+, Debian 10+, Fedora 31+) gèrent ce fichier via systemd-resolved. Un éditeur manuel sera écrasé au prochain renouvellement du fichier par NetworkManager. Utiliser resolvectl dns ou la config NetworkManager.

• sysctl non persisté : sysctl -w en ligne de commande ne survit pas au reboot. Pour la persistance, écrire dans /etc/sysctl.d/99-custom.conf puis sudo sysctl --system.

• Session SSH sans $HOME : quand on invoque sudo bash -c "echo $JAVA_HOME", la variable peut être vide. sudo crée un environnement neutre. Utiliser sudo -E pour conserver l’environnement ou faire confiance au fichier système.

Référence : systemd.journald man page , sysctl documentation , NSSwitch . Tester chaque modification avec un serveur de test isolé avant production.