Files

Tallagrand Thierry 2e27e4dfdb Un role de lecture seule dont le mot de passe se genere et ne s affiche pas

Le proprietaire releve, a juste titre, que ma commande precedente lui demandait
de CHOISIR un mot de passe — trois messages apres lui avoir explique qu un
secret se genere et ne se choisit pas. Contradiction corrigee par un script.

creer-role-lecture.sh cree le role evcs_lecture en lecture seule, tire son mot
de passe avec openssl et le depose directement dans le .env a la racine du
depot, sans jamais l afficher : rien a recopier entre deux endroits, donc rien
a exposer dans une capture. Il est rejouable — si le role existe et que son mot
de passe est deja dans le fichier, il ne fait rien.

Deux raisons de ne pas analyser avec le compte evcs : une memoire dont tout
l interet est de ne pas etre reecrite ne se consulte pas avec un compte qui peut
ecrire, et un mot de passe range dans un fichier lisible par un autre compte ne
doit pas etre celui qui gouverne la base. Les privileges par defaut couvrent les
tables futures, et un REVOKE explicite ferme l ecriture par ceinture.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

2026-09-04 01:54:39 +02:00

4.8 KiB

Raw Blame History

Mémoire de mesures EVCS

Deux bases sur 10.10.10.22, décidées le 04/09/2026 : on met les deux en service et on décide à l'usage s'il faut garder les deux.

	rôle	source	résolution
PostgreSQL	ce que n8n calcule — bilan, décisions, prévisions publiées	workflows n8n	cadence des workflows
InfluxDB	ce que Home Assistant observe — tous les états du périmètre énergie	intégration HA	chaque changement d'état

Le raisonnement complet et le comparatif : HANDOFF.md §42 et suivantes.

Pourquoi pas sur 10.10.10.17

Cette machine porte déjà Home Assistant, n8n, openclaw et open-webui. Une mémoire hébergée par la machine dont elle documente les pannes ne survit pas à celles-ci. Le volume n'est pas l'argument : les deux Synology ont des téraoctets libres.

Mise en service

1. Les deux bases (à faire sur 10.10.10.22)

cd /volume2/projects/EVCS/EVCS/deploy/historisation
bash preparer-env.sh      # génère .env avec des secrets aléatoires
docker compose up -d
docker compose logs -f

D'où viennent les secrets

secret	origine
`HA_TOKEN`	existe déjà — repris du `.env` à la racine du dépôt
`POSTGRES_PASSWORD`	créé ici — la base n'existe pas encore, ce fichier décide de son mot de passe
`DOCKER_INFLUXDB_INIT_PASSWORD`	créé ici, idem (InfluxDB exige au moins 8 caractères)
`DOCKER_INFLUXDB_INIT_ADMIN_TOKEN`	créé ici — c'est le jeton que Home Assistant utilisera pour écrire

Aucun ne s'obtient auprès de quelqu'un, et aucun ne doit être choisi à la main : personne ne les tape jamais — les conteneurs les lisent dans .env, et Home Assistant lit le jeton dans son propre secrets.yaml. Une phrase inventée est plus courte et plus devinable qu'elle n'en a l'air ; openssl rand ne l'est pas.

preparer-env.sh refuse d'écraser un .env existant : régénérer les mots de passe d'une base déjà créée la rendrait inaccessible, puisqu'elle continuerait d'attendre les anciens.

Vérifications :

docker compose exec postgres psql -U evcs -d evcs -c '\dt'
curl -s http://10.10.10.22:8086/health
docker compose logs historisation --tail 5

Ports : 5433, et pas 5432

DSM fait tourner son propre PostgreSQL sur 5432, pour ses services internes. Notre base est donc publiée sur 5433. Ce port ne sert qu'à l'analyse depuis un poste de travail :

psql -h 10.10.10.22 -p 5433 -U evcs -d evcs

Les trois conteneurs, eux, se parlent par le réseau interne du compose et par nom de service (postgres:5432) — ni adresse IP en dur, ni dépendance au port publié. Vérifier ce qui occupe un port avant de conclure :

sudo ss -lntp | grep -E '5432|5433|8086'

Le schéma (schema.sql) est appliqué une seule fois, à la création de la base. Pour le faire évoluer ensuite, écrire une migration et la passer à psql : recréer le volume effacerait l'historique, ce qui est précisément ce qu'on cherche à ne plus faire.

2. Brancher Home Assistant sur InfluxDB

⚠️ Demande un redémarrage de Home Assistant, pendant lequel le contrôleur EVCS ne décide plus rien. Jamais entre 01:24 et 07:24, ni pendant une charge. Le bon créneau est le milieu de matinée.

mettre le jeton dans secrets.yaml sous la clé influxdb_token ;
coller le bloc de ha-influxdb.yaml dans configuration.yaml ;
homeassistant.check_config, puis redémarrer.

3. Alimenter PostgreSQL depuis n8n

À faire après l'étape 1 — n8n a besoin que la base existe pour qu'on y crée l'identifiant de connexion.

Accès en lecture pour l'analyse

sudo bash creer-role-lecture.sh

Crée le rôle evcs_lecture en lecture seule et dépose son mot de passe dans le .env à la racine du dépôt. Le mot de passe est généré, jamais choisi, et n'est pas affiché : il va du générateur au fichier, donc rien à recopier et rien à exposer dans une capture.

Deux raisons de ne pas analyser avec le compte evcs : une mémoire dont tout l'intérêt est de ne pas être réécrite ne se consulte pas avec un compte qui peut écrire, et un mot de passe rangé dans un fichier lisible ne doit pas être celui qui gouverne la base.

Le script est rejouable : si le rôle existe déjà et que son mot de passe est dans le .env, il ne fait rien.

Ce qu'aucune des deux ne fait

Elles ne remontent pas dans le passé. La mémoire commence le jour où on les branche : c'est un argument pour les mettre en service vite, pas pour les mettre en service parfaitement.

Sauvegarde

Les deux bases vivent dans des volumes Docker nommés, donc hors du dépôt et hors des sauvegardes Home Assistant. Une mémoire non sauvegardée est une mémoire qu'on perdra une fois — voir HANDOFF.md §34, qui raconte la même histoire pour Home Assistant.

4.8 KiB Raw Blame History