Wie geht's mit dem Zarafa Package weiter?

[Matis]

docker log enthält nichst.
zarafa: package.log (der einzige log mit neuen Einträgen)
2017.02.28-20:58:41 Starting Zarafa for Home install..
2017.02.28-20:58:41 Creating database zarafa4h owned by zarafa4h with random internal password
2017.02.28-20:58:41 Tuning zarafa chache-call from 16M to 128M. Also increased other z-caches

 

[Matis]

die zweite Kiste war völlig clean! mariadb komplett neu.

Auf der DS1515 läuft die Installation nicht mal zu Ende, sie läuft sich tot und ich kann nur neu starten, löschen, neu starten und nochmals versuchen.

 

[rolf418]

komisch... hab auf der testmaschine ebenfalls einen clean install gemacht. welche version von zarafa4h hast du installiert? welche pakete sind sonst noch installiert?

 

[Matis]

docker.log:

2017-02-28T21:50:10+01:00 DS1515 docker[21323]: ERRO[1100] Handler for POST /v1.23/containers/create returned error: No such image
: tosoboso/zarafa4h:7.2.1-51838_Web-2.1.2_Push-2.2.13
2017-02-28T21:50:10+01:00 DS1515 docker[21323]: WARN[1100] Could not get operating system name: Error opening /usr/lib/os-release:
open /usr/lib/os-release: no such file or directory
2017-02-28T21:50:28+01:00 DS1515 docker[21323]: ERRO[1118] Attempting next endpoint for pull after error: manifest unknown: manife
st unknown
2017-02-28T21:50:29+01:00 DS1515 docker[21323]: ERRO[1119] unable to get remote tags: Could not reach any registry endpoint
2017-02-28T21:50:29+01:00 DS1515 docker[21323]: ERRO[1119] Not continuing with pull after error: Could not reach any registry endp
oint
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Error setting up exec command in container zarafa4h: No such container:
zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Handler for POST /v1.23/containers/zarafa4h/exec returned error: No suc
h container: zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Error setting up exec command in container zarafa4h: No such container:
zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Handler for POST /v1.23/containers/zarafa4h/exec returned error: No suc
h container: zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Error setting up exec command in container zarafa4h: No such container:
zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Handler for POST /v1.23/containers/zarafa4h/exec returned error: No suc
h container: zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Error setting up exec command in container zarafa4h: No such container:
zarafa4h
2017-02-28T21:50:49+01:00 DS1515 docker[21323]: ERRO[1139] Handler for POST /v1.23/containers/zarafa4h/exec returned error: No suc
h container: zarafa4h
2017-02-28T21:51:22+01:00 DS1515 docker[21323]: ERRO[1172] Error setting up exec command in container zarafa4h: No such container:
zarafa4h
2017-02-28T21:51:22+01:00 DS1515 docker[21323]: ERRO[1172] Handler for POST /v1.23/containers/zarafa4h/exec returned error: No suc
h container: zarafa4h
2017-02-28T21:51:33+01:00 DS1515 docker[21323]: ERRO[1183] Handler for POST /v1.23/containers/zarafa4h/start returned error: No su
ch container: zarafa4h
2017-02-28T21:51:33+01:00 DS1515 docker[21323]: ERRO[1183] Handler for POST /v1.23/containers/zarafa4h/stop returned error: No suc
h container: zarafa4h
2017-02-28T21:51:54+01:00 DS1515 docker[21323]: ERRO[1204] Handler for POST /v1.23/containers/zarafa4h/stop returned error: No suc
h container: zarafa4h
2017-02-28T21:51:54+01:00 DS1515 docker[21323]: ERRO[1204] Handler for DELETE /v1.23/images/tosoboso/zarafa4h:7.2.1-51838_Web-2.1.
2_Push-2.2.13 returned error: No such image: tosoboso/zarafa4h:7.2.1-51838_Web-2.1.2_Push-2.2.13
2017-02-28T21:51:54+01:00 DS1515 docker[21323]: ERRO[1204] Handler for DELETE /v1.23/images/debian:jessie returned error: No such
image: debian:jessie

 

[Matis]

..... ich gehe nun fast davon aus, dass es zu 6.1. irgendwelche db-Ungereimtheiten gibt. Eine Installation war erst wieder möglich mit komplett neu erstellter, leerer Datenbank.

 

[rolf418]

merkwürdig... mit ner clean db und full uninstall funktioniert es jetzt?

kann es sein dass der container nicht sauber gelöscht wurde bzw. dass docker eventuell dessen löschung nicht korrekt realisierte? probier, wenn du lust und zeit hast (ggf. in einer test vm), mal aus ob es problemlos klappt wenn du vor der reinstall docker restartest. vielleicht ein bug von docker in 6.1?

 

[Matis]

ja, aber das war mehr Zufall als System. Nach dem xten Versuch, ohne dass ich wirklich was anders gemacht habe. Irgendwas ist da seit den Updates völlig im argen.
Auf der 716 läuft z4h jetzt auch, aber der Order "zarafa" in der file-station ist nicht vorhanden, damit auch nicht die Backups.
ich hab das Vertrauen an das Paket und an die Synology seit gestern verloren.
Es kann nicht sein, dass nach einem Restart eine komplette Installation im Eimer ist und die Datenbank damit auch nicht mehr zugänglich!

 

[rolf418]

hmm... bekomme gerade angst vor dem nächsten reboot.... ;-)

 

[Andy+]

Ein Reboot ist in aller Regel gut -> jeder Boot tut Good .......

Ich habe bislang auch mit Docker gearbeitet, jedoch gehe ich wegen aehnlicher Ausfaelle mal dazu ueber, das mit Debian Chroot zu testen. Ich habe die Ahnung, dass die Containerinstallation nicht stabil ist oder bleibt.

 

[catweazle71]

Also ich bekomme langsam ein wenig Schiss. Bei mir läuft es aktuell wieder und ich werde absolut nix ändern. Meine DS fährt per Scheduler jede Nacht runter und morgens wieder hoch. Bisher ohne Probleme.

Aber das es immer wieder jemanden gibt, der Probleme hat, kann doch irgendwie nicht sein. Meiner Meinung nach stopft Synology einfach zu viel in die Kiste rein, ich mein ins DSM. Ich selber nutze fast nix. Vielleicht liegt es auch daran, dass es irgendwann bei mir läuft.

@Matis: Ich wäre mal neugierig, was Du sonst so nutzt an Paketen. Und an Beta-Versionen, die aktuell so im Umlauf sind von Synology. Kannst ja vielleicht mal posten.

Ich liste mal meine Pakete auf (ohne sowas wie Perl oder PHP): ActiveBackup, Apache 2.2, Docker, File Station, Hyper Backup, MariaDB, Photo Station, phpMyAdmin, Web Station, WebDAV Server, WordPress und z4h.

Nach dem Upgrade auf 6.1 final lief bei mir ja auch nix mehr. Ich bin so vorgegangen (nach einigen Fehlversuchen):
- Docker deinstall
- z4h komplett deinstall (ohne irgendwelche Optionen für reinstall)
- zarafa Share manuell gelöscht (war nämlich noch da)
- DB überprüft, ob zarafa DB gelöscht (war so)
- DS neu gestartet
- Docker install
- z4h install
- Dann erst mal gewartet, ob der Container oder zarafa selbst wieder abschmiert (war nicht so)
- DS neu gestartet (da zarafa Share nicht sichtbar war; nach Neustart war es da)
- zarafa-backup restore ausgeführt
- Danach musste ich glaub ich noch den fetchmail User anlegen

 

[Matis]

ich nutze eignetlich nur Zarafa4h und Surveillance und den Plattenplatz als Backup für meine Daten.

So wie Du bin ich seither auch immer vorgegangen.
Seither lief die Kiste mehreren Wochen absolut stabil mit der immer gleichen z4h Installation.
Der Reboot nach 6.1. bzw. Update 1 hat dies geändert, sonst habe ich nichts geändert!
Und zwar war z4h weder auf der DS1515+ noch auf der 716+II intallierbar und beide mit dem gleichen Problem.
Obwohl die 716 nie vorher irgendwas anderes als Hyper-Backup gesehen hatte.

Nch zig Neuinstallationen und erst nach dem Löschen der kompletten Datenbank war z4h installierbar.
Inzwischen habe ich die Datenbank wieder über Outlook gefüllt und traue mich nicht mehr meine DS1515 zu booten.
Die 716+II ließ sich nach erneutem Löschen der db auch mit z4h installieren, Das Verzeichnis zarafa ist zwar in volume1 vorhanden (SSH), aber nicht in der FileStation sichtbar (auch nicht nach 2 reboots).
Und ich weiß nicht wie ich das ändern kann. Erneute Installation hat nichts gebracht.

Seither habe ich an die Logik des Systems geglaubt, inzwischen machen ich manche Dinge mehrmals mit anderem Ergebnis.
Das ist nicht mehr nachvollziehbar, kostet mich jede Menge Zeit und läßt mich am Sinn der Kiste zweiferln.
Ich bin keine IT'ler und kann die Fehler nicht nachvollziehen. Ich kann mal ein Script ändern, per Transferleistung, aber keines schreiben.

Ich werde mit der 716+II noch weiter probieren, in der Hoffnung mir ein laufendes z4h Backup installieren zu können.
Wenn ich das zarafa Verzeichnis nicht sehe, bekommen ich auch die db nicht restored.
Vielleicht ist das alles auch zu experimentell.

Auf jeden Fall werde ich auf meiner DS1515+ nicht die kleinste Änderung oder Installation von patches oder anderem mehr machen, bevor sie nicht wochenlang im Markt ist.

 

[coka1999]

Hallo ich bin auch newbee,

versuche grade zarafa4h auf meine 916+ im docker zu installieren. hier meine fragen:
1) Welche Synlogy Pakete müssen vor der Installation installiert werden (Damit meine ich z.B. Mailserver/Maria DB/PHP / Java /usw)
2) Welche reinefolge muss installiert werden.

Habe Docker installiert
dann ngnix1:latest installiert
dann tosoboso/zarafa4h 7.2.1-51838_WEB-2.1.2_Push-2.2.13. installiert

dann die Abbilder gestartet mit default einstellungen.
Container ngnix1:latest läuft
Container zarafa4h läuft kurz an und bleibt dann stehn.

Im Logfile steht tosoboso-zarafa4h1
date,stream,content
2017-03-01 19:32:52,stdout,/usr/local/bin/init.sh: 379: .: Can't open /etc/zarafa/fpm-pool-target
2017-03-01 19:32:52,stdout,/usr/local/bin/init.sh: 377: /usr/local/bin/init.sh: cannot create /etc/zarafa/fpm-pool-target: Directory nonexistent
2017-03-01 19:32:52,stdout,/usr/local/bin/init.sh: 376: /usr/local/bin/init.sh: cannot create /etc/zarafa/fpm-pool-target: Directory nonexistent
2017-03-01 19:32:52,stdout,/usr/local/bin/init.sh: 375: /usr/local/bin/init.sh: cannot create /etc/zarafa/fpm-pool-target: Directory nonexistent
2017-03-01 19:32:52,stdout,/usr/local/bin/init.sh: 374: /usr/local/bin/init.sh: cannot create /etc/zarafa/fpm-pool-target: Directory nonexistent
2017-03-01 19:32:52,stdout,"image intializing UID, GID, etc-cfg, log, ssl
was muss ich machen das der Container läuft ??

 

[Matis]

.... auch nach mehrmaligen Versuch neu zu installieren wird das Verzeichnis "zarafa" nicht sichtbar.
Beim Probieren habe ich folgendes festgestellt:
* wenn das Verzeichnis "zarafa" nicht gelöscht wird, scheitert die Installation
* manuelles Anlegen des Verzeichnisses "zarafa" und dann Installation scheitert ebenso

Mit löschen des Verzeichnisses "Zarafa" habe ich es zumindest geschafft, dass z4h wieder verläßlich neu installierbar ist.
"zarafa" wird aber danach immer noch nicht "sichtbar" für FileStation oder SMB, nur per SSH zu finden.

 

[Matis]

... jemand ne Idee wir ich das "zarafa"-Verzeichnis wieder sichbar bekomme?

 

[MrDisaster]

Hi Matis,

wie ich von 5.2 auf 6.x umgestiegen bin war bei mir noch alles in Ordnung. Mußte kurze Zeit später meine DS komplett neu machen. Nach der Installation fehlt mir auch der Ordner "zarafa" unter Root, ich habe den Ordner einfach in der Systemsteuerung/Gemeisame Ordner selber neu angelegt. Bei Berechtigung habe ich den Benutzer admin und zarafa eingetragen. Ob der Admin dafür nötig ist, weiß ich nicht. Nachdem der Ordner angelegt war, waren alle Unterordner vorhanden und ich konnte meine Backup-Datenbank in den Ordner kopieren und dann mein Backup wieder einspielen. Es gab auch keine Meckern, das es den Ordner schon gibt.

Vielleicht klappt es ja bei Dir auch so auf diesem Weg.

 

[Matis]

Danke für die Rückmeldung. Das hatte ich auch versucht, dann geht die Installation nicht.
Ich hatte allerdings nicht den User zarafa dem Verzeichnis zugeordnet. Guter Tipp. Leider geht es trotzdem nicht, wieder Fehler: Paket konnte nicht gestartet werden.

 

[MrDisaster]

Ich hatte zuerst das Paket installiert und nach der Installation im Anschluss direkt den Ordner erstellt und zuletzt dann mein Backup wieder eingespielt.

Bin mir jetzt mehr sicher, wie ich den Ordner anlegt habe, hatte ich das Paket nicht gestoppt gehabt.

Vielleicht mal in der Reihenfolge probieren.

Gruß
Thomas

 

[Matis]

... wenn das Paket schon installiert ist, gibt es den Ordner schon, aber nur in SSH zu finden. Dann läßt er sich nicht mehr erstellen.
Ich probier grade jede Variante durch.

 

[MrDisaster]

Wie gesagt, bei mir hatte es in der Reihenfolge geklappt. Erst Paket installiert und dann den Ordner über die Systemsteuerung erstellt und dem Benutzer Zarafa zugeordnet. Es gab keine Fehlermeldung, das es den Ordner bereits gibt.

Ich hätte ja gesagt ich teste es nochmal bei mir, ist aber leider mein Produktiv Nas und es würde wieder mecker geben vom WAF, wenn der Kalender wieder nicht geht.

Gruß
Thomas

 

[Matis]

.... so alle Varianten durch. Das Paket läßt sich nur in einer Konstellation erfolgreich installieren:
Verzeichnis gelöscht!
Die DB kann vorhanden sein.
Danach läuft alles, nur das Verzeichnis "zarafa" ist weiter nicht sichtbar und auch nicht neu anzulegen "Vorgang fehlgeschlagen", da in SSH schon vorhanden.

Damit hätte ich wahrscheinlich auch meine DS1515 retten können! Verzeichnis löschen und db stehen lassen!
Das hatte ich nicht ausprobiert! Nur wer kann das wissen in der Panik?
Nachdem ich alle drei Haken rausgemacht hatte und damit auch die db weg war, ging es. Zwei Haken hätten aber auch gereicht!
Das ärgert mich im Nachhinein maßlos. Ich hätte Stunden sparen können.

Das zeigt mir aber endgültig, dass sich mit 6.1. mal wieder gravierend was geändert hat! Ich liebe die Entwickler von Syno. Der Traum aller Anwender!
Heute gut, morgen im Eimer und keine Doku! Super!

Damit bin ich schlauer habe das Problem mit der Verzeichnis-Freigabe immer noch nicht gelöst.
Wenn noch jemand eine Idee hat, gerne!