# Rapport Hermes — 2026-06-03_11-38 > Branche : `hermes/daily-work` · Fichiers analysés : 5 --- ## Résumé - ✅ À jour : 5 - ⚠️ À améliorer : 0 ## ✅ `admin/infra/dnsmasq.md` — 9/10 **Statut** : à_jour **Résumé** : Document complet et structuré décrivant la configuration et la gestion de dnsmasq sur le cluster Funk, avec des exemples concrets et des solutions à problèmes. **Problèmes :** - La section 'Problème connu' mentionne un fix systemd mais ne précise pas que ce fichier de configuration doit être déployé via Ansible - Les commandes 'sudo journalctl' ne spécifient pas le besoin de sudo pour les utilisateurs non-root - Le template MetalLB n'est pas encore implémenté dans le document **Suggestions :** - Ajouter un avertissement sur la nécessité de relancer dnsmasq après modification de la config - Mettre en évidence les commandes critiques avec des couleurs ou des balises visuelles - Ajouter une vérification automatique du statut des interfaces réseau dans les exemples - Préciser les dépendances Ansible pour le fix du problème connu **État réel connu de Hermes :** ok --- ## ✅ `admin/infra/email.md` — 9/10 **Statut** : ok **Résumé** : Document complet sur la configuration du relais SMTP Postfix vers Gmail, avec étapes claires et vérification détaillée. **Problèmes :** - Manque de mention sur la sécurité (SPF/DKIM/DMARC) pour les emails relayés - Aucune indication sur la gestion des droits d'accès au vault_postfix_relay_password - Le chapitre 'Utilisation' pourrait préciser les limites des exemples (ex: nécessité de sudo) **Suggestions :** - Ajouter une section sur la configuration SPF/DKIM pour les emails relayés - Mettre en avant les bonnes pratiques de stockage des App Passwords - Préciser les contraintes d'exécution des exemples (ex: nécessité de sudo) **État réel connu de Hermes :** Le relais SMTP fonctionne selon les tests décrits, avec des logs postfix corrects. Les App Passwords sont gérés via le vault. Les IPs autorisées incluent le réseau k8s et le LAN. --- ## ✅ `admin/infra/nfs.md` — 9/10 **Statut** : à_jour **Résumé** : Documentation complète sur la configuration NFS avec des procédures claires pour serveur et client, mais présente quelques redondances et opportunités d'optimisation. **Problèmes :** - Les exports NFS définis (/srv/data/nfs/k8s et /srv/data/models) sont redondants avec le répertoire parent /srv/data/nfs/k8s - Les paramètres de montage sur le client (soft, timeo=30, retrans=3) pourraient être documentés avec des explications sur leur impact - La section 'Ajouter un nouveau répertoire partagé' manque de précision sur les droits spécifiques à assigner (uid/gid) **Suggestions :** - Simplifier les exports en ne définissant que /srv/data/nfs/k8s et ajouter les autres répertoires comme sous-dossiers - Ajouter une explication sur la gestion des montages automount lors de l'arrêt/redémarrage du serveur - Préciser les bonnes pratiques pour les permissions (ex: utiliser le UID/GID du service concerné) **État réel connu de Hermes :** Le setup NFS est actif sur storage-01 avec les exports configurés. Les clients gpu-01 montent correctement les répertoires via automount. Les modèles GGUF sont accessibles via NFS comme prévu. --- ## ✅ `admin/infra/reseau.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation structurée et complète sur la configuration réseau du cluster Funk, avec des exemples pratiques et des conseils pour nftables. **Problèmes :** - La section nftables manque d'exemples concrets de règles applicatives - Le diagramme d'architecture réseau manque d'illustration visuelle - Les commandes de débogage pourraient inclure des tests de connectivité plus complets - Le rôle des interfaces WAN/LAN pourrait être mieux expliqué pour les nouveaux utilisateurs **Suggestions :** - Ajouter un schéma réseau visuel (diagramme de connections) - Compléter la section nftables avec des exemples de règles typiques - Inclure des tests de ping/traceroute pour chaque configuration - Ajouter une note sur la sécurité réseau (firewalld vs nftables) - Mettre en évidence les commandes critiques avec des couleurs ou des emojis **État réel connu de Hermes :** Le réseau fonctionne correctement avec la configuration documentée, mais des améliorations sont possibles pour la sécurité et la documentation. --- ## ✅ `admin/infra/ssh.md` — 7/10 **Statut** : à_jour **Résumé** : Le document décrit correctement les connexions SSH et transferts de fichiers avec des alias et des exemples pratiques, mais manque de détails sur la sécurité et les bonnes pratiques. **Problèmes :** - Aucun mention de politique de rotation des clés SSH - Manque d'explications sur l'utilisation de SSH agent forwarding - Les commandes de débogage ne couvrent pas les cas d'erreur liés aux tunnels SSH - Aucun exemple sur la configuration avancée des clés (ex: SSH config pour plusieurs hôtes) **Suggestions :** - Ajouter une section sur les bonnes pratiques de sécurité (rotation de clés, permissions des fichiers .ssh) - Préciser les risques liés aux connexions en root et recommander des alternatives - Ajouter des exemples de débogage pour les problèmes de tunnels SSH - Mettre en évidence les différences entre les méthodes de connexion (alias vs ProxyJump) **État réel connu de Hermes :** Le système SSH est opérationnel avec des connexions sécurisées via des clés ed25519, mais les politiques de maintenance des clés et les configurations avancées nécessitent des améliorations. ---