Kopano4S (Zarafa 2.0)

[Andy+]

kopano4s-backup macht immer eine 1:1 Sicherung der DB und entsprechend ein Restore und dabei geht man mit 1 oder 2 gz Dateien um. Die Tabellen können leer oder nicht vorhanden sein. kopano-backup ist da differenzierter und komplexer, wie man sieht. Differentialsicherung, Anhangumstellung, individuelle Userbearbeitung usw. Für den Alltag ziehe ich sowas, wie kopano4s-backup vor.

 

[491810]

Was würdest Du denn empfehlen? Mit "Kopano4s-backup" (wo ich am Ende zwei Dateien habe) fühle ich mich eigentlich wohler als mit dem ganzen Ordner-Krims-Krams.
Mit "kopano4s-backup" mache ich ein Initialbackup oder kann ich direkt mit "kopan4s-backup --differential" starten? wie ist denn da die Logik beim Restore des Backups?

Braucht es immer das Vollbackup als Basis? Und wie läuft das bei "kopano-backup" wenn ich ein Vollbackup und dann mit "--differential" weiter die Sicherungen mache?
"kopano-backup" sichert ja in den Ordner "/volume1/kopano/backup" und erstellt die Unterordner woegegen "--differential" in ein Unterordner "/differential" darunter sichert.

Muss ich da auch die Ordner unter "/kopano/backup" wie auch die im Unterordner "/kopano/backup/differential" aufheben? Wei weiß ich wann ich was löschen kann???
Ich kenne das immer so, dass ich bei einem differentiellen oder Inkrementellen Backup als Basis die Vollsicherung aufheben muss sonst klappt der Restore nicht mehr.

 

[honk013]

Auch dieser Tag war kein GUTER TAG.

Ich habe die Version 1.0.4 Stable bestimmt 10mal installiert und deinstalliert (mit verschiedensten Einstellungen), ich habe die 1.0.3 installiert und auf die 1.0.4 upgedatet. Alles keine Chance; Senden und Empfangen geht nicht.

Die Spooler.log sagt mir jetzt etwas von:
Sat Sep 7 16:56:53 2019: [error ] [ 63] Unable to get outgoing queue count: network error (80040115)
Sat Sep 7 16:56:53 2019: [warning] [ 63] ProcessQueue: ProcessAllEntries failed: network error (80040115)
Sat Sep 7 16:56:53 2019: [warning] [ 63] Server connection lost. Reconnecting in 3 seconds...
Sat Sep 7 16:56:53 2019: [error ] [ 63] gsoap connect: ()
Sat Sep 7 16:56:53 2019: [error ] [ 63] HrLogon server "default:" user "SYSTEM": network error
Sat Sep 7 16:56:53 2019: [error ] [ 63] Unable to open admin session: network error (80040115)

Irgendetwas scheint mit dem "network" nicht zu stimmen!! Aber allen Unkenrufen gleich gesagt: Die DS hängt am Netz!! Warum Kopano bzw. Postfix und Fetchmail nicht ins Netzwerk kommen, keine Ahnung.

Langsam beschleicht sich bei mir der Eindruck, dass vielleicht doch etwas beim Downgrade falschgelaufen ist?!

Werden denn irgendwelche Daten diesbezüglich (Network) in der Database gespeichert? Da ich ja mehrfach De- und Installiert habe.

 

[honk013]

Desweiteren sagt mir mein "server.log" ich soll das reporten:

Sat Sep 7 16:45:06 2019: [warning] Shutting down
Sat Sep 7 16:45:06 2019: [crit ] ----------------------------------------------------------------------
Sat Sep 7 16:45:06 2019: [crit ] Fatal error detected. Please report all following information.
Sat Sep 7 16:45:06 2019: [crit ] kopano-server 8.7.1
Sat Sep 7 16:45:06 2019: [crit ] OS: Debian GNU/Linux 9 (stretch) (Linux 4.4.59+ x86_64)
Sat Sep 7 16:45:06 2019: [crit ] Thread name: NotificationMan
Sat Sep 7 16:45:06 2019: [crit ] Peak RSS: 39380
Sat Sep 7 16:45:06 2019: [crit ] Pid 52 caught SIGSEGV (11), traceback:
Sat Sep 7 16:45:06 2019: [crit ] Backtrace:
Sat Sep 7 16:45:06 2019: [crit ] f0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x4a4e0) [0x7f8538ee24e0]
Sat Sep 7 16:45:06 2019: [crit ] f1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x32ba6) [0x7f8538ecaba6]
Sat Sep 7 16:45:06 2019: [crit ] f2. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x32dca) [0x7f8538ecadca]
Sat Sep 7 16:45:06 2019: [crit ] f3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0) [0x7f8533bb30e0]
Sat Sep 7 16:45:06 2019: [crit ] f4. /usr/sbin/kopano-server(+0x105f0) [0x55bef9d005f0]
Sat Sep 7 16:45:06 2019: [crit ] f5. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(+0xb030f) [0x7f8538b4630f]
Sat Sep 7 16:45:06 2019: [crit ] f6. /lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4) [0x7f8533ba94a4]
Sat Sep 7 16:45:06 2019: [crit ] f7. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f853304ed0f]
Sat Sep 7 16:45:06 2019: [crit ] Signal errno: Success, signal code: 1
Sat Sep 7 16:45:06 2019: [crit ] Sender pid: 0, sender uid: 0, si_status: 947166816
Sat Sep 7 16:45:06 2019: [crit ] Signal value: 947166816, faulting address: (nil)
Sat Sep 7 16:45:06 2019: [crit ] When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version.
Sat Sep 7 16:48:14 2019: [=======] Starting kopano-server version 8.7.1 (pid 36 uid 0)
Sat Sep 7 16:48:14 2019: [=======] Starting kopano-server version 8.7.1 (pid 36 uid 1048)

Alles böhmische Dörfer für mich.

 

[honk013]

Boahh ey .... es wird.

Senden geht wieder und empfangen auf einer Domain auch schon wieder. Auf der anderen noch nicht; das könnte aber auch Serverseitig ein Fehler sein. Ich habe da mal eine E-Mail hingeschrieben und warte auf Antwort.

Auf jeden Fall lasse ich das jetzt erst einmal so.

Kopano4S D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 installed! und Kopano health status OK. WebAPP geht. Was will man noch mehr. Ja, Outlook und die Mobiles sind morgen dran.

Also Downgrade geht, mit viel Zeit und Arbeit!!!!!

 

[Andy+]

Die von Dir beschriebenen Fehler können DS-individuell sein, das ist teils ziemlich verschieden, die böhmischen Dörfer wären damit für mich auch, wobei beim ersten Post scheint es ein Anbindungsproblem mit Deinem Provider zu geben. Aber Hauptsache ist erst mal, dass es wieder läuft, sehr gut! Ich denke, nacheinander geht das wieder. Wenn Du noch Probleme hast, dann sende es.

 

[Tosoboso]

Warnungen beim Downgrade in Restore-User.log

. Downgrade vollzogen.. 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 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'
Was will mir das sagen? Muss ich mir Gedanken machen?

Hi, das sind Warnungen, die beim Laden der Meta-Data respektive ACLs anderer User gegen den eigenen Store entstehen, falls Diese nocht nicht existieren. Das ist ein Problem(chen) mit der Reihenfolge. Ursprünglich hatte ich das pragmatisch so gelöst, dass am Ende des Resore Loops nochmals alle Meta-Daten Geladen werden, was aber zu diesen Warnungen führt, die man ignorieren kann. Ich habe nun eine bessere Lösung ohne Warning gefunden, indem zuerst alle User angelegt werden und dann in der 2. Loop die User Daten und dann erst die Metadaten Geladen werden. So gibt es das Problem nicht mehr, dass ACLs geladen werden sollten, für User, die noch nicht existieren.
Ich hatte die ersten Tests mit bereits angelegten Usern gemacht und daher bin ich nicht in diesen Fall gelaufen; aber mit der Anpassung ist es nun besser und geräuscharm..
-TosoBoso

 

[Tosoboso]

Boahh ey .... es wird. Auf jeden Fall lasse ich das jetzt erst einmal so. Kopano4S D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 installed! und Kopano health status OK. WebAPP geht. Was will man noch mehr. Ja, Outlook und die Mobiles sind morgen dran.Also Downgrade geht, mit viel Zeit und Arbeit!!!!!

Hi, freut mich dass es vorangeht und einige der Fehler, die du hast kann ich mir nicht erklären, aber auf die Warnungen beim restore User habe ich eine Erklärung (siehe Oben). Eigentlich sollte der Downgrade nicht so aufwendig sein.
Die Pakete Stable Default zu Beta Community sind übrigens identisch in Funktion und nur die Kopano Binaries sind Anders, insofern sollte sich das Verhalten nicht Ändern und du bist in irgend eine verzwackte Sache rein gerannt; Syno seitig, oder so. Naja Glück auf!
-TosoBoso

 

[Andy+]

Nach wie vor gibt es keine neue Deskapp, weiss da jemand was?

https://download.kopano.io/community/deskapp:/

 

[honk013]

Hi, das sind Warnungen,........die man ignorieren kann. TosoBoso

Puuhhh.... Das hört sich ja schon mal gut an.

Bzgl. USER habe ich da noch folgende Meldung in meinem "server.log"

Mon Sep 9 09:43:52 2019: [warning] K-1515: Object not found unknown user "Everyone": Everyone

Die kommt auch ständig. Laut meinem "Kopano4S-Admin -> USER" gibt es keinen USER "Everyone". Es gibt, so bei jedem denke ich, eine Group "Everyone". Aber keinen USER. Was ist da los?

 

[honk013]

Langsam bin ich an einem Punkt angekommen, dass ich überlege Kopano KOMPLETT zu löschen. Es nervt, wenn Sachen nicht funktionieren und irgendwo ein Fehler/Bit falsch sitzt und man die Nadel im Heuhaufen sucht.

Ein letzter Versuch, vielleicht weiß ja einer von Euch weiter.

Ausgangslage: 2 Domains mit E-Mailkonten auf unterschiedlichen Servern. Auf Server 1, der noch das uralte Protokoll TLS1.0 im Moment unterstützt, funktioniert der E-Mailabruf. Auf Server 2, der nur noch TLS 1.1 und höher unterstützt, funktioniert der E-Mailabruf nicht. Die Fehlermeldung im "fetchmail.log" lautet:
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)

Die Konten habe ich zig-mal unterschiedlich in Kopano angelegt, immer das gleiche Ergebnis. Mit dem Provider geschrieben; Aussage siehe oben.

Wenn ich die Kontodaten im Mozilla Thunderbird eingebe, funktioniert das ohne Probleme. Es muss also irgendwie an Fetchmail liegen. Nur WO?

Ich bin für jeden Tip dankbar.

Vor dem Downgrade, den ich am Freitag gemacht habe, funktionierte noch alles und ich glaube nicht, dass der Provider am Wochenende das auf seinem Server geändert hat. Das wäre ja ein Zufall.

 

[sky63]

Ist das schon die fetchmail-Ausgabe mit -v -v? (ja zweimal). Da würde ich mehr erwarten.

gruss,
sky

 

[honk013]

Moin Sky,

ich bin ein IT-Analphabet. Was meinst Du bitte mit fetchmail-Ausgabe -v -v?
Dieses Log finde ich im Admin GUI.
Gruß
Frank

 

[sky63]

Du kannst das Logging vom fetchmail erweitern indem du beim starten "-v" oder "-vv" als Parameter mitgibst.

Verbinden per putty auf die syno
Ausführen von kopano-cmdline
Dann die Datei /etc/default/fetchmail editieren. Normalweie sollte die letzte Zeile dort START_DAEMON=yes lauten.
Da fügst du eine Zeile drunter ein

OPTIONS=-vv

Anschliessend fetschmail neu starten und sich das log anschauen.
Achtung. Es wird viel geloggt, also wieder rausnehmen nachdem ein Versuch fehlgeschlagen ist.
Achtung. Wenn ich recht erinnere wird das Passwort bzw. der Hash im Klartext mitgeloggt.

gruss,
sky

 

[honk013]

Hi,
bei mir gibt es kein "/etc/default/fetchmail". Bei mir gibt es noch nicht einmal "/etc/default".
Meinst Du vielleicht die "fetchmailrc"?

 

[honk013]

Hab' sie gefunden. Danke. Ich schaue mir das jetzt mal an.

 

[honk013]

Jetzt steht etwas mehr drin (womit ich nichts anfangen kann)!

fetchmail: starting fetchmail 6.3.26 daemon
fetchmail: 6.3.26 querying sv35.domainunion.de (protocol POP3) at Mo 09 Sep 2019 17:49:36 CEST: poll started
fetchmail: Trying to connect to 172.17.0.2/995...connection failed.
fetchmail: connection to sv35.domainunion.de:995 [172.17.0.2/995] failed: Connection refused.
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: 6.3.26 querying sv35.domainunion.de (protocol POP3) at Mo 09 Sep 2019 17:49:36 CEST: poll completed
fetchmail: Merged UID list from sv35.domainunion.de: <empty>
fetchmail: Query status=2 (SOCKET)

 

[Andy+]

Dann teste mal statt Port 995 die Port-Nr. 110 ohne Sicherheit. Oder mal IMAP Protokoll mit Port 993 oder ggf. dann 143.

 

[honk013]

Moin Andy,
Port 110 mit POP3 funktioniert nicht (schon getestet). Da gibt es einen Authorisierungsfehler.

Ich denke gerade über eine andere Möglichkeit nach. UnInstall Kopano komplett mit anschließender Neuinstallation (leere Datenbank etc., alles neu). Dann neue Verbindung zu Outlook herstellen und in Outlook die gesicherte pst-Datei wieder importieren. Die wird wieder mit Kopano gesynct und alles müsste wieder da sein und jungfräulich; oder?

 

[Andy+]

Im Grunde ja, so habe ich das ja gemacht. Allerdings scheinen mir Anbindungsfehler bezüglich den Fetchmailkonten unabhängig hiervon. Jedoch, wenn Du eine Datenbanksicherung hast, kannst Du alles runternehmen, komplett neu installieren, Datenbank zurücksichern, dann sollte das auch laufen. Oder die Schiene mit Outlook. Am besten testen.