# 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.

---

