Bester CalDAV-Server überhaupt (wenn man der einzige Benutzer ist)

Bis vor kurzem habe ich zur Synchronisation meiner Kontakte und meines Kalenders Owncloud benutzt, um zu vermeiden, dass alle meine Daten bei Google liegen. Owncloud habe ich damals gewählt, weil es mir aufgrund der hohen Verbreitung als die einfachste Lösung erschien. Was von so vielen Leuten benutzt wird, kann so schlecht ja gar nicht sein.

Falsch gedacht! Owncloud ist einfach nur schrecklich! Es gibt keine Autoupdatefunktion, man muss aber ständig updaten, weil immer wieder hochkritische Sicherheitslücken auftauchen. Man wird nicht einmal informiert, wenn ein neues Update verfügbar ist. Und wenn man mal wieder updaten muss, weil man erfahren hat, dass seine ganze Serverinfrastruktur bedroht ist*, muss man eine extrem lange Liste von Schritten manuell abarbeiten, nur um festzustellen, dass irgendwas doch kaputt gegangen ist und man bis nachts um drei da sitzen muss um es zu fixen, weil man auf die Synchronisierung seiner Kalenderdaten angewiesen ist.

Performant ist es auch nicht, da CalDAV und CardDAV eigentlich nicht die Hauptfunktionalität von Owncloud sind und man noch einen riesigen Overhead an „Cloud“-Funktionalitäten hat. Außerdem musste ich manchmal an der Korrektheit der Software zweifeln – auch wenn ich nicht beweisen kann, dass es an Owncloud lag – da irgendwann mal ein paar Aufgaben im Kalender gefehlt haben, und dafür ein paar andere doppelt waren.

Baikal for the Rescue

Nun habe ich mit Baikal einen neuen CalDAV-Server gefunden und ich muss wirklich sagen, er erfüllt (fast) alle meine Ansprüche.

Zuallererst bringt Baikal keinen unnötigen Schnickschnack mit, sondern nur die CalDAV/CardDAV-Funktionalität. Ein kleines Admin-Webinterface ist auch dabei, sonst nichts. Es ist relativ leicht zu installieren, scheint recht effizient zu laufen und funktioniert einwandfrei. Eine gute Installationsanleitung findet sich hier. Ich habe zuerst Version 0.2.7 installiert und vor ein paar Tagen auf 0.3.4 geupdatet und hatte überhaupt keine Probleme damit.

Ist Baikal also Perfekt?

Wie jede andere Software hat Baikal auch seine Nachteile. Zum einen ist die Dokumentation miserabel und die Funktionalität findet sich nicht immer da, wo man sie gerade erwartet hätte. So ist das Webinterface beispielsweise nur vom Benutzer „admin“ benutzbar, was bei mir zuerst für Verwirrung gesorgt hat (Der Benutzername ist sogar hardgecodet, ich hab es mir im Code angesehen). Normale Benutzer können so keine eigenen Kalender über das Admininterface anlegen. Das geht nur direkt über das darunterliegende SabreDAV in einem extrem hässlichen Interface. Wie man als normaler Nutzer sein Passwort ändert, habe ich noch nicht herausgefunden. Da ich aber der einzige Benutzer bin, stört mich das alles nicht.

Die Entwickler scheinen außerdem nicht wirklich auf Sicherheit bedacht zu sein. Das Webinterface ist durchgehend anfällig für CSRF und man kann mit einem einfachen GET-Request ganze Benutzer und ihre Kalender aus der Datenbank löschen, was die Entwickler aber nicht zu stören scheint. Auf der GitHub-Seite gibt es schon seit einiger Zeit ein Issue dafür, die Entwickler meinen aber, es gebe „wichtigeres“ zu tun.

Zugegebenermaßen hat auch Baikal keine Autoupdatefunktion, das Updaten geht jedoch viel schneller und einfacher als bei Owncloud und lässt sich wahrscheinlich mit einem Skript automatisieren.

Wenn man aber der einzige Benutzer dieser Software ist, der sich darüber hinaus nur einmal ins Admininterface eingeloggt hat, um seine Kalender zu erstellen und sie dann einfach nur laufen lässt, ist Baikal wohl der beste CalDAV-Server, den es gibt.

Fußnoten:

* OK, so schlimm ist es nun auch nicht. Die kritischen Code-Execution-Lücken konnten nur von authentifizierten Nutzern durchgeführt werden und ich bin der einzige Benutzer. Für Installationen mit nicht vertrauenswürdigen Nutzern (alle Nutzer außer dem Admin) trifft das aber dennoch zu.

Resize Bcache Caching Device

Bcache is a cache for Linux. It can be used when you have a normal HDD and a faster SSD in your computer to let the SSD or part of the SSD act as a cache for the HDD to improve overall system performance. There is plenty of information on how to resize the backing device (the partition on the HDD) but I couldn’t find any information on how to resize the caching device without losing the data on the backing device. However a couple of weeks ago I was able to achieve this and I now want to share what I still remember of it.

I write the following from memory and I am not entirely sure that this is exactly what I did. Follow these instructions at your own risk and make a backup of your data (you should have a backup of your data anyway). If you find my explanation to be vague, refer to the Arch Linux wiki or ask a question in the comments.

 1. Detach the backing device from your caching device

# echo 1 > /sys/block/sdX/sdX[Y]/bcache/detach

Doing this will make Bcache ignore the caching device and forward every hard disk access to the backing device and the old caching device is no longer needed.

2. Resize the caching device

Now we can actually resize the caching device. The filesystem on the caching device itself can’t be resized so we will just resize the underlying partition and create a new caching device on the partition. I use LVM so what I did was something like the following:

# lvresize -L -20G VolumeGroup/cache

If you don’t use LVM it could be a little bit more difficult to resize the partition but there are plenty of partitioning tools out there so I will assume that you can find out how to do it.

3. Creating a new caching device

The last step destroyed the bcache file system on the partition so we have to create a new one.

# make-bcache -C /dev/VolumeGroup/cache

The above command will  create a new caching device on /dev/VolumeGroup/cache.

4. Reattach the backing device to the caching device

Now we can put it all together again. To reattach the backing device we first have to find out the cset.uuid of the caching device. Assuming that the caching device is located at /dev/VolumeGroup/cache we can do this with

bcache-super-show /dev/VolumeGroup/cache | grep cset.uuid

The backing device then can be reattached with

# echo cset.uuid > /sys/block/bcache0/bcache/attach

assuming that your caching device is bcache0.

Now the cache should be working properly. You can check this by executing

# cat /sys/block/bcache0/bcache/state

If the above has the output „clean“ then you have successfully resized your caching device.

Case-Insensitive Autocompletion for Bash

Autocompletion is a pretty nice feature when working in the shell. However the most commonly used Bourne-Again-Shell (Bash) does not use case-insensitive autocompletion by default like the less common zsh does.

But here’s the good news:  You can configure it to do so.

If you want to set this system-wide, all you have to do is add the following line to your /etc/inputrc :

set completion-ignore-case on

You will need root privileges to do this. If you don’t have root access or you only want to set this for your account, just add the above line to your ~/.inputrc file (you probably will have to create it first).