# Rapport Hermes — 2026-06-04_21-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 sur la configuration et la gestion de dnsmasq avec des exemples pratiques, bien que quelques améliorations soient possibles.  

**Problèmes :**
- La section 'Problème connu' mentionne un fix Ansible mais ne précise pas le chemin exact du playbook (le chemin 'playbooks/storage-01.yml' est indiqué mais pourrait être vérifié)
- Le test DNS sur gpu-01 ne montre pas explicitement l'utilisation de 'dig' ou 'nslookup' avec l'IP de storage-01
- Le template MetalLB pour la wildcard DNS n'est pas illustré avec un exemple concret

**Suggestions :**
- Ajouter un exemple de commande 'dig' sur gpu-01 avec l'IP de storage-01 pour clarifier les tests
- Mettre en évidence le template MetalLB avec un exemple de configuration complète
- Vérifier la mise à jour du chemin du playbook Ansible dans la documentation
- Ajouter une note sur la priorité des interfaces réseau dans systemd pour éviter les crashes

**État réel connu de Hermes :**  
dnsmasq fonctionne correctement sur storage-01 avec résolution DNS pour *.lab.local. Le problème USB persistant nécessite le fix systemd mentionné. Les tests DNS montrent des résultats attendus sur les machines du cluster.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail avec des étapes claires et des vérifications  

**Problèmes :**
- Manque de mention sur la rotation sécurisée des App Passwords
- Aucune indication sur la configuration SPF/DKIM pour le domaine de l'expéditeur

**Suggestions :**
- Ajouter une section sur la gestion des mots de passe SMTP (rotation, stockage sécurisé)
- Mettre à jour les exemples de code Python avec des pratiques de sécurité modernes

**État réel connu de Hermes :**  
Le relais SMTP est opérationnel selon la documentation, mais les mesures de sécurité avancées (rotation de clés, vérification SPF/DKIM) ne sont pas implémentées

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète des configurations NFS avec procédures claires, mais manque de sections sur la surveillance et la résolution des problèmes.  

**Problèmes :**
- Aucune mention des mécanismes de surveillance NFS (ex: tools de monitoring, checks réguliers)
- Le comportement d'automontage n'explique pas les retards potentiels lors des premiers accès
- La section GGUF ne détaill pas comment les modèles sont accessibles via NFS (chemins d'accès, permissions)

**Suggestions :**
- Ajouter une section 'Surveillance' avec des commandes comme 'nfsstat', 'showmount', et des règles d'alerte
- Mettre en évidence les retards d'automontage dans le comportement client avec des exemples concrets
- Clarifier le mapping entre les répertoires NFS et les chemins d'accès sur gpu-01 pour les modèles GGUF

**État réel connu de Hermes :**  
Les exports NFS sont actifs sur storage-01 avec les chemins /srv/data/nfs/k8s et /srv/data/models. Les automontages sur gpu-01 fonctionnent selon les paramètres x-systemd. Les modèles GGUF sont effectivement partagés via NFS vers /mnt/models.

---

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

**Statut** : à_jour  
**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et debugging.  

**Problèmes :**
- Manque d'exemples concrets pour l'insertion de règles nftables avant la règle drop terminale
- La note sur les DNS indique que storage-01 utilise 1.1.1.1/9.9.9.9 mais la /etc/hosts contient une entrée manuelle pour gpu-01, ce qui pourrait causer des ambiguïtés

**Suggestions :**
- Ajouter un exemple pratique d'insertion de règle nftables avec position=<handle_avant_drop>
- Clarifier la configuration DNS : préciser que /etc/hosts est le seul point de vérité pour les résolutions critiques
- Mettre en évidence la priorité des règles nftables (insert vs add)

**État réel connu de Hermes :**  
Le réseau est correctement configuré avec Ansible gérant les nftables, les routes statiques et le DNS. Les règles de forwarding sont en place, mais la documentation pourrait être plus précise sur les cas d'usage avancés.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur les connexions SSH avec des alias, transferts de fichiers et débogage, mais manque de détails sur la sécurité et la configuration avancée.  

**Problèmes :**
- Aucune explication sur la configuration de ProxyJump dans les alias
- Utilisation de root@ dans l'exemple de connexion (risque de sécurité)
- Manque de mention sur la gestion des clés (génération, ajout à l'agent)
- Les commandes de débogage pourraient inclure des exemples de vérification des clés

**Suggestions :**
- Ajouter une explication sur la configuration de ProxyJump dans ~/.ssh/config
- Remplacer la connexion root par sudo et mettre en garde contre l'utilisation de root
- Inclure des exemples de génération de clés (ssh-keygen) et d'ajout à l'agent
- Détailler la commande ssh -v pour identifier les erreurs de clé

**État réel connu de Hermes :**  
Les configurations SSH sont actives sur les machines du cluster, les clés ed25519 sont configurées et les transferts fonctionnent via les alias. Les connexions à root sont limitées aux cas spécifiques.

---

