# Rapport Hermes — 2026-06-05_00-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 structurée sur la configuration et la gestion de dnsmasq dans le cluster Funk, avec des exemples pratiques et des solutions pour les problèmes courants.  

**Problèmes :**
- La section 'Ajouter une entrée DNS' mentionne un fichier YAML mais ne précise pas les étapes exactes pour appliquer les changements via Ansible.
- Le fix permanent pour le problème de démarrage nécessite une vérification que le playbook Ansible est correctement configuré pour appliquer les overrides systemd.

**Suggestions :**
- Ajouter un exemple concret de commande Ansible pour appliquer les modifications de configuration dnsmasq.
- Mettre en avant la nécessité de tester la configuration avec 'sudo dnsmasq --test' avant de recharger le service.

**État réel connu de Hermes :**  
ok

---

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

**Statut** : ok  
**Résumé** : Document complet et bien structuré décrivant la configuration du relais SMTP Postfix vers Gmail, avec des étapes claires pour l'installation, la vérification et le dépannage.  

**Problèmes :**
- La commande 'make vault-edit' pourrait être ambiguë sans contexte sur la présence d'un script personnalisé.
- L'utilisation de caractères d'espace dans le mot de passe SMTP pourrait poser des problèmes dans certains contextes (ex: API externes).

**Suggestions :**
- Ajouter un schéma visuel de l'architecture de relais SMTP pour améliorer la compréhension visuelle.
- Mettre en avant la rotation périodique des App Passwords pour les bonnes pratiques de sécurité.
- Préciser que le fichier '/etc/postfix/generic' doit être mis à jour après modification du 'smtp_generic_maps'.

**État réel connu de Hermes :**  
La configuration décrite est actuellement en place dans Funk, avec les vérifications de réseau et les tests de relais configurés selon les étapes documentées.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration NFS avec RAID5, exports et automounts, mais avec quelques améliorations possibles.  

**Problèmes :**
- La description du RAID5 indique 4×1 TB = 2.7 TB utiles (mais RAID5 utilise (n-1)*taille, donc 3 TB ici)
- Les options nfsvers=4 sont implicites dans les commandes de montage manuel
- Les exemples de UID/GID dans les étapes d'ajout de répertoire utilisent <uid> et <gid> sans valeurs concrètes

**Suggestions :**
- Préciser le calcul RAID5 (3×1 TB = 3 TB utiles au lieu de 2.7 TB)
- Ajouter timeout=30 aux options de montage pour clarifier le comportement
- Remplacer <uid> et <gid> par des exemples concrets (ex: 1000:1000)
- Ajouter une section sur la surveillance (ex: nfsstat, rpcinfo)
- Mettre en évidence les risques de perte de données avec les options no_root_squash

**État réel connu de Hermes :**  
Le RAID md127 est actif sur storage-01, les exports NFS fonctionnent avec les montages automount sur gpu-01. Les modèles GGUF sont partagés via NFS vers gpu-01.

---

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

**Statut** : à_jour  
**Résumé** : Document complet sur la configuration réseau de storage-01, couvrant interfaces, routes statiques, nftables, ports ouverts et débogage. Manque quelques détails sur la gestion des IP dynamiques.  

**Problèmes :**
- Aucune mention des règles nftables pour le NAT sortant vers le WAN
- Le rôle des chaines 'input'/'output'/'forward' dans nftables est ambigu
- Pas d'explication sur la priorité des règles nftables et le mécanisme de drop terminal

**Suggestions :**
- Ajouter un exemple concret de règles nftables pour le NAT sortant
- Préciser la structure des chaines et la logique de filtrage
- Inclure une vérification des tables nat avec 'nft list table ip nat'
- Ajouter un avertissement sur les risques des règles non-ansiblées

**État réel connu de Hermes :**  
Configuration opérationnelle avec interfaces WAN/LAN configurées, routes statiques implantées, nftables géré par Ansible. Les tests de débogage (traceroute, ping) confirment le fonctionnement du NAT et du routage.

---

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

**Statut** : à_jour  
**Résumé** : Document bien structuré avec des exemples pratiques, mais manque de détails sur la configuration réelle et de bonnes pratiques de sécurité.  

**Problèmes :**
- Mention de l'accès en root (risque de sécurité)
- Aucune mention des bonnes pratiques de chiffrement (ex: use of ed25519)
- Manque de précision sur la configuration réelle des aliases (ex: contenu de ~/.ssh/config)
- Commandes de debug SSH pourraient inclure des exemples avec --quiet ou --verbose pour différents niveaux

**Suggestions :**
- Supprimer ou réviser la section d'accès root
- Ajouter une section sur les bonnes pratiques (chiffrement, gestion des clés)
- Préciser les règles réelles des aliases (ex: ProxyJump configuration)
- Ajouter des exemples de scp avec -C pour compression

**État réel connu de Hermes :**  
Les aliases SSH sont actifs sur storage-01, les clés ed25519 sont configurées, les transferts SCP fonctionnent via ProxyJump. Les connexions root sont désactivées par défaut.

---