11 Posts

HowTo noch im Aufbau

Vorwort:

Anknüpfen an das alte manuelle HowTo für Kopano  unter Debian 9 gibt es nun eine Update in Form von Debian 10 und einer Installation mittels Paketmanager.

Voraussetzungen:

Installiertes und lauffähiges Debian 10

Es ist nicht notwendig weitere externe Repositories zu ergänzen, da Kopano bereits im Debian Repo mit enthalten ist. Dank der Pakete kommen die meisten (nicht alle) Abhängigkeiten automatisch mit und man muss nicht mehr manuell auf eine gewisse Reihenfolge achten.

Die Installation:

Sicherheitshalber Updates installieren, sofern vorhanden

root@mail:~# apt-get update & apt-get dist-upgrade -V

Installation Kopano Pakete als Basis. Alle notwendigen Abhängigkeiten werden installiert. Man kann auch statt dem Nginx alternativ Apache oder Lighthttpd verwenden.

root@mail2:~# apt-get install kopano-core kopano-webapp-nginx

Während der Installation muss man ein Kennwort für den MySQL Server angeben sowie bestätigen:

Im nächsten Schritt wird ein erster Admin-User erstellt. Dank CLI Tools sehr einfach:

root@mail2:~# kopano-admin -c thuerter -p %passwort% -e tim@mail2.huerter.me -f "Tim Huerter" -a1
User created.

Die Webseite kann nun per https:%servername% aufgerufen werden. Jedoch wird es einen Fehler beim Login geben in Form von „Unknown MAPI Error: MAPI_E_NOT_FOUND“

 

Der genannte Fehler resultiert aus einem fehlenden Datenstore für den User.

Prüfen ob ein User einen Store hat:

root@mail2:~# kopano-cli --list-orphans
Stores without users:
Store guid                       Username             Last login       Store size       Store type
--------------------------------------------------------------------------------------------------------
Users without stores (1):
User             Full Name            Homeserver
----------------------------------------------------------
thuerter        Tim Huerter           Unknown

Erstellen eines globalen Stores:

root@mail2:~# kopano-cli --create-store

Erstellen eines User-Stores:

root@mail2:~# kopano-cli --create-store -u thuerter

Erneute Store-Prüfung:

root@mail2:~# kopano-cli --list-orphans
Stores without users:
Store guid                       Username             Last login       Store size       Store type
--------------------------------------------------------------------------------------------------------
Users without stores (0):
User             Full Name            Homeserver
----------------------------------------------------------

Nun kann man sich unter https://server-name und dem zuvor erstellten User einloggen.

Hinweis: Eine automatisch Weiterleitung von http auf https existiert nicht!

Nun ist Kopano grundinstalliert jedoch nicht nicht nutzbaz, da man weder Mails versenden noch empfangen kann. Hierfür wird ein MTA benötigt.

Installation MTA (Mailserver) in Form von Postfix inklusive MySQL Anbindung

root@mail2:~# apt-get install postfix postfix-mysql

Meine /etc/postfix/main.cf habe ich um folgende Parameter erweitert:

#Kopano Custom
virtual_alias_maps = hash:/etc/postfix/virtual # Aliase/Weiterleitungen für Postfächer
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf # Auslesen vorhandener Postfächer
virtual_transport = lmtp:127.0.0.1:2003 # Weiterleiten der Mail an Dagent für die Zustellung an das Postfach
virtual_mailbox_domains = mail2.huerter.me # Berechtigte Empfangs-Domains

smtpd_recipient_restrictions = permit_mynetworks,
reject_non_fqdn_recipient,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unauth_pipelining,
reject_unverified_recipient

 

Inhalt „/etc/postfix/virtual“ für Weiterleitungen:

#ALIAS  E-MAIL
kontakt@mail2.huerter.me      tim@mail2.huerter.me

Damit Postfix sich auch verbinden zum Auslesenn der Benutzer, erstellen wir noch die passende MySQL-Berechtigung:

root@mail2:/etc/postfix# mysql -u root

Der Login ohne Passwort ist möglich, da die UNIX Socket Authentisierung genutzt wird.

MariaDB [(none)]> GRANT ALL PRIVILEGES ON kopanoserver.* TO 'kopano'@'localhost' IDENTIFIED BY '%mein-passwort%' WITH GRANT OPTION;
MariaDB [(none)]> flush privileges;

Inhalt „/etc/postfix/mysql-users.cf“ für die Prüfung, ob der Empfänger überhaupt existiert:

user = kopano
password = %mein-passwort%
hosts = 127.0.0.1
dbname = kopanoserver
query = SELECT value FROM objectproperty where propname = 'emailaddress' and value = '%s';

 

 

Umwandeln der Map Dateien in ein lesbares Format für Postfix sowie Neustart des Dienstes

root@mail2:/etc/postfix# chmod 600 /etc/postfix/mysql-users.cf
root@mail2:/etc/postfix# postmap /etc/postfix/mysql-users.cf
root@mail2:/etc/postfix# postmap /etc/postfix/virtual

Optional können noch WebApps installiert werden

root@mail:~# apt-get install kopano-webapp-contactfax kopano-webapp-gmaps kopano-webapp-pimfolder kopano-webapp-quickitems kopano-webapp-titlecounter kopano-webapp-webappmanual kopano-webapp-zdeveloper kopano-webapp-files

 

 

 

 

 

Einleitung

Ursprünglich war geplant eine einmalig gekaufte Office 2013 Business Version unter einem Windows Terminalserver mit mehreren Usern zu betreiben. Die Installation von Office als auch die Aktivierung verlief ohne Probleme. Beim ersten Start von einem Office Programm (Word, Excel, Outlook, …)

Diese Kopie von Microsoft Office 2013 kann auf einem Computer mit Terminal Services verwendet werden. Um Office 2013 auf einem Terminaldienste-Computer verwenden, müssen Sie eine Volume License Edition von Office verwenden.

oder

This copy of Microsoft Office 2013 cannot be used on a computer running Terminal Services. To use Office 2013 on a computer running Terminal Services, you must use a Volume License edition of Office.

Nun kann man entweder eine Volumenlizenz erwerben oder aber man nutzt Office 365. Laut einem ISP welcher ebenfalls Office 365 Abos vermittelt habe ich die Aussage erhalten es würde mit einer „Office 365 Business“ Lizenz funktionieren. Aufgrund anderer Blogs stößt man öfter auf „Office 365 ProPlus“ als Abo.

 

Hierbei handelt es sich um ein reines Office Abo ohne Exchange Funktionalität. Kostentechnisch bietet es sich an, dieses Abo mit einem „Office 365 Business Essentials“ Abo zu kombinieren, da die Kosten hier etwas geringer sind als bei einem Office 365 E3 Plan. Der E3 Plan hat aus meiner Sicht einzig den Vorteil, dass er 100GB Postfachgröße statt 50GB beinhaltet.

Ob die folgenden Schritte technisch auch mit einer Office 365 Business Lizenz machbar sind ist möglich. Ich wurde jedoch explizit von einem direkten Microsoft Cloud Partner darauf hingewiesen, dass dies ein Lizenzverstoß wäre.

Zusammenfassung als Ausgangsbasis:

Office 365 Business Essentials Abo + Office 365 ProPlus Abo pro User besitzen

Windows Server 2016 mit Terminalserver Rollen

 

Lösung:

Eine reguläre Installation von Office ist nicht direkt notwendig. Hierzu nutzt man das Office Bereitstellungstools mit einigen Anpassungen

  1. Herstellen einer (RDP) Verbindung mit einem Administrator User
  2. Download Bereitstellungstool
  3. Erstellen einer eigenen „myconfiguration.xml“
  4. Öffnen einer CMD mit administrativen Rechten
    1. Download von Office per „setup.exe /download myconfiguration.xml“
    2. Installation von Office per „setup.exe /configure myconfiguration.xml“
  5. Office Anwendung bspw. Word starten und mit dem berechtigten (lizenzierten!) Office 365 Benutzer einloggen

 

Hinweis zu Schritt 4.1:

Den Fortschritt kann man nicht konkret prüfen jedoch wird im selben Ordner in welchem sich die „setup.exe“ befindet ein neuer Ordner namens „Office“ erstellt. Nach dem Download war dieser Ordner circa 2GB groß.

 

Hinweis zu Schritt 3:

Empfehlen würde ich als Editor Notepad++ um ein versehentliches formatieren zu verhindern.
Meine Konfiguration sieht wie folgt aus:

 

Die Konfiguration kann man sich entweder per Dokumentation von Microsoft selbst mühevoll zusammenbauen oder man nutzt einen Config Generator welcher von Microsoft bereitgestellt wird. Besonders wichtig ist die Zeile „SharedComputerLicensing“ welche den Wert „1“ beinhaltet. Ansonsten wird Office nicht starten und die in der Einleitung genannte Fehlermeldung liefern.

 

Hinweis zu Windows Server 2019:

Laut MS Cloud Partner ist das oben beschriebene Vorgehen nicht möglich bei Windows 2019 Servern. Entweder bleibt hier der Erwerb von Volumen-Lizenzen oder einew Migration in die Azure Umgebung. Letzteres dürfte verhältnismäßig teuer werden.

 

 

Da öfter mal Zertifikate in den Arten umgewandelt werden müssen, kommt es öfter mal vor, dass Zertifikate von PFX (Windows) in cert/key Dateien umgewandelt werden müssen.

Export Zertifikate (cer) aus pfx:

openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.crt

Export Key aus pfx:

openssl pkcs12 -in cert.pfx -nocerts -out cert_crypted.key

openssl rsa -in cert_crypted.key -out cert.key

Der erste Befehl exportiert den Schlüssel passwortgeschützt (passphrase), der zweite entfernt das Kennwort. Gerade in Verbindung mit einem webserver (Apache/Nginx) sollte das Kennwort entfernt werden.

Umwandlung cert/key zu pfx [HowTo: cert to pfx]

 

 

 

Vorwort:

Mir selbst ist schon öfters die teils sehr schlechte Qualität einer RDP Sitzung aufgefallen. Ein Bekannter hatte mich gebeten, einmal zu prüfen ob man nicht was „Tuning“ betreiben kann. Hierzu muss man wissen, dass RDP selbst standardmäßig immer TCP Port 3389 nutzt. TCP ist aufgrund seiner Struktur verglichen mit UDP langsam.

 

Im Weg durch das „Neuland“ habe ich verschiedene Ansätze gefunden und zwei konkrete habe ich erfolgreich getestet

  1. Einrichtung RDS Gateway Server welcher die Datenübermittlung per UDP erledigt
  2. Anpassung der FPS für die RDP Sitzung (auch für Windows Clients interessant)

Beide Varianten sind so gesehen Windows Boardmittel und benötigen keine Programme von Drittanbietern. Gerade von letzteren dürften diverse Tools vorhanden sein, bspw. für Citrix Sitzungen.

 

Installation & Einrichtung RDS Gateway Server

Info: Um den RDS Gateway Server nutzen zu können, sollte man nach Möglichkeit ein öffentliches Zertifikat besitzen.

Das folgende Tutorial zeigt Schritt für Schritt die Installation und Konfiguration.

 

Öffnen des Server Managers

Allgemeine Info Seite, „Weiter“

Und nochmal „Weiter“

Auswahl des Zielservers, bei einem System nun nicht so schwer…

 

 

Auswahl der „Remotedesktopdienste“ Rolle:

Bestätigung der Installation von benötigten Abhängigkeiten in Form von „Features“.

 

Nach erfolgter Installation können wir nun mit der Konfiguration beginnen:

Erstellen einer neuen Richtlinie innerhalb der „Verbindungsautorisierungsrichtlinien“.

Erstellen einer RD CAP / RD RAP Richlinie.

 

Festlegen eines Namens für die CAP Richtlinie:

Auswahl von Autorisierung-Art und Auswahl der erlaubten Gruppen/Computer

 

Auswahl und Import des Zertifikats.

Sofern die Zertifikate als c(e)rt. vorliegen, so muss man diese in eine PFX Datei umwandeln Konvertieren von crt zu pfx

Alternativ kann man auch mit Windows Tools ein selbst signiertes Zertifikat erstellen.

 

Damit der zusätzliche Gateway Dienst genutzt wird, müssen noch die Firewall Regeln aktiviert werden. Erstellt wurden diese bereits:

Abschließend für diesen Punkt kann man die Einstellungen Testen, in dem man eine neue RDP Verbindung öffnet.

Über die Verbindungseigenschaften sollte nun innerhalb des Popups der Zusatz „and UDP is enabled“ erkennbar sein.

Beobachtung: Bei meiner Windows 10 VM (Client!) ist UDP wohl schon von Haus aus aktiviert…

 

 

Anpassung FPS

Hinweis: Ich würde in jedem Falle vorher ein Backup der Registry Einstellungen durchführen per Rechtsklick und „Export“:

 

Quelle: https://support.microsoft.com/de-de/help/2885213/frame-rate-is-limited-to-30-fps-in-windows-8-and-windows-server-2012-r

Mittels „regedit“ bzw. Registry kann man unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations den Schlüssel „DWMFRAMEINTERVAL“ mit dem Dezimal-Wert „15“ erstellen. nach einem Reboot greift die Änderung.

 

 

Fazit: Die Verbindungsqualität ist erheblich besser. Bei einem Musikvideo mit 720p von Youtube kann man es relativ ruckelfrei sehen. Dies spiegelt sich aber auch in der genutzten Bandbreite wieder, die Auslastung ist hier zwischen 3-10 MB/s.

 

Bei größeren Umgebung mit vielen Nutzern dürfte die Bandbreite zum Problem werden … für die Admin-VM aber sicherlich von Vorteil 😉

 

Meine Teststellung wird jedoch zusätzlich durch ein (Open)VPN geleitet und der Zielcomputer steht im Internet. Ein Test im LAN steht noch aus…

Zertifikate waren noch nie unwichtig und auch durch diverse Änderungen (DSGVO, …) nimmt das Verschlüsseln immer mehr zu. Diverse (REST-) APIs, Publishings, Netscaler usw. funktionieren ohne SSL nicht.

Kurzer Überblick der Filetypen:

  • .csr => Certifcate Request, dieser muss an den Provider welcher das SSL Zertifikat ausstellt übermittelt werden
  • .key => Ist der private Schlüssel und wird zur Verschlüsselung der Daten genutzt. Dieser sollte gut gesichert aufbewahrt und nicht mit Dritten geteilt werden
  • .crt => Enthält das reine Zertifikat
  • .pem => Enthält den privaten Schlüssel (.key) als auch das eigentliche Zertifikat (.crt)
  • .pfx => Ist ein spezielles Format für Windows Serrver. Diese Datei enthält alle Dateitypen (Zertifikate, ggf. Zwischenzertifikat, privater Schlüssel).

Da Windows Server auch im Jahr 2019 noch keine gängigen Typen importieren können, muss man die Datein zusammenfügen in einer PFX Datei.

 

Zur Umwandlung habe ich eine Debian Maschine als Hilfe genutzt:

Das „Export Password“ dient als Absicherung der neuen Datei, damit diese nicht unberechtigt genutzt werden kann.

Nun kann das PFX File normal auf dem Windows Server importiert werden.

Hinweis: Je nach openssl Version passiert es, dass die Umwandlung ohne Fehler festhängt. Hierbei könnte es helfen „-passout pass:%mein_pw%“ dem Befehl anzuhängen.

Im folgenden Artikel beschreibe ich die Peer-to-Peer (P2P) Anbindung zwischen einer PfSense als OpenVPN Server und einem Windows 2016 Server OpenVPN Client mittels eines Shares Secrets.

 

Als Vorbreitung sollte OpenVPN installiert werden. Man kann aus dem anderen HowTo OpenVPN installieren – [HOWTO OpenVPN] . Hierbei reicht die Durchführung der Schritte 1 bis 2.

 

Nachdem Login in der PfSense wird unter dem Punkt „VPN“ der Unterpunkt „OpenVPN“ ausgewählt. Anschließend wird ein neues Server Profil erstellt:

Für das neue Profil müssen diverse Einstellungen definiert werden.

 

Die Verschlüsselung kann frei gewählt werden, muss aber auf Client und Serverseite gleich sein. Ebenso muss der „Local port“ mit dem Zielport aus der Clientconfig übereinstimmen.

Das „Ipv4 Tunnel Network“ ist lediglich ein virtuelles Transfernetzwerk. Dieses darf sich nicht mit anderen vorhandenen Netzen schneiden.

Weiterhin wichtig ist das Setzen der IPv4 Remote networks, da ansonsten die Rück-Routen fehlen und keine Kommunikation stattfinden kann.

Das Shared Secret wird nach dem Speichern automatisch erstellt, wenn man anschließend wieder in die Konfiguration wechselt von dem neu erstellten OpenVPN Profil, so muss das Shared Secret auf dem Client ebenso in einer Datei (C:\Program Files\OpenVPN\pre_shared_key\site1.key) hinterlegt werden.

Client Config:

##########################
# VPN %Ziel%
##########################

dev tun

#Optional sofern separater Adapter genutzt wird
#dev-node "tap-vpn-name"

script-security 3
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256

#Lokale IP des Clients
local %local-ip%
lport 0

# Remote IP oder DynDNS Name
remote %remote-ip% 1199

# virtuelle-Ip Client gefolgt von IP des Gateways/OpenVPN Servers (virtuelle IP)
ifconfig 10.0.4.2 10.0.4.1

# Rück-Route, kann mehrfach gesetzt werden
route 192.168.178.0 255.255.255.0
secret "C:\\Program Files\\OpenVPN\\pre_shared_key\\site1.key"
comp-lzo adaptive
resolv-retry infinite

##########################
# Logging
##########################

status "C:\\Programme\\OpenVPN\\log\\site1.log"
log "C:\\Programme\\OpenVPN\\log\\site1.log"
log-append "C:\\Programme\\OpenVPN\\log\\site1.log"
verb 3

Bei dem Verbindungsaufbau sollte dann anschließend folgendes erkennbar sein in der PfSense unter „Status“ > „OpenVPN“

Die Verbindung sollte „up“ sein und Traffic muss erkennbar sein.

 

Hinweis: In jedem Falle prüfen, dass die entsprechenden Ports (VPN Port + diverse Ports welche man freigeben möchte, bspw. RDP 3389/TCP, …) auf beiden Seiten in den Firewall freigegeben sind.

Für einen Kunden war die Anforderung ein (Windows) System mittels eines VPNs abzusichern, das Ganze möglichst einfach und dennoch ohne Sicherheitsverlust.

Daher habe ich mich für den Einsatz von OpenVPN entschieden, da dieses OpenSource ist und eine große Bekanntheit hat.

 

1. Vorbereitung:

  • fertig installierter Windows 2016 Server
  • Download Community OpenVPN NSIS Package (https://openvpn.net/community-downloads/)

2. Installation OpenVPN Server:

Nachdem wir in der Vorbereitung die EXE Datei heruntergeladen haben, können wir diese installieren:

Übliche Willkommensmaske:

Bestätigen der Nutzungsbedingungen:

Auswahl der zu installierenden Komponenten. Hier sollte man noch den Punkt „EasyRSA 2“ auswählen.

Im nächsten Schritt wird der Installationordner ausgewählt:

Während der Installation muss man noch explizit die Installation eines virtuellen Netzwerkadapters freigeben.

Hinweis: Ohne entsprechende Berechtigung kann der Installer den Adapter nicht korrekt erstellen und eine VPN Verbindung ist nicht möglich!

Abschluss der Installation:

Nun haben wir OpenVPN installiert jedoch existieren noch keine Custom Keys oder Einstellungen welche die VPN Verbindung erst ausmachen.

 

3. Schlüsselpaare erstellen

In den folgenden Schritten werden folgende Keys bzw. Zertifikate erstellt:

  1. Einmalig: Certificate Authority (CA)  – build-ca.bat
  2. Einmalig: Diffie-Hellman Key – build-dh.bat
  3. Einmalig: Server Certificate – build-key-server.bat
  4. Pro Client ein Client Certificate – build-key.bat

Hinweis: Die Zertifikate bzw. Keys sind per Default 10 Jahre gültig. In dieser Zeit ist spätestens das Betriebssystem EOL, aus diesem Grunde vollkommen ausreichend.

Hierbei sollte man in den Easy-RSA Pfad wechseln in welchen OpenVPN installiert wurde ( C:\Program Files\OpenVPN\easy-rsa ). In diesem Ordner wird die vorhandene Datei vars.bat.example dupliziert oder nur umbenannt in „vars.bat“ und folgende Zeilen werden verändert bzw. hinzugefügt.

set KEY_COUNTRY=DE
set KEY_PROVINCE=RLP
set KEY_CITY=KOBLENZ
set KEY_ORG=MeineFirma AG
set KEY_EMAIL=kontakt@firma.tld
set KEY_CN=vpn.firma.tld
set KEY_NAME="Firmenname OpenVPN Key"
set KEY_OU="Abteilung"
set PKCS11_MODULE_PATH=platzhalter
set PKCS11_PIN=123456
set KEY_SIZE=2048

Die Werte sollten gesetzt werden, da es sonst zu Hinweis- als auch Fehlermeldungen kommen kann.

Ich habe bei der Schlüssellänge 2048 gewählt, da hier Sicherheit und Performance in einem guten Verhältnis stehen. Sofern man eine potente Hardware hat oder nur eine Verbindung aufbaut, kann man sich für 4096 entscheiden. Desto größer die Schlüssellänge desto länger dauert auch das Erstellen der jeweiligen Dateien!

Im Anschluss wird die „Arbeitsumgebung“ geladen:

Hinweis: Die Umgebung muss bei jeder neuen CMD Sitzung neu ausgeführt werden, da die Variablen sonst nicht gesetzt sind!

Um sicher zu gehen, dass alles sauber erstellt wird, lasse ich noch den Clean Job laufe. Dieser Schritt sollte bei einer Neuerstellung von einem Keypair oder bei einem Fehler in jedem Falle wiederholt werden!

Hinweis: Hierbei werden alle zuvor erstellten Keypairs gelöscht!

Erstellung Certificate Authority:

Erstellung Diffie-Hellman Key

Erstellung Server Certificate

In diesem Schritt muss man insbesondere das Signieren als auch das Erstellen des Zertifikates mit „y“ bestätigen:

Erstellung Client Certificate

Bei der Generierung des Client Certificates sollte man pro Client einen eigenen Namen wählen. Sollte man ein Zertifikat für mehrere Clients verwenden wollen, in den Default Settings würden sich die Clients immer gegenseitig aus der Sitzung werfen! Besser ist ein Zertifikat pro Client oder wenn es sein muss, wird der Parameter „duplicate-cn“ in der OpenVPN Konfig hinterlegt.

 

Überblick der Zertifikate:

Für den Client werden die folgenden Zertifikate benötigt:

  • ca.crt
  • client_%name%.crt
  • client_%name%.key

Die Server Files werden im folgenden Schritt beschrieben.

Alle anderen Dateien sollten unter keinen Umständen weitergegeben werden, da ansonsten die Sicherheit erheblich gefährdet ist.

4. Konfiguration OpenVPN Server:

Für den Server werden nun unter „C:\Program Files\OpenVPN“ noch weitere Ordner erstellt:

  • ccd
  • keys

Bei mir sieht es anschließend wie folgt aus:

Der Ordner „pre_shared_key“ ist zu ignorieren, dieser ist für ein Peer-to-Peer VPN (HowTo – LINK) erstellt worden.

Nun kopieren wir die zuvor erstellten Key und Zertifikate in den Ordner „keys“:

 

Optional:

Auf dem Kundensystem sollen zwei OpenVPN Instanzen laufen. Eine als Peer-to-Peer zu einem anderen OpenVPN Server und eine weitere als reiner OpenVPN Server für „normale“ Clients wie Windows 10, Android, iOS, …. Hierfür habe ich einen weiteren Tap Adapter erstellt, man kann nur eine Instanz pro Adapter betreiben.

Starten einer CMD mit Administratoren Berechtigung und anschließendes erstellen eines weiteren Adapters per OpenVPN „addtap.bat“.

Danach sollte der neue Adapter verfügbar sein und im Netzwerk Center bzw. per CMD sichtbar sein. Ich habe den Adapter umbenannt per „Umbennen“ in „tap-vpn-server“:

Man kann die Adapter auch per OpenVPN  Binary prüfen und schauen, ob diese verfügbar sind:

 

OpenVPN Server Konfig „C:\Program Files\OpenVPN\config\vpn_server_client.ovpn“

##########################
# VPN Server for clients
##########################

# Lokale IP auf welche der Socket/Port gebunden wird
local 89.22.112.244

#Listener des OpenVPN Servers
port 1194

#Protokoll des Servers
proto udp
dev tun
# Zuweisung auf separaten Adapter
dev-node "tap-vpn-server"

##########################
# Zertifikate
##########################

dh "C:\\Program Files\\OpenVPN\\keys\\dh2048.pem"
ca "C:\\Program Files\\OpenVPN\\keys\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\keys\\vpn_name.crt"
key "C:\\Program Files\\OpenVPN\\keys\\vpn_name.key"

##########################
# Server-Setup
##########################

# DHCP Subnetz
server 10.0.100.0 255.255.255.0
ifconfig-pool-persist "C:\\Program Files\\OpenVPN\\ipp.txt"

#Ermöglichen von Anfragen von einem Client zum anderen, bei Bedarf die Zeile entfernen
client-to-client

##########################
# Client-Settings (inkl Special Dir)Files
##########################

client-config-dir "C:\\Program Files\\OpenVPN\\ccd"
push "route 192.168.1.0 255.255.255.0"
#push "dhcp-option DNS 192.168.1.10"

##########################
# Defaults
##########################

keepalive 10 120
comp-lzo
persist-key
persist-tun

##########################
# Logging
##########################

status "C:\\Program Files\\OpenVPN\\log\\vpn_server_client_status.log"
log "C:\\Program Files\\OpenVPN\\log\\vpn_server_client.log"
log-append "C:\\Program Files\\OpenVPN\\log\\vpn_server_client.log"
verb 3

Der OpenVPN Server kann mittels „C:\Program Files\OpenVPN\bin\openvpn-gui.exe“ starten, gerade während der Einrichtung sollte man diese Option nutzen. So startet man die GUI und sieht die Fehlermeldungen direkt.

Später kann man den OpenVPNService nutzen. Dieser ist per Default vorhanden aber auf „Manuell“ gestellt, damit der Dienst automatisch verfügbar ist habe ich die Einstellung auf „Automatisch“ angepasst.

 

Tipp zum Prüfen ob der Socket existiert:

netstat -a | findstr 1194

So sollte die Ausgabe sein:

Ebenso sollte der Windows Firewall noch ein Eintrag bei den eingehenden Regel ergänzt werden für den gewählten Port (UDP/1194).

5. Installation Client

Für die Client-Installation unter Windows 10 kann man Schritt 2. unter Windows 10 wiederholen (die EasyRSA Tools müssen hier nicht mitinstalliert werden)

C:\Program Files\OpenVPN\config\vpn_client1.ovpn:

##########################
# VPN Client config
##########################

client
dev tun

proto udp
remote vpn.server.tld 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client_1.crt"
key "C:\\Program Files\\OpenVPN\\config\\client_1.key"
ns-cert-type server

comp-lzo
verb 3

 

So sollte es bei dem Verbindungsaufbau aussehen:

Hinweis: OpenVPN muss als Administrator oder mit einem User der die entsprechenden Berechtigungen (eines Netzwerkoperatoren) hat ausgeführt werden. Ansonsten schlägt der Verbindungsaufbau fehl.

Einleitung:

Zur privaten Weiterbildung habe ich mir den ELK Stack angesehen.

Was ist ELK und wofür steht es?

Im Grunde genommen ist es nicht ein Produkt sondern eine Sammlung aus mehreren Open-Source Produkten. Grob zusammengefasst:

Elasticsearch = Datenbank (NoSQL, Ansprechbar per RESTful)

Logstash = Ermöglicht Sammeln, Filtern und Anpassen von Datenströmen

Kibana = Visualisierung der gespeicherten/gesammelten Daten

1. Voraussetzungen

  • Debian 9
  • RAM: >= 8GB (läuft auch mit weniger, ggf. Anpassungen notwendig bei kleinen VMs
  •  

Hinweis für VMs mit wenig RAM:

/etc/elasticsearch/jvm.options

Anpassen der Java Memory Werte notwendig, da der Dienst sonst nicht startet

2. Update

apt-get update && apt-get -y dist-upgrade
apt-get install apt-transport-https software-properties-common wget telnet net-tools psmisc curl vim nginx

3. Vorbereitung

Um die ELK Komponenten zu installieren, sollte man das Anbieter eigene Repository nutzen. Alternativ kann man dieses auch manuell über die entsprechenden Downloads installieren. Insbesondere die automatischen Updates sprechen aber für den Paketmanager.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-6.x.list
apt-get update

Da Elasticsearch auf Java zurückgreift, muss dieses natürlich ebenso installiert werden.

apt-get install -y openjdk-8-jdk

Verifizierung der Java Version:

root@petyr:~/.vim/syntax# java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Laut diversen Foreneinträgen kann man auch Oracle Java nutzen, ich persönlich bevorzuge die „freie“ Variante. Ebenso müssen hierbei keine weiteren Repositories ergänzt werden.

 

4. Installation & Konfiguration Elasticsearch

Installation von Elasticsearch mittels Paketmanager:

apt-get install elasticsearch

Nach Abschluss der Installation sollte man den Listener beschränken auf localhost

/etc/elasticsearch/elasticsearch.yml
network.host: localhost

Aktivierung Autostart + Starten des Dienstes:

systemctl restart elasticsearch
systemctl enable elasticsearch

Funktionstest mittels curl Aufruf:

root@petyr:~/.vim/syntax# curl -X GET http://localhost:9200
{
  "name" : "V0PJlmj",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "OtdhYFIdQGiFakmd1c1arw",
  "version" : {
    "number" : "6.6.0",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "a9861f4",
    "build_date" : "2019-01-24T11:27:09.439740Z",
    "build_snapshot" : false,
    "lucene_version" : "7.6.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

5. Installation & Konfiguration Kibana

Installation von Elasticsearch mittels Paketmanager:

apt-get install kibana

Nach Abschluss der Installation sollte man den Listener beschränken auf localhost. Weitere Anpassungen wie bspw. ein Wunschname (server.name Parameter) sind möglich.

/etc/kibana/kibana.yml
server.host: "localhost"

Aktivierung Autostart + Starten des Dienstes:

systemctl restart kibana
systemctl enable kibana

Da wir Kibana auf den localhost beschränkt haben muss ein Webserver (nginx) als reverse Proxy eingerichtet werden. Dieser ermöglicht zum einen eine Authentifizierung einzelner Benutzer als auch mehr Möglichkeiten für die Zukunft (SSO, …). Die Installation erfolgte bereits im Schritt „Vorbereitung“.

 

Nun muss nur noch ein Benutzer erstellt werden:

echo "admin:$(openssl passwd -apr1 %Wunschpasswort%)" | sudo tee -a /etc/nginx/htpasswd.kibana
rm -f /etc/nginx/sites-enabled/default
vim /etc/nginx/sites-available/kibana

Inhalt der kibana-Datei:

server {
    listen 80 default_server;
    server_name _;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 default_server ssl http2;

    server_name _;

    ssl_certificate /etc/ssl/certs/localhost.crt;
    ssl_certificate_key /etc/ssl/private/localhost.key;
    ssl_session_cache shared:SSL:10m;

    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/htpasswd.kibana;

    location / {
        proxy_pass http://localhost:5601;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Damit der Webserver auch korrekt startet muss noch ein passendes Zertifikat erstellt werden:

mkdir /root/localhost_cert
cd /root/localhost_cert
vim localhost.conf

Inhalt Zertifikats-Template (localhost.conf)

[req]
default_bits       = 2048
default_keyfile    = %NAME%.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions    = v3_ca

[req_distinguished_name]
countryName                 = Country Name (2 letter code)
countryName_default         = %LÄNDER-KÜRZEL%
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = %B-LAND%
localityName                = Locality Name (eg, city)
localityName_default        = %ORT%
organizationName            = Organization Name (eg, company)
organizationName_default    = %ORGANISATION%
organizationalUnitName      = organizationalunit
organizationalUnitName_default = %ABTEILUNG%
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_default          = %WEBADRESSE%
commonName_max              = 64

[req_ext]
subjectAltName = @alt_names

[v3_ca]
subjectAltName = @alt_names

[alt_names]
DNS.1   = localhost
DNS.2   = 127.0.0.1

Erstellung des eigentlichen Zertifikats samt Key:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -config localhost.conf

Kopieren der Dateien an die richtige Stelle, aktivieren der Konfiguration und starten des Webservers:

cp localhost.crt /etc/ssl/certs/localhost.crt
cp localhost.key /etc/ssl/private/localhost.key
ln -s /etc/nginx/sites-available/kibana /etc/nginx/sites-enabled/kibana
systemctl enable nginx
systemctl restart nginx

6. Installation & Konfiguration Logstash

Installation von Logstashmittels Paketmanager:

apt-get install logstash

Aktivierung Autostart + Starten des Dienstes:

systemctl restart logstash
systemctl enable logstash

Jetzt kann man mittels eines Browser auf Kibana zugreifen:

 

 

VIM Template 

mkdir ~/.vim/syntax
cd ~/.vim/syntax
wget https://www.vim.org/scripts/download_script.php?src_id=22309 -O logstash.vim.zip
unzip logstash.vim.zip
wget http://www.vim.org/scripts/download_script.php?src_id=19394 -O nginx.vim

 

 

 

UPDATE Kopano mit Debian 10 

Einleitung:

Die letzten Jahre habe ich Kolab unter Debian Wheezy (7) als Groupware genutzt. Ich hatte mich für Kolab entschieden, da ich eine einfache Lösung wollte welche alle Grundfunktionen einer Groupware vereint. Damals hatte ich diverse Lösungen (SoGo, Tine, ….) getestet . Entweder bestanden die Installationen aus sehr vielen Bestandteilen welche häufig manuell installiert werden mussten und/oder die Konfiguration war sehr umfangreich – neben diversen anderen Nachteilen . Dank der Opensource Vielfalt und vielen fertigen Teillösungen kann man sich auch selbst eine Groupware zusammen konfigurieren, dann lohnt sich auch die investierte Zeit. Eine „Schlüsselfertig“ Groupware sollte daher möglichst einfach installierbar sein, gute Standard-Einstellungen mitbringen und nach Möglichkeit individuell anpassbar sein. Somit fiel die Wahl (damals) auf Kolab, mit etwas Einarbeitung stand auch zügig das System. Über den integrierten LDAP Server als Datenbasis kann man streiten, für mich aber okay. Letztlich muss nun wieder eine Alternative her, für Kolab gibt es nicht wirklich Updates und die Winterfell Version ist meiner Meinung nach mehr eine Beta Version. Das angekündigte Kolab Release war ursprünglich für Q1/2017 angekündigt und wurde mittels Kolab 18 auf Q1/2018 „verschoben“. De facto gibt derzeit kein aktuelles Kolab, lediglich eine ältere Version unter Debian 8. Mal ganz abgesehen von den vielen kleinen Fehlern innerhalb der Installation oder auch danach.

Was ist eine Alternative?

Nach einiger Suche wurde ich auf Kopano aufmerksam.Die Key-Features klingen gut, die Optik passt. Somit stand einer Test-VM nicht mehr im Weg. Leider gibt es derzeit keine fertigen Pakete innerhalb eines Repositories für die Community Variante. Die Pakete sind im Subscription Modell enthalten. Laut einer Ankündigung soll das kommende Debian Buster (10) – Release wohl Sommer 2019 – die Pakete beinhalten. Im Testing-Zweig sind die Pakete zumindest schon mal gelistet. Bis dahin installiere ich es lieber manuell unter einem LTS OS.

Wer wie ich die Komponente(n) manuell installieren möchte, sollte sich den Download Bereich einmal ansehen von Kopano. Hier findet man alle nötigen Pakete innerhalb von Nightly-Build-Archiven.

Die Installation:

Für den Anfang wird eine Debian Grundinstallation vorgenommen. Es gibt auch die Möglichkeit, eine andere Distribution zu nutzen wie bspw. Ubuntu, RHEL, SLES, OpenSuse und Weitere.

1. LAMP & Nützliche Tools

Nach Absenden des folgenden Befehls dem Menü folgen und „Apache2“ im Dialogmenü auswählen. Im Dialog bezüglich des PhpMyAdmin ist die Option „dbconfig-common“ auszuwählen.

root@mail:~#apt-get update && apt-get install -y apache2 mysql-server phpmyadmin postfix

2. Nützliche Tools & Absicherung

root@mail:~# apt-get install -y vim telnet wget w3m apt-transport-https net-tools mlocate vim && updatedb

Absicherung Webserver

Folgende Zeilen innerhalb der /etc/apache2/conf-available/security.conf anpassen.

ServerTokens Prod
ServerSignature Off
Header set X-Content-Type-Options: "nosniff"
Header set X-Frame-Options: "sameorigin"

Dies gibt Angreifern weniger Informationen über den Server und somit erhöht sich der Aufwand für eine erfolgreiche Serverübernahme. Zusätzliche aktiviere ich das Apache Module und starte den Dienst neu, damit die Konfiguration übernommen wird.

root@mail:~# a2enmod headers && systemctl restart apache2

Absicherung MySQL / MariaDB Datenbankserver

Setzen des Datenbank root Kennwortes sowie entfernen unnötiger Einträge. Im darauf folgenden Dialog können jeweils die Default „Y“ (YES) übernommen werden.

root@mail:~# mysql_secure_installation

Zwischenpprüfung

Bis hierin sollten keine Fehlermeldungen auf der Konsole zu finden sein. Wenn alles richtig gemacht wurde dürften die folgenden Prozesse (apache2 & mysqld) existieren

root@mail:~# pstree
systemd─┬─agetty
        ├─apache2───10*[apache2]
        ├─cron
        ├─dbus-daemon
        ├─mysqld───26*[{mysqld}]
        ├─rsyslogd─┬─{in:imklog}
        │          ├─{in:imuxsock}
        │          └─{rs:main Q:Reg}
        ├─sshd───sshd───bash───pstree
        ├─systemd───(sd-pam)
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-timesyn───{sd-resolve}
        └─systemd-udevd

Zusätzlich muss unter http://%IP-Adresse%/phpmyadmin die GUI von phpMyAdmin erreichbar sein. Beispiel:

Der Login wird jedoch fehlschlagen, da mit der neuen MariaDB Version auf eine weitere Authentifizierung „unix-socket“ zurückgegriffen wird. Hierbei kann man sich mit einem entsprechendem User direkt ohne Passwort innerhalb der Konsole einloggen. Im Folgenden der Befehl um das gewohnte Verhalten zu erzwingen:

root@mail:~# mysql -u root -p -e "update mysql.user set plugin='' where User='root';"

Installation Kopano

Wie bereits erwähnt findet man die Archive unter https://download.kopano.io/community/, hierbei muss man die folgenden Download-URLs entsprechend des derzeit aktuellen Paketes anpassen. Weiterhin muss man diverse Abhängigkeiten während der Installation „nachziehen“, da sonst die Installation nicht möglich ist. Dank Paketmanager aber eine einfach Aufgabe.

root@mail:~# mkdir kopano_temp
root@mail:~# cd kopano_temp/
root@mail:~/kopano_temp# wget https://download.kopano.io/community/core:/core-8.6.80.1248_0%2B176-Debian_9.0-amd64.tar.gz
root@mail:~/kopano_temp# wget https://download.kopano.io/community/files:/files-2.1.4.286-Debian_9.0-all.tar.gz
root@mail:~/kopano_temp# wget https://download.kopano.io/community/mdm:/mdm-2.1.0.102%2B23-Debian_9.0-all.tar.gz
root@mail:~/kopano_temp# wget https://download.kopano.io/community/webapp:/webapp-3.4.17.1630%2B928-Debian_9.0-all.tar.gz

Installation Core-Paket

root@mail:~/kopano_temp# tar xfz core-*.tar.gz
root@mail:~/kopano_temp# cd core-8.6.80.1248_0+176-Debian_9.0-amd64/
root@mail:~/kopano_temp/core-8.6.80.1248_0+176-Debian_9.0-amd64# dpkg -i *.deb
root@mail:~/kopano_temp/core-8.6.80.1248_0+176-Debian_9.0-amd64# apt-get install -f
root@mail:~/kopano_temp/core-8.6.80.1248_0+176-Debian_9.0-amd64# dpkg -i *.deb
root@mail:~/kopano_temp/core-8.6.80.1248_0+176-Debian_9.0-amd64# cd ..

Nun sollten keine Abhängigkeiten mehr fehlen, abgesehen von „libjansson-doc“. Dies vernachlässige ich jedoch, da es sich hierbei lediglich um eine Dokumentation handelt.

Installation Webapp-Paket

root@mail:~/kopano_temp# tar xfz webapp-*.tar.gz
root@mail:~/kopano_temp# cd webapp-3.4.17.1630+928-Debian_9.0-all
root@mail:~/kopano_temp/webapp-3.4.17.1630+928-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/webapp-3.4.17.1630+928-Debian_9.0-all# apt-get -f install
root@mail:~/kopano_temp/webapp-3.4.17.1630+928-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/webapp-3.4.17.1630+928-Debian_9.0-all# cd ..

Installation Files-Paket

root@mail:~/kopano_temp# tar xfz files-*.tar.gz
root@mail:~/kopano_temp# cd files-2.1.4.286-Debian_9.0-all/
root@mail:~/kopano_temp/files-2.1.4.286-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/files-2.1.4.286-Debian_9.0-all# apt-get install -f
root@mail:~/kopano_temp/files-2.1.4.286-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/files-2.1.4.286-Debian_9.0-all# cd ..

Installation MDM-Paket

root@mail:~/kopano_temp# tar xfz mdm-*.tar.gz
root@mail:~/kopano_temp# cd mdm-2.1.0.102+23-Debian_9.0-all/
root@mail:~/kopano_temp/mdm-2.1.0.102+23-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/mdm-2.1.0.102+23-Debian_9.0-all# apt-get install -f
root@mail:~/kopano_temp/mdm-2.1.0.102+23-Debian_9.0-all# dpkg -i *.deb
root@mail:~/kopano_temp/mdm-2.1.0.102+23-Debian_9.0-all# cd ..

Installation Z-Push:

Für Kopano ist Z-Push eine Voraussetzung.

root@mail:~/kopano_temp# wget -qO - http://repo.z-hub.io/z-push:/final/Debian_9.0/Release.key | apt-key add -
OK
root@mail:~/kopano_temp# echo "deb http://repo.z-hub.io/z-push:/final/Debian_9.0/ /" | tee /etc/apt/sources.list.d/z-push.list
deb http://repo.z-hub.io/z-push:/final/Debian_9.0/ /
root@mail:~/kopano_temp# apt-get update
root@mail:~/kopano_temp# apt-get install z-push-kopano z-push-config-apache -y
root@mail:~/kopano_temp# z-push-admin -a fixstates

Nun wird noch das SSL Modul aktiviert, der https vHost aktiviert und die php.ini bearbeitet. Hierbei sollte man den Wert von „session.cookie_httponly“ (bei mir Zeile 1386) auf den Bool-Wert „true“ setzen, optional kann man noch „date.timezone = „Europe/Berlin“ hinterlegen. Wie gehabt im Anschluss den Dienst neustarten.

root@mail:~/kopano_temp# a2enmod ssl
root@mail:~/kopano_temp# a2ensite default-ssl.conf
root@mail:~/kopano_temp# vim /etc/php/7.0/apache2/php.ini
root@mail:~/kopano_temp# systemctl restart apache2

Optional: LetsEncrypt Zertifkat

Dank Letsencrypt kann jeder kostenfreie öffentliche Zertifikate nutzen. Innerhalb der Webserver-Konfig wird noch der FQDN gesetzt im Parameter „ServerName, ansonsten erkennt der Certbot den vHost nicht korrekt.

root@mail:~/kopano_temp# echo "deb http://ftp.debian.org/debian stretch-backports main" >> /etc/apt/sources.list
root@mail:~/kopano_temp# apt-get update
root@mail:~/kopano_temp# apt-get install python-certbot-apache -t stretch-backports -y
root@mail:~/kopano_temp# vim /etc/apache2/sites-enabled/000-default.conf
root@mail:~/kopano_temp# systemctl restart apache2
root@mail:~/kopano_temp# certbot --apache

 

Anschließend ist die Webseite bzw. GUI unter https://%IP-Adresse%/webapp erreichbar. Beispiel?

Der Screenshot wurde vor LetsEncrypt erstellt, daher ist auch das Zertifikat nicht vertrauenswürdig.

Eine wirkliche Funktion ist bis hierhin nicht gegeben, da das komplette Backend, die Datenbank fehlt. Hierzu werden wir einen Benutzer „kopano-user“ mit dem zugehörigen Kennwort „GEHEIM“ erstellen samt Datenbank „kopano“.

root@mail:~/kopano_temp# mysql -u root -p -e "CREATE USER 'kopano-user'@'localhost' IDENTIFIED BY 'GEHEIM';GRANT USAGE ON *.* TO 'kopano-user'@'localhost'; CREATE DATABASE kopano;GRANT ALL PRIVILEGES ON kopano.* TO 'kopano-user'@'localhost';flush privileges;"

Im nächsten Schritt werden die soeben erstellten Daten genutzt indem die Konfigurationsdatei angepasst wird

root@mail:~/kopano_temp# gunzip -c /usr/share/doc/kopano/example-config/server.cfg.gz > /etc/kopano/server.cfg
root@mail:~/kopano_temp# vim /etc/kopano/server.cfg

Meine Konfiguration sieht wie folgt aus:

Damit Kopano die Änderung auch erfasst und die Tabellenstruktur erstellt ist ein Neustart des Dienstes notwendig. Anschließend wird noch der erste Benutzer für Kopano selbst erzeugt.

root@mail:~/kopano_temp# systemctl restart kopano-server.service
root@mail:~/kopano_temp# kopano-admin -c thuerter -p 123456 -e noreply@huerter.me -f "Tim Hürter" -a1
User created.

Bug in der aktuellen Version: Der Mail-Store muss manuell erstellt werden, dieser sollte in wenigen Tagen (Stand: 15.07.2018) behoben werden.

 

Konfiguration Mobile Device Management (MDM)

root@mail:~/kopano_temp# hostname -f
mail.genx-dev.de
root@mail:~/kopano_temp# vim /etc/kopano/webapp/config-mdm.php

Die aufgerufene config-mdm.php sollte wie folgt bearbeitet werden. Hierbei ist der FQDN (hostname -f) entsprechend zu setzen

<?php
define('PLUGIN_MDM_USER_DEFAULT_ENABLE_MDM', false);
define('PLUGIN_MDM_SERVER', 'mail.genx-dev.de');
define('PLUGIN_MDM_SERVER_SSL', false);
?>

Kopano dagent & Postfix:

Kopano hat einen eigenen MTA Agent. Hierbei wird der Agent im MTA (bspw. Postfix) integriert mittels LMTP.

root@mail:~/kopano_temp# gunzip -c /usr/share/doc/kopano/example-config/dagent.cfg.gz > /etc/kopano/dagent.cfg

Hinweis, möglicherweise ist folgende Anpassung notwendig, sofern der Dienst nicht gestartet wird, Zeile ~75 der dagent.cfg. Mit der Default-Konfig wurde der Dienst nicht gestartet und entsprechend war der Port nicht verfügbar. Bug Link

lmtp_listen = [::1]:2003 127.0.0.1:2003
lmtp_port = 2004
root@mail:~# systemctl status kopano-dagent.service
● kopano-dagent.service - Kopano Core Delivery Agent
   Loaded: loaded (/lib/systemd/system/kopano-dagent.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-07-11 22:33:21 CEST; 3min 4s ago
     Docs: man:kopano-dagent(8)
           man:kopano-dagent.cfg(5)
 Main PID: 1166 (kopano-dagent)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/kopano-dagent.service
           └─1166 /usr/sbin/kopano-dagent -l

Jul 11 22:33:21 mail systemd[1]: Started Kopano Core Delivery Agent.
Jul 11 22:33:21 mail kopano-dagent[1166]: Starting kopano-dagent version 8.6.80 (pid 1166) (LMTP mode)
root@mail:~# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      107        12170      860/mysqld
tcp        0      0 127.0.0.1:2003          0.0.0.0:*               LISTEN      0          15527      1166/kopano-dagent
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          12015      736/sshd
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          12798      963/master
tcp6       0      0 :::80                   :::*                    LISTEN      0          12052      862/apache2
tcp6       0      0 ::1:2003                :::*                    LISTEN      0          15528      1166/kopano-dagent
tcp6       0      0 :::22                   :::*                    LISTEN      0          12017      736/sshd
tcp6       0      0 :::25                   :::*                    LISTEN      0          12799      963/master
tcp6       0      0 :::443                  :::*                    LISTEN      0          12056      862/apache2

Feinschliff & Abschluss

Sofern alle Dienste laufen, sollte man unbedingt den Autostart aktivieren.Zu guter Letzt wird noch der Installationsordner entfernt.

root@mail:~/kopano_temp# systemctl enable kopano-dagent kopano-gateway kopano-ical kopano-monitor kopano-presence kopano-search kopano-server kopano-spooler
root@mail:~/kopano_temp# cd ..
root@mail:~# rm -rf kopano_temp

Wenn Kolab es mal geschafft hat Version 18 zu veröffentlichen, welches übrigens schon seit Q1/2018 released sein soll, wäre es evtl. einen Blick wert. Vermutlich wird dann aber Kopano Mitte 2019 dank Debian 10 und besseren Updates durch das Repository die bessere Wahl sein.ABER, erstmal in Ruhe alle Kopano Funktionen testen.

 

Viel Erfolg beim eigenen Setup.

Für meine Datensicherung nutze ich „tar„, eines der meist genutzten Programme zum erstellen von Archiven. Dank der weiten Verbreitung ist das Tool zumeist mit den meisten Distributionen vorinstalliert.Per Default ist es aber recht langsam und nutzt nicht wirklich die Leistung des Systems. Grund hierfür ist die fehlende Multithreading Unterstützung.

 

Im konkreten möchte ich einen Samba Share innerhalb einer KVM-VM sichern. In diesem sind alle möglichen Arten von Dateien (Programme, Datenbanken, Scripte, PDFs, TXTs, Videos, …) vorhanden.

Die vorhandenen 22 GB Daten verteilen sich auf rund 90.000 Dateien. Für die Erstellung des Archivs stehen innerhalb der VM 1GB RAM sowie 2 virtuelle CPU Cores zur Verfügung vom KVM Hostsystem (Intel Xeon CPU E3-1240L v5 @ 2.10GHz, 16 GB DDR4 ECC 2133MHz, RAID1 über WD20EFRX-68EUZN0) bereit.

Top 15 Dateitypen zur Veranschaulichung:

root@catelyn:/storage_data/folder# find . -type f | sed -n 's/..*\.//p' | sort | uniq -c | sort -nr | head -n 15
  27511 jpg
  11864 php
  11345 png
  10867 html
   4623 gif
   4472 js
   2321 pdf
   1697 css
   1382 bmp
   1337 ini
   1307 JPG
   1278 xml
   1258 txt
    855 docx
    771 htm

Die Tools können alle mittels des jeweiligen Paketmanagers (yum, apt etc.) installiert werden.

 

Typ Befehl Zeit Größe in MB Kompression
null Reine Ordner/Dateigröße 0 21949 0
tar tar cf backup_plain.tar ../folder 7m22.590s 21736 0,97%
tar compress tar czf backup_compress.tar.gz ../folder/ 16m8.776s 18387 16,23%
pigz tar -I pigz -cf backup_pigz.tar.gz ../folder/ 9m43.084s 18392 16,21%
pbzip2 tar -I pbzip2 -cf backup_pbzip2.tar.bz2 ../folder/ 28m33.028s 17898 18,46%
pxz tar -I pxz -cf backup_pxz.tar.xz ../folder/ 82m30.024s 17325 21,07%
zip zip -r backup ../folder/* 17m16.504s 18464 15,88%

Meine persönliche Wahl fällt auf pigz, da hier Kompression und Rechenzeit in einem guten Verhältnis stehen.

 

Wenn reine Dokumente gesichert werden, würde ich den Test nochmals wiederholen. Der durchgeführte Test bezieht sich auf viele verschiedene Dateitypen welche teilweise bereits komprimiert waren.