Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/docs/runbooks-exploitation.md
Daniel Allaire b95a82251b doc : pas de page « ce qui va te mentir » — les pieges ont trouve leur domicile 
Trois des cinq pieges restants avaient deja une page depuis que la semaine a
avance : le connect() vers le vide (frontiere-opnsense.md + le controle porte
par frontiere-mesurer), le `make prouver` vert (wiki « Verifier le deploye »),
et le banner exchange. Les deux orphelins — kcadm -s sur une map, grafana-cli
dans une base fantome — s'adressent a qui ECRIT du code, pas a qui reprend
l'exploitation : ils n'ont rien a faire dans un chemin de reprise.

Une page separee aurait redit ce que trois autres disent deja, et aurait donc
vieilli mal — le reproche exact qu'on faisait a sa version longue.

La section ⑤ de « Reprendre l'ecosysteme » porte desormais la REGLE qui les
relie (verifier l'instrument avant d'accuser le composant) et un tableau de
trois lignes qui renvoie chacune a son domicile. Plus de promesse en attente.

Et le banner exchange n'avait AUCUN domicile : le savoir vivait dans un
commentaire du Makefile et trois entrees du CHANGELOG — nulle part ou on le
cherche, exactement le mal que la refonte traite. Ecrit en runbook §3, avec
ses trois causes par frequence et ce qui tranche dans l'ordre.

runbooks-exploitation.md declare aussi son lecteur, comme le veut la
convention validee.

Verifie : chaque renvoi controle un a un, prouver.py 0 (33 OK), plan-recette
inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 23:59:02 -04:00

4.8 KiB
Raw Blame History

Runbooks d'exploitation — Set-OPS

Pour qui : l'exploitant, face à une situation. Pas le mainteneur, pas l'apprenant. Le pourquoi vit dans les autres docs/ ; la version pédagogique, dans le wiki. Ici, uniquement le comment faire.

Tu viens de reprendre l'écosystème et tu ne sais pas par où entrer ? Wiki → Reprendre l'écosystème.

1. Un certificat a expiré / le login SSO est cassé

Symptôme : connexion à une app via le SSO échoue après le login ; log Grafana/app : tls: failed to verify certificate: x509: certificate has expired.

Cause fréquente : le cert step-ca a été renouvelé sur disque mais le service (nginx sur l'edge) n'a pas été rechargé → il sert l'ancien cert en mémoire.

Diagnostic-réflexe — comparer le cert servi au cert fichier :

# SERVI (en mémoire par nginx)
echo | openssl s_client -connect infra-edge-01…:443 -servername keycloak.lab… 2>/dev/null \
  | openssl x509 -noout -enddate
# FICHIER (sur disque)
openssl x509 -in /etc/step/certs/infra-edge-01….crt -noout -enddate

Dates différentes (servi < fichier) ⇒ nginx sert un cert périmé.

Fix immédiat : systemctl reload nginx sur l'edge (idem postfix/dovecot/slapd selon le service touché).

Fix permanent (déjà en place) : client_pki_reload_services recharge les vrais consommateurs après chaque renouvellement — edge→nginx, mail→postfix/dovecot, annuaire→slapd. Vérifier : systemctl cat cert-renewer@$(hostname -f).service | grep ExecStartPost. Voir aussi l'unité wiki PKI & confiance (⑤ le renouvellement).

2. Donner Explore/Editor à un opérateur dans Grafana (RBAC)

Par défaut, un utilisateur SSO est Viewer (dashboards seulement, pas Explore). Pour l'élever :

  1. Déclarer l'assignation dans l'inventaire de l'instance (group_vars serveur_keycloak) : 
    serveur_keycloak_role_assignments:
  - { user: <uid>, role: grafana-editor }   # ou grafana-admin
  2. Redéployer Keycloak (make deployer sur le nœud SSO) — kcadm à chaud, sans coupure.
  3. L'utilisateur doit se déconnecter/reconnecter (Grafana applique le rôle à la connexion).

Mapping (défaut du rôle grafana) : grafana-admin→Admin, grafana-editor→Editor, sinon Viewer (serveur_grafana_oidc_role_path). Idéal souverain : piloter par un groupe d'annuaire plutôt qu'un utilisateur explicite. Voir l'unité wiki Autorisation & RBAC.

3. « Connection timed out during banner exchange » — le message qui accuse le réseau

Symptôme : Ansible marque un ou plusieurs hôtes injoignables, avec ce message. On soupçonne le réseau, la route ou le pare-feu. C'est presque toujours autre chose.

Pourquoi le message trompe. À travers la frontière, la poignée TCP aboutit toujours — le pare-feu y répond lui-même sans relayer (voir frontiere-opnsense.md). L'échec ne peut donc pas se présenter comme un « connection refused » franc : il se manifeste plus tard, au moment où le serveur devrait annoncer sa bannière SSH. D'où un message qui parle de délai réseau pour un hôte qui, souvent, n'a jamais rien reçu.

Les trois causes, par fréquence :

  1. La VM n'est pas encore là. make creer-vm rend la main dès que Proxmox a démarré la VM, pas quand elle répond. C'est le cas normal, quotidien, et aucun correctif ne l'abolira : les attentes actives du Makefile existent pour ça.
  2. sshd refuse une rafale. MaxStartups / MaxSessions trop serrés coupent des connexions parfaitement légitimes — deux déploiements interrompus le 2026-08-09, sur des hôtes qui n'avaient ni redémarré ni perdu leur réseau. Réglés par ssh_hardening_max_startups (10:30:60) et ssh_hardening_max_sessions (10), avec l'arbitrage expliqué dans roles/ssh_hardening/defaults/main.yml.
  3. Le réseau, vraiment — le cas le plus rare, et le dernier à examiner.

Ce qui tranche, dans l'ordre :

make hote-afficher HOTE=<nom>                 # l'hôte existe-t-il au plan ?
ssh -v ansible@<ip> 2>&1 | tail -20           # où la négociation s'arrête exactement

Une bannière (SSH-2.0-OpenSSH…) prouve que le chemin est bon et que le problème est applicatif. Aucun connect() ne prouvera quoi que ce soit ici — il réussit vers le vide.

4. Brander une instance Forgejo (identité visuelle)

Activer dans l'inventaire (group_vars serveur_forgejo) :

serveur_forgejo_branding: true
serveur_forgejo_app_name: "Forge Chezlepro"
serveur_forgejo_theme: "forgejo-dark"
serveur_forgejo_meta_description: "…"

Puis redéployer. Le rôle déploie le dossier custom/ officiel (logo/favicon aurore, accent CSS par variables, page d'accueil brandée) — léger, résistant aux MAJ (aucune classe interne touchée). Note : ne s'applique qu'aux Forgejo gérées par Set-OPS.