Cas pratiques Linux Administration

Contexte : Une application interne déployée sur un serveur Linux ne parvient plus à écrire dans un répertoire partagé utilisé pour stocker des fichiers temporaires. Le Problème : L’utilisateur applicatif reçoit une erreur "Permission denied" alors que le dossier existe bien sur le système. Contraintes : Vous ne pouvez pas modifier le code de l’application ni supprimer le répertoire. Vous devez corriger uniquement la propriété ou les permissions Unix en respectant le principe du moindre privilège. Extrait actuel : drwx------ 2 root root 4096 Mar 10 10:00 /srv/appdata Livrable attendu : Fournir les commandes nécessaires pour permettre à l’utilisateur "appuser" d’accéder en lecture et écriture au répertoire sans ouvrir l’accès à tous les utilisateurs du système.

Contexte : Un service personnalisé a été configuré pour démarrer automatiquement au boot du serveur. Le Problème : Après redémarrage, le service ne démarre pas et systemctl status affiche une erreur liée à une directive manquante. Contraintes : Corriger uniquement le fichier .service sans modifier l’exécutable cible. Extrait actuel : [Service] ExecStart=/usr/bin/myapp Restart=always Livrable attendu : Proposer une version complète et valide du fichier systemd permettant le démarrage correct du service.

Contexte : Une nouvelle application doit être déployée sur un serveur Linux de production. Le Problème : Aucun compte dédié n’existe et l’équipe refuse d’utiliser root pour exécuter l’application. Contraintes : Créer un utilisateur avec répertoire personnel, shell valide, mot de passe défini et sans privilèges sudo. Livrable attendu : Fournir les commandes permettant de créer l’utilisateur "deployuser" avec home directory, mot de passe sécurisé et permissions standards sans droits administrateur.

Contexte : Une application web écoute sur le port 8080 mais n’est pas accessible depuis l’extérieur. Le Problème : Le pare-feu bloque les connexions entrantes sur ce port. Contraintes : Ouvrir uniquement le port 8080 sans désactiver le firewall ni ouvrir d’autres ports. Livrable attendu : Fournir les commandes nécessaires avec ufw ou firewall-cmd pour autoriser le port 8080 et appliquer la configuration.

Contexte : Une sauvegarde doit être exécutée chaque jour à 2h du matin sur un serveur Linux. Le Problème : Le script de sauvegarde existe mais aucune tâche automatique n’est configurée. Contraintes : Utiliser cron sans modifier le script existant situé dans /usr/local/bin/backup.sh. Livrable attendu : Fournir la ligne cron correcte permettant l’exécution quotidienne du script à 02:00 et indiquer la commande pour éditer la crontab.

Contexte : Un serveur critique présente des ralentissements avec une utilisation mémoire proche de 100%. Le Problème : Il est difficile de déterminer si la consommation provient d’un processus spécifique, d’un leak mémoire ou du cache système. Contraintes : Utiliser uniquement des outils natifs comme free, top, vmstat, ps et /proc. Livrable attendu : Décrire une méthodologie structurée pour identifier la cause réelle de la saturation et proposer des actions correctives adaptées au contexte.

Contexte : Une base de données doit être sauvegardée quotidiennement avec conservation limitée des anciennes sauvegardes. Le Problème : Les sauvegardes s’accumulent sans mécanisme automatique de suppression. Contraintes : Écrire un script shell simple et planifier son exécution via cron, avec suppression automatique des fichiers de plus de 7 jours. Livrable attendu : Décrire la structure du script et la planification cron assurant une rotation efficace des sauvegardes.

Contexte : Une application génère plusieurs gigaoctets de logs par semaine. Le Problème : Les fichiers ne sont pas correctement archivés ni compressés, ce qui remplit le disque. Contraintes : Mettre en place une rotation quotidienne, conserver 14 archives et compresser automatiquement les anciens fichiers. Livrable attendu : Proposer un fichier de configuration logrotate complet adapté au chemin /var/log/myapp/*.log.

Contexte : Une application génère plusieurs gigaoctets de logs chaque semaine sur /var/log/myapp/. Le Problème : Les fichiers ne sont pas compressés ni correctement archivés, ce qui provoque une saturation disque. Contraintes : Mettre en place une rotation quotidienne, conserver 14 archives et compresser automatiquement les anciens fichiers. Livrable attendu : Fournir un fichier de configuration logrotate adapté au chemin /var/log/myapp/*.log avec paramètres cohérents.

Contexte : Un serveur Linux héberge des machines virtuelles nécessitant un accès direct au réseau local. Le Problème : Les machines virtuelles ne reçoivent pas d’adresse IP du réseau principal. Contraintes : Configurer un bridge réseau via netplan ou /etc/network/interfaces selon la distribution. Livrable attendu : Proposer une configuration réseau permettant aux VM d’obtenir une adresse IP via le réseau local grâce à un bridge fonctionnel.

Contexte : Un serveur doit autoriser uniquement les ports 22, 80 et 443 tout en bloquant tout autre trafic entrant. Le Problème : Les règles actuelles disparaissent après redémarrage ou sont trop permissives. Contraintes : Utiliser iptables ou firewalld selon la distribution et assurer la persistance des règles. Livrable attendu : Proposer un ensemble de commandes permettant de configurer un firewall restrictif et durable après reboot.

Contexte : Une équipe DevOps souhaite autoriser un utilisateur à redémarrer uniquement le service nginx. Le Problème : Donner un accès sudo complet serait trop risqué. Contraintes : Modifier le fichier sudoers via visudo pour permettre uniquement l’exécution de "systemctl restart nginx". Livrable attendu : Proposer la ligne sudoers exacte permettant à "deployuser" d’exécuter cette commande sans mot de passe tout en interdisant les autres privilèges.

Contexte : Une équipe d’exploitation souhaite permettre à un développeur de redémarrer uniquement le service nginx en production. Le Problème : Donner un accès sudo complet représenterait un risque de sécurité important. Contraintes : Modifier le fichier sudoers via visudo afin d’autoriser exclusivement la commande "systemctl restart nginx". Aucun autre privilège ne doit être accordé. Livrable attendu : Fournir la ligne exacte à ajouter dans sudoers pour l’utilisateur "deployuser", en respectant la bonne syntaxe et le principe du moindre privilège.

Contexte : Un service personnalisé fonctionne manuellement mais ne démarre pas après reboot. Le Problème : systemctl enable semble activé mais le service reste inactif au démarrage. Contraintes : Vérifier les dépendances systemd, les targets et les permissions associées. Livrable attendu : Décrire une méthodologie complète pour analyser et corriger le problème de démarrage automatique du service.

Contexte : Un serveur Linux en production présente des ralentissements et une utilisation mémoire élevée. Le Problème : Il n’est pas clair si la saturation provient d’un processus spécifique ou du cache système. Contraintes : Utiliser uniquement des outils natifs comme free, top, vmstat et ps. Livrable attendu : Décrire une méthodologie d’analyse étape par étape pour identifier la cause principale de la saturation mémoire et proposer des actions correctives adaptées.

Contexte : Un serveur exposé sur Internet autorise encore la connexion SSH directe en root. Le Problème : Cette configuration augmente significativement la surface d’attaque. Contraintes : Désactiver le login root et appliquer la modification sans perdre l’accès distant. Livrable attendu : Indiquer les modifications nécessaires dans sshd_config, la procédure sécurisée de rechargement du service et la vérification post-configuration.

Contexte : Un serveur multi-utilisateurs doit limiter l’espace disque utilisé par chaque compte. Le Problème : Aucun mécanisme de quota n’est activé et certains utilisateurs saturent le stockage. Contraintes : Activer les quotas sur le système de fichiers existant et définir une limite de 1 Go pour un utilisateur spécifique. Livrable attendu : Décrire les étapes nécessaires pour activer les quotas, générer les fichiers aquota et définir les limites utilisateur.

Contexte : Un serveur doit monter automatiquement un partage NFS distant utilisé pour les sauvegardes quotidiennes. Le Problème : Après redémarrage, le montage échoue et bloque parfois le boot lorsque le serveur NFS est temporairement indisponible. Contraintes : Configurer /etc/fstab avec des options adaptées garantissant la persistance et la tolérance aux pannes réseau. Livrable attendu : Proposer une entrée fstab complète incluant les options recommandées (comme _netdev ou nofail) afin d’assurer un montage robuste.

Contexte : Un serveur doit monter automatiquement un partage NFS distant pour stocker des sauvegardes. Le Problème : Le montage manuel fonctionne mais disparaît après redémarrage. Contraintes : Ajouter une entrée correcte dans /etc/fstab sans bloquer le boot si le serveur NFS est temporairement indisponible. Livrable attendu : Fournir une ligne fstab robuste incluant les options recommandées pour un montage NFS fiable et persistant.

Contexte : Un serveur est accessible via SSH avec authentification par mot de passe. Le Problème : Cette méthode expose le serveur aux attaques par brute force. Contraintes : Mettre en place une authentification par clé publique et désactiver l’authentification par mot de passe sans perdre l’accès distant. Livrable attendu : Décrire les étapes complètes incluant génération de clé, copie sur le serveur et modification sécurisée de sshd_config.

Contexte : Une application critique tourne sur un serveur Linux unique en production. Le Problème : Toute panne matérielle ou logicielle entraîne une interruption totale du service. Contraintes : Concevoir une architecture avec deux serveurs Linux, mécanisme de failover automatique (ex: keepalived ou pacemaker) et IP virtuelle partagée. Aucune modification du code applicatif. Livrable attendu : Proposer une architecture complète incluant synchronisation des données, gestion d’IP virtuelle et stratégie de bascule automatique en cas de panne.

Contexte : Une application distribuée subit des ralentissements intermittents liés au réseau. Le Problème : Il est difficile d’identifier si la latence provient du serveur local ou d’un maillon intermédiaire. Contraintes : Utiliser uniquement des outils Linux natifs comme ss, netstat, tcpdump, traceroute et ip. Livrable attendu : Décrire une méthodologie complète d’audit réseau permettant d’identifier l’origine précise des problèmes de latence.

Contexte : Une équipe déploie régulièrement une application sur plusieurs serveurs Linux. Le Problème : Les déploiements manuels créent des incohérences entre environnements. Contraintes : Concevoir un script bash idempotent garantissant un état final cohérent même en cas d’exécution multiple. Livrable attendu : Décrire la structure d’un script robuste incluant vérifications préalables, gestion d’erreurs et journalisation.

Contexte : Un serveur doit assurer la tolérance aux pannes disque pour des données critiques. Le Problème : Aucun mécanisme de redondance n’est actuellement configuré. Contraintes : Mettre en place un RAID logiciel (mdadm) avec surveillance et alertes en cas de défaillance. Livrable attendu : Décrire les étapes d’installation, configuration RAID 1 et mise en place d’un monitoring automatique.

Contexte : Un service en production consomme progressivement toute la mémoire disponible après plusieurs heures de fonctionnement. Le Problème : Le redémarrage temporaire règle le problème, mais la cause racine n’est pas identifiée. Contraintes : Utiliser uniquement des outils Linux natifs comme top, pmap, smem, vmstat et /proc sans modifier le code. Livrable attendu : Décrire une méthodologie détaillée pour identifier une fuite mémoire et isoler le processus responsable avec preuves chiffrées.

Contexte : Un serveur Linux héberge plusieurs services accessibles publiquement. Le Problème : La configuration actuelle présente des failles potentielles (SSH ouvert, services inutiles actifs, firewall permissif). Contraintes : Mettre en place un plan de hardening incluant configuration SSH sécurisée, firewall restrictif, désactivation des services inutiles et configuration fail2ban. Livrable attendu : Proposer une stratégie complète de sécurisation avec commandes clés et justification des choix techniques.

Contexte : Une application critique doit être isolée pour éviter qu’elle consomme toutes les ressources système. Le Problème : En cas de pic d’activité, elle impacte les autres services. Contraintes : Utiliser cgroups et namespaces Linux pour limiter CPU et mémoire sans utiliser Docker. Livrable attendu : Proposer une stratégie d’isolation basée sur cgroups avec limitation précise des ressources.

Contexte : Un serveur arrive à saturation disque et doit être étendu sans interruption majeure. Le Problème : Le partitionnement actuel ne permet pas d’extension flexible. Contraintes : Migrer vers LVM, ajouter un nouveau disque et étendre le volume logique existant. Livrable attendu : Décrire les étapes complètes permettant l’ajout d’un disque, la création d’un volume group et l’extension du système de fichiers.

Contexte : Plusieurs serveurs Linux doivent centraliser leurs logs sur une machine dédiée. Le Problème : Les journaux restent locaux et compliquent l’analyse d’incidents distribués. Contraintes : Configurer rsyslog pour transmettre les logs à un serveur central tout en conservant les logs locaux. Livrable attendu : Proposer une configuration complète permettant l’envoi sécurisé des logs vers un serveur centralisé.

Contexte : Un serveur Linux reçoit plusieurs milliers de requêtes par seconde et montre des signes de saturation. Le Problème : Les paramètres système par défaut limitent les performances réseau et la gestion des fichiers ouverts. Contraintes : Ajuster sysctl (net.core, fs.file-max), limites ulimit et paramètres kernel sans compromettre la stabilité. Livrable attendu : Proposer une stratégie complète d’optimisation système incluant réglages noyau, gestion des descripteurs de fichiers et validation des performances.