Hallo zusammen,
ich versuche seit Tagen, paperless auf einer Ubuntu-VM zu installieren. Ich habe noch nie eine Installation erlebt, die mich derart mit Fehlern totschmeißt.
Warum will ich das überhaupt?
- Ich habe paperless seit ein paar Tagen auf meiner Syno (918+) unter docker laufen. Das Tool gefällt mir ganz gut, es hat Gimmicks, die ecoDMS nicht hat.
- die Performance beim Einlesen neuer Dokumente ist recht bescheiden, der Syno-Prozessor ist für den Anwendungsbetrieb zu lahm.
- Ich konnte mich mit Docker noch nie so recht anfreunden, weil die Apps abgeschottete Blackboxes sind. Ich sehe das als Nachteil.
- Ich habe als vorgeschädigter ITler allerhand VMs auf Proxmox laufen, überwiegend Ubuntu für checkmk, ntopng, ecodms, splunk, pihole usw. Das sind alles Ubuntu-VMs, deshalb möchte ich nicht für eine Applikation auf Debian ausweichen.
- Meine ecoDMS-VM z.B. sichere ich als komplette VM über einen ProxmoxBackupServer extern. Das funktioniert super geschmeidig und automatisch.
- Ein Proxmax Container fällt aus, weil man im unprivilegierten Container keine Shares publishen kann (für das consumer Verzeichnis) und privilegierte Container unsicherer als eine separate VM für das Hostsystem sind.
Ich habe mir die letzten Tage einen abgebrochen mit dieser Installation. Ich habe Dutzende howto’s abgearbeitet, keine - auch die Kombination mehrerer - hat nicht funktioniert. Hauptursache ist der Python Unterbau. Ubuntu 24.04.2 kommt mit Python3.12 daher. Mit der globalen Systeminstallation von Python kommt das paperless PIP-Install script nicht zurecht, dutzende Fehler wegen fehlender Module, access denied Fehler oder „…das ist ein externally managed environment…“ und und und. Mit einer Python3.11 Parallelinstallation in einer venv kommen wieder andere Fehler wegen fehlender Schreibrechte in einigen myenv-Unterverzeichnissen. Es ist ein Graus. Jedem Installationsversuch ging übrigens ein snapshot restore auf ein sauberes System voraus.
Hat vielleicht jemand paperless erfolgreich auf ein aktuelles Ubuntu 24.04.2 installiert und kennt ein howto, mit dem man step-by-step zum Erfolg kommt?
Allerdings plagt mich schon der Gedanke: Wenn schon die initiale Installation für mich ein solches Disaster ist, wie sollen dann Updates auf neue Versionen oder mögliche Änderungen der Python Version laufen? Möglicherweise führt die kleinste Versionsänderung zum Ausfall der Applikation.
Momentan habe ich erstmal aufgegeben. Jedem behobenen Fehler folgen anschließend neue Fehlermeldungen, die vorher noch nicht aufgetaucht waren. Mir fehlt die Motivation, für eine einzelne Anwendung mit viel Aufwand bestehende Abhängigkeiten in der vorausgesetzten Laufzeitumgebung manuell erkunden zu müssen.
Vielleicht gibt es für paperless irgendwann fertige Pakete für die Distributionen oder fertige VM-Images für verbreitete Virtualisierer.
Gruß Roland
Servus,
Die 918+ ist definitiv nicht zu alt für größere Dokumente wenn du den RAM aufs Maximum erhöhst.
Das nimmt dir meine 918+ jetzt übel.
Was hast du denn für besondere Dokumente ?
Viel MB oder eher viele Seiten ?
Und wieso du jetzt mit Debian nicht klar kommst aber mit Ubuntu das auf Debian basiert musst mir mal erklären.
Debian und Docker mit Paperless ist genauso einfach wie auf dem Raspberry OS und läuft auch baremetal.
Paperless selbst hab ich jetzt explizit nie Baremetal genutzt… Dafür gibt’s ja Docker.
Wenn du sicher mit der Shell umgehen kannst brauchst du doch auch nur n Debian Server ( Minimal Installation ) und vielleicht was bequemes zur Verwaltung wie Webmin ( SMB, User usw. ) und die benötigten Pakete.
Du kannst da sogar fast 1:1 die Installation aus der Masterclass oder die Config ausm Shop verwenden.
Für die Container Verwaltung nutze ich nur noch mehr „dockge“ …
Hallo,
ich habe nicht gesagt, daß ich nicht mit Debian zurechtkomme. Ich möchte nur ein homogenes Umfeld haben, wenn alle anderen Server auf Ubuntu sind. Ich möchte auch nicht Docker auf Debian oder Ubuntu, sondern paperless als nativ installierte Anwendung auf Ubuntu. Webmin habe ich schon laufen, auch als Ubuntu-VM. Ich würde mir (dem Link folgend) auch kein Video kaufen, das die Installation auf der Syno beschreibt, auf der Syno läuft es schon mit Docker. Für die Containerverwaltung verwende ich portainer. Ich habe auch keine besonderen Dokumente. Mein Problem ist, daß ich für ecoDMS am Anfang mit zu großer Auflösung gescannt habe und damit zu große Dateien erzeugt habe. Später habe ich das korrigiert, aber die großen Dokumente sind halt schon im Archiv und ich müßte sie so von ecoDMS nach paperless portieren.
Nochmal was mich antreibt, von der Docker auf Syno Installation wegzukommen:
- die Performance bei der Dokumentenverarbeitung ist im Vergleich zu ecoDMS lahm.
- ich habe lieber eine separate Voll-VM mit installierter Anwendung als einen abgeschotteten Container wo man komplett von einem vorgefertigten Image abhängig ist. Wobei das „vorgefertigt“ in diesem Falle eher ein Vorteil wäre.
- ich schätze das Backupkonzept von Proxmox. Damit habe ich ein automatisches externes Backup, das im Notfall in 5 Minuten völlig streßfrei wiederhergestellt ist.
Vielleicht starte ich irgendwann nochmal eine Serie von Installationsversuchen. Momentan fehlt mir die Zeit. Ich werde paperless erstmal auf der Syno weiter betreiben. Vielleicht gibt’s irgendwann ein Distri-Package mit allen Anhängigkeiten, das man mit apt installieren kann.
Danke und Gruß
Roland
Hilft Dir nicht direkt, aber vielleicht zum Spicken:
Es gibt ja die Proxmox-Helper-Scripts unter Proxmox VE Helper-Scripts Da ist auch ein Script für Paperless dabei. Dieses installiert zwar in einen Debian LXC Container, aber zum Spicken könntest Du Dir das eigentliche Script https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/paperless-ngx.sh auf jeden Fall mal genauer anschauen. Das sind ja normale Installationssteps, die theoretisch so auch unter einem Ubuntu funktionieren könnten. Sieht für mich sehr straightforward aus, was da gemacht wird. Keine Ahnung, ob genau diese Schritte dann unter Ubuntu 24 aus irgendwelchen Gründen schief gehen, aber testen könnte man es ja mal genau so wie es in dem Script auch abläuft.
Es spricht ja nichts gegen eine separate VM, in der Du paperless ngx dann via Docker installierst. Genau das was Du an Problemen bei der Installation beschreibst, ist das, was den eigentlichen Vorteil von Docker ausmacht: Es bringt Dir eine stabile Umgebung, in der die Anwendung läuft.
Ich habe es nach einigen Versuchen jetzt genauso umgesetzt. Eine VM mit Ubuntu unter Proxmox, darin Docker und dann via Docker-Compose installiert. Ich nutze dazu noch Portainer und ein git-Repo, aber das muss nicht sein.
Insbesondere bei Updates ist das eine sehr charmante und sichere Lösung, da kein unerwartetes Update dazischenfunken kann. Die Umgebung im Docker bleibt von allen HostUpdates unbeeindruckt und lässt sich selbst noch viel einfacher Updaten.
ach ja, nur der Vollständigkeit halber, weil Du es nicht explizit schreibst: den offiziellen Baremetal-Weg von https://docs.paperless-ngx.com/setup/#bare_metal hast Du so auch unter Ubuntu schon probiert? Mich wundert, daß Du von Problemen mit Python 3.12 schreibst, weil das ja explizit als unterstützt in dieser Anleitung aufgeführt wird. Aber klar, auch da ist von Debian die Rede, kann also sein, daß das aus irgendwelchen Gründen dann unter Ubuntu Probleme macht.
@shakebox : Ich hatte auf dem proxmox Host schon ein script ausprobiert. Das ist aber abgebrochen, weil Ubuntu 24.04.2 nicht unterstützt wird. Ich hab’s dann gelassen, weil ein unprivilegierter Container keine shares (consume) freigeben kann und einen privilegierten Container möchte ich aus Sicherheitsgründen nicht.
Den „offiziellen“ Weg hatte ich als Erstes probiert, aber wegen unzähligen Fehlermeldungen dann gelassen. Ich hatte auch Python3.11 in einer venv installiert, auch pipx probiert, alles gescheitert wegen access denied Meldungen auf bei der Installation angelegten Unterverzeichnissen, fehlenden Python Modulen usw. ich hab versucht, diese Module (imp…) nachzuinstallieren, bin aber daran gescheitert, daß ich nirgendwo gefunden habe, wie das zuhörige package genau heißen muß.
Außerdem kommt bei einer System-Python Installation die paperless Installation mit „-r requirements.txt“ immer mit der Fehlermeldung abbricht, daß das ein „externally-managed-environment“ sei.
Ich bin ja beruflich mehr im Windows Bereich (AD) unterwegs, habe zuhause aber auch viel Ubuntu VMs laufen. Will sagen: ich bin allerhand Elend gewöhnt, aber diese Installation ist schon hartes Brot.
@AlexanderF70 : Auf diese Idee bin ich noch nicht gekommen, danke dafür! Die Variante dürfte alle Vorteile, die ich im Auge habe, vereinen. ich könnte proxmox-backup nutzen, hätte ein aktuelles OS laufen und spare mir den Python-heckmeck, der sich als Showstopper herausgestellt hat.
Was die paperless Container Aktualisierung betrifft: Wenn ich „watchtower“ richtig verstanden habe, klopft der zyklisch bei Github an, zieht automatisch neue Releases, tauscht die im Docker aus und startet die Container neu. Das muß ich aber noch beobachten.
Vielen Dank an Alle!
Gruß Roland
Watchtowr prüft auf Updates, benachrichtigt dich oder installiert es automatisch.
Automatisch halte ich bei produktiv eingesetzten Systemen für höchst leichtsinnig. Aber eine Anzeige genügt ja auch. Dann testen und weiterschauen.
Bei der Datensicherung ist zu beachten, wo die eigentlichen Daten liegen sollen. Da gibt es verschiedenste Wege.
Ich habe noch nicht rausgefunden, wo und wie man watchtower konfiguriert.
Mit ProxmoxBackupServer schreibe ich einfach zyklisch die komplette VM weg und synchronisiere das verschlüsselte Backup auf einen externen Backupserver. Bei inett zahlt man 2 Cent für’s Gigabyte. Damit habe ich meine Dokumente für ein paar Cent im Monat sicher bei einem externen Hoster. Im Notfall kann ich direkt von dort auf einen beliebigen Proxmox-Knoten (hab’ drei im Cluster) in ein paar Minuten streßfrei zurückspielen.
Gruß Roland
Der Link war nicht von mir und ich verwies explizit auf die Konfiguration für Raspberry oder Synology die auch auf Debian minimale angepasst funktioniert.
Du weißt hoffentlich das du die Cores und die Threads in der ENV angeben musst.
Gibt es einige Beiträge dazu in Bezug auf die schwachbrüstige 224+ .
Die großen PDFs könntest du ja die DPI einfach reduzieren lassen und neu ausgeben lassen… OK kommt jetzt auf die Menge an Dateien drauf an.
Aber dafür gibt’s sicherlich auch ne Lösung auf Windows oder Linux.
Der Vorteil von Docker ist einfach du musst selbst wenn dein System nicht mehr geht nur die Ordner sichern und nicht erst Tabula Rasa machen und alles von Hand neu aufsetzen.
Mir ist nichts bekannt das Docker die Ressourcen begrenzt wir in ner VM wo RAM usw. Fix eingestellt ist.
Kann mich aber auch irren.
Wenn du jetzt die Performance von EcoDMS auf deinem Server mit Paperless auf der 918+ vergleichst muss ich einfach nur lachen da Äpfel und Birnen…
Spiel dich einfach mal mit den o.g. variablen der Cores und Threads auf deinem Server und mach realisierbare Tests.
Du wirst feststellen müssen das sich das Ergebnis mit den richtigen Einstellungen deinen Wünschen nähern wird.
Zum Thema Proxmox und so bin ich raus.
Wird schon so stimmen mit dem Backup.
Hab ich keine Ahnung von und bin Docker-Jünger ^^ 
Ich wußte nicht, daß man Cores und Threads angeben muß, dazu hatte ich bisher noch nix gelesen. Aber wie gesagt, ich habe mich nie tiefergehend mit Docker beschäftigt. Ein paar Container habe ich auf der Syno laufen. Das beschränkt sich aber auf Image suchen, registrieren, ggfls. ein paar Ports und Volumes einrichten und gut is.
Mittlerweile bin ich der Idee von @AlexanderF70 gefolgt und habe paperless auf einer separaten VM unter Docker mit dem Installationsscript ohne Probleme installiert. Damit läuft die Verarbeitung der Dokumente in paperless spürbar performanter.
Diese Lösung paßt gut in mein Umfeld und ich muß mich nicht mit Einstellungsvarianten und Tests befassen.
Vielen Dank an Alle.
Gruß Roland
Ich habe das auf meinem Proxmox so gelöst:
- Im Proxmox Host habe ich eine (eigentlich zwei: Einmal eine SSD und einemal eine große 3,5”) Datenplatte gemountet (ext4)
- In einem unpriviligierten LXC läuft ein (SMB) Fileserver. Dieser mountet per bind mount die Datenplatten und gibt diese dann über SMB im Netzwerk frei
- Der Paperless LXC mountet wie der Fileserver LXC die Datenplatten. In der Paperless-INI sind die Pfade entsprechend angepasst.
In meinem Netzwerk habe ich jetzt eine Consume-Freigabe über den Fileserver. Funktioniert hervorragend. Auf gleiche Art und weise habe ich z.B. auch einen Immich-Server am laufen.
Die Geschichte mit den bind mounts ist ein bisschen tricky beim Einrichten wegen der Rechte, aber wenn man das einmal verinnerlicht hat ist das kein Problem.
Ich habe auf der Ubuntu VM Samba installiert, /mnt/consume mit CIFS freigegeben und mit dem paperless Installationsscript consume dorthin zeigen lassen. man muß nur darauf achten, die Freigabe mit Samba vor der Installation von paperless zu erledigen, weil Samba an den Verzeichnisrechten dreht, wenn das Verzeichnis von der paperless Installation vorher angelegt wurde und dann freigegeben werden soll.
Gruß Roland