Aller au contenu principal

Questions de révision

Essayer de répondre avant de lire les corrections.

Questions​

  1. Quelle différence entre Restart=on-failure et enable ?
  2. Un stop volontaire déclenche-t-il Restart=always ?
  3. Pourquoi réinitialiser ExecStart dans un drop-in ?
  4. Que fait sudo tee que sudo echo suivi de > ne garantit pas ?
  5. nsenter --mount reproduit-il toutes les protections d’un service ?
  6. Quelle différence entre StateDirectory et RuntimeDirectory ?
  7. Que compte StartLimitBurst : uniquement les relances ?
  8. Un port LISTEN prouve-t-il qu’une application répond depuis une autre machine ?
  9. Que signifient Local Address et Peer Address dans ss ?
  10. Pourquoi louis ne pouvait-il pas lire le dossier 0750 de labdemo ?

Corrections​

  1. Restart relance après panne ; enable configure l’activation au démarrage.
  2. Non, un arrêt demandé avec systemctl stop ne déclenche pas la relance.
  3. Pour effacer la commande héritée avant de définir la nouvelle.
  4. Avec sudo tee, le programme qui ouvre le fichier possède les droits administrateur ; > est exécuté par le shell courant.
  5. Non : la vue des montages seule est reprise, pas automatiquement l’utilisateur, NoNewPrivileges, seccomp ou SELinux.
  6. StateDirectory conserve les données ; RuntimeDirectory est supprimé à l’arrêt par défaut et recréé au démarrage.
  7. Tous les démarrages concernés, y compris les démarrages manuels.
  8. Non : vérifier aussi réseau, pare-feu et réponse applicative.
  9. Local désigne la machine où ss est exécuté ; Peer désigne l’autre extrémité.
  10. Aucun droit pour les autres comptes ; sudo d’une commande ne s’applique pas à la suivante.

Révisions historiques conservées​

7. Questions de révision​

Essayer de répondre avant de consulter les corrections.

  1. Quelle différence entre QEMU/KVM et libvirt ?
  2. Que fait systemctl enable --now ?
  3. Les avertissements IOMMU et SEV/TDX bloquent-ils nos VM Linux ordinaires ?
  4. Depuis Fedora physique, peut-on joindre le SSH d’une VM qui écoute uniquement sur 127.0.0.1:22 ?
  5. Une clé publique autorisée change-t-elle la réponse précédente ?
  6. Dans la VM, que vise ssh louis@127.0.0.1 ? La connexion est-elle automatiquement authentifiée ?
  7. 0.0.0.0:22 signifie-t-il que tous les utilisateurs peuvent se connecter ?
  8. Pourquoi ss affiche-t-il systemd sur le port de Cockpit ?
  9. cockpit.service inactif et cockpit.socket active : est-ce incohérent ?
  10. Comment retrouver les journaux d’un service pour le démarrage actuel ?

8. Corrections​

  1. QEMU/KVM exécute la VM avec accélération matérielle ; libvirt fournit sa gestion et celle des ressources associées.
  2. Configure l’activation au démarrage et active immédiatement l’unité.
  3. Non. Ces mécanismes servent à des usages particuliers qui ne sont pas requis dans cet exemple.
  4. Non, pas directement via l’adresse réseau de la VM : l’écoute est limitée à sa boucle locale.
  5. Non. La clé intervient lors de l’authentification, après établissement de la connexion.
  6. Son propre serveur SSH, sur le port 22 par défaut en l’absence de configuration contraire. Il faut encore s’authentifier ; la clé privée du Fedora physique n’est pas automatiquement présente dans la VM.
  7. Non. Cela définit les adresses locales d’écoute IPv4, pas les autorisations d’accès.
  8. Systemd possède la socket et peut démarrer Cockpit à la demande.
  9. Non. C’est un état normal possible avant une connexion avec l’activation par socket.
  10. Avec journalctl -u NOM.service -b, en ajoutant sudo si nécessaire pour l’accès aux journaux.