Version 2.8.33: Selbstreparatur der Python-Umgebung nach einem Release-Upgrade

deploy/install.sh

@@ -418,49 +418,11 @@ info "Dateien abgeglichen (Instanzdaten unter data/ bleiben unangetastet)"
 
 # -- venv --------------------------------------------------------------------
 step "Python-Umgebung"
-# Ein venv haengt an der **Minor-Fassung**, mit der er gebaut wurde: die Pakete
-# liegen unter lib/python3.X. Wechselt die Systemfassung -- ein Release-Upgrade
-# von Ubuntu bringt genau das, 24.04 hat 3.12 und 26.04 hat 3.14 --, dann ist
-# venv/bin/python3 weiter ausfuehrbar: der Verweis zeigt auf /usr/bin/python3,
-# also auf den **neuen** Interpreter. Der venv sieht heil aus und ist es nicht.
-# Er findet danach kein einziges Paket mehr, nicht einmal pip.
-#
-# Gemessen auf dem Testserver, mit verschobenem lib-Verzeichnis:
-#     [[ -x venv/bin/python3 ]]        -> wahr
-#     venv/bin/python3 -m pip --version -> "No module named pip"
-#
-# Die alte Pruefung fragte nur nach der Ausfuehrbarkeit. Sie haette den toten
-# venv behalten und waere eine Zeile spaeter an "python3 -m pip" gescheitert --
-# mitten in einer Aktualisierung, auf einem Server, dessen Dienste ohnehin
-# schon stehen. Gefragt wird deshalb, was gebraucht wird: laesst sich in
-# diesem venv pip benutzen?
-venv_traegt() {
-  [[ -x "$ROOT/venv/bin/python3" ]] || return 1
-  "$ROOT/venv/bin/python3" -c "import pip" >/dev/null 2>&1
-}
-if ! venv_traegt; then
-  # Ohne --clear: ein erneutes "venv" ergaenzt das fehlende lib-Verzeichnis und
-  # holt pip zurueck; die Abhaengigkeiten kommen gleich darunter ohnehin neu.
-  # Auch das ist gemessen und nicht angenommen.
-  python3 -m venv "$ROOT/venv"
-  info "Python-Umgebung aufgebaut ($(python3 -V 2>&1))"
-fi
-# Immer ueber "python3 -m pip" -- der pip-Shim im venv baeckt einen absoluten
-# Pfad in seinen Shebang, der nach einer Umbenennung des Verzeichnisses bricht.
-"$ROOT/venv/bin/python3" -m pip install --quiet --upgrade pip setuptools wheel
-PAKETE=("$ROOT/packages/tesm-licensing" "$ROOT/packages/tesm-core")
-# Die Serverhaelfte des Lizenzprotokolls -- ausstellen, erneuern, antworten --
-# gehoert ausschliesslich zum Lizenzserver. Ein Client verifiziert Lizenzen und
-# stellt Anfragen; den Code zum Ausstellen soll er nicht einmal mitbringen.
-if [[ "$APP" == "tesm-license" ]]; then
-  [[ -d "$ROOT/packages/tesm-licensing-server" ]] ||
-    fail "packages/tesm-licensing-server fehlt -- ohne sie kann der Lizenzserver nichts ausstellen"
-  PAKETE+=("$ROOT/packages/tesm-licensing-server")
-fi
-"$ROOT/venv/bin/python3" -m pip install --quiet "${PAKETE[@]}" "$ROOT/apps/$APP" gunicorn
-if [[ "$APP" == "tesm" ]]; then
-  "$ROOT/venv/bin/python3" -m pip install --quiet flask-sock
-fi
+# Aufbauen, pruefen und reparieren steht in genau einem Programm -- und
+# dasselbe laeuft als ExecStartPre vor jedem Dienststart. Zwei getrennte
+# Paketlisten waeren zwei Listen, die auseinanderlaufen: die Reparatur baute
+# dann eine Umgebung, die nicht mehr der Installation entspricht.
+"$ROOT/deploy/tesm-venv" "$ROOT" "$APP" --immer
 info "Abhaengigkeiten installiert"
 
 # -- Statische Dateien fuer nginx --------------------------------------------
@@ -490,6 +452,12 @@ install_if_changed() {
 install_if_changed "$ROOT/deploy/tesm-helper" /usr/local/lib/tesm/tesm-helper 0755 && \
   info "Helfer aktualisiert" || info "Helfer unveraendert"
 
+# Derselbe Baustein, der oben die Umgebung gebaut hat: die Dienste rufen ihn
+# vor jedem Start auf und reparieren damit, was ein Release-Upgrade des
+# Betriebssystems ihnen unter den Fuessen weggezogen hat.
+install_if_changed "$ROOT/deploy/tesm-venv" /usr/local/lib/tesm/tesm-venv 0755 >/dev/null \
+  && info "Umgebungspfleger aktualisiert" || true
+
 # visudo -c prueft die Datei, bevor sie aktiv wird -- eine kaputte sudoers-Datei
 # waere sonst ein Totalausfall der Administration.
 TMP_SUDO="$(mktemp)"