LFCS : compétences essentielles

Cette page recense les compétences officielles exhaustives de la certification LFCS, telles que décrites dans le blueprint publié par la Linux Foundation. Pour chaque domaine, elle traduit ces compétences en savoir-faire concrets à démontrer en lab.

Il ne s'agit pas d'une liste fermée de commandes à mémoriser, la Linux Foundation publie un référentiel de compétences, pas une checklist d'outils imposés. L'objectif est de vous aider à identifier ce que vous devez être capable de faire le jour de l'examen.

Les 5 domaines officiels

Les pourcentages ci-dessous ne sont pas décoratifs, ils déterminent combien de tâches de chaque domaine tombent le jour J. Sur les 17 à 20 tâches de l'examen, un domaine à 25 % en représente quatre à cinq, un domaine à 10 % une ou deux. Lisez ce tableau comme un budget de révision : le temps consacré à chaque bloc devrait suivre à peu près la même répartition que les poids affichés.

Domaine	Poids
Operations and Deployment	25 %
Networking	25 %
Storage	20 %
Essential Commands	20 %
Users and Groups	10 %

Operations and Deployment (25 %)

Ce domaine couvre la gestion du système au quotidien : processus, services, planification, paquets, récupération après incident, virtualisation, conteneurs et contrôle d'accès obligatoire.

Compétences officielles

Les huit intitulés ci-dessous traduisent les objectifs publiés par la Linux Foundation. Ils sont formulés en verbes d'action parce que l'examen note un état système obtenu, jamais une méthode. Repérez les verbes doubles du type « gérer et dépanner » : ils annoncent des tâches où le service est déjà en panne au départ et où votre premier geste sera de lire un journal, pas d'écrire une configuration.

Configurer des paramètres noyau, persistants et non persistants
Diagnostiquer, identifier, gérer et dépanner des processus et des services
Gérer ou planifier des jobs exécutant des commandes
Rechercher, installer, valider et maintenir des paquets logiciels ou des dépôts
Récupérer un système après une panne matérielle, OS ou filesystem
Gérer des machines virtuelles avec libvirt
Configurer un moteur de conteneurs, créer et gérer des conteneurs
Créer et faire respecter du contrôle d'accès obligatoire avec SELinux

Ce que cela implique concrètement

Servez-vous de ce découpage comme d'une grille d'auto-évaluation plutôt que comme d'un cours. Pour chaque puce, posez-vous une seule question : sauriez-vous l'exécuter sans documentation, puis vérifier le résultat par une commande de contrôle ? Une compétence que vous comprenez sans l'avoir jamais tapée compte comme un manque, le format performance-based ne note que l'état de la machine à la fin du temps imparti.

Paramètres noyau :

Être capable de modifier un paramètre noyau de façon éphémère et de façon persistante
Savoir où déposer une configuration persistante et comment l'appliquer sans reboot
Exemples de paramètres fréquents : forwarding IP, taille des buffers réseau, limites système

Processus et services :

Savoir lister les processus, identifier celui qui consomme le plus de CPU ou de mémoire
Interrompre un processus proprement, puis de façon forcée si nécessaire
Gérer les tâches en arrière-plan d'un shell
Modifier la priorité d'un processus en cours d'exécution
Démarrer, arrêter, activer un service, comprendre la différence entre un service actif et un service activé au démarrage
Diagnostiquer un service qui ne démarre pas : lire les journaux, identifier la cause, corriger et vérifier

Planification :

Créer une tâche récurrente qui s'exécute selon un calendrier
Créer une tâche unique différée
Connaître les deux mécanismes principaux de planification sous Linux (cron et timers systemd)
Savoir vérifier qu'une tâche planifiée est bien en place

Paquets et dépôts :

Installer, supprimer et rechercher des paquets, sur les familles Debian et RHEL
Identifier quel paquet fournit un fichier ou une commande donnée
Gérer un dépôt de paquets : ajouter, désactiver, vérifier

Récupération système :

Accéder au mode rescue ou urgence via le chargeur de démarrage
Réparer un filesystem corrompu (non monté)
Régénérer la configuration du chargeur de démarrage
Investiguer les journaux du boot précédent

Virtualisation libvirt :

Lister les VMs, démarrer, arrêter proprement, arrêter de force
Créer une VM à partir d'un fichier de définition
Configurer le démarrage automatique d'une VM
Accéder à la console d'une VM
Cloner une VM existante

Conteneurs :

Lancer un conteneur en arrière-plan, exposer un port
Inspecter un conteneur, exécuter une commande à l'intérieur
Arrêter et supprimer un conteneur
Générer un service système à partir d'un conteneur existant
L'outil dépend de la distribution, les compétences sont les mêmes quel que soit le moteur

SELinux :

Vérifier le mode courant (enforcing, permissive, disabled)
Afficher et modifier le contexte SELinux d'un fichier
Appliquer un contexte permanent pour un répertoire personnalisé
Activer un boolean SELinux de manière persistante
Autoriser un port non standard pour un service
Diagnostiquer un refus SELinux : lire les logs d'audit, identifier la cause, appliquer la correction

Pièges fréquents

Ces quatre erreurs partagent le même mode d'échec : la commande retourne un code 0, aucune sortie ne signale d'anomalie, et la tâche est quand même comptée fausse. C'est ce qui coûte le plus cher en examen pratique, puisque rien ne vous alerte. La parade est mécanique : après chaque modification, relisez l'état persistant écrit sur disque, jamais seulement l'état courant en mémoire.

Modifier un paramètre noyau ou un boolean SELinux sans le rendre persistant, l'effet est perdu au reboot
Désactiver SELinux au lieu de le gérer, la LFCS exige de travailler en mode enforcing
Utiliser chcon seul sans semanage fcontext, le contexte sera écrasé au prochain relabel
Oublier daemon-reload après une modification de unit systemd

Networking (25 %)

Ce domaine couvre l'ensemble de la pile réseau : adressage, résolution de noms, synchronisation du temps, monitoring, SSH serveur et client, filtrage/NAT, routage, agrégation d'interfaces et proxy inverse.

Compétences officielles

Le réseau pèse autant que les opérations, et son périmètre est le plus étendu du blueprint : il part de l'adressage d'une interface pour aller jusqu'à la mise en place d'un proxy inverse. Les points 5 à 8 sont ceux que la plupart des candidats découvrent le jour de l'examen, car filtrage, NAT, bonding et répartition de charge sortent du périmètre d'un poste de travail ou d'un serveur applicatif classique.

Configurer IPv4 et IPv6 ainsi que la résolution de noms
Régler et synchroniser l'heure avec des serveurs de temps
Superviser et dépanner le réseau
Configurer le serveur et le client OpenSSH
Configurer le filtrage de paquets, la redirection de ports et le NAT
Configurer du routage statique
Configurer bridge et bonding
Mettre en œuvre des reverse proxies et load balancers

Ce que cela implique concrètement

La plupart des blocs ci-dessous exigent deux machines pour être travaillés sérieusement, sinon vous ne verrez jamais échouer ce qui doit échouer. Une règle de filtrage ne se teste pas depuis la machine qu'elle protège, et une route statique n'a de sens que vers une destination injoignable autrement. Montez un lab à deux VM avant d'attaquer cette liste, sans quoi la vérification restera théorique.

Adressage et résolution :

Afficher et modifier la configuration IP d'une interface, IPv4 et IPv6
Rendre une configuration réseau persistante selon le mécanisme de la distribution
Modifier le hostname de façon persistante
Configurer la résolution de noms locale et les serveurs DNS

Synchronisation du temps :

Vérifier la synchronisation NTP courante
Modifier les serveurs NTP de référence et redémarrer le service
S'assurer que la synchronisation est active et persistante

Monitoring réseau :

Tester la connectivité de base (ICMP, traceroute)
Identifier les ports en écoute et les processus associés
Résoudre un nom de domaine et diagnostiquer un problème DNS
Capturer du trafic réseau pour analyse
Tester une connexion HTTP/HTTPS

OpenSSH serveur et client :

Générer une paire de clés et déployer la clé publique sur un serveur distant
Configurer le serveur SSH : modifier le port, désactiver l'authentification par mot de passe, interdire la connexion root directe
Appliquer les changements sans couper les sessions actives
Configurer des raccourcis de connexion côté client

Filtrage, NAT, redirection de ports :

Ouvrir un port précis pour un service, de façon permanente
Appliquer les règles, savoir qu'une règle non appliquée n'est pas active
Configurer le NAT masquerade pour permettre à un réseau interne de sortir
Configurer une redirection de port (port forwarding)
Le blueprint ne prescrit pas un outil de firewall précis, les compétences sont les mêmes quel que soit l'outil

Routage statique :

Ajouter une route statique éphémère
Rendre une route statique persistante
Vérifier la table de routage

Bridge et bonding :

Créer un bridge Linux et y attacher des interfaces
Créer une interface bonding avec un mode d'agrégation (active-backup, balance-rr…)
Vérifier le fonctionnement de l'agrégation

Reverse proxy et load balancer :

Mettre en place un proxy inverse qui redirige le trafic vers un backend
Configurer un mécanisme de répartition de charge entre plusieurs backends
Vérifier la syntaxe de la configuration et appliquer sans interruption

Pièges fréquents

Le réseau ajoute un risque que les autres domaines n'ont pas : une configuration erronée peut vous couper de la machine en cours de manipulation. Prenez le réflexe de garder une console locale ou une session déjà ouverte avant de toucher une interface ou une règle de filtrage. Sur le fond, les points ci-dessous reviennent tous à confondre une modification appliquée en mémoire et une modification enregistrée dans un fichier.

Configurer une adresse IP ou un firewall sans persistance, tout disparaît au reboot
Oublier de recharger les règles de firewall après les avoir créées en mode permanent
Centrer sa préparation sur nmcli ou ufw uniquement, sans maîtriser ip comme dénominateur commun
Ignorer la configuration serveur SSH, le blueprint couvre explicitement le serveur, pas seulement le client
Ne pas pratiquer bridge/bonding et reverse proxy, ces sujets figurent dans le blueprint et sont souvent négligés

Storage (20 %)

Ce domaine couvre la gestion complète du stockage : volumes logiques, systèmes de fichiers locaux et distants, montages persistants, swap, montages automatiques et performance.

Compétences officielles

Le stockage est le domaine le plus mécanique du blueprint : les tâches y sont longues mais rarement ambiguës, parce qu'elles suivent presque toujours la même chaîne d'opérations (repérer le périphérique, découper, formater, monter, persister). Deux compétences échappent à cette logique et demandent une machine en face : les filesystems distants (point 4) et les automounters (point 6).

Configurer et gérer du stockage LVM
Gérer et configurer le virtual file system
Créer, gérer et dépanner des filesystems
Utiliser des filesystems distants et des network block devices
Configurer et gérer le swap
Configurer des automounters
Superviser les performances de stockage

Ce que cela implique concrètement

Le fil conducteur de tout ce domaine est l'ordre des opérations. Une tâche de stockage réussie enchaîne création, formatage, montage puis persistance, et sauter la dernière étape suffit à perdre l'intégralité des points. Repérez au passage les commandes de contrôle qui reviennent partout, lsblk, blkid et findmnt : elles constituent votre seule preuve que l'état demandé est réellement atteint.

LVM :

Créer un Physical Volume, un Volume Group et un Logical Volume
Étendre un Volume Group en ajoutant un disque
Étendre un Logical Volume et redimensionner le filesystem en conséquence (ext4 et xfs)
Supprimer un Logical Volume
Savoir que resize2fs fonctionne offline ou online, tandis que xfs_growfs ne fonctionne que sur un FS monté

Virtual file system et filesystems :

Identifier les disques et partitions disponibles
Créer et formater des partitions (ext4, xfs, vfat)
Diagnostiquer un filesystem corrompu et le réparer (non monté)
Trouver l'UUID d'un block device

Montages persistants :

Monter un filesystem de façon éphémère
Rendre un montage persistant via /etc/fstab, toujours avec UUID, jamais avec /dev/sdX
Vérifier la cohérence de /etc/fstab et tester sans reboot

Filesystems distants et network block devices :

Monter un partage NFS de façon persistante ; sous systemd, le type de filesystem suffit à classer le montage comme réseau, _netdev ne fait que forcer cette détection
Monter un partage CIFS avec un fichier de credentials séparé
Découvrir et se connecter à une cible iSCSI, et là _netdev devient indispensable : un network block device n'est pas reconnu comme réseau à partir de son type de filesystem

Swap :

Créer une partition swap ou un fichier swap
Activer le swap et le rendre persistant

Automounters :

Configurer autofs pour monter un partage à la demande
Comprendre la relation entre /etc/auto.master et les fichiers de map
Vérifier que le montage dynamique fonctionne

Performance stockage :

Identifier quel disque ou quel processus provoque des I/O excessives
Mesurer le débit brut d'un disque
Surveiller l'utilisation de l'espace en temps réel

Pièges fréquents

Trois de ces quatre erreurs ne se révèlent qu'au redémarrage, donc bien trop tard dans un examen chronométré. Rendez la détection immédiate : après toute édition de /etc/fstab, enchaînez findmnt --verify puis mount -a. La première contrôle la cohérence du fichier sans rien monter, la seconde rejoue les entrées manquantes et échoue bruyamment sur une entrée invalide, ce qui vous évite de découvrir le problème après un reboot.

Utiliser /dev/sdX au lieu de l'UUID dans /etc/fstab, les noms de devices peuvent changer
Oublier _netdev sur un montage posé au-dessus d'un network block device (iSCSI, NBD) : systemd ne peut pas deviner qu'il dépend du réseau à partir du type de filesystem, le montage échoue au boot
Étendre un LV sans redimensionner le filesystem, l'espace supplémentaire reste invisible
Ne pas pratiquer autofs, le montage dynamique est spécifique et se maîtrise uniquement par la pratique

Essential Commands (20 %)

Ce domaine couvre des compétences transversales qui ne se résument pas à de la navigation de fichiers. Il évalue la capacité à utiliser Git, à créer et dépanner des services, à surveiller la performance, à identifier les contraintes d'une application, à diagnostiquer les problèmes d'espace disque et à travailler avec les certificats SSL/TLS.

Compétences officielles

Le nom du domaine induit en erreur : « Essential Commands » ne désigne plus les commandes de base du shell mais un ensemble de compétences transversales que la Linux Foundation n'a pas voulu rattacher aux quatre autres blocs. Git et les certificats SSL/TLS y côtoient le diagnostic de performance et l'espace disque. Traitez chacun des six points comme un mini-domaine autonome, ils n'ont aucun outil en commun.

Basic Git Operations
Créer, configurer et dépanner des services
Superviser et dépanner la performance système et les services
Déterminer les contraintes spécifiques à une application ou un service
Dépanner les problèmes d'espace disque
Travailler avec les certificats SSL

Ce que cela implique concrètement

Les blocs de ce domaine se travaillent sur une seule machine et sans matériel particulier, ce qui en fait le meilleur point de départ si vous manquez de temps ou de lab. Priorisez dans cet ordre : diagnostic de service, espace disque, certificats, puis Git. Les trois premiers sont ceux où une tâche mal comprise vous coûte plusieurs minutes de recherche à l'aveugle, alors que les opérations Git demandées restent volontairement basiques.

Git :

Initialiser un dépôt local, cloner un dépôt distant
Indexer des fichiers, créer un commit avec un message, consulter l'historique
Créer une branche, basculer dessus, fusionner
Mettre de côté des modifications en cours (stash)
Gérer un dépôt distant : ajouter, pousser, tirer
Configurer l'identité Git (nom, email), souvent nécessaire avant le premier commit

Services :

Écrire un unit file systemd minimal fonctionnel
Diagnostiquer un service en état failed : lire les journaux, identifier l'erreur, corriger, recharger et vérifier
Appliquer une modification de unit sans redémarrage du daemon complet

Performance et monitoring :

Identifier quel processus consomme le plus de CPU, de mémoire ou d'I/O
Surveiller le load average et la mémoire disponible
Utiliser des outils de monitoring en continu (rafraîchissement par intervalle)
Lire un rapport de performance historique (si sysstat est disponible)

Contraintes applicatives :

Afficher les limites effectives du shell courant ou d'un processus spécifique
Identifier les limites imposées à un service systemd
Trouver les fichiers ouverts par un processus
Modifier un paramètre noyau qui contraint le comportement d'un service

Espace disque :

Identifier quel filesystem est plein et quel répertoire en est la cause
Trouver les fichiers volumineux d'un filesystem
Détecter les fichiers supprimés mais toujours ouverts par un processus, cause fréquente de "disque plein" invisible
Vérifier les inodes disponibles (un filesystem peut être "plein" avec de l'espace libre si les inodes sont épuisés)
Nettoyer les journaux système trop volumineux

Certificats SSL/TLS :

Générer une clé privée et une demande de certificat (CSR)
Créer un certificat auto-signé
Inspecter un certificat existant : dates de validité, sujet, émetteur
Tester une connexion TLS vers un serveur distant
Vérifier la chaîne de confiance d'un certificat
Installer un certificat d'autorité sur le système, la procédure diffère selon la distribution

Pièges fréquents

Le piège principal de ce domaine est un malentendu sur son nom, et il conduit à ne pas le réviser du tout. Les quatre points suivants découlent tous de cette impasse initiale : un candidat qui lit « commandes essentielles » comme « ls, cd, grep » arrive à l'examen sans avoir ouvert openssl ni diagnostiqué un service en état failed, alors que ce bloc pèse 20 % du score.

Considérer ce domaine comme "les commandes de base Linux", ce n'est plus le cas depuis la refonte du blueprint
Négliger Git, il représente une compétence officielle à part entière
Ne pas savoir diagnostiquer un service failed au-delà de la lecture de status
Ignorer lsof +L1 pour les problèmes de disque plein sans fichiers visibles
Ne pas savoir manipuler de certificats SSL, ce sujet est explicitement dans le blueprint

Users and Groups (10 %)

C'est le domaine le moins pondéré, mais il contient des compétences précises qui ne s'improvisent pas le jour J, notamment les ACL, les profils d'environnement et l'intégration LDAP.

Compétences officielles

Ces cinq intitulés vont du très courant au très rarement pratiqué, et l'écart est brutal : créer un compte local est un geste quotidien, brancher le système sur un annuaire LDAP ne l'est pas. Le poids de 10 % ne doit pas vous tromper sur l'effort à fournir : les points 4 et 5, ACL et LDAP, demandent à eux seuls plus de préparation que les trois premiers réunis.

Créer et gérer des comptes utilisateurs et groupes locaux
Gérer des profils d'environnement personnels et système
Configurer des limites de ressources utilisateur
Configurer et gérer des ACL
Configurer le système pour utiliser des comptes utilisateurs et groupes LDAP

Ce que cela implique concrètement

Deux compétences de cette liste se vérifient autrement que par la lecture d'un fichier de configuration. Pour les ACL, la preuve est getfacl sur la cible, pas l'affichage de ls -l. Pour LDAP, la preuve est getent passwd <utilisateur> qui renvoie une ligne, pas le fait que le service d'annuaire tourne. Repérez ces commandes de contrôle en lisant les puces, ce sont elles qui font la différence entre une tâche crue faite et une tâche réellement faite.

Comptes et groupes locaux :

Créer un utilisateur avec des paramètres précis : home, shell, UID, groupe principal
Ajouter un utilisateur à un groupe secondaire sans perdre ses groupes existants
Verrouiller et déverrouiller un compte
Configurer l'expiration du mot de passe et l'expiration du compte
Créer des groupes avec un GID spécifique
Déléguer des droits via sudo avec le moindre privilège, fichiers dans /etc/sudoers.d/

Profils d'environnement :

Comprendre la différence entre /etc/profile, /etc/profile.d/, ~/.bash_profile, ~/.bashrc et /etc/environment
Savoir où ajouter une variable d'environnement pour qu'elle soit disponible pour tous les utilisateurs ou pour un seul
Savoir appliquer un changement de profil sans déconnexion

Limites de ressources :

Afficher les limites courantes d'un shell ou d'un processus
Configurer des limites permanentes (fichiers ouverts, nombre de processus…)
Identifier et modifier les limites d'un service systemd

ACL :

Ajouter une permission à un utilisateur ou un groupe spécifique sur un fichier ou répertoire
Définir des ACL par défaut pour qu'elles soient héritées par les nouveaux fichiers
Supprimer des ACL ciblées ou réinitialiser toutes les ACL
Vérifier qu'un filesystem supporte les ACL
Reconnaître la présence d'ACL dans la sortie de ls -l (indicateur +)

LDAP :

Configurer le système pour résoudre les comptes utilisateurs et groupes depuis un serveur LDAP
Vérifier que l'utilisateur LDAP est bien résolu localement
Comprendre le rôle de nsswitch.conf dans l'ordre de résolution
S'assurer que le service d'authentification est activé et persistant
Configurer la création automatique du home directory à la première connexion
Les outils diffèrent selon la distribution, les compétences sous-jacentes sont identiques

Pièges fréquents

La première erreur de cette liste est destructive et silencieuse : elle retire des groupes à un compte sans le moindre avertissement, et vous ne vous en apercevez qu'au refus d'accès suivant. Prenez l'habitude de relever les groupes courants avec id <utilisateur> avant toute modification, puis de comparer après coup. Les trois autres points sont des omissions plutôt que des destructions, mais elles coûtent les mêmes points.

Utiliser usermod -G au lieu de usermod -aG, sans le -a, les groupes secondaires existants sont écrasés
Ne pas comprendre la différence entre les fichiers de profil login et non-login
Oublier que les ACL nécessitent un support filesystem adapté
Ignorer LDAP dans la préparation, c'est un sujet officiel

Compétences souvent sous-estimées

Ces sujets figurent dans le blueprint mais sont fréquemment absents des révisions. Chacun d'eux peut représenter une ou plusieurs tâches le jour J.

Compétence	Domaine	Pourquoi c'est sous-estimé
SELinux	Opérations	Beaucoup le désactivent au quotidien, mais la LFCS exige de le gérer en enforcing
libvirt / KVM	Opérations	Peu pratiqué en dehors d'un lab dédié
Conteneurs	Opérations	Le moteur dépend de la distro, il faut maîtriser le concept, pas juste un outil
OpenSSH serveur	Réseau	Les candidats préparent le client, pas la configuration du serveur
NAT / redirection de ports	Réseau	Plus complexe qu'ouvrir un simple port
Bridge / bonding	Réseau	Rarement utilisé au quotidien, mais dans le blueprint
Automounters	Stockage	`autofs` se maîtrise uniquement par la pratique
LDAP	Utilisateurs	Exige un serveur LDAP pour s'entraîner
Proxy inverse / load balancer	Réseau	Souvent considéré comme "hors scope sysadmin"
SSL/TLS	Commandes essentielles	Manipuler des certificats demande de la pratique
Synchronisation NTP	Réseau	Souvent négligé car "ça marche tout seul"
Paramètres noyau persistants	Opérations	Savoir modifier `sysctl` ne suffit pas, il faut rendre la modification permanente

Réflexes de préparation

Ces principes sont transversaux à tous les domaines.

Toujours distinguer temporaire et persistant :

Chaque modification qui doit survivre à un reboot nécessite une action explicite de persistance. Si vous ne savez pas comment rendre un changement permanent, vous ne maîtrisez pas encore la compétence.

Toujours vérifier le résultat après modification :

Configurer ne suffit pas. Après chaque action, vérifier l'état avec une commande de contrôle : systemctl status, ip addr, findmnt, ss -tulpn, getenforce, firewall-cmd --list-all…

Savoir diagnostiquer, pas seulement configurer :

Le blueprint demande explicitement de dépanner, pas seulement de configurer. Vous devez savoir identifier la cause d'un problème, lire des journaux, interpréter un message d'erreur et corriger.

Ne pas réviser uniquement son quotidien :

Si votre environnement est centré Debian, vous n'avez probablement jamais touché à SELinux, firewalld ou authselect. Si votre environnement est centré RHEL, vous n'avez peut-être jamais configuré netplan ou ufw. Le blueprint est vendor-neutral, entraînez-vous sur les sujets hors de votre zone de confort.

Entraîner les sujets rares du blueprint :

libvirt, conteneurs, bridge/bonding, autofs, LDAP et reverse proxy font partie de l'examen. Ce sont des compétences qui se maîtrisent en lab, pas en relisant une page de documentation.

Utiliser les ressources autorisées :

Pendant l'examen, vous avez accès à man, --help, info et /usr/share/doc. Apprenez à les consulter efficacement, savoir trouver rapidement la bonne option dans une page man fait gagner un temps précieux.

À retenir

La LFCS évalue des compétences, pas la mémorisation de commandes, le blueprint décrit ce que vous devez savoir faire.
Les domaines Réseau et Opérations représentent 50 % du score, ce sont les blocs à maîtriser en priorité.
Chaque modification doit être vérifiée : configurer → vérifier → persister → vérifier après reboot.
Le blueprint est vendor-neutral : l'examen n'est plus lié à une distribution particulière, mais il faut connaître les mécanismes communs à toutes.
Les sujets souvent négligés sont aussi les plus discriminants : SELinux, libvirt, conteneurs, reverse proxy, LDAP, bridge/bonding.
Les quotas disque ne figurent pas dans le blueprint LFCS actuel.
Les prérequis Linux (navigation, permissions, édition avec vi) sont implicites mais indispensables.
L'entraînement en lab réel est irremplaçable, relire une page de commandes ne suffit pas.