KOPANO-VM als ZARAFA-Ersatz

[Andy+]

........deine Nutzung ist die in Kopano per WebApp mögliche Integration von OwnCloud vielleicht ein bisher vermisstes Gimmik.........

ownCloud ja, aber DAV ist deutlich schneller und das habe ich jetzt schon. Hinterlegung mit Netzwerk-IP, Port 5005, Benutzer, Passwort, das wars, das habe ich in Z4H aber schon länger. ownCloud ist dagegen zu träge, sicherlich auch eine charmante Lösung.

 

[FricklerAtHome]

Für Leute mit Muße oder halt "Frickler"

Nur mal kurz mein aktueller Stand:

Ich habe eigentlich mit der Univention / Kopano Kombi gute Erfahrungen gemacht. Zumindest wenn man schnell und ohne größere Kenntnisse ( zum Beispiel nach einem Hardwareausfall etc. ) die Benutzer wieder bedienen muss.
Persönlich habe ich mich aber wieder davon verabschiedet und bin den Weg des Fricklers gegangen.

Aktuell läuft bei mir in einer Debian 9.3 VM, Kopano 8.6.80, Z-PUSH 2.4.0 und die WebApp 3.4.7 auf meiner Synokiste mit 8 GB RAM und BRTFS. Zwischen meiner parralellen Z4H Installation fallen nur wenige Unterschiede auf, Performance etc. sind gleichwertig. Der VM sind 3 GB RAM zugeordnet.
Die Installation von Hand dauerte und erforderte auch einige interne Kenntnisse, das Snapshot System für VM's unter BRTFS macht aber Entwicklung bzw. die Sammlung eigener und tieferer Installationserfahrungen sehr Risiskoarm. ---- Aktuell laufen beide Systeme superstabil produktiv. Ich teste gerade die Import / Exportfunktionen des VM-Managers. Wenn das gut geht, habe ich eine weitere Alternative.

Gruss der FricklerAtHome

PS.: Ich bin von Univention weg, weil es mir zu oft nach Hause angerufen hat. Es waren vor allem App-Center und Update-Center Anfragen. Fand ich einfach blöd.

 

[Andy+]

Ich habe auch mit den beiden Distris experimentiert. Ich habe immer 4 CPU´s und 4 GB RAM berücksichtigt, damit läuft es bei mir am besten.

An Univention 4.2 VM stört mich das träge Verhalten, die nicht mehr ganz aktuellen Kopano-Apps und die Benutzerverknüpfung mit der Datenbank. Meine Datenbank aus Z4H als Backup rübernehmen und als Restore wieder einbinden hat nicht geklappt. Das und noch so ein paar Dinge haben mich davon abkommen lassen. Ein netter Versuch von Univention, sowas wie ein DSM zu machen, ist aber nicht so das Wahre, finde ich.

Mit Debian 9.3 VM habe ich da weit bessere Erfahrungen gemacht. Es bootet schnell, ist schnell und das neuste Kopano läuft auch mit dem Datenbankbackup von Z4H. Was zB. Probleme macht, sind die Plugins, die sich nicht dauerhaft einbinden lassen, wenn vom Standard abweichend, die fehlenden aktiviert werden. Habe ich welche angewählt und speichere das und aktualisiere das WebAPP, sind die Haken an den entsprechenden Positionen wieder weg. Ich muss dann über WinSCP in das Plugin-Verzeichnis und in den einzelnen Dateien von "false" auf "true" ändern, dann sind die betreffenden auch aktiv. Ich will nicht ausschliessen, dass das alles mit der Datenbank von Z4H zu tun hat, die ggf. im Detail anders ist.

Davon abgesehen fehlt mir aber auch das KnowHow, das Sytem durchgängig zu machen, also Mailversand und -empfang einzurichten. Insofern wär mal gut, eine Step-by-Step-Anleitung zu haben.

 

[FricklerAtHome]

Anleitung und Step by Step wird es von mir hierzu nicht geben. War für mich eher so ein Proof of Conzept, das nun rund läuft.
Das System ist aber vollständig und autark! Das bedeutet eigene Zertifikate mit openssl, rein virtuelle Kopano-User, Mail-Versand und Empfang via fetchmail, postfix, postgrey, amavisd-new ( Anitvir und Spamassassin ), Kopano mit ActiveSync, IMAP, POP3, ical (jeweils auch in der verschlüsselten ssl-Variante), alle wesentlichen WebApp-Plugin's installiert und getestet (aber nicht alle in Nutzung: aktuell frickel ich an der Anbindung meiner Fritzbox an das Fax-Plugin, meine Frau und Kinder lieben aber die WhatsApp Integration).
Wenn man die Installationsmechanismen aus den Community "Nightly-Builds" erst einmal trainiert und verinnerlicht hat, funktionieren Updates aller Kopano-Komponenten weitgehend störungsfrei. Die Z-Push Komponente wird sogar über den Debian Installer apt-get aktuell gehalten. Die wesentlich "fricklere" Arbeit ist das Basis-Mail System soweit lauffähig zu bekommen wie man es sich selbst und seinen Sicherheitsansprüchen schuldet. Kopano dann für empfangene Mails einzuschleifenund den Versand wieder an das Basis-Mail System zu übergeben ist die leichtere Aufgabe. Ich habe zum Beispiel (wegen eigener Dummheit bzw. einem Verständnis-Fehler) fast einen Woche gebraucht um Fehler mit automatischen BCC-Regeln zu beheben.

--- Alles im Allem: Das ist für euch hier im Forum nur der Hinweis: "Es geht, auch von Hand". Es hat aber typisch für OpenSource weitgehend keine graphische Admin-Oberfläche. Ist es, wie in meinem Fall für überschaubare Anwenderzahlen aber konfiguriert, wird der Aufwand zur Pflege immer geringer bzw. aufwandsfreier.

Gruss Der FricklerAtHome

PS.: In meiner Syno läuft die VM nur auf einem Kern, hat 3 GB Ram und liegt nicht auf einer SSD, sondern in einem ganz normalen RAID Volumen mit BRTFS. In der VM wird ein Ext4 Filesystem genutzt. In der Performance ist das nicht schlechter wie Z4H auf der baugleichen zweiten Syno.

 

[Andy+]

Für sowas fehlt mir einfach die Zeit. So gesehen haben wir es mit den SPK´s von Tosoboso schon gut. Ich werde daher weiterhin rumexperimentieren, aber produktiv bleibe ich ohnehin bei Z4H, zumal funktional und oberflächlich keine Unterschiede da sind.

 

[FricklerAtHome]

Ich betreibe das ganze nur als Hobby! Maximal 1 bis 2 Stunden pro Tag und auch nicht an jedem Tag der Woche.
Beruflich bin und komme ich aus einer ganz anderen Branche, als der EDV. Aber ich bin auch durch die IHK zugelassen als Ausbilder für "Fachinformatiker - Systemintegration".
Für mich sind das quasi "Entspannungen" vom Tagesgeschäft.

Gruss der FricklerAtHome

 

[Andy+]

Dann ist es ja ganz ähnlich. Und die Entspannung ist eigentlich die spannende Geschichte dahinter ....

 

[Online78]

Hallo zusammen,

im Beitrag #61 wurde aufgezeigt, wie einzelne User aus Zarafa zu Kopano migriert werden können. Bei mir hat dies ausser mit einer Zarafa4H installation auch gut funktioniert. Diese Installation hat eine grosse DB von über 10 GB. Ursprünglich habe ich bei der univention vm 10GB speicher zugewiesen und später auf 50 erhöht. Beim holen der Daten von Zarafa gibt es immer den Fehler, dass nicht genügend speicherplatz verfügbar ist. Sprich, wenn die 10GB grenze erreicht ist, ist schluss - obwohl ich später ja 50GB zugewiesen habe.

kennt jemand eine möglichkeit dies zu korrigieren, oder die User auf einem anderen weg zu übernehmen?
danke für Eure Hilfestellung.
Domi

 

[fbartels]

Ursprünglich habe ich bei der univention vm 10GB speicher zugewiesen und später auf 50 erhöht

Wurde nur die Festplatte auf der Syno vergrößert oder auch das Dateisystem/die Partition in der VM? Klingt so als wenn Univention nach wie vor nur die 10GB kennt.

 

[FricklerAtHome]

Ich habe den gleichen Vertacht wie Felix B. Bei mir wird die VMM immer und primär mit mehr als 50 GB erstellt, schadet ja in der Regel nicht da es entsprechend der wahren Nutzung mitwächst.
Ich konnte mit dem wirklich tollen Script auch Benutzerkonten jenseits der 25 GB zb. aus zarafa in kopano importieren.
Bei mir ist das aktuell das High-Light in der betreuten Nachbarschaft! -- Das liegt vor allem an der MAPI Systematik. Das Kopano speichert Anhänge im Filesystem, viele der alten ZARA's in der Datenbank. Mit dem Script geht der Wechsel nach meinen Erfahrungen sehr geschmeidig, ich brauche keine weiteren Hilfen in der Migration. Und das Problem der unterschiedlichen "Ablagen" spielt in einer VM keine Rolle.

Gruss der FricklerAtHome

 

[Online78]

Hallo Zusammen, möchte euch noch ein Update geben. Es hat nun funktioniert, jedoch habe ich eine neue VM erstellt mit gleich 100GB. Damit konnte ich ohne Probleme den Import der Daten über kopano-backup script machen.

Was mich aber wundert ist, dass eine erweiterung des Speicherplatz anscheinend nicht erkannt wird. Ich habe nähmlich den VM-Storage korrekt erweitert. Also ja, ich habe in der VM das Dateisystem/die Partition erweitert. Univiention erkannte trotzem nur 10GB. Neu Start hat auch nichts geändert. Dies ist aus meiner Sicht sehr schade, denn es schränkt die Handlungsfreiheit für spätere Anpassungen ein.

Nun denn, mit 100GB zuweisung habe ich entsprechende Reserve, danke für Eure Hilfe.

Im Übrigen bin ich mit Kopano auf Univention total zufrieden. Dies vor allem, weil ich mit Thunderbird und dem Addon TbSync ein MailClient anbinden und alles syncen kann: Mail, Kalender, Adressbuch, Aufgaben. Dies funktioniert mit Zarafa4H nicht. Zudem ist das "basteln" bzw Einrichten mit einer VM viel Stressfreier.

@ FricklerAtHome: warum machst du kein Tutorial bezüglich Debian? Fänden sicherlich viele toll, denn es ist bekannt, sehr gut supported und würde vermutlich einige dazu bringen, sich für diese Alternative zu entscheiden.

herzlichen Dank für alle Hilfe
Dominique

 

[Andy+]

So ein Tutorial wäre mal ganz gut. Ich habe zwar keine Motivation von Z4H auf Kopano zu wechseln, insbesondere in einer extra VMM, aber um das mal vollständig ans rennen zu bringen und als mögliche Alternative, weshalb nicht? Nur Kopano in dieser VMM laufen zu lassen ist halt auch eine Recoursenfrage und damit das performant läuft kann man ja auch keine Sparflamme einrichten und das Ganze geht dann zu Lasten von allem anderen, da man sich schon im Klaren sein muss, dass man zwei Linuxserver am Start hat.

 

[FricklerAtHome]

Hallo am Samstag

es gibt zahlreiche Anleitungen zur Installation von Kopano auf Debian im Netz. Sucht mal nach "Kopano Debian Installation".
Ich habe mich auch immer wieder bei solchen Quellen inspirieren lassen. Trotzdem wir da jeder seine eigenen Erfahrungen machen müssen.
Das schöne an der VM sind die Snapshots. Immer bevor ich etwas neu installiert oder umkonfiguriert habe, gab es einen Snapshot. War es eine Sackgasse, wurde einfach auf den alten Stand zurückgesprungen.
Damit ging es komfortabel. Nehmt euch vor allem Zeit, und schaut euch bei Fehlern die LOG-Files an.
Hilfe und Rat bei konkreten Problemen gerne, ein Tutorial --- nein!

Beste Grüße Der FricklerAtHome

 

[Online78]

Konkrete Frage zu Kopano auf Univention.

Ich versuche folgendes szenario:
- Email Account von virtueller Domain auf Kopano, welche mit Email des Providers übereinstimmt.

Bsp:
Henry@provider.ch

virtuelle Domain auf Kopano:
- provider.ch

Versenden über postfix geht wenn ich mit dieser Anleitung Postfix einrichte und unter Configurtation Registry mail/postfix/virtual/enabled auf false setze. Alle Mails werden dann über den eingerichteten relay gesendet.

wenn ich fetchmail einrichte werden die Mails beim Provider heruntergeladen, jedoch nicht in den Posteingang von Henry@provider.de gelegt.

Gibt es hierzu eine Lösung bzw ein Hinweis, wie ich dies bewerkstelligen kann?
Danke

 

[FricklerAtHome]

Wenn ich das richtig verstehe holt dein Fetchmail Post für den User Henry@provider.ch ab. Dein Kopano ist das HOME für die Domäne provider.ch. Ob die Post ankommt suchst du aber im Postfach henry@provider.de .
Dieses Postfach gibt es aber in der "schweizer" Domäne sicher nicht. In Fetchmail müsste das so laufen: Hole von Provider mit Protokol pop3 für Benutzer xyz@provider."de" mit dem Passwort "egal" der hier xyz@provider."ch" ist.
Wenn du Post aus der schweizer Domäne in der deutschen Domäne sehen willst, musst deine virtuelle Domäne aber "provider.de" heissen.
Damit das mit den virtuellen Postfächern und Domänen klappt muss ../virtual/enable aber auf true bleiben. Es sei denn du hast einen realen Benutzer Henry in der LDAP Domäne und auf dem Univention Server eingerichtet. Ansonsten fuktioniert da im weiteren vieles nicht.
Da ich kein Univention mehr habe, kann ich hier auch nicht weiter helfen. Es gibt aber ein super Forum mit Hilfen zu Kopano auf Univention. Dort ließt / hilft der liebe Felix B. direkt den Ratsuchenden.

Schönen Abend (ich habe jetzt einen Job in der "Betreuten Nachbarschaft": Hyperbackup läuft aus dem Ruder! --- Es gibt kühles Gerstenbräu, wird also nicht so schlimm!)

Der FricklerAtHome

 

[Online78]

Werter FricklerAtHome,

leider hast du es nicht richtig verstanden bzw ich habe es sehr schlecht erklärt. Es geht mir darum, dass ich auf Kopano ein Account mit identischer Mail habe und über fetchmail bzw relayhost die Mails vom Provider abhole und über den Provider versende.

Bsp:
- Mail Provider: henry@provider.de
- Account Kopano: henry@provider.de

eigentlich ist es ja egal wie, identisch sollte es sein.
Grüsse Domi

 

[FricklerAtHome]

Hallo online78

also so wie es jetzt erklärt ist sollte es eigendlich funktionieren. Hast du für den Benutzer in Univention auch die entsprechenden E-Mail Dienste aktiviert, eine Adresse vergeben. Ansonsten ist zwar der Benutzer für Univention berechtigt aber noch nicht für Kopano und das MailSystem. Da kommt dann auch nichts an. Das wäre jetzt der wahrscheinlichste Fehler der mir einfällt.

Beste Grüße Der FricklerAtHome

 

[Online78]

Nun, ich habe alle Benutzer in Univention erstellt sowie im Kopano Bereich die Einstellungen gemacht. Bei anderen VM's hat die Einstellung der Benutzer entsprechend funktioniert. Im Gesamten jedoch mit einer anderen Strategie. Wüsste nicht, was ich ändern müsste.

Fest steht, ist das mit der selben VM, folgendes Tatsache ist:

Fetchmail stellt Mails nur User zu, deren Mail anders lautet als jene vom Download, sprich:
- Mails vom account: Henry@provider.de können nicht an
- Henry@provider.de auf der virtual domain in Kopano weitergeleitet werden, jedoch an
- Henry@kopano.net.

Vielleicht hilft diese Info?
Gruss Domi

 

[FricklerAtHome]

Hallo Domi

das Problem liegt nicht an Fetchmail. Fetchmail holt alles und für jeden ab und übergibt es an den MTA in diesem Fall POSTFIX. Es selbst prüft dabei gar nichts. Ich nutze fetchmail seit Jahren um Mails von einem Provider an einen anderen E-Mail-User weiterzuleiten.
Hier scheint deine Postfix-Konfiguration zu klemmen. Scheinbar nimmt sie keine Mails für die Domäne "@provider.de" an.

Irgendwo in der Postfix main.cf muss ein Eintrag existieren:

mydomain = provider.de

weiter danach müssen die virtuellen Domänen definiert werden:

virtual_mailbox_domains = provider.de, provider.net (usw.)

Hier muss auch die erste Domain enthalten sein. Mit den Einträgen:

virtual_alias_maps = hash:/etc/postfix/virtual_alias (die mit postmap erzeugte db aus der Datei /etc/virtual_alias)
virtual_mailbox_maps = mysql:/etc/postfix/sqluser.cf (abfrage der User aus einer Mysql Datenbank) (diese Eintrag kann bei Univention wegen der LDAP einbindung auch anders aussehen)

sollte es dann funktionieren. Das tut es zumindest bei mir. Ich tippe dringend auf eine Fehlkonfiguration von Postfix.

Beste Grüße Der FricklerAtHome

 

[FricklerAtHome]

Hallo Domi

hast du mal eine der von dir genutzten Fetchmailrc Datei. Mach die anonym. Die fetchmail Syntax ist manchmal tricky und könnte auch eine Ursache sein.

das müsste so ausshen:

poll pop.provider.de protocol pop3 port 995 user 'henry@provider.de' pass 'henry-passwort' is 'henry@provider.de' here keep #UID henry

zumindest für Pop3.

mit: tail -f /var/log/mail.log
in einem Terminal kannst du was im Mail-System passiert in Echtzeit mitlesen. Damit habe ich bereits häufig Fehler gefunden.

Gruss der FricklerATHome