sysops
4e085238b6
install.sh/update.sh übersprangen den Manticore-Block komplett, sobald irgendeine Version schon lief — der Versions-Pin aus dem letzten Fix wirkte dadurch nie auf existierende Installationen (nur Neuinstallationen). Jetzt per dpkg --compare-versions: ist die installierte Version älter als _MANTICORE_VERSION, wird der Dienst gestoppt, das neue Paket eingespielt und neu gestartet. Downgrade-Schutz durch "lt"-Vergleich. Spec PROJ-67 dokumentiert die Recherche zum Versionssprung 25.0.0 -> 27.1.5 (u.a. offene Frage zur neuen v27-Auth-Funktionalität) und den geplanten Produktiv-Test auf 131.
105 lines
4.9 KiB
Markdown
105 lines
4.9 KiB
Markdown
---
|
|
id: PROJ-67
|
|
title: Manticore Search Upgrade 25.0.0 → 27.1.5 + Auto-Upgrade-Pfad für Bestandsinstallationen
|
|
status: In Review
|
|
created: 2026-07-05
|
|
---
|
|
|
|
## Kontext
|
|
|
|
Der Manticore-Installer-Fix (Commit 3428537, 2026-07-04) hat Paketname/Pfad/
|
|
Version im Installations-Codepfad von `install.sh`/`update.sh` aktualisiert,
|
|
aber dieser Codepfad läuft **nur bei einer komplett frischen Maschine**
|
|
(`if ! command -v searchd ... ; then install; else skip`). Bestehende
|
|
Installationen (131 aktuell auf 25.0.0) werden dadurch nie automatisch
|
|
aktualisiert — der neue Versions-Pin wirkt nur für Neuinstallationen.
|
|
|
|
Nutzer-Entscheidung (2026-07-05): Produktiv-Upgrade direkt auf 131
|
|
durchführen (nicht erst auf 132 testen), UND den Upgrade-Pfad dauerhaft im
|
|
Repo/Gitea pflegen, damit auch andere/ältere Instanzen beim nächsten
|
|
`update.sh`-Lauf automatisch mitgezogen werden — nicht nur ein einmaliger
|
|
manueller Fix auf 131.
|
|
|
|
## Was sich zwischen 25.0.0 und 27.1.5 ändert (Recherche 2026-07-05)
|
|
|
|
- Parallel OPTIMIZE (schnelleres RT-Index-Compaction), diverse Crash-/
|
|
Stability-Fixes (Replikations-Edge-Cases, JOIN-Handling, Secondary-Index-
|
|
Korruption) — für archivmail relevant, reiner Volltext-Betrieb profitiert.
|
|
- Hybrid Search/KNN/Embeddings/Conversational Search — nicht genutzt, kein
|
|
Effekt.
|
|
- **v27.0.0: eingebaute Authentifizierung (Bearer-Token, Rollen/Permissions)**
|
|
— Release-Notes: "requires coordinated cluster upgrades". Offene Frage vor
|
|
diesem Ticket: greift das automatisch/breaking für die bestehende
|
|
unauthentifizierte DSN-Verbindung (`manticore@tcp(127.0.0.1:9306)/`) oder
|
|
ist es Opt-in? **Muss im Rahmen dieses Tickets am echten Server geklärt
|
|
werden** (siehe Acceptance Criteria).
|
|
- Replikations-Layout umgebaut — betrifft archivmail voraussichtlich nicht
|
|
(keine Manticore-Cluster-Replikation im Einsatz, nur einzelne RT-Indizes
|
|
pro Tenant), aber am Server zu verifizieren.
|
|
|
|
## User Stories
|
|
|
|
- Als Betreiber möchte ich, dass ein Manticore-Versions-Upgrade nicht nur auf
|
|
131 manuell passiert, sondern beim nächsten regulären `update.sh`-Lauf auf
|
|
jeder Instanz (auch 132, auch künftigen Neuinstallationen) konsistent
|
|
nachgezogen wird.
|
|
- Als Betreiber möchte ich vor einem Produktiv-Upgrade wissen, ob die neue
|
|
Auth-Funktionalität in v27 die bestehende, unauthentifizierte
|
|
Manticore-Verbindung bricht.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] `update.sh`/`install.sh`: Versionsprüfung ergänzt — wenn Manticore
|
|
bereits installiert ist, aber älter als der gepinnte
|
|
`_MANTICORE_VERSION`, wird ein Upgrade (`dpkg -i` des neuen Pakets über
|
|
die bestehende Installation) durchgeführt statt den Block zu
|
|
überspringen. Downgrade-Schutz: nie auf eine ältere Version
|
|
"upgraden" als die installierte.
|
|
- [ ] Upgrade-Vorgang stoppt den `manticore`-Dienst sauber vor dem
|
|
Paket-Austausch und startet ihn danach neu (kein `dpkg -i` gegen einen
|
|
laufenden Prozess).
|
|
- [ ] Verifiziert: Bestehende RT-Indizes (`emails_global`, `emails_tenant_N`)
|
|
bleiben nach dem Upgrade intakt und durchsuchbar (kein Datenverlust,
|
|
keine Reindex-Pflicht als Normalfall).
|
|
- [ ] Geklärt und dokumentiert: Wirkt sich die v27-Auth-Funktionalität auf
|
|
die bestehende `manticore_dsn`-Verbindung aus? Falls ja: Config-Anpassung
|
|
(z.B. expliziter Verzicht auf Auth-Erzwingung) dokumentiert und
|
|
angewendet, bevor das Upgrade als abgeschlossen gilt.
|
|
- [ ] Upgrade auf 131 durchgeführt, danach vollständiger Funktionstest:
|
|
Suche über die Web-UI, IMAP-Read-Only-Zugriff, `archivmail status`
|
|
(Manticore-Check), Reconciliation-Report (PROJ-52) — alle grün.
|
|
- [ ] `_MANTICORE_VERSION` bleibt als Pin im Skript (siehe Kommentar aus
|
|
Commit 3428537, manuell aktualisieren bei künftigen Versionen) — kein
|
|
automatisches "immer neueste Version"-Verhalten, das ungetestet in
|
|
Produktion landen könnte.
|
|
|
|
## Edge Cases
|
|
|
|
- Manticore-Dienst lässt sich nach Upgrade nicht starten (inkompatible
|
|
RT-Index-Version) → Upgrade-Skript darf nicht stillschweigend weiterlaufen,
|
|
muss Fehler sichtbar machen (kein `|| true` an der kritischen Stelle).
|
|
- Downgrade-Versuch (gepinnte Version älter als installierte, z.B. durch
|
|
einen Merge-Konflikt oder versehentlichen Revert) → Skript muss das
|
|
erkennen und den Upgrade-Schritt überspringen statt zu downgraden.
|
|
- 132 (teilproduktiv) bekommt das Upgrade beim nächsten regulären
|
|
`update.sh`-Lauf automatisch mit — nicht separat anzustoßen, aber im Auge
|
|
behalten (siehe Memory `project_132_teilproduktiv`).
|
|
|
|
## Technical Requirements
|
|
|
|
- Betroffene Dateien: `install.sh`, `update.sh` (Versionsvergleich +
|
|
Upgrade-statt-Skip-Logik).
|
|
- Versionsvergleich: `dpkg --compare-versions` (bereits auf Debian
|
|
vorhanden, kein neues Tool-Dependency).
|
|
|
|
---
|
|
|
|
## Implementation Notes
|
|
_wird während der Umsetzung ergänzt._
|
|
|
|
## QA Test Results
|
|
_wird nach dem Upgrade-Test auf 131 ergänzt._
|
|
|
|
## Deployment
|
|
_wird nach Abschluss ergänzt._
|