Eigener Server für Kalender und Kontakte

Kalender und Kontakte sollten auf allen Geräten, sei es mobil oder stationär, abrufbar und synchron sein. Das spricht dafür, dass sie über Netzwerk oder sogar das Internet abgeglichen werden. Müssen diese sensiblen Daten aber gleich in der Cloud eines großen Anbieters wie Google und Co landen?

Wenn man dies nicht will, bieten sich Lösungen auf CalDav– und CardDav-Technologie an. Beide Protokolle setzen auf WebDAV nach RFC 4918 auf. CalDAV synchronisiert Kalenderdaten nach RFC 4791, CardDav hingegen Kontakte nach RFC 6352.

Bei der Auswahl des Servers für beide Protokolle hat man viel Auswahl. Die Wikipedia bietet eine Aufstellung von Möglichkeiten.

Server einrichten

Für den Server habe ich ich mich für Radicale entschieden. Zusätzlich soll als Frontend InfCloud verwendet werden um auch mit dem Browser von beliebigen Endgeräten auf die Kalender und Adressen zugreifen zu können.

Thomas Queste hat mit dem Docker Image tomsquest/docker-radicale eine einfache Möglichkeit geschaffen, diese Software zu verwenden.

Zunächst legt man Verzeichnisse an:

  • /data/cal/config – für die Konfigurationsdatei und die Datei mit den Nutzern
  • /data/cal/data – für die eigentlichen Kalender- und Adress-Daten

An Konfigurationsdateien benötigt man die Datei /data/cal/config/config mit folgendem Inhalt:

[server]
hosts = 0.0.0.0:5232

[encoding]

[auth]
type = htpasswd
htpasswd_filename = /config/users
htpasswd_encryption = bcrypt

[rights]

[storage]
filesystem_folder = /data/collections

[web]
type = radicale_infcloud

[logging]

[headers]

Die Datei /data/cal/config/users wird mit den üblichen Tools zur Verwaltung von .htaccess-Dateien modifiziert: htpasswd. Wichtig ist mit der obigen Konfiguration der Parameter -B zur Aktivierung der bcrypt-Verschlüsselung:

htpasswd -B /data/cal/config/users $username

Anschließend muss der Docker-Container angelegt und ausgeführt werden:

docker run \
    -d \
    --name radicale \
    -p 5323:5232 \
    -v ~/tmp/cal_data:/data \
    -v ~/tmp/cal_config:/config:ro \
    tomsquest/docker-radicale

Natürlich sollte man im produktiven Einsatz eine TLS-gesicherte Verbindung auf Port 443 verwenden!

Wenn alles funktioniert sollte man unter http://localhost:5232/.web auf die Weboberfläche von Radicale zugreifen können. Als Logins dienen die Accounts, die in der Datei users angelegt wurden. Dort kann man nun alle benötigten Collections, wie Adressbücher, Kalender und Aufgabenlisten anlegen.

Clients

Clients wurden für eine möglichst große Anzahl von Plattformen untersucht.

Browser

InfCloud (in Version 0.13.1) läuft laut Hersteller in allen HTML5 fähigen Browsern wie Safari/Mobile Safari, allen Webkit-basierten, iCab, Firefox, Opera (15+) und Chrome. Zugegriffen werden kann auf InfCloud unter http://localhost:5232/.web/infcloud/.

iOS

Funktioniert direkt ohne weitere Software, was mich positiv überraschte.

Unter EinstellungenAccounts & Passwörter → Account hinzufügen → Andere → CalDAV-Account hinzufügen konfiguriert man den Zugriff auf die Kalender:

Server ist hier der Hostname, unter der Radicale zu erreichen ist. Benutzername und Passwort sind wie in der Users-Datei angegeben und die Beschreibung ist ein beliebiger Text.

Analog verfährt man mit dem Einbinden der Adressbücher. Unter EinstellungenAccounts & Passwörter → Account hinzufügen → Andere → CardDAV-Account hinzufügen konfiguriert man den Zugriff auf die Adressbücher. Die Werte sind analog zu denen bei den Kalendern.

Android

Google macht es uns bei Android etwas schwerer, man will wohl die eigene Cloud mal wieder pushen.

Aber mit CalDAV Sync Free Beta erhält man eine Open-Source Software, die weiterhilft. Ist die Software installiert, so kann man unter EinstellungenKonten → Konto hinzufügen mit der Option CalDav Sync Adapter den Zugang zu den Kalendern einrichten.

Der Benutzer und das Passwort sind die Werte, die auch für das Login in InfCloud verwendet werden. Die URL findet man in der Web-UI von Radicale und sollte einfach per Mail auf das Android Gerät kopiert werden. Anschließend findet man unter EinstellungenKonten → CalDav Sync Adapter den neu eingerichteten Kalender und muss bei diesen noch die Synchronisierung aktivieren:

Jetzt sollte der eingerichtete Kalender in der Kalender App eingebunden sein.

Kontaktdaten via CardDav können ebenso nur mit Zusatzsoftware eingebunden werden. Hier CardDAV-Sync free eine kostenlose Option, die leider nicht frei (wie in freier Software) ist. Auch hier muss man wieder die komplette URL aus der Radicale Web-UI verwenden (analog zur Lösung für CalDAV-Daten). Anschließend können Kontakte zwischen Radicale synchronisiert werden und auch auf dem Android Gerät wie gewohnt erstellt werden.

Desktop

macOS

Unter macOS gibt es, wie unter iOS auch, die Möglichkeit direkt mit Bordmitteln auf Adress- und Kalenderdaten zuzugreifen. In den Einstellungen gibt es Optionen sowohl für CalDAV als auch für CardDAV.

Die Einrichtung findet analog zu iOS statt (hier sieht man inwieweit iOS und macOS sich gleichen).

Linux/Windows

Hier kann Thunderbird mit den beiden Add-ons Lightning (getestet in Version 6.2) und CardBook (getestet in Version 31.2) alle notwendigen Funktionen bereitstellen.

Lightning konfigurieren

Hier wählt man beim Anlegen eines neuen Kalenders die Option Im Netzwerk und als Format CalDAV. Auch hier muss man die URL des Kalenders aus der Web-UI von Radicale entnehmen und einfügen. Anschließend definiert man einen lokalen Namen und legt eine Farbe fest. Im Authentifizierungsdialog trägt man Nutzernamen und Passwort ein. Die Authentifizierung muss pro Server nur einmal vorgenommen werden.

CardBook konfigurieren

Beim Anlegen eines neuen Adressbuches wiederum die Option Im Netzwerk und als Format CardDAV. Dann kopiert man erneut die URL des Adressbuchs und authentifiziert sich. Wichtig das vCard-Format muss auf 3.0 geändert werden! Ansonsten können die erstellten vCards nicht auf allen Clients (z.B. InfCloud) bearbeitet werden.

Windows 10

Unter Windows 10 kann man sich mit folgendem Trick behelfen: https://www.ctrl.blog/entry/how-to-win10-webdav-syncengine (Allerdings ohne Garantie für zukünftige Updates).

 

Probleme mit Windows Update KB3033929 (SHA2 Einführung)

Auch bei meinem Desktop hat KB3033929 zu Problemen geführt. Windows 7 befindet sich auf der ersten Festplatte, Linux auf der zweiten. Natürlich wird Grub zum Booten verwendet. Leider befand sich kein Windows Boot Loader mehr auf keiner der beiden Platten.

Woher bekommt man jetzt wieder ein direkt bootfähiges Windows 7?

  1. Die meisten Webseiten empfehlen die Windows 7 Installations Medien zu verwenden um das System zu reparieren. Gut, müsste man suchen und die richtigen Medien erwischen. Meine war “inkompatibel”.
  2. Diverse Linux-Tools wie install-mbr führten auch nicht zum Erfolg.
  3. Zum Glück konnte ich das Windows noch starten und das Programm EasyBCD installieren. Wie auf der Hersteller Web-Seite beschrieben, kann das Tool einen Windows 7 MBR schreiben.

Nach dem Anwenden von EasyBCD kann das Windows wieder nativ von der ersten Festplatte gestartet werden und ebenso von der zweiten Festplatte via Grub.

Problem gelöst!

Apache Maven – Launch4j Integration

Im 5ten Teil der Serie über Maven (Teil 1, Teil 2, Teil 3, Teil 4 – Teil 4 wird für diesen Teil allerdings nicht benötigt, kann also überlesen werden) soll gezeigt werden, wie wiederum Maven genutzt werden kann, um automatisiert im Build-Prozess direkt ausführbare Dateien für Windows (exe) erzeugt werden können.

Launch4j

Launch4j ist ein plattform-übergreifendes Werkzeug zur Erstellung von ausführbaren EXE-Dateien für Windows. Für einmale Aktionen und zum Üben bietet Launch4j eine GUI an, diese eignet sich aber nicht zur Integration in einen Build-Prozess. Hier kann uns Maven wieder helfen.

Erweiterung der pom.xml

Zunächst muss ein (zusätzliches) pluginRepository eingebunden werden. Das Tag pluginRepositories wird nur benötigt, wenn es noch nicht vorhanden war.

<pluginRepositories>
    <pluginRepository>
        <id>launch4j-xml-plugin-repo</id>
        <name>launch4j-xml-plugin Repository for Maven</name>
        <url>
            https://launch4j-xml-plugin.googlecode.com/svn/repo
        </url>
    </pluginRepository>
</pluginRepositories>

Anschließend wird wie in Teil 3 der Build-Prozess angepasst. Dazu wird unter /project/build/plugins (dem XPath folgen) folgendes zusätzliche Plugin eingetragen. Es wird davon ausgegangen, dass

  • ein ausführbares JAR-File vorliegt
  • und dieses muss unter plugin/executions/execution/configuration/jar (XPath) angegeben werden

Die gewünschte Ergebnisdatei wird unter plugin/executions/execution/configuration/outfile (XPath) angegeben.

<plugin>
    <groupId>org.bluestemsoftware.open.maven.plugin</groupId>
    <artifactId>launch4j-plugin</artifactId>
    <version>1.5.0.0</version>
    <executions>
        <execution>
            <id>l4j-gui</id>
            <phase>package</phase>
            <goals>
                <goal>launch4j</goal>
            </goals>
            <configuration>
                <headerType>gui</headerType>
                <outfile>target/MouseMover.exe</outfile>
                <jar>target/MouseMover-0.0.1.jar</jar>
                <errTitle>MouseMover Error</errTitle>
                <icon>src/main/resources/mm.ico</icon>
                <jre>
                    <minVersion>1.5.0</minVersion>
                    <maxVersion>1.6.0</maxVersion>
                    <initialHeapSize>128</initialHeapSize>
                    <maxHeapSize>1024</maxHeapSize>
                </jre>
                <versionInfo>
                    <fileVersion>1.0</fileVersion>
                    <txtFileVersion>1.0</txtFileVersion>
                    <fileDescription>Desc</fileDescription>
                    <copyright>C</copyright>
                    <productVersion>1.0</productVersion>
                    <txtProductVersion>1.0</txtProductVersion>
                    <productName>MouseMover</productName>
                    <internalName>MouseMover</internalName>
                    <originalFilename>
                        MouseMover.exe
                    </originalFilename>
                </versionInfo>
            </configuration>
        </execution>
    </executions>
</plugin>

Nach dem nächsten Build steht euch dann an der angegebenen Stelle eine EXE (hier MouseMover.exe) zur Verfügung. Das klappt zum Glück nicht nur unter Windows, sondern auch unter Linux und Mac OS X. Aber das war auch auf der Homepage von Launch4j so angegeben.

Résumé

Launch4j ermöglicht in Verbindung mit Maven das Erstellen von EXE-Dateien ohne große Probleme. So kommen Windows-Nutzer in den Genuss direkt ausführbarer Java-Programme.

Downloads

Das Testprojekt findet sich hier und die enstandene EXE hier.

Update 6. Juni 2018

Die Quellen zu diesem Artikel findet man jetzt unter https://git.lusiardi.de/jlusiardi/MouseMover. Leider scheint der Build aktuell nicht möglich.

Fernwartungskarten Teil 2

Mal wieder traten die Fernwartungskarten (namentlich unsere Drac5) negativ in Erscheinung. Das Problem diesmal wurde zwar höchstwahrscheinlich durch ein Update auf Windows-Seite ausgelöst, bestand aber nur für die Drac5 Karten. Diese können in den uns vorliegenden (zugegebenermassen etwas älteren) Version 1.33 nur über ein Active-X Plugin auf KVM-Ebene angesprochen werden.

Unter Windows 7 ist im Startmenu der Internet Explorer 2 mal zu finden:

  • Internet Explorer 64bit
  • Internet Explorer

Man könnte ja nun annehmen, der Internet Explorer ohne Bit-Angabe wäre 32bit, oder? War er eventuell auch, nach dem erwähnten Update ist er es jedoch sicher nicht mehr. Man erhält unter beiden Punkten einen 64-bit IE. Will man dort auf die KVM-Konsole der Drac5 per Active-X zugreifen, so scheitert dies ohne klare Fehlermeldung. Es geht halt einfach nicht.

Die Lösung, auf die weder unsere Firmen-Windows-Admins noch der Dell-Premium-Support kamen, ist der Internet Explorer (mit 32 bit!)   direkt aus dem Programmverzeichnis der X86-Anwendungen zu starten. Dort können die benötigten Active-X Plugins dann wieder problemlos ausgeführt werden.

Für die Lösung des Problems danke ich Stefan C.!

Testaccount für vServer (Linux, Windows)

United Hoster vergibt gerade Testaccounts für vServer mit

  • Linux,
  • Windows 2003 oder
  • Windows 2008 R2

Unter folgender Adresse können die vServer bestellt werden: http://united-hoster.com/vserver-testaccount.html

Nach der Anmeldung kam bei mir am nächsten Tag eine eMail mit den Zugangsdaten an die angegebene Mail-Adresse. Der vServer ist mit 5 GB Festplatte, 512 MB Ram recht knapp ausgestattet. Aber, hey, ist ja gratis.

 

Fernwartungskarten sind für die Administrationsarbeit unerlässlich…

Zur Fernwartung von Servern in Rechenzentren setzt man auf Fernwartungskarten. In Systemen der Firma Dell sind das die iDRAC Karten.

Zu tun hatte ich bisher mit Version 5 (iDRAC5) und 6 (iDRAC6).

Beide bieten den Zugriff auf eine Konsole, die Möglichkeit virtuelle DVDs einzulegen, den Rechner zu resetten und vieles mehr.

iDRAC5 setzt dazu in einer früheren Version auf ein ActiveX Plugin, was eine Verwendung nur im Internet Explorer erlaubt. Das Einbinden der virtuellen Medien funktioniert nicht wirklich zuverlässig.

Anders hingegen bei iDRAC6: Eine wirklich stark verbesserte Oberfläche, Konsole und virtuelle Medien funktionieren über Java und somit nicht mehr nur im Internet Explorer. Auch eine komplette Installation eines Betriebssystems war nun problemlos möglich. Bei der älteren iDRAC5 war dann eher ein Besuch im Rechenzentrum angesagt.