# Rapport Hermes — 2026-06-07_20-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é** : Le document dnsmasq.md est complet et à jour, couvrant la configuration, les tests, les bonnes pratiques et les résolutions de problèmes connus. Les étapes de vérification et de maintenance sont bien documentées.  

**Problèmes :**
- Le problème du crash au démarrage lié à l'interface USB n'est pas résolu dans le fichier (il faut appliquer le fix systemd)
- Le template MetalLB n'est pas encore configuré dans les exemples DNS

**Suggestions :**
- Ajouter une note explicite sur la priorité des interfaces réseau dans systemd
- Mettre à jour le template MetalLB avec l'exemple d'address=/.lab.local/192.168.10.200
- Ajouter une vérification des règles nftables dans la section de test

**É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é

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète pour configurer un relay SMTP Postfix vers Gmail, avec étapes d'installation, vérification et dépannage.  

**Problèmes :**
- Manque de mention des considérations de sécurité (SPF/DKIM) malgré l'utilisation de Gmail
- Le test d'email utilise le même adresse pour expéditeur et destinataire, ce qui n'est pas idéal
- Aucune mention des cas d'erreur liés à la révocation du App Password
- Les étapes d'installation supposent une connaissance préalable des outils Ansible/vault

**Suggestions :**
- Ajouter une note sur la sécurité SPF/DKIM même si Gmail ne les requiert pas
- Proposer un exemple de test avec des adresses différentes
- Mettre à jour la procédure pour régénérer le App Password en cas de révocation
- Ajouter une explication simplifiée pour les utilisateurs sans expérience Ansible

**État réel connu de Hermes :**  
Le setup est fonctionnel selon la description, mais les cas d'edge (ex: authentification échouée, spam) nécessitent des vérifications supplémentaires

---

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

**Statut** : à_jour  
**Résumé** : La documentation NFS est complète et conforme à la configuration actuelle du cluster, avec des exports corrects et des procédures validées.  

**Suggestions :**
- Ajouter une note sur la surveillance des performances NFS (ex: nfsstat, iostat)
- Mettre à jour les exemples de commandes pour inclure les options de sécurité (ex: sec=sys, nosec)
- Ajouter une section sur la sauvegarde des données NFS critiques

**État réel connu de Hermes :**  
Configuration stable avec exports actifs, services nfs-server opérationnels, automounts clients fonctionnant correctement avec timeout de 30s. Aucun élément critique à corriger.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète du réseau Funk avec configurations nftables, routage et interfaces, mais présente quelques incohérences techniques.  

**Problèmes :**
- La mention de HSA_OVERRIDE_GFX_VERSION=10.3.0 pour RX 6704 est incorrecte (le GPU est un RX 6700XT gfx1031)
- La section nftables manque des exemples concrets de règles d'insertion avant la règle drop
- La note sur les ports ouverts ne précise pas les protocoles exacts pour les ports 111/2049 (SUNRPC)
- Le statut final est incomplet (mention de 'llama-s' coupé)

**Suggestions :**
- Ajouter un exemple concret de règle nftables avec position d'insertion
- Mettre à jour la version GPU pour correspondre au RX 6700XT
- Préciser les protocoles pour les ports 111/2049
- Compléter le statut final avec la version complète de ROCm

**État réel connu de Hermes :**  
Le réseau fonctionne correctement avec nftables géré par Ansible, les routes statiques sont configurées, et les ports critiques sont ouverts. Le debug NAT fonctionne comme attendu.

---

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

**Statut** : à_jour  
**Résumé** : Le document SSH décrit correctement les connexions, transferts et configurations essentielles avec des exemples pratiques, mais manque de détails sur certaines pratiques avancées.  

**Problèmes :**
- Aucune mention des clés SSH pour les nœuds Kubernetes
- Pas de section sur la rotation des clés ou leur sauvegarde
- Les commandes de débogage pourraient inclure des scénarios plus variés

**Suggestions :**
- Ajouter une section sur la gestion des clés pour les nœuds Kubernetes
- Inclure des instructions pour la rotation sécurisée des clés SSH
- Détailler les pratiques de chiffrement pour les transferts sensibles
- Ajouter des notes sur l'utilisation d'SSH agent pour les connexions multiples

**État réel connu de Hermes :**  
Le service sshd est actif avec la configuration sécurisée : Port 22, PermitRootLogin=yes, PasswordAuthentication=no, PubkeyAuthentication=yes. Aucun élément critique détécté dans les configurations des hôtes.

---