EnglishCommencer

Les fichiers de configuration

Où vivent les réglages d'un système et d'un utilisateur, les formats courants (clé=valeur, INI, YAML, JSON), l'ordre de priorité des sources et la nécessité de recharger le service.

  • 24 cartes
  • 4 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Fichier de configuration : de quoi s'agit-il ?

    Voir la réponse

    Fichier texte qui garde les réglages d'un programme, lu au lancement pour décider de son comportement sans modifier le programme lui-même.

    Sous Linux, ceux du système vivent dans /etc et ceux d'un utilisateur dans son répertoire personnel. Une erreur de syntaxe dans l'un peut empêcher le programme de démarrer.

  • ls n'affiche pas le fichier .bashrc du répertoire personnel. Quelle commande le montre ?

    • ls -a
    • ls -l
    • ls -R
    • ls -h
    Voir la réponse

    ls -a

    -a affiche tout, y compris les noms qui commencent par un point. -l ajoute des détails sans révéler les fichiers cachés, -R descend dans les sous-répertoires, -h rend les tailles lisibles.

  • Pour ajouter des réglages sans toucher au fichier principal, beaucoup de programmes lisent aussi tous les fichiers d'un répertoire dont le nom se termine par ….

    Voir la réponse

    Pour ajouter des réglages sans toucher au fichier principal, beaucoup de programmes lisent aussi tous les fichiers d'un répertoire dont le nom se termine par .d.

    Par exemple /etc/apt/sources.list.d/ à côté de /etc/apt/sources.list. Chaque fichier du répertoire apporte un morceau de configuration : un paquet peut ajouter ou retirer le sien sans réécrire un fichier partagé.

  • Fichier caché : de quoi s'agit-il ?

    Voir la réponse

    Fichier ou dossier dont le nom commence par un point, que ls n'affiche pas sans l'option -a, et que les programmes utilisent pour les réglages d'un utilisateur.

    ~/.bashrc, ~/.gitconfig et ~/.ssh/ sont dans ce cas. Le point n'est qu'une convention d'affichage : il ne protège pas le fichier.

  • Le port a été changé dans sshd_config, mais le service écoute toujours sur le port 22. Quelle cause et quelle solution sont les plus probables ?

    • Le service n'a pas relu son fichier ; le redémarrer avec systemctl
    • Le fichier n'est lu qu'au démarrage de la machine ; il faut redémarrer le système entier
    • Le fichier ~/.sshd_config de l'utilisateur prend le dessus sur celui du système ; le supprimer
    • Le port 22 est réservé à SSH ; le changer demande de recompiler le serveur
    Voir la réponse

    Le service n'a pas relu son fichier ; le redémarrer avec systemctl

    Un service garde ses réglages en mémoire depuis son lancement. Après modification, sudo systemctl restart ssh (nom du service sur Debian) les relit ; sur les Ubuntu récents, où c'est ssh.socket qui écoute, il faut sudo systemctl daemon-reload puis sudo systemctl restart ssh.socket. Redémarrer la machine marcherait, mais c'est disproportionné. Tester avec sudo sshd -t avant de redémarrer le service évite de se couper l'accès à distance.

Réviser ce deck