ESPO-03, ESPO-10, ESPO-12 und ESPO-20 lasen version aus
defaults/config.php, config.php und config-internal.php. EspoCRM 10 fuehrt
version aber als State-Parameter in data/state.php, und Config::load() liest
die Image-Vorgaben gar nicht. Gemeldet wurde also der Vorgabewert des Images:
nach einem gescheiterten migrate die neue Version, obwohl die Instanz auf der
alten steht.
Jetzt fragen die Skripte EspoCRM ueber "command.php version" - derselbe Wert,
gegen den auch Extensions ihre acceptableVersions pruefen. Aufruf als
www-data mit absolutem Pfad (bootstrap.php wechselt selbst ins
Installationsverzeichnis); akzeptiert wird nur eine Zeile der Form 1.2.3,
damit eine PHP-Warnung nie als Version in ein Custom Field geraet. Die
grep-Rueckfallwege auf config.php entfallen, sie lasen dieselbe falsche Quelle.
Probe gegen die Integrationsinstanz 10.0.8: Ausgabe "10.0.8".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1. Gewartet wird jetzt auf ALLE vier Container, nicht nur auf espocrm.
"health: starting" im Bericht war keine Aussage. Scheitert es, nennt die
Fehlermeldung, welcher Container in welchem Zustand haengt. Gilt fuer
ESPO-03, ESPO-10 und ESPO-12.
2. ESPO-10 raeumt alte Images weg: Es bleiben genau zwei je Anwendung, das
laufende und das vorherige - fuer EspoCRM wie fuer MariaDB. Das vorherige
muss bleiben, sonst zeigt die von ESPO-12 zurueckgerollte Compose auf einen
Tag, der lokal nicht mehr liegt. Alles aeltere fuellte bisher nur das
docker-lv; Docker raeumt von sich aus nichts weg.
3. ESPO-10 zeigt einen eigenen Abschnitt "Datenbank" mit Image, Version und
Digest, analog zum Abschnitt "Instanz", sowie die Images auf der VM.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der vorige Commit hat nur den Kommentar geaendert, der Ersetzungsausdruck griff
nicht. Jetzt lesen alle drei Skripte defaults, config und config-internal in
dieser Reihenfolge; der spaetere Wert gewinnt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ESPO-20 meldete 'EspoCRM-Version nicht ermittelbar'. Ursache ist vermutlich der
relative Pfad: docker exec startet im Arbeitsverzeichnis des Images, data/...
ohne fuehrenden Schraegstrich geht dann ins Leere.
Jetzt absolute Pfade, beide Konfigurationsdateien (config-internal zuerst), als
Rueckfall ein grep ueber den Bind-Mount. Bleibt es leer, zeigt ESPO-20 welche
Dateien es gibt und welche Schluessel sie tragen - dann ist die Ursache nach
einem Lauf bekannt statt nach dreien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Grundeinstellungen gehoeren zum Stand eines Rings wie die Compose: Eine
Aenderung daran soll denselben Freigabeweg nehmen. Die Datei liegt jetzt in
allen drei Ringordnern, die gemeinsame Fassung ist entfallen.
ESPO-03 holt sie aus dem Ordner des jeweiligen Rings; die Zuordnung Ring zu
Ordner steht damit an zwei Stellen und ist in beiden vermerkt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Abnahmelauf meldete 'Version: unbekannt' - das grep auf data/config.php
griff nicht. Jetzt fragt das Skript EspoCRM im Container (config.php und
config-internal.php zusammengefuehrt) und faellt nur ersatzweise auf grep
ueber beide Dateien zurueck.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der erste Lauf hat die Instanz erfolgreich gestartet (db und espocrm healthy,
daemon und websocket gestartet), der Task galt aber als Failed: Die tausenden
Fortschrittszeilen des Image-Pulls haben den Abschlussbericht verdraengt.
up -d laeuft jetzt mit --quiet-pull, die Ausgabe wird aufgefangen und nur bei
Fehlschlag mit den letzten 20 Zeilen gezeigt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Pruefung auf vorhandene Container, docker-compose.yml und data/config.php
entfaellt. Dass der Lauf nur an einer neuen Instanz stattfindet, stellt der Task
ueber If/Then auf espo_zustand sicher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei apt-Fehler ohne eine einzige Zeile aus dem Skript liessen offen, ob
ueberhaupt die Repo-Fassung gelaufen ist. Die Standzeile beantwortet das
kuenftig in der ersten Ausgabezeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Task entscheidet per If/Then auf espo_zustand, ob er laufen darf; die
Skripte brauchen den Wert dann nicht mehr. ESPO-01 nimmt nur noch den
Kundennamen, ESPO-02 kein Argument, ESPO-03 fqdn und ring.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz - sie beruht auf
Tatsachen auf der VM, nicht auf einem Feldwert, und verhindert eine Migration
ohne geprueftes Backup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Statt lokaler Merkmale steuert das Custom Field espo_zustand zentral, was laufen
darf. Jedes der drei Skripte nimmt den Wert als Argument und bricht ohne
Aenderung ab, wenn er nicht NEU ist.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz als Rueckfall
erhalten: Der Zustand im RMM ist von Hand aenderbar, eine laufende Instanz ist
es nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Richtet EspoCRM auf einer vorbereiteten VM zum ersten Mal ein: Verzeichnisse,
Geheimnisse auf der VM erzeugt, config-override.php bereitgelegt, Compose aus
dem Stand des Rings gerendert, up -d, Warten auf app-check, Abschlusspruefung.
Bricht ab, sobald eine Instanz vorhanden ist (Container, Compose-Datei oder
data/config.php). Damit kann dieses Skript keine Migration ohne geprueftes
Backup ausloesen - Aktualisierungen bekommen einen eigenen Weg.
Die Abschlusspruefung misst zugleich die in ADR 0008 offenen Punkte:
Zeichensatz des Servers und Laenge der Record-IDs (36 = UUIDv4 aktiv, sonst
Abbruch). Die Datenbankabfragen laufen im Container und lesen das Passwort dort
aus der Secret-Datei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
