Kopano4S (Zarafa 2.0)

[Andy+]

....Mit "kopano4s-backup" ist das anders, das läuft....

Ich habe auf meinem Testsystem

K4S gestoppt,
die Datenbank geleert,
in der server.cfg von 'files' auf 'database' umgestellt
die im Produktivsystem mit "kopano4s-backup" erstellten *sql.gz auf das Testsystem kopiert
K4S gestartet, die Tabellen wurden alle neu angelegt
"kopano4s-backup restore" gestartet, der neuste Timestamp wird angezeigt (hier 201909051700)
"kopano4s-backup restore 201909051700 gestartet
K4S gestartet > Läuft

Die Anhänge sind auch da wieder in der Datenbank. Damit habe ich nun zwei einwandfrei funktionierende Lösungen, mit der Datenbanksicherung so umzugehen, dass ich eine Wiederherstellung darstellen kann.

 

[Andy+]

Was nicht funktioniert über "kopano4s-backup", ist, von

attachment_storage = database
auf
attachment_storage = files

umstellen zu wollen, oder andersrum. "kopano4s-backup" stellt das wieder her, was gespeichert wurde. In der Tabelle "lob" sind die Anhänge gespeichert und diese wird gefüllt, ob "database" oder "files" hinterlegt wurde. Ich kann es nicht testen, aber diese Umstellung geht wohl nur mit "kopano-backup". Mit Outlook geht die Umstellung ganz sicher.

 

[honk013]

So . . . . Melde Vollzug .... Downgrade vollzogen.
Das hat alles eigentlich ganz gut geklappt. Mein "backup-user.log" sah so aus:

2019-09-05 19:01:35,224 - backup - INFO - starting backup
2019-09-05 19:01:35,307 - backup - INFO - queued 2 store(s) for parallel backup (5 processes)
2019-09-05 19:01:35,324 - backup4 - INFO - backing up: public
2019-09-05 19:01:35,335 - backup4 - INFO - backing up public took 0.02 seconds (0 changes, ~0.00/sec, 0 errors)
2019-09-05 19:01:35,367 - backup0 - INFO - backing up: frankxxxxx
2019-09-05 19:17:27,486 - backup0 - INFO - backing up frankxxxx took 952.15 seconds (8218 changes, ~8.63/sec, 0 errors)
2019-09-05 19:17:27,489 - backup - INFO - queue processed in 952.18 seconds (8218 changes, ~8.63/sec, 0 errors)
2019-09-05 19:17:27,490 - backup - INFO - stopping backup
Kopano brick level backup completed in 15 : 55 min:sec...
per user kopano created in backup share (container: /var/lib/kopano/backup): frankxxxx

und nach dem Downgrade sah das bei mir so aus:

2019.09.05-19.34.26 step 2: run differential kopano user backup (backup-user.log)...
2019-09-05 19:34:27,346 - backup - INFO - starting backup
2019-09-05 19:34:27,436 - backup - INFO - queued 2 store(s) for parallel backup (4 processes)
2019-09-05 19:34:27,449 - backup1 - INFO - backing up: public
2019-09-05 19:34:27,465 - backup1 - INFO - backing up public took 0.02 seconds (0 changes, ~0.00/sec, 0 errors)
2019-09-05 19:34:27,489 - backup0 - INFO - backing up: frankxxxx
2019-09-05 19:35:20,696 - backup0 - INFO - backing up frankxxxx took 53.23 seconds (0 changes, ~0.00/sec, 0 errors)
2019-09-05 19:35:20,698 - backup - INFO - queue processed in 53.26 seconds (0 changes, ~0.00/sec, 0 errors)
2019-09-05 19:35:20,699 - backup - INFO - stopping backup
Kopano brick level backup completed in 0 : 55 min:sec...
per user kopano created in backup share (container: /var/lib/kopano/backup): frankxxxx

Das hat alles gepasst. Man muss nur Geduld haben. Die Sachen brauchen ihre Zeit. Ich habe mir immer den Ressourcen-Monitor angeschaut und wenn der zur Ruhe kam gab es noch etwas Zeitnachschlag.


Das einzige was ist: Ich habe jede Menge Meldungen im "restore-user.log". Das sieht dann so aus:

2019.09.05-19.44.23 Restoring user frankxxxx incl. creation with current pwd..
2019-09-05 19:44:23,946 - backup - INFO - starting backup
2019-09-05 19:44:23,957 - backup - INFO - starting restore of frankxxxx
2019-09-05 19:44:24,005 - backup - INFO - restoring to store 0000000038A1BB1005E5101AA1BB08002B2A56C200007A617261666136636C69656E742E646C6C0000000000B2E2EB5F8ED345159B097C015071F0680100000001000000C99E166FD74248FD976D5C7B5F25689370736575646F3A2F2F556E6B6E6F776E00
2019-09-05 21:09:28,695 - backup - INFO - restoring metadata
2019-09-05 21:09:28,762 - backup - ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc
try: yield
File "/usr/lib/python3/dist-packages/kopano_backup/__init__.py", line 886, in load_acl
member_type, value = row[1].Value
AttributeError: 'int' object has no attribute 'Value'

2019-09-05 21:09:28,786 - backup - ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc
try: yield
File "/usr/lib/python3/dist-packages/kopano_backup/__init__.py", line 934, in load_rules
etxml = ElementTree.fromstring(data)
File "/usr/lib/python3.5/xml/etree/ElementTree.py", line 1344, in XML
parser.feed(text)
TypeError: a bytes-like object is required, not 'dict'

2019-09-05 21:09:28,823 - backup - ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc
try: yield
File "/usr/lib/python3/dist-packages/kopano_backup/__init__.py", line 886, in load_acl
member_type, value = row[1].Value
AttributeError: 'int' object has no attribute 'Value'

und so weiter. Was will mir das sagen? Muss ich mir Gedanken machen?

 

[Andy+]

Gratuliere, ist die neuste Stable Version drauf und läuft?

 

[honk013]

Naja, was soll ich sagen. Fetchmail geht nicht, die vielen Meldungen im "restore-user.log" irretieren mich doch sehr ( 2019-09-05 21:09:29,194 - backup - ERROR - Traceback (most recent call last) und die Verbindung zu Outlook/Androiden habe ich noch nicht versucht!

Läuft wäre vielleicht etwas übertrieben. Ich muss mich heute damit noch weiter befassen.

 

[Andy+]

Vielleicht zunächst nochmals ist die neuste Stable Version nun drauf? Welches Image läuft? Geht WebAPP usw.? Stimmt die Datenbank in phpMyAdmin? Reboot erfolgt?

Wichtig ist erst mal, dass alles soweit plausibel aussieht, vom Grundsatz her läuft und die Datenbank iO. ist. Wenn Du nicht weiterkommst, hast Du noch immer die Option, die aktuelle Datenbank zu sichern und eine Neuinstallation durchzuführen. Aber erst mal Schritt für Schritt.

 

[honk013]

Moin Andy,
ja, die letzte Stable Version 1.0.4 ist drauf (Kopano4S D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 installed!). Es gibt nur ein Abbild in Docker und dieser Container läuft auch. Auch das WebAPP funktioniert. Das sieht so also eigentlich gut aus!
Rebootet habe ich die DS auch schon ein paar Male, die Konten aus Fetchmail gelöscht und neu angelegt (mit restart von Fetchmail) und auch die anderen Eingabefelder kontrolliert.
Ich denke, dass ich die Version noch einmal deinstalliere (mit behalten der Datenbank) und dann neu installiere; so wie Du es mir beigebracht hast. Mal sehen, was dann ist.

Zu den Log-Files: Da in allen anderen Log-files alles in Ordnung war, habe mir jetzt einmal den "restore-user.log" etwas genauer angeschaut.
Er sieht vereinfacht so aus:
2019.09.05-19.44.23 Restoring user frankxxxx incl. creation with current pwd..
2019-09-05 19:44:23,946 - backup - INFO - starting backup
2019-09-05 19:44:23,957 - backup - INFO - starting restore of frankxxxx
2019-09-05 19:44:24,005 - backup - INFO - restoring to store 0000000038A1BB1005E5101AA1BB08002B2A56C200007A617261666136636C69656E742E646C6C0000000000B2E2EB5F8ED345159B097C015071F0680100000001000000C99E166FD74248FD976D5C7B5F25689370736575646F3A2F2F556E6B6E6F776E00
2019-09-05 21:09:28,695 - backup - INFO - restoring metadata

*****FEHLERMELDUNGEN******

2019-09-05 21:09:36,705 - backup - WARNING - skipping delegation for unknown user 'b'usernames''

*****FEHLERMELDUNGEN******

2019-09-05 21:09:36,723 - backup - INFO - restore completed in 5112.72 seconds (8218 changes, ~1.61/sec, 391 errors)
2019-09-05 21:09:37,392 - backup - INFO - stopping backup
Kopano brick level backup completed in 85 : 15 min:sec...

*****FEHLERMELDUNGEN******

2019-09-05 21:09:43,255 - backup - WARNING - skipping delegation for unknown user 'b'usernames''

*****FEHLERMELDUNGEN******

Kopano brick level backup completed in 0 : 5 min:sec...

Die 782 Fehlermeldungen sind genauer betrachtet immer die gleichen zwei:

1.) 392 mal die Meldung
2019-09-05 21:09:28,762 - backup - ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc
try: yield
File "/usr/lib/python3/dist-packages/kopano_backup/__init__.py", line 886, in load_acl
member_type, value = row[1].Value
AttributeError: 'int' object has no attribute 'Value'

2.) 390 mal die Meldung

2019-09-05 21:09:28,786 - backup - ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc
try: yield
File "/usr/lib/python3/dist-packages/kopano_backup/__init__.py", line 934, in load_rules
etxml = ElementTree.fromstring(data)
File "/usr/lib/python3.5/xml/etree/ElementTree.py", line 1344, in XML
parser.feed(text)
TypeError: a bytes-like object is required, not 'dict'

Nur die Zeiten sind bei jeder Meldung geringfügig unterschiedlich. D.h. beim restoren der User ist das Script immer wieder über diese zwei Fehler gestolpert.

Kann mir einer sagen, was diese zwei Fehlermeldungen zu bedeuten haben? Ich habe keine Ahnung!

 

[honk013]

Anscheinend habe ich auch eine funktionierende Beta-Version gegen ein nicht richtig laufende Stable getauscht zu haben...Grrrrrrrr

Emails senden und empfangen geht nicht. Warum, keine Ahnung.Habe schon vieles probiert.
Beim Senden sagt mir die WebAPP:
Unfortunately, kopano-spooler was unable to deliver your mail to the/some of the recipient(s).
You may need to contact your e-mail administrator to solve this problem.
und das "spooler.log" meint:
Fri Sep 6 15:58:18 2019: [error ] [24395] RCPT line gave SMTP error: 451 4.3.0 <stxxxx@xxxxx-net.de>: Temporary lookup failure. (will be retried)
Fri Sep 6 15:58:18 2019: [error ] [24395] SMTP: Error while executing command 'DATA'. Response: 554 5.5.1 Error: no valid recipients
Fri Sep 6 15:58:18 2019: [warning] [24395] E-mail for user frankxxxx could not be sent, notifying user: cancel message (40580)

Hat jemand eine Idee? Danke.

 

[Andy+]

Vielleicht Fetchmail und Postfix restarten und Fetchmail Init auslösen, DS dann nochmal rebooten. Wenn Senden und Empfangen nicht geht, ist das sehr ungewöhnlich. Jedenfalls kommt beim protokollarischen Austausch mit dem Provider wohl keine Verbindung zustande. Prüf mal die SMTP Einstellungen, oder speichete die neu ab.

 

[honk013]

Habe ich schon mehrfach gemacht; o.E.

Das fetchmail.log sagt:
fetchmail: Connection errors for this poll:
name 0: connection to sv35.domainunion.de:995 [172.17.0.2/995] failed: Connection refused.
fetchmail: POP3 connection to sv35.domainunion.de failed: Connection refused
fetchmail: Query status=2 (SOCKET)

Wer oder was ist bitte "name 0"?

 

[Matis]

Das Problem mit fetchmail / smpt und OL (über reverse proxy) hatte ich nach dem downgrade auch.
Ich habe damals nochmals deinstalliert und neuinstalliert (db natürlich behalten). Das löste das Problem mit SMTP und dass ich mit OL nicht mehr verbinden konnte.

Dann mehrmals die fetchmail Einträge über putty manuell gelöscht, neu aufgesetzt und fetchmail neu gestartet. Hat alles nix gebracht.
Als ich dann die fetchmail Einträge im K4s-Admin UI gelöscht habe und neu aufgetzt, ging es plötzlich? Zufall? probieren ist es wert.

Dann hatte ich noch ein Sync Problem mit den Apple-Geräten. Das konnte gelöst werden durch löschen aller devices im k4s-Admin UI.
Die Geräte haben sich dann neu angemeldet und synchronisiert und es läuft seither problemlos.

Als resume habe ich mir gedacht, dass da beim update irgendwas mit der Netzwerkconfig des Containers verbogen wurde (???)

 

[Andy+]

Vieleicht ist es die POP-Einstellung mit Port 995. Hat die vorher auch funktioniert? Ich konfiguriere das pro Konto immer so:

kopano-fetchmail add USER EMAIL PASSWORT IMAPSERVER imap 993 ssl INBOX
kopano-fetchmail init
kopano-fetchmail restart

 

[honk013]

Bei IMAP SSL ist Port 993 richtig. Für POP ist der Port 995.
Alle Einstellungen sind wie vorher. Jetzt schon zig mal geändert und überschrieben. Fast 100mal Dienste neu gestartet oder komplett die Syno rebootet. NO HELP.
Mache jetzt seit fast 6 Stunden daran rum; Faxen für heute DICK.

Vielen Dank für Eure Hilfe, jetzt ist bei mir der Alkohol dran.

 

[Andy+]

Du hast die Basis mit der Datenbank. Mach Sicherungen davon und eine saubere Neuinstallation. Schritte weist Du ja noch… ansonsten liste ich die nochmal, kein Thema. Ich denke, da ist was verbogen. Deine Anhänge sind, soviel ich noch weiss in der Datenbank. Lösche also alles, ausser Datenbank, Reboot, Neuinstall usw...

 

[sky63]

*wird mal bei seiner 0.9.8 bleiben bis alle Klarheiten beseitigt sind.

gruss,
sky

 

[honk013]

Moin allerseits,

ein neuer Tag, vielleicht ein neues Glück. Heute versuche ich weiter.

Der Downgrade hat m.E. ja geklappt. Die Stable Version kann und habe ich schon zwei Mal installiert und deinstalliert. Das funktioniert . Auch scheinen alle Termine, Kontakte, Mails etc. da zu sein; das sieht jedenfalls so im WebAPP aus.

Warum das Senden und Empfangen noch nicht geht, k.A.

Ich werde jetzt noch einmal Deinstallieren und Installieren. Dazu eine Frage: Muss ich den Punkt "add webapp & z-push as reverse proxy ......." beim Installieren anhaken oder nicht?

 

[Andy+]

Nein, würde ich weglassen, da hatte ich schon Störungen deswegen. Dass ist m.W. nur, um die 9443 weglassen zu können und damit eine https:// Adresse genügt.

 

[Andy+]

Im Offline-Modus bekomme ich gelegentlich die Meldung



Was hat das zu bedeuten?

 

[honk013]

Moin Andy,
alles klar. Dann werde ich die nächste Runde einläuten. Wäre doch gelacht, wenn man das nicht hinbekommt

Was Deine Fehlermeldung angeht; ich habe mit dem KOE-Client gearbeitet und der hat mir so eine Meldung nie geschmissen.

 

[491810]

[...] "kopano-restore" hat als Voraussetzung "kopano-backup", um rücksichern zu können, daher hängen diese zusammen.

Wofür ist denn "kopano4s-backup" gedacht? Dachte damit könnte ich meine Kopano4s DB-Schema sichern und wiederherstellen.
Wollte jetzt ein Vollbackup (Skript "kopano-backup") und dann nur Differenzsicherungen (Skript "kopano-backup --difference") machen (?)

Geht das so? Habe gesehen, dass "kopano-backup" direkt in "/volume1/kopano/backup" Unterordner anlegt "--differential" aber im Ordner
"/volume1/kopano/backup/differential". Passt das dann so? Oder brauche ich dann gar kein Vollbackup (da das ja nicht im selben Ordner ist)?

Die Sicherung in einen anderen Ordner anzulegen wäre der Befehl dann ja wie folgt (, oder?):"kopano-backup --differential -f /volume1/kopano-backup"?