Kopano kein Mailempfang möglich....Frage zum Postfixverständnis etc

[Gordon696]

Hallo Tosoboso,

vielen Dank für die Unterstützung.
Leider komme ich im Moment nicht dazu mich mit dem Thema ordentlich auseinander zu setzen.

Ein erster Aufruf Deines Scripts meldete mir einen Fehler weil die server.cfg von zarafa nicht im entsprechenden UV zu finden war.
Das ist aber logisch, weil ich kein zarafa mehr installiert habe.
Ich sagte ja das ich keine Parallelinstallation mehr nutze.

Entsprechend werde ich mir Dein Script anschauen wenn ich Zeit habe.
Wird vermutlich Wochenende werden.

Auf jeden Fall nochmal herzlichen Dank für den Support!

Gruß
Gordon

 

[Gordon696]

Hi Tosoboso,

nochmal vielen Dank für Deine Unterstützung.

Ich habe Dein Script genutzt, leider ergeben sich folgende Meldungen bei Nutzung:

root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) resore to kopano-db. 4) user export from kopano migration version 5) restore usersto kopano baseline
2020.01.11-21.59.34 step 1: create baseline dump from kopano...
starting mysql-dump of kopano to /volume1/kopano/backup... use help for detailse.g. on restore
dump done, saving attachments linked to kopano...
dump for kopano completed in 1 : 1 min:sec.
2020.01.11-22.00.38 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legac backup. Add cfg or copy over zarafa dump of today

Frage:
Ich habe einen dump des ursprünglichen zarafas ......muß ich dem dump den Timestamp des heutigen Tages geben damit es funktioniert?

Gruß
Gordon

 

[Andy+]

Nein, Du nimmst für die gewünschte Rücksicherung den Timestamp der letzten oder gewünschten Sicherung, die in Deinem Sicherungsordner liegt.

 

[Gordon696]

Moin...

klappt leider nicht....

root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start ./mysqldump-20191104-202818.gz
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) restore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2020.01.12-07.20.49 step 1: skipped as kopano dump exists for today...
2020.01.12-07.20.49 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legacy backup. Add cfg or copy over zarafa dump of today
root@DiskStation:


Gruß
Gordon

 

[Gordon696]

Bei der Migration via > kopano4s-migration-zarafa start wird zuerst ein Backup gezogen, als Fallback, dann wird auf die Migration Edition geswitched, Zarafa per DB importiert und per Users exportiert und dies in das bestehende k4s importiert. Hoffe das hilft
-TosoBoso

Hi Tosoboso,

habe nun mehrfach versucht den Dump zu übernehme, leider ohne Erfolg.

Siehe output:

root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) restore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2020.01.13-22.36.01 step 1: create baseline dump from kopano...
starting mysql-dump of kopano to /volume1/kopano/backup... use help for details e.g. on restore
dump done, saving attachments linked to kopano...
dump for kopano completed in 1 : 21 min:sec.
2020.01.13-22.37.24 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legacy backup. Add cfg or copy over zarafa dump of today

Output des Logs:
root@DiskStation:/volume1/kopano/backup# more migrate-steps.log
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) rest
ore to kopano-db. 4) user export from kopano migration version 5) restore users
to kopano baseline
2020.01.13-22.36.01 step 1: create baseline dump from kopano...
2020.01.13-22.37.24 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legacy
backup. Add cfg or copy over zarafa dump of today


Wo hängt es denn bei dem Script?
Ich finde es nicht...

Gruß
Gordon

 

[Tosoboso]

Hi Tosoboso, Ich habe Dein Script genutzt, leider ergeben sich folgende Meldungen bei Nutzung:
root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) resore to kopano-db. 4) user export from kopano migration version 5) restore usersto kopano baseline
2020.01.11-21.59.34 step 1: create baseline dump from kopano...
starting mysql-dump of kopano to /volume1/kopano/backup... use help for detailse.g. on restore
dump done, saving attachments linked to kopano...
dump for kopano completed in 1 : 1 min:sec.
2020.01.11-22.00.38 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legac backup. Add cfg or copy over zarafa dump of today
Ich habe einen dump des ursprünglichen zarafas ......muß ich dem dump den Timestamp des heutigen Tages geben damit es funktioniert?

JA genau, der Dump muss vom aktuellen Tag sein, sonst versucht das Skript einen aktuellen Dump zu ziehen, was natürlich nicht geht, da keine Zarafa-DB und etc mit user/pwd vorhanden ist. Ich dachte das erwähnt zu haben und die Fehlermeldung spricht auch vom Dump of Today..
-TosoBoso

 

[Andy+]

Kann man dann einen älteren nicht einfach umdatieren im Dateinamen?

 

[Tosoboso]

Ja klar kann man den Umbenennen / Umdatieren. Die Basislogik der Migration sieht eben vor, dass man am geliechen Tag X mit dem aktuellen Stand migriert
-TosoBoso

 

[Gordon696]

Nabend,

das mit dem einfachen Umbenennen klappt leider nicht.

Die Kopano Dumps sehen wie folgt aus:

dump-kopano-202001132236.sql.gz

Mein alter Zarafa Dump so:

mysqldump-20200116-202818.gz

Nun habe ich den timestamp und auch die Modificationtime auf den heutigen Tag geändert.
Leider ohne Erfolg.

root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start mysqldu mp-20200116-202818.gz
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) rest ore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2020.01.16-21.56.20 step 1: skipped as kopano dump exists for today...
2020.01.16-21.56.20 ERROR no /etc/zarafa(4h)/server.cfg found: cannot run legacy backup. Add cfg or copy over zarafa dump of today


Übersehe ich da etwas?

Nach welchem Muster sucht eigentlich das Skript?

Da es noch ein dump von MariaDB5 ist, kann ich ja schlecht einfach nur den Dateinamen ändern....oder?


Gruß
Gordon

 

[Andy+]

Ich denke schon, dass Du mysqldump-20200116-202818.gz in sowas, wie dump-kopano-202001162236.sql.gz ändern musst. Jedoch bitte berücksichtigen, dass Zarafa 26 Tabellen hat und Kopano 25. Kopano läuft auch mit den 26, ich wollte das hier nur bemerken.

 

[Gordon696]

Jetzt lief es doch durch...siehe output
.
Aber nach Abschluss sieht mein Kopano aus wie vor der Migration.
So wie ich das sehe hat er sehr lange gewerkelt, allerdings ohne den notwendigen dump.


root@DiskStation:/volume1/kopano/backup# kopano4s-migration-zarafa start
Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) restore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2020.01.16-22.22.35 step 1: skipped as kopano dump exists for today...
2020.01.16-22.22.35 step 2: skipped as zarafa dump exists for today...
Stopping Kopano core...
stopping kopano-server..
stopping kopano-spooler..
stopping kopano-dagent..
stopping kopano-gateway..
Stopping Kopano web...
stopping nginx..
stopping php7.0-fpm..
Stopping Kopano mail...
stopping postfix..
Stopping Kopano sys...
stopping rsyslog..
stopping cron..
kopano4s
Kopano services stopped
ls: cannot access /volume1/kopano/backup/dump-zarafa-*.sql.gz: No such file or directory
2020.01.16-22.23.18 step 3: restore zarafa dump of into kopano...
no valid restore argument was provided. Latest timestamp would be <no files exist>
2020.01.16-22.23.23 step 4: starting kopano migration (8.4.5) to run user export...
refresh: initializing container from fresh image loaded at docker hub..
init: remove and build kopano4s docker container from refreshed image.. stop:
remove container:
kopano4s
remove image:
Untagged: tosoboso/kopano4s-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1
Untagged: tosoboso/kopano4s@sha256:ac054294cb95cf3fcfed83dce284a4556ad9cdfa215c935557e57d6b91226b8d
Deleted: sha256:fd817dac472b66a6c5110e1a8f10838700b4801948f33bb48a39a285c1a60b5c
Deleted: sha256:96125bb816dbaffd49ab204f4e5954341cb18a7619b16764be193360672b3e71
Deleted: sha256:412cde449698fb946c00174435d2015af652744d71f5f67f0f9f22d69cb172a5
Deleted: sha256:098dc7d5ed1918c3eab4f933b7f7957cd7e214ee4eb1cef27efdbf78bea6105c
Deleted: sha256:ca0e2eee05931e6d091e9910920f57a8638848447333d49b62338977a7f966d7
Deleted: sha256:557f4b1483f0e07a9693a1d9c1f83069b210e4bfa1c6f03f3a573b8a003cf074
Deleted: sha256:99b5261d397c75b1de2c91f0c89f4e6f287248669b72de6cb143e82ea67ad056
build M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5:
postmap on '/etc/kopano/postfix/valiases'..
postmap on '/etc/kopano/postfix/recipient_bcc'..
postmap on '/etc/kopano/postfix/sender_bcc'..
postmap on '/etc/kopano/postfix/recipient_access'..
postmap on '/etc/kopano/postfix/sender_access'..
waiting for services to restart: 60s..
image intializing UID, GID, etc-cfg, log, ssl, post-build
initializing virtual aliases and pwd e.g. for proxy..
modifying kopano user and group ids (1061 / 65550) plus file limits ..
usermod: no changes
usermod: no changes
usermod: no changes
increasing php upload_max_filesize to 15M..
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "de_DE.UTF-8",
LC_ALL = "de_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
setting acl, ssl, fetchmail and plugins..
at least 1 poll entry must be present and init has to be done before starting it..

2020.01.16-22.39.38 sleep 4 min to have migration version running smoothly with zarafa database import..
2020.01.16-22.43.39 ERROR running imported data (see migrate-server.log); rolling back..
2020.01.16-22.43.39 rollback restore kopano baseline dump of 202001162056 ...
stoping kopano for restore of kopano from dump of 202001162056...
.....
......
.....
.....


Gruß und gute Nacht
Gordon

 

[Tosoboso]

Hi,
die Fehlermeldung weist doch aus, dass kein dump-zarafa gefunden wird. Du musst die an die Namensgebung halten.
ls: cannot access /volume1/kopano/backup/dump-zarafa-*.sql.gz
Wenn du die Tools zum Sichern der Datenbanken verwenden würdest, die ich angehängt hatte, dann sollte der dump auch passend heissen.
Ansonsten benenne den dump analog zur Nomenklatur der Kopano-Sicherung um: dump-zarafa-timestamp.sql.gz
Was hier passiert, ist, dass nach einem Fehler, in dem Fall Dump nicht gefunden das Skrippt einen roll-back macht und dann sieht alles aus wie zuvor..
-TosoBoso

 

[Gordon696]

Hi Tosoboso.

Ich muß wohl genauer beschreiben wo die Schwierigkeiten liegen.

Das Script das du angehängt hast, kann nur kopano oder kopano4s sichern.
Zumindest sagt mir das der output:
Somit in meiner Situation nicht nuzbar.

root@DiskStation:/volume1/kopano/backup# ./mySqlDumpDbs.sh -help
Pleae provide MariaDB root password : xxxxxxxxxxx
no database -help to backup use e.g.: kopano4s kopano
root@DiskStation:/volume1/kopano/backup# ./mySqlDumpDbs.sh zarafa
Pleae provide MariaDB root password : xxxxxxxxxxx
no database zarafa to backup use e.g.: kopano4s kopano
root@DiskStation:/volume1/kopano/backup# grep zarafa mySqlDumpDbs.sh (offensichtlich wird zarafa in diesem Skript nicht berücksichtigt)

Hier auch nochmal Details zur Ausgangsituation:

Es läuft iinzwischenDSM 6.2x und Kopanos4s installiert.
Kein Zarafa mehr am laufen und somit auch keine Möglichkeit mehr über die Zarafa/Kopano Skripte zu dumpen.
So zumindest mein aktueller Kenntnisstand und meine Ergebnisse von verschiedenen Versuchen.
Würde mich freuen wenn es doch irgendwie geht.


Ich habe noch einen Dump der ursprünglichen Datenbanken den ich zurücksichern wollte..

mysqldump-20200117-202818.gz (das war die der ursprüngliche Dateiname)

dump-zarafa-202001172056.sql.gz (gleicher Dateiinhalt, aber angepasst an die Notwendigkeiten des Skripts kopano4s-migration-zarafa)

Nachdem ich diesen Dump angepasst habe und alle Attribute Sktipkonform angepasst habe, lief es ansatzweise.
Das Skript brach ab, nachdem es an dem falschen bzw fehlenden Passwort der IT Wiki DB hängen blieb.

Gibt es die Möglichkeit eine spezielle DB über phpMyAdmin zu dumpen und dann in die neue kopano DB zu übernehmen?

Wenn noch weitere Infos benötigt werden um sich ein besseres Bild der Situation zu machen, bitte fragen.

Soviel in Kürze zur Situation.....

to be contnued......


EDIT:
Wenn ich es denn hinbekommen würde erfolgreich mit dem Skript zu migrieren (kopano4s-migration-zarafa).
Hätte ich dann einfach die alten Mails und Verzeichnisse wenn ich mein Kopano4s wieder starte oder muß ich in der server.cfg oder einer anderen Config Datei etwas anpassen?