Beim monatlichen Schwachstellenscan förderte Nikto eine offene CVE an meinem NGINX zu Tage und leider wollten weder Debian noch NGINX die fehlerfreie Version auf Buster installieren. Somit war Debian Buster jetzt für mich endgültig am Ende.
Also habe ich das Backup überprüft und go for it. In apt die Sourcen der nächsten Version eingetragen und:
apt update
apt full-upgrade…
Es lief durch, aber das erste Problem war, dass Mariadb als MySQL-Ersatz nicht mehr hochkam. Da ich ein vollständiges Backup auf einer Partition ohne mount hatte, war ich mutig und machte apt purge und apt install mit den Vorraussetzungen meiner Anwendungen, was in vielen „referenced by another packet“ endete. Etwas stochern in den Paket-Status-Pages ergab, dass Debian beim Übergang von Python2 auf Python3 etliche Pakete umbenannt und die Referenzen nicht gepflegt hat. Andere, wie libmysqlclient-dev sollen durch andere ersetzt werden, aber Python erkennt den Debian-Way nicht an und die Tools finden keinen Weg zur Datenbank. Installieren mit pip ist ein Tor zur Hölle, das ich auf dem exponierten Webserver nicht aufstoßen möchte.
Die Qualität von Debian ist seit den Systemd-Kriegen verglichen mit dem Stand davor in der Hose. Zu viele Maintainer haben das Projekt entnervt verlassen. Somit wird es durch ein Frankendebian mit externen Paketquellen auch nicht mehr schlimmer und ich habe mich entschlossen
- Nginx
- MariaDB
- Python
… und meine Virenscanner- und Härtungstools direkt ab Hersteller zu beziehen. Also habe ich alle Pakete aus diesen Gassen mit purge entfernt und frisch bezogen und die config-files minimal angepasst.
Nach ein paar mal „apt purge“ und „apt install“ in einem rhythmischen Verfahren zu Erdmitte hin liefen die meisten Webseiten wieder.
Ich habe die Seiten, die noch zwingend Python2 verwenden und mit Python3 nicht klarkommen, erstmal abgeschaltet. Leider war da auch das Seafile-Frontend dabei und das upgrade von Seafile auf die ganz neue Version schmiss Fehler. Also Rundmail an Nutzer, dass beide Seafiles für ein paar Tage da Freizeit-Projekt down sein werden. Ich habe den Nutzern Zugriff auf die Files in meinem Raspi gegeben, der stets eine Kopie hostet. Dann habe ich frisch installiert.
Auch hier funktionierte die neueste Version zunächst nicht und schmiss mit Python- und Django-Fehlern. Die Version davor dito, aber immerhin startete das Webfrontend. Nur bei Uploads bekam ich einen Timeout vom Client und einen Django-Fehler im Log.
Morgens um sechs mit einem frischen Energydrink im Kopf sah ich dann, dass ich noch Reste von fastcgi in der NGINX-Konfiguration hatte, die von einer uralten Seafile-Version stammen. Als ich die entfernt hatte und den Rewrite des Reverse-Proxys neu geschrieben hatte, liefen die Seafiles wieder. Performance ist noch mau, weil ich die Nutzershares auf einmal aus dem Backup gefüllt habe und der Garbage-Collector noch nie gelaufen ist. Dadurch habe ich eine doppelten IO-Penalty durch das Dedup-Dateisystem und die Deduplikation von Seafile. Andererseits kamen die Rückmeldungen, dass mein Seafile Onedrive immer noch oder „wieder“ um Längen schlägt.
Kommentare
Keine Kommentare
Kommentare