# Rapport Hermes — 2026-06-07_14-00
> 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é** : Documentation complète et actualisée sur la configuration et la gestion de dnsmasq dans le lab, avec des exemples de tests et des solutions aux problèmes connus.  

**Problèmes :**
- La section sur l'ajout d'entrées DNS mentionne un template MetalLB non implémenté
- Le fix permanent pour le problème de démarrage utilise un fichier de configuration manuellement mentionné sans lien vers le répertoire réel

**Suggestions :**
- Ajouter des exemples concrets de commandes Ansible pour le playbook dnsmasq
- Mettre à jour le template MetalLB avec un exemple de configuration complet
- Inclure une vérification des dépendances réseau dans la section de tests

**État réel connu de Hermes :**  
Service actif depuis 3 jours, résolution DNS correcte pour les hôtes clés, aucun incident critique signalé

---

## ✅ `admin/infra/email.md` — 8/10

**Statut** : à_jour  
**Résumé** : Le document décrit correctement la configuration du relais SMTP via Postfix vers Gmail, avec des étapes claires et des vérifications pertinentes. Quelques améliorations mineures sont possibles.  

**Problèmes :**
- Le symptôme 'Mail en spam' mentionne 'Expéditeur no' (typo probable, devrait être 'no-reply' ou 'nobody@domain.com')
- Le mot de passe App Password dans l'exemple contient des espaces (format non standard), bien que le document indique que c'est acceptable

**Suggestions :**
- Corriger le typo dans la section dépannage ('Expéditeur no' → 'no-reply' ou 'nobody@domain.com')
- Préciser que les commandes 'make apply-storage' et 'make vault-*' sont des commandes personnalisées du projet, pour éviter la confusion avec des outils standards

**État réel connu de Hermes :**  
La configuration décrite est correcte et fonctionnelle, mais nécessite une vérification pratique des règles de réécriture des expéditeurs et des tests de relais SMTP

---

## ✅ `admin/infra/nfs.md` — 9/10

**Statut** : à_jour  
**Résumé** : Documentation complète et à jour sur la configuration NFS du homelab Funk, avec procédures claires pour les serveurs et clients.  

**Problèmes :**
- La référence 'g01' dans la commande SSH pourrait être un typo (devrait être 'gpu-01')

**Suggestions :**
- Ajouter une note sur la supervision des montages NFS et les mécanismes de reprise après panne
- Mettre à jour le exemple de commande SSH pour utiliser 'gpu-01' comme hôte

**État réel connu de Hermes :**  
Configuration NFS stable et opérationnelle avec deux exports configurés, automount fonctionnel sur gpu-01, et procédures de déploiement via Ansible validées le 2026-06-05

---

## ✅ `admin/infra/reseau.md` — 7/10

**Statut** : à_jour  
**Résumé** : Documentation réseau complète avec configuration nftables, routage et ports ouverts, mais contient une erreur de formatage et une ligne incomplète.  

**Problèmes :**
- La ligne 'ROCm 6.1.2 (llama-s' est incomplète et pourrait être un erreur de saisie
- Les tableaux présentent des incohérences de alignement et de formatage
- Manque de clarification sur la configuration de la Freebox pour le routage LAN cluster
- Les commandes de vérification du NAT pourraient inclure des exemples de traffic spécifique

**Suggestions :**
- Corriger la ligne incomplète concernant ROCm
- Standardiser le format des tableaux avec headers alignés
- Ajouter une note explicite sur la configuration Freebox
- Compléter les exemples de débogage avec des scénarios concrets

**État réel connu de Hermes :**  
Configuration nftables fonctionnelle via Ansible, IP forwarding actif, DNS correctement configuré, mais la version ROCm mentionnée est incomplète et nécessite vérification

---

## ✅ `admin/infra/ssh.md` — 9/10

**Statut** : à_jour  
**Résumé** : Le document décrit correctement les configurations SSH et les bonnes pratiques pour les connexions et transferts de fichiers dans le cluster Funk.  

**Problèmes :**
- Manque d'informations sur l'utilisation de SSH agent forwarding pour les connexions sécurisées
- Aucun exemple sur la gestion des clés SSH via API ou outils programmables

**Suggestions :**
- Ajouter une section sur les meilleures pratiques de chiffrement pour les transferts massifs
- Mettre en avant la vérification régulière des clés avec ssh-keygen -y
- Préciser les politiques de rotation des clés SSH

**État réel connu de Hermes :**  
Le service sshd est actif avec la configuration sécurisée mentionnée (PermitRootLogin=yes, PasswordAuthentication=no). Les clés ED25519 sont utilisées pour les connexions, conformément aux standards de sécurité actuels.

---