Z-Push 2.4.1 - Update von Z4H 0.7.4 auf 0.7.5

[Matis]

... hatte ich, leider völlig ohne Erfolg. Erst die Rechteänderung NACH Start von z4h hat nun geholfen, da der Start die vorher schon korrigierten Rechte wieder geändert hatte. Das erklärt auch, warum sich keine weiteren Clients nach dem Update konnektieren konnten, denn durch den Neustart nach DSM Update waren die Rechte wieder falsch gewesen. Das ist ziemlich verzwickt.

 

[dbru]

Hallo Zusammen,

ich habe heute das Update auf 0.7.4 gemacht und habe seit dem das gleiche Problem. Der Versuch mit 0.7.5 hat auch nichts gebracht.
Leider hat auch keiner der Vorschläge funktioniert. Die Befehle habe ich ausgeführt aber ich kann kein mobiles Device mit dem Server verbinden.
im z-push.log stehen folgende Meldungen:

28/05/2018 02:10:41 [ 1906] [ INFO] [#unknown] StateNotFoundException: FileStateMachine->GetState(): Could not locate state '/etc/zarafa/z-push/state/o/n/no-devicedata' - code: 0 - file: /usr/share/z-push/lib/default/filestatemachine.php:126
28/05/2018 02:10:41 [ 1912] [ INFO] [#unknown] The configuration parameter 'USE_X_FORWARDED_FOR_HEADER' was deprecated in favor of 'USE_CUSTOM_REMOTE_IP_HEADER'. Please update your configuration.

Was kann ich noch ausprobieren?

Vielen Dank

 

[Andy+]

Ich hatte das Problem bereits in der v0.7.4, da hatte ich auch das Problem mit der Clientanbindung und habe in WinSCP die Unterordner von z-push (/etc/zarafa4h/z-push/) Gruppe "root" und Eigentümer "http" und Rechte 0775 rekursiv vergeben. Dann lief das bestens.

Wenn das nichts hilft, das Paket stoppen, alles löschen im Verzeichnis /etc/zarafa4h/z-push/state/ und das Paket wieder starten und erneut versuchen. Wenn das auch nicht geht, Backups anfertigen, dann alles, ausser der Datenbank deinstallieren, Reboot und neu installieren. Das Image im Docker besser vorladen, damit die Installation das nicht machen muss und ggf. dadurch Fehler passieren.

 

[Matis]

.... bei mir hat es dann funktioniert, als ich NACH dem Starten von z4h die Rechte der beiden Verzeichnisse nochmals auf 0775 gesetzt habe. Denn beim Start wurden dies des Verzeichnisses wieder eingeschränkt.

 

[dbru]

kein Erfolg, funktioniert immer noch nicht.
Ich habe jetzt zum als Test mal kopano4s ausprobiert klappt sofort...

Wenn ich noch herausfinde wie ich die Datenbank übernehmen kann lasse ich es dabei.

 

[Andy+]

Es gibt eine Migrationsversion, Kopano 8.4.40, in die ein Import der Zarafa Datenbank möglich sein sollte. Nach dem Import Deinstalliert man k4sMigration, behält die Datenbank und Installiert neu drüber.

Schritt 1 davon hat bei mir funktioniert. Das Migrationskopano v8.4.40 lief dann auch. WebAPP und alles weitere funktionierte. Die Datenbank läuft und hat 26 Tabellen, wie bislang.

Danach erfolgte Schritt 2, welcher mit der v8.6.80 von der Installation her zunächst auch läuft. Nach der Datenbankanpassung, welche mit der Reduzierung von 26 auf 25 Tabellen abschliesst, stoppte das Paket und startet nicht mehr. Weshalb, ist aber unklar.

Der Migrationsvorgang ist mir im Grunde unklar. Das führte mich wieder zum unkonventionellen Weg, damit die Datenbank mit einem Import wieder läuft :

- Paket ist wegen des Fehlers bereits gestoppt
- Löschen aller Datenbanktabellen
- Starten des Pakets, damit werden alle Tabellen neu und im aktuellen Format angelegt werden, K4s läuft danach wieder stabil
- Stop des Pakets
- Rücksicherung der Datenbank mit SypexDumper mit der Funktionsvariante INSERT IGNORE
- die Datenbank von Z4H hat 26 Tabellen und die K4S 25 Tabellen, die "26-zigste" Tabelle "clientupdatestatus" nach dem Restore löschen, war ohnehin leer
- Start des Pakets und läuft stabil

Ob auch mit der Migrations-SPK das "kopano4s-backup legacy" und "kopano4s-backup restore timestamp" verwendet wird, ist mir unklar. In diesem Falle hier geht das Datenbankhandling nur mit SypexDumper, erst Export der vorhandenen, K4S installieren und die obige Methode testen. Leider habe ich auch noch keine Lösung für das weitere nach Schritt 1.

 

[hovas]

Ich hatte das Problem bereits in der v0.7.4, da hatte ich auch das Problem mit der Clientanbindung und habe in WinSCP die Unterordner von z-push (/etc/zarafa4h/z-push/) Gruppe "root" und Eigentümer "http" und Rechte 0775 rekursiv vergeben. Dann lief das bestens.

Wenn das nichts hilft, das Paket stoppen, alles löschen im Verzeichnis /etc/zarafa4h/z-push/state/ und das Paket wieder starten und erneut versuchen. Wenn das auch nicht geht, Backups anfertigen, dann alles, ausser der Datenbank deinstallieren, Reboot und neu installieren. Das Image im Docker besser vorladen, damit die Installation das nicht machen muss und ggf. dadurch Fehler passieren.

Moin, ich habe das gleiche Problem und möchte daher auch die Rechte der Unterordner von z-push verändern. Außer bei Z4h habe ich aber mit Docker Containern nicht viel Berührung gehabt und frage mich, wie ich da ran bzw. in den Container rein komme. Das Terminal der Syno-Docker-App brachte mich da leider nicht weiter. Ein kleines Step-by-Step für Docker-Newbies wäre super!

--> Update: Mit dem richtigen Tool (WinSCP) erklärt sich die obige Frage von selbst, da mittels Link für /etc/zarafa4h mir das o.g. Verfahren dann klar wurde. Danke für diesen Hinweis!

 

[Andy+]

Am besten mit WinSCP in die Unterordner /etc/zarafa4h/z-push/ gehen und anpassen, mehr gibts da nicht.

 

[hovas]

Hallo millilenium, das Problem mit der abstürzenden Kalender-App bei mobil editierten Kalendereinträgen habe ich auch. Konntest du das Problem letztendlich mit Z-Push 2.4.1 lösen oder verblieb es beim Downgrade auf Z4H 0.7.4?

 

[millilenium]

Nein ich konnte es leider nicht lösen und habe noch Z4H 0.7.4 im Einsatz

 

[b8wnf9v]

Hallo zusammen,

ich habe bei mir das gleiche Problem, dass Z-Push einfach nicht klappt und immer noch die Meldung mit dem Header kommt.
Kann mir jemand helfen bzw. fällt jemanden hierzu noch etwas ein?

(habe auch einen neuen Thread eröffnet)
https://www.synology-forum.de/showthread.html?99631-Kopano-Z-Push-verbindet-nicht

#######
Bei mir gehts jetzt (AW siehe Link darüber)
#######

LG