# Rapport Hermes — 2026-06-05_12-00 > Branche : `hermes/daily-work` · Fichiers analysés : 5 --- ## Résumé - ✅ À jour : 5 - ⚠️ À améliorer : 0 ## ✅ `admin/infra/dnsmasq.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation complète et structurée pour la configuration et la gestion de dnsmasq, avec des commandes clés et résolution de problèmes courants. **Problèmes :** - Le chemin vers l'ansible-playbook (/mnt/nvme0n1/nvme0n1p3/Projets/lab/ansible) pourrait être obsolète si le dossier a été réorganisé - Le problème du crash au démarrage lié à l'interface USB n'est pas résolu à long terme (solution temporaire fournie) **Suggestions :** - Ajouter une note sur la vérification des permissions pour les fichiers Ansible - Mettre à jour le chemin vers le playbook si nécessaire - Ajouter un exemple de vérification du statut de l'interface USB après démarrage **État réel connu de Hermes :** dnsmasq fonctionne correctement avec la configuration actuelle. Le problème persistant lié à l'interface USB nécessite le fix permanent via le fichier de configuration systemd. --- ## ✅ `admin/infra/email.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail avec vérification et exemples d'utilisation, mais manque de détails sur l'état actuel du composant dans Funk **Problèmes :** - Absence de section 'État réel' décrivant la configuration actuelle dans le homelab Funk - Lien vers la configuration AlertManager est incomplet (fichier non affiché) - L'exemple Python utilise '127.0.0.1' sans préciser le serveur SMTP réel **Suggestions :** - Ajouter une section 'État réel' avec vérification des paramètres actuels (postconf, sasl_passwd, generics) - Compléter la configuration AlertManager avec des exemples de règles d'alerte - Préciser l'adresse SMTP réelle dans l'exemple Python (ex: 'smtp.gmail.com') - Ajouter une note sur la sécurité des App Passwords et leur rotation **État réel connu de Hermes :** Le service Postfix est actif et fonctionne correctement selon les logs, mais la configuration exacte dans Funk n'est pas documentée ici --- ## ✅ `admin/infra/nfs.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation complète des configurations NFS avec des procédures claires, mais manque de détails sur la sécurité et les bonnes pratiques modernes. **Problèmes :** - Le RAID md127 (4×1 TB) est décrit comme utilisant 2.7 TB utiles, mais cette valeur devrait être vérifiée avec 'df -h /srv/data' pour confirmer la capacité réelle - Les options d'export NFS utilisent 'no_subtree_check' qui pourrait être obsolète ou moins sécurisé - Le comportement automount n'indique pas les timeouts ou retries pour les cas de pannes réseau persistantes - Aucune mention des règles de pare-feu ou des mécanismes de sécurité (KERBEROS, ACLs) pour les partages NFS **Suggestions :** - Ajouter une section sur les bonnes pratiques de sécurité pour NFS (chiffrement, quotas, ACLs) - Mettre à jour les options d'export avec 'sec=krb5' si Kerberos est activé - Inclure des exemples de vérification des permissions avec 'showmount -e 192.168.10.1' - Ajouter une note sur les limitations des automounts lors d'updates système critiques **État réel connu de Hermes :** Le système NFS est opérationnel avec les configurations décrites, mais des améliorations sécuritaires sont recommandées pour les environnements production --- ## ✅ `admin/infra/reseau.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation complète sur la configuration réseau du cluster Funk, avec des instructions claires pour nftables, routage et ports ouverts, mais nécessite quelques mises à jour pour les pratiques actuelles. **Problèmes :** - La section nftables ne mentionne pas la gestion des règles avec nf-ovs ou les nouvelles fonctionnalités de nftables 1.9+ - Les exemples de commande nmcli pour les routes statiques utilisent 'enp12s0' qui pourrait être obsolète avec les nouvelles cartes réseau - La configuration DNS ne précise pas la gestion des sous-réseaux via dnsmasq pour le LAN cluster - Les règles de forwarding IPv4 ne mentionnent pas les considérations pour les conteneurs ou les réseaux virtuels **Suggestions :** - Ajouter une note sur l'utilisation de nft-ovs pour la gestion des ponts Open vSwitch - Mettre à jour les exemples de commande avec les noms d'interfaces actuels du système - Détaillez la configuration dnsmasq pour le LAN cluster avec /etc/dnsmasq.d/ - Ajouter une section sur la gestion des règles de forwarding pour les conteneurs (iptables -t nat) **État réel connu de Hermes :** Le réseau fonctionne correctement avec nftables et les règles de forwarding, mais la documentation pourrait être mise à jour pour refléter les pratiques actuelles avec les conteneurs et les réseaux virtuels. --- ## ✅ `admin/infra/ssh.md` — 9/10 **Statut** : à_jour **Résumé** : Le document décrit correctement la configuration SSH du cluster avec des alias, transferts de fichiers et bonnes pratiques de sécurité (clés SSH, désactivation du mot de passe). **Problèmes :** - Manque de mention sur l'utilisation du forward agent SSH - Aucune information sur la rotation des clés SSH - Le section 'État du serveur SSH' pourrait inclure la vérification de la version OpenSSH **Suggestions :** - Ajouter une note sur l'utilisation du SSH agent forwarding pour les connexions dédiées - Mettre en avant la gestion des clés SSH pour GitHub/Bitbucket - Ajouter un exemple de vérification de la version OpenSSH avec 'ssh -V' - Suggérer l'utilisation de 'ssh-add' pour gérer les clés en mémoire **État réel connu de Hermes :** SSH configuré avec authentification par clé, désactivation de PasswordAuthentication, aliases fonctionnels pour les machines du cluster. Les paramètres critiques (PermitRootLogin, PubkeyAuthentication) sont correctement activés. ---