Zertifikatseigenschaften von FreeRadius prüfen lassen

Ich hab seit einiger Zeit einen FreeRadius-Server um mein WLAN abzusichern und mein VPN Zugang zu regeln. Das System war so konfiguriert, dass der Client ein Zertifikat vorzeigt, einen Tunnel aufbaut und dann via EAP/PAP autorisiert wird. Das Gruppenmanagement übernahm dabei LDAP und die das Passwort wurde via Kerberos geprüft. Alles in allem sehr flexibel aber auch sehr komplex. Vor allem der LDAP Server störte mich doch extrem. Zum einen ist der so ganz anders zu konfigurieren und zu verwalten, als alle anderen Dienst ein meiner Landschaft, zum anderen hab ich ihn nie so richtig verstanden. Kurz der musste weg. Ich wollte aber weiterhin die Option haben, eine Nutzer via VPN auf Subnets „Zugang“ zu lassen aber vom Heimnetz „Sicher“ fern zu halten. Insofern man den aktuellen FreeRadius einsetzt bietet dieser eine sehr elegante Möglichkeit an, dass auf Zertifikatsbasis zu lösen.

Der Grundgedanke: Insofern man der CA wirklich vertraut bzw. die CA selber stellt, kann man davon ausgehen, dass ein Client nur das Zertifikat hat, dass er haben darf. Verlust und Diebstahl wird über eine aktuelle „Revocation Liste“ gelöst. Vertraut man der CA, kann man somit die Zugangsinformationen ins Zertifikat hinterlegen. Zum Beispiel kann man das OU (OrganisationUnit) oder gar das CN Feld nutzen. In meinem Fall, hab ich mich auf das CN Feld bzw den ganzen Zertifikats-Pfad verlassen. Meine Netz ist in verschiedene Bereiche getrennt: Sicher, Gesichert, Offen (Radius entfällt). Alle Clients haben schon jetzt Zertifikate die wie folgt aussehen: hostname.sicher.ca oder bekannter.gesichert.ca. Ich musste den Radius nur noch dazu bekommen, dass ein Client der in das „Sichere“ Netz will auch ein „sicher.ca“-Zertifakt vorweißt.

Umsetzung: Was man vorher braucht, ist ein Radius der TLS beherrscht. Das wird hier beschrieben: Ubuntusers:Wiki – FreeRadius. Läuft der TLS Modus stehen nun eine Reihe von Variablen innerhalb der FreeRadius-Configuraiton zur Verfügung. Eine komplette Liste konnte ich nicht auftreiben aber laut einigen Mailinglisten sind die folgenden Variablen wohl verfügbar:

  • TLS-Cert-Serial
  • TLS-Cert-Expiration
  • TLS-Cert-Issuer
  • TLS-Cert-Subject
  • TLS-Client-Cert-Serial
  • TLS-Client-Cert-Expiration
  • TLS-Client-Cert-Issuer
  • TLS-Client-Cert-Subject

Interessant ist die TLS-Client-Cert-Subject – Variable. Diese stellt das Subject via String zur verfügung. Jetzt muss man nur noch mittels RegExp seine gewünschte Prüfung durchführen. Dass kann dann so aussehen.

Die „Huntgroup“ ist eine Eigenschaft die durch beliebige Regeln vorher gesetzt wird. In meinem Fall sieht die Regel so aus:

Was folgt ist folgende Prüfung. Wenn eine TLS-Verbindung über einen Zugangspunkt mit der IP 10.11.1.2 und NAS-ID (vorher vereinbart) „sicheres-lan“ ankommt muss das CLientZertifikat auf „*.sicher.ca“ ausgestellt sein. Alles andere wird abgeleht. Mann kann da noch weitere else-Zweige einbauen. Aber das Prinzip bleibt das gleiche.

Servergespeicherte Profile mit unison

Da CSync leider nicht meine Erwartungen erfüllt hat bzw. nicht im Ubuntu-Repository versorgt wird musste ich mich vor ein Weile nach Alternativen umschauen.

Dabei bin ich auf Unison gestoßen. Installiert man es auf Client und Server kann man via ssh sehr schnell große Datenmengen in beide Richtungen abgleichen. Man kann sogar eine Konfliktlösungsstrategie angeben, falls es sowohl auf Server als auch Clients zu Änderungen kam.
Mittels Exclude-List kann man gezielt steuern was übertragen werden soll. Sogar via Regex.

Beispielconfig:

Das ganze kann man ohne Probleme über ein Skript beim Start oder Login automatisieren:

Bleibt nur noch das Problem wie man den ssh-Daemon auf der Server-Seite dazu bekommt ohne weitere Passwortabfrage eine Verbindung zuzulassen. Da gibt es verschiedene Varianten wie z.b. das Public-Key-Verfahren (wobei der keyring automatisch aufgemacht werden muss) oder GSSAPI. Letztere ist relativ bequem einzusetzen, wenn man mal einen Kerberos eingerichtet hat. Dann muss man einfach folgende Konfiguration im SSH Daemon vornehmen.

Anschließend akzeptiert der SSH Daemon nach einem Neustart auch Kerberos Tickets anstatt ein Password abzufragen.

IPSec/L2TP VPN mit OpenWRT

Da ich mehrere Android Geräte in Benutzung habe die ich nicht „rooten“ darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das „Vergnügen“ mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)

PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.

Damit beginnt aber auch schon der Ärger.  IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.

OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.

Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.

Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.

Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von „Außen“ auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.

Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches „NAT“ing zum Einsatz kommt.1

Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:

Man benötigt  als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.

Configuration – /etc/ppp/options.xl2tpd

Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!

Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf

Nun zu IPSec

Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus

Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.

Linux Bandbreiten-Monitor/Traffic-Accounting

Wenn man unter Linux einen Rechner betreibt findet man einen Haufen an Möglichkeiten den Bandbreitenverbrauch zu ermitteln. Betreibt man hingegen einen Router und will nicht nur den eigenen Verbrauch, sondern den Transfer-Traffic aufgeschlüsselt nach gewissen Attributen, wird es dünn im Lösungsumfeld. Soll das ganze dann noch auf einem handelsüblichen SOHO-Router laufen, wird es richtig kniffelig.

Das erste Problem ist, dass man wissen muss nach,nach was man sucht. Unter „Bandbreiten-Monitor“ verstehen die meisten Lösungsvorschläge das Monitoring des eigenen Verbrauchs/Traffic oder nur das „Gesamtaufkommen“ an einem Interface. Kurzum: Werte die sich leicht ermitteln lassen. Das aufschlüsseln des Transfertraffics bezeichnet man häufig als IP-Accounting. Danach teilt sich das Feld in folgende Lösungen auf:

  • Promiscuous Mode Basiert: Hierbei wird ein Interface in den Promiscuous-Mode geschaltet und der komplette Netzwerktraffic mitgeschnitten. Die Lösungen unterscheiden sich dann darin, wo und wie die Daten ausgewertet werden. Im einfachsten Fall werden die Pakete vorverarbeitet und an eine Sammelstelle weiter geleitet. Bekannteste Vertreter sind NTop, NProbe und bandwidthd.
  • IPTables/NetFilter Basiert: Hierbei wird ausgenutzt, dass IPTables mit protokolliert wie viele Pakete/Bytes über eine Filter-Regel gelaufen sind. Dies kann man dann asyncron über Bash-Befehle auslesen.

Der Promiscuous Mode basierten Lösungen sind die allumfassenden Lösungen. Sie schneiden alles mit und können die detailliertesten Auswertungen bieten. Sie haben jedoch immer zwei massive Nachteile. Erstens ist die benötigte CPU-Leistung enorm. Selbst die schlanke NPrope schaffte bei einem 600MHz Prozessor nicht mal Ansatzweise den zu erwartenden Transfertraffic (100Mbit/s). Auch wird das Analyseziel stark belastet. Sowohl was die Bandbreite als auch die CPU-Last betrifft. Das ist für eine einfache Bandbreitenanalyse ein wenig übertrieben. Des weiteren ist es mehr als fraglich ob das ganze rechtlich überhaupt zulässig ist. Immerhin handelt es sich hierbei um eine DPI,  jeh nach Ausführung sogar mit ungesicherter Ausleitung.

Die IPTables -Variante hat den Vorteil, dass die Pakete sowieso durch IPTables verarbeitet werden müssen. Der Overhead für das zusätzliche Monitoring hält sich in Grenzen. Auf besagtem 600 MHz Prozessor war keine Leistungsabfall durch Zu- oder Abschalten der Filter-Regeln zu messen, noch gab es eine nennenswerte CPU-Last. Der Nachteil ist jedoch, dass man wissen muss was man Monitoren will. Wenn man nur wissen will, wie viel Traffic auf ein Netzsegment entfällt, ist das einfach umsetzbar. Will man jedoch wissen auf welchen Client im Netzsegment der Traffic aufgelaufen ist, wird es schwierig. Besonders wenn es sich um ein Netzsegment mit ständig wechselnden Clients handelt wird es nahezu unmöglich das mit IPTables alleine zu bewerkstelligen.

Abhilfe schafft ein die ULog Schnittstelle und ein Daemon aus dem pmacct.net-Project. IPTables führt das Decoding und Vorfilterung durch und leitet das Paket dann an den uacctd weiter. Dieser filtert, aggregiert und verarbeitet die Daten oder leitet sie an ein Sammelstelle weiter.

Das Ganze ist denkbar einfach zu konfigurieren. Als erstes braucht es nur IPTables-Regeln die die interessanten Pakete ausleiten.

Durch diese Regeln werden alle Pakete die das 192.168-Netz betreffen an die ULog-Schnittstelle weitergeleitet. Die weiteren Parameter bewirken, dass immer gewartet wird bis sich 50 Pakete gesammelt haben und nur die ersten 48 Bytes weitergeleitet werden. Die Group-Angabe ist später für die Auswertung wichtig.

Der entsprechende uacctd ist wie folgt konfiguriert:

Durch diese Konfiguration werden zwei Endpunkte angelegt, jeweils einen für ein- und ausgehendem Traffic und nach internem Client aggregiert. Der Speicherverbrauch und die Prozessorlast ist in meinem Einsatzgebiet zu vernachlässigen (selten mehr als 20 Clients gleichzeitig) kann jedoch je nach Einsatzart stark ansteigen. Ob das ganze bei 10k Clients und „portgenauem“ Monitoring noch skaliert habe ich nicht ausprobiert.

Auswerten kann man das ganze wie folgt:

Mit der eigenen Wunsch-Skriptsprache kann man nun die wildesten Skriptes zum überwachen des Traffics basteln.
Hier mein Beispiel für einen Perl-Skript/Munin-Plugin: munin-bandwidth.perl

Samba/CIFS und Kerberos Authentifizierung

Nachdem ich NFS und Kerberos installiert hatte, wollte ich auch Samba/CIFS an Kerberos anbinden. Das gestaltete sich schwerer als erwartet.

Das Einrichten auf Serverseite gestaltete relativ reibungslos. Einfach dem Samba-Dienst entsprechend Konfigurieren.

Im Kerberos hinterlegt man einen entsprechenden Principal und fügt ihn dem CIFS-Server hinzu.

Nach einem Neustart des Dienstes werden die User-Credentials von Samba gegenüber Kerberos Authentiziert.

Auf Client-Seite war dem ganzen nicht so leicht bei zu kommen. Als erstes muss ein Client-Key am Kerberos erzeugt werden und in der Client Keytab hinterlegt werden.

Anschließend mounted man den Share wie folgt:

Bis dahin hat mich das „nur wenige“ Stunden gekostet. Der Parameter „uid“ wird scheinbar gebraucht wenn Winbind nicht so will, wie es soll. Ich hab es ums verrecken nicht hinbekommen, dass der Winbind mehr schmeißt als nur Fehler.

Daneben war es mit nicht möglich den krb5i-Modus zu aktivieren, also Schutz gegen Veränderung der einzelnen Daten-Pakete. Zudem scheint CIFS/Samba nur beim Mount die Usercredentials zu überprüfen und die Verbindung dann an den User zu knüpfen. Wenn ein anderer User (root) auf den Share zugrifft, erfolgt das unter der UID des Users der den Mount aufgemacht hat.

ics dhcp hostname direktive wird ignoriert.

Ich hatte bei mir das Problem, dass bei aktiven DNS-Update durch den DHCP Server „illegale“ DNS-Namen in meine dynamische Zone eingetragen wurden. Irgendein Witzbold muss sich bei Google wohl gedacht haben, dass „android_{MAC}“ ein wunderbar einfacher Hostname ist und den ein User nie ändern will.

Dummerweise wird dieser von keinem DNS Server standardmäßig akzeptiert. Man muss zu mindestens das „Sperrverhalten“ abschalten. Ich entschied mich dafür im DHCP Server ein Hostname zu definieren. Der wurde aber geflissentlich ignoriert. Das Snippet das standardmäßig als „on-commit“ Hook hinterlegt ist greift auf „option host-name“ zu anstatt auf „config-option host-name“.

Ich hab es wie folgt angepasst und in meine dhcpd.conf eingefügt

RSyslog und der komfortable Weg Logfiles zu lesen.

Seit geraumer Zeit hab ich eine Artikel aus dem CT Sonderheft vor mir hergeschoben. Nun hab ich es endlichgeschafft RSyslog Logs über MySQL durch LogAnalyzer analysieren zu lassen. Wer nur Bahnhof versteht, hier eine kleine Zusammenfassung: Worum geht es eigendlich? Ein laufendes LinuxSystem produziert ziehmlich zentral einen Haufen LogFIles. Diese geben meist den entschiedenden Anhaltspunkt wenn es darum geht rauszufinden, was passiert ist, warum etwas nicht funktioniert und so weiter. Das Problem bei der vielzahl an Logs ist, dass man sie schlecht durchsuchen kann. Wenn man einen Zeitstempel hat, kann man vieleicht noch gezielt Suchen, aber spätestens wenn es um die Frage geht: „wann wurde Datei XY gelöscht und von wem“ wirds ungemütlich, Liegt der fragliche Zeitpunkt noch in der Logrotation, wenn ja in welcher und überhaupt ist suchen über mehrere Dateien angesagt. Wie häufig wünschte ich mir bei sowas ein statement wie folgendes:

Nunja genau das kann man mit RSyslog umsetzten. Sobald man das Packet „rsyslog-mysql“ installiert (es gibt noch eine PostGreSQL Backend) werden alle LogEintrage zusätzlich auch in einer (auf Wunsch automatisch angelegten) Datenbank abgelegt. Zusätzlich deshalb, weil es blöd ist, in die Datenbank zu schreiben, dass die Datenbank nicht da ist. Hat man einmal diese Komfortstatus erreicht, will man ihn gleich richtig Auskosten. Hier kommt LogAnalyzer ins Spiel.

LogAufkommen nach SeverityLogAufkommen nach Diensten
LogAnalysen

LogAnalyzer wiederum ist eine „kleine“ PHP-Anwendung die mehrere Quellen (darunter MySQL, PlaintextFile, etc) einlesen und auswerten kann. Diese können dann Aggregiert, komfortabel durchsucht und ausgewertet werden. Das macht einem das Leben im Zweifelsfall ziehmlcih einfach. Und gerade mit dem PlaintextFile kann man so ziehmlich jede Quelle in das System einbinden Link: http://loganalyzer.adiscon.com/downloads

EGroupware und SyncML im Einsatz

Wer ein mobiles Gerät mit Android seit eigen nennt, wird schnell feststellen, dass nur zwei sinnvolle Sync-Optionen vorgesehen sind: Google(Mail/Konto) und Exchange. Wer wie ich ersteres nicht hat und auch nicht will und für letzteres kein Sinn sieht (OpenXchange ist die OpenSource Alternative) der muss etwas suchen um seine Kalender, Kontakte und ToDo-List zu synchronisieren.

Seit einiger Zeit kristallisiert sich SyncML  als „Transportstandart“ für genau diese Aufgabe heraus. Der Vorteil dieses offenen Standards liegt auf der Hand. Es gibt verschiedene Backends und Frontends, die alle in unterschiedlicher Kombination miteinander Synchronisieren können. Dieser Artikel geht auf beides ein.

Mein Setup sieht wie folgt aus:

  • mehrere Thunderbird Endgeräte – mobil wie stationär
  • mehrere mobile Endgeräte mit verschieden OS Typen (Symbian, Android, usw)
  • Outlook/Exchange (Arbeitsrechner)
  • Ubuntu-Server als zentrale Datenhalde.

Das Frontend

Recht schnell bin ich auf Funambol gestoßen. Diese Firma bietet Sync-Tools für alle möglichen Plattformen, einen SyncML-Server und einen CloudService. Funambol betreibt dabei das typische OpenSource – Geschäfftsmodel. Code und Tools kostenlos, den Service und einige Features gibt’s gegen Bares. Aber das stört nicht. Zum einen gibt es den FunambolServer (SyncML) als installpacket zum anderen kann man auch auf andere SyncML-Angbote zurückgreifen. Das Backend ist frei konfigurierbar. Mein Fazit nach zwei Wochen mit Funambol im Test:

  • Thunderbird: Erst einmal muss man das Plugin finden. Dazu muss man sich das Plugin entweder selber bauen oder unter www.memotoo.com ein vorkompiliertes Paket herunter laden. Einmal installiert funktioniert alles wie man es sich vorstellt. Adressbücher, Kalender und Task werden ordnungsgemäß synchronisiert.
  • Android: Auch hier gibt es eine Funambol-Applikation kostenlos im markten. Einmal installiert, legt es ein neues „Synchronisations-Konto“ an. Es existiert neben Exchange und Google-Mail dann noch eine weite SyncQuelle, die sich schön in die Android-Oberfläche einbindet. Aufbau der Applikation und Funktonumfang entspricht den Standart Funambol Desktop-Client mit einer Ausnahme: auf dem Android gibt es (noch) keine Task. Es gibt noch keine Task-App die mit Funambol koppelt – leider.
  • Outlook: hier gibt es ein offizielles Plugin das ebenfalls einwandfrei funktioniert.

Eine Einschränkung gibt es jedoch: Funambol scheint beim syncen „marker“ in die jeweiligen Kalendereinträge zu machen (id). Wird der Kalender aber nicht lokal gespeichert sondern ebenfalls synchronisiert oder gar über Netzwerk eingebunden (Exchange/ICS/CalDav) gehen diese Informationen verloren. Der Client ist scheinbar nicht mehr in der Lage, Einträge die vom Server kommen zuzuordnen, mit der unschönen Folge das Dubletten entstehen. Bei meinem Outlook muss ich auf eine veraltete Funambol Version (8.72) setzten, weile nur noch diese den „One-Way“ Modus unterstützt. Dabei überträgt der Client (wahlweise) nur Zum Server oder Empfängt nur vom Server.

Das Backend

Funambol bietet auch einen SyncML Server.  Bei diesem handelt es sich um ein Java – basierten Server samt Konfiguration. Im ersten Überblick wirkte das alles ein wenig „unübersichtlich“ und wenig strukturiert aus. Ich muss aber gestehen das ich mir den Server nur ganze 2 Stunden angeschaut habe. Nebenher hatte ich mir noch ein EGroupware Server aufgesetzt und direkt verglichen. Diesen Vergleich hat der Funambol-Server aus folgenden Gründen verloren:

  • Funambol setzt eine eigene Server-Struktur auf. Dieser Server braucht einen Port den ich durch meine FW Routen muss und so weiter. Auf meinen Server läuft aber schon ein Apache. Egroupware nutzt diesen, so fällt der Mehraufwand weg.
  • Funambol setzt sein eigenes DB-Backend ein. Die wollen gesichert werden. EGroupware kann alle DB-Backends ansprechen, die PHP beherrscht. Standardmäßig komm MySQL zum Einsatz.
  • Und mein Totschlag-Argument: Funambol kann man (noch) nicht aus einer apt-Quelle installieren. Man muss sich also selber kümmern ob und wie man das ganze aktuell hält. EGroupware gibt es als Paket aus den offiziellen quellen.

Bei Egroupware handelt es sich ebenfalls um eine OpenSource-Projekt mit kommerziellen Grundgerüst. Die Community-Edition gibt es kostenlos, den Service muss man kaufen. Man kann das Paket direkt aus den offiziellen Quellen beziehen (die sind veraltet) oder man greift auf Quellen des Herstellers zurück. Dieser bietet für fast alle Debian/Ubuntu-Verianten die quellen an.

Standardmäßig wird EGroupware so installiert das es ein Anwendung unter „http://localhost/egroupware“ gibt. Das kann man wie gewohnt über die Apache-configs umbiegen und anpassen. Die geführte Installation in der Webanwendung gestaltet sich ein wenig hackelig. Das ist bedingt durch den Umstand, dass EGroupware für große Mittelständler gedacht ist. Es unterstützt Domänenkonzepte, Mailserver, verschiedenste Authentifizierungen usw Für den Zweck der einfachen „Ein Mann Synchronisierung“ ein wenig oversized aber es gibt schlimmeres.

Einmal installiert und eingerichtet zeigt sich EGroupware sehr aufgeräumt und übersichtlich. Besonders hervor gestochen haben folgende Funktionen:

  • Es gitb unterschiedlichste Sync-Schnittstellen für ein und das selbe. Zum Beispiel kann der Kalender unter ./calendar oder calendar angesprochen werden. Jede dieser Schnittstellen kann man ein eigenes Konflikt-Management vorgeben.
  • Es wird die WebDav – Schnittstelle angeboten. Hat man Festrechner, die immer mit dem Server verbunden sind, kann man die Kalender bequem mittels WebDav einbinden. Insofern die Kalender der „Kollegen“ freigegeben sind kann man sogar die einbinden. Der Link sieht dann so aus: https://egroupware/groupdav.php/<username>/calendar
  • Legt man einen Eintrag im Kalender an und hinterlegt dabei einen Gesprächspartner (E-Mail) gleicht Egroupware automatisch mit der internen Kontakt-Liste ab und macht entsprechende Einträge bzw. versendet E-Mails
  • Sowohl IMAP als auch POP Server werden unterstützt, auch SMTP wird angeboten – Es muss aber kein Mail-Server angegeben werden!
  • Das WebEnd-ist ansprechend und übersichtlich.

Fazit

Seit zwei Wochen synchronisiere ich erfolgreich zwischen allen meinen Geräten. Von der kleinen Outlook-Einschränkung mal abgesehen funktioniert das Problemlos. Besonders das Feature, dass meine Freundin jederzeit sehen kann, wie meine geschäftlichen Termine liegen bzw. mir von zu Hause Termine „rein knallen“ kann, erleichtert mir ein wenig das leben. Der Verwaltungsaufwand hält sich in Grenzen, da fast alles aus den Mail-Clients her raus gelöst werden kann. Eine klare Empfehlung an alle die ihre Kontaktdaten,Kalender und Aufgaben lieber nicht in der Cloud speichern wollen aber dennoch auf den SyncService nicht verzichten wollen.

Weitere Links:

Wenn rdiff-backup mal streikt…

Rdiff-backup ist meine favorisierte Backuplösung. Sie hat einfach zu viele nette Feutures, allen vor ran der geringe Speicherplatzverbrauch plus der Datei-Historie. Leider hat rdiff-backup ein Problem mit seiner Stabilität.  Wenn es mal zu einem inkonsistenten Backup kommt. steht man ziemlich mit runter gelassenen Hosen da. Ich selbst leide an einem solchen Problem. Um zu ermitteln ob mit einem Backup alles in Ordnung ist muss man folgenden Befehl ausführen:

Liefert dieser Befehl keinen Output kann man es ruhig angehen lassen. Gibt es jedoch Meldungen wie diese hier, sollte man auf jeden Fall prüfen was mit dem Backup nicht stimmt.

Wenn man dem nicht traut kann man mittels folgenden Befehl einen kompletten vergleiche Quelle<>Backup anstoßen:

Dieser Befehl liefert die Files, bei dehnen sich Quelle und Backup unterscheiden unabhängig davon ob sich laut Change-Time irgendwas an der Datei geändert haben sollte.
Zusätzlich gibt es noch:

Dieser macht das gleiche wie der vorherige Befehl, nur vergleicht er nur die gespeicherten Hashes mit den neu genierten der Qulle. Das hilft nichts, wenn sich die Dateien im Backup geändert haben (z.B. korruptes File-System).
Kurz wenn der „compare-file‘ Befehl sagt „alles ok“, dann kann man dem trauen. Er ist jedoch auch der aufwändigste. Jeh nach Datenmenge kann das 24 Stunden und mehr brauchen. Leider hat der Befehl auch noch einen anderen Hinkfuß. Für die Dauer der Prüfung darf die Quelle nicht geändert werden, da es sonst zu unnützen Flaschmeldungen kommt.

Hat man einmal eine Datei (oder mehrere) ermittelt die defekt im Backup gespeichert vorliegt muss man diese im Backup aktualisieren. Leider bietet rdiff-backup dafür keinen Mechanismus. So das man händisch bei allen dateien  den „mdoified“-Zeitstempel auf einen Wert nach dem letzt Backup setzt muss. Also einfach ein touch auf alle Quelldateien bei den das Backup nicht in Ordnung ist, anschließend rdiff-backup nochmal laufen lassen.