Procédure

1. Pour mettre à jour le noyau, entrez la commande suivante :

   # dnf update kernel

   Cette commande met à jour le noyau ainsi que toutes les dépendances vers la dernière version disponible.

2. Redémarrez votre système pour que les modifications soient prises en compte.

Procédure

1. Sélectionnez le module du noyau que vous souhaitez charger.

   Les modules sont situés dans le répertoire /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

2. Charger le module du noyau concerné :

   # modprobe <MODULE_NAME>

   Note

   Lorsque vous saisissez le nom d'un module du noyau, n'ajoutez pas l'extension .ko.xz à la fin du nom. Les noms des modules du noyau n'ont pas d'extension, mais les fichiers correspondants en ont une.

3. En option, vérifier que le module concerné a été chargé :

   $ lsmod | grep <MODULE_NAME>

   Si le module a été correctement chargé, cette commande affiche le module du noyau correspondant. Par exemple :

   $ lsmod | grep serio_raw
   serio_raw              16384  0

Procédure

1. Entrez la commande lsmod et sélectionnez un module du noyau que vous souhaitez décharger.

   Si un module du noyau a des dépendances, déchargez-les avant de décharger le module du noyau. Pour plus de détails sur l'identification des modules ayant des dépendances, voir Lister les modules du noyau actuellement chargés et Dépendances des modules du noyau.

2. Décharger le module du noyau concerné :

   # modprobe -r <MODULE_NAME>

   Lorsque vous saisissez le nom d'un module du noyau, n'ajoutez pas l'extension .ko.xz à la fin du nom. Les noms des modules du noyau n'ont pas d'extension, mais les fichiers correspondants en ont une.

   Avertissement

   Ne pas décharger les modules du noyau lorsqu'ils sont utilisés par le système en cours d'exécution. Cela peut conduire à un système instable ou non opérationnel.

3. Optionnellement, vérifier que le module concerné a été déchargé :

   $ lsmod | grep <MODULE_NAME>

   Si le module a été déchargé avec succès, cette commande n'affiche aucun résultat.

Procédure

1. Sélectionnez un module du noyau que vous souhaitez charger pendant le processus de démarrage.

   Les modules sont situés dans le répertoire /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

2. Créer un fichier de configuration pour le module :

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   Note

   Lorsque vous saisissez le nom d'un module du noyau, n'ajoutez pas l'extension .ko.xz à la fin du nom. Les noms des modules du noyau n'ont pas d'extension, mais les fichiers correspondants en ont une.

3. En option, après le redémarrage, vérifiez que le module concerné a été chargé :

   $ lsmod | grep <MODULE_NAME>

   L'exemple de commande ci-dessus devrait réussir et afficher le module du noyau concerné.

Procédure

1. Sélectionnez un module du noyau que vous souhaitez placer dans une liste de refus :

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1
   …​

   La commande lsmod affiche une liste des modules chargés dans le noyau en cours d'exécution.

   • Vous pouvez également identifier un module du noyau non chargé que vous souhaitez empêcher de se charger.

     Tous les modules du noyau sont situés dans le répertoire /lib/modules/<KERNEL_VERSION>/kernel/<SUBSYSTEM>/.

2. Créer un fichier de configuration pour une liste de deniers :

   # vim /etc/modprobe.d/blacklist.conf
   
   	# Blacklists <KERNEL_MODULE_1>
   	blacklist <MODULE_NAME_1>
   	install <MODULE_NAME_1> /bin/false
   
   	# Blacklists <KERNEL_MODULE_2>
   	blacklist <MODULE_NAME_2>
   	install <MODULE_NAME_2> /bin/false
   
   	# Blacklists <KERNEL_MODULE_n>
   	blacklist <MODULE_NAME_n>
   	install <MODULE_NAME_n> /bin/false
   	…​

   L'exemple montre le contenu du fichier blacklist.conf, édité par l'éditeur vim. La ligne blacklist garantit que le module du noyau concerné ne sera pas automatiquement chargé pendant le processus de démarrage. La commande blacklist, cependant, n'empêche pas le module d'être chargé en tant que dépendance d'un autre module du noyau qui n'est pas dans une liste de dénylage. Par conséquent, la ligne install entraîne l'exécution de la commande /bin/false au lieu de l'installation d'un module.

   Les lignes commençant par un signe dièse sont des commentaires destinés à rendre le fichier plus lisible.

   Note

   Lorsque vous saisissez le nom d'un module du noyau, n'ajoutez pas l'extension .ko.xz à la fin du nom. Les noms des modules du noyau n'ont pas d'extension, mais les fichiers correspondants en ont une.

3. Créez une copie de sauvegarde de l'image ramdisk initiale actuelle avant de la reconstruire :

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date %m-\r%H%M%S).img

   La commande ci-dessus crée une image de sauvegarde initramfs au cas où la nouvelle version aurait un problème inattendu.

   • Vous pouvez également créer une copie de sauvegarde d'une autre image initiale de ramdisk qui correspond à la version du noyau pour laquelle vous souhaitez placer des modules de noyau dans une liste de dénombrement :

     # cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date %m-\r%H%M%S)

4. Générer une nouvelle image ramdisk initiale pour refléter les changements :

   # dracut -f -v

   • Si vous construisez une image initiale de ramdisk pour une version de noyau différente de celle dans laquelle vous êtes actuellement démarré, indiquez à la fois la cible initramfs et la version du noyau :

     # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

5. Redémarrer le système :

   $ reboot

Procédure

1. Créez le fichier /root/testmodule/test.c avec le contenu suivant.

   #include <linux/module.h>
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }
   
   MODULE_LICENSE("GPL");

   Le fichier test.c est un fichier source qui fournit les principales fonctionnalités du module du noyau. Le fichier a été créé dans un répertoire /root/testmodule/ dédié à des fins d'organisation. Après la compilation du module, le répertoire /root/testmodule/ contiendra plusieurs fichiers.

   Le fichier test.c inclut les bibliothèques du système :

   • Le fichier d'en-tête linux/kernel.h est nécessaire pour la fonction printk() dans le code d'exemple.

   • Le fichier linux/module.h contient des déclarations de fonctions et des définitions de macros à partager entre plusieurs fichiers sources écrits en langage de programmation C.

     Suivez ensuite les fonctions init_module() et cleanup_module() pour démarrer et terminer la fonction d'enregistrement du noyau printk(), qui imprime du texte.

2. Créez le fichier /root/testmodule/Makefile avec le contenu suivant.

   obj-m := test.o

   Le Makefile contient des instructions selon lesquelles le compilateur doit produire un fichier objet spécifiquement nommé test.o. La directive obj-m spécifie que le fichier test.ko résultant sera compilé en tant que module de noyau chargeable. Alternativement, la directive obj-y indiquerait de compiler test.ko en tant que module de noyau intégré.

3. Compiler le module du noyau.

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'
     CC [M]  /root/testmodule/test.o
     MODPOST /root/testmodule/Module.symvers
     CC [M]  /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
     BTF [M] /root/testmodule/test.ko
   Skipping BTF generation for /root/testmodule/test.ko due to unavailability of vmlinux
   make: Leaving directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'

   Le compilateur crée un fichier objet (test.o) pour chaque fichier source (test.c) en tant qu'étape intermédiaire avant de les lier ensemble dans le module final du noyau (test.ko).

   Après une compilation réussie, /root/testmodule/ contient des fichiers supplémentaires relatifs au module de noyau personnalisé compilé. Le module compilé lui-même est représenté par le fichier test.ko.

Vérification

1. Facultatif : vérifiez le contenu du répertoire /root/testmodule/:

   # ls -l /root/testmodule/
   total 152
   -rw-r—​r--. 1 root root    16 Jul 26 08:19 Makefile
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 modules.order
   -rw-r—​r--. 1 root root     0 Jul 26 08:20 Module.symvers
   -rw-r—​r--. 1 root root   224 Jul 26 08:18 test.c
   -rw-r—​r--. 1 root root 62176 Jul 26 08:20 test.ko
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 test.mod
   -rw-r—​r--. 1 root root   849 Jul 26 08:20 test.mod.c
   -rw-r—​r--. 1 root root 50936 Jul 26 08:20 test.mod.o
   -rw-r—​r--. 1 root root 12912 Jul 26 08:20 test.o

2. Copiez le module du noyau dans le répertoire /lib/modules/$(uname -r)/:

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. Mise à jour de la liste des dépendances modulaires :

   # depmod -a

4. Charger le module du noyau :

   # modprobe -v test
   insmod /lib/modules/5.14.0-1.el9.x86_64/test.ko

5. Vérifiez que le module du noyau a été chargé avec succès :

   # lsmod | grep test
   test                   16384  0

6. Lire les derniers messages du tampon circulaire du noyau :

   # dmesg
   [74422.545004] Hello World
                   This is a test

Procédure

1. Exportez votre clé publique vers le fichier sb_cert.cer:

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. Importez votre clé publique dans la liste MOK :

   # mokutil --import sb_cert.cer

3. Saisissez un nouveau mot de passe pour cette demande d'inscription au MOK.

4. Redémarrer la machine.

   Le chargeur de démarrage shim remarque la demande d'enrôlement de la clé MOK en attente et lance MokManager.efi pour vous permettre de terminer l'enrôlement à partir de la console UEFI.

5. Choisissez Enroll MOK, saisissez le mot de passe que vous avez précédemment associé à cette demande lorsque vous y êtes invité et confirmez l'inscription.

   Votre clé publique est ajoutée à la liste MOK, qui est persistante.

   Une fois qu'une clé figure sur la liste MOK, elle est automatiquement propagée dans le trousseau .platform lors de ce démarrage et des suivants lorsque l'UEFI Secure Boot est activé.

Procédure

1. Exportez votre clé publique vers le fichier sb_cert.cer:

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. Extraire la clé de la base de données du SSN sous la forme d'un fichier PKCS #12 :

   # pk12util -o sb_cert.p12 \
              -n 'Custom Secure Boot key' \
              -d /etc/pki/pesign

3. Lorsque la commande précédente vous y invite, entrez un nouveau mot de passe qui crypte la clé privée.

4. Exporter la clé privée non chiffrée :

   # openssl pkcs12 \
            -in sb_cert.p12 \
            -out sb_cert.priv \
            -nocerts \
            -noenc

   Important

   Manipulez la clé privée non chiffrée avec précaution.

5. Signez votre module de noyau. La commande suivante ajoute la signature directement à l'image ELF dans le fichier du module du noyau :

   # /usr/src/kernels/$(uname -r)/scripts/sign-file \
             sha256 \
             sb_cert.priv \
             sb_cert.cer \
             my_module.ko

Vérification

1. Affiche des informations sur la signature du module du noyau :

   # modinfo my_module.ko | grep signer
     signer:         Your Name Key

   Vérifiez que la signature mentionne votre nom tel qu'il a été saisi lors de la génération.

   Note

   La signature annexée n'est pas contenue dans une section de l'image ELF et ne constitue pas une partie formelle de l'image ELF. Par conséquent, des utilitaires tels que readelf ne peuvent pas afficher la signature sur votre module de noyau.

2. Charger le module :

   # insmod my_module.ko

3. Retirer (décharger) le module :

   # rmmod my_module.ko

Procédure

1. Vérifiez que vos clés publiques se trouvent sur le trousseau de clés du système :

   # keyctl list %:.platform

2. Copiez le module du noyau dans le répertoire extra/ du noyau que vous voulez :

   # cp my_module.ko /lib/modules/$(uname -r)/extra/

3. Mise à jour de la liste des dépendances modulaires :

   # depmod -a

4. Charger le module du noyau :

   # modprobe -v my_module

5. En option, pour charger le module au démarrage, ajoutez-le au fichier /etc/modules-loaded.d/my_module.conf pour charger le module au démarrage :

   # echo "my_module" > /etc/modules-load.d/my_module.conf

Procédure

1. Déterminer la version actuelle de la liste de révocation :

   # fwupdmgr get-devices

   Voir le champ Current version sous UEFI dbx.

2. Activer le référentiel de listes de révocation LVFS :

   # fwupdmgr enable-remote lvfs

3. Actualiser les métadonnées du référentiel :

   # fwupdmgr refresh

4. Appliquer la mise à jour de la liste de révocation :

   • Sur la ligne de commande :

     # fwupdmgr update

   • Dans l'interface graphique :

     1. Ouvrir l'application Software
     2. Naviguez jusqu'à l'onglet Updates.
     3. Trouvez l'entrée Secure Boot dbx Configuration Update.
     4. Cliquez sur Mettre à jour.
5. À la fin de la mise à jour, fwupdmgr ou Software vous demande de redémarrer le système. Confirmez le redémarrage.

Procédure

1. Déterminer la version actuelle de la liste de révocation :

   # fwupdmgr get-devices

   Voir le champ Current version sous UEFI dbx.

2. Liste des mises à jour disponibles auprès de RHEL :

   # ls /usr/share/dbxtool/

3. Sélectionnez le fichier de mise à jour le plus récent pour votre architecture. Les noms de fichiers utilisent le format suivant :

   DBXUpdate-date-architecture.cab

4. Installer le fichier de mise à jour sélectionné :

   # fwupdmgr install /usr/share/dbxtool/DBXUpdate-date-architecture.cab

5. À la fin de la mise à jour, fwupdmgr vous demande de redémarrer le système. Confirmez le redémarrage.

Procédure

1. Sélectionnez le noyau que vous souhaitez lancer lorsque le menu de démarrage de GRUB 2 s'affiche et appuyez sur la touche e pour modifier les paramètres du noyau.
2. Trouvez la ligne de commande du noyau en déplaçant le curseur vers le bas. La ligne de commande du noyau commence par linux sur les systèmes IBM Power Series 64 bits et x86-64 basés sur le BIOS, ou par linuxefi sur les systèmes UEFI.

3. Déplacer le curseur à la fin de la ligne.

   Note

   Appuyer sur Ctrl+a pour sauter au début de la ligne et Ctrl+e pour passer à la fin de la ligne. Sur certains systèmes, les touches Home et End peuvent également fonctionner.

4. Modifiez les paramètres du noyau en fonction des besoins. Par exemple, pour faire fonctionner le système en mode d'urgence, ajoutez le paramètre emergency à la fin de la ligne linux:

1. Appuyer sur Ctrl+x pour démarrer avec le noyau sélectionné et les paramètres de ligne de commande modifiés.

Procédure

1. Ajoutez les deux lignes suivantes au fichier /etc/default/grub:

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   La première ligne désactive le terminal graphique. La clé GRUB_TERMINAL remplace les valeurs des clés GRUB_TERMINAL_INPUT et GRUB_TERMINAL_OUTPUT.

   La deuxième ligne ajuste le débit en bauds (--speed), la parité et d'autres valeurs en fonction de votre environnement et de votre matériel. Notez qu'une vitesse de transmission beaucoup plus élevée, par exemple 115200, est préférable pour des tâches telles que le suivi des fichiers journaux.

2. Mettre à jour le fichier de configuration GRUB.

   • Sur les machines basées sur le BIOS :

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • Sur les machines basées sur l'UEFI :

     # grub2-mkconfig -o /boot/grub2/grub.cfg

3. Redémarrez le système pour que les modifications soient prises en compte.

Procédure

1. Liste de tous les paramètres et de leurs valeurs.

   # sysctl -a

   Note

   La commande # sysctl -a affiche les paramètres du noyau, qui peuvent être ajustés en cours d'exécution et au démarrage.

2. Pour configurer temporairement un paramètre, entrez :

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   L'exemple de commande ci-dessus modifie la valeur du paramètre alors que le système est en cours d'exécution. Les modifications prennent effet immédiatement, sans qu'il soit nécessaire de redémarrer le système.

   Note

   Les modifications reviennent aux valeurs par défaut après le redémarrage du système.

Procédure

1. Liste de tous les paramètres.

   # sysctl -a

   La commande affiche tous les paramètres du noyau qui peuvent être configurés au moment de l'exécution.

2. Configurer un paramètre de manière permanente :

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   L'exemple de commande modifie la valeur ajustable et l'écrit dans le fichier /etc/sysctl.conf, ce qui remplace les valeurs par défaut des paramètres du noyau. Les modifications prennent effet immédiatement et de manière persistante, sans qu'il soit nécessaire de redémarrer le système.

Procédure

1. Créez un nouveau fichier de configuration à l'adresse /etc/sysctl.d/.

   # vim /etc/sysctl.d/<some_file.conf>

2. Inclure les paramètres du noyau, un par ligne.

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. Sauvegarder le fichier de configuration.

4. Redémarrez la machine pour que les modifications soient prises en compte.

   • Sinon, pour appliquer les changements sans redémarrer, entrez :

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     Cette commande vous permet de lire les valeurs du fichier de configuration que vous avez créé précédemment.

Procédure

1. Identifiez un paramètre du noyau que vous souhaitez configurer.

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   Les fichiers accessibles en écriture renvoyés par la commande peuvent être utilisés pour configurer le noyau. Les fichiers en lecture seule fournissent des informations sur les paramètres actuels.

2. Attribuer une valeur cible au paramètre du noyau.

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   La commande apporte des modifications à la configuration qui disparaîtront après le redémarrage du système.

3. En option, vérifiez la valeur du nouveau paramètre du noyau.

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

1. valeur. Console log-level, définit la priorité la plus basse des messages imprimés sur la console.
2. valeur. Niveau de journalisation par défaut pour les messages sans niveau de journalisation explicite.
3. valeur. Définit la configuration du niveau de journalisation le plus bas possible pour le niveau de journalisation de la console.

4. valeur. Définit la valeur par défaut du niveau de journalisation de la console au démarrage.

   Chacune de ces valeurs définit une règle différente pour le traitement des messages d'erreur.

Procédure

1. Allez dans le champ Kdump.

2. Activer kdump si ce n'est pas déjà fait.

   

3. Définir la quantité de mémoire à réserver pour kdump.

   

Procédure

1. Vérifiez si kdump est installé sur votre système :

   # rpm -q kexec-tools

   Indique si le paquet est installé :

   # kexec-tools-2.0.22-13.el9.x86_64

   Sortie si le paquet n'est pas installé :

   le paquet kexec-tools n'est pas installé

2. Installez kdump et les autres paquets nécessaires en :

   # dnf install kexec-tools

Procédure

1. Configurer la valeur par défaut de crashkernel:

   # kdumpctl reset-crashkernel --kernel=ALL

2. (Facultatif) Pour utiliser une valeur personnalisée crashkernel:

   1. Configurer la réserve de mémoire nécessaire :

      crashkernel=1G-4G:192M,4G-:256M

      L'exemple réserve 192 Mo de mémoire si la quantité totale de mémoire du système est égale ou supérieure à 1 Go et inférieure à 4 Go. Si la quantité totale de mémoire est supérieure à 4 Go, 256 Mo sont réservés pour kdump.

      • (Facultatif) Décaler la mémoire réservée :

        Certains systèmes exigent de réserver de la mémoire avec un certain décalage fixe, car la réservation du noyau en cas de crash est très précoce, et il veut réserver une zone pour un usage spécial. Si le décalage est défini, la mémoire réservée commence à cet endroit. Pour décaler la mémoire réservée, utilisez la syntaxe suivante :

        crashkernel=192M@16M

        L'exemple ci-dessus réserve 192 Mo de mémoire en commençant par 16 Mo (adresse physique 0x01000000). Si le paramètre offset est fixé à 0 ou omis complètement, kdump décale automatiquement la mémoire réservée. Vous pouvez également décaler la mémoire lors de la définition d'une réservation de mémoire variable en spécifiant le décalage comme dernière valeur. Par exemple, crashkernel=1G-4G:192M,2G-64G:256M@16M.

   2. Mettre à jour la configuration du chargeur de démarrage :

      # grubby --update-kernel ALL --args "crashkernel=<CUSTOM-VALUE>”

      Sur les systèmes IBM Z qui utilisent le chargeur de démarrage zIPL, la commande ajoute un nouveau paramètre de noyau à chaque fichier /boot/loader/entries/<ENTRY>.conf.

      • Sur les systèmes IBM Z, pour mettre à jour le menu de démarrage, exécutez la commande zipl sans spécifier d'options :

        # zipl

3. Redémarrez pour que les modifications soient prises en compte :

   # reboot

Vérification

1. Activez la touche sysrq pour démarrer avec le noyau kdump:

   # echo 1 > /proc/sys/kernel/sysrq
   # echo c > /proc/sysrq-trigger

   Cela oblige le noyau Linux à se planter et à copier le fichier address-YYYY-MM-DD-HH:MM:SS/vmcore à l'emplacement cible spécifié dans le fichier de configuration.

2. Vérifiez que le fichier vmcore est déversé dans la cible comme spécifié dans le fichier /etc/kdump.conf:

   $ ls /var/crash/127.0.0.1-2022-01-18-0
   
   /var/crash/127.0.0.1-2022-01-18-05:23:10':
   kexec-dmesg.log  vmcore  vmcore-dmesg.txt

   Dans cet exemple, le noyau enregistre le fichier vmcore dans le répertoire cible par défaut, /var/crash/.

Procédure

1. En tant qu'utilisateur de root, modifiez le fichier de configuration de /etc/kdump.conf pour supprimer le signe de hachage ("#") au début de la commande suivante :

   core_collector makedumpfile -z -d 31 --message-level 1

2. Pour activer la compression du fichier dump, spécifiez l'une des options makedumpfile:

   core_collector makedumpfile -z -d 31 --message-level 1

   où,

   • -z spécifie le format de fichier compressé dump.
   • -d spécifie que le niveau de vidage est 31.
   • --message-level spécifie que le niveau du message est 1.

Procédure

1. Comme pour root, supprimez le signe de hachage ("#") au début de la ligne #failure_action dans le fichier de configuration /etc/kdump.conf.

2. Remplacer la valeur par une action souhaitée.

   failure_action poweroff

Procédure

1. Pour activer le service kdump, utilisez la commande suivante :

   # systemctl enable kdump.service

   Cela permet au service de se rendre sur le site multi-user.target.

2. Pour démarrer le service dans la session en cours, utilisez la commande suivante :

   # systemctl start kdump.service

3. Pour arrêter le service kdump, tapez la commande suivante :

   # systemctl stop kdump.service

4. Pour désactiver le service kdump, exécutez la commande suivante :

   # systemctl disable kdump.service

Procédure

1. Redémarrez le système avec kdump activé.

2. Assurez-vous que kdump est en cours d'exécution :

   # systemctl is-active kdump
   active

3. Forcer le noyau Linux à se bloquer :

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger

   Avertissement

   La commande ci-dessus plante le noyau, et un redémarrage est nécessaire.

   Une fois redémarré, le fichier address-YYYY-MM-DD-HH:MM:SS/vmcore est créé à l'emplacement que vous avez spécifié dans le fichier /etc/kdump.conf (par défaut /var/crash/).

   Note

   Cette action confirme la validité de la configuration. Il est également possible d'utiliser cette action pour enregistrer le temps nécessaire à l'exécution d'un crash dump avec une charge de travail représentative.

Procédure

1. Sélectionnez un module du noyau dont vous souhaitez bloquer le chargement.

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1

   La commande lsmod affiche une liste des modules chargés dans le noyau en cours d'exécution.

2. Mettre à jour la variable KDUMP_COMMANDLINE_APPEND= dans le fichier /etc/sysconfig/kdump.

   # KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

   Prenons également l'exemple suivant, qui utilise l'option de configuration modprobe.blacklist=<modules>.

   # KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

3. Redémarrez le service kdump.

   # systemctl restart kdump

Procédure

1. Imprimer la valeur estimée de crashkernel:

   # kdumpctl estimate
   
   Encrypted kdump target requires extra memory, assuming using the keyslot with minimum memory requirement
      Reserved crashkernel:    256M
      Recommended crashkernel: 652M
      Kernel image size:   47M
      Kernel modules size: 8M
      Initramfs size:      20M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules: none
      WARNING: Current crashkernel size is lower than recommended size 652M.

2. Configurez la quantité de mémoire requise en augmentant crashkernel jusqu'à la valeur souhaitée.

   # grubby –args=”crashkernel=652M” --update-kernel=ALL

3. Redémarrez pour que les modifications soient prises en compte.

   # reboot

Procédure

1. Pour configurer final_action, modifiez le fichier /etc/kdump.conf et ajoutez l'une des options suivantes :

   # final_action <reboot | halt | poweroff>

2. Redémarrez le service kdump pour que les modifications soient prises en compte :

   # kdumpctl restart

Procédure :

1. Pour configurer une action à entreprendre en cas d'échec du vidage, modifiez le fichier /etc/kdump.conf et spécifiez l'une des options failure_action:

   # failure_action <reboot | halt | poweroff | shell | dump_to_rootfs>

2. Redémarrez le service kdump pour que les modifications soient prises en compte :

   # kdumpctl restart

Procédure

1. Installez le paquetage kexec-tools.

2. Configurer la valeur par défaut de crashkernel.

   # kdumpctl reset-crashkernel –fadump=on --kernel=ALL

3. (Facultatif) Réserver la mémoire de démarrage au lieu de la valeur par défaut.

   # grubby --update-kernel ALL --args=”fadump=on crashkernel=xxM"

   où xx est la taille de la mémoire requise en mégaoctets.

   Note

   Lorsque vous spécifiez des options de configuration de démarrage, testez les configurations en redémarrant le noyau avec kdump activé. Si le noyau kdump ne démarre pas, augmentez progressivement la valeur de crashkernel pour définir une valeur appropriée.

4. Redémarrez pour que les modifications soient prises en compte.

   # reboot

Procédure

1. Ajoutez ou modifiez les lignes suivantes dans le fichier /etc/sysctl.conf pour vous assurer que kdump démarre comme prévu pour sadump:

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   Avertissement

   En particulier, assurez-vous qu'après kdump, le système ne redémarre pas. Si le système redémarre après que kdump n'a pas sauvegardé le fichier vmcore, il n'est pas possible d'invoquer le programme sadump.

2. Définissez le paramètre failure_action dans /etc/kdump.conf de manière appropriée comme halt ou shell.

   failure_action shell

Procédure

1. Activer les référentiels concernés :

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

2. Installez le paquetage crash:

   # dnf install crash

3. Installez le paquetage kernel-debuginfo:

   # dnf install kernel-debuginfo

   Le paquet correspond à votre noyau en cours d'exécution et fournit les données nécessaires à l'analyse du dump.

Procédure

1. Pour lancer l'utilitaire crash, deux paramètres nécessaires doivent être transmis à la commande :

   • Les informations de débogage (une image vmlinuz décompressée), par exemple /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux, sont fournies par le biais d'un paquetage kernel-debuginfo spécifique.

   • Le fichier vmcore actuel, par exemple /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore

     La commande crash qui en résulte se présente alors comme suit :

     # crash /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore

     Utilisez la même version de <kernel> qui a été capturée par kdump.

     Exemple 15.1. Exécution de l'utilitaire de crash

     L'exemple suivant montre l'analyse d'un core dump créé le 13 septembre 2021 à 14:05 PM, utilisant le noyau 5.14.0-1.el9.x86_64.

     ...
     WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
     
           KERNEL: /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux
         DUMPFILE: /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore  [PARTIAL DUMP]
             CPUS: 2
             DATE: Mon Sep 13 14:05:16 2021
           UPTIME: 01:03:57
     LOAD AVERAGE: 0.00, 0.00, 0.00
            TASKS: 586
         NODENAME: localhost.localdomain
          RELEASE: 5.14.0-1.el9.x86_64
          VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
          MACHINE: x86_64  (2904 Mhz)
           MEMORY: 2.9 GB
            PANIC: "sysrq: SysRq : Trigger a crash"
              PID: 10635
          COMMAND: "bash"
             TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
              CPU: 1
            STATE: TASK_RUNNING (SYSRQ)
     
     crash>

2. Pour quitter l'invite interactive et mettre fin à crash, tapez exit ou q.

   Exemple 15.2. Quitter l'utilitaire de crash

   crash> exit
   ~]#

Procédure

1. Accédez à l'outil Kernel Oops Analyzer.

2. Pour diagnostiquer un problème de crash du noyau, téléchargez un journal des opérations du noyau généré à l'adresse vmcore.

   • Vous pouvez également diagnostiquer un problème de crash du noyau en fournissant un message texte ou une adresse vmcore-dmesg.txt comme entrée.

     
3. Cliquez sur DETECT pour comparer le message oops basé sur les informations de makedumpfile avec les solutions connues.

1. Le module de correction du noyau est copié dans le répertoire /var/lib/kpatch/ et enregistré pour être réappliqué au noyau par systemd lors du prochain démarrage.
2. Le module kpatch est chargé dans le noyau en cours d'exécution et les nouvelles fonctions sont enregistrées dans le mécanisme ftrace avec un pointeur sur l'emplacement en mémoire du nouveau code.
3. Lorsque le noyau accède à la fonction corrigée, il est redirigé par le mécanisme ftrace qui contourne les fonctions d'origine et redirige le noyau vers la version corrigée de la fonction.

Procédure

1. Si vous le souhaitez, vérifiez la version de votre noyau :

   # uname -r
   5.14.0-1.el9.x86_64

2. Recherchez un paquet de correctifs correspondant à la version de votre noyau :

   # dnf search $(uname -r)

3. Installer le paquet de correctifs en direct :

   # dnf install "kpatch-patch = $(uname -r)"

   La commande ci-dessus installe et applique les derniers correctifs cumulatifs pour ce noyau spécifique uniquement.

   Si la version d'un paquet de correctifs en direct est 1-1 ou supérieure, le paquet contiendra un module de correctifs. Dans ce cas, le noyau sera automatiquement corrigé lors de l'installation du paquet de correctifs.

   Le module de correction du noyau est également installé dans le répertoire /var/lib/kpatch/ afin d'être chargé par le système systemd et le gestionnaire de services lors des prochains redémarrages.

   Note

   Un paquet de live patching vide sera installé lorsqu'il n'y a pas de live patches disponibles pour un noyau donné. Un paquet de live patching vide aura un kpatch_version-kpatch_release de 0-0, par exemple kpatch-patch-5_14_0-1-0-0.x86_64.rpm. L'installation du RPM vide abonne le système à tous les futurs live patches pour le noyau donné.

4. Optionnellement, vérifiez que le noyau est corrigé :

   # kpatch list
   Loaded patch modules:
   kpatch_5_14_0_1_0_1 [enabled]
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)
   …​

   La sortie montre que le module de correction du noyau a été chargé dans le noyau, qui est maintenant corrigé avec les derniers correctifs du paquet kpatch-patch-5_14_0-1-0-1.el9.x86_64.rpm.

Procédure

1. Optionnellement, vérifiez tous les noyaux installés et le noyau que vous utilisez actuellement :

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

2. Installez le plugin kpatch-dnf:

   # dnf install kpatch-dnf

3. Activer l'abonnement automatique aux correctifs du noyau :

   # dnf kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 1:38:21 ago on Fri 17 Sep 2021 07:29:53 AM EDT.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-5_14_0-1               x86_64
    kpatch-patch-5_14_0-2               x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   Cette commande permet d'abonner tous les noyaux actuellement installés à la réception des correctifs en direct du noyau. Elle installe et applique également les derniers correctifs cumulatifs, le cas échéant, pour tous les noyaux installés.

   À l'avenir, lorsque vous mettrez à jour le noyau, les correctifs seront automatiquement installés au cours de la procédure d'installation du nouveau noyau.

   Le module de correction du noyau est également installé dans le répertoire /var/lib/kpatch/ afin d'être chargé par le système systemd et le gestionnaire de services lors des prochains redémarrages.

   Note

   Un paquet de live patching vide sera installé lorsqu'il n'y a pas de live patches disponibles pour un noyau donné. Un paquet de live patching vide aura un kpatch_version-kpatch_release de 0-0, par exemple kpatch-patch-5_14_0-1-0-0.el9.x86_64.rpm L'installation du RPM vide abonne le système à tous les futurs live patches pour le noyau donné.

Procédure

1. Optionnellement, vérifiez tous les noyaux installés et le noyau que vous utilisez actuellement :

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

2. Désactiver l'abonnement automatique aux correctifs du noyau :

   # dnf kpatch manual
   Updating Subscription Management repositories.

Procédure

1. Sélectionnez le paquet de correctifs en direct.

   # dnf list installed | grep kpatch-patch
   kpatch-patch-5_14_0-1.x86_64        0-1.el9        @@commandline
   …​

   L'exemple ci-dessus présente la liste des paquets de correctifs que vous avez installés.

2. Supprimez le paquet de correctifs en direct.

   # dnf remove kpatch-patch-5_14_0-1.x86_64

   Lorsqu'un paquet de correctifs en direct est supprimé, le noyau reste corrigé jusqu'au prochain redémarrage, mais le module de correctifs du noyau est supprimé du disque. Au prochain redémarrage, le noyau correspondant ne sera plus patché.

3. Redémarrez votre système.

4. Vérifiez que le paquet de correctifs en direct a été supprimé.

   # dnf list installed | grep kpatch-patch

   La commande n'affiche aucun résultat si le paquet a été supprimé avec succès.

5. En option, vérifiez que la solution de correctifs en direct du noyau est désactivée.

   # kpatch list
   Loaded patch modules:

   L'exemple de sortie montre que le noyau n'est pas patché et que la solution de patching en direct n'est pas active parce qu'il n'y a pas de modules de patching actuellement chargés.

Procédure

1. Sélectionnez un module de correction du noyau :

   # kpatch list
   Loaded patch modules:
   kpatch_5_14_0_1_0_1 [enabled]
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)
   …​

2. Désinstaller le module de correction du noyau sélectionné.

   # kpatch uninstall kpatch_5_14_0_1_0_1
   uninstalling kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   • Notez que le module de correction du noyau désinstallé est toujours chargé :

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     Lorsque le module sélectionné est désinstallé, le noyau reste corrigé jusqu'au prochain redémarrage, mais le module de correction du noyau est supprimé du disque.

3. Redémarrez votre système.

4. En option, vérifiez que le module de correction du noyau a été désinstallé.

   # kpatch list
   Loaded patch modules:
   …​

   L'exemple ci-dessus ne montre aucun module de correction du noyau chargé ou installé. Le noyau n'est donc pas corrigé et la solution de correction en direct du noyau n'est pas active.

Procédure

1. Vérifiez que kpatch.service est activé.

   # systemctl is-enabled kpatch.service
   enabled

2. Désactiver kpatch.service:

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • Notez que le module de correction du noyau appliqué est toujours chargé :

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

3. Redémarrez votre système.

4. Optionnellement, vérifiez l'état de kpatch.service.

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   L'exemple de sortie indique que kpatch.service a été désactivé et n'est pas en cours d'exécution. Par conséquent, la solution de correctifs en direct du noyau n'est pas active.

5. Vérifiez que le module de correction du noyau a été déchargé.

   # kpatch list
   Loaded patch modules:
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   L'exemple ci-dessus montre qu'un module de correction du noyau est toujours installé mais que le noyau n'est pas corrigé.

1. Vérifiez les valeurs attribuées pour le service de votre choix.

   # systemctl show --propriété <unit file option> <service name>

2. Définir la valeur requise de l'option de politique d'allocation du temps CPU :

   # systemctl set-property <service name> <unit file option> =<value>

Procédure

1. Pour savoir à quel site cgroup un processus appartient, exécutez la commande suivante # cat proc/<PID>/cgroup commande :

   # cat /proc/2467/cgroup
   0::/system.slice/example.service

   L'exemple de sortie se rapporte à un processus d'intérêt. Dans ce cas, il s'agit d'un processus identifié par PID 2467, qui appartient à l'unité example.service. Vous pouvez déterminer si le processus a été placé dans un groupe de contrôle correct, tel que défini par les spécifications du fichier de l'unité systemd.

2. Pour afficher les contrôleurs utilisés par le site cgroup et les fichiers de configuration correspondants, consultez le répertoire cgroup:

   # cat /sys/fs/cgroup/system.slice/example.service/cgroup.controllers
   memory pids
   
   # ls /sys/fs/cgroup/system.slice/example.service/
   cgroup.controllers
   cgroup.events
   …​
   cpu.pressure
   cpu.stat
   io.pressure
   memory.current
   memory.events
   …​
   pids.current
   pids.events
   pids.max

Procédure

1. La commande systemd-cgtop permet d'afficher un compte dynamique des sites en cours d'exécution ( cgroups ).

   # systemd-cgtop
   Control Group                            Tasks   %CPU   Memory  Input/s Output/s
   /                                          607   29.8     1.5G        -        -
   /system.slice                              125      -   428.7M        -        -
   /system.slice/ModemManager.service           3      -     8.6M        -        -
   /system.slice/NetworkManager.service         3      -    12.8M        -        -
   /system.slice/accounts-daemon.service        3      -     1.8M        -        -
   /system.slice/boot.mount                     -      -    48.0K        -        -
   /system.slice/chronyd.service                1      -     2.0M        -        -
   /system.slice/cockpit.socket                 -      -     1.3M        -        -
   /system.slice/colord.service                 3      -     3.5M        -        -
   /system.slice/crond.service                  1      -     1.8M        -        -
   /system.slice/cups.service                   1      -     3.1M        -        -
   /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
   /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
   /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
   /system.slice/example.service                2      -     2.0M        -        -
   /system.slice/firewalld.service              2      -    28.8M        -        -
   ...

   L'exemple suivant affiche les sites cgroups en cours d'exécution, classés en fonction de leur utilisation des ressources (CPU, mémoire, charge d'E/S sur disque). La liste est actualisée toutes les secondes par défaut. Elle offre donc un aperçu dynamique de l'utilisation réelle des ressources de chaque groupe de contrôle.

Procédure

1. Modifier le fichier /usr/lib/systemd/system/example.service pour limiter l'utilisation de la mémoire d'un service :

   …​
   [Service]
   MemoryMax=1500K
   …​

   La configuration ci-dessus impose une limite de mémoire maximale que les processus d'un groupe de contrôle ne peuvent pas dépasser. Le service example.service fait partie d'un tel groupe de contrôle auquel des limites ont été imposées. Vous pouvez utiliser les suffixes K, M, G ou T pour identifier le kilo-octet, le méga-octet, le giga-octet ou le téra-octet comme unité de mesure.

2. Recharger tous les fichiers de configuration de l'unité :

   # systemctl daemon-reload

3. Redémarrer le service :

   # systemctl restart example.service

Vérification

1. Vérifiez que les modifications ont bien été prises en compte :

   # cat /sys/fs/cgroup/system.slice/example.service/memory.max
   1536000

   L'exemple montre que la consommation de mémoire a été limitée à environ 1 500 Ko.

1. Vérifiez les valeurs de l'option de fichier de l'unité CPUAffinity dans le service de votre choix :

   systemctl show --property <CPU affinity configuration option> <service name>

2. En tant que root, définissez la valeur requise de l'option CPUAffinity unit file pour les plages de CPU utilisées comme masque d'affinité :

   # systemctl set-property <service name> CPUAffinity=<value>

3. Redémarrez le service pour appliquer les modifications.

   # systemctl restart <service name>

1. Définissez les numéros de CPU pour l'option CPUAffinity= dans le fichier /etc/systemd/system.conf.

2. Enregistrez le fichier modifié et rechargez le service systemd:

   # systemctl daemon-reload

3. Redémarrez le serveur pour appliquer les modifications.

1. Vérifiez les valeurs de l'option de fichier de l'unité NUMAPolicy dans le service de votre choix :

   $ systemctl show --property <NUMA policy configuration option> <service name>

2. En tant qu'utilisateur principal, définissez le type de stratégie requis pour l'option de fichier d'unité NUMAPolicy:

   # systemctl set-property <service name> NUMAPolicy=<value>

3. Redémarrez le service pour appliquer les modifications.

   # systemctl restart <service name>

1. Recherchez l'option NUMAPolicy dans le fichier /etc/systemd/system.conf.
2. Modifiez le type de politique et enregistrez le fichier.

3. Recharger la configuration de systemd:

   # systemd daemon-reload

4. Redémarrer le serveur.

Procédure

1. Activer zswap de façon permanente :

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="zswap.enabled=1"

2. Redémarrez le système pour que les modifications soient prises en compte.

Procédure

1. Créez le répertoire /sys/fs/cgroup/Example/:

   # mkdir /sys/fs/cgroup/Example/

   Le répertoire /sys/fs/cgroup/Example/ définit un groupe enfant. Lorsque vous créez le répertoire /sys/fs/cgroup/Example/, certains fichiers d'interface cgroups-v2 sont automatiquement créés dans le répertoire. Le répertoire /sys/fs/cgroup/Example/ contient également des fichiers spécifiques aux contrôleurs memory et pids.

2. Il est possible d'inspecter le groupe de contrôle enfant nouvellement créé :

   # ll /sys/fs/cgroup/Example/
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.procs
   …​
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

   L'exemple de sortie montre les fichiers généraux de l'interface de contrôle cgroup tels que cgroup.procs ou cgroup.controllers. Ces fichiers sont communs à tous les groupes de contrôle, quels que soient les contrôleurs activés.

   Les fichiers tels que memory.high et pids.max se rapportent aux contrôleurs memory et pids, qui se trouvent dans le groupe de contrôle racine (/sys/fs/cgroup/), et sont activés par défaut par systemd.

   Par défaut, le groupe enfant nouvellement créé hérite de tous les paramètres du parent cgroup. Dans ce cas, aucune limite n'est imposée par la racine cgroup.

3. Vérifiez que les contrôleurs souhaités sont disponibles dans le fichier /sys/fs/cgroup/cgroup.controllers:

   # cat /sys/fs/cgroup/cgroup.controllers
   cpuset cpu io memory hugetlb pids rdma

4. Activez les contrôleurs souhaités. Dans cet exemple, il s'agit des contrôleurs cpu et cpuset:

   # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

   Ces commandes activent les contrôleurs cpu et cpuset pour les groupes enfants immédiats du groupe de contrôle racine /sys/fs/cgroup/. Y compris le groupe de contrôle Example nouvellement créé. Un site child group est l'endroit où vous pouvez spécifier des processus et appliquer des contrôles à chacun des processus en fonction de vos critères.

   Les utilisateurs peuvent lire le contenu du fichier cgroup.subtree_control à n'importe quel niveau pour avoir une idée des contrôleurs qui seront disponibles pour l'activation dans le groupe enfant immédiat.

   Note

   Par défaut, le fichier /sys/fs/cgroup/cgroup.subtree_control du groupe de contrôle racine contient les contrôleurs memory et pids.

5. Activez les contrôleurs souhaités pour l'enfant cgroups du groupe de contrôle Example:

   # echo " cpu cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

   Cette commande garantit que le groupe de contrôle enfant immédiat only aura des contrôleurs pertinents pour réguler la distribution du temps CPU - et non des contrôleurs memory ou pids.

6. Créez le répertoire /sys/fs/cgroup/Example/tasks/:

   # mkdir /sys/fs/cgroup/Example/tasks/

   Le répertoire /sys/fs/cgroup/Example/tasks/ définit un groupe enfant avec des fichiers qui se rapportent uniquement aux contrôleurs cpu et cpuset. Vous pouvez maintenant affecter des processus à ce groupe de contrôle et utiliser les options des contrôleurs cpu et cpuset pour vos processus.

7. Optionnellement, inspecter le groupe de contrôle de l'enfant :

   # ll /sys/fs/cgroup/Example/tasks
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure

Procédure

1. Configurez les poids CPU souhaités afin de respecter les restrictions de ressources au sein des groupes de contrôle :

   # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
   # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
   # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight

2. Ajoutez les PID des applications aux groupes enfants g1, g2, et g3:

   # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
   # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
   # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

   Les commandes de l'exemple garantissent que les applications souhaitées deviennent membres des cgroups enfants Example/g*/ et que leur temps d'utilisation de l'unité centrale est réparti conformément à la configuration de ces cgroups.

   Les poids des cgroups enfants (g1, g2, g3) qui ont des processus en cours sont additionnés au niveau du cgroup parent (Example). Les ressources de l'unité centrale sont ensuite réparties proportionnellement en fonction des poids respectifs.

   Par conséquent, lorsque tous les processus s'exécutent en même temps, le noyau alloue à chacun d'entre eux un temps d'utilisation proportionnel basé sur le fichier cpu.weight de leur cgroupe respectif :

   Enfant cgroup	cpu.weight fichier	Attribution du temps de l'unité centrale
   g1	150	~50% (150/300)
   g2	100	~33% (100/300)
   g3	50	~16% (50/300)

   La valeur du fichier du contrôleur cpu.weight n'est pas un pourcentage.

   Si un processus cessait de fonctionner, laissant le cgroup g2 sans aucun processus en cours, le calcul ne tiendrait pas compte du cgroup g2 et ne prendrait en compte que les poids des cgroups g1 et g3:

   Enfant cgroup	cpu.weight fichier	Attribution du temps de l'unité centrale
   g1	150	~75% (150/200)
   g3	50	~25% (50/200)

   Important

   Si un cgroup enfant a plusieurs processus en cours d'exécution, le temps CPU alloué au cgroup respectif sera distribué de manière égale aux processus membres de ce cgroup.

Vérification

1. Vérifiez que les applications s'exécutent dans les groupes de contrôle spécifiés :

   # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
   0::/Example/g1
   0::/Example/g2
   0::/Example/g3

   La sortie de la commande montre les processus des applications spécifiées qui s'exécutent dans les cgroups enfants Example/g*/.

2. Examinez la consommation actuelle de l'unité centrale des applications limitées :

   # top
   top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
   Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
     33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
     33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
       760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
         1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
   ...

   Note

   Nous avons forcé tous les processus de l'exemple à s'exécuter sur une seule unité centrale pour une illustration plus claire. Le poids de l'unité centrale applique les mêmes principes lorsqu'il est utilisé sur plusieurs unités centrales.

   Notez que la ressource CPU pour les applications PID 33373, PID 33374 et PID 33377 a été allouée en fonction des poids, 150, 100, 50, que vous avez attribués aux groupes enfants respectifs. Ces poids correspondent à environ 50 %, 33 % et 16 % du temps d'utilisation de l'unité centrale pour chaque application.

Procédure

1. Configurer le système pour qu'il monte cgroups-v1 par défaut lors du démarrage du système par le système systemd et le gestionnaire de services :

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

   Cette opération ajoute les paramètres de ligne de commande du noyau nécessaires à l'entrée de démarrage actuelle.

   Pour ajouter les mêmes paramètres à toutes les entrées de démarrage du noyau :

   # grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

2. Redémarrez le système pour que les modifications soient prises en compte.

Vérification

1. Optionnellement, vérifiez que le système de fichiers cgroups-v1 a été monté :

   # mount -l | grep cgroup
   tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,size=4096k,nr_inodes=1024,mode=755,inode64)
   cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
   cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
   cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
   cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
   cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
   cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
   cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
   cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
   cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
   cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
   cgroup on /sys/fs/cgroup/misc type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,misc)
   cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
   cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,rdma)

   Les systèmes de fichiers cgroups-v1 correspondant aux différents contrôleurs cgroup-v1 ont été montés avec succès dans le répertoire /sys/fs/cgroup/.

2. Il est possible d'inspecter le contenu du répertoire /sys/fs/cgroup/:

   # ll /sys/fs/cgroup/
   dr-xr-xr-x. 10 root root  0 Mar 16 09:34 blkio
   lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpu → cpu,cpuacct
   lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpuacct → cpu,cpuacct
   dr-xr-xr-x. 10 root root  0 Mar 16 09:34 cpu,cpuacct
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 cpuset
   dr-xr-xr-x. 10 root root  0 Mar 16 09:34 devices
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 freezer
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 hugetlb
   dr-xr-xr-x. 10 root root  0 Mar 16 09:34 memory
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 misc
   lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_cls → net_cls,net_prio
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 net_cls,net_prio
   lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_prio → net_cls,net_prio
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 perf_event
   dr-xr-xr-x. 10 root root  0 Mar 16 09:34 pids
   dr-xr-xr-x.  2 root root  0 Mar 16 09:34 rdma
   dr-xr-xr-x. 11 root root  0 Mar 16 09:34 systemd

   Le répertoire /sys/fs/cgroup/, également appelé root control group, par défaut, contient des répertoires spécifiques aux contrôleurs, tels que cpuset. En outre, il existe des répertoires liés à systemd.

Procédure

1. Identifiez l'ID du processus (PID) de l'application dont vous souhaitez limiter la consommation de CPU :

   # top
   top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
   Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
   MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
    5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
    6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
       1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
     505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
   ...

   L'exemple de sortie du programme top révèle que PID 6955 (application illustrative sha1sum) consomme beaucoup de ressources de l'unité centrale.

2. Créez un sous-répertoire dans le répertoire du contrôleur de ressources cpu:

   # mkdir /sys/fs/cgroup/cpu/Example/

   Le répertoire ci-dessus représente un groupe de contrôle, dans lequel vous pouvez placer des processus spécifiques et leur appliquer certaines limites de CPU. En même temps, certains fichiers d'interface cgroups-v1 et des fichiers spécifiques au contrôleur cpu seront créés dans le répertoire.

3. Il est possible d'inspecter le groupe de contrôle nouvellement créé :

   # ll /sys/fs/cgroup/cpu/Example/
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

   L'exemple de sortie montre des fichiers, tels que cpuacct.usage, cpu.cfs._period_us, qui représentent des configurations et/ou des limites spécifiques, qui peuvent être définies pour les processus dans le groupe de contrôle Example. Notez que les noms de fichiers respectifs sont précédés du nom du contrôleur du groupe de contrôle auquel ils appartiennent.

   Par défaut, le groupe de contrôle nouvellement créé hérite de l'accès à l'ensemble des ressources de l'unité centrale du système, sans limite.

4. Configurer les limites de CPU pour le groupe de contrôle :

   # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
   # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

   Le fichier cpu.cfs_period_us représente une période de temps en microsecondes (µs, représentée ici par "us") pour la fréquence à laquelle l'accès d'un groupe de contrôle aux ressources de l'unité centrale doit être réattribué. La limite supérieure est de 1 seconde et la limite inférieure de 1000 microsecondes.

   Le fichier cpu.cfs_quota_us représente la durée totale en microsecondes pendant laquelle tous les processus d'un groupe de contrôle peuvent s'exécuter au cours d'une période (telle que définie par cpu.cfs_period_us). Dès que les processus d'un groupe de contrôle, au cours d'une période unique, utilisent la totalité du temps spécifié par le quota, ils sont bridés pour le reste de la période et ne sont plus autorisés à s'exécuter jusqu'à la période suivante. La limite inférieure est de 1000 microsecondes.

   Les exemples de commandes ci-dessus définissent les limites de temps de l'unité centrale de sorte que tous les processus du groupe de contrôle Example ne puissent s'exécuter que pendant 0,2 seconde (définie par cpu.cfs_quota_us) sur 1 seconde (définie par cpu.cfs_period_us).

5. Il est possible de vérifier les limites :

   # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
   1000000
   200000

6. Ajouter le PID de l'application au groupe de contrôle Example:

   # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
   
   or
   
   # echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

   La commande précédente garantit qu'une application souhaitée devient membre du groupe de contrôle Example et ne dépasse donc pas les limites de CPU configurées pour le groupe de contrôle Example. Le PID doit représenter un processus existant dans le système. L'adresse PID 6955 a été attribuée au processus sha1sum /dev/zero &, utilisé pour illustrer le cas d'utilisation du contrôleur cpu.

7. Vérifiez que l'application s'exécute dans le groupe de contrôle spécifié :

   # cat /proc/6955/cgroup
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

   L'exemple ci-dessus montre que le processus de l'application souhaitée s'exécute dans le groupe de contrôle Example, qui applique des limites de CPU au processus de l'application.

8. Identifiez la consommation actuelle de l'unité centrale de votre application limitée :

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
    5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
    6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
     505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
    4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
   ...

   Remarquez que la consommation de l'unité centrale du site PID 6955 est passée de 99 % à 20 %.

Procédure

1. Installer bcc-tools.

   # dnf install bcc-tools

   Les outils BCC sont installés dans le répertoire /usr/share/bcc/tools/.

2. Optionnellement, inspecter les outils :

   # ll /usr/share/bcc/tools/
   ...
   -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
   -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
   -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
   -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
   drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
   -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
   -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
   -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
   ...

   Le répertoire doc de la liste ci-dessus contient la documentation de chaque outil.

1. Exécutez le programme execsnoop dans un terminal :

   # /usr/share/bcc/tools/execsnoop

2. Dans un autre terminal, par exemple :

   $ ls /usr/share/bcc/tools/doc/

   Ce qui précède crée un processus éphémère de la commande ls.

3. Le terminal exécutant execsnoop affiche une sortie similaire à la suivante :

   PCOMM	PID    PPID   RET ARGS
   ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
   ...

   Le programme execsnoop imprime une ligne de sortie pour chaque nouveau processus, ce qui consomme des ressources système. Il détecte même les processus de programmes qui s'exécutent très brièvement, tels que ls, et que la plupart des outils de surveillance n'enregistreraient pas.

   Le site execsnoop affiche les champs suivants :

   • PCOMM - Le nom du processus parent. (ls)
   • PID - L'ID du processus. (8382)
   • PPID - L'ID du processus parent. (8287)
   • RET - La valeur de retour de l'appel système exec() (0), qui charge le code du programme dans de nouveaux processus.
   • ARGS - Emplacement du programme lancé avec les arguments.

1. Exécutez le programme opensnoop dans un terminal :

   # /usr/share/bcc/tools/opensnoop -n uname

   Ce qui précède imprime la sortie des fichiers qui ne sont ouverts que par le processus de la commande uname.

2. Dans un autre terminal, entrez :

   $ uname

   La commande ci-dessus ouvre certains fichiers, qui sont capturés à l'étape suivante.

3. Le terminal exécutant opensnoop affiche une sortie similaire à la suivante :

   PID    COMM 	FD ERR PATH
   8596   uname 	3  0   /etc/ld.so.cache
   8596   uname 	3  0   /lib64/libc.so.6
   8596   uname 	3  0   /usr/lib/locale/locale-archive
   ...

   Le programme opensnoop surveille l'appel système open() sur l'ensemble du système et imprime une ligne de sortie pour chaque fichier que uname a essayé d'ouvrir en cours de route.

   Le site opensnoop affiche les champs suivants :

   • PID - L'ID du processus. (8596)
   • COMM - Le nom du processus. (uname)
   • FD - Le descripteur de fichier - une valeur que open() renvoie pour faire référence au fichier ouvert. (3)
   • ERR - Erreurs éventuelles.

   • PATH - Emplacement des fichiers que open() a tenté d'ouvrir.

     Si une commande tente de lire un fichier inexistant, la colonne FD renvoie -1 et la colonne ERR imprime une valeur correspondant à l'erreur en question. Par conséquent, opensnoop peut vous aider à identifier une application qui ne se comporte pas correctement.

1. Exécutez le programme biotop dans un terminal :

   # /usr/share/bcc/tools/biotop 30

   Cette commande vous permet de surveiller les principaux processus qui effectuent des opérations d'entrée/sortie sur le disque. L'argument garantit que la commande produira un résumé de 30 secondes.

   Note

   Si aucun argument n'est fourni, l'écran de sortie est rafraîchi par défaut toutes les 1 secondes.

2. Dans un autre terminal, entrez, par exemple, :

   # dd if=/dev/vda of=/dev/zero

   La commande ci-dessus lit le contenu du disque dur local et écrit la sortie dans le fichier /dev/zero. Cette étape génère un certain trafic d'E/S pour illustrer biotop.

3. Le terminal exécutant biotop affiche une sortie similaire à la suivante :

   PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
   9568   dd               R 252 0   vda      16294 14440636.0  3.69
   48     kswapd0          W 252 0   vda       1763 120696.0    1.65
   7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
   1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
   7515   Xorg             R 252 0   vda        280  9940.0     0.28
   7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
   9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
   8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
   7807   gnome-software   R 252 0   vda         31  2336.0     0.73
   9578   awk              R 252 0   vda         17  2228.0     0.66
   7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
   9581   pgrep            R 252 0   vda         58  1748.0     0.42
   7531   InputThread      R 252 0   vda         30  1200.0     0.48
   7504   gdbus            R 252 0   vda          3  1164.0     0.30
   1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
   1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
   ...

   Le site biotop affiche les champs suivants :

   • PID - L'ID du processus. (9568)
   • COMM - Le nom du processus. (dd)
   • DISK - Le disque effectuant les opérations de lecture. (vda)
   • I/O - Nombre d'opérations de lecture effectuées. (16294)
   • Kbytes - Le nombre de Kbytes atteint par les opérations de lecture. (14,440,636)
   • AVGms - Le temps d'E/S moyen des opérations de lecture. (3.69)

1. Exécutez le programme xfsslower dans un terminal :

   # /usr/share/bcc/tools/xfsslower 1

   La commande ci-dessus mesure le temps que le système de fichiers XFS passe à effectuer des opérations de lecture, d'écriture, d'ouverture ou de synchronisation (fsync). L'argument 1 garantit que le programme n'affiche que les opérations qui sont plus lentes que 1 ms.

   Note

   En l'absence d'arguments, xfsslower affiche par défaut les opérations plus lentes que 10 ms.

2. Dans un autre terminal, entrez, par exemple, ce qui suit :

   $ vim text

   La commande ci-dessus crée un fichier texte dans l'éditeur vim afin d'initier certaines interactions avec le système de fichiers XFS.

3. Le terminal qui exécute xfsslower affiche quelque chose de similaire après avoir sauvegardé le fichier de l'étape précédente :

   TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
   13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
   13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
   13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
   13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
   13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
   13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
   13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
   ...

   Chaque ligne ci-dessus représente une opération dans le système de fichiers qui a pris plus de temps qu'un certain seuil. xfsslower est capable d'exposer les problèmes éventuels du système de fichiers, qui peuvent prendre la forme d'opérations inopinément lentes.

   Le site xfsslower affiche les champs suivants :

   • COMM - Le nom du processus. (b’bash')

   • T - Le type d'opération. (R)

     • Rtête
     • Write
     • Sync
   • OFF_KB - Le décalage du fichier en Ko. (0)
   • FILENAME - Le fichier en cours de lecture, d'écriture ou de synchronisation.

Procédure

1. Créez une clé RSA de 2048 bits avec une clé de stockage primaire SHA-256 avec une poignée persistante, par exemple, 81000001, en utilisant l'un des utilitaires suivants :

   1. En utilisant le paquet tss2:

      # TPM_DEVICE=/dev/tpm0 tsscreateprimary -hi o -st
      Handle 80000000
      # TPM_DEVICE=/dev/tpm0 tssevictcontrol -hi o -ho 80000000 -hp 81000001

   2. En utilisant le paquet tpm2-tools:

      # tpm2_createprimary --key-algorithm=rsa2048 --key-context=key.ctxt
      name-alg:
        value: sha256
        raw: 0xb
      …
      sym-keybits: 128
      rsa: xxxxxx…
      
      # tpm2_evictcontrol -c key.ctxt 0x81000001
      persistentHandle: 0x81000001
      action: persisted

2. Créez une clé de confiance en utilisant un TPM 2.0 avec la syntaxe suivante keyctl add trusted <NAME> "new <KEY_LENGTH> keyhandle=<PERSISTENT-HANDLE> [options]" <KEYRING>. Dans cet exemple, la poignée persistante est 81000001.

   # keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
   642500861

   La commande crée une clé de confiance appelée kmk d'une longueur de 32 octets (256 bits) et la place dans le trousseau de l'utilisateur (@u). Les clés peuvent avoir une longueur de 32 à 128 octets (256 à 1024 bits).

3. Liste la structure actuelle des trousseaux de clés du noyau.

   # keyctl show
   Session Keyring
          -3 --alswrv    500   500  keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

4. Exporter la clé vers un blob de l'espace utilisateur en utilisant le numéro de série de la clé de confiance.

   # keyctl pipe 642500861 > kmk.blob

   La commande utilise la sous-commande pipe et le numéro de série kmk.

5. Charger la clé de confiance à partir du blob de l'espace utilisateur.

   # keyctl add trusted kmk "load `cat kmk.blob`" @u
   268728824

6. Créez des clés cryptées sécurisées qui utilisent la clé de confiance scellée par le TPM (kmk). Suivez la syntaxe suivante : keyctl add encrypted <NAME> "new [FORMAT] <KEY_TYPE>:<PRIMARY_KEY_NAME> <KEY_LENGTH>" <KEYRING>.

   # keyctl add encrypted encr-key "new trusted:kmk 32" @u
   159771175

Procédure

1. Générer une clé d'utilisateur en utilisant une séquence aléatoire de nombres.

   # keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u
   427069434

   La commande génère une clé d'utilisateur appelée kmk-user qui fait office de primary key et est utilisée pour sceller les clés cryptées proprement dites.

2. Générer une clé cryptée en utilisant la clé primaire de l'étape précédente :

   # keyctl add encrypted encr-key "new user:kmk-user 32" @u
   1012412758

3. Optionnellement, liste de toutes les clés du trousseau de l'utilisateur spécifié :

   # keyctl list @u
   2 keys in keyring:
   427069434: --alswrv  1000  1000 user: kmk-user
   1012412758: --alswrv  1000  1000 encrypted: encr-key

Procédure

1. Activez l'IMA et l'EVM dans le mode fix pour l'entrée de démarrage actuelle et permettez aux utilisateurs de recueillir et de mettre à jour les mesures IMA en ajoutant les paramètres de ligne de commande du noyau suivants :

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

   La commande active l'IMA et l'EVM dans le mode fix pour l'entrée de démarrage actuelle et permet aux utilisateurs de rassembler et de mettre à jour les mesures IMA.

   Le paramètre de ligne de commande du noyau ima_policy=appraise_tcb garantit que le noyau utilise la politique de mesure par défaut de la Trusted Computing Base (TCB) et l'étape d'évaluation. L'étape d'évaluation interdit l'accès aux fichiers dont les mesures antérieures et actuelles ne correspondent pas.

2. Redémarrez pour que les modifications soient prises en compte.

3. Facultatif : Vérifiez que les paramètres ont été ajoutés à la ligne de commande du noyau :

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-1.el9.x86_64 root=/dev/mapper/rhel-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix

4. Créer une clé maître du noyau pour protéger la clé EVM :

   # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
   748544121

   L'adresse kmk est entièrement conservée dans la mémoire du noyau. La valeur de 32 octets de kmk est générée à partir d'octets aléatoires du fichier /dev/urandom et placée dans le trousseau de l'utilisateur (@u). Le numéro de série de la clé se trouve sur la première ligne de la sortie précédente.

5. Créer une clé EVM cryptée sur la base du site kmk:

   # keyctl add encrypted evm-key "new user:kmk 64" @u
   641780271

   La commande utilise le site kmk pour générer et crypter une clé d'utilisateur de 64 octets (nommée evm-key) et la placer dans le trousseau de l'utilisateur (@u). Le numéro de série de la clé se trouve sur la première ligne de la sortie précédente.

   Important

   Il est nécessaire de nommer la clé utilisateur evm-key car c'est le nom que le sous-système EVM attend et avec lequel il travaille.

6. Créer un répertoire pour les clés exportées.

   # mkdir -p /etc/keys/

7. Recherchez le site kmk et exportez sa valeur en clair dans le nouveau répertoire.

   # keyctl pipe $(keyctl search @u user kmk) > /etc/keys/kmk

8. Recherchez le site evm-key et exportez sa valeur cryptée dans le nouveau répertoire.

   # keyctl pipe $(keyctl search @u encrypted evm-key) > /etc/keys/evm-key

   Le site evm-key a été crypté précédemment par la clé principale du noyau.

9. Optionnel : Affichez les clés nouvellement créées.

   # keyctl show
   Session Keyring
   974575405   --alswrv     0        0      keyring: ses 299489774 --alswrv 0 65534 \ keyring: uid.0 748544121 --alswrv 0 0 \ user: kmk
   641780271   --alswrv     0        0           \_ encrypted: evm-key
   
   # ls -l /etc/keys/
   total 8
   -rw-r--r--. 1 root root 246 Jun 24 12:44 evm-key
   -rw-r--r--. 1 root root  32 Jun 24 12:43 kmk

10. Facultatif : si les clés ont été supprimées du trousseau, par exemple après un redémarrage du système, vous pouvez importer les clés déjà exportées kmk et evm-key au lieu d'en créer de nouvelles.

    1. Importer le site kmk.

       # keyctl add user kmk "$(cat /etc/keys/kmk)" @u
       451342217

    2. Importer le site evm-key.

       # keyctl add encrypted evm-key "load $(cat /etc/keys/evm-key)" @u
       924537557

11. Activer l'EVM.

    # echo 1 > /sys/kernel/security/evm

12. Réétiqueter l'ensemble du système.

    # find / -fstype xfs -type f -uid 0 -exec head -n 1 '{}' >/dev/null \;

    Avertissement

    L'activation de l'IMA et de l'EVM sans réétiquetage du système peut rendre la majorité des fichiers du système inaccessibles.