paperless-ngx update script Fehler

[drpsycho]

Hallo,

ich wollte heute meinen Paperless Container updaten. Die Installation wurde seinerzeit mit dem Script von
https://tteck.github.io/Proxmox/ durchgeführt. Gelegentlich Updates waren bisher immer ohne Fehler. Bis heute.
Update von 2.7.2 auf. 2.10.2 mittels “update” auf der Konsole. Danach ist die Paperless Instanz leider nicht mehr
konsistent. Web interface ist noch erreichbar, Dokumente werden nicht angezeigt. Folgende Fehler sind aufgetreten.

Script bricht ab:

“cat: /opt/Paperless-ngx_version.txt: No such file or directory
• Stopped all Paperless-ngx Services
\ Updating to v2.10.2 [ERROR] in line 83: exit code0: while executing command
/usr/bin/python3 manage.py migrate &> /dev/null”

Im Webinterface kann ich keine Dokumente anzeigen. Unter “Dateiaufgaben - Abgeschlossen” sowie im entsprechenden Ordner im Dateisystem sind
die Dokumente vorhanden: Fehler im Webinterface siehe Screenshot 2.
Proxmox Installation wurde vor Update Paperless upgedated. Reboot usw. ist erfolgt.
Log im Proxmox zeigt keine Fehler.
Die Version ist laut Webinterface auch upgedated auf 2.10.2.
Wenn ich das Updatescript erneut aufrufe, wird mir wieder das Update auf 2.10.2 angeboten, was nach Start des Script
immer wieder auf den gleichen Fehler läuft.

Habe jetzt erstmal das Backup zurückgespielt.

Evtl. hat wer eine Lösung oder einen Tipp für mich?

Danke euch - Wolfgang

 

[clone]

>> EDIT: Nachdem ich das letzte Backup des LXC in pve zurückgespielt habe, lief das tteck script zum Update erfolgreich durch. Komisch...

Hi drpsycho,
ich schließe mich dem Post an, da ich offenbar den gleichen/ähnlichen Fehler bekomme:

    ____                        __                                   
   / __ \____ _____  ___  _____/ /__  __________    ____  ____ __  __
  / /_/ / __ `/ __ \/ _ \/ ___/ / _ \/ ___/ ___/___/ __ \/ __ `/ |/_/
 / ____/ /_/ / /_/ /  __/ /  / /  __(__  |__  )___/ / / / /_/ />  <
/_/    \__,_/ .___/\___/_/  /_/\___/____/____/   /_/ /_/\__, /_/|_|
           /_/                                         /____/     
 
cat: /opt/Paperless-ngx_version.txt: No such file or directory
 ✓ Stopped all Paperless-ngx Services
 | Updating to v2.11.4 
[ERROR] in line 81: exit code 0: while executing command pip install -r requirements.txt &> /dev/null

root@paperless-ngx:~#

Google meint, die pip bzw. python version sei out of date. Ein update von pip schlägt aber ebenfalls fehl:

[notice] To update, run: python3 -m pip install --upgrade pip
root@paperless-ngx:~# python3 -m pip install --upgrade pip
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
  
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
  
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
  
    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

[notice] A new release of pip is available: 23.3.2 -> 24.2
[notice] To update, run: python3 -m pip install --upgrade pip

 

[dokkenrolf]

Na ja, dein Betriebssystem ist ja für die Updates zuständig, also auch für python3/pip. Da ist es klar, dass es zu diesem Fehler mit python3/pip kommt. Also mal ein z. B. sudo apt update && sudo apt upgrade -y probieren.

 

[zebbl]

Also mir hat folgender Befehl geholfen:

rm -rf /usr/lib/python3.*/EXTERNALLY-MANAGED

 

[supertevran]

@zebbl Danke! Genau das hat mir ebenfalls geholfen.

 

[PRNT]

Hallo zusammen,

ich habe heute das Update (Proxmox 8.2, LXC Container mit paperless-ngx via Script installiert und geupdated) auf 2,ausgefuehrt und bin damit maechtig auf die Nase gefallen (Web GUI ist nicht mehr erreichbar etc., bin da etwas ratlos, Backup ist was aelter etc.).

Letztlich bin ich bei dem gleichen Fehler gelandet und das Update brach ab.
Kann es etwas mit der Python3 Version zu tun haben (hier erstaunlicherweise im Container 3.9 / Host: 3.11)?
Die Tipps hier haben mir nicht geholfen soweit ich das sagen kann.

Was kann ich hier tun? Tipps?

Gruss und Danke,
PRNT

 

[mikee]

Vielleicht mal beim Entwickler "vorbeischauen" und/oder dort nachfragen?
https://github.com/tteck/Proxmox/discussions

 

[PRNT]

Kann es etwas mit der Python3 Version zu tun haben (hier erstaunlicherweise im Container 3.9 / Host: 3.11)?

So als Proxmox Anfaenger bin ich etwas weiter gekommen. Der Container war in seinen Sourcen noch bei bullseye und nicht bei bookworm.
Der Container war urspruenglich unter Proxmox 7 erstellt worden. Ich war damals noch der irrigen Annahme, dass der Container die Hauptversion des Hosts 'erbt'. Ich lerne noch.

Vielleicht mal beim Entwickler "vorbeischauen" und/oder dort nachfragen?

Danke fuer den Hinweis. Aber in den dortigen einschlaegigen Quellen wird dann u.a. auf Python/paperless verwiesen etc.
So bin ich auch zur der Annahme gekommen, dass die Python Version im Container veraltet ist.

Die wunderbaren Helper-Scripts liefen bislang eigentlich immer mit Fire&Forget durch. Was es aber nicht macht, die Version des Containers zu pruefen, wenn es dort zum Update laeuft (Vermutung). Im Gegegensatz dazu meckert es durchaus, wenn der Host veraltet ist. Auch hier glaubte ich, dass es meckern wuerde, wenn die Containerversion veraltet ist. Das ist leider nicht der Fall - schoen waere es aber,
Ich denke, dass das Thema zwischen den Stuehlen und vor dem Rechner sitzt.

Ich habe den Container nun geupdatet, was dann auch durchlief. Leider ist paperless immer noch mausetot und da beisse ich bald in die Tischkante und befuerchte den total Verlust. In das Setup ist einiges an Arbeit und Dokumenten geflossen. Hilfe.**

Gruss und Danke,
PRNT

PS. Ich weiss mehr Arbeit waere besser in Backups geflossen

 

[PRNT]

[Update - alles ohne Gewaehr da teiweise gefaehrliches Halbwissen und so ganz blicke ich das noch nicht]

Vielleicht hilft das hier auch anderen weiter als Startpunkt - vielmehr (s.o.) kann es nicht sein

Ich denke, dass ich mehrere Probleme habe bzw. hatte:

​

1. Was bisher geschah:

• der LCX Container fuer Paperless-NGX wurde urspruenglich unter einem Host Proxmox 7.XX mit bullseye Basis durch das Script unter https://tteck.github.io/Proxmox/ erstellt (aktuelle Script Version hier) und regelmaessig geupdated
  (das Script leistet beides je nachdem wo es aufgerufen wird).
  
  Das bedingt, dass auch der Container in seinen Sourcen.List bullseye vermerkt wurde - logisch.
  Zum Update auf neue Paperless Versionen wurde nur das Script verwendet. Das lief mehrfach problemlos.
  Das Vertrauen in das Script wuchs und auf regelmaessige Backups vor dem Update wurde alsbald verzichtet (leider),
  
  
• Der Proxmox Host erfuhr dann im Juni 2024 ein Update von 7.XX auf 8 (aktuell 8.2.7) und damit den Sprung von bullseye auf bookworm als Debian Basis.
  Der LXC Container wurde dabei nicht angefasst und verharrt bei bullseye in seiner SourcenList.
  
  Das Update Script bemaengelt zwar, wenn der Host bei der Installation/Update veraltet ist jedoch wird der Stand im Container selbst scheinbar nicht weiter geprueft sondern einfach akzpetiert.
  
  Ich unterlag so der irrigen Annahme, dass alles auch dauerhaft passen wuerde bzw. dachte nicht weiter darueber nach.
  
  
• Updates mittels des HelperScripts liefen so nach dem Host Update wieder sauber durch.
  Das aenderte sich aber beim letzten versuchten Update auf 2.13.0 gestern.
  
  

2. Update Error / paperless nicht mehr ueber die WEB GUI ansprechbar → leichte Panik​

• Das Update auf 2.13.0 war angezeigt.
  
  Zack ohne grosse Ueberlegung wurde das HelperScript angeworfen → Fehler.
  Paperless WEB GUI war nicht mehr erreichbar. Bumms.
  
  Neustart von Host und Container → keine Aenderung. Paperless-NGX WebGui blieb tot
  
  
• Fehler: Python3
  /usr/bin/python3 manage.py migrate &> /dev/null” warf den Fehler
  
  Nach einer Recherche liegt es daran, dass die im Container verfuegbare python3 Version (3.9) nicht kompatibel sei (Operand nicht unterstuetzt etc.) und es mindest einer 3.10er Version bedarf.
  
  Daher kommt mein erster der Ansatz allein die python3 Version im Container auf eine neue Version zu heben.
  Dass die veraltete Version mehrheitlich an den Eintraegen zu bullseye in der sources.list im Container lag, war mir da nicht bewusst bzw. kam mir nicht in den Sinn.
  Man liest doch allenthalben, dass der Container die Resourcen/Komponenten des Hosts nutzt oder?
  
  
• So langsam kann bei mir etwas Panik auf, da ich die Pasperless Instanz reichlich gefuettert hatte mit Dokumenten, Tags und Regeln.
  Droht hier der Totalverlust?
  
  Ein Umziehen nur von Files, um ein lauffaehiges Paperless zu bauen und so wieder wenigstens Zugriff zu bekommen schien mir als nicht gangbarer Weg. Bzw. ich fand wenig vielversprechende Infos dazu.

3. Meine (Teil)Loesungen bislang : Heben des LXC Containers auf bookworm Basis

• nach einiger Recherche versuchte ich zuerst die Python3 Version allein auf mehr als 3.9 zu heben.
  
  Ich habe sogar versucht im Container python3 zu kompilieren → scheiterte aber an einer veralteten OpenSSL Version usw.
  Zum Glueck hatte ich dieses Mal ein Backup zuvor in Proxmox erstellt sodass ich wieder auf den alten Stand zurueck kommen gehen konnte. Also von vorn.
  
  Es gabe zwischenzeitlich ebenso einen Versuch die DB von paperless upzudaten, was aber auch in einem Rollback auf den alten Stand muendete. Das nur am Rande. Einer der DeadEnds auf dem Weg zur Besserung.
  
  
• Schliesslich habe ich mir andere LXC Container in Proxmox angesehen und via apt-cache policy python3 (Konsole/Shell) gesehen, dass dort das Paket mit 3.11.2 bereit steht (wie im Host).
  Komisch. Warum aber hier nicht? (Er war der einzige Container mit nur 3.9).
  
  Eine andere als Test vor einiger Zeit aufgesetzte paperless-ngx Instanz zeigte auch 3.11.2 und verdaute das HelperScript zum Update ohne Probleme. Erste Hoffnung keimte. Sollte python3 auf >3.9 also der Weg sein?
  
  Es dauerte bis mein Blick auf den Buecherwurm (via apt-cache policy python3in der Konsole/Shell)
  
  
  fiel und bis ich das im kaputten paperless container auch sah und den feinen Unterschied abseits der Version bemerkte – fast zufaellig.
  Denn im fraglichen paperless-ngx Container stand dort noch bullseye.
  Das fuehrte zum neuem Ansatz:
  
  
• ==> Update der sourcen.list im Container auf bookworm via Konsole:
  
  sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
  (Find&Replace bullseye durch bookworm in der Liste)
  
  und das Upgrade ansgestossen via
  
  apt update && apt upgrade -y (?)
  
  Das Update lief nach einer kleinen Ewigkeit durch. Prima.
  
  Im Ergebnis ist der LXC Container von bullseye auf bookworm in der Basis gehoben worden.
  Der Vorgang hatte unzaehlige Updates zur Folge.
  Aber so steht u.a. im Container nun auch python 3.11.2 anstelle von 3.9 zu Verfuegung.
  Erst mal prima!
  
  
• [Backup des Containers erstellt vor dem naechsten Schritt]
  
  
• Dennoch war paperless-ngx’s Web-GUI weiterhin tot. Grrrrr
  
  
• Neuer Update/Repairversuch mit HelperScript ausgegfuehrt in der Konsole
  → anderer neuer Fehler in einer anderen Zeile des Scripts:
  
  [ERROR] in line 81: exit code 0: while executing command pip install -r requirements.txt &> /dev/null
  
  

4. Meine (Teil)Loesungen: Erneutes Update mit HelperScript mit Umwegen

• Um den Fehler zu beheben, stiess ich dann auf folgenden Tipp (u.a. hier im Thread):
  
  rm -rf /usr/lib/python3.*/EXTERNALLY-MANAGED
  [1] https://forum.proxmox.com/threads/paperless-ngx-update-script-fehler.150797/post-698022
  
  Nach meiner Recherche schien das moeglich, dass hier eine Ursache liegen kann.
  Also diesen Befehl im Container (Konsole) ausgefuehrt.
  
  
• Update Paperless-NGX HelperScript in der Konsole erneut ausgefuehrt
  
  
• Es dauert, es dauerte – aber es endete ohne Fehler! Success!
  
  
• Best of all: Paperless-NGX Web-GUI war wieder erreichbar! → Wunderbar!
  
  
  
• Jetzt werden erst mal neue Backups gezogen usw.
  ​

  ---

  
  Vermutlich werde ich das ganze auf einen neuen LXC Container umziehen, da ich kaum weiss wie lange der aktuelle Container halten wird und ob es nicht noch nachteiligen residue von meinen vielflachen Rep.versuchen gibt.
  Danach werden ich mich in Bezug auf Proxmox noch ein wenig aufschlauen, so dass so was die Ausnahme bleibt.
  
  Ich bin mir ziemlich sicher, dass es nicht der Stein des Weisen hier ist, aber vielleicht hilft es auch anderen weiter bzw. bietet einen Einstieg.
  
  
  Gruss und Danke,
  PRNT​

 

[Johannes S]

Nicht böse gemeint, aber warum arbeitet ihr mit Helperskripten, wenn ihr laut eurer eigenen Aussage noch nicht so richtig wisst, wie alles zusammen funktioniert? Wenn man nicht versteht, was die Skripte und der Rest des Systems genau machen, ist man verloren, sobald es mal Probleme gibt. Und wenn man soweit ist, dass man das Helperskript versteht, kann man die manuellen Schritte auch selbst machen.

Um was konstruktives beizutragen: paperless-ngx hat eine Anleitung die eine Installation über deren eigenes, offizielles Skript beschreibt (bin ich immer noch kein Fan von, irgendwas aus dem Internet auszuführen, aber immerhin wird das offiziell von paperless unterstützt) oder über ein docker-compose:
https://docs.paperless-ngx.com/setup/

Eine Debian- oder Ubuntu-VM mit portainer ist schnell aufgesetzt und simpler als über docker-compose geht es dann echt nicht mehr. Vorteil: Da die Abhängigkeiten und alles dann direkt über das Docker-Image mitgezogen werden, gibt es dann nie mehr Ärger mit den Abhängigkeiten nach einen Update.

Alle male besser, als sich mit nicht verstandenen Helper-Skripten und deren Folgen rumzuärgern.

Just my two cents, Johannes.

 

[PRNT]

Nicht böse gemeint, aber warum arbeitet ihr mit Helperskripten,

Das soll hier auch nicht die Diskussion sein um den Sinn oder Unsinn von solchen Skripten. Natuerlich sollte man sich dem Nutzen als auch den Gefahren (Quellen) bewusst sein. Solche Skripte sind sicher nicht fuer jeden was. Das ist klar.

Das hier genutzte HelperSkript ist aber einsehbar und kann von jedem, der verstaendig ist, entsprechend beurteilt werden.
Nicht alle Nutzer koennen das und es wird auch nie so sein.
Ich bin allerdings auch nicht der Meinung, dass man alles verstehen muss geschweige denn kann, auch wenn mehr Verstaendis meist hilft.
Irgendwo faengt jeder an und da sind diese Scritpts schon hilfreich IMHO, wenn es in Richtung LXC Container gehen soll etc.

Wir nutzen Proxmox, z.B. Synaptic auf dem Desktop, ohne dass ein Detailvertstaendnis da ist. Wir vertrauen auf Paketquellen usw.
Es ist nicht alles ideal, aber so ist das eben und größtenteils faehrt man damit ganz gut.
Docker hat per se auch nicht Sicherheit im Bauch.

Der Vorschlag zur VM ist einer, aber das moechte ich z.B. hier explizit nicht, da sich das ganze hier auf einem MiniPC abquaelt der zwar wenig verbraucht aber nicht unendlich Ressourcen hat. LXC Container sind da schlanker und eben auch andere Tiere als Docker Images.
Aber der Gedanke nur eine kleine Maschine einzusetzen war fuer mich dann der Ausschlag fuer LXC. So war mein Anfang damit.

Docker wird andere Probleme haben. Docker Images sind auch oft BlackBoxes. Aber mit Docker habe ich noch weniger Erfahrung zugegebenermassen.

Aegert man sich nicht ueber Proxmox und LXC Container sind es dann Docker Container ;-).
Alles hat seine Vor- und Nachteile und Lernkurven IMHO. Auch wenn ich Docker zugestehen muss, dass es einfacher zu haendeln sind vermutlch.
Ich kann Deinen Vorschlag also gut verstehen.

Und klar paperless selbst sieht da genau diesen Weg vor. Das nutzen von paperless im LXC Container weicht davon ab.

Aber wir wollen ja alles lernen ;-)
Das habe ich heute getan. Immerhin etwas.

Also nichts fuer ungut!

Gruss,
PRNT

 

[Johannes S]

Das soll hier auch nicht die Diskussion sein um den Sinn oder Unsinn von solchen Skripten. Natuerlich sollte man sich dem Nutzen als auch den Gefahren (Quellen) bewusst sein. Solche Skripte sind sicher nicht fuer jeden was. Das ist klar.

Das hier genutzte HelperSkript ist aber einsehbar und kann von jedem, der verstaendig ist, entsprechend beurteilt werden.

Und wieviele Leute machen das? Natürlich sieht das beim offiziellen Skript von paperless-ngx oder deren docker-container nicht wesentlich besser aus, dort halte ich es aber für deutlich wahrscheinlicher, dass den paperless-Entwicklern selbst Probleme auffallen und gefixet werden.
Mein Punkt ist: Wenn einen die Gefahren klar sind und man das Skript verstanden hat, braucht man es im Regelfall nicht mehr. Wenn man das aber nicht tut (und sorry, aber danach klingt es, wenn da so ein Paket-Mischmasch mit mehreren Installationsvarianten (apt und pip sind ja zwei verschiedene und unabhängig voneinander laufende Paketverwaltungen, die somit auch gegenseitig sich Probleme machen können!) beschrieben wird), dann sorgt das doch früher oder später dafür, dass man (wie hier im Thread) Probleme bekommt, ohne überhaupt einen Lösungsansatz zu haben.

Nicht alle Nutzer koennen das und es wird auch nie so sein.
Ich bin allerdings auch nicht der Meinung, dass man alles verstehen muss geschweige denn kann, auch wenn mehr Verstaendis meist hilft.
Irgendwo faengt jeder an und da sind diese Scritpts schon hilfreich IMHO, wenn es in Richtung LXC Container gehen soll etc.

Wofür helfen diese Skripte? Beim Verständnis schon mal nicht, anders als wenn man Z.B. sich ein Debian in einen LXC-Container installiert und dort dann paperless-ngx nach der offiziellen Dokumentation (wenn es denn schon lxc sein muss) installiert
Und wenn man einfach "fire and forget" will, ist der Weg über eigene vm für docker deutlich weniger fehleranfällig:

• Mit dem Update des docker-containers werden auch die Abhängigkeiten mit aktualisiert, also kein Ärger durch verhauene Pakete beim Systemupdate
• Die VM isoliert das System noch mal besser als per LXC, ein Sicherheitsproblem oder hack, betrifft also, wenn man Glück hat, nicht auch die anderen VMs / container
• Ich muss für alle in dieser VM gehosteten Container das Betriebssystem nur einmal aktualisieren, statt (wie wenn ich für jede Anwendung einen eigenen lxc-Container einrichte) jedes lxc für sich plus darauf hoffen, dass mit den Update einen nichts kaputt gemacht wird.

Wir nutzen Proxmox, z.B. Synaptic auf dem Desktop, ohne dass ein Detailvertstaendnis da ist. Wir vertrauen auf Paketquellen usw.
Es ist nicht alles ideal, aber so ist das eben und größtenteils faehrt man damit ganz gut.

Du nutzt Proxmox auf einen Desktop? Dann ist das schon mal eine Variante, die offiziell nicht unterstützt wird. Man kann das natürlich trotzdem machen, aber das macht es dann ja nur schwieriger bei Fehlern zu helfen. Und "faehrt damit ganz gut" würde ich bei Problemen, wie hier im Thread jetzt nicht sagen, aber jeder wie er mag.

Docker hat per se auch nicht Sicherheit im Bauch.

Das war auch nicht der Punkt, sondern dass das beim Deployen von Anwendungen mit weniger Stress verbunden ist, gerade wenn man (noch) nicht die Skills hat.

Der Vorschlag zur VM ist einer, aber das moechte ich z.B. hier explizit nicht, da sich das ganze hier auf einem MiniPC abquaelt der zwar wenig verbraucht aber nicht unendlich Ressourcen hat. LXC Container sind da schlanker und eben auch andere Tiere als Docker Images.

Docker-Container sind nicht mehr und nicht weniger ressourcenhungrig als lxc. Und das mit der VM trifft nur zu, wenn man meint für jeden Docker-Container eine neue VM aufmachen zu müssen, das sollte man bei begrenzten Ressourcen natürlich nicht tun. Aber dass ein MiniPC mit einer Debian-VM und den darin laufenden Docker-Containern überfordert ist, das wage ich dann doch zu bezweifeln. Wenn man natürlich bei vier CPU-Kernen analog zu 20 LXC-Containern 20 VMs mit jeweils einen Docker-Container laufen lässt, dann haut das natürlich nicht hin. Aber so sollte man das ja auch nicht machen.

Wenn man das ganze als Lernprojekt sieht, ist es natürlich ok das über lxc und co zu machen,, dann muss man dann aber auch mit den Ausfallzeiten (weil man öfter Sachen reparieren muss) leben. Die helper-scripts sind dafür aber gerade nicht hilfreich, weil sie die Komplexität verstecken, die dann früher oder später doch zuschlägt. Will man dagegen die Anwendungen tatsächlich produktiv einsetzen (wie hier als Sammlung aller wichtigen Dokumente), würde ich mir dagegen noch mal überlegen, ob diese Art von Downtime einen das wert ist.