MQTT-Server auf dem Raspberry Pi

Ziel

Das Ziel ist es, auf einem Raspberry Pi einen MQTT-Server („Broker“) einzurichten, wie er bspw. für die Heimautomatisierung benötigt wird. In dieser Anleitung werde ich Mosquitto als Broker verwenden.

Voraussetzungen

Benötigt wird ein fertig eingerichteter Raspberry Pi, den man über SSH erreichen kann und für den man Root-Rechte hat. Hilfreich ist es, wenn man schon weiß, wie MQTT ungefähr funktioniert. Das kann man in der Anleitung aber auch nebenbei lernen.

Installation und Test

Zunächst loggt man sich auf dem Raspberry Pi ein und installiert den MQTT-Server und die Clients per apt:

sudo apt install mosquitto mosquitto-clients

Danach läuft der Server bereits und man kann ihn testen. Dazu ruft man einen Client auf und abonniert alle Topics:

mosquitto_sub -h localhost -v -t '#'

Dabei bedeutet „-h localhost“ dass man den Server auf dem gleichen Rechner benutzt (also den, den man gerade installiert hat), das „-v“ sorgt für eine umfangreichere Ausgabe und „-t ‚#’“ schließlich bedeutet, dass man bei allen Topics mithören möchte, die der Broker verarbeitet. Topics kann man sich vorstellen als Kanäle, über die man wie im Funkverkehr empfangen und senden kann, wenn man den passenden Kanal eingestellt hat. Man sendet hier allerdings nur an den Broker und der verteilt die Nachricht an alle weiter, die diesen Kanal bzw. dieses Topic empfangen möchten.

Da (vermutlich) noch kein anderer Client verbunden ist, wird man noch keine Ausgabe sehen. Zum weiteren Testen öffnet man deshalb ein weiteres Fenster, in dem man sich erneut mit dem Raspberry Pi verbindet. Dort veröffentlicht man dann eine Nachricht über den Broker:

mosquitto_pub -h localhost -t 'Test-Topic' -m 'Hallo Welt!'

Mit „-t“ wählt man dazu das Topic aus, unter dem man veröffentlichen will und mit „-m“ gibt man die Nachricht an. Im ersten Fenster sieht man dann die Ausgabe, die der Broker veröffentlicht hat:

Test-Topic Hallo Welt!

Der MQTT-Broker funktioniert also.

Konfiguration des Brokers

In der Grundkonfiguration gibt es keine Beschränkungen für den Zugriff auf den Broker. Jeder (aus dem Heimnetz) kann also Nachrichten veröffentlichen oder mitlesen. In einer minimalen Konfiguration wollen wir den Zugang nun einschränken. Dazu legen wir hier beispielhaft zwei User an, die jeweils ein Passwort bekommen.

Als erstes muss man eine Datei erzeugen, die die User/Passwort-Kombinationen enthält. Die erzeugt man, indem man sie schon gleich mit dem ersten User füllt, nennen wir ihn hier user1.

mosquitto_passwd -c passwords user1

Man wird nach dem Passwort für den User gefragt und muss dies noch einmal wiederholen. Dann wird die gewünschte Datei erzeugt, hier heißt sie passwords (wie hinter „-c“ angegeben).

Nun kann man noch beliebig viele weitere User hinzufügen:

mosquitto_passwd passwords user2

Wieder muss man das Passwort zweimal eingeben. Alternativ kann man auch die Option „-b“ verwenden und das Passwort in die Kommandozeile schreiben. Allerdings sollte man sich angewöhnen, nie Passwörter in Kommandos zu verwenden, denn diese werden dadurch auch für andere Benutzer auf dem gleichen Rechner sichtbar. Auch wenn man niemanden sonst auf seinen Rechner lässt, sollte man sich solche Unachtsamkeiten erst gar nicht angewöhnen.

Wir haben jetzt eine Datei passwords im aktuellen Verzeichnis liegen, also vermutlich in unserem Heim-Verzeichnis. Diese Datei verschieben wir nun ins passende Verzeichnis unter /etc. Und weil es sicher sein soll, überschreiben wir die Datei an den Benutzer root und gewähren nur ihm Schreibzugriff darauf:

sudo mv passwords /etc/mosquitto/conf.d/
sudo chown root:root /etc/mosquitto/conf.d/passwords
sudo chmod 644 /etc/mosquitto/conf.d/passwords

Jetzt brauchen wir noch eine Konfigurationsdatei, die diese Datei einbindet und die den anonymen Zugang unterbindet. Die legen wir im gleichen Verzeichnis ab wie die Passwort-Datei (also /etc/mosquitto/conf.d). Am besten macht man das gleich als root. Ich benutze meinen Lieblingseditor vim (eine beliebte Alternative ist nano):

sudo vim /etc/mosquitto/conf.d/auth.conf

Man fügt zwei Zeilen ein:

allow_anonymous false
password_file /etc/mosquitto/conf.d/passwords

Damit die neue Konfiguration greift, muss man den Dienst noch neu starten. Das muss man auch dann tun, wenn man nur die Datei mit den Passwörtern ändert.

sudo systemctl restart mosquitto

Danach kann man sich nur noch mit Mosquitto verbinden, wenn man einen der zuvor eingerichteten Zugänge benutzt. Eine anonyme Verbindung funktioniert nicht mehr und natürlich auch keine mit falschen Zugangsdaten.

Der Vollständigkeit halber möchte ich noch erwähnen, wie man ausprobieren kann, ob ein Zugang funktioniert, auch wenn man dazu das Passwort im Kommando angeben muss, was man ja nicht tun sollte! Hier geht es aber nicht anders:

mosquitto_pub -u user1 -P passwort1 -t 'Test-Topic' -m 'Ich bin drin!'

Wenn man ein falsches Passwort benutzt oder einen unbekannten Benutzernamen, wird der Broker die Verbindung nicht zulassen. Ebenso nicht, wenn man gar keine Zugangsdaten angibt.

Die Angabe des Host-Namens habe ich hier übrigens weggelassen, denn localhost ist der Default-Host.

Schauen wir zum Abschluss noch auf die beiden Direktiven allow_anonymous und password_file. Diese kann man auch jeweils weg lassen. Das ergibt vier Möglichkeiten, die alle zu einem unterschiedlichen Verhalten führen.

Fall 1: Wenn man keine der beiden Direktiven benutzt, kann man sich wie am Anfang anonym einloggen, also ohne Zugangsdaten. Man kann aber sogar beliebige Zugangsdaten benutzen, wenn man möchte.

Fall 2: Der Zustand, den wir zuletzt hatten, sowohl allow_anonymous false als auch password_file sind vorhanden. Dann kann man sich nicht mehr anonym verbinden und muss gültige Zugangsdaten angeben.

Fall 3: Es wird nur allow_anonymous false verwendet. Dann kann man sich nicht mehr anonym verbinden. Man kann sich allerdings mit beliebigen (!) Zugangsdaten verbinden.

Fall 4: Es wird nur password_file angegeben. Dann kann man sich anonym einloggen. Man kann aber auch Zugangsdaten angeben. Wenn man das tut, müssen diese allerdings zu einem hinterlegten Zugang passen. Man sollte dann aber explizit allow_anonymous true setzen. Benutzen kann man das mit weiteren Einstellungen um bspw. allen Usern lesenden Zugriff zu ermöglichen, das Schreiben aber zu beschränken.

Soweit eine erste Grundeinrichtung, die ohne viele Umstände funktioniert. Es gibt noch viele Konfigurationsmöglichkeiten, mit dem man Mosquitto weiter absichern kann.

Wichtig: Man sollte sich klar darüber sein, dass in der vorgestellten Grundkonfiguration die Zugangsdaten unverschlüsselt über die Leitung gehen! Das ist ein Problem, wenn jemand anderes im Heimnetz mitlesen kann. Im Zweifelsfall sollte man seinen Mosquitto besser noch per SSL absichern. Wie das geht, ist allerdings einen eigenen Artikel wert.

Raspberry Pi einfach und schnell einrichten

Worum es geht

Ziel ist es, ein Linux-System auf einen Raspberry Pi zu bringen. Dieses soll im „headless“-Modus laufen, also ohne grafische Oberfläche. Damit bekommt man ein Server-Grundsystem, dass man für verschiedene Dienste nutzen kann, wie es bspw. für die Heimautomatisierung gebraucht wird.

Voraussetzungen

Das wird benötigt:

  • Ein Raspberry Pi. Ich benutze das Modell 3 B+, welches schon WLAN an Bord hat. Mit älteren Modellen plus WLAN-Adapter sollte es aber auch funktionieren, ebenso ganz ohne WLAN, wenn man mit einem Netzwerkkabel arbeitet.
  • Eine microSD-Speicherkarte. Ich benutze eine 16 GB-Karte. Es funktioniert aber auch mit weniger (und natürlich auch mit mehr) Speicher.
  • Eine Stromversorgung für das Gerät (Micro-USB-Anschluss, mindestens 2 Ampere).
  • Ggf. ein Netzwerkkabel, wenn es mit dem WLAN nicht sofort funktioniert oder man kein WLAN nutzen will.
  • Einen Rechner mit Internet-Zugang zur Vorbereitung bzw. zur „Fernbedienung“. Ich benutze für diese Anleitung einen Linux-Rechner, damit geht es am einfachsten. Wer Windows benutzt, sollte herausfinden können, wie man einen Schritt auf andere Weise hinbekommt, teilweise erläutere ich das.
  • Einen Kartenleser, mit dem man die Daten auf der SD-Karte ändern kann.
  • Grundwissen über Computer-Netzwerke, insbesondere wie man einen Rechner im eigenen Netz erreicht und wie man SSH benutzt.

Teil 1: Vorbereitungen am PC

Im ersten Teil wird das Betriebssystem heruntergeladen und dann die Speicherkarte so vorbereitet, dass sie im RasPi genutzt werden kann. Dazu benötigt man den RasPi zunächst nicht. Alle Arbeiten erfolgen am PC.

Als Linux-Betriebssystem für den RasPi benutze ich Raspbian. Dieses lädt man sich zunächst herunter. Benötigt wird die „Lite“-Variante, die keine grafische Benutzeroberfläche (Desktop) enthält. Zum Zeitpunkt des Schreiben dieses Artikels ist das Raspbian Stretch Lite. Dabei bezeichnet „Stretch“ die Debian-Version, auf der Raspbian basiert.

Download-Seite: https://www.raspberrypi.org/downloads/raspbian/

Die Desktop-Varianten auf der Seite funktionieren im Folgenden auch. Für ein schlankes, schnelles System ist aber „Lite“ die richtige Wahl.

Beim Herunterladen erhält man ein Zip-Archiv, das eine einzige Datei enthält, nämlich ein Image mit dem Betriebssystem. Diese Datei entpackt man. Sie hat die Dateiendung .img und heißt bei mir

2018-11-13-raspbian-stretch-lite.img

Dieses Image schreibt man nun auf die Speicherkarte. Im Folgenden wird beschrieben, wie das unter Linux geht.

Zunächst schließt man die Speicherkarte am PC an. Dann kann man nachschauen, als welches Gerät sie eingehängt wurde.

lsblk -o KNAME,TYPE,SIZE,MODEL | grep disk
sda       disk   1,8T SAMSUNG xxx
sdb disk 238,5G SAMSUNG SSD xxx
sdc disk 14,9G Mass-Storage
nvme0n1 disk 232,9G Samsung SSD xxx

In diesem Fall also unter sdc, zu erreichen unter /dev/sdc. Das merkt man sich und ändert es in den von mir angegebenen Befehlen entsprechend ab. Das ist äußerst wichtig, denn bei Benutzung eines falschen Devices schreibt man auf einen anderen Datenträger, bspw. eine Festplatte!

Die Karte enthielt vermutlich schon mindestens eine Partition, die automatisch eingehängt wurde. Die hänge ich zuerst aus und schreiben dann das Image auf die Karte (nicht vergessen: sdc ggf. anpassen!):

sudo umount /dev/sdc?*
sudo dd bs=4M if=2018-11-13-raspbian-stretch-lite.img of=/dev/sdc status=progress conv=fdatasync

Die Speicherkarte kann man danach abziehen und wieder anstecken. Das System entdeckt dann darauf zwei Partitionen: boot und rootfs. Einige Dateien darin werden nun so angepasst, dass das Betriebssystem später problemlos startet und kaum noch weitere Arbeiten nötig sind. Bei mir sind die beiden Partitionen auf der SD-Karte so eingehängt, dass ich sie über /media/$USER erreichen kann. Auf anderen Systemen ist der Pfad ggf. anders.

Zunächst muss man auf dem neuen System einen Zugang per SSH ermöglichen. Dazu legt man einfach eine leere Datei ssh an, die im Root-Verzeichnis der Partition boot liegen muss.

touch /media/$USER/boot/ssh

Als nächstes wird die Verwendung des WLANs vorbereitet. Wenn man dies bereits zu diesem Zeitpunkt macht, kann man sich später per WLAN auf dem RasPi einloggen und muss kein Netzwerkkabel anschließen.

Dazu legt man wiederum in der boot-Partition eine Datei wpa_supplicant.conf an (/media/$USER/boot/wpa_supplicant.conf), die folgenden Inhalt hat:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE

network={
ssid="WLAN-SSID"
psk="WLAN-Passwort"
}

An den Stellen WLAN-SSID und WLAN-Passwort muss man die Zugangsdaten zu seinem eigenen WLAN-Netz angeben. Als country habe ich DE angegeben, auch das sollte man ggf. anpassen.

Jetzt wäre man soweit, die Karte im RasPi einzusetzen, aber noch zwei Kleinigkeiten kann man am besten jetzt erledigen.

Zugang zum RasPi erhält man standardmäßig mit dem Benutzernamen pi und dem Passwort raspberry. Ich möchte aber mit meinem gewohnten Benutzernamen mac arbeiten und dazu keinen zweiten Account auf dem RasPi einrichten. Auch das Umbenennen ist später recht aufwendig. Deshalb machen wir das schon jetzt. Dazu werden mit zwei Kommandos ein paar Dateien in rootfs geändert:

sudo sed -i 's/\bpi\b/mac/g' /media/$USER/rootfs/etc/passwd /media/$USER/rootfs/etc/shadow /media/$USER/rootfs/etc/group
sudo mv /media/$USER/rootfs/home/pi /media/$USER/rootfs/home/mac

Das änderten den User pi zu mac und benennt das Home-Verzeichnis entsprechend um. Um einen eigenen Namen zu benutzen, muss das mac entsprechend an beiden Stellen geändert werden. Alternativ kann man auch die drei Dateien etc/passwd, /etc/shadow und /etc/group mit einem Editor so bearbeiten, dass man die Vorkommen von pi abändert in den bevorzugten Namen. Sie befinden sich in der Partition rootfs.

Zuletzt kann man noch den Host-Namen des Raspberrys schon jetzt ändern, um ihn später im eigenen Netz leichter finden zu können. Der voreingestellte Name ist raspberrypi und wird hier im Beispiel zu raspbian.

sudo sed -i 's/raspberrypi/raspbian/g' /media/$USER/rootfs/etc/hostname

Alternativ kann man auch die Datei /etc/hostname in rootfs mit einem Editor entsprechend ändern. Sie enthält nur eine Zeile mit dem späteren Hostnamen.

Das war es mit den Arbeiten am Dateisystem. Man hängt die Karte nun aus und kann sie anschließend vom PC abziehen.

sudo umount /media/$USER/boot /media/$USER/rootfs

Teil 2: Raspberry Pi konfigurieren

Die Speicherkarte steckt man nun in den RasPi und schließt ihn danach an den Strom an. Nach einer Weile sollte er im lokalen Netz auftauchen, entweder über WLAN verbunden, oder über ein angestecktes Netzwerkkabel. In der Standard-Konfiguration bekommt er per DHCP eine IP aus dem lokalen Netz zugewiesen. Alternativ kann er aber natürlich auch mit dem voreingestellten Namen angesprochen werden. In der Grundkonfiguration war das raspberrypi, oben habe ich das geändert in raspbian, welches ich nun benutzt. Ebenfalls benutze ich den geänderten Benutzernamen mac zum Einloggen. In der Grundkonfiguration war das pi.

Den RasPi erreicht man über SSH. Linux-Nutzer haben dafür alles an Bord. Windows-Nutzer werden vermutlich am ehesten PuTTY benutzen wollen.

ssh mac@raspbian

Das Standard-Passwort lautet raspberry (natürlich auch für den geänderten Benutzernamen). Und dieses sollte man auch als allererstes ändern. Wenn das Einloggen geklappt hat, gibt man ein

sudo raspi-config

… was man ein letztes Mal mit dem alten Passwort raspberry bestätigen muss.

Man wählt nun den ersten Menüpunkt Change User Password mit den Cursor-Tasten aus und drückt <Return>. Die Nachfrage bestätigt man erneut mit <Return> und gibt dann ein neues Passwort ein. Dieses muss man danach noch ein weiteres Mal zur Bestätigung eingeben. Danach hat man für den neuen Account ein eigenes Passwort (das man sich merken muss!).

Bevor man nun die weiteren Menüpunkte abarbeitet, sollte man zuerst den Punkt Update besuchen und das Tool auf den aktuellen Stand bringen. Es wird dann automatisch die aktuelle Version heruntergeladen und installiert und anschließend startet raspi-config neu.

Nun zu den weiteren Einstellmöglichkeiten. Unter Localisation Options sollte man unter Change Timezone die richtige Zeitzone auswählen, damit der RasPi später die richtige Uhrzeit hat. Unter Change Locale kann man zusätzlich de_DE.UTF-8 wählen (mit den Cursor-Tasten dorthin scrollen, mit der Leertaste auswählen und dann mit <Tab> aus der Auswahl springen). Diese Auswahl kann man danach als Default einstellen und enthält dann teilweise deutsche Meldungen im System.

Danach kann man sich die Advanced Options vornehmen. Expand Filesystem sollte auf modernen Systemen nicht mehr nötig sein, dort sollte die zweite Partition bereits beim ersten Start auf die maximale Größe gebracht worden sein. Das kann man gefahrlos aber auch ein zweites Mal machen. Unter Memory Split kann man die Größe des Grafik-Speichers verringern, denn man hat ja ein System ohne Desktop. Hier kann man 16 (MB) eingeben.

Damit ist man mit den wichtigen Punkten durch und kann raspi-config über Finish beenden. Evtl. möchte das System danach neu booten, je nachdem, was man alles ausprobiert hat.

Nun aktualisiert man noch die Software des kompletten Systems:

sudo apt update && sudo apt upgrade

… was man mit dem eigenen Passwort bestätigen muss. Ist dieser Vorgang durch, hat man ein vollständiges Linux-System, das auf dem aktuellen Stand ist.

Nun kann man noch individuelle Einstellungen vornehmen und bspw. weitere Pakete installieren mit Software, die man benötigt. Ich bevorzuge bspw. den Editor vim. Zusätzlich installiere ich auch git, was für spätere Erweiterungen sinnvoll sein kann. Software-Pakete kann man aber jederzeit auf diese Weise installieren, das muss nicht zu diesem Zeitpunkt passieren.

sudo apt install vim git

Außerdem logge ich mich am liebsten ohne Passwort ein. Dazu kopiert man einen zuvor erzeugten SSH-Key auf den RasPi (vom PC aus, von wo man sich einloggen möchte):

ssh-copy-id -i ~/.ssh/id_rsa.pub mac@raspbian

Damit ist die Grundinstallation des Raspberry Pi fertig. Je nach gewünschter weiterer Nutzung kann man nun noch weitere Software installieren und den RasPi für den Einsatz als Server oder Arbeitsmaschine ausrüsten.

Noch ein kleiner Hinweis zum Ausschalten des Systems. Wie jeden anderen Computer darf man den RasPi nicht einfach ausschalten (also den Stecker ziehen). Vorher muss man das System herunterfahren. Dies macht man mit diesem Kommando:

sudo poweroff

Threema statt WhatsApp

In zwei Wochen wird der Messenger WhatsApp zum ersten Mal für mich kostenpflichtig. Zeit für ein Resümee. Zeit für den Ausstieg. Ein Blick auf den Abschnitt „Sicherheit“ bei Wikipedia reicht schon aus, um genügend Gründe zu haben, dieses Produkt nicht finanziell unterstützen zu wollen, und sei es auch nur mit einem recht mickrigen Betrag, der jährlich fällig wird. WhatsApp ist zu löchrig, zu unsicher, geht zu nachlässig mit meinen Daten um. Dafür sind auch 99 US-Cent im Jahr zu viel.

Ganz sicher kommt nun der Einwand „du benutzt doch auch Google+ und Skype“ (um nur einige Dienste zu nennen). Das stimmt, aber die bekommen auch kein Geld von mir. Okay, sie bekommen meine Daten, davon leben insbesondere Dienste wie Google und Facebook. In diesem Punkt bin ich nicht ganz konsequent, das muss ich zugeben. Aber von einigen Diensten fühle ich mich inzwischen abhängig, da beiße ich (ungern) in den sauren Apfel.

Von WhatsApp ist aber niemand abhängig. Es gibt inzwischen zahlreiche Alternativen, die es besser machen. Mein Favorit ist Threema geworden. Die Seite zeigt schon auf den ersten Blick, was hier genau besser ist: Datenschutz wird ernst genommen und dies wird durch Offenheit deutlich gemacht. Die Betreiber verzichten darauf, meine Mailadresse und meine Telefonnummer zu erfahren (oder die meiner Kontakte), ganz zu schweigen davon, dass sie diese speichern würden. Die gesamte Kommunikation erfolgt verschlüsselt, vom einen Ende bis zum anderen. Da kann niemand mitlesen, auch der Dienstanbieter selbst nicht (und die NSA natürlich auch nicht).

Threema hat mich also überzeugt. Zukünftig wird dies mein Messenger der Wahl sein. WhatsApp hat ausgedient. Survival of the Fittest.

Wer also zukünftig mal eben übers Handy mit mir (auf Textbasis) kommunizieren will, hat dafür zwei Möglichkeiten:

  • Google Hangouts: Von der Datenkrake Google höchstpersönlich. Nicht viel besser als WhatsApp, aber kostenlos und zweckmäßig. Hat sich als sehr nützlich erwiesen, besonders weil man auch vom Computer aus schreiben kann. Für alle diejenigen optimal, die sowieso einen Account bei Google haben.
  • Threema: Die sichere Alternative. Besonders gefällt mir das dreistufige Sicherheitssystem. Ich freue mich schon auf den ersten „grünen“ Kontakt.

Als weitere Alternativen, um im Kontakt zu bleiben, gibt es noch Skype (Microsoft, uah!), die gute alte E-Mail (völlig unterschätzt inzwischen), SMS und das Telefon. Aber was spricht dagegen, Threema parallel zu den anderen Messengern zu installieren, die man nicht aufgeben mag? Mir fällt da nichts ein.

Also, dann bis bald auf Threema!

Gespräch mit den Reviewern

Ende August führte die Archivierung des Caches „STIRB EWIG“ durch den Reviewer eigengott zu einer Protestaktion unter Cache-Ownern. Diese schlossen ihre Caches für zehn Tage, um gegen „Reviewerwillkür“ zu protestieren, die sie durch die Zwangsarchivierung gegeben sahen. Der Cache wurde archiviert, weil Stationen mit Schrauben an Bäumen befestigt waren. Der Owner wurde nicht dazu befragt, der Cache wurde ohne Rücksprache geschlossen.

In den öffentlich geführten Diskussionen während des Protests ging es teilweise hoch her, so dass ein sachlicher Austausch von Argumenten unmöglich erschien. Sowohl von Befürwortern als auch von Gegnern der Aktion wurde scharf geschossen, so dass die wenigen sachlichen Beiträge meistens untergingen. Es beteiligten sich auch einige Reviewer an der Diskussion und gossen mit unbedachten Worten leider zusätzliches Öl ins Feuer. So blieben nach dem Ende der Protestaktion viele Fragen offen.

Treffen mit den Reviewern

Aus diesem unbefriedigenden Zustand heraus entstand eine Initiative, das Gespräch mit den Reviewern zu suchen. Dabei sollte es darum gehen, im kleinen Kreis die Kernpunkte des Protests darzustellen und bestenfalls Lösungen zu finden. Der Kontakt zu den Reviewern war schnell hergestellt und diese zeigten sich sehr interessiert an einem Austausch. Nachdem alle vorgesehenen Beteiligten aus dem Urlaub zurück waren, wurden ein Termin und ein Ort für ein Treffen festgemacht. Von Seiten der Reviewer nahmen eigengott und Obelodalix daran teil. Als Abordnung der Cache-Owner waren austriaka, Limbofische, Feuerkaefer und ich (macronom) vertreten. In einem gemütlichen Lokal in Bergisch Gladbach trafen wir uns bei gutem Essen zu einem Gespräch.

Während unseres Gesprächs wurden sehr viele verschiedene Themen angesprochen, teilweise auch solche, die nichts mit der Protestaktion zu tun hatten. Ich beschränke mich in diesem Bericht auf einen wesentlichen Aspekt des Treffens, nämlich die Frage, warum die Reviewer so handeln, wie sie es tun. Der Protest stand unter dem Motto „gegen Reviewerwillkür“ und es galt herauszufinden, was an diesem Vorwurf dran ist.

Die Geocaching-Welt

Nachdem wir uns etwas beschnuppert hatten, führte uns eigengott mit vorbereiteten Schaubildern ins Thema ein. Danach gibt es zwei Bereiche, die getrennt voneinander betrachtet werden müssen und die ihre eigenen Regeln, Erfordernisse und auch Zwänge haben.

Zunächst einmal gibt es die „Geocaching-Welt“. Darin tummeln sich drei Gruppen: Der Plattformbetreiber (in diesem Fall Groundspeak), der die Spielregeln innerhalb dieser „Welt“ vorgibt. Die Reviewer, die sich um die Einhaltung dieser Regeln kümmern. Und schließlich die Cacher und insbesondere auch die Owner, die an die vorgegebenen Regeln gebunden sind.

Die Regeln in der Geocaching-Welt sind in den Guidelines festgelegt. Sie regeln beispielsweise, welche Cache-Arten es gibt, welche Behältergrößen es gibt, welche Arten von Logs es gibt, dass nichts vergraben werden darf und vieles mehr. Ein typisches Beispiel ist wohl die Abstandsregel, die (etwas vereinfacht) besagt, dass Caches 161 Meter voneinander entfernt liegen müssen. Alle diese Regeln beziehen sich ausschließlich aufs Geocaching. Sie haben in der „realen Welt“ keine Bedeutung, aber jeder Geocacher hat sich mit Anmeldung auf der Plattform mit ihnen einverstanden erklärt und ist somit an sie gebunden.

Das Erfreuliche an der Geocaching-Welt ist, dass hier drei Parteien aufeinander treffen, die ein gemeinsames Ziel haben, nämlich Spaß am Geocaching. Obelodalix machte uns darauf aufmerksam, dass die Regeln in diesem Rahmen durchaus verhandelbar sind. Er nannte als Beispiel ein Event, das möglicherweise nicht ganz zu den vorgegebenen Regeln passt, das man aber durchaus mit einer Ausnahmegenehmigung erlauben könnte. In der Geocaching-Welt können Regeln eben manchmal so verbogen werden, dass sie dem Spaß am Spiel nicht entgegen stehen. Außerdem kann sich jeder Cacher aktiv an der Gestaltung der Regeln beteiligen, indem er sich mit Vorschlägen direkt an Groundspeak wendet.

Die „reale“ Welt

Anders sieht es in der „realen Welt“ aus. Hier heißen die Regeln „Gesetze“ und diese lassen sich weder verhandeln, noch (direkt) verändern. Und da Geocaching in dieser realen Welt stattfindet – die Geocaching-Welt also Teil der realen Welt ist – sind auch alle Teilnehmer des Spiels an diese Regeln (Gesetze) gebunden. Mit anderen Worten: Wenn ich etwas in der realen Welt nicht tun darf, darf ich es in der Geocaching-Welt auch nicht tun.

Ich muss mich als Geocacher also an die Gesetze halten? Tatsächlich scheint es vielen Cachern häufig schwer zu fallen, sich diese eigentliche Selbstverständlich­keit bewusst zu machen. Es gibt also (Spiel-)Regeln, die nicht das Geocaching als solches betreffen, an die man sich als Cacher aber dennoch halten muss.

Viele Cacher scheinen trotzdem zu denken „ich bin Geocacher, ich darf das“, als würden die Zugehörigkeit zu einer Gruppe alle Gesetze aufheben. Manchmal wird der Sinn bestimmter Regeln auch aus Unkenntnis oder Unwissenheit nicht verstanden und die Regel daher als solche in Frage gestellt. Vielfach hört man beispielsweise „ein Nagel schadet einem Baum doch gar nicht“. Aber wenn dein Auto zerkratzt wird, dann fährt es auch nicht schlechter. Trotzdem wärst du ganz schön verärgert, wenn es jemand täte. Und auch für andere Verbote gibt es gute Gründe. Viele Probleme könnte man vermeiden, wenn man sich vor Ort fragen würde: Mache ich das hier gerade nur, weil ich Geocacher bin oder würde ich mich sonst auch so verhalten?

Geocaching in der Welt

Okay, Geocacher halten sich also manchmal nicht an Gesetze. Wo ist das Problem? Solange ich die Regeln der Geocaching-Welt beachte, ist in dieser Welt doch alles in Ordnung, oder?

Das Problem ist, dass wir inzwischen beobachtet werden. Und zwar in der realen Welt. Wenn sich früher ein paar Geocacher auf verbotenem Gelände rumgedrückt haben, war das kein großes Problem (aber dennoch: ein Problem war es schon immer!). Wenn einzelne Cacher quer durch den Wald gelaufen sind, auch nicht. Vielleicht konnte man sogar in der Geocaching-Welt über sowas hinweg sehen, solange Geocaching nicht im Bewusstsein der Öffentlichkeit war. Aber die Zeiten haben sich geändert.

Inzwischen ist Geocaching längst nicht mehr das geheime Hobby, das es mal war. Jeder Förster weiß inzwischen, dass es Cacher gibt, die durch seinen Wald laufen. Geocaching ist in der realen Welt angekommen und damit auch seinen Zwängen unterworfen.

Und was bedeutet das? Nun, als es noch keine Autos gab, brauchte man auch keine Geschwindigkeitsbegrenzungen. Erst als Autos verbreiteter wurden und das schnelle Fahren zum Problem wurde, brauchte man spezielle Regeln, die nur auf das Fahren von Kraftfahrzeugen zugeschnitten waren. Ähnlich verhält es sich mit dem Geocaching. Wenn die Öffentlichkeit den Eindruck bekommt, dass Geocaching ein Problem darstellt, wird es unweigerlich auch Vorschriften geben, die das Geocaching einschränken werden. Oder möglicherweise sogar ganz verbieten werden.

Die ersten Einschränkungen dieser Art gibt es bereits auf lokaler Ebene. Es gibt Gebiete, in denen Caches nicht mehr erlaubt sind. Und auch auf höherer Ebene gibt es längst Diskussionen, ob es spezielle Vorschriften geben sollte, die das Geocaching reglementieren oder ganz verbieten. Es dürfte außer Frage stehen, dass dies nicht in unserem Interesse sein kann.

Wirkliche Welt – echte Schranken

Geocaching steht also unter Beobachtung und ist von Einschränkungen oder Verboten bedroht. Aber was hat das mit der Schraube im Baum zu tun, wegen der der Cache archiviert wurde?

Hier schließt sich nun der Kreis. Sollte die Öffentlichkeit den Eindruck bekommen, dass Geocaching ein Problem darstellt, werden wir zwangsläufig Gesetze bekommen, die unser Hobby reglementieren. Folglich sollte uns daran gelegen sein, als Geocacher alles zu vermeiden, was nach außen problematisch wirken kann. Groundspeak setzt sich (über die Reviewer als Ausführende) gerade verstärkt dafür ein. Wenn ein Problem nach „außen“ sichtbar wird, wird es sofort intern gelöst. Ein Cache, der gegen Gesetze oder Vorschriften der „realen Welt“ verstößt, wird innerhalb der Geocaching-Welt entfernt. Nach außen wird damit signalisiert: Wir haben alles im Griff, die Selbstkontrolle funktioniert, es sind keine speziellen Vorschriften für uns nötig.

Damit wird auch klar, warum sofort archiviert wurde. Probleme, die die reale Welt betreffen, müssen sofort gelöst werden. Der Cache muss auf der öffentlich sichtbaren Karte verschwinden. Probleme in der Geocaching-Welt kann man dagegen anders behandeln. Hier reicht es meist, den Cache vorerst zu deaktivieren und dem Owner Zeit zur Verbesserung des Caches zu geben.

Mein Fazit

Das Gespräch mit den Reviewern hat sich gelohnt, nicht nur wegen des leckeren Essens. Obelodalix und eigengott konnten uns einige Aspekte verdeutlichen, die wir zuvor nicht so klar gesehen hatten. Vom Vorwurf der Willkür kann man sie frei sprechen. Ihr Vorgehen folgt durchaus logischen Regeln und hat letztendlich das Ziel, unser Hobby zu schützen. Das war uns in dieser Deutlichkeit zuvor nicht klar.

Mir ist bewusst, dass viele Cacher nach der Lektüre meines Berichts aufheulen werden. „Was, ich darf keinen Lost Place mehr besuchen? Keine Dosen in den Boden einlassen? So macht das Hobby keinen Spaß mehr!“ Tja, liebe Leute, das Hobby wird euch aber noch viel weniger Spaß machen, wenn uns alle Freiheiten genommen werden und nicht nur ein paar. Jeder öffentlich bekannt gewordene Regelverstoß ist ein Sargnagel für unser Hobby! Wir müssen akzeptieren, dass es auch beim Geocachen Grenzen gibt. Ich sehe keine Alternative. Die Zeiten haben sich geändert.

Die Rätselzeit hat begonnen

Ich merke, dass meine Rätselcaches (auch Mysteries genannt) in den letzten zwei Wochen endlich wieder häufiger angegangen werden. In den Sommermonaten tat sich fast gar nichts, da bekamen die Dosen fast häufiger von mir Besuch als von anderen Cachern. Die langen Abende in Herbst und Winter laden wohl eher zum Lösen von Rätseln ein, während im Sommer die einfachen Punkte eingefahren werden.

Also ist es Zeit für mich, meine auf Halde liegenden Rätsel in Listings zu verwandeln und diese zu veröffentlichen. Derzeit warten noch vier fest geplante Mysteries aus der „Geo-Serie“ darauf, sowie ein paar weitere Ideen.

Deutschlandreise IIDen Anfang macht heute der zweite Teil der „Deutschlandreise“. Der Cache geht auf den Plattformen von opencaching.de und geocaching.com gleichzeitig ins Rennen, wobei Opencaching zwangsläufig die Nase vorn hat, weil es dort keine Reviewer gibt. Ein kleines Risiko gehe ich damit allerdings auch ein, denn man weiß ja nie, was die Vasallen von Groundspeak für Einwände vorbringen, die einer Veröffentlichung im Wege stehen. Aber ich bin zuversichtlich, alle Bedingungen erfüllt zu haben.

Ich würde mich jedenfalls darüber freuen, wenn die Deutschlandreise II auch Logs bei opencaching.de bekommen würde. Der Streik vor ein paar Wochen hat immerhin dafür gesorgt, dass viele bestehende Caches, die vorher „GC-only“ waren, nun auch auf dieser Plattform zu finden sind.

E.ON lässt Caches in Kirchhellen archivieren

Dies ist eine Kopie meines Artikels im Bottroper Forum.

Ich habe nun in dem Fall der beiden archivierten Caches einiges recherchiert. Ich habe Rückmeldungen von den beiden betroffenen Ownern, vom Reviewer, der die Caches archiviert hat und ich habe mit einer zuständigen Mitarbeiterin von E.ON gesprochen, auf deren Grundstücken die Caches lagen.

Nochmals zur Erinnerung: Am 9.5.2012 wurden die beiden Caches „Gladorgelbot“ und „Der Schatz des Grafen“ vom Reviewer Obelodalix archiviert. Als Begründung wurde angegeben, dass die Owner keine Genehmigung des Grundstückbesitzers eingeholt hätten und damit gegen die Richtlinien von Groundspeak verstoßen hätten. Weitere Informationen gab es nicht, weder für die Owner, noch für die Öffentlichkeit.

Bei vielen von uns ist das rigorose Vorgehen von Groundspeak in diesem Fall sicher auf Verwunderung gestoßen. Ich habe mich daher entschlossen, etwas über die Hintergründe herauszufinden.

Zunächst bestätigten mir die beiden betroffenen Owner, dass die Archivierung ohne Vorwarnung kam. Ihnen wurde im Vorfeld keine Möglichkeit gegeben, die Caches zu verlegen oder selbst zu archivieren, noch wurden sie informiert, wer die Archivierung verlangt hatte und auf wessen Grundstücken die Caches überhaupt lagen. Es gab auch keinen direkten Kontakt zu dem Grundstückeigentümern selbst.

Vom Reviewer, der die Caches archiviert hatte, erfuhr ich dann zumindest einiges zu den Hintergründen. Die Archivierung der Caches wurde von der E.ON AG gewünscht, der im Raum Kirchhellen/Dorsten/Gladbeck drei Waldstücke gehören (es ist das Gebiet östlich der beiden Freizeitparks). Diesem Wunsch wurde entsprochen und die Caches wurden mit Hinweis auf die fehlende Genehmigung archiviert.

Nachdem ich nun wusste, von wem die Archivierungen ursprünglich ausgingen, besichtigte ich zunächst die Orte, wo die Caches lagen. Es war auffällig, dass an mehreren Stellen Arbeiten im Wald stattfanden. Dort wurden teils großflächig Bäume gefällt. Im Fall von „Gladorgelbot“ hatten die Arbeiten den Ort des Finals noch nicht erreicht (es war ansonsten ein „Ablese-Multi“), während der Tradi „Der Schatz des Grafen“ direkt an ein Gebiet grenzte, wo Bäume gefällt worden waren. Während der Behälter des Tradis verschwunden war (wie der Owner mir berichtete), war das Final des Multis noch vorhanden (wie ich selbst festgestellt habe).

Ich versuchte daraufhin, Kontakt zur E.ON AG herzustellen, was einige Zeit dauerte. Bei einem großen Unternehmen mit langen Wegen ist das aber keine Überraschung. Heute konnte ich dann mit einer Mitarbeiterin von E.ON sprechen, die für die Verwaltung der betroffenen Waldstücke zuständig ist. Sie bestätigte mir zunächst, dass die Archivierung tatsächlich von der E.ON AG ausging. Sie hatte sich direkt an Groundspeak in Seattle gewandt und dort um die nötigen Maßnahmen zur Entfernung der Caches gebeten.

Auf meine Frage, wie E.ON auf die Caches aufmerksam wurde, bekam ich leider nur eine ausweichende Antwort. Es war von „Menschen im Wald“ die Rede, die aufgefallen wären. Meine Frage, ob einer der Caches gefunden worden sei, wurde verneint. Es wurde auch ausdrücklich ausgeschlossen, dass der fehlende Tradi bei den Waldarbeiten entfernt wurde.

Ich kam dann zum eigentlichen Kern des Problems und fragte, warum E.ON die Caches überhaupt archivieren ließ. Meine Gesprächspartnerin sagte, dies sei aus „grundsätzlichen Erwägungen“ heraus geschehen. Sie erwähnte nun die üblichen Vorbehalte gegen Geocaching, bspw. dass Cacher quer durch den Wald laufen würden. Auch meinen Einwand, dass die betroffenen Caches in diesem Fall nur wenige Meter vom Weg entfernt lagen und dass es keinen Grund gäbe, dort quer durch den Wald zu laufen, ließ sie nicht gelten und zog sich wieder auf die grundsätzlichen Bedenken zurück. Ganz offensichtlich wurden hier also nicht die Einzelfälle geprüft, sondern es wurde pauschal eine Entscheidung gegen Geocaches getroffen.

Ich fragte nun nach, ob es denn möglich wäre, bei E.ON eine Genehmigung zu bekommen, Caches auf deren Grundstücken zu platzieren. Dies wurde eindeutig verneint. Es würde „grundsätzlich“ keine solchen Einwilligungen geben. Dies gelte zumindest für die E.ON AG selbst, für Tochterunternehmen könne sie keine Aussagen treffen.

Auf meine Frage, ob denn nun damit zu rechnen sei, dass E.ON auch an anderen Orten Caches archivieren lassen würde, bekam ich wieder nur eine ausweichende Antwort. Dort, wo Caches „bekannt würden“, sei dies möglich. Es würde aber nicht gezielt nach Caches auf den eigenen Grundstücken gesucht (über die Geocaching-Plattformen im Internet).

Zuletzt kamen wir noch auf die Waldarbeiten zu sprechen, die ich in einem ersten Anschreiben als bedenklich eingestuft hatte. Diesbezüglich konnten meine Bedenken allerdings zumindest teilweise zerstreut werden. Im Bereich des Multis „Gladorgelbot“ finden derzeit übliche forstwirtschaftliche Maßnahmen statt, bei denen ältere Bäume aus dem Bestand herausgenommen werden. Die Arbeiten finden mit schwerem Gerät statt, was allerdings den Stand der Technik darstellt. Außerdem werden die Arbeiten von einem Förster begleitet, der einzelne Bäume vom Einschlag ausschließen kann (etwa wenn dort Vögel nisten). Im Bereich des Tradis wird dagegen ein Bestand komplett entfernt, der aus Pappeln besteht, die umsturzgefährdet sind. Diese sollen durch einheimische Baumarten ersetzt werden, wie mir gesagt wurde.

Wie ich vom Reviewer erfahren habe, sind bei Groundspeak nun die Flächen der E.ON AG (zumindest im aktuell betroffenen Gebiet) gesperrt. Das deckt sich mit der Aussage von E.ON, grundsätzlich keine Genehmigungen für Caches zu erteilen. Dort ist es also nun auch nicht mehr möglich, neue Caches zu platzieren. Dies dürfte vermutlich in der Zukunft noch für Unmut sorgen, wenn jemand versucht, in den schönen und vermeintlich leeren Waldstücken einen Cache zu legen.

Fazit: Groundspeak reagiert schnell auf Einsprüche von Grundstücksbesitzern und macht so nach außen hin deutlich, dass es keine Probleme mit Geocachern gibt und es somit auch keine Notwendigkeit für gesetzliche Beschränkungen gibt. Die Taktik geht auf, solange nicht jeder Grundbesitzer Einspruch erhebt. Denn eins dürfte allen klar sein, auch Groundspeak selbst: Für so gut wie keinen Cache gibt es eine Genehmigung des Grundstückeigentümers. Ein paar ungeliebte Caches im eigenen Vorgarten ausgenommen.