Ich habe mich in den letzten Wochen relativ intensiv mit der Groupwarelösung Kopano auseinandergesetzt. Dabei habe ich sicher bei Weitem nicht alles ausgekostet. Nun führten mich meine Gedanken im Zuge dessen wiedereinmal zur Frage, was im Grunde genommen für und gegen eine Opensourcegroupwarelösung spricht.
Andersrum gefragt: Wieso braucht man Exchange?
Aus der Hüfte geschossen, würde ich sagen: „Ich weiß es nicht… mir fällt nichts ein.“
Irgendwelche Behauptungen in den Raum zu stellen, ist natürlich immer leicht, deshalb versuche ich im Folgenden einige Aspekte zu beleuchten. Es würde mich freuen, wenn daraus eine (Kommentar)diskussion entsteht. (…sofern modsecurity gnädig ist).
MS Exchange (aktuell 2016)
Softwareanforderungen
Ohne Frage, ist Microsoft-Exchange ein rundum ausgereiftes Produkt, das Unmengen an Funktionen liefert. Es tut was es soll. Es ist ganz einfach das Standardprodukt in der Groupwarewelt.
Eingesetzt wird es innerhalb einer Active Directory Domain. Der hierfür notwendige Domänencontroller benötigt MS Windows Server ab Version 2008. (Exchange wird nicht auf dem DC installiert!)
Es wird empfohlen, dass Exchange nur auf Mitgliedsservern installiert wird. Unterstützt wird MS Windows Server ab Version 2012. Die IIS Komponente für die Nutzung von Outlook Web Acces ist bereits inkludiert.
Dies gilt auch für die Datenbank, die für Exchange notwendig ist.
Wenn man die gesamte Funktionalität von Exchange auskosten will, muss man MS Outlook einsetzen. (Mindestens Version 2010 inkl. KB 296525).
Outlook Web Access ermöglicht die Nutzung der Groupware per Webbrowser.
Hardwareanforderungen
Mindestens 8 GB Ram / bei Edge-Transport mindestens 4GB Ram
Mindestens 30GB+ Festplattenspeicher für die Exchange-Installation
Notwendige Lizenzen / Software
Server 2016
Annahme: Physischer Server mit 2 CPUs und 8 physischen Kernen / CPU. (Entspricht der Minimallizenzierung nach Cores = 16 Cores.)
1x Server Lizenz 2016
x-mal Benutzerzugriffslizenzen / Gerätezugriffslizenzen Server
Wird nur die Hyper-V Rolle installiert, dürfen 2 VMs mit Server 2016 auf dem Host betrieben werden.
Die Konfiguration könnte (minimal) so aussehen:
1x VM Server 2016 Domänencontroller
1x VM Server 2016 (Domainmember) für Exchange
Als Betriebssystemplattform kommt eine kostenlose Linuxdistribution zum Einsatz, die die Datenbank (MySQL, MariaDB, …) und den Webserver (Apache) mit im Gepäck hat.
Hardwareanforderungen
Kurz und bündig mit einem Ausschnitt aus einer Grafik (Quelle: Kopano) veranschaulicht.
Notwendige Lizenzen / Software
In der Community Edition kann Kopano kostenlos eingesetzt werden.
Fokussiert auf die Serverkomponenten der Groupware (Linuxserver / Kopano + Module) gibt es also keine Kosten für Einzellizenzen, Serverlizenzen, Clientzugriffslizenzen, Corelizenzen, Lizenzen zum Töten, erröten…
Zitat:
„Die Serverlizenzkosten / Cals etc. hat man im Firmenumfeld doch immer! Es sind mehrere Windows Domänencontroller und x Windows Clients im Einsatz“.
Stimmt sicher, will ich auch gar nicht abstreiten. Die Exchange Lizenzkosten spart man sich aber!
Fazit
Warum bin ich der Meinung, dass Opensource Groupware, wie zum Beispiel Kopano, ganz einfach die bessere Wahl ist? Warum muss es nicht immer gleich Exchange sein, nur weil es ja „die Anderen auch alle so machen“ ?
Keine Lizenzgebühren, nur eine Subscription (oder gratis community-edition).
Keine komplizierte Lizenzpolitik
Selbst hosten auf einem günstigen Rootserver möglich
Nicht abhängig von MS-Server-Struktur
Stand-Alone-Installation möglich
Somit geringe Kostenbelastung für Unternehmen
Unabhängigkeit von den „Big Playern“
Komplett flexibler, modularer Aufbau
Keine starren Vorgaben, man macht sich die Welt, wie sie einem gefällt!
Opensource = Mehraugenprinzip = Sicherheit
Annähernd freie Wahl der OS-Plattform
Ersatz von Outlook@Desktop via Deskapp
Ehrlich gesagt finde ich keine Argumente, die gegen eine Groupwarelösung wie z.B. Zarafa, Kopano etc. sprechen. Es läuft und läuft und läuft und läuft…
Und weiter gehts… Teil 1 und Teil 2 der Kopanoinstallation sollten erledigt sein. Aktuell sind die Verbindungen, die zu Kopano aufgebaut werden noch nicht verschlüsselt, da das http-Protokoll verwendet wird.
Dies bedeutet, dass sämtliche Passwörter im Klartext über die Leitung gehen. Sehr unschön, nicht zeitgemäß und deshalb unbedingt zu beheben!
SSL-Zertifikat
Für die Verschlüsselung der Verbindung, benötigt man ein SSL-Zertifikat. Variante 1 wäre, sich ein solches Zertifikat selbst zu erstellen. Variante 2 wäre, ein Zertifikat zu kaufen.
Variante 1 (self-signed): Kostet nichts, jedoch werden Internetbrowser und andere Endgeräte beim Verbindungsaufbau meckern.
Nach Eingabe des letzten Befehles, werden einige Details abgefragt. Am Wichtigsten ist die Frage nach dem common name dieser MUSS entsprechend dem FQDN des Servers befüllt werden, auf dem Kopano läuft.
a2enmod ssl
service apache2 restart
service apache2 status
vHost anpassen
Kopano + Postfix werden exklusiv auf meinem Server betrieben (es läuft sonst kein vHost). Die Konfiguration findet deshalb direkt in der /etc/apache2/sites-available/000-default.conf statt.
Grundsätzlich leite ich alle Anfragen die auf Port 80 an den Server gerichtet werden auf die HTTPS-Seite um.
Innerhalb des *.80er Virtualhost-Eintrags, richte ich eine permanente Umleitung ein:
Redirect / https://<FQDN Kopano Server>/
Danach erstelle ich im File 000-default.conf einen weiteren vHost. Dieser ist für die SSL Anfragen zuständig:
Es ist an der Zeit, den URL https//:<FQDN>/webapp aufzurufen. Ist das Zertifikat self-signed, wird der Browser eine Fehlermeldung ausgeben. (Es muss eine Ausnahme erstellt werden).
Wie im Screenshot leicht erkennbar ist, wird ein Zertifikatsfehler angezeigt (hier im IE). Dieser Fehler wird durch das self-signed Zertifikat ausgelöst. Die Verbindung ist dennoch verschlüsselt!
SSL-Variante 2 – Ein Zertifikat von einer CA kaufen. Die Implementierung eines gekauften SSL Zertifikates, läuft im Großen und Ganzen gleich ab, wie bei Einbindung eines self-signed Zertifikates.
Gegebenenfalls muss jedoch noch ein Rootzertifikat eingebunden werden, dass von der jeweiligen CA bezogen werden kann.
Nach Installation und Aufruf der Deskapp, muss ein neues Profil angelegt werden.
Deskapp up and running…
Definiert als Standard-Mail-App
Kopano-Files (Einbindung Cloudspeicher)
Herunterladen und entpacken des Modules:
cd /tmp
wget https://download.kopano.io/community/files:/files-2.1.0.74-Debian_8.0-amd64.tar.gz
tar xvfz *.tar.gz
cd files-2.1.0.74-Debian_8.0-amd64/
dpkg -i *.deb
apt-get -f install
dpkg -i *.deb
Falls man in der Webapp angemeldet ist, bitte abmelden und erneut anmelden, damit das Modul aktiv wird. (Es sollte im oberen Bereich – blaue Leiste – mit Namen FILES aufscheinen).
Über das Menü: Einstellungen -> Files (+ Add Account), kann ein Account (z.B. von Nextcloud) eingebunden werden.
Status OK
Clouddrive eingebunden
Z-Push
Sicher kein „Unbekannter“ für Zarafauser. Z-push sorgt dafür, dass die Groupwaredaten den Weg auf das Smartphone finden. Um dies zu bewerkstelligen, emuiert es das ActiveSync Protokoll. (Und das macht es extrem gut.)
Ich gehe hier nicht auf jeden Schritt ein, da die Doku von Kopano wirklich alles abdeckt, was das z-push-Herz begehrt.
Wichtig ist u.a. folgende Info:
To encrypt data between the mobile devices and the server, it’s required to enable SSL support in the web server.
Keep in mind that some mobile devices require an official SSL certificate and don’t work with self signed certificates. For Windows Phone and Windows Mobile you might need to install the certificates on the device
Heißt soviel wie:
Verschlüsselte Verbindungen benötigen SSL Support (erledigt)
Das SSL-Zertifikat sollte ein offiziell anerkanntes SSL Zertifikat sein, da es u.U. zu Problemen mit z-push kommen kann, wenn man ein self-signed Zertifikat verwendet. (die Konfiguration in diesem Artikel, verwendet ein self-signed Zertifikat.)
Windows Phone / Mobile Nutzer müssen das Zertifikat eventuell auf dem Mobilgerät installieren, damit es funktioniert.
Mit einem offiziellen SSL-Zertifikat, gibt es keine Probleme mit z-push
Mobile Device Management (mdm)
Das letzte Modul, das ich kurz besprechen möchte ist das „Mobile Device Management“ – kurz mdm. Mittlerweile sollte klar sein, dass man das komprimierte File wieder über https://download.kopano.io/community/ beziehen kann.
Der Installationsvorgang ist bitte ebenso – wie bereits bekannt – zu vollziehen.
cd /tmp
wget https://download.kopano.io/community/mdm:/mdm-2.1.0.20_16-Debian_8.0-all.tar.gz
tar xvfz mdm-2.1.0.20_16-Debian_8.0-all.tar.gz
cd mdm-2.1.0.20_16-Debian_8.0-all
dpkg -i *.deb
apt-get -f install
dpkg -i *.deb
Konfiguration
Die zu erledigenden Anpassungen, halten sich sehr stark in Grenzen.
nano /etc/kopano/webapp/config-mdm.php
Die Datei sollte nach der Anpassung so aussehen, wobei der Wert des PLUGIN_MDM_SERVER dem FQDN des Kopanoservers entsprechen muss. (mit localhost bzw. 127.0.0.1 hat es bei mir nicht funktioniert).
Verwendung
In der Webapp -> Menü Einstellungen -> MDM, sollten spätestens nach einem Klick auf den Button „Refresh“ alle Geräte / Programme aufscheinen, die per z-push mit dem Server (Mailkonto) synchronisieren.
Mit mdm kann somit per Webapp Einfluß auf die Devicesynchronisierung genommen werden.
Schlussworte
Ich hoffe, ich konnte mit meinen 3 Artikeln zum Thema „Kopano“ einen kleinen Einblick in die Leistungsfähigkeit dieser Groupwarelösung bieten, obwohl ich nicht alle der vorhandenen Module besprochen habe.
In Teil 1 meiner Kopanoartikelserie wurde (hoffentlich) klar, dass die Installation im Grunde genommen kein Hexenwerk ist. Kopano läuft, die Komponenten funktionieren. Aber… Ohne einen MTA – wie zum Beispiel Postfix – macht eine Groupware keinen Spaß!
Ziel dieses Artikels ist es, die Mailfunktionalität in Kopano zu implementieren. Damit man die Mailaccounts nicht separat anlegen muss, erhält der MTA die benötigten Daten aus der Kopanodatenbank. (= primäre Mailadresse).
Schließlich werden noch ein paar Mechanismen zur Spamabwehr eingebaut.
Dazu kommen wir jedoch später!
Kopanobenutzer, Postfix, Mailadressen… wie passt das zusammen?
Ist man Teil 1 gefolgt, befindet sich zur Zeit ein Benutzer in der Kopanodatenbank. (Benutzername: gestl, Emailadresse: daniel.gestl@it-yourself.at). Nun muss noch ein MTA her, der die Emailkommunikation übernimmt und ankommende Emails an Kopano weitergibt.
Kopano dagent
Die Kommunikationsschnittstelle zwischen dem MTA (z.B. Postfix) und Kopano bildet der sogenannte Kopano-dagent. Er „wartet“ auf eingehende Verbindungen vom MTA. Der Datenaustausch erfolgt über das LMTP (Local Mail Transfer Protocol.)
Wie auch bei der server.cfg ist die Datei dagent.cfg nicht im Verzeichnis /etc/kopano vorhanden und muss erst aus dem Verzeichnis /usr/share/doc/kopano/example-config dorthin kopiert werden.
In der Standardkonfiguration, ist der Port auskommentiert. Ich habe den Eintrag wie folgend angepasst:
lmtp_listen = 2003
Prüfen ob der kopano-dagent läuft / neu starten:
service kopano-dagent stop
service kopano-dagent start
service kopano-dagent status
Der Status sollte auf: active (running) stehen.
Ein weiterer Check, kann mit Telnet durchgeführt werden
telnet 127.0.0.1 2003
und sollte zum Ergebnis haben, dass sich der LTMP Server meldet:
Connected to 127.0.0.1.
Escape character is ‚^]‘.
220 2.1.5 LMTP server is ready
kopano-spooler
Der Kopano-Spooler ist für das Abarbeiten von ausgehenen Emails notwendig. Wenn dieses Service nicht läuft, bleiben ausgehende Emails im Postausgang hängen. Die .cfg Datei muss erst wieder in das entsprechende Verzeichnis kopiert werden:
Auch der Kopano-Suchdienst sollte laufen. Wie bereits oben durchgeführt, muss auch hier die Konfigurationsdatei erst in das Verzeichnis /etc/kopano kopiert werden. Die Datei liegt allerdings bereits entpackt im Beispielverzeichnis vor. Abgesehen davon, ist der Kopiervorgang identisch.
Auch dieser Dienst sollte als Status active (running)aufweisen.
Muss es Postfix sein?
Nein, muss es nicht. Kopano ist vollkommen modular aufgebaut. Dies gilt nicht nur für die Kopanokomponenten, sondern auch für annähernd alle Komponenten, mit denen Kopano interagiert.
Da Postfix aber einfach cool ist, darf es hier auch mitspielen. 😉
Falls Postfix und Postfix-mysql noch nicht am Server installiert wurde, ist dies nachzuholen:
apt-get install postfix postfix-mysql
Die Grundkonfiguration, besteht aus wenigen Schritten:
Auswahl von „Internet Site“
Angabe des Systemmailnamens. Das ist der Voll qualifizierte Domainname des Mailservers. Also zum Beispiel: mail.it-yourself.at. Mit diesem Namen, gibt sich der Mailserver anderen Mailservern zu erkennen. Hierbei ist es extrem wichtig, dass sowohl A-DNS (forward lookup), DNS-MX (Eintrag wer für die Maildomain der Mailexchanger ist) und Reverse-DNS (reverse DNS Lookup) korrekt konfiguriert wurden.
Kurzer DNS-Exkurs
In der Regel wird es so sein, dass die DNS Einstellungen beim Domainregistrar (dort wo man die Domain registriert hat) durchgeführt werden muss. Hierfür gibt es meistens einen Kundenbereich.
Forward DNS = DNS (A): zb. mail.it-yourself.at -> zeigt auf IP 81.28.243.54
Reverse DNS = PTR: zb. 81.28.243.54 -> zeigt auf mail.it-yourself.at
MX = Welcher Server ist für die Mailzustellung an *@it-yourself.at zuständig = mail.it-yourself.at
Services starten nicht automatisch
Die installierten Services, starten nach der installation nicht automatisch, d.h. nach einem Serverneustart müssen die Services manuell gestartet werden, sofern man den Autostart nicht aktiviert:
virtual_alias_maps: Die Aliasadressen sind in dieser Konfiguraton in einer Datei zu hinterlegen. Die Datei kann so aussehen (/etc/postfix/virtual):
Nachdem die Datei gespeichert wurde, muss sie für Postfix lesbar gemacht werden:
postmap /etc/postfix/virtual
virtual_mailbox_maps: Der Dreh- und Angelpunkt! Hier wird definiert, woher Postfix die Primärmailadresse bezieht.
Der Wert mysql:/etc/postfix/mysql-users.cf verweist auf eine Datei (mysql-users.cf), in der eine MySQL-Abfrage definiert ist, die die Mailadresse aus der Kopanodatenbank ausliest.
Ebenso in der Datei zu hinterlegen, sind die MySQL-Logindaten für die Kopano-MySQL-Datenbank, da sich Postfix sonst nicht mit der Datenbank verbinden und die Abfrage ausführen kann.
user = kopano_usr
password = geheimespasswort
hosts = 127.0.0.1
dbname = kopano_db
query = SELECT value FROM objectproperty where propname = 'emailaddress' and value = '%s';
Der Datei mysql-users.cf sollten aus Sicherheitsgründen die Rechte „600“ gesetzt werden. User und Gruppe auf root setzen!
Dieser Platzhalter wird von Postfix automatisch mit der Empfängeradresse befüllt (mail to:).
Würde eine Email an daniel.gestl@it-yourself.at ergehen, dann erhält Postfix auf die Abfrage eine positive Rückmeldung. (Emailadresse vorhanden -> Die Email wird an den dagent weitergegeben)
Wenn die Abfrage keinen Rückgabewert liefert, wird die Email abgelehnt. (Sinngemäß mit: User unknown in virtual address table)
virtual_transport: Definiert, dass Postix Emails an das LMTP-Port 2003 weitergibt, sofern sie akzeptiert worden sind. D.h. Postfix übergibt die Mails an den dagent von Kopano.
Der dagent ist fähig, die Emails anhand des Benutzernamens, oder der Emailadresse dem entsprechenden Kopanouser zuzuordnen.
virtual_mailbox_domains: Für welche Domains ist der Postfixserver zuständig.
Lokale Zustellung
Keine der Emails sollen lokal zugestellt werden. Deshalb, muss der Wert für mydestination auf localhost stehen.
Die Relayingkonfiguration
Ein sehr relevantes Thema. Nur Kopanobenutzer dürfen über den Server relayen. Entweder kann die Webapp, die Deskapp, oder eine Activesyncanbindung genutzt werden (Outlook, Smartphone). Ein direkter SMTP Versand von einem beliebigen Client ist NICHT möglich!
Anmerkung: Mit Deskapp und Z-Push beschäftige ich mich in Artikel 3 der Serie.
Anmerkung: Mit Deskapp und Z-Push beschäftige ich mich in Artikel 3 der Serie.
Funktionsprüfung
Nach jeder Konfigurationsänderung, müssen die betroffenen Dienste neu gestartet werden.
service postfix restart
Abgesehen davon, ist es immer eine gute Idee, den Status eines neu gestarteten Dienstes zu prüfen.
service postfix status
(Nicht irritieren lassen, hier ist u.a. bereits spamassassin aktiv).
Wichtig ist active (running).
Wir senden eine Email und prüfen die Webapp
Finale – Teil 2: Mit einem beliebigen Mailclient senden wir eine Email an die in Kopano vorhandene Mailadresse. In meinem Fall ist dies daniel.gestl@it-yourself.at.
Die Email sollte – sofern alles korrekt konfiguriert ist – in der Webapp von Kopano erscheinen. (http://<FQDN oder IP>/webapp)
Perfekt, läuft!
Probleme?
Sofern Probleme auftreten, kann die Logdatei von Postfix überprüft werden.
tail -f /var/log/mail.log
= Echtzeitdarstellung der Logdatei.
Noch ein paar Worte…
Dies ist das Ende von Teil 2 der Kopanoinstallation. In Teil 3 möchte ich mich mit einigen weiteren Modulen von Kopano beschäftigen.
Ebenso ist das Aktivieren des HTTPS-Protokolles ein Thema.
Kopano ist ein Fork (eine Abspaltung) von Zarafa. Einige Komponenten wurden übernommen, andere von Grund auf neu geschrieben. Kopano ist Opensource, bietet ein umfangreiches Sortiment an Funktionen und ist modular aufgebaut:
core (Basis für alle anderen Komponenten)
webapp (komplett ausgestattete Web-GUI a la Outlook Web Access)
deskapp (Vollwertiger Desktop-Mailclient auf Basis eines modifizierten Chromium Browsers! –> Senden an… funktioniert! –> kein Outlook mehr!)
mdm (mobile device management)
Betriebssystemplattform
Als Betriebssystem habe ich (wie sooft) Debian GNU Linux „momentan Version 9 (stretch)“ im Einsatz. Die Basis der Installation bildet im Grunde eine LAMP Installation. PHP sollte als mod_php laufen. Abgesehen davon, gibt es natürlich noch einige Abhängigkeiten, die bei der Installation von Kopano erfüllt werden müssen.
Klingt kompliziert, ist es aber nicht!
Natürlich werden auch einige andere Distributionen unterstützt, wie zum Beispiel: OpenSuse, Ubuntu, Fedora, RHEL, SLE….
Wer gerne „from scratch“ arbeitet, kann auch alles selbst kompilieren. Dies ist jedoch „nicht meine Baustelle“ ;-).
Woher bekommt man die Pakete von Kopano?
Die Pakete der Community-Edition können über die Website https://download.kopano.io/community/ heruntergeladen werden. Jedes Verzeichnis entspricht hierbei einem Modul (core, deskapp, files…).
Community Edition vs. Subscription
Wenn Kopano-Community-Edition eingesetzt wird, erhält man die Pakete in Form einer „bleeding edge“ Variante. Bei den Paketen handelt es sich um nightly-builds.
Die Pakete können/müssen per wget heruntergeladen werden. Die Installation erfolgt per dpkg.
Ist eine Subscription vorhanden wird es komfortabler, denn dann kann das Kopano-Repository eingebunden werden, was in weiterer Folge bedeutet, dass die gesamte Paketverwaltung per apt-get erfolgen kann.
Handysynchronisierung Z-Push
Auch Smartphoneuser kommen nicht zu kurz. Per z-push, welches kostenlos zur Verfügung steht, wird ActiveSync implementiert.
Installation LAMP
Ich gehe hier nicht darauf ein, wie man Debian GNU Linux „from scratch“ installiert. Ich gehe davon aus, dass wir von einer Basisinstallation starten.
Nachdem es auch notwendig ist, eine Datenbank zur Verfügung zu stellen und diverse Einstellungen zu bearbeiten, installiere ich zusätzlich das Paket phpmyadmin.
apt-get install mysql-server apache2 phpmyadmin
Durch obenstehenden Befehl werden auch sämtliche notwendigen Pakete (Abhängigkeiten) mitinstalliert. Es sind nur einige wenige Dialogfelder zu bestätigen:
Als Webserver wird Apache2 eingesetzt. Dies ist im Setupdialog auch so zu wählen.
Phpmyadmin fragt nach einem Passwort für den User phpmyadmin. Hier bitte einfach nur die Eingabetaste drücken. Es wird automatisch ein Passwort erzeugt, das wir in weiterer Folge NICHT benötigen.
MariaDB Einrichtung
Hierzu gibt es nicht viel zu sagen. Nachdem alle Pakete installiert wurden, muss der Befehl mysql_secure_installation aufgerufen werden. (Remove anonymous user (yes), Dissallow root login remotely (yes), remove Testdb (yes), Reload privilege tables now (yes).
Kein Login in phpmyadmin mit dem User „root“ möglich
Bei Mariadb ist für den root-user ein unix_socket Plugin aktiv. Dieses Plugin prüft, ob 2 Bedingungen gegeben sind und lässt erst dann einen administrativen Zugriff auf die Datenbank (root-User) zu. Die Bedingungen sind:
1.) Als Rootuser in der Konsole eingeloggt?
2.) Authentifiziert als vorhandener Mariadb-root-user?
Wenn man sich nun bei phpmyadmin als Benutzer root einloggen will, schlägt dies fehl. Klar! In dem Fall meldet man sich ja nicht per Konsole (als User root) bei der Mariadb an, sondern über das Web. D.h. es werden nicht beide Bedingungen erfüllt.
Eine gute Lösung hierfür ist, einen eigenen Benutzer anzulegen, der MariaDB-Rootrechte besitzt.
Im Terminal des Servers bzw. des Linuxsystems sind folgende Schritte (eingeloggt als root) durchzuführen:
mysql
grant all on *.* to neuerrootuser@localhost (RETURN)
identified by 'deinpasswort' with grant option;
Nach Abschluss obiger Aktion, haben wir uns somit nun einen neuen Rootuser für die MariaDB gebaut. Um wieder aus der Mariadb-Konsole auszusteigen, muss quit eingegeben werden.
phpmyadmin
Zur einfacheren Verwaltung von Datenbanken, wird phpmyadmin installiert. Auch hier ist das Setup schnell vollzogen. Nach Beantwortung der Frage „Konfigurieren der Datenbank für phpmyadmin mit dbconfig-common“ mit JA und der Bestätigung der Frage nach einem Passwort für den phpmyadmin-Benutzer mit einem Return (Details siehe weiter oben), ist die Installation abgeschlossen.
Phpmyadmin sollte nun per Internetbrowser aufrufbar sein. Als Login ist bitte der User/Passwort zu verwenden, den wir in der Konsole für die MariaDB angelegt haben!
Mit root funktioniert es nicht!
Somit haben wir eine LAMP Basis geschaffen und können uns nun der Kopanoinstallation widmen.
Kopano installieren
Pakete herunterladen
Die Pakete von Kopano können – sofern man keine Subscription hat – per wget heruntergeladen werden. (Anmerkung: Nutzer mit Subscription, können direkt per apt-get auf die Pakete zugreifen.)
Auf dem Linuxserver selbst, kann man ein Verzeichnis erstellen, um die Pakete in selbiges herunterzuladen, oder man greift auf das /tmp Verzeichnis zurück.
cd /tmp
wget https://download.kopano.io/community/core:/core-8.6.81.475_0%2B86-Debian_9.0-amd64.tar.gz
wget https://download.kopano.io/community/webapp:/webapp-3.4.23.1812%2B1035-Debian_9.0-all.tar.gz
wget https://download.kopano.io/community/files:/files-2.1.5.296-Debian_9.0-all.tar.gz
wget https://download.kopano.io/community/mdm:/mdm-2.1.0.106%2B26-Debian_9.0-all.tar.gz
Anmerkung: Die Dateinamen ändern sich täglich (Versionsnummer -> da nightlies! Bitte die Links entsprechend anpassen. Notwendige Daten hierfür erhält man auf der Kopano-Community-Seite.
Nach dem Download, werden die *.tar.gz Dateien enpackt. Pro entpackter Datei, wird automatisch ein entsprechendes Unterverzeichnis erstellt.
Entpacken und installieren des Kopano-core
tar xvfz core-8.6.81.475_0+86-Debian_9.0-amd64.tar.gzcore-8.4.0~35_19.1-Debian_8.0-amd64
cd core-8.6.81.475_0+86-Debian_9.0-amd64
dpkg -i *.deb
Der Installationsversuch schlägt fehl, da es unaufgelöste Abhängigkeiten gibt. Genaugenommen erhält man die Meldung: „Fehler traten auf beim Bearbeiten von:“
Unaufgelöste Abhängigkeiten bereinigen
Apt wäre nicht apt, wenn es für diesen Umstand keine einfache Lösung gäbe.
apt-get install -f
Durch diesen Befehl werden alle fehlenden Pakete „nachgezogen“.
Kopano-core — Zweiter Versuch
Bei der Instation von Kopano-Core sollten nun keine unaufgelösten Abhängigkeiten mehr angezeigt werden.
Kopano Webapp
Bei der Installation der Webapp wird nun gleich verfahren, wie bei „Core“. Entpacken der tag.gz Datei, in das Verzeichnis wechseln, in dem die entpackten .deb Files liegen + Installation mittelst dpkg.
tar xvfz webapp-3.4.23.1812+1035-Debian_9.0-all.tar.gz
cd webapp-3.4.23.1812+1035-Debian_9.0-all
dpkg -i *.deb
Wieder werden fehlende Abhängigkeiten zu Problemen bei der Installation führen. Abermals löst apt-get das Problem.
apt-get -f install
Abschließend stellt auch die Installation der Webapp kein Problem mehr dar. (Im Verzeichnis in dem die entpackten Dateien der Webapp liegen):
dpkg -i *.deb
Um die Konfiguration der Webbapp zu aktivieren, muss der Apachewebserver neu gestartet bzw. die Konfiguration neu eingelesen werden.
service apache2 reload
oder
service apache2 restart
Ist die Webapp erreichbar?
Dies lässt sich sehr einfach mittels Browser testen.
http://<FQDN oder IP>/webapp
Bad request?
Offenbar erhalten wir hier einen Bad Request. Erste Anlaufstelle für diesen Fehler, sind die Apache Logdateien, die sich im Verzeichnis /var/log/apache2 befinden.
Der Fehler wird in der Datei /var/log/apache2/error.log protokolliert.
cat /var/log/apache2/error.log
Er lautet:
Rejected insecure request as configuration for ‚INSECURE_COOKIES‘ is false.
Das Problem tritt deshalb auf, da wir unverschlüsselt auf die Webapp zugreifen wollen. Es ist also eine HTTPS-Verbindung notwendig, um in der Standardkonfiguration auf die WebApp zugreifen zu können.
Dies kann man allerdings umschiffen (wenngleich es im Grunde keine gute Idee ist). Wir ziehen die HTTPS Konfiguration später nach und deaktivieren die Zwangsverschlüsselung der Verbindung.
nano /etc/kopano/webapp/config.php
Anpassen der Zeile: define(„INSECURE_COOKIES“,true);
Das Ganze steht per default auf false.
In der Konfigurationsdatei steht hierzu geschrieben: // Set to ‚true‘ to disable secure session cookies and to allow log-in without HTTPS.
Nach dieser Änderung, muss der Apache2 neu gestartet werden.
service apache2 restart
Und wir versuchen es erneut! Diesmal funktioniert es einwandfrei!
Die Grundinstallation von Kopano-Core und der Webapp sind somit abgeschlossen. Hierbei handelt es sich jedoch bislang rein um das Frontend! Die Datenbankanbindung ist noch nicht gegeben.
WICHTIG:Das Deaktivieren der SSL-Verbindung, dient hier rein dazu, mit der Installation in einer Testumgebung fortfahren zu können. Wenn der Server sich später im Produktiveinsatz befinden soll, MUSS UNBEDINGT darauf geachtet werden, dass dies wieder umgestellt wird. Verschlüsselung ist ein MUSS!
Die Konfigurationsfiles der Kopanokomponenten fehlen
Die Konfigurationsdateien befinden sich schon seit Längerem nicht mehr im Ordner /etc/kopano/…
Diese findet man aktuell unter: /usr/share/doc/kopano/example-config/, wobei die server.cfg und die spooler.cfg im .gz Format vorliegen und erst enpackt werden müssen!
Wir kopieren die Datei server.cfg.gz in den Ordner /etc/kopano/ und entpacken sie mit gzip:
Im nächsten Schritt muss eine Datenbank eingerichtet werden.
MySQL Datenbank einrichten
Per phpmyadmin stellt dieses Vorhaben kein all zu großes Problem dar.
Zuerst erstellt man eine neue Datenbank.
und einen Benutzer
Den Abschluß bildet die Zuordnung der Benutzerberechtigungen. (Datenbank kopano / Benutzer kopano)
Konfigurationsdatei von Kopano-Core anpassen
In einem der vorhergehenden Schritte, wurde die Konfigurationsdatei in das Verzeichnis /etc/kopano kopiert und entpackt. Sämtliche Konfigurationsparameter, sind in der Datei auskommentiert und müssen erst (nach Bedarf) aktiviert werden.
Die server.cfg Datei für dieses Tutorial, kann man sich hier herunterladen.
ACHTUNG: Bitte die Einstellungen für die Datenbank anpassen (User, Passwort, DB-Name, Connection).
Kopano Server starten
Der Start des Server sollte nun bewirken, dass die zuvor erstellte Datenbank mit den notwendigen Tabellen / Feldern befüllt wird.
Zuerst stoppen wir einen eventuell laufenden Kopano Server.
service kopano-server stop
Der Start
service kopano-server start
und die folgende Statusprüfung (service kopano-server status), sollte folgendes Bild ergeben.
Sofern man hier etwas von einem Datenbankproblem (DB nicht vorhanden) liest und alle Einstellungen in der server.cfg korrekt sind, hilft oft ein weiterer Neustart von Kopano.
Normalerweise werden mit dem Start des Kopano-Server, in der Datenbank Tabellen und Felder angelegt.
Um zu überprüfen, ob die Datenbank bereits mit Daten befüllt wurde, kann sie in phpmyadmin aufgerufen werden. (Wenn der der Verbindungsvorgang erfolgreich war, sollten hier etliche Tables und Felder ersichtlich sein):
Kopano Benutzer
Die Kopanobenutzer kommen in dieser Konfiguration aus der MySQL Datenbank und müssen per Linuxkonsole angelegt werden.
Folgend wird ein Benutzer „gestl“ inklusive Mailadresse angelegt. Der Benutzer ist Administrator und bekommt deshalb zusätzlich einen Parameter mit auf den Weg (-a1).
Um zu prüfen, ob die Konfigurationsarbeiten erfolgreich waren, erfolgt abschließend der Loginversuch.
http://<FQDN / IP>/webapp
Aufgaben
Kalender
Kontakte
Mail
Englische Ordnernamen
So manchem, mag aufgefallen sein, dass die Ordner für Posteingang, Postausgang etc. auf englisch angeführt werden. Um dies im Nachhinein zu ändern, sind einige Schritte notwendig.
Zuerst muss man sicherstellen, dass das deutsche Sprachpaket für die jeweilige Linuxdistribution installiert ist. Da ich Debian verwende, kann dies mit dem Befehl:
dpkg-reconfigure locales
erledigt werden. Im erscheinenden Fenster, muss bitte de_DE.UTF8 UTF8 ausgewählt (Leertaste) und schließlich mit OK bestätigt werden.
Die Frage nach dem „default locale“ bitte ebenso mit de_DE.UTF8 bestätigen.
Kopano liefert mit dem Befehl „kopano-localize-folders“ eine Möglichkeit mit, die bereits erstellten englischen Ordnernamen auf deutsche Ordnernamen umzustellen:
Danach sollten die Ordner in deutscher Sprache erscheinen.
Ende – Teil 1
Wie man sieht, ist die Installation keine Zauberei. Allerdings fehlt hier noch die Einbindung von Postfix, damit Emails versendet und empfangen werden können. (…und ein wenig Finetuning).
Darauf werde ich in einem zweiten Artikel zum Thema „Kopano“ eingehen.
An alle, die ggf. gerne einen Kommentar hinterlassen würden, jedoch von modsecurity blockiert werden / worden sind.
Trotz einer Unmenge an Ausnahmen per ID, passiert es immer wieder. Ich dachte, es wäre mittlerweile gelöst… 🙁
Ich entschuldige mich vielmals für diese Unannehmlichkeiten.
Das Problem sollte nun nicht mehr bestehen.
PS: Falls jemand eine recht vollständige Ausnahmeliste für die /wp-comments-post.php usw.hat, bitte immer her damit! 🙂
Cookie-Zustimmung verwalten
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Notwendige Lizenzen / Software
Nachdem die Datei gespeichert wurde, muss sie für Postfix lesbar gemacht werden:
