ecoDMS - Upgrade auf v24.01 - Error occurred while accessing an OpenSSL library method

[SurveillanceUser]

Hallo zusammen,

ich bin langsam wirklich am verzweifeln und hoffe auf eure Hilfe

Ich nutze "ecoDMS" auf meiner "DS718+" mit der DMS-Version 7.1.1-42962 Update 6 in "Docker" mit der Version 20.10.3-1308.

Bis gestern lief ecoDMS in der Version 22.08 völlig problemlos.
Da es mittlerweile aber die Version 24.01 gibt, wollte ich nun mal updaten.

Das updaten an sich verlief problemlos:
- Vollbackup erstellt
- Container der Version 22.08 gestoppt
- Ports geändert, damit diese für die Konfiguration der neuen Version frei sind
- Image der Version 24.01 (latest) geladen
- Container erstellt und konfiguriert
- Client aktualisiert

Soweit so gut. Wie gesagt, alles problemlos.
Das Dateisystem bzw. die benötigten Ordner (Daten (data), Backup (backup), Restore (restore), ScanInput (scaninput)) hab ich inkl. deren Inhalt unangetastet liegen lassen.

Seither kann ich mich nicht mehr mit dem Server verbinden. Ich erhalte nur noch eine der folgenden Fehlermeldungen - mal die eine (etwas detaillierter), mal die andere (etwas "einfacher"):

Error occurred while accessing an OpenSSL library method: error:0A000126:SSL routines::unexpected eof while reading

Error occurred while accessing an OpenSSL library method:

Hatte dann etwas im Netz recherchiert und die Info gefunden, dass es wohl wieder funktionieren soll, wenn man alle alten Container komplett löscht, dann das System mit der neuen Version neu aufsetzt und im Anschluss ein Backup einspielt.

Das hab ich dann versucht. Leider erfolglos. Das Problem blieb. Ich kann mich nicht mehr mit dem Server verbinden.

Ergänzend vielleicht noch die Info:
Hab auch versucht den Client komplett zu de- und im Anschluss neu zu installieren.
Hier fällt auf, dass nach der Neuinstallation im "Connection Manager" direkt wieder die Profile sichtbar sind.
Irgendwo liegen also wohl noch Konfigurationsdaten rum, die bei einer Deinstallation nicht gelöscht werden.

Hab leider keine Idee mehr, wo hier das Problem liegen könnte und was ich tun kann, um ecoDMS wieder ans Laufen zu bringen

Ich hoffe, ihr könnt mir helfen

 

[Ronny1978]

Auch wenn es bei mir nicht im Docker, sondern auf einer Windows 11 VM läuft, hatte ich auch das Problem, dass die VM dann dauerhaft hoch ausgelastet war. Lösung BEI MIR:

- KOMPLETT-Backup von ecoDMS erstellt
- alles deinstalliert
- neuen Server installieren, inkl. neuer SQL Datenbank
- Backup zurückspielen

Bei dir:
- KOMPLETT-Backup erstellen
- Container löschen
- neuen Ordner im Docker erstellen
- ecoDMS Container neu erstellen
- Client + PDF Drucker auf dem PC / Laptop auf den aktuellen Stand bringen
- Backup zurückspielen

So hat es bei mir geklappt.

P.S. Es kann aber daran liegen, dass, glaube ich, mit der 23er Version, die Datenbank bereits aktualisiert wurde. Ich kann nur empfehlen, nicht so große "Lücken" beim ecoDMS zu lassen.

 

[SurveillanceUser]

Hi Ronny,

danke für deine Antwort.

Damit ich dich richtig verstehe:
Ich soll die vorhandenen Ordner (inkl. Inhalt) löschen, die dann neu erstellen und leer lassen, richtig?
Dann normaler Ablauf zum aufsetzen des Systems?

Und dann sollte das klappen?

Ich hatte früher immer zeitnah die Version aktualisiert.
Hatte dann aber dasselbe Problem wie jetzt bereits mit Version 23.x.
Hier konnte ich seinerzeit dann aber noch zurück zur 22.08.
Damit war die Sache für mich erstmal erledigt.

Diesmal komme ich leider nicht mehr zurück. Eine Dauerlösung aber ist das ja sowieso nicht.

 

[Ronny1978]

Ich soll die vorhandenen Ordner (inkl. Inhalt) löschen, die dann neu erstellen und leer lassen, richtig?

Nein, den Ordner würde ich zur Sicherheit lassen. Ich habe es früher immer so gemacht:

Im Ordner docker hatte ich einen Ordner ecoDMS. IN DEM Ordner ecoDMS dann den Ordner ecoDMS_2208. Dort drin dann die Standardordner scaninput, .... usw. (Vorgabe laut Handbuch) Gab es eine neue HAUPT-Version habe ich mir einen neuen, leeren Ordner ecoDMS_2401 angelegt und wieder Unterordner scaninput,....

Dann:
- richtiges Backup von ecoDMS erstellt
- Container gelöscht
- neue Version vom Container heruntergeladen
- die NEUEN Ordner (ecoDMS_2401 mit scaninput, usw.) im Container gemappt
- den neuen Container gestartet und das Backup wieder zurückgespielt

WENN dann ALLES funktioniert, habe ich noch einen Monat gewartet und dann den alten Ordner ecoDMS_2208 gelöscht. Bei einer kleinen Versionsänderung habe ich das natürlich nicht gemacht, wie von 23.01 auf 23.02 zum Beispiel. Aber schon oft, wurde was an der Datenbank geändert, sodass es für MICH sicherer war, eine "neue / leere" Instanz anzulegen und das Backup zurückzuspielen.

Ich hoffe, dass hilft dir weiter.

 

[SurveillanceUser]

Danke für die Tipps.

Tatsächlich hatte ich mir auch schon Mal etwas ähnliches überlegt.
Da ich aber abhängige Systeme angebunden habe - z. B. einen Netzwerk-Scanner der in den "ScanInput"-Ordner scannt - müsste ich dann auch immer diese Systeme anpassen. Hier ist mir der Aufwand tatsächlich zu groß.

Aber:

Endlich läuft das System wieder. Ich hab's so gemacht, wie in meinem letzten Post beschrieben. Das hat funktioniert.

Nun muss nur noch das Einspielen des Backups funktionieren.

Darf ich hierzu noch kurz Fragen:
Lt. meinen Recherchen muss ich nur die Backup-Zip, die das Vollbackup erstellt hat, in den "Restore"-Ordner schieben und in "restore.zip" umbenennen. Im Backup Ordner muss nichts liegen. Dann sollte das System automatisch ohne weiteres zutun das Backup wiederherstellen.

Korrekt?

 

[Ronny1978]

Vorher bitte Lizenz deaktivieren! Sonst sollte es so gehen.

P.S. Bitte erst Container runterfahren, restore.zip in den Ordner legen und dann Container neu starten!!! Und bitte etwas Geduld mitbringen und nicht gleich hektisch werden. Die Wiederherstellung wird einen Moment dauern.

 

[Ronny1978]

@SurveillanceUser : Kleiner Tipp für die nächste Mal beim "Löschen": Lege dir doch in docker/ecodms einen 2. Ordner docker/ecoDMS-Backup2208 an und verschiebe alle Dateien/Ordner von docker/ecodms nach docker/ecoDMS-Backup2208. Dann im LEEREN Ordner docker/ecodms die 4 Standardordner anlegen und "von vorn" beginnen. So hast du die Daten - außer dem Backup - immer noch da und kann recht schnell zurück.

So musst du nichts bei den Scannern ändern.

 

[SurveillanceUser]

Super! Und erneut, vielen Dank!
Ich stoße das jetzt direkt mal an und dann schauen wir mal

 

[SurveillanceUser]

So, unglaublich aber wahr, es läuft wieder

Vielen herzlich Dank für die Unterstützung!

 

[Ronny1978]

Gerne doch .

 

[SurveillanceUser]

Jetzt muss ich doch nochmal was fragen:

Die "restore.zip" kann ich nun aus dem "Restore"-Ordner wieder rauslöschen, oder?
Ist ja doch ziemlich groß das Ding

 

[Ronny1978]

Die "restore.zip" kann ich nun aus dem "Restore"-Ordner wieder rauslöschen, oder?

Nach klar. Die müsste aber umbenannt sein, oder?

 

[SurveillanceUser]

Tatsächlich, mittlerweile heißt die "restore-processed.zip".
Dann lösch ich sie

 

[Frank_1234]

Guten Tag,

ich habe exakt das gleiche Problem, wie beim Eröffnungsthread geschildert. Selbst mit mehrfacher Neuinstallation auf dem NAS und dem Notebook bekomme ich keine Verbindung vom Connection Manager zum Server.

Meine Hardware:

• NAS: DS423+, mit vier mal 4 TB WD Red Pro als RAID 5
• LAN NAS: Beide Anschlüsse an einen Switch angeschlossen
• Notebook (Client): Dell XPS 13 9305 mit Windows 11 PRO
• Docker auf NAS eingerichtet
• ecoDMS 24.02 (latest) installiert, nach Anleitung
• Ports gesetzt, ohne Fehlermeldungen: 17001, 17002, 17004 und 17005
• Ordner angelegt, Daten und data sind korrekt hinterlegt ;-)
• Ordner als "/srv/NAME" alle hinterlegt
• Client auf XPS installiert, ohne Fehlermeldungen
• Connection Manager: Aufruf ohne Fehlermeldungen
• Verbindung: IP-Adresse des NAS (beide ausprobiert) und Zugangsdaten ecodms / ecodms
• Alle Software (XPS, NAS) ist auf dem neuesten Stand
• Für eco*** eine Regel bei Bitdefender hinterlegt, dass alle Ports genutzt werden dürfen

Rufe ich den Connection Manager auf und versuche eine Verbindung zu erstellen, dauert es eine Ewigkeit, bis etwas passiert. Danach kommt die oben genannte Meldung mit SSL. Ganz selten kommt die Meldung "verbinden", eine Verbindung kommt allerdings nie zustande. Lege ich eine neue Verbindung an, dauert es ebenfalls Minuten, bis ich diese speichern kann. Klicke ich während dieser Wartezeiten auf eine beliebige Fläche im Connection Manager, kann ich diesen nur noch schließen.

Das Protokoll des Servers hat mittlerweile über 8.800 Einträge. Dort fällt auf, dass "localhost:17001" oft auftaucht. Aus meiner Sicht verwunderlich, weil ich mit Server und Client arbeite. Netzwerk ist unverändert als Bridge eingestellt. Es gibt diverse weitere Fehlermeldungen. Der Server an sich läuft.

Ich habe eine ähnliche Lösung bereits im Einsatz, die auf Anhieb lief, allerdings mit einer ältere Version von ecoDMS.

Den Server habe ich gestern bestimmt ein gutes Dutzend mal neu installiert. Den Client ebenfalls. Ich lade nur den Client und den PDF-Drucker herunter.

Es kommt partout keine Verbindung mit dem Server über den Connection Manager zustande. Ich habe keine Idee mehr, was ich sonst noch anstellen kann, um das System zum Laufen zu bekommen.

Hat jemand einen Tipp für mich?

Viele Grüße
Frank

 

[Frank_1234]

Guten Tag,

zu früh gefreut...einmal klappte die Verbindung, jetzt geht wieder nichts mehr. Die Verbindung ließ sich einmalig herstellen, der Client starten. Allerdings blieb der Client dann gleich hängen. Danach war die Verbindung wieder weg. Neuaufbau scheitert wieder.

Ich habe gerade mal die Ports geprüft. Ich habe ja eine funktionierende Installation auf einem anderen Rechner und NAS. Ich hatte für 8080 den Port 17004 eingetragen. Allerdings muss dort der Port 17006 eingetragen werden. Kleine Ursache, große Wirkung: Mit dem Port 17006 funktioniert es jetzt.

Viele Grüße
Frank

 

[Frank_1234]

Guten Tag,

das Problem ist nun gelöst. Die vermutliche Ursache ist ein bisschen speziell. Ich habe den Containermanager noch einmal deinstalliert und nach einem Neustart der DS423+ neu installiert. Danach habe das Image von ecoDMS auf dem NAS und den Client samt Connection Manager auf dem Notebook neu installiert.

In dieser Konstellation, die sich nur durch die einmalige Neuinstallation des Containermanagers unterschied, lief alles auf Anhieb. Was da bei der ersten Installation des Containermanagers schiefgelaufen ist, weiß ich nicht.

Viele Grüße
Frank