CrashPlan 4.5.0-0036 - Upgrade

[BigBen2013]

Hall Zusammen,

seit einiger Zeit bemerke ich stets, dass eintreffende Updates nicht korrekt installiert werden können:

Im Protokoll steht lediglich folgendes:

I 01/12/16 09:13PM Eine neuere Version von CrashPlan wird heruntergeladen.
I 01/12/16 09:13PM Herunterladen des Upgrades abgeschlossen - Version 1435726800452.
I 01/12/16 09:13PM Upgrade wird installiert - Version 1435726800452}
I 01/12/16 09:13PM Upgrade fehlgeschlagen - Version 1435726800452
I 01/12/16 09:16PM Stopping CrashPlan
I 01/12/16 09:17PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1435726800452_78.1452629630050

Kann mr jemand mitteilen, wie das Update manuell installiert werden kann?

Im CrashPlan-Ordner ist im UnterOrdner Upgrade die folgenden Dateien enthalten:

drwxr-xr-x 4 root root 4096 Jan 12 21:17 1435726800452_78.1452629630050
-rw-r--r-- 1 root root 38468715 Jan 6 06:32 1435726800452_78.jar
drwxrwxr-x 2 root root 4096 Dec 16 18:50 UpgradeUI
-rw-rw-r-- 1 root root 127 Dec 16 18:50 start.bat
-rw-rw-r-- 1 root root 247 Jan 12 21:17 start.sh
-rw-rw-r-- 1 root root 92 Dec 16 18:50 startDesktop.bat
-rw-rw-r-- 1 root root 312 Jan 12 21:17 startDesktop.sh
-rw-rw-r-- 1 root root 135 Jan 12 21:17 startDesktopLinux.sh
-rw-rw-r-- 1 root root 137 Jan 12 21:17 startDesktopSolaris.sh
-rw-rw-r-- 1 root root 87 Jan 12 21:17 startFirst.sh
-rw-rw-r-- 1 root root 211 Jan 12 21:17 startLinux.sh
-rw-rw-r-- 1 root root 213 Jan 12 21:17 startSolaris.sh

Bislang orientiere ich mich gemäß dieser veralteten Anleitung: http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/

Nach dieser Anleitung müssen folgende Befehle ausgeführt werden:

unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar *.jar -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar lang/* -d /var/packages/CrashPlan/target/

Die Datei-Angabe "1425276000420.jar" muss vor der Ausführung gegen die aktuelle vorhandene Datei ausgetauscht werden.

Mit dem zusätzlichen Ordner "1435726800452_78.1452629630050" weiß ich nichts anzufangen.

Laut der Anleitung muss hier lediglich die Datei update.sh umbenannt werden in update.sh.old

In der Regel läuft das Paket erst wieder an, nachdem der gesamte upgrade-Ordner komplett gelöscht und ein neuer leer angelegt wird.

Zusätzlich ist mir aufgefallen, dass sich die Port-Nummer scheinbar von 4243 auf 4245 geändert hat:

Der Befehl

cat /var/lib/crashplan/.ui_info ; echo

liefert folgende Information:

4245,b946efce-XXXX-XXXX-ac7f-e2499d6098fb,0.0.0.0

In der Client-Configurations wurde diese neue Angabe bereits übertragen.

Hat jemand aktuellere Informationen?

 

[utsiria]

Hallo BigBen,

habe das gleiche Problem mit dem 1435726800452 update. Den Fix nach der o.g. Anleitung hatte ich auch versucht. Crashplan ließ sich danach trotzdem nicht mehr starten. Ich bin beim suchen auf folgenden Link gestoßen: http://blogs.merikan.com/peter/2015/10/03/upgrade-crashplan-on-synology/
Entsprechend habe ich bisher folgendes versucht:

unter /var/packages/CrashPlan/target/upgrade/ habe ich sämtliche Ordner
1435726800452_78.xxxxxxxxxxxxx und die Datei
1435726800452_78.jar gelöscht.

Anschließend ließ sich Crashplan wieder normal starten und im Protokoll wird die Version 4.5.2 angezeigt.

Der Befehl cat /var/lib/crashplan/.ui_info ; echo gibt bei mir immer noch den bisherigen Port aus:
4243,xxxxxxxxxxxxxxxxxxxxxxxxx,0.0.0.0

Nach entsprechendem Anpassen der Datei C:\ProgramData\CrashPlan\.ui_info klappt auch wieder der Zugriff per Webbrowser. Allerdings wird hier noch die Version 4.5.0 angezeigt.


Ist offensichtlich noch keine richtige Lösung - aber vielleicht hilft es einen Schritt weiter.

 

[BigBen2013]

Hallo utsiria,

vielen Dank für die Informationen.

selbst wenn das Paket IPKG nach installiert wird und bash nochmal via /bin/bash aufrubar ist, kann das upgrade-Bash-Script nicht korrekt ablaufen.

Der Befehl ps unterstützt leider in der BusyBox-Version nur den Parameter "w". Im Script wird allerdings der Parameter "e" übergeben.

Da fragt man sich doch allen ernstes, welchen Hintergedanken sich die Designer des Systems dabei hatten, anstelle dem normalen Linux eine verkrüppelte Version darauf zu installieren?

Da kann man ja fast z.B. eine RaspBerry Pi oder eine Virtuelle Maschine von einem Proxmox-Server (jeweils zusammen mit einem Debian 8 System) neben dem NAS stellen und hierüber den Service CrashPlan laufen lassen. Via Samba-Freigabe würde dann auf alle Dateien des NAS-Servers zugegriffen werden können.

Da hätte man es nicht mehr mit irgendwelchen Script-Inkompatibilitäten zu tun.

Zusätzlich braucht dann im NAS nicht mehr die ganze JAVA-Umgebung laufen, die ja auch einige hundert MB RAM belegt.

Jetzt wo ich darüber nachdenke, werde ich es wohl auch in Angriff nehmen. Ein Proxmox-System habe ich eh schon am Laufen.

Da kommt es auf eine CT mehr oder weniger auch nicht mehr drauf an.

Denn alle zusätzlichen Pakete, wie z.B. IPKG u.s.w. funktionieren nur bis zum nächsten System-Upgrade. Danach geht die Suche nch einer funktionierenden Lösung wieder los.

Dennoch vielen Dank.

Werde an dieser Stelle berichten, ob die von mir in der Theorie angedachte Lösung funktioniert.

VG, BigBen

Nachtrag:
=======
Ein Raspberry Pi ist gänzlich ungeeignet. Bei diesem hat die LAN-Schnittstelle eine schlechte Performance. Besser wäre hier z.B. ein Cubieboard. Dieser hat schon 2 GB RAM mit einer ARM-2-Core-CPU. - Auch dieser als allerdings seine Schattenseiten. Ein im Einsatz befindliches Testmodell muss etwa alle 4 - 6 Monate einmal für 1 Sekunde Stromlos gemacht werden. Andernfalls friert das System irgendwann komplett ein. - Es konnte bislang nicht verifiziert werden, ob hier ein Hardwarefehler vorliegt.

Nachdem ein Debian System installiert wurde, stellt sich die Frage, wie man auf den Ordner /volume1 zugreifen kann. Dieser Ordner au dem NAS kann ja nicht freigegeben werden.

Falls hierzu jemand eine Idee hat, immer her damit. (-;

 

[BigBen2013]

Hallo,

nachdem das Paket CrashPlan wieder vom NAS entfernt wurde, läuft sich das NAS-System wieder performant.

Der Prozess CrashPlan hat wegen der zusätzlich geladenen Java-Umgebung zuviel RAM belegt.

Nun läuft CrashPlan auf einem Debian-OS als Virtuelle Maschine in einem Proxmox-System.

Die Freigabe von /volume1 wurde wie folgt gelöst:

1. Normale Freigabe in der Web-Oberfläche des NAS-Systems erstellen.
2. Über SSH den Freigabe-Ordner löschen nd mit "ln -s " als Softlink auf /Volume1 neu anlegen

3. In CrashPlan muss die neu angelegte Freigabe von der Sicherung audgenommen werden. Andernfalls entsteht eine Endlosschleife

Im Debian-System kann einfach mit einem mount-Befehl die Freigabe gemounted werden. Im Idealfall sollte in Debian-System der gemountete Ordner auch /Volume1 heißen. Dann passen auch etwaige verhandene Sicherungen in CrashPlan.

Nachteil dieser Lösung:

- Es muss zusätzlich zum NAS ein weiteres System laufen.
- Alle zu Sichernde Daten müssen erst über das LAN zum Debian-System transportiert werden um dort verarbeitet werden. Anschließend müssen diese normal über das Internet an CrashPlan übertragen werden.

Vorteil:
Etwaige update-Scripte laufen wieder fehlerfrei durch.

Falls Optware im NAS für BASH eingesetzt wurde, kann diese wieder entfernt werden. Folglich tauchen im Sicherheitsbericht keine Warnmeldungen mehr auf.