KOPANO-VM als ZARAFA-Ersatz

[catweazle71]

@catweazel71

Ich arbeite in DO und wohne in GE, komme aus WAT. Also ein Pendler im Pott. In der einen Sache wo die Ruhrie's keinen Spass kennen (dem Fussball) bin ich also Betroffener. Morgens darf ich nicht sagen wo ich hinfahr, auf der Arbeit nicht wo ich herkomme.
Ich pendel also zwischen Nirgendwo und Unbekannt. ;-))))
Der FricklerAtHome

Ich lach mich schlapp ))
Ich hab zwar nie in GE gewohnt, und ich bin auch nicht gerade ein Fußball-Fan, aber wenn, dann schlägt mein Herz auch für schwarz-gelb ;-)

Wow, was Du da mit Deinen Syno's hochgezogen hast, lässt einen erblassen. Es lässt auch zumindest vermuten, dass IT- bzw. Information Security für Dich keine unbeschriebenen Blätter sind. Machst Du da auch was beruflich? Bei mir ist das nämlich tatsächlich so.
Leider habe ich nur eine einzige DS, die 415+, inoffiziell hochgerüstet auf 8GB Ram. Das war es auch schon. Klar könnte man da 4GB an die VM abgeben und es sollte gut laufen.

Bzgl. Deiner Sicherheitsbedenken hast Du natürlich in allen Punkten Recht. Aber man sollte dennoch zugestehen, dass ein gutes Passwort immer noch Schutz genug bietet, vorausgesetzt:
- die Krypto-Implementierungen sind nicht abgreifbar (dann hättest Du aber auch ein Problem)
- man selbst ist nicht das Opfer eines gezielten Angriffs durch einen Täter, der schoon einige Ressourcen aufbringen können muss

Meine wichtigen Passwörter sind immer (pseudo-)zufallsgeneriert und zwischen 12 und 16 Zeichen lang. Das halte ich dann doch für ausreichend bzw. lebe einfach mit dem Restrisiko.

 

[FricklerAtHome]

Also ich bin sicher "profinaher" Autodidakt. Wie schon mal genannt, darf ich sogar Fachinformatiker Systemintegration ausbilden. Ich komme und arbeite aber in einer ganz anderen Branche. Da ich teilweise freiberuflich unterwegs bin und deutlich schützungwürdige Daten verarbeite / benutze muss ich gesetzliche oder auch höhere Anforderungen an meine System stellen. Die Nachbarn nehmen dies gerne mit, sie merken es ja nicht!
Da wo ich arbeite, kümmern sich Profis um alles. Da ist es Exchange und nicht ZARA / KOPA. Für meinen privaten Bereich versuche ich aber zumindest gleiche beruflichen Anforderungen zu erfüllen, ohne in Lizenzfallen zu laufen.
Ich kenne also meine Anforderungen und "frickel" halt so lange bis es mit freier Software genau so gut und genau so sicher geht!

Andy+ fordert immer wieder nach einer Back-Anleitung für eine "reibungslose" Imitation meiner Lösung. Die Lösung ZARAFA / KOPANO in einer VM auf einer SYNO ist aber extrem Vielschichtig. 90% der Instalation hat nichst mit unserer Zara/Kopa zu tun. 100% aller notwendigen Schritte sind in den entsprechenden Detail-Foren für freie Software beschrieben. So habe ich meine Lösung gefunden. Wenn die nicht passten, teilweise "Try and Error", frickelnd halt.Tutorials gibt es reichlich und müssen hier nicht wiederholt werden.
Auf diesem Weg lernt man sehr viel mehr als als Konsument eines SPK. Das ist für mich wichtig. Wer also höhere Anforderungen an ZARAFA / KOPANO auf den Synokisten stellt als angeboten, der muss sich selbst bewegen. Das Angebot durch Z4H kann und wird sicher den meisten genügen.

Beste Grüße
der FricklerAtHome

 

[Andy+]

Ich fordere nichts und wie gesagt, Dein/Euer Weg ist Dein/Euer geistiges Eigentum.

Erlaube allerdings die Bemerkung, weshalb wir das Forum dann nicht schliessen. Es steht alles irgendwo, auch das, was ich hier zum Thema als Konzentrat beigetragen habe. Jetzt jedenfalls, verstehe ich, weshalb sich das so verhält. Danke für Deine Offenheit und immer wieder kompetente Hilfe.

 

[Andy+]

P. S. und weil es mir persönlich zu dumm war, immer wieder dasselbe zu schreiben, gibt es seither lauter solche "Konzentrate" auf meiner Homepage. Und das nicht ohne Eigennutz.... .... ich brauche das selber immer wieder.

 

[Andy+]

Wenn ich mit der aktuellen Version von Kopano experimentiere und möchte die Datenbank aus Zarafa4h importieren, kommt beim Start des Service eine Fehlermeldung

"Unable to Upgrade database from version 7.2.6.10.64 to version 8.6.80.0.70"

Wie kann das nun konvertiert werden?

 

[FricklerAtHome]

Der Weg über ein einfaches MySql Backup geht wie innerhalb der ZARAFA Versionen nach KOPANO nicht.

Der beste Weg ist im Beitrag von fbartels (#61 in diesem Thread) beschrieben: Kopano-backup! Funktioniert extrem schnell und sicher! Es trennt auch Anhänge aus der Datenbank in das Filesystem.

Gruss der FricklerAtHome

 

[Online78]

Lieber FricklerAThome, liebe Community

ich habe noch immer das selbe Problem wie in # 113 beschrieben und bin leider nicht weiter gekommen. Wäre froh um Hilfe.

Danke für Eure Hilfe, Online78

 

[FricklerAtHome]

Hallo Online78

scheinbar ist da immer noch ein Bug in deiner main.cf von Postfix. Nach deinen bisherigen Angaben kann ich noch nicht helfen. Hast du mit postmap alle aufzurufende Dateien als .db vorliegen? Also zum Beispiel die Datei Alias auch als alias.db?
Wo definierst du eigendlich deine realen User? Ich lasse Postfix mittels sql-plugin direkt auf die Kopano-Benutzer zugreifen.
Mach mal einen Screen-Shot vom Verzeichnis /etc/postfix (Ansicht im MC reicht). Hilfreich wäre auch eine main.cf (da müssen dann deine persönlichen Inhalte neutralisiert werden).
Vielleicht komm ich dann dahinter wo es haken könnte.

Grüsse DF@H

 

[Online78]

Lieber FricklerAThome

Versuche mal deine Fragen zu beantworten.
1. Definieren der realen User. Bin nicht sicher was du meinst. In Univention lege ich die User in Kopano fest. Dort habe ich auch alle Angaben für fetchmail eingetragen.

2. screenshot von /etc/postfix/:


3. Hast du mit postmap alle aufzurufenden Dateien als db vorliegen --> wir könnte ich das prüfen?

4. main.cf:
*******************************************************************************************

# Warning: This file is auto-generated and might be overwritten by
# univention-config-registry.
# Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
# univention-config-registry überschrieben werden.
# Bitte bearbeiten Sie an Stelle dessen die folgende Datei(en):
#
# /etc/univention/templates/files/etc/postfix/main.cf.d/10_general
# /etc/univention/templates/files/etc/postfix/main.cf.d/30_maps
# /etc/univention/templates/files/etc/postfix/main.cf.d/40_postscreen
# /etc/univention/templates/files/etc/postfix/main.cf.d/50_restrictions
# /etc/univention/templates/files/etc/postfix/main.cf.d/60_tls
# /etc/univention/templates/files/etc/postfix/main.cf.d/80_delivery
# /etc/univention/templates/files/etc/postfix/main.cf.d/99_local
#

# The message_size_limit parameter limits the total size in bytes of
# a message, including envelope information. Default is 10240000
message_size_limit = 10240000


# mailbox_size_limit limits the max. size of local mailboxes. Default is 51200000
# mailbox_size_limit = 51200000


# some basic path definitions
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix


# some basic mail system settings
myhostname = &&&&&&&&&&&&&&&&
# mydomain is unset - The default is to use $myhostname minus the first component.
myorigin = &&&&&&&&&&&&&&&&&
smtp_helo_name = &&&&&&&&&&&&&&&&&&&&



append_dot_mydomain = no

inet_interfaces = all
inet_protocols = ipv4

mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8

masquerade_domains = $mydomain
masquerade_exceptions = root

transport_maps = hash:/etc/postfix/transport


# we need to name a smtp relay host to which we forward non-local
# mails. smtp authentication is also possible.
relayhost = &&&&&&&&&&&&&&&&&&:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth


disable_vrfy_command = no


# banner

local_header_rewrite_clients =


virtual_alias_domains =

virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.groups,
ldap:/etc/postfix/ldap.distlist,
ldap:/etc/postfix/ldap.virtual,
ldap:/etc/postfix/ldap.external_aliases,
ldap:/etc/postfix/ldap.sharedfolderremote,
ldap:/etc/postfix/ldap.sharedfolderlocal_aliases

virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains

virtual_mailbox_maps = ldap:/etc/postfix/ldap.virtual_mailbox,
ldap:/etc/postfix/ldap.sharedfolderlocal

virtual_transport = lmtp:127.0.0.1:2003


canonical_maps = hash:/etc/postfix/canonical
relocated_maps = hash:/etc/postfix/relocated

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases


# postscreen settings

postscreen_dnsbl_action = enforce
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_sites =

postscreen_helo_required = no
postscreen_greet_action = drop
postscreen_greet_ttl = 1d

postscreen_non_smtp_command_enable = no
postscreen_non_smtp_command_action = ignore

postscreen_bare_newline_enable = no
postscreen_bare_newline_action = ignore

postscreen_blacklist_action = ignore
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_access.cidr

# smtpd_sender_restrictions is not defined since all relevant checks have been moved to
# smtpd_recipient_restrictions (see below) and every mail has to pass smtpd_recipient_restrictions too.
#smtpd_sender_restrictions =

smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient

# special recipient_restrictions which may be used by smtps/submission services
# (can be configured via UCR: mail/postfix/submission/restrictions/recipient/...)
# submission_recipient_restrictions =


#TLS settings
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols =
smtpd_tls_exclude_ciphers = RC4, aNULL
smtpd_tls_cert_file = /etc/univention/ssl/&&&&&&&&&&&&&/cert.pem
smtpd_tls_key_file = /etc/univention/ssl/&&&&&&&&&&&&&/private.key

smtpd_tls_received_header = no
smtpd_tls_session_cache_timeout = 3600s

tls_random_source = dev:/dev/urandom

smtpd_sasl_local_domain =

smtpd_sasl_security_options = noanonymous



# smtp client
smtp_tls_security_level = may
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_exclude_ciphers = RC4, aNULL
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy



# Support broken clients like Microsoft Outlook Express 4.x which expect AUTH=LOGIN instead of AUTH LOGIN
broken_sasl_auth_clients = yes

# tls logging
smtp_tls_loglevel = 0
smtpd_tls_loglevel = 0

# EDH config
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem


# use the Postfix SMTP server's cipher preference order instead of the remote client's cipher preference order.
tls_preempt_cipherlist = yes

# The Postfix SMTP server security grade for ephemeral elliptic-curve Diffie-Hellman (EECDH) key exchange
smtpd_tls_eecdh_grade = strong

# if virus scanning is desired, all mails can be redirected through amavis.
content_filter = smtp-amavis:[127.0.0.1]:10024

***********************************************************************************************************************
main.cf END

 

[Dufooy]

Hi @Andy+ und FricklerAtHome,

danke für diesen Threat und die ganzen Erklärungen.
@Frickler ich hatte Dir kürzlich eine PM gesendet betreffend der VM und ich verstehe Deinen Ansatz mit dem selber lesen etc...trotzdem bin ich ein grosser Freund von Konzentraten wie es Andy+ in seinem Kommentar erwähnt hat.
Im Moment nutze ich wie schon geschrieben eine Univention Kopano Lösung, leider ist diese anfällig da die gesamte Geschichte extrem aufgeblasen ist, daher bevorzuge ich doch eine Lösung wie von Dir beschrieben.
Kopano4z ist auch OK aber auch hier gibt es wieder vieles dass wir als Laien nicht einsehen können und wir sind sehr auf Infos 3er angewiesen.

Wäre toll, wenn Du mir in einer Ruhigen Minute antworten könntest, da ich sehr an Deinem System interessiert bin.

Viele Grüsse D.

 

[Dufooy]

Hi Zusammen,

hat schon jemand im Virtual Machine Manager den Collax Groupware Server vernünftig zum laufen gebracht.
Ich konnte diesen sehr schnell installieren, war in 15 Minuten erledigt und Kopano ist out of the Box on board aber es fehlen ein paar Plugins und inwieweit dieser an die jeweiligen Bedürfnisse von Hand anzupassen ist, ist fraglich.
Jemand eine Idee?

Gruß D.

PS: Im Moment ist mir unklar, warum wir uns so auf Docker einschiessen, denke eine VM im VMM ist doch viel einfacher zu händeln...was ist der Vorteil von Docker...werde dass noch mal im kopano4s Threat fragen...

 

[FricklerAtHome]

Release Hinweis PHP

Glück Auf Kopanie's

ich bin mit meiner VM von Debian 9 auf Ubuntu Server 18.04 LTS ungestiegen. Das hat im Nachgang mehrere Vorteile. Nachdem ich zunächst UBU 18.04 wie in unzähligen Anleitungen im Netz mit Apache, Maria10 und PHP 7.2 installiert habe, wurde Z-PUSH und Postfix nachinstalliert. Postfix wurde primär mit Amavis-New und Spamassassin installiert und konfiguriert.

Für die Installation von Kopano habe ich nach den Hinweisen von FBartels (hier im Forum) zwei Batch-Dateien ( Core + Wep-APP) geschrieben, die immer die aktuellen "Nightly Builds (Community)" in entsprechende Ordner entpacken und über "dpkg -i" installationsfähig machen. Bitte immer ein "apt-get install -f" bei Änderungen zur Sicherung der Abhängigkeiten von Paketen! --- @fbartels auch ich bin kein Freund von dpkg -i *.deb, manchmal ist es aber nicht zu vermeiden. kopano-spam und kopano-search, mariaDB10 laufen bei mir in der VM z.B. auch auf einem BRTFS Filesystem des VM-Host ganz ohne Probleme. Selbst der SSD Einsatz ist bei 3-6 privaten Kopano-Nutzern pro VM und einer schwachen NAS Intel-CPU mit 8 GB Ram nicht erforderlich.

Da wir nur wenige Benutzer pro VM haben, sind diese nur per DB eingebunden bzw. abgebildet. Es gibt die Benutzer nicht als UNIX-User der VM! Die Kopano User-Verwaltung erfolgt strikt per 'kopano-cli'. Die Migration zwischen einzelnen KOPANO Instanzen wird immer über den MAPI Zugriff per 'kopano-backup' organisiert. Entsprechend ist auch Postfix konfiguriert.

Ich hatte das security-update-ende von PHP 5.6 und PHP vor 7.2 zwar mitbekommen, aber ehrlicherweise auch nicht beachtet. PHP ist aber für Kopano nicht trivial! Kopano arbeitet immer mit der "default PHP" des zugrunde liegenden System. Die neue Ubuntu 18.04 based Kopano-VM hat grundsätzlich PHP 7.2 und ist auch hier weiter mit Updates versorgt (Kopano4S bzw auch meine alte Debian 9 - basierte VM sind also hier ab dem 01.01.2019 OutOfOrder---- Das Synology SPK steht aktuell bei php 7.03). Kopano läuft in dieser Konstellation auch mit den PHP 7.2 MAPI-Konnektoren für Outlook!!! Als besondere Integration ist lediglich der Apache2 zur Zusammenarbeit mit PhP 7.2 zu "enablen". Wie das funktioniert steht explizit im Output des notwendigen "apt-get install". Ansonsten waren wesentlich weniger Nachfragen beim großen "Go...." notwendig.

Beste Grüße für das neue Jahr, Gesundheit und gutes Gelingen
Der Frickler@Home

 

[fbartels]

Da du mich erwähnt hast:

@fbartels auch ich bin kein Freund von dpkg -i *.deb, manchmal ist es aber nicht zu vermeiden

es gibt immer einen Weg dies zu vermeiden. In der Vergangenheit habe ich schon öfter ein Skript gepostet, welches ein zuvor heruntergeladenes Archiv zu einem Apt Repo aufarbeitet (wodurch dann kein dpkg -i und schon gar nicht mit *.deb notwendig ist). In https://github.com/zokradonh/kopano-docker/ gibt es sogar ein Skript welches auch den Download der neuesten verfügbaren Version noch mit übernimmt: https://github.com/zokradonh/kopano-docker/blob/master/base/create-kopano-repo.sh.

Die Verwendung kann man in https://github.com/zokradonh/kopano-docker/blob/master/core/Dockerfile#L16-L20 sehen.

 

[FricklerAtHome]

@fbartels

Das ist wirklich eleganter! Danke für den Tip und auch für Euren / Deinen Support über das ganze Jahr!!
Danke auch an TosoBoso für die Weiterentwicklung des SPK's.

Gutes 2019 der Frickler@Home

 

[Tosoboso]

@fbartels
Das ist wirklich eleganter! Danke für den Tip und auch für Euren / Deinen Support über das ganze Jahr!! Danke auch an TosoBoso für die Weiterentwicklung des SPK's.

Hi F@H alternativ kannst du dieses Skript verwenden, was Teil von k4s ist und ein signiertes Repository baut; Ich habe es an Ubuntu angepasst, hoffentlich passt es; die URL muss man regelmässig aktualisieren (ich hab auch Skripte, die das machen..)
-TosoBoso

 

[fbartels]

That Skript sieht in Summe komplexer aus, als es sein muss.

Der typische Synology Nutzer ist ja nicht wirklich technisch, ich würde aber dennoch empfehlen den Quelltext von Kopano4S in ein Git Repo zu packen. Auf diesem Wege finden sicher bestimmt der ein oder andere Mitstreiter.

https://github.com/zokradonh/kopano-docker hat als Projekt eines einzelnen Nutzers angefangen, ich konnte dann darauf aufbauen und mittlerweile haben wir zwei weitere die Pull Requests beigesteuert haben.

 

[FricklerAtHome]

@Fbartels und @tosoboso

ich habe angefangen mich mit dem "Repository-Bau" zu beschäftigen. Mal schauen wie weit ich mit den Hilfen kommen! Evtuell kann ich sogar helfen.

Nun aber noch zu einer Nachfrage an FBartels:
Wie ihr mitbekommen habt frickel ich mich machmal zu Tode. Heute war wieder so ein Tag. Für eine Ubuntu 18.04 VM mit Kopano habe ich einen primären Snapshot der VM in dem sind Postfix 3.3 mit Amavis-New, Spamassassin und Postgrey komplett und nach aktuellen Standarts installiert. Z-Push ist als Paket-Quelle bereits verlinkt und führt in die aktuelle 2.4.5. Ansonsten ist Apache2.4 mit dem aktuellen Stand der 18.04 am Start.
Ich habe gestern in diesen Basis-Stand zunächst Kopano-Core integriert (noch nicht als eigenes Repository). Meine Idee war / ist nicht den Ballast alter Installationen mitzuschleppen. Jeder einzelne Dienst von Kopano-Core und zuvor auch die anderen Dienste, wurden aus neuen default-CFG / CF Dateien unter Nutzungen der Man-Pages und Quellen im Internet individuell entwickelt bzw. erstellt.
Den heutigen Tag hat aber kopano-gateway gefressen. --- Routinemässig vermeide ich auf meinen Kisten die IPv6 Nutzung. Das kann man unter Debian 8 und 9 scheinbar sehr schön in der default-sysctl ausschalten. Ruft man nach dem Eingriff ip a, ifconfig oder sonstiges auf, findet sich kein Hinweis auf verbleibende IPv6 Adressen. Unter Ubuntu 18.04 helfen diese Befehle aber nur auf der lo-Schnittstelle. Um das in 18.04 vollständig auszuschalten, muss die entsprechende grub-Datei angepasst werden. Das war bei meinem Startpunkt aus dem Snapshot der Fall. Und jetzt kommt das gateway! Aus verständlichen Gründen wird hier nicht der Zugriff auf ein File.sock empfohlen, sondern der Zugriff auf den Kopano-Server mittels Http und PORT 236 (geht auch mit https und Port 237 wenn eingerichtet).
Ich habe den Tag dafür gebraucht um zu verstehen das unter Debian, trotz scheinbar ausgeschaltetem IPv6, die Gateway-Ports trotzdem und ausschließlich für IPv6 zur Nutzung von IMAP/S und POP3/S angelegt werden. Unter meiner 18.04 mit radikal ausgeschaltetem IPv6 konnte das Kopano-Gateway nicht gestartet werden. Erst heute abend habe ich probeweise das IPv6 aus der GRUB befreit, die Einträge in der sysctl aber auf NO-IPv6 belassen. ---- Und kopano-gateway rennt. Erstaunlicherweise wird auf der lo-Schnittstelle kein IPv6 Eintrag angezeigt, für die ens3 (VM), also der nach aussen sichtbaren Netzwerkschnittstelle, schon. Unter debian wie gesagt kein entsprechender Eintrag an beiden Schnittstellen für IPv6. --- Nun die Frage: Könnt ihr in den Man-Pages und auch unter documentation.kopano.io ein wenig ausführlicher auch auf die notwendigen / zu nutzenden Netzprotokolle eingehen? Unter forum.kopano.io gibt es einen unfreundlichen beitrag zu dieser Thematik, den ich erst nicht verstanden habe.
Bei mir laufen aus dem Core folgende Module nicht kapid, konnectd, presence. Ich arbeite bei kleiner Benutzerzahl mit dem DB plugin. Alles Andere inklusive search und spamd laufen. Für das NAS (filesystem VM = ext4; Filesystem NAS = brtfs) kann ich keine wesentlich veränderten CPU-Lasten oder Festpalttenzugriffe feststellen.

Lasst uns das neue Jahr für neue Horizonte nutzen; ich bin dabei!

der Frickler@Home

 

[FricklerAtHome]

@ tosoboso und @ fbartels

Ich habe das Skript von Tosoboso für mich ein wenig angepasst.

Anhang anzeigen kopa-repo-builder.txt

Im wesentlichen habe ich die Pakete reduziert (Webmeeting, Mattermost, Office) und der Download zeigt jetzt immer auf die aktuellen Nightly-Builds. Für etwas mehr Sicherheit (zumindest gefühlt), habe ich das Skript auch noch auf zwei Dateien verteilt. Nummer 1 oben erledigt den Download und die Vorbereitungen, Nummer 2 generiert dann das lokale Repo mit dem entsprechenden INSTALL bzw. Update. Nur zur Vorsicht wenn beim Download mal was passiert.

Mit den Paketen die bei kopano.io heute liegen, hat das einwandfrei funktioniert, sind installiert und funktionsfähig. Das Nachinstallieren der Ubuntu-Pakete für Postfix, Nginx, rsyslog etc. habe ich auskommentiert. Diese Pakete sind bei mir regelhaft installiert und konfiguriert. Hier laufen Updates über das reguläre APT.

Ansonsten hat die Sache wirklich Charme! Und nach dem ersten Test funtioniert es wie es soll. Ich werde mal weiter damit rumspielen! Danke das der geschenkte Tag gestern, jetzt wieder ausgeglichen ist.

Glück Auf
Der Frickler@Home

 

[Tosoboso]

Freut mich

 

[FricklerAtHome]

Hin und wieder Zurück

Glück Auf Kopanies

ich bin produktiv von Community-Kopano auf Ubuntu 18.04 wieder zu Community-Kopano auf Debian 9.6 mit PHP 7.2 gewechselt.

Da ich eigendlich nur auf Debian unterwegs bin, habe ich im Ubuntu keine richtige Heimat gefunden. Es läuft, aber mit für mich ungewohnter Zusatz-Frickelei. In der Testmaschine wurde also eine aktuelle Debian 9 als VM installiert (ohne jegliche Desktop-Varianten); mysql-server (also Maria10), postfix, apache2, postgrey, amavis-new mit clamav und spamassassin nachinstalliert und lauffähig konfiguriert.

Jetzt wäre die Installation für Kopano dran. --- Aber wie Tosoboso, habe ich zunächst das Debian Paket / Repositry von Ond?ej Surý für PHP7.2 eingebunden. Die Debian 9-VM hat also php7.2 (weiterhin mit Updates unterstützt) als "default-PHP Basis".
Ein entscheidender PHP Antteil an Kopano ist die PHP-MAPI. Die ist aktuell und nach meinem Wissen gegen die "default-PHP" der Distribution kompiliert. Ich habe also sowohl die Kopano-Pakete für debian 9 als auch für ubuntu 18.04 heruntergeladen. Dann habe ich die gelichnamigen php7-mapi*.deb pakete aus Ubuntu 18.04 in den Debian Paketen ersetzt (einfach ersetzent reinkopiert --- das meint wahrscheinlcih auch Tososbos mit dem "Unterschieben"). Ich baue dann gemäß der Hilfen von FB und TB ein Repositry aus dem ich dann mit apt-get mein Kopano installiere.

Es hat funktioniert. Ein reines Nutzen der bisher hier veröffentlichen Scripte reicht nicht, aber man sollte schnell dahinterkommen, was wie und wo einzustellen ist.
Ich bin jetzt mit Debian 9.6, PHP7.2, Kopano 8.7.80 .465, WebApp 3.5.1.2091+, Maria10.2 und Z-Push 2.4.5 produktiv.

Aktueller geht nicht! -- oder erst nach mit den neuen "nightly builds".

@Tosoboso oder @FBartels
wann werden die Debian_9 Pakete auch gegen php7.2 kompiliert. Die deb-Datein haben bereits den gleichen Namen und die gleiche Größe // ich möchte mir das "unterschieben" sparen.

Habt immer ein: Licht-bei-der-Nacht
Der Frickler@Home