archivmail/features/PROJ-67-manticore-upgrade-25-zu-27.md at 4e085238b65796d5e91efb86714a009456a22a27

Files

T

sysops 4e085238b6 feat(PROJ-67): Manticore-Upgrade-Pfad für Bestandsinstallationen

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.

2026-07-05 18:10:53 +02:00

4.9 KiB

Raw Blame History

id, title, status, created

id	title	status	created
PROJ-67	Manticore Search Upgrade 25.0.0 → 27.1.5 + Auto-Upgrade-Pfad für Bestandsinstallationen	In Review	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.

4.9 KiB Raw Blame History