lighttpd, ownCloud, FolderSync: 417 und Expectation Failed

Seit einiger Zeit hatte ich beim Synchronisieren zwischen ownCloud und Android-Telefon mit FolderSync das Problem, dass ich vom Telefon aus keine neuen Dateien in meine ownCloud hochladen konnte.
Fehlermeldung in FolderSync: ‚Expectation Failed‘.

Im lighttpd-access.log fand ich folgende Zeile:

89.XXX.XXX.XXX - - [17/Dec/2013:06:49:23 +0100] "PUT /remote.php/webdav/testdatei HTTP/1.1" 417 363 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"

Lösen lässt sich das Problem, indem in der Datei /etc/lighttpd/lighttpd.conf folgendes eingefügt wird:

server.reject-expect-100-with-417 = "disable"

Quelle: https://groups.google.com/forum/#!topic/tacitdynamics/k1MssqqVWYc

Debian 6 Squeeze: openssl 1.0.1e und lighttpd 1.4.33 selbst kompilieren (für TLS 1.2 mit PFS)

Nach den ganzen Geschichten um die NSA wollte ich dann meinen Webserver auch mal etwas besser absichern.

Dazu habe ich für den bei mir eingesetzten lighttpd hier eine Anleitung gefunden.

Problem ist allerdings, dass die meisten Chiffre mit der in Debian Squeeze eingesetzten openssl-Bibliothek in der Version 0.9.8o leider nicht funktionieren. Die Lösung: eine neue openssl-Version muss her. Aktuell (Stand November 2013) ist die Version 1.0.1e.

Dank Server4You und dem dort eingesetzten vServer bin ich leider auf das mittlerweile veraltete Debian 6 (Squeeze) angewiesen und kann mangels Unterstützung durch die Server4You-Host-Server nicht auf Wheezy aktualisieren. Deshalb bleibt uns nichts anderes übrig, als die notwendigen Pakete selbst zu kompilieren.

Damit lighttpd (lighty) auch mit der neuen openssl-Version umgehen kann, werden wir die derzeit letzte lighty-Version 1.4.33 runterladen und selbst kompilieren.

Ich gehe hier davon aus, dass lighttpd und openssl bereits aus den normalen apt-Quellen installiert sind.

Zunächst zu openssl:

apt-get build-dep openssl
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
cd openssl-*
unp openssl-1.0.1e.tar.gz
./config shared zlib-dynamic
#so sähe die config-Zeile für den vollständigen Debian-openssl-Ersatz aus:
#./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared zlib-dynamic
make
make test

#ohne den folgenden Befehl läuft checkinstall nicht durch
mkdir -p /usr/local/ssl/lib/engines

Das .deb-Paket erstellt nun checkinstall. Allerdings ändern wir den Paketnamen, damit wir nicht mehr der originalen Debian-openssl-Installation ins Gehege kommen:

checkinstall -D --pkgname openssl-pfs

Da wir die neue openssl-Version in /usr/local/* installieren, muss die originale Debian-Version nicht deinstalliert werden, d.h. wir können es einfach parallel installieren:

dpkg -i openssl_1.0.1e-1_i386.deb

Jetzt kann es mit lighttpd weitergehen. Wir sorgen zunächst dafür, dass alle Build-Abhängigkeiten von Debian gelöst werden:

apt-get build-dep lighttpd

wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.33.tar.gz
unp lighttpd-1.4.33.tar.gz
cd lighttpd-*
./autogen.sh
./configure --with-openssl --with-openssl-libs=/usr/lib --prefix=/usr --with-webdav-props --with-webdav-locks

#neues .deb-Paket erstellen
checkinstall -D

#alte Debian-Skripte sichern
cp -r /usr/share/lighttpd/ /root/usr_share_lighttpd

#die aktuelle lighttpd-Installation entfernen
apt-get remove lighttpd

#alte Debian-Skripte wiederherstellen 
#(da diese durch die Deinstallation verloren gegangen sind)
cp -r /root/usr_share_lighttpd /usr/share/lighttpd

Jetzt können wir endlich das gerade erstellte lighty-Paket installieren:

dpkg -i lighttpd_1.4.33-1_i386.deb

Mit einem

service lighttpd restart

starten wir den neu kompilierten Webserver. Danach sollten wir mal testen, ob alle Webseiten noch klappen 😉

Falls ja, können wir den Autostart von lighty wieder einrichten:

update-rc.d lighttpd defaults

Jetzt können wir endlich unsere Konfiguration so anpassen, dass der Webserver mit sicheren Chiffre und Perfect Forward Secrecy (PFS) arbeitet:

ssl.use-sslv2 = "disable"
ssl.use-compression = "disable"
ssl.honor-cipher-order = "enable"
ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA"

Oder Alternativ komplett ohne Unterstützung für RC4 (dadurch keine Unterstützung für Java und IE unter Windows XP):

ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA"

UPDATE 20.01.2014:
Das funktioniert natürlich auch mit lighttpd Version 1.4.34 genauso. Einfach oben immer 1.4.33 ersetzen durch 1.4.34.

Postfix: 535 Authentication credentials invalid

Ich verwende Postfix, um per Relay E-Mails über Web.de zu verschicken.
Das klappte bisher auch problemlos, bis ich die Fehlermeldung bekam:

postfix/smtp[11477]: SASL authentication failed; server smtp.web.de[213.165.67.124] said: 535 Authentication credentials invalid

Nach einem Einloggen auf Web.de und dem Verschicken einer Mail an einen beliebigen Empfänger übers Webinterface, klappte auch, ohne Änderung an meiner Postfix-Konfiguration, wieder das Verschicken von E-Mails über Postfix.

Klingt komisch, ist aber so!

=================================
EDIT:
Es kommt noch schlimmer. Nachdem auch die Vorgehensweise von oben nicht mehr klappte, habe ich festgestellt, dass Web.de einfach so meinen POP3/IMAP-Zugang „sicherheitshalber“ deaktiviert hat. Dies hat Web.de in einer Mail angekündigt. Zum Reaktivieren muss man folgendes in der Weboberfläche durchführen:
https://hilfe.web.de/e-mail/einstellungen.html#pop3-imap

Postfix und TLS

Damit die TLS-Zertifikate der Gegenstellen akzeptiert werden, müssen die CA-Zertifikate bekannt sein.
Dazu wird in der Datei /etc/postfix/main.cf folgende Zeile eingefügt
smtp_tls_CApath = /etc/ssl/certs/

Damit die Zertifikate auch erkannt werden, müssen sie vorher gehasht werden:
c_rehash $(postconf -h smtp_tls_CApath)

Zum Schluss noch ein
service postfix restart

Da postfix unter Debian allerdings in einer chroot-Umgebung läuft, muss der smtp_tls_CApath vor dem postfix Start in den chroot-Ordner (/var/spool/postfix) kopiert werden. Dies geschieht am einfachsten, wenn man in der /etc/init.d/postfix folgendes abändert (ab Zeile 77):

#               # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
#               if [ -f "/etc/ssl/certs/ca-certificates.crt" ]; then
#                   smtp_use_tls=$(postconf -h smtp_use_tls)
#                   smtp_enforce_tls=$(postconf -h smtp_enforce_tls)
#                   smtpd_use_tls=$(postconf -h smtpd_use_tls)
#                   smtpd_enforce_tls=$(postconf -h smtpd_use_tls)
#                   case :$smtp_use_tls:$smtp_enforce_tls:$smtpd_use_tls:$smtpd_enforce_tls: in
#                       *:yes:*)
#                           mkdir -p etc/ssl/certs
#                           cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
#                   esac
#               fi

                # if we're using CApath, we need to copy the whole directory
                ca_path=$(postconf -h smtp_tls_CApath)
                if [ "X$ca_path" != "X" ]; then
                        /usr/bin/c_rehash $(postconf -h smtp_tls_CApath) > /dev/null
                        # strip leading /
                        ca_path="${ca_path#/}"
                        # delete current copy
                        [ -d ${ca_path} ] && rm -rf ${ca_path}
                        mkdir -p ${ca_path}
                        if [ -d /${ca_path} ]; then
                                # copy hashes and dereference
                                cp -L /${ca_path}/*.0 ${ca_path}/
                                chmod -R a+rX ${ca_path}
                        fi
                fi

Quelle: http://bugs.debian.org/287795.

SSL-Zertifikate von startssl

Certificate Signing Request (CSR) für startssl.com erstellen:
openssl req -new -key stephangsell.de.key -out stephangsell.de.csr

Für lighttpd muss eine PEM-Datei erstellt werden, die den privaten und öffentlichen Schlüssel in einer Datei enthält:
cat /etc/ssl/private/stephangsell.de.key /etc/ssl/certs/stephangsell.de.crt > /etc/ssl/pem/stephangsell.de.pem

Mehr Infos hier.

Redmine und bundle

Update von Redmine (auf neuen svn-Stable-Zweig wechseln).
svn switch http://svn.redmine.org/redmine/branches/2.2-stable
(im Redmine-Verzeichnis ausführen, i.d.R. /var/www/redmine).

Danach mit
bundle update
die Ruby-Geschichten aktualisieren.

Jetzt sollte Redmine wieder laufen.

udev und eSATA

Damit Kubuntu meinen eSATA-Anschluss (der an einen internen SATA-Anschluss angeschlossen ist) auch als externe Variante erkennt, muss er mit udev als solches deklariert werden.

Vor dem Anschließen der externen Festplatte den Befehl ausführen:
udevadm monitor --environment
Nach dem Anschließen werden dann sämtliche Informationen zum angeschlossenen Gerät angezeigt. Wichtig ist hierbei die Zeile, die mit „DEVPATH=“ beginnt.

In der Datei „/etc/udev/rules.d/09-esata.rules“ ist dann folgendes einzutragen:
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/ata5/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"

Danach erkennt der KDE-Desktop eine eSATA-Festplatte genauso, wie eine USB-Festplatte. D.h. es kommt ein Pop-Up-Fenster, indem man die externen Partitionen einbinden und öffnen kann.

Mailman: neue Subdomain

Kürzlich musste ich die Subdomain für den administrativen Zugriff auf Mailman ändern.

Dazu zuerst in der Datei /etc/mailman/mm_cfg.py folgende Zeile anpassen:
DEFAULT_URL_HOST = 'sub1.example.org'

Damit anschließend Links auf den Mailman-Seiten funktionieren, müssen diese an die neue Subdomain angepasst werden mittels
withlist -l -r fix_url <listenname>

SSH-Zugang ohne Passwort per Public-Key-Authentifizierung

Hier habe ich einen netten Einzeiler dazu gefunden, der auch noch auf das mounten entfernter Verzeichnisse per sshfs eingeht.

Zunächst mit

ssh-keygen

ein (passwortloses) RSA-Schlüsselpaar erstellen.

Dann einmal mit

cat ~/.ssh/id_rsa.pub | ssh user@server 'cat >>~/.ssh/authorized_keys'

auf dem Server einloggen.

Update: Alternativ macht dieser Befehl das gleiche:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Beim nächsten Zugriff per

ssh user@server

ist dann auch kein Passwort mehr notwendig.