---
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._