Synchronisation: „works for me“

Motivation

This article has multiple motivations. First, it is a follow-up to an article by Patrick Ohly (author of syncEvolution). As such it illustrates my own experience with his software, but also is meant as a way to show my gratitude and give kudos to him and all contributors of syncEvolution. Second, but this is somehow related to the aforementioned article, it should show that synchronisation [of PIM data] can work reliably and as such it opposes a wide spread opinion.

Scope

What I’ll try to show is how I’m successfully synchronising my notebook, my workstation (both Fedora 15) and my Android phone using the SyncML protocol.

Disclaimer: on the phone, I’m currently using a non-free piece of software from Synthesis AG for the only reason that the free Funambol client doesn’t play well with my self-signed SSL certificate (yet!?).

Weiterlesen →

WordPress Multi-Network with Nginx

Today I found out the hard way, how an nginx web-server has to be configured to properly work together with the WP Multi Network plugin.

The problem was, that for some reason and on some machines, WordPress showed always only one blog (not the same on all machines) and ignored the domain entered into the browser. Now it is exactly the purpose of the multi-network plugin to resolve different domains to different blogs (hopefully in a reproducible manner).

It turned out, that the problem was in the nginx configuration that looked like that:

server {
    server_name  _ .fabianmoser.at .nataschastanke.eu;
    #...
}

thus catching both domain names registered for my server.

After some twiddling with the nginx log format to inspect where the http header got lost, I found the following solution:

server {
    server_name  .fabianmoser.at;
    #...
}
server {
    server_name  .nataschastanke.eu;
    #...
}

thus effectively duplicating the virtual server section and giving just one server name each time.

Now everything works fine as you can easily verify yourself.

DKIM DNS Einstellungen im SERVER4YOU Powerpanel

Heute habe ich meinen Mailserver um ein neues Feature erweitert: die Unterstützung von DomainKeys Identified Mail, einem Verfahren, das helfen soll, Absender Adressen von E-Mails zu verifizieren. Es ist damit ein effektives Werkzeug im Kampf gegen Spam E-Mails

Der versendende Server signiert alle Mails die er versendet vor der Übertragung. Spam Versender haben keinen Zugriff auf den privaten Schlüssel des Servers in dessen Namen sie versenden und können daher keine gültige Signatur bereitstellen. Der empfangende Server kann sich aus einem speziellen DNS Eintrag der Absender-Domain den zur im Absender angegebenen Domain gehörenden öffentlichen Schlüssel holen und damit die Signatur der empfangenen E-Mail überprüfen.

Bei der Einrichtung habe ich mich größtenteils an eine Anleitung von R. I. Pienaar gehalten. Nur bei den DNS Einträgen hatte ich vorübergehend Schwierigkeiten. Im Unterschied zu der Anleitung, habe ich keinen direkten Zugriff auf die Bind Konfigurationsdatei. Stattdessen muss ich die Administrationsoberfläche meines Hosting Providers SERVER4YOU verwenden. Anstatt umständlich das Format der notwendigen Einträge in der Domainverwaltung zu beschreiben, ist hier ein Screenshot von meinen korrekten, funktionierenden Einstellungen:

DNS Einstellungen für DKIM

Man beachte, dass in der oberen Zeile kein v= Eintrag vorkommt und dass ich weder Anführungszeichen noch Backslashes verwende.

Virtuelle Übersiedlung

Die vergangene Woche hat ein paar virtuelle Neuerungen gebracht. Ich habe meinen privaten Server auf eine neue Hardware umgezogen. Tatsächlich geht es zwar genau genommen um virtualisierte Hardware, aber mit dem Umzug haben sich die diversen Ressourcenlimitierungen nach oben verschoben, sprich mehr Speicher und mehr Leistung.

Redmine

Der Grund für die doch etwas aufwendige Aktion war ein mehr oder weniger fehlgeschlagener Versuch, die das Projektmanagement-Tool Redmine als Ersatz für das bisher eingesetzte Trac auszuprobieren. Leider stieß mein alter Server dabei an seine Grenzen und verweigerte für kurze Zeit sogar die Annahme von E-Mails.

Weil ich einen Umstieg schon seit einem Jahr immer wieder überlegte, nahm ich die Situation zum Anlass um mit meinem Provider die Optionen zu besprechen. Mir wurde ein Upgrade angeboten, das sich heute leider als ungültig erwiesen hat. Letztendlich ist der einzige Unterschied eine Monatsmiete, weil ich beide Verträge nur mit einmonatiger Bindung abgeschlossen habe.

Den für Redmine notwendigen Ruby Stack habe ich aus den aktuellen Quellen selbst kompiliert, weil die Versionen in den CentOS Repositories für diese junge Software stark veraltet sind. Ruby stellt mit den gut unterstützen Gems eine gute eigene Paketverwaltung bereit.

CentOS

Weil ich auf meinem Laptop seit einiger Zeit auf die Linux Distribution Fedora setze, habe ich meine Distributionswahl am Server überdacht und statt Debian auf das Fedora-ähnliche aber auf den Servereinsatz aufgelegte CentOS gesetzt. Vom Geist der Revolution beflügelt, habe ich mich auch gleich versuchsweise von Apache als Webserver verabschiedet und auf Nginx umgestellt. Die gerade angezeigte WordPress wird entsprechend von PHP-FPM ausgeführt.

Für die Mailserver Infrastruktur verlasse ich mich weiterhin auf das bewährte Gespann von Dovecot und Exim. Weil mein Server meine zentrale Sammelstelle für alle E-Mail Konten ist (per Fetchmail), wollte ich hier nichts riskieren und sah auch wirklich keinen einzigen Grund für eine Veränderung.

VCS

Meine alten Subversion Repositories habe ich natürlich unverändert kopiert. Daneben habe ich mit Hilfe von Gitosis eine für meine Zwecke perfekte Git Verwahltung eingerichtet, die (wie svn+ssh) unter einem einzelnen Systemaccount und einer Sammlung von autorisierten öffentlichen Schlüsseln beliebig viele Git Repositories mit getrennt einstellbaren Zugriffsrechten zur Verfügung stellt. Nebenbei war die Unterstützung von Git und Subversion einer der Mitgründe für den Umstieg von Trac auf Redmine.

Fertig

Also genug Fachjargon. Fazit: Ich habe einige glückliche Stunden mit meiner virtuellen „Immobilie“ verbracht. Nur damit die Änderungen nach außen hin nicht völlig unbemerkt bleiben habe ich auch gleich das WordPress Motiv geändert.

Einrichtung eines sicheren Fileservers

Theorie

Bei diesem Titel versteht es sich vielleicht von selbst, dass FTP hier kein Thema ist. Es ist vermutlich zu einem nicht unwesentlichen Teil persönliche Präferenz, aber wenn ich das Wort sicher im Zusammenhang mit Servern verwende, verlasse ich mich immer gern auf SSH. Im Fall eines Fileservers bietet sich also das SFTP Protokoll an. Generell wirft die Verwendung von SSH und, im Speziellen, die Weitergabe von Zugangsdaten für einen SSH Server (zumindest) zwei brennende Fragen auf.

Zum einen muss verhindert werden, dass der eingeloggte Benutzer beliebigen Code ausführen kann. Da er zumindest für das Upload Verzeichnis Schreibrechte hat, kann ein eventueller Upload von Exploits nicht prinzipiell verhindert werden, aber wenn man dem Benutzer erst gar keine Shell gibt, kann er die Ausführung des Schadcodes nicht veranlassen. Diese Strategie verfolgt die scponly Software.

Zum anderen ist man als Administator auch interessiert, dem eingeloggten Benutzer möglichst wenig Information über das System preiszugeben. Das erreicht man mit einer chroot Umgebung. Nun wird sogar von scponly ein Skript angeboten, um eine solche Umgebung zu erstellen. Dessen Verwendung wird auf der ubuntuusers Wiki beschrieben. Leider ist dafür das Setzen des SUID Bits notwendig, was meiner Meinung nach keine saubere Lösung ist. Daher werde ich hier beschreiben, wie man eine äquivalente Umgebung mit dem makejail Skript erstellt. Diese Vorgehensweise orientiert sich stark an der Anleitung zum Absichern von Debian, welche in ihrer Gesamtheit auf jeden Fall eine Lektüre wert ist, wenn man einen Debian Server administrieren muss.

Praxis

Diese Anleitung bezieht sich auf Debian Lenny. Zuerst werden die erforderlichen Pakete installiert:

# aptitude install libpam-chroot makejail scponly

Nun wird das eben installierte PAM Modul libpam-chroot für SSH Logins aktiviert. Dazu werden die folgenden Zeilen zu der Datei /etc/pam.d/sshd hinzugefügt:

session    required     pam_chroot.so

Zunächst muss der entsprechende Benutzer erstellt werden, mit dem man sich später am Server anmelden kann.

# adduser --home /home/sftp --shell /usr/bin/scponly --no-create-home sftp

Damit das PAM Modul auch wirklich greift, muss es für den neuen Benutzer aktiviert werden. Das geschieht durch folgende Zeile in der Datei /etc/security/chroot.conf.

sftp	/var/chroot/users/sftp

Als nächstes wird das Verzeichnis für die chroot Umgebung erstellt und der neue Benutzer erhält Schreibrechte für sein Heimatverzeichnis.

# mkdir -p /var/chroot/users/sftp/home/sftp
# chown sftp:sftp /var/chroot/users/sftp/home/sftp

Für die Verwendung des makejail Skripts wird eine Konfigurationsdatei mit folgendem Inhalt erstellt und als sftp-jail.py gespeichert.

chroot="/var/chroot/users/sftp"
users=["sftp"]
testCommandsInsideJail=["scponly", "ls", "scp", "rm", "ln", "mv", "chmod", "chown", "chgrp", "mkdir", "rmdir", "pwd", "groups", "id", "echo", "passwd"]
forceCopy=["/usr/lib/sftp-server"]
cleanJailFirst=1
preserve=["/home/sftp"]

Es folgt der Aufruf des Skripts.

# makejail sftp-jail.py

Die am Ende ausgegebenen Warnungen können getrost ignoriert werden. Wenn man so vorsichtig ist wie ich, muss man noch dafür sorgen, dass der SSH Login für den neuen Benutzer freigegeben wird. Dazu fügt man den neuen Benutzernamen dem AllowUsers Parameter in der Datei /etc/ssh/sshd_config hinzu und startet das SSH Service neu.

# /etc/init.d/ssh restart