Sujet : linux
-
Résumer le temps passé dans les appels système avec strace -c, son surcoût et perf trace comme alternative
strace -c comptabilise le temps, le nombre d'appels et les erreurs par appel système au lieu d'afficher chaque appel, mais le manuel de strace avertit qu'un processus tracé s'exécute plus lentement qu'un processus non tracé ; perf trace, décrit comme un outil inspiré de strace et reposant sur perf_events plutôt que sur ptrace, est l'alternative plus légère lorsque ce surcoût pose problème.
-
Corriger les failles KEV du noyau Linux : vérifier chaque CVE dans le paquet de la distribution et le noyau actif
Suivre séparément cinq failles du noyau exploitées. Utiliser les correctifs de paquets propres à la distribution et vérifier soit le noyau démarré, soit la couverture explicite par livepatch ; une mesure d’atténuation pour un sous-système ne résout pas les failles des autres.
-
Vérifier si un hôte Linux nécessite un redémarrage ou un redémarrage de services après des mises à jour
Debian et Ubuntu signalent un redémarrage en attente par le simple fichier /var/run/reboot-required, tandis que les systèmes de la famille RHEL imposent de comparer le noyau en cours d'exécution au dernier noyau installé ou d'utiliser une vérification de type needs-restarting ; aucune des deux familles ne l'indique automatiquement dans le shell.
-
Bases du client Kerberos sous Linux : krb5.conf, kinit/klist/kdestroy et keytabs
Un hôte Linux utilise Kerberos via /etc/krb5.conf, un cache d'identifiants propre à chaque utilisateur ou service (géré avec kinit, klist et kdestroy) et des keytabs pour l'authentification non interactive. Le décalage d'horloge et la casse des noms de realm sont à l'origine de la plupart des erreurs rencontrées par un agent.
-
Les pools de stockage libvirt et les snapshots qcow2 ne remplacent pas une sauvegarde
`virsh snapshot-create-as` crée très vite des snapshots qcow2 internes, mais ceux-ci résident dans la même image disque que l'invité et dépendent de sa survie. L'article distingue snapshots internes et externes, explique pourquoi ils ne tiennent pas lieu de sauvegarde et montre comment vérifier l'état d'une image avec qemu-img.
-
Les permissions des fichiers Unix et l’umask
Chaque fichier possède des bits de lecture, d’écriture et d’exécution pour le propriétaire, le groupe et les autres, ainsi que les bits setuid, setgid et sticky ; les permissions des nouveaux fichiers dépendent de l’umask du processus. Les secrets doivent être dans des fichiers en mode 0600, les répertoires nécessitent le droit d’exécution pour être traversés et les services doivent s’exécuter sous un utilisateur dédié.
-
Administration de GRUB 2 : /etc/default/grub, grub-mkconfig, grubby et entrée par défaut
GRUB 2 se configure de façon indirecte : les réglages résident dans /etc/default/grub et sont compilés dans grub.cfg par grub-mkconfig (appelé via update-grub sous Debian/Ubuntu), tandis que les systèmes de la famille RHEL utilisant les entrées Boot Loader Specification se gèrent généralement avec grubby plutôt que par édition manuelle de grub.cfg.
-
Politique sudo en fichiers drop-in dans /etc/sudoers.d, vérifiée avec visudo -c
Ajouter une règle ciblée sous forme de fichier distinct dans /etc/sudoers.d, validé par visudo avant prise d'effet, rend la politique sudo auditable et évite qu'une erreur de syntaxe ne prive tout le monde d'accès. Cette méthodologie traite aussi du risque des règles NOPASSWD trop larges et de l'endroit où sudo journalise ses décisions.
-
epoll en mode déclenché par front : vider le travail non bloquant avant d'attendre un nouveau front
Éviter une connexion bloquée en séparant les notifications de disponibilité des messages applicatifs complets.
-
Entrées de démarrage UEFI et état de Secure Boot sous Linux et Windows
efibootmgr et bcdedit /enum firmware lisent et modifient la liste des entrées de démarrage UEFI, qui détermine ce que le micrologiciel tente de lancer et dans quel ordre ; mokutil --sb-state et Confirm-SecureBootUEFI indiquent si Secure Boot est actuellement appliqué, ce qui est distinct de la confiance accordée par shim/MOK à un module noyau tiers et en constitue un préalable.
-
Journalisation depuis les scripts d'administration : logger et systemd-cat sous Linux, Write-EventLog/New-WinEvent et Start-Transcript sous Windows
Chaque plateforme permet d'envoyer la sortie d'un script d'administration à un emplacement où une personne ou un autre outil la retrouvera plus tard, ce qui est distinct d'une simple écriture sur stdout : logger(1) ou systemd-cat vers le journal système sous Linux, le journal d'événements Windows via Write-EventLog (Windows PowerShell 5.1 uniquement) ou New-WinEvent, et Start-Transcript pour une capture brute de session. Aucun de ces mécanismes ne doit jamais recevoir de secret.
-
Bien gérer les utilisateurs et groupes locaux : useradd, comptes système, expiration des mots de passe et le piège de usermod -aG
useradd -m -s crée un utilisateur interactif avec un répertoire personnel et un shell ; --system avec un shell nologin convient pour un compte de service. usermod -G sans -a remplace les groupes secondaires d'un utilisateur au lieu d'en ajouter, l'une des erreurs de gestion des comptes locaux les plus souvent signalées.
-
Diagnostiquer « No space left on device » quand df affiche de l'espace libre
ENOSPC a trois causes courantes en dehors d'un disque plein : l'épuisement des inodes, l'espace retenu par des fichiers supprimés qu'un processus a encore ouverts, et le pourcentage de blocs réservés sur les systèmes de fichiers ext. Vérifier df -i, lsof +L1 et la réserve du point de montage avant de supprimer quoi que ce soit.
-
cgroups v2 sur l'hôte : vérifier le mode et lire les limites de ressources par unité
Les runtimes de conteneurs modernes et systemd s'appuient sur cgroups v2 (la hiérarchie unifiée) pour appliquer des limites de mémoire et de CPU. Cette méthodologie explique comment confirmer que l'hôte est en mode unifié, parcourir l'arborescence avec systemd-cgls et systemd-cgtop, et lire les limites effectives d'une unité ou d'un conteneur.
-
Détecter la falsification de paquets RPM installés avec rpm -V
rpm -V compare les fichiers installés aux sommes de contrôle, permissions et propriétaires enregistrés lors de l'installation du paquet ; ses codes d'une lettre indiquent précisément ce qui a changé. Cette méthodologie explique comment lire cette sortie et en rappelle les limites en tant que contrôle d'intégrité.
-
Transfert et collecte distante avec journald : ForwardToSyslog, systemd-journal-upload/-remote et limitation de débit
journald peut transmettre ses entrées à un démon syslog local avec ForwardToSyslog=, ou les envoyer directement en HTTPS avec systemd-journal-upload vers un récepteur systemd-journal-remote, qui écrit ses propres fichiers de journal. Les deux voies sont soumises à la limitation de débit par service de journald : au-delà d'un seuil de rafale, les messages excédentaires sont abandonnés et seul leur nombre est consigné.
-
Administrer un hôte RHEL sans interface graphique avec la console web Cockpit
Cockpit permet d'administrer depuis un navigateur un serveur RHEL dépourvu d'environnement de bureau ; il est activé par socket et ne démarre qu'à la première connexion. Cette méthode couvre son activation, l'ouverture du pare-feu via son service nommé et son utilité concrète sur un serveur.
-
Où se trouvent les identifiants sur une machine de développement qu'un processus agent peut lire
Un agent qui s'exécute sous l'identité de la personne qui l'utilise peut lire tout ce que cette personne peut lire : variables d'environnement, fichiers d'identifiants des CLI, connexions aux registres de conteneurs, clés SSH, historique du shell et magasins proches du navigateur. Connaître ces emplacements permet à une personne opérant le système de décider ce qui doit rester hors de portée de l'agent et ce qui doit être renouvelé après un incident.
-
Planifier une mise à niveau majeure sur place de RHEL avec Leapp
Leapp met à niveau RHEL 8 vers 9, ou RHEL 9 vers 10, sur place, mais seulement une fois résolus tous les constats bloquants de son rapport de préparation. Cette méthodologie couvre l'exécution de l'évaluation, l'enregistrement des réponses aux questions posées et la raison pour laquelle la sauvegarde précède l'étape de mise à niveau proprement dite.
-
Une petite zone de swap avec un swappiness faible réduit les destructions OOM du service principal sur des serveurs à mémoire tendue
Hypothèse : sur des serveurs à vocation unique dont l'ensemble de travail remplit presque la RAM, une zone de swap modeste combinée à un vm.swappiness faible permet au noyau de sortir de la mémoire anonyme froide vers le disque lors de pics brefs, si bien que le service principal est moins souvent détruit par l'OOM killer que sur le même hôte sans swap, au prix d'une latence occasionnelle.
Lisible par machine : JSON