duffyduckandClaude Opus 5
2ca6ed2f70
Der Tester fragte praezise: Loest cleanup -> rehash OHNE erneutes Siegeln, ueber NICHT versiegelten Inhalt, etwas Automatisches aus - oder nur die Prosa in verify, die ein Mensch lesen muss? Gemessen statt behauptet: Es loeste bereits aus, aber als Nebenwirkung. Ein Rehash aendert jeden Hash, also stimmt der beglaubigte Kettenkopf nicht mehr und der bestehende Vergleich schlug an. Das funktioniert, ist aber ein Zufallstreffer - verschoebe sich der Anker, waere der Melder lautlos weg. Und die Meldung hiess "Eintrag wurde veraendert" statt "die Kette wurde neu berechnet", also Wirkung statt Ursache. Jetzt haengt der Alarm an der Sache selbst: Das Gegenbuch fuehrt rehashCount/rehashLast im Buch mit und meldet jede neue Neuberechnung seit der letzten Beglaubigung mit exit 2, samt Zeitpunkt, Zeilenzahl und dem Befund, der unmittelbar davor galt. Dieselbe Lehre wie R184-01 (Gate am Ausloeser statt an der Wirkung) und R185-01 (Wurzelwechsel statt valid). Reihenfolge geaendert, und das war noetig: Der neue Melder steht VOR dem Kopf-Hash-Vergleich, sonst haette immer die unpraezisere Meldung gewonnen. Und der Kopf-Vergleich wird nach einer bestaetigten Neuberechnung uebersprungen - sonst waere die Bestaetigung wertlos, weil ein Rehash den Kopf zwangslaeufig aendert. Beim Bauen aufgefallen, nicht im Entwurf. NOTARY_REHASH_ACK wird mit der ID des Rehash-Eintrags bestaetigt, nicht mit true; IDs steigen streng, ein stehen gelassener Wert passt beim naechsten Vorgang nicht mehr. Ein fehlender beglaubigter Eintrag alarmiert weiterhin immer: bestaetigt wird die Neuberechnung, nicht das Verschwinden von Zeilen. Getestet mit echtem Gegenbuch gegen ein echtes CRM, SSH-signiertes lokales Buch: Waesche ohne Datenbankzugriff -> CRM meldet valid:true und chainGaps:[], Gegenbuch exit 2 mit der Neuberechnung als Ursache. Falsche Ack-ID weiter exit 2, richtige exit 0, Folgelauf ruhig. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
64 lines
2.4 KiB
YAML
64 lines
2.4 KiB
YAML
# Gegenbuch für OpenCRM
|
||
# =====================
|
||
# Gehört auf einen EIGENEN Rechner – nicht dorthin, wo OpenCRM läuft.
|
||
#
|
||
# Richtung der Verbindung (das ist der eigentliche Schutz):
|
||
# Gegenbuch ──holt lesend──> OpenCRM (HTTPS, Token nur mit audit:read)
|
||
# OpenCRM ─────────────────> (kennt das Gegenbuch nicht)
|
||
#
|
||
# Wer OpenCRM übernimmt, kommt damit nicht an dieses Buch heran. Deshalb holt
|
||
# das Gegenbuch selbst, statt sich etwas schicken zu lassen.
|
||
#
|
||
# Start:
|
||
# cp .env.example .env # Werte eintragen
|
||
# docker compose up -d
|
||
#
|
||
# Zwei Bücher auf einer Maschine sind vorgesehen (Produktion und Test): zwei
|
||
# getrennte Dienste mit getrennten Verzeichnissen und getrennten Schlüsseln.
|
||
# Welche laufen, steuert COMPOSE_PROFILES in der .env.
|
||
|
||
services:
|
||
prod:
|
||
build: .
|
||
container_name: gegenbuch-prod
|
||
restart: unless-stopped
|
||
profiles: ["prod"]
|
||
environment:
|
||
INSTANZ: prod
|
||
CRM_URL: ${PROD_CRM_URL}
|
||
CRM_EMAIL: ${PROD_CRM_EMAIL}
|
||
CRM_PASSWORD: ${PROD_CRM_PASSWORD}
|
||
NOTARY_INTERVAL: ${PROD_INTERVAL:-3600}
|
||
NOTAR_EMAIL: ${NOTAR_EMAIL:-gegenbuch@localhost}
|
||
# Nur beim allerersten Lauf einmalig auf true, danach wieder leeren:
|
||
NOTARY_GENESIS_ACK: ${PROD_GENESIS_ACK:-}
|
||
# Nur nach geklärtem Verlust des Beobachtungsspeichers, siehe README:
|
||
NOTARY_ADOPT_ACK: ${PROD_ADOPT_ACK:-}
|
||
# Nur nach einem GEWOLLTEN Siegelwechsel, mit der neuen Wurzel:
|
||
NOTARY_SEAL_ACK: ${PROD_SEAL_ACK:-}
|
||
# Nur nach einer GEWOLLTEN Neuberechnung, mit der ID des Rehash-Eintrags:
|
||
NOTARY_REHASH_ACK: ${PROD_REHASH_ACK:-}
|
||
volumes:
|
||
# Buch, Schlüssel, Beobachtungsspeicher und Statusdatei.
|
||
# Dieses Verzeichnis ist das Gegenbuch – es gehört ins Backup.
|
||
- ${PROD_DIR:-./data/prod}:/gegenbuch
|
||
|
||
staging:
|
||
build: .
|
||
container_name: gegenbuch-staging
|
||
restart: unless-stopped
|
||
profiles: ["staging"]
|
||
environment:
|
||
INSTANZ: staging
|
||
CRM_URL: ${STAGING_CRM_URL}
|
||
CRM_EMAIL: ${STAGING_CRM_EMAIL}
|
||
CRM_PASSWORD: ${STAGING_CRM_PASSWORD}
|
||
NOTARY_INTERVAL: ${STAGING_INTERVAL:-3600}
|
||
NOTAR_EMAIL: ${NOTAR_EMAIL:-gegenbuch@localhost}
|
||
NOTARY_GENESIS_ACK: ${STAGING_GENESIS_ACK:-}
|
||
NOTARY_ADOPT_ACK: ${STAGING_ADOPT_ACK:-}
|
||
NOTARY_SEAL_ACK: ${STAGING_SEAL_ACK:-}
|
||
NOTARY_REHASH_ACK: ${STAGING_REHASH_ACK:-}
|
||
volumes:
|
||
- ${STAGING_DIR:-./data/staging}:/gegenbuch
|