Anpassungen von Anwendungen nach Debian Bookworm Upgrade: Unterschied zwischen den Versionen
Tim00 (Diskussion | Beiträge) |
Tim00 (Diskussion | Beiträge) |
||
Zeile 24: | Zeile 24: | ||
export PYTHONIOENCODING=utf-8 | export PYTHONIOENCODING=utf-8 | ||
=== Änderungen beim Einsatz von Passenger === | === Änderungen beim Einsatz von Passenger und Python === | ||
Falls Passenger zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert: Es können nicht mehr <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code> Datei gesetzt werden. Das führt zu einem 500er Fehler. | Falls Passenger zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert: Es können nicht mehr <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code> Datei gesetzt werden. Das führt zu einem 500er Fehler. | ||
Version vom 25. November 2023, 08:20 Uhr
Upgrade von z.B. Debian Buster zu Debian Bookworm
Die Hostmaster aktualisieren das Betriebssytem.
Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Dazu sind keine besonderen Rechte erforderlich, und können daher vom Mitglied selber vorgenommen werden, wenn die technischen Fertigkeiten vorliegen.
Gerne kann das Mitglied einen WoD Auftrag erteilen, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Einfach eine E-Mail an service@ schreiben, und die Anwendung nennen, und in welchem Benutzer die Anwendung läuft.
Diese Seite soll Anleitungen teilen, wie man die eigene Anwendung selber wieder zum Laufen bringt.
Reparatur von Python Anwendungen
Achtung
Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!
Nach dem Upgrade müssen die meisten Python Anwendungen angepasst werden.
Dann muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python Version von Debian, bei Bookworm ist das Python 3.11
Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python Version, z.B. 3.10 installiert werden: Eigenes_Python_installieren#Installation_mit_pyenv
Falls bereits mit pyenv eine andere Python Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Evtl. ist das aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.
Es sollte in der .profile oder .bash_profile diese Variable gesetzt werden:
export PYTHONIOENCODING=utf-8
Änderungen beim Einsatz von Passenger und Python
Falls Passenger zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert: Es können nicht mehr PassengerPython
oder PassengerFriendlyErrorPages
in der .htaccess
Datei gesetzt werden. Das führt zu einem 500er Fehler.
Falls ein Virtual Environment benutzt wird, sollten folgende Einträge in der .htaccess
Datei gesetzt werden:
SetEnv PYTHONPATH /home/pacs/xyz00/users/meinuser/meinprojekt SetEnv PATH /home/pacs/xyz00/users/meinuser/meinprojekt/.venv/bin:%{ENV:PATH}
Ansonsten können diese Variablen auch in der .profile
Datei gesetzt werden, also wird so z.B. auch eine pyenv Umgebung genutzt.
Reparatur von PHP Anwendungen
Eventuell müssen die phpstubs angepasst werden.
- Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss der phpstub für 7.4 kopiert werden, und in der .htaccess Datei die Zeilen eingesetzt werden:
nano doms/meinedomain.de/.htaccess # diese Zeilen dort einsetzen: AddType application/x-httpd-php74 .php Action application/x-httpd-php74 /fastcgi-bin/phpstub74 cp /usr/local/src/phpstub/phpstub74 doms/meinedomain.de/fastcgi-ssl
- Wenn bisher ein phpstub82 benutzt wurde, kann dieser nun gelöscht werden, und die Zeilen in der .htaccess Datei können auskommentiert werden.
- Wenn bisher ein anderer phpstub genutzt wurde, z.B. phpstub81, und die Seite nicht mit PHP 8.2 laufen würde, muss die aktualisierte Datei kopiert werden:
cp /usr/local/src/phpstub/phpstub81 doms/meinedomain.de/fastcgi-ssl
Reparatur von Ruby Anwendungen
Die meisten Ruby Anwendungen werden mit rbenv betrieben. Dieses funktioniert dann nicht mehr, wegen Inkompatibilitäten mit der openssl Bibliothek.
Daher muss die rbenv Umgebung neu installiert werden. siehe RubyRBEnv
Es müssen auch meistens die Ruby Gems neu installiert werden.
# erst löschen rm -Rf ~/.gem/ rm -Rf ~/.bundle rm -Rf ~/.local/state/gem/ # dann installieren cd meineapp # z.B. zammad export RAILS_ENV="production" bundle install
Falls Passenger zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert: Es müssen die Einträge aus doms/meinedomain.de/.htaccess
nach doms/meinedomain.de/app-ssl/.htaccess
verschoben werden.
Reparatur von Node.js Anwendungen
Es muss das Verzeichns .nvm
im Home Verzeichnis gelöscht werden, und node_modules
im Projekt.
Dann Node wieder neu installieren, siehe NodeJS.
Dann yarn install
bzw andere Befehle ausführen, um die Node Module wieder zu installieren.
Reparatur von Java Anwendungen
Eigenes Java JDK installieren
Auf Debian Buster lief lief Java 11. Auf Debian Bookworm steht Java 17 zur Verfügung.
Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.
Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/
Ein Beispiel für JDK 11:
mkdir ~/bin cd bin wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz
Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/
Dann muss z.B. im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:
JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11
Eigenen Tomcat installieren
Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von javax.
nach jakarta.
umbenannt.
Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool javax2jakarta
diesen Schritt in der Regel leisten.
Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.
Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi
mv tomcat tomcat.bak wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.82/bin/apache-tomcat-9.0.82.tar.gz mv apache-tomcat-9.0.82 tomcat cp tomcat.bak/conf/server.xml tomcat/conf/ cp tomcat.bak/conf/setenv.sh tomcat/conf/ cp -R tomcat.bak/webapps tomcat
Darauf achten, ob noch weitere Konfigurationsdateien kopiert werden müssen, und Anpassungen an der context.xml und web.xml übernommen werden müssen.