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.
This commit is contained in:
sysops
+3
-2
@@ -81,8 +81,9 @@
|
||||
| PROJ-63 | Defensive Tenant-Scope-Härtung der Tenant-Verwaltungs-Endpunkte (FUND-2) | Deployed | [PROJ-63](PROJ-63-harden-tenant-admin-scope.md) | 2026-06-25 |
|
||||
| PROJ-64 | Session-Invalidation bei Passwort-Change + Datei-Permissions-Härtung (Security-Audit) | Deployed | [PROJ-64](PROJ-64-session-invalidation-file-permissions.md) | 2026-07-03 |
|
||||
| PROJ-65 | Physische Tenant-Trennung im Storage-Layer | Deployed | [PROJ-65](PROJ-65-physische-tenant-trennung.md) | 2026-07-04 |
|
||||
| PROJ-66 | Backup-Strategie für Store, Keyfile, PostgreSQL (Produktiv + Teilproduktiv) | In Progress | [PROJ-66](PROJ-66-backup-strategie.md) | 2026-07-04 |
|
||||
| PROJ-66 | Backup-Strategie für Store, Keyfile, PostgreSQL (Produktiv + Teilproduktiv) | Deployed | [PROJ-66](PROJ-66-backup-strategie.md) | 2026-07-04 |
|
||||
| PROJ-67 | Manticore Search Upgrade 25.0.0 → 27.1.5 + Auto-Upgrade-Pfad | In Review | [PROJ-67](PROJ-67-manticore-upgrade-25-zu-27.md) | 2026-07-05 |
|
||||
|
||||
<!-- Add features above this line -->
|
||||
|
||||
## Next Available ID: PROJ-67
|
||||
## Next Available ID: PROJ-68
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
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._
|
||||
Reference in New Issue
Block a user