Ce tutoriel explique comment lister et surveiller les ports ouverts sous Linux, une compétence essentielle pour les administrateurs système. L’article présente trois commandes clés : netstat, ss et lsof, détaillant leurs options pour identifier les ports en écoute, les connexions actives et les processus associés. Il souligne l’importance de cette surveillance pour la sécurité, la performance et le diagnostic réseau, tout en comparant les outils, avec une préférence pour ss, plus moderne et performant.

L’auteur insiste sur les risques liés aux ports non sécurisés, comme les services non autorisés ou les conflits de ressources, et propose des exemples concrets pour filtrer les résultats (par protocole, état ou port spécifique). Les commandes sont accompagnées d’explications sur leur utilité, comme l’option -p pour afficher les processus ou -s pour obtenir des statistiques. Le guide inclut aussi des instructions d’installation pour chaque outil selon les distributions Linux.

Wikidata est une base de données libre et collaborative, gérée par la Fondation Wikimedia, qui stocke des connaissances sous forme de données structurées et interconnectées, contrairement à Wikipédia qui utilise du texte non structuré. Chaque entité y est identifiée par un identifiant unique (Q pour les éléments, P pour les propriétés) et organisée en triplets RDF, formant un graphe de connaissances exploitable par les machines. En 2024, Wikidata comptait plus de 1,5 milliard de triplets sémantiques, interrogeables via un point d'accès SPARQL public.

Cette structure permet des requêtes précises, comme identifier tous les écrivains français nés à Nantes, offrant des résultats exploitables directement, là où une recherche classique ne renverrait que des pages à consulter. Wikidata s'inscrit dans la logique du Linked Open Data, visant à décrire le monde de manière explicite pour une compréhension optimale par les machines, à l'instar des microdonnées JSON-LD utilisées sur les pages web.

Les grands modèles de langage (LLM) apprécient particulièrement Wikidata pour sa fiabilité et sa qualité, car elle fournit une source de données structurées et vérifiables, réduisant ainsi les risques d'hallucinations lors des réponses aux requêtes. Contrairement à des sources moins fiables comme les forums, Wikidata est considérée comme une référence solide pour enrichir les connaissances des modèles d'intelligence artificielle.

Ce mémo complet explique SELinux, un module de sécurité intégré au noyau Linux qui applique un contrôle d'accès obligatoire (MAC), plus strict que les permissions Unix classiques. Contrairement à AppArmor, souvent utilisé sur Debian/Ubuntu, SELinux est activé par défaut sur les distributions comme Red Hat, Fedora ou leurs dérivées. Son objectif principal est de limiter les actions des processus, même en tant que root, renforçant ainsi la protection contre les exploits et les compromissions.

L’article détaille les concepts clés comme les contextes de sécurité, les politiques SELinux et les booléens, essentiels pour configurer et diagnostiquer le système. Il aborde aussi des cas pratiques (Apache, SSH, Samba) et propose des outils comme audit2why ou audit2allow pour analyser et résoudre les blocages, ainsi que des commandes utiles pour gérer les modes Enforcing et Permissive.

Les NAS, contrairement aux PC, fonctionnent en continu et subissent davantage les fortes chaleurs, surtout en 2026 avec des modèles plus puissants et denses. Les disques (HDD, SSD SATA ou NVMe) et processeurs ont des seuils critiques de température à surveiller, les NVMe étant particulièrement sensibles au thermal throttling sans alerte visible. Les NAS fanless sont particulièrement vulnérables au-delà de 35°C ambiants.

Pour éviter les pannes, il est crucial de configurer des alertes thermiques via l’interface du NAS (Synology DSM, QNAP QTS, ASUSTOR ADM, etc.) et de vérifier que les ventilateurs fonctionnent en mode réactif. Les outils natifs permettent de suivre en temps réel les températures des disques et du processeur, avec des notifications par e-mail ou mobile pour les seuils critiques.

En complément, un nettoyage régulier (poussière, ventilation) et une optimisation de l’emplacement du NAS (éviter les pièces surchauffées) réduisent les risques. Les solutions DIY (Unraid, TrueNAS, OpenMediaVault) offrent aussi des plugins ou modules pour une surveillance avancée et des alertes personnalisables.

L’article critique l’idée selon laquelle l’ère de l’IA rendrait la technique obsolète au profit d’une approche strictement "product-first". L’auteur souligne que, malgré les gains de productivité permis par l’IA, la qualité technique reste essentielle pour éviter des problèmes comme des performances médiocres, une architecture chaotique ou des solutions ingérables. Il met en garde contre l’usage abusif de l’argument "product-first" comme prétexte pour négliger la rigueur technique, même si des compromis sont parfois nécessaires pour livrer rapidement.

L’auteur, qui utilise massivement l’IA pour coder, rappelle que savoir quoi construire ne suffit pas : le comment compte toujours, surtout pour des projets complexes. Il cite Rich Hickey pour rappeler que la simplicité et la clarté technique restent des piliers, même avec des outils avancés. L’IA accélère le développement, mais ne dispense pas d’une réflexion sur l’architecture et la maintenabilité.

L’auteur partage son expérience après avoir mis en place un monitoring sur son infrastructure, combinant Uptime Kuma pour un suivi actif et passif des services (Nextcloud, Vaultwarden, etc.) et Beszel pour surveiller les ressources système (CPU, RAM, disque). Ce système simple et léger lui permet d’être alerté en cas de dysfonctionnement ou de dépassement de seuils, tout en visualisant l’historique des performances.

L’analyse révèle un problème inattendu : une sauvegarde de base de données (via un container Docker) était compressée de manière excessive avec XZ en niveau 9, prenant près de 45 minutes trois fois par jour. Un benchmark comparant différents algorithmes et niveaux de compression montre qu’un réglage par défaut (XZ niveau 6 ou GZIP niveau 6) réduit drastiquement le temps de traitement (de 45 à 3 minutes) avec une perte de taille minime (1 Mo sur 229 Mo).

Cette expérience illustre l’importance d’ajuster les paramètres de compression en fonction des ressources disponibles et des besoins réels, évitant ainsi des optimisations contre-productives.