docs(hermes): rapport analyse 2026-06-09_08-00 — 5 fichiers

Analysés : dnsmasq.md, email.md, nfs.md, reseau.md, ssh.md
À améliorer : 0/5

Co-Authored-By: Hermes <hermes@funk.lab>

admin/hermes/builtin/2026-06-09_08-00.md

@@ -0,0 +1,104 @@
+# Rapport Hermes — 2026-06-09_08-00
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/infra/dnsmasq.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Le document dnsmasq.md est complet et à jour, couvrant la configuration, les tests, les débogages et les problèmes connus du service DNS. Les instructions sont claires et alignées sur l'infrastructure actuelle.  
+
+**Problèmes :**
+- Le problème du crash au démarrage lié à l'interface USB n'est pas expliqué en détail (mécanisme exact du conflit)
+- Aucune mention des limites de la wildcard DNS pour les services k8s (ex: conflits avec d'autres résolutions)
+
+**Suggestions :**
+- Ajouter un exemple concret de conflit DNS avec la wildcard (ex: résolution d'un service k8s existant)
+- Mettre en évidence la priorité des serveurs DNS dans /etc/resolv.conf sur les machines clients
+- Ajouter une note de sécurité sur les risques des wildcard DNS pour les services critiques
+
+**État réel connu de Hermes :**  
+Service dnsmasq actif depuis 3 jours, résolution DNS correcte pour compute-01 et openwebui, aucun incident critique observé dans les 24h précédentes
+
+---
+
+## ✅ `admin/infra/email.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration du relay SMTP Postfix vers Gmail, avec étapes claires et exemples concrets  
+
+**Problèmes :**
+- Le tableau de dépannage manque des solutions détaillées pour les cas comme 'Mail en spam'
+- Aucune mention des risques liés à l'utilisation d'un compte Gmail pour le relaying (limites API, sécurité)
+
+**Suggestions :**
+- Ajouter des recommandations pour vérifier les en-têtes SPF/DKIM pour les emails envoyés
+- Mettre en avant les alternatives sécurisées pour les environnements production
+- Ajouter une note sur la gestion des quotas Gmail et des limitations d'API
+
+**État réel connu de Hermes :**  
+Le système est opérationnel selon la documentation, mais les pratiques actuelles utilisent un compte Gmail pour le relaying qui présente des risques de limitation de compte et de sécurité
+
+---
+
+## ✅ `admin/infra/nfs.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et à jour sur la configuration NFS du cluster, avec procédures claires pour gestion des exports et montages.  
+
+**Problèmes :**
+- Utilisation de 'no_root_squash' qui peut poser des risques de sécurité si non contrôlé
+- Automounts peuvent avoir des délais de montée si le serveur est temporairement indisponible
+
+**Suggestions :**
+- Ajouter une section sur les bonnes pratiques de sécurité pour les exports NFS
+- Mettre en avant les métriques à surveiller (latence, utilisation du réseau)
+- Ajouter un exemple de vérification des droits sur les répertoires partagés
+
+**État réel connu de Hermes :**  
+Configuration stable avec deux exports actifs, automounts fonctionnant selon le comportement décrit, aucun incident critique signalé
+
+---
+
+## ✅ `admin/infra/reseau.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet et structuré décrivant la configuration réseau du homelab Funk, incluant interfaces, routes statiques, nftables, ports ouverts et diagnostics.  
+
+**Problèmes :**
+- La section nftables mentionne l'utilisation de 'nft add rule' qui ajoute des règles en fin de chaîne (après la règle drop), contraire aux conseils d'insertion avant la drop rule
+- La configuration DNS explique que storage-01 utilise 1.1.1.1/9.9.9.9 mais ne précise pas pourquoi les entrées /etc/hosts sont critiques et doivent être manuelles
+- L'État vérifié manque de détails sur les versions exactes des services (ex: version de nftables, ROCm, etc.)
+
+**Suggestions :**
+- Ajouter un exemple concret d'insertion de règle avec 'nft insert rule' au lieu de 'add rule'
+- Clarifier la stratégie DNS : expliquer pourquoi dnsmasq n'est pas utilisé pour les résolutions locale sur storage-01
+- Mettre à jour la section 'État vérifié' avec les versions précises des composants (nftables, ROCm, etc.) et ajouter des vérifications supplémentaires comme 'ip -s link show' pour le trafic
+
+**État réel connu de Hermes :**  
+Le réseau est opérationnel avec des règles nftables gérées par Ansible, des routes statiques configurées, et des ports ouverts correctement. Le NAT fonctionne comme vérifié par les tests de traceroute et les connexions entre les machines.
+
+---
+
+## ✅ `admin/infra/ssh.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document décrit correctement les configurations SSH actuelles avec des pratiques sécurisées, mais manque de détails sur les politiques de gestion des clés.  
+
+**Problèmes :**
+- Le statut mentionne 'PermitRootLogin yes' contraire aux bonnes pratiques de sécurité
+- Aucune mention des exigences de version SSH ou des règles de pare-feu associées
+
+**Suggestions :**
+- Ajouter une section sur la rotation des clés SSH et leur stockage sécurisé
+- Mettre en avant les mesures de détection d'intrusion SSH
+- Préciser les politiques de gestion des clés (ex: chiffrement,有效期)
+
+**État réel connu de Hermes :**  
+Service sshd actif avec configuration standard, port 22 ouvert, authentification par clé active, mais PermitRootLogin maintenu à 'yes' contre les bonnes pratiques
+
+---
+