[zarafa4h] Umstellung der Speicherung von Anhängen von DB auf Dateibasis

Status
Für weitere Antworten geschlossen.

Banesh

Benutzer
Mitglied seit
09. Sep 2012
Beiträge
51
Punkte für Reaktionen
0
Punkte
6
Hallo,

ich experimentiere gerade mit Zarafa4h und habe meine bestehende alte Datenbank von J.D. Zarafa nach Zarafa4h migriert.
Bei der Gelegenheit habe ich mittels des Scriptes db-convert-attachments-to-files die Anhänge aus der Datenbank in das Filesystem verschoben. Das lief auch soweit Problemlos. Nun habe ich das Problem das Zarafa laut server.log mit der Fehlermeldung "Attachments are stored with option 'database', but 'files' is selected" abbricht.

Das Problem soll gelöst werden können, indem man den Zarafa-Server einmal mit der Option --ignore-attachment-storage-conflict startet. Das Problem ist jedoch, das der Befehl im Docker Container nur die Meldung "Server.cfg nicht gefunden" ausspuckt. Dannach ist meistens der Container sowieso wieder automatisch gestoppt. Also der Container startet, merkt das Zarafa nicht ordnungsgemäß startet, und schleißt sich dann wieder.

Weiß jemand wie ich dem Zarafa-Server die Option --ignore-attachment-storage-conflict gleich beim start mitgeben kann?
 

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.256
Punkte für Reaktionen
52
Punkte
74
Hi,
die Möglichkeit auf Attachments um-zustellen via Skripts und GUI habe ich auf der Feature Liste, aber noch nicht damit experimentiert. Die Grundschritte wie Oben beschrieben kenne ich, ich sehe aber --ignore-attachment-storage-conflict als nicht zwingend an.
Ein -- Switch ist im aktuellen Setup nicht vorgesehen, aber der ignore-attachment-storage-conflict ist auch m.W. in der /etc/zarafa/default Konfig möglich (SERVER_OPTS="--ignore-attachment-storage-conflict"), aber nicht nötig.
Laut Wiki http://wiki.zarafa.com/index.php/Store_attachment_outside_of_the_database braucht man das Ignore nur, wenn man das Skript db-convert-attachments-to-files mehrfach ausführen will. Statt dessen das optionale delete Ausführen und dann geht es m.W.
Nach der Aktion sollte man ürigens die Datenbank reorganisieren via zarafa-backup und dann zarafa-backup resore timestamp; sonst ist der Platz für die Attachments noch allokiert..
Hoffe das hilft.. Wie gesagt ich habe das noch nicht getestet; sollte es Pflicht sein, 1x mit ignore Zarafa Server zu starten, dann muss ich das als Art Utility einbauen => Feature Liste,,,
-TosoBoso
 
Zuletzt bearbeitet:

Banesh

Benutzer
Mitglied seit
09. Sep 2012
Beiträge
51
Punkte für Reaktionen
0
Punkte
6
Ich hab beschlossen es nochmal zu versuchen.

Der Tipp mit der default Konfigurations datei und der Option SERVER_OPTS="--ignore-attachment-storage-conflict" hat erstmal funktioniert.

Nun bekomme ich allerdings die Meldung:

Tue Jul 4 15:31:30 2017: [error ] Unable to write attachments to the directory '/var/lib/zarafa/attachments' - Permission denied. Please check the directory and sub directories.
Tue Jul 4 15:31:30 2017: [ notice] Server shutdown complete.

Den Benutzer des attachments-Ordners habe ich bereits auf den user "zarafa" umgestellt. Auch für die Unterordner. Allerdings wird der nach jedem Neustartversuch der Besitzer des Ordners auf "1030" geändert.
Ist "zarafa" nicht der richtige Eigentümer?
 

Tosoboso

Benutzer
Mitglied seit
27. Aug 2012
Beiträge
1.256
Punkte für Reaktionen
52
Punkte
74
Hi, Zarafa ist der richtige Eingetümer, aber der hat auch eine UID (z.B. 1030) und die UID von Synology muss an den Zarafa Container übergeben werden.
Das funktioniert normalerweise auch, die richtige UID (1030 ist default und unwahrscheinlich) wird beim install gesetzt und jedesmal bein neuem Container (> zarafa reset container) neu gesetzt incl. ACLs, jedenfalls per Design in der z4h 0.6.4.
-TosoBoso
 

otti-o

Benutzer
Mitglied seit
22. Feb 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
Howto Attachments ins Dateisystem verschieben

Hallo zusammen,
ich habe die Umstellung (mit einigen "Lerneinheiten" ;-) geschafft. Damit es bei anderen schneller geht hier meine gesammelten Erfahrungen:

Howto Attachments ins Dateisystem verschieben

Damit die Backups konsistent sind: Fetchmail deaktivieren. Dazu per ssh die Datei /usr/syno/etc/packages/Zarafa4home/zarafa/fetchmailrc umbenennen und eine leere Datei per "touch /usr/syno/..." erstellen. Und damit die Fehlerlogs nicht ganz vollaufen noch die Rechte der neuen Datei an die der alten Datei anpassen. Und um das Ganze abzuschließen fetchmail im Zarafa-Admin neu starten.

Backup Datenbank
Da das Backup von Zarafa zwar die Konfiguration von Zarafa beachtet und alles im laufenden Betrieb sichert aber nicht das schnellste ist nehmen wir Sybex dumper. Es sichert nur die Datenbank und hat auch keine Ahnung von Zarafa aber es ist sauschnell. Dazu das Programm herunterladen (s.u.) und das Verzeichnis sxd aus der zip-Datei in das Verzeichnis web auf der NAS kopieren. Jetzt noch den Browser öffnen und http://your.ip/sxd aufrufen.
Das Programm ist selbsterklärend. Einen Export der Datenbank zarafa4h erstellen.

Vorbereitungen
ssh auf NAS
per "zarafa-cmdline" eine shell im Container öffnen
dort das mysql-Perl Modul installieren mit apt-get update, apt-get upgrade, apt-get install libdbd-mysql-perl

Konvertierung
Im Container cd in das Verzeichnis "/usr/share/doc/zarafa/"
Dort die Konvertierung anstoßen mit "perl db-convert-attachments-to-files root ****** zarafa4h /var/lib/zarafa/attachments (Sternchen durch das Root-pw ersetzen)
Wenn die sauber durchläuft dann das ganze mit angehängtem "delete" nochmal
Anschließend Rechte richtig setzen. Dazu in das Attachments-Verzeichnis gehen und bei allen Dateien den Eigentümer setzen
cd /var/lib/zarafa/attachments
chown zarafa * -R

Umstellung des Servers
Im Container in der Datei server.cfg die Parameter "attachment_storage = files" und "attachment_path = /var/lib/zarafa/attachments" setzen.
Dann ein ps aux|grep zarafa machen und die PID von zarafa-server rausfinden.
Diesen mit kill abschießen
Dann den Server neu starten mit "/usr/sbin/zarafa-server -c /etc/zarafa/server.cfg --ignore-attachment-storage-conflict

Schrumpfen der Datenbank
Wenn Einträge aus der Datenbank gelöscht werden dann wird der Eintrag zwar gelöscht, der Platz in der Datei wird aber nicht freigegeben. Das führt dazu dass die Datenbank trotz entfernter Attachments immer noch die gleiche Größe hat. Um diesen Platz wirklich frei zu bekommen muss man einmal alle Daten in eine externe Datei schreiben, die Datenbank löschen, neu (leer)
anlegen und dann wieder mit den Daten aus der Datei füllen.
Dazu erst mal das Zarafa-Paket stoppen. Mit Sybex Dumper die Datenbank exportieren. Dann die Datenbank umbenennen (vielleicht mit mySQL-Admin) z.B. in zarafa4h-old, dann eine neue Datenbank namens zarafa4h anlegen und die Rechte von der alten zu exportieren und in die neue zu importieren. Danach die zuvor mit Sybex erstellte Sicherung wieder einspielen. Jetzt noch Fetchmail wieder aktivieren (s.o.) und Zarafa wieder starten.
DAS WARS! :)
Und wenn ihr wollt könnt ihr bei der Gelegenheit auch gleich noch die Konfiguration der Datenbank überprüfen. Aber das dürft ihr unten selbst nachlesen. ;-)

Referenzen
Zarafa Server Tuning https://wiki.zarafa.com/index.php/Zarafa_server_tuning
Attachments aus Datenbank ins Dateisystem http://www.synology-forum.de/showth...52316&highlight=attachment_storage#post752316
MariaDB beschleunigen https://www.boernyblog.de/mariadb-auf-synology-diskstation-beschleunigen/
DB beschleunigen http://www.synology-forum.de/showth...e-weiter/page200&highlight=attachment_storage
Sybex Dumper http://sypex.net/en/products/dumper/screenshots/
DB-Backup http://synology.tsu-pe.de/
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat