Daniel Allaire
19871894ed
Technolibre remonte depuis zero une seconde fois — 14 hotes, 2588 taches ok, 0 failed. Deux defauts trouves en chemin. LE JETON KEYCLOAK VIVAIT 60 SECONDES. Il etait pris dans politique-mdp.yml — le 2e des neuf fichiers du role — et reutilise jusqu'au 8e. Entre les deux, six fichiers de travail dont groupes-ldap.yml et ses reprises espacees de 15 s. Sur une construction NEUVE le temps depasse la minute : 401. Sur un REJEU tout est converge, ca va vite, ca passe. D'ou les deux echecs du matin, chaque fois suivis d'un succes au rejeu, qui donnaient l'illusion d'une course au demarrage de Keycloak. J'avais ecrit alors ne pas avoir de mesure qui le prouve — c'etait juste, et la cause etait l'AGE du jeton. jeton-admin.yml en prend un frais la ou on s'en sert. GRAFANA : UN ECHEC TRANSITOIRE RENDU ILLISIBLE. Premier demarrage, apres 67 s de migrations : « failed to create admin user: no such column: uid », alors que la migration qui ajoute cette colonne etait journalisee comme reussie. Base neuve : tout remigre, service actif, colonne presente. L'incident ne s'est pas reproduit et Chezlepro ne l'a jamais eu — je n'ai donc PAS corrige la cause, faute de l'avoir reproduite. J'ai corrige ce qui la rendait indechiffrable : - Restart=on-failure venait du paquet SANS RestartSec, donc 100 ms : six relances en une seconde, chacune rejouant les migrations sur la meme base SQLite. Un echec unique se presentait comme un desastre. RestartSec=10 ; - la rotation du compte de secours echouait cinq fois sous no_log en annoncant « the output has been hidden », alors que la vraie cause etait ailleurs et lisible : le serveur ne demarrait pas. Une attente explicite sur le port precede desormais la CLI, avec un message qui renvoie a la PREMIERE erreur du journal. Troisieme fois dans la journee que no_log masque la cause au moment ou elle sert : une garde qui protege un secret ne doit pas emporter le diagnostic. Verifie : 7 devis sur Technolibre — MTU, identite, certificats, PostgreSQL, courriel, frontiere CONFORME ; prouver.py 35 OK ; ansible-lint production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
32 lines
1.5 KiB
YAML
32 lines
1.5 KiB
YAML
---
|
|
# Un jeton d'administration FRAIS, a inclure juste avant de s'en servir.
|
|
#
|
|
# POURQUOI CE FICHIER EXISTE. Le jeton etait obtenu une seule fois, dans
|
|
# `politique-mdp.yml` — le 2e des neuf fichiers du role — puis reutilise jusqu'au 8e.
|
|
# Or le jeton `admin-cli` du realm `master` vit **60 secondes** par defaut. Entre les
|
|
# deux, six fichiers de travail, dont `groupes-ldap.yml` et ses reprises espacees de 15 s.
|
|
#
|
|
# Sur un deploiement NEUF, le temps ecoule depasse la minute et l'appel suivant se prend
|
|
# un 401. Sur un REJEU, tout est deja converge, ca va vite, et ca passe. C'est exactement
|
|
# ce qu'on a observe le 2026-08-10 : echec sur la construction, succes au rejeu — deux
|
|
# fois, ce qui donnait l'illusion d'une course aleatoire au demarrage de Keycloak.
|
|
#
|
|
# Un jeton se prend donc la ou on l'utilise, jamais « une fois pour toutes ». C'est
|
|
# gratuit : Keycloak repond en quelques millisecondes en local.
|
|
- name: Obtenir un jeton d'administration frais
|
|
ansible.builtin.uri:
|
|
url: "http://localhost:8080/realms/master/protocol/openid-connect/token"
|
|
method: POST
|
|
body_format: form-urlencoded
|
|
body:
|
|
grant_type: password
|
|
client_id: admin-cli
|
|
username: "{{ serveur_keycloak_admin_user }}"
|
|
password: "{{ serveur_keycloak_admin_password }}"
|
|
status_code: [200]
|
|
register: serveur_keycloak_pol_jeton
|
|
no_log: true
|
|
# Keycloak peut encore etre en train de recharger apres une tache precedente.
|
|
retries: 5
|
|
delay: 4
|
|
until: serveur_keycloak_pol_jeton is succeeded
|