Debian Stretch Mariadb – Rootlogin phpmyadmin funktioniert nicht mehr

Es ist zwar kein neuer Hut mehr, dass es mit Mariadb in Verbindung mit dem rootlogin in phpmyadmin Probleme gibt, ich möchte es an dieser Stelle aber dennoch erwähnen und eine – meiner Meinung nach gute – Lösung anbieten.

Hintergrund

Bei Mariadb (aktuell in Version 10.1.26-0+deb9u1) ist für den root-user ein unix_socket Plugin aktiv. Dieses Plugin prüft, ob man:

1.) Als Rootuser in der Konsole eingeloggt ist und
2.) den vorhandenen 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.

Lösungsweg

Es gäbe nun die Möglichkeit, das Plugin für den Mariadb-Benutzer root zu deaktivieren. (Davon sehe ich hier aber ab). Besser ist es, einen neuen Datenbankbenutzer anzulegen, der -so wie root- auch Vollzugriff auf alle Datenbanken hat, um letztendlich alle Datenbanken per phpmyadmin verwalten zu können.



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;

Es ist nun ein weiterer Benutzer mit DB-Rootrechten angelegt worden.

Absicherung der Installation

Es ist immer eine gute Idee, den Befehl

mysql_secure_installation

auszuführen, um einige DB-Einstellungen sicherer zu gestalten. Hierbei kann (und sollte!) auch für den bereits vorhandenen DB-Benutzer „root“ ein Passwort gesetzt werden. (In der Standardkonfiguration hat dieser DB-Benutzer kein Passwort, da ja u.a. auf das unix_socket-Plugin zurückgegriffen wird).

Bestehende MariaDB-Benutzer abfragen / Plugincheck

Will man prüfen, welche User angelegt sind / für wen das oben erwähnte Plugin aktiv ist, begibt man sich abermals in ein Rootterminal und startet folgende Abfrage:

mysql

select user, plugin from mysql.user;

 

 

Meltdown, Spectre: Systeme patchen nicht vergessen

Angesichts der momentan vorherrschenden Securityproblematik (Spectre, Meltdown…) solltet ihr eure Systeme Patchen. Für „Linux“ gilt es bereits vorhandene Kernelaktualisierungen einzuspielen und das System danach neu zu starten.

So gibts für die Stable Version von Debian (Stretch) mittlerweile die Kernelversion 4.9.65-3+deb9u2, die der Sicherheitsproblematik entgegenwirkt.

https://www.debian.org/security/2018/dsa-4078

https://security-tracker.debian.org/tracker/linux

Auch Microsoft stellt Patches zur Verfügung

Windows 7: https://support.microsoft.com/en-us/help/4056897/windows-7-update-kb4056897

Windows 8: https://support.microsoft.com/en-us/help/4056898/windows-81-update-kb4056898

Windows 10: https://support.microsoft.com/de-de/help/4056892/windows-10-update-kb4056892

Starre Vorgaben versus Flexibilität? Exchange vs. Opensource Groupware

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

Exchange 2016

  • 1x Lizenz für Exchange
  • x-mal Benutzerzugriffslizenzen / Gerätezugriffslizenzen Exchange

Kopano

Softwareanforderungen

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.

Im  Firmenumfeld bietet es sich jedoch an, eine Subscription abzuschließen. Die Kosten richten sich hier nach der Anzahl der User und nach der Ausstattung des Kopano Paketes.

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“ ?

  1. Keine Lizenzgebühren, nur eine Subscription (oder gratis community-edition).
  2. Keine komplizierte Lizenzpolitik
  3. Selbst hosten auf einem günstigen Rootserver möglich
  4. Nicht abhängig von MS-Server-Struktur
  5. Stand-Alone-Installation möglich
  6. Somit geringe Kostenbelastung für Unternehmen
  7. Unabhängigkeit von den „Big Playern“
  8. Komplett flexibler, modularer Aufbau
  9. Keine starren Vorgaben, man macht sich die Welt, wie sie einem gefällt!
  10. Opensource = Mehraugenprinzip = Sicherheit
  11. Annähernd freie Wahl der OS-Plattform
  12. 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…

 

 

Installation: Kopano der „neue“ Stern am Groupwarehimmel – Teil 3

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 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.

Ein solches Zertifikat wird so zusammengebaut:

openssl genrsa -des3 -passout pass:x -out kopano.pass.key 4096
openssl rsa -passin pass:x -in kopano.pass.key -out kopano.key
rm kopano.pass.key
openssl req -new -key kopano.key -out kopano.csr

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.

Und nochmals in die Konsole:

openssl x509 -req -days 1095 -in kopano.csr -signkey kopano.key -out kopano.crt

Das .key-File und das .crt-File werden anschließend in die dafür vorgesehenen Ordner verschoben.

mv kopano.crt /etc/ssl/certs

 

mv kopano.key /etc/ssl/private

Apache ssl aktivieren

Kurz und schmerzlos.

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:

<Virtualhost *:443>
ServerName <FQDN Kopano Server>
ServerAdmin hostmaster@domain
DocumentRoot /var/www/html

 

#SSL Zertifikate
SSLEngine on
SSLCertificateFile /etc/ssl/certs/kopano.crt
SSLCertificateKeyFile /etc/ssl/private/kopano.key

 

#SSL Logging
LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/kopano_ssl_error.log
CustomLog ${APACHE_LOG_DIR}/kopano_ssl_access.log combined
</VirtualHost>

Apacheserver neu starten…

service apache2 restart

SSL-Check

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.

Bsp:

SSLCaCertificateFile /etc/ssl/certs/RootZertifikat.crt

Ich empfehle hier bewusst keine CA (Zertifizierungsstelle). Bitte googeln.

SSL Done! 😉

Deskapp im Einsatz

Die Standarddeskapplikaton für Emails unter MS Betriebssystemen ist Outlook. Im Arbeitsalltag ist dies (leider) annähernd selbstverständlich.

Hierbei scheint ein funktionierendes „Senden an… -> Emailempfänger“ das absolute Killerkriterium zu sein. (Zumindest meiner Erfahrung nach).

Wenn man „seinerzeit“ Zarafa mit Hilfe der Webapp verwendete und keinen Emailclient einsetzen wollte, gab es dieses Feature einfach nicht.

Aber…

Mit Kopano kam die Deskapp. Die Deskapp ist genaugenommen ein adaptierter Chromium Browser, der sämtliche Funktionen der Webapp beinhaltet.

Der Clou dabei? — „Senden an Emailempfänger“ funktioniert damit!

Bye Bye liebe Standard-Mailclients!

Download /  Einrichtung / Start der Deskapp

Wie alle anderen Komponenten auch, kann die Deskapp von https://download.kopano.io/community auf den Rechner gezogen werden.

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.

vim /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.

Vielen Dank für das Interesse!

Hier gehts zu Teil 1 …

 

 

 

1 2 3 26