Kopano4S (Zarafa 2.0)

[leppy0815]

Hallo Leute,
ich habe immer noch die Version 0.9.0 laufen.
Kann ich einfach über das Paketzentrum da Update machen und alles ist gut oder muss ich besondere Schritte einhalten und wenn ja welche??

Gruß

Daniel

 

[Andy+]

Ich habe im Forum schon gelesen, dass das funktioniert hat, aber ich würde mich nicht darauf verlassen, insbesondere auch nicht, dass dann alles geupdated wird. Es gab in der Vergangenheit immer wieder inhaltliche Differenzen zwischen Updates und Neuinstallationen. Ob das noch immer gilt, kann ich nun nicht sagen. Für eine Neuinstallation spricht im Zusammenhang, weil mit der v1.0.0 eine Umstellung in der Verzeichnisstruktur der Installation stattgefunden hat. Ob die vom Update so 1:1 eingerichtet wird, wäre für mich zumindest fraglich.

Daher meine Empfehlung: Alles sichern und sich auf eine Neuinstallation einstellen, sofern ein Update danebengeht. Oder gleich neu installieren unter Beibehaltung der Datenbank, alles andere löschen lassen. Und ich bete es immer wieder:

1. Deinstallation
2. Reboot der DS
3. Installation des aktuellen SPK´s
4. Anlegen der abzurufenden Mailkonten
5. Reboot der DS
6. ggf. Fertigstellung

Sofern der WebAdmin nicht geöffnet werden kann, dann Punkt 5 mit 4 tauschen und einen 3. Reboot machen danach, das hat sich trotz den Konsolenbefehlen als am besten erwiesen für das ganze System. Für den Punkt 4 hier habe ich bereits fertige Scripts, da ich in aller Regel noch immer neu installiere, dann geht das Ganze innerhalb rund 20 Minuten über die Bühne und läuft in aller Regel auch gleich wieder.

Da Du die v0.9.0 hast, empfehle ich Dir sogleich die Defaultinstallation mit dem Image "D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5" mit dem SPK mit der derzeitigen v1.0.6, da v0.9.0 noch mit Core 8.6x.x laufen sollte. Dann hast Du gleich die Stable und nicht die Beta.

 

[491810]

Kann mir noch jemand wegen meiner Einbindung von IMAP helfen???

 

[Andy+]

Was meinst Du damit? IMAP geht per Default schon.

 

[491810]

Naja. Ich bekomme keine Verbindung via IMAP SSL. Zertifikat hatte ich eingebunden. Auch nicht aus dem lokalen Netzt. Account hat auch Rechte für IMAP.

 

[Andy+]

Hi F@H und Alle
Kopano hat mit der COre 8.7.x wieder AÄnderungen an den Config-Files durch geführt und das nicht im Hadnbuch hier https://documentation.kopano.io/kopanocore_administrator_manual/configure_kc_components.html#configure-kopano-gateway-imap-and-pop3 Nachgezogen: imaps_enable, imaps_port wurden Ersetzt durch: imaps_listen = *:993 (analog. für icals, pop3s) . Ich hatte auch meinen Spass, weil die Services wegen unknown parameter nicht starten und die Änderung aus den neusten cfg-examples herausgelesen.
Bei der Gelegentheit habe ich nochmals die ssl Funktion (>kopanoas-init ssl) Überarbeitet in k4s v.1.0.3 und nun Funktionieren die Core Services incl. Outlook Client auf 237 ebenso wie Gateway, Ical auf SSl. Als Zertifikat wird das Default Zertifikat der Synology importiert. Wenn man z.B. den "Alternate Name" mail.mydomain.de, oder kopano.mydomain.de hat, dann wird Dieser passen verwendet zum (Dyn)DNS-Eintrag.
-TosoBoso

Entweder diese Lösung, ansonsten ggf. in der

/etc/kopano/gateway.cfg

und das # wegnehmen bei

#imaps_enable = no
#imaps_port = 993

und imaps_enable = yes setzen

 

[Andy+]

Zunächst habe ich auf meiner einen Test-DS415+ v1.0.7B installiert und seit C-Core-8.7.82, jetzt C-Core-8.7.85, lässt sich die WebAPP nicht starten. Ich habe nun die Installation auf meiner anderen Test-DS412+ wiederholt mit dem gleichen Ergebnis. Container läuft, Paket läuft, WebADMIN läuft, WebAPP nicht. Was ist zu tun?

 

[Andy+]

Da ich Produktiv die Default einsetze und immer mit dem SPK manuell installiere, lasse ich im Paketzentrum die Einstellung auf BETA und kann daher trotzdem Beta-Software installieren. Ich habe festgestellt, obwohl für das derzeitige Default-Image das SPK v1.0.6 aktuell ist, wird mir im Paketzentrum die v1.0.7 Beta zum Update angeboten. Natürlich geht das, aber ein Update von Default auf Community sollte nicht so einfach möglich sein, denn Unwissende gehen auf Aktualisieren und haben damit auch die Datenbank auf Beta-Niveau angehoben und ärgern sich hinterher und müssen ggf. warten, bis die künftige Default die aktuelle Beta in der Versionierung überholt hat. Erst dann könnte wieder auf die Default gegangen werden.

Nur mal als Hinweis ....

 

[dafri]

@Andi+: Du tust gut daran nicht immer die neueste Version zu installieren. Ich bin einer der unbedarften, der schnell mal der Aufforderung zur Aktualisierung folgt, auch wenn dabei eine beta installiert wird.
Mit folgendem Effekt: seit Installation v 1.0.7 habe ich hyperaktive Festplatten und ein immer zäher werdendes System bis zur Lähmung der Weboberfläche. Auch ein Telnetzugang erfolgt nur in Zeitlupe - zwischen den Eingaben und dem Kommandozeilenprompt vergehen ein bis zwei Minuten. Das einzige was derzeit hilft ist Neustart. Zwischenzeitlich habe ich alle mir bekannten Indizierungsdienste ausgeschaltet, nicht benötigte Pakete angehalten.
Letztendlich zeigte sich dann im Ressourcen-Monitor bei den Diensten logrotate mit einer hohen Speicherauslastung (137 MB) und hohen CPU Auslastung.
Die Frage ins Forum: wie sollte ich vorgehen? Gibt es logs die ein DOS Nutzer (Linux Anfänger) einsehen kann, welche weiterhelfen? Kann ich ein roll-back auf die frühere Version machen? Sollte ich neu installieren? Ist mein Problem anderen Nutzern auch aufgefallen?

 

[dafri]

Update:
Ich habe mittlerweile den Arbeitsspeicher von 1 GB auf 4 GB erhöht. Seitdem ist das System, wenn kopano läuft, nicht mehr mit I/O Warten zu 80% beschäftigt.





Auch haben sich dadurch die swaps im Arbeitsspeicher auf fast null senken lassen

.



Auffällig ist jedoch weiterhin eine sehr hohe Speicheranforderung von logrotate in drei Instanzen mit jeweils ca 120 MB.
Auch die CPU Auslastung scheint täglich um 07:00 um 20% zuzunehmen.





Stoppe ich kopano4s ist der Spuk vorbei. Kein logrotate, keine CPU Ausnutzung.





Starte ich kopano4s erneut, dauert es knapp drei Tage und das System ist wieder ausgelastet.
Ich habe gehört, daß man den Neustart mit cronjob automatisieren kann. Leider bin ich in Linux unterbelichtet. Kann mir jemand hierzu helfen?

 

[Andy+]

Du kannst K4S über Konsolenbefehle starten und stoppen, oder in der Folge auch einen Neustart durchführen. Das kannst Du aber auch im Aufgabenplaner in der Systemsteuerung hinterlegen, dann sind nicht die komplizierteren crontab Einträge erforderlich:

Start
/var/packages/Kopano4s/scripts/start-stop-status start

Stop
/var/packages/Kopano4s/scripts/start-stop-status stop

Neustart
/var/packages/Kopano4s/scripts/start-stop-status stop && sleep 3 && /var/packages/Kopano4s/scripts/start-stop-status start

Ist natürlich etwas ungewöhnlich bei Dir mit der Auslastung. Welches Dateisystem hast Du, BRTFS oder EXT4?

 

[dafri]

Ich habe ext4 auf allen volumes.
Danke für das Skript! Ich habe das in den Aufgabenplaner kopiert. Mal sehen, ob das klappt. Wäre auf jeden Fall eine einfache Lösung.
Das sleep 3 bedeutet wohl, daß 3 Sekunden gewartet werden oder? Bedeutet das, daß nach dem stoppen von kopano noch 3 Sekunden gewartet wird, oder daß 3 Sekunden gewartet wird bevor der Neustart erfolgt?

 

[Andy+]

So gesehen beides, es ist eine extra Sequenz. Die Pause kann im Grunde auch weggelassen werden, ich finde das so eben etwas eleganter ...

EXT4 ist gut wegen der Datenbank. Wenn die Auslastung immer weiter ansteigt, ist die Frage, was da passiert. Ist es nur K4S? Ggf. wird die Datenbank aufgeräumt? Hast Du ein Monitoringtool?

 

[FricklerAtHome]

Kopano Server mit Versionssprung auf 9.0.1

Hallo Kopano'ies

Im Community-Bereich ist der Kopano-Server auf die Version 9.0.1.4 umgezogen. Zumindest mit den Basis-Optionen, Core und WebApp. Läuft bei mir stabil, eine Änaderung an der Datenbank zur Version 8.7.85 war nicht nötig.

Glück Auf und immer ein Licht bei der Nacht

der Frickler@Home

 

[dafri]

@Andi+
Es ist tatsächlich nur k4s. Wenn ich das Paket deaktiviere, ist logrotate nicht mehr mit 3 x 120 MB Speicher und ca 40% CPU Last aktiv. Aktiviere ich das Paket wieder läuft alles glatt, aber eben nach drei Tagen steigt die Auslastung. Meines Erachtens erst seit dem letzten Update. Momentan läuft bei mir auf einer DS412+ das DSM 6.2, K4S 1.07, Kopano4S C-Core-8.7.85, Webapp-3.5.12, Z-Push-2.5.1, WMeet-0.29.5. Zum Monitoring habe ich nur den Ressourcen Monitor.
@FricklerAtHome
Du meinst eventuell wäre die Version 9.0.1.4 eine schlaue Maßnahme?

 

[FricklerAtHome]

Bei mir ist logrotate ruhig, Kopano läuft allerdings in einer VM. Hier kann ich keine Unterschiede zwischen den Versionen feststellen. ich benutze jedoch kein WebMeeting.
Als Tip bleibt nur zu schauen was in den Logs passiert. Logrotate greift normalerweise nach Zeitraum oder Füllgrad des LOG. Ich hatte mal einen "ähnlich unerklärbares Verhalten". Letzlich war die DHCP Einbindung bei Debian 10 Buster schuld. Das sollte aber in K4S im Hafer (ist das die deutsche Übersetzung für Docker ;-)) nicht betreffen. Schau mal welche Logs am schnellsten wachsen. Der Versionssprung ist es eher nicht und müsste von Tososbos per SPK-Update angestossen werden. Sonst wird es noch unkontrollierter.

GLück Auf und immer ein Licht bei der Nacht
der Frickler@Home

 

[FricklerAtHome]

Hinweise für Kopano als Syno VM

Glück Auf Kopano'ies

ich bin persönlich und bei der betreuten Nachbarschaft (wie immer bei mir in einer VM) auf Debian Buster (10) und wie bereits verbreitet nun auf Kopano 9.01 (Community). Das läuft. Wir haben uns aber ein par Schmankerl überlegt und umgesetzt. MariaDB und die Attachments (Ablage der Anhänge) sind nicht mehr in der VM. Die mariaDb läuft meistens auf einer anderen Linux-Server-Kiste und die Anhänge sind mittels NFS-Freigabe mit kopano als externem /Home auch ausgelagert. Hierdurch bleibt die VM stabil klein und bei einem Schwenk auf eine neue Version etablieren wir nur ein naktes System dem wir dann die entsprechenden Connects (Datenbank /Attachments) unterschieben.
Damit war gestern ein Wechsel von Debian 9 mit Kopano 8.73x zu Debian 10 mit Kopano 9.0.1x und 4 aktiven Benutzern (ca. 660 MB Datenbankvolumen ohne Anhänge) in 7 Minuten erledigt. Die Vorbereitungszeit gleiche Postfix/Kopano Basis Konfigs anzulegen war länger. Die Anwender hatten real jedoch nur 3 Minuten "Disconnect".
Da die meisten der betreuten Nachbarschaft mittlerweile fette Internetzugänge haben (wir sind glücklicherweise Kabelgebiet) erfolgt die Bereitstellung der "nackten" VM mittels Nextcloud oder VPN (Größe ca 1,8 GB bis max 2,63 GB) ohne Probleme. Diese VM ist primär mit einer variablen IP Adresse in deren Netze eingebunden. Es wird kurz alles an das entsprechende Homenetz angepasst (lokal // mit Bier // oder per VPN // ohne Anerkennung) , während die alte Version seelenruhig auf der gewohnten IP weiterläuft. Ist alles (vor allen Kopano Datenbank und bei uns Postfix per DB für User) in der neuen Maschine eingestellt, wird die alte Maschine ausgestellt und mittels DHCP die neue Maschine mit der IP der alten gestartet. -- Braucht einige Minuten, aber in danach läuft es für Outlook, Handy, DeskApp ohne weitere Probleme. Man kann das auch per KOPANO-BACKUP regeln, brauchen wir aber nicht. Keine Neuanmeldung, keine neuen Passwörter etc. --- Zumindest unsere Erfahrung.

Immer ein Licht bei der Nacht
der Frickler@Home

 

[FricklerAtHome]

Geiles UTF-8 Problem

 

[hnies]

Ich habe ein Problem mit logrotate gefunden, in /etc/logrotade.d steht die Datei mail. Hier sind die Logs mit "mail.*" angegeben. Dies ermöglicht logrotate eine rekursive Schleife im die Unendlichkeit und er packt und packt.
Ändern von mail.* nach mail.log und ergänzen für mail.err , mail.info.

Danach entweder das ..\log komplett removen oder Stück für Stück die 1000ende Dateien löschen.

Probleme mit Hoher Last durch Logrotate:

Auf der Syn:

/var/log/kopano:

for i in *.gz ; do rm $i ; done

In der Docker Console:

cd /etc/logrotade.d

Datei mail

Hier ist ein * drin, der verursacht recursive rotates …..

Ersetzen mit mail.log, warn, info und err
Vi mail.warn

 

[NoFear-MK]

Kopano4S Backup

Moin Gemeinde,
habe seit ein paar Tagen einer Fehlermeldung im Backup Log, ich sichere per Aufgabenplaner mittels script : "kopano4s-backup"

mysqldump: Got errno 32 on write mysqldump: Got errno 32 on write dump for kopano completed in 5 : 46 min:sec

Auf meinem Zweit-NAS läßt sich das Backup so nicht zurücklesen ....

Kennt jemand die Ursache und die Behebung ?

Gruss,
MAX

P.S. Kopano4S Community-8.7.80_Web-3.5.1_Push-2.4.5_Meet-0.29.5_Mmost-5.6.1_Files-2.1.5_Docs-5.4 installed!