Bei einer Fritzbox 7412 das WLAN aktivieren

Seit einiger Zeit bieten 1&1 zu ihren DSL-Verträgen keine kostenlosen WLAN-Router mehr an. Um einen WLAN-Router zu bekommen, muss man 2,99€ extra im Monat zahlen, was eine ziemliche Frechheit ist, insbesondere weil der ausgelieferte Router, die FRITZ!Box 7412, der gleiche ist. In der kostenlosen Version ist das WLAN lediglich in der Firmware deaktiviert. Das heißt allerdings, dass man durch aufspielen einer anderen Firmware die WLAN-Funktionalität aktivieren kann. Lustigerweise wurde sich nicht einmal die Mühe gemacht, eine andere Verpackung zu produzieren, und so wird auf dem Karton die FRITZ!Box verwirrenderweise als WLAN-Router bezeichnet.

Bei der folgenden Anleitung gehe ich davon aus, dass die FRITZ!Box noch nicht eingerichtet wurde, da das sowieso danach nochmal gemacht werden muss. Außerdem gehe ich davon aus, dass viele Leute die FRITZ!Box gar nicht einrichten wollen, und das WLAN nur zwecks besseren Weiterverkaufsmöglichkeiten aktivieren und bei sich zuhause einen gescheiten Router benutzen.

  1. Die aktuelle Firmware von der AVM-Seite downloaden: https://ftp.avm.de/fritzbox/fritzbox-7412/deutschland/fritz.os/
  2. Die FRITZ!Box in die Steckdose stecken
  3. Die FRITZ!Box per Netzwerkkabel mit einem Rechner verbinden
  4. Das Konfigurationsinterface der FRITZ!Box aufrufen; dazu in einem Browser fritz.box aufrufen
  5. Alle Einrichtungsdialoge überspringen
  6. Durch einen Klick auf „Ansicht: Standard“ in der Fußleiste die erweiterte Ansicht freischalten
  7. In der Seitenleiste auf „System“ klicken
  8. In der Seitenleiste auf „Update“ klicken
  9. Oben auf den Reiter „FRITZ!OS-Datei“ klicken
  10. Das Häkchen bei „Sicherungsdatei vor dem Update erstellen“ entfernen
  11. Im folgenden Menüpunkt die in Schritt 1 heruntergeladene Datei hochladen
  12. Auf „Update starten“ klicken
  13. Warten, bis man wieder auf die Startseite weitergeleitet wird
  14. Wieder alle Einrichtungsdialoge überspringen
  15. In der Seitenleiste auf „System“ klicken
  16. In der Seitenleiste auf „Sicherung“ klicken
  17. Oben auf den Reiter „Werkseinstellungen“ klicken
  18. In diesem Menü die FRITZ!Box auf Werkseinstellungen zurücksetzen

Jetzt sollte bei der FRITZ!Box das WLAN aktiviert sein und auch die WLAN-LED am Router leuchten.

How to Cite a Website with BibTeX

Citing a website in some kind of scientific writing can be really annoying. If you use LaTeX (which you should do) to write it, you probably will use BibTeX for bibliography managment. However, because the BibTeX format has been relatively unchanged since 1985 there is no entry type for a website. The solution to this is just using the newer BibLaTeX which supports the @ONLINE entry type.

In order to switch from BibTeX to BibLaTeX you just need to add \usepackage{biblatex} to your preamble. Assuming your bibliography file is called bibliography.bib you will also have to add \bibliography{bibliography.bib} to the preamble. Printing the bibliography is done by \printbibliography instead of \bibliography{bibliography}. Instead of running bibtex on the .aux-file after running pdflatex for the first time, you will have to run biber on the generated .bcf-file. Much more about BibTeX and bibliography management in general can be found here.

Having done all this, this website for example could be cited after adding the following to your bibliography file:

@online{cite_key, 
    author = {Jonas Mönnig},
    title = {How to Cite a Website with BibTeX},
    year = 2016,
    url = {https://jonas-moennig.de/how-to-cite-a-website-with-bibtex/ },
    urldate = {2016-07-26}
}

This is a simple format but still annoying to type manually. Wouldn’t it be easier if you could just generate these entries automatically? That is why I have written a Firefox Add-on that does exactly this. It tries to extract author, title and publishing year from the website and generates an @ONLINE entry that can be copied and pasted into your .bib file. You still have to change the cite key manually as the add-on cannot guess what you would prefer. You can find the add-on in the Mozilla Add-on store.

Unfortunately version 1.0 requires Firefox 48 which at the time of this writing is only available as a beta version. A stable version can be expected mid-August. Until then you can install version 0.9.1 manually here.

If you don’t like the default template, for example because you want to use plain BibTeX and not BibLaTeX, from version 1.0 upwards you can change the template in the preferences. For a plain BibTeX format you could simply use

@misc{cite_key,
    author = {$author$},
    title = {$title$},
    year = $year$,
    howpublished = {\url{$url$}},
    note = {Accessed: $urldate$}
}

which would result to something like this:

@misc{cite_key,
    author = {jonas},
    title = {How to Cite a Website with BibTeX},
    year = 2016,
    howpublished = {\url{https://jonas-moennig.de/how-to-cite-a-website-with-bibtex/}},
    note = {Accessed: 2016-07-26}
}

Sometimes the add-on has multiple guesses available for author name, title and publishing year. In this case you can click on the current value to open a menu with all of the guesses from which you can choose from. Sometimes however, it doesn’t find the right values at all in which case you have to fill in the blanks manually.

As the add-on uses the WebExtension standard it can be easily ported to Chrome. If you want the add-on to be released as a Chrome extension, you can just leave a comment down below or feel free to fork the project on GitHub and do it yourself.

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.

Let’s Encrypt ist das Beste überhaupt

SSL-Zertifikate zu erstellen war früher sehr nervig. Zuerst musste man sich mit dem unzumutbaren OpenSSL-Syntax herum ärgern und dann die überteuerten Preise der „Zertifikatsmafia“ bezahlen, um ein von Browsern akzeptiertes Zertifikat zu erhalten. (Technisch gesehen war es möglich von StartSSL kostenlose Zertifikate zu bekommen, allerdings nicht für Subdomains und das Widerrufen von Zertifikaten war sehr teuer.)

Zum Glück ändert sich das jetzt, da Let’s Encrypt seit einiger Zeit in der Public-Beta Phase ist. Let’s Encrypt ist eine Certificate Authority (CA), die unter anderem von Mozilla und der EFF gesponsert wird und deren Ziel es ist, das Erstellen von SSL-Zertifikaten unkompliziert zu machen. Dadurch soll verschlüsselter Datentransfer im Internet gefördert werden. Durch den einmaligen Aufruf eines Kommandozeilenprogramms wird ein von Let’s Encrypt validiertes Zertifikat erstellt und der Webserver dazu konfiguriert, es zu benutzen. Und das beste ist, es kostet überhaupt nichts.

Da Let’s Encrypt noch in der Public-Beta ist, ist das ganze noch nicht so komfortabel, wie es einmal sein soll. Es ist jedoch hundertmal einfacher als mit der klassischen Methode.

Da ich Ubuntu-Server 14.04 benutze, und es dafür noch kein Paket gibt, musste ich erst mal das Git-Repository klonen. Dort steht der Wrapper „letsencrypt-auto“ bereit, der Abhängigkeiten für den Client automatisch auflöst und automatische Updates durchführt.

Für die Validierung der Domain und das Erstellen und die Installation des Zertifikats stehen verschiedene Optionen zur Verfügung. Eine davon ist, dass der Let’s Encrypt Client direkt über den Webserver die Validierung durchführt und das erhaltene Zertifikat automatisch auf diesem installiert. Da ich aber keine Lust darauf habe, dass experimentelle Software mir in meiner Serverkonfiguration herum pfuscht, habe ich die „webroot“-Variante gewählt. Dabei wird im obersten Verzeichnis der Webseite („webroot“) der zu validierenden Domain ein Token platziert, das vorher vom Validerungsserver erhalten wurde und das dieser dann abruft und so den Besitz der Domain bestätigt. Das Zertifikat wird bei dieser Variante nicht automatisch installiert. Wenn man für seinen Server bereits SSL-Zertifikate eingerichtet hat, ist das aber kein nennenswerter Mehraufwand.

Ein Zertifikat für alle meine SSL-verschlüsselten Webseiten konnte ich so mit

$ ./letsencrypt-auto certonly --webroot --webroot-path /var/www/wordpress -d 'jonas-moennig.de' -d 'www.jonas-moennig.de' \
--webroot-path /var/www/piwik -d 'piwik.jonas-moennig.de' -d 'www.piwik.jonas-moennig.de' \
--webroot-path /var/www/baikal/html -d 'baikal.jonas-moennig.de' --email jonas@jonas-moennig.de

erhalten.

Die Zertifikate sind nur für 90 Tage gültig, aber das macht nichts, da das Erneuern der Zertifikate noch viel einfacher ist als das Erstellen:

$ ./letsencrypt-auto renew --email jonas@jonas-moennig.de --agree-tos

erneuert alle Zertifikate, die in den nächsten 30 Tagen ablaufen automatisch. Die aktuellen Zertifikate werden immer in /etc/letsencrypt/live/<domain>/fullchain.pem und der dazugehörige Schlüssel in /etc/letsencrypt/live/<domain>/privkey.pem gespeichert, sodass man seine Webserverkonfiguration überhaupt nicht anfassen muss.

Man kann durchaus sagen, dass Let’s Encrypt das Erstellen von SSL-Zertifikaten revolutioniert hat und in den nächsten Jahren maßgeblich dazu beitragen wird, dass Verschlüsselung im Internet noch häufiger Anwendung findet.

Der Grund, warum Spam-Mails so schlecht sind

Neulich hat mal wieder eine Spam-Mail den Spamfilter überwunden und ist in meinen Posteingang gelangt. Da habe ich mir die gleiche Frage gestellt wie immer, wenn ich mal wieder Spam lese:

Warum sind diese Betrugsversuche so unglaublich miserabel?

Man denkt sich doch, dass nur komplette Vollidioten auf so etwas antworten. Und genau das ist der Grund! Wenn Spam-Mails gut geschrieben wären, würden viel zu viele Leute darauf antworten. Die ganzen Rechtschreibfehler und die unrealistischen Szenarien dienen nur dazu die schlauen Leute auszusieben, damit die Betrüger sich auf die Vollidioten konzentrieren können.

Briefmarkenautomaten sind scheiße

Letzte Woche musste ich einen Brief verschicken, was an sich schon schlimm genug ist, weil Briefe zu versenden ein total ineffizientes und veraltetes System ist. Da ich nur sehr selten Briefe verschicken muss, wollte ich mir eine einzelne Briefmarke aus einem Briefmarkenautomaten ziehen. Dann fing der Ärger an:

Der Briefmarkenautomat konnte kein Wechselgeld auszahlen, sondern erstattete den überschüssigen Betrag in BRIEFMARKEN. Zum Glück hatte ich 70 Cent passend, und zwar bestehend aus:

  • einem 50ct Stück
  • einem 10ct Stück
  • einem 5ct Stück
  • zwei 2ct Stücken
  • einem 1ct Stück

Nachdem ich alle kleinen Münzen mühselig eingeworfen hatte, fehlte nur noch das 50ct Stück. Dann entschied sich aber der Automat, dieses nicht anzunehmen. Dann entschloss er sich, den Vorgang abzubrechen und alle SECHS Münzen wieder auszuspucken. Ich hatte also den ganzen Aufwand umsonst betrieben.

Frustriert bezahlte ich meine Briefmarke mit einem 1€ Stück und bekam dafür die erwartete 70ct Briefmarke und drei 10ct Briefmarken, für die kein Mensch irgendeine Verwendung haben könnte. (Wenn ich das ganze noch zwei mal machen würde, könnte ich zwar sieben 10ct Briefmarken auf einen Brief kleben, das wäre aber ein bisschen lächerlich.)

Wie kann die Deutsche Post nur ein so nutzloses Gerät bei sich aufstellen? Warum werden überhaupt noch so viele Briefe versendet? (Die Antwort ist: Weil sie die Schriftform erfüllen. Aber das war eine rhetorische Frage.) Man bezahlt 70ct und es dauert länger als einen Tag, bis der Brief ankommt. Eine E-Mail kostet praktisch nichts und ist gefühlt sofort da. Hoffentlich gibt es bald keine Briefe mehr, denn Briefe sind genauso scheiße wie Briefmarkenautomaten.

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.

Lustiges Tool zum Dateitransfer

Wer kennt das nicht? Man will ganz schnell mal eine Datei von einem Gerät auf ein anderes transferieren, aber hat keinen USB-Stick parat. Dafür habe ich nun eine Lösung entwickelt. Auf fifo.jonas-moennig.de kann man genau eine Datei hochladen und sie dann genau einmal herunterladen. Ruft man die Seite auf und es liegt schon eine Datei auf dem Server, wird die Datei heruntergeladen und dann auf dem Server gelöscht. Ist keine Datei vorhanden, wird ein Formular angezeigt, über das man eine Datei hochladen kann. Versucht man eine Datei hochzuladen, obwohl schon eine andere auf dem Server liegt, wird die Anfrage zurückgewiesen.

Das Ganze funktioniert leider nur einwandfrei, wenn sehr wenige Leute es benutzen, da man jemand anderem die Datei vor der Nase wegschnappen kann und dieser diese dann nochmals hochladen muss. Da ich die Seite im Wesentlichen für mich geschrieben habe und nur wenige Leute diese Seite kennen werden, ist das aber ziemlich egal.

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).