Mosquitto MQTT-Broker im Uberspace installieren

Vorbemerkung

Der ursprüngliche Artikel stammte vom 1. August 2015, etwas weniger als ein Jahr später hat sich die Sache allerdings weiterentwickelt, daher habe ich den Artikel umdatiert und neu veröffentlicht. Das Wichtigste zuerst: Die Sache funktioniert, sauber sicher und stabil. Der ganze nachfolgend erträumte Funktionsumfang ist noch nicht erreicht, aber daran kann man ja noch arbeiten.

Vision

Wir alle bewgen uns viel durch die Welt, häufig nicht alleine. Und Karten sind ein fantastisches Medium, um solche Bewegungen auf einer sphärischen Fläche festzuhalten und darzustellen. Zwei interessante Fragen/Problemstellungen/Aufgaben tauchen dabei häufiger auf:

  1. Wo bin ich überall schon mal gewesen?
  2. Wo bin ich jetzt grade, wohin bin ich unterwegs, wie bewege ich mich fort und wann komme ich an? (Insbesondere, wenn man sich mit jemandem treffen möchte)
  3. (Spielen! Jedes Mal, wenn ich über diesen Komplex nachdenke, drängt sich der Gedanke auf, dass man daraus ein fantastisches (Gelände-/Real-)Spiel basteln könnte, etwas in der Art einer Schnitzeljagd oder Geocaching in Verwandschaft zu Scotland Yard oder Mister X, vielleicht sogar mit Carmen Sandiego. Auch Deutschlandreise oder Globetrotter kommen einem in den Sinn. Große Metropolregionen wie das Ruhrgebiet, in dem ich wohne, bieten sich dafür natürlich an, aber auch im Rahmen einer Jugendfreizeit ließe sich das sicher gut nutzen. Siedler- oder andere Segelspiele haben wir ja schonmal auch ganz offline hinbekommen. Andere haben sowas auch schon gemacht: z.B. auf dem 31C3 und vorher wurde in der Freakshow davon berichtet. Ingress trifft einen ähnlichen Nerv)

Ziel wäre also, die Position von mehreren Leuten zu erfassen, verfolgen, aufzuzeichnen und (auch im Verlauf, also als Spur) darzustellen, eventuell in Beziehung zu setzen mit einander oder anderen Daten (Wetter, Verkehr, ÖPNV), zusätzlich noch Ziel/Zwischenziele, Route, Verkehrsmittel, Voraussichtliche Ankunftszeit, passende Wikipedia-Artikel etc.
Das würde erstmal die Grundanforderungen abdecken, sich mit anderen Menschen besser absprechen zu können und auch im Nachhinein sehen zu können, wo man war.
Wenn es dann noch zusätzlich Berechtigungs-Einschränkungen gäbe (alle senden ihre Position, aber nicht jeder kann immer die Positionen aller anderen einsehen), käme man der Spiel-Nutzung näher.

Möglichkeiten

Es gab mal einen Dienst namens Google Latitude, der ungefähr in die Richtung ging, er ist mittlerweile in Google+/Maps (Timeline) aufgegangen, in Facebook, FourSquare/Swarm, Apples Find My Friends oder waze finden sich ähnliche Ansätze. Sehr nah an meine Vorstellung der Umsetzung kommt Glympse, gegenüber den anderen genannten Diensten benötigt man zum Angucken kein Konto und die Freigabe ist zeitlich beschränkt.

Aber einen Nachteil haben sie alle: Sie sind ein großer Eingriff in die Privatsphäre, man gibt Kontrolle ab, man muss (überwiegend sehr großen) Firmen trauen, die im Ausland und damit anderen Jurisdiktionen sitzen, von denen man abhängig und denen man ausgeliefert ist. Kurz: Sie sind nicht  offen, noch frei.

Also sind sie keine echte Option. Ein paar gäbe es da aber schon schon: OsMo/OsmAnd, Userhash Location Reporting, Gps Cell Phone Tracker, Trackserver. Es gibt auch eine schöne Übersicht von Diensten mit Vergleich. So recht schien mir aber keins davon zu passen. Zwischenzeitlich trug ich mich mit dem Gedanken, selbst was auf reiner Browser/Javascript-Basis zu entwickeln, was eventuell mit einem NodeJS-Server spricht: Sehr viel Aufwand, aber wäre ein Anlass zum Lernen.

Ansatz

Doch in dem Vergleich wird OwnTracks erwähnt (nicht zu verwechseln mit owntrack, dessen Idee ähnlich, Umsetzung aber nicht so nachhaltig zu sein scheint), dazu gibt es auch einen Artikel bei Cashy und einen von nullniveau. (Und noch ein paar hier und dort). Das scheint mir eine Lösung voll nach meinem Geschmack. OwnTracks selbst ist eine OpenSource-App (sowohl für iOS als auch für Android), die die Position ermittelt und per MQTT (Message Queue Telemetry Transport), einem offenen Publish-/Subscribe-Protokoll für die dezentrale Übermittlung kleiner Nachrichten wie Sensor-Messdaten über Verbindungen, die auch schonmal aussetzen können, verteilt. Passt also sehr gut, hat auch den aparten Vorteil, dass die Server-Seite unabhängig von dem Geo-Thema ist und in der Heimautomatisierungsszene (s. openHAB) Zuspruch findet, man ist also da nicht allzusehr in der Nische und läuft Gefahr, dass man sich übernimmt oder die Weiterentwicklung eingestellt wird. Es gibt einen Open Source-MQTT Message Broker (=Server) namens Mosquitto, der auch von den OwnTracks-Machern unterstützt und empfohlen wird.

Einziger Wermutstropfen: OwnTracks ist zwar OpenSource, aber (noch) nicht im F-Droid-Repository zu finden, da es auf die proprietären Google Play Services zur Ortung zurückgreift. Kein Problem, das man nicht lösen könnte! 😉 (Allerdings ist die dafür notwendige Implementierung von Geofencing in LOST zur Zeit eingeschlafen.)

Die OwnTracks-App sendet und empfängt die Positionen und zeigt sie auf einer Karte an.
Der MQTT-Broker verteilt nur die Positions-Nachrichten aber zeichnet sie nicht auf, dazu gibt es mittlerweile ot-recorder (zuvor gab es schon das m2s-Backend bzw. auch mit Darstellung im Web den Nachfolger Pista. Um die Vision zu Erreichen, wäre außerdem der Einbau einer Authentifikation noch wichtig.

Mosquitto möchte ich gerne nicht auf einem Raspberry Pi installieren wie in der OwnTracks-Doku und allen anderen Anleitungen, die ich finden konnte, sondern in meinem Uberspace. Denn ich möchte die Position ja von Unterwegs aufzeichnen und einsehen, und ich möchte mein Netzwerk zuhause nicht nach Außen aufmachen. Das ist insofern problematisch, als die Anleitungen alle vom praktischen Weg „sudo apt-get“ ausgehen, der im uberspace logischerweise nicht funktioniert (keine sudo-Berechtigung). Also bleibt nur die andere Möglichkeit: Selbst kompilieren.

Umsetzung

Genug der langen Vorrede, werden wir etwas konkreter und kommen zur Umsetzung: Den Mosquitto-Broker im Uberspace kompilieren und starten.

Eine der Anleitungen beinhaltet das Kompilieren, aber als root, von der bin ich ausgegangen und habe sie dann ein wenig angepasst, um der User-Umgebung Rechnung zu tragen. Außerdem werden jetzt in der zweiten Version des Artikels direkt von Anfang an Websockets mit aktiviert und in der Konfiguration TLS verwendet.

Los geht’s:

Websockets

Geholfen haben mir zwei Artikel.

libwebsockets 1.6 ist die letzte explizit von mosquitto erwähnte Version und danach haben sich ABI-Changes ereignet, also nehmen wir die und kompilieren/installieren sie:

Damit wird heruntergeladen, ausgepackt, das buildscript erzeugt und dann ausgeführt. Danach liegen in lib/  die nötigen libraries, die man nach ~/lib  kopieren kann:

Jetzt geht es weiter mit  mosquitto selbst.

Mosquitto

Nun muss die config.mk angepasst werden, um die Websockets-Bibliothek erreichbar zu machen und zu linken

Also Folgendes jeweils an den richtigen Stellen in der Datei ändern:

Dann ändern, speichern und verlassen.

Es werden außerdem noch zwei header-Dateien gebraucht:

Weiter mit

Dabei passiert folgendes: Die Dateien werden kompiliert und unter $HOME/ in  entsprechenden Verzeichnissen (~/bin, ~/include, ~/lib, ~/sbin, ~/share) abgelegt, aber am Ende des Kompilierens erscheint der Fehler

Man kann auch erkennen warum: Die Dateien, die eigentlich in /etc/mosquitto landen sollen, berücksichtigen aus unerklärlichen Gründen den Prefix nicht, und auf das systemweite /etc-Verzeichnis haben wir natürlich keinen Zugriff. Ist aber auch nicht weiter schlimm, wir legen einfach eine eigene Konfigurationsdatei an, sie wird gleich editiert:

TLS

Doch zunächst müssen noch einige Vorbereitungen bezüglich des TLS getroffen werden. Der Server soll unter einer eigenen Domain erreichbar sein und es soll ein Zertifikat von Let’s Encrypt zum Einsatz kommen, das passt gut in die Uberspace-Architektur und wird auf den Mobilgeräten automatisch akzeptiert. Alternativ, insbesondere wenn man keine Domain hat oder dafür nur die normale Uberspace-Domain ($USER.$SERVER.uberspace.de) benutzen möchte, wäre es auch möglich, das Zertifikat selbst zu generieren/signieren (Weiteres dazu unter http://owntracks.org/booklet/features/tls/ und http://mosquitto.org/man/mosquitto-tls-7.html) und das dazu passende CA-Zertifikat auf den Geräten in das System zu importieren oder in der App anzugeben. Das macht die Einrichtung aber unnötig kompliziert und hat z.B. bei Android als Nebeneffekt zur Folge, dass die Bildschirmsperre mindestens per Muster deaktiviert werden muss (was ohnehin eine gute Sache wäre).

Nun also –  Im virtuellen User-Webroot wird ein Verzeichnis als Platzhalter angelegt:

Es ist sinnvoll, hier eine eigene, sonst nicht benutzte Subdomain zu vergeben, (der Name muss natürlich entsprechend angepasst werden) um das Let’s Encrypt-Zertifikat separat zu verwalten.

Die (Sub-)Domain muss dann im DNS angelegt werden, z.B. bei INWX, was ich nur empfehlen kann. Im Wiki von Uberspace gibt es noch genauere Informationen.

Es muss sichergestellt sein, dass die Server von Let’s Encrypt unter der Domain auch wirklich den Uberspace-Server erreichen, also am besten nochmal von außen probieren, z.B. eine Test-Datei aus dem Platzhalter-Verzeichnis herunterzuladen.

Wenn Let’s Encrypt bisher noch nicht im Einsatz war ist es an der Zeit (den Uberspace-Wiki-Eintrag zu lesen und dann) für

Jetzt, oder falls Let’s Encrypt schon im Einsatz war findet sich unter ~/config/letsencrypt/cli.ini eine Konfigurationsdatei, in der alle Domains eingetragen sind. Die wird nun kopiert, bearbeitet (also alle Domains außer der für Mosquitto entfernt) und zum Erzeugen der Zertifikate benutzt:

Die Zertifikate werden nun für mosquitto kopiert. Im Prinzip könnten sie auch aus dem .config-Ordner heraus verwendet werden, aber so hat man alles zusammen. Geschmackssache:

Konfiguration

Es sind zwei offene Ports in der Firewall nötig, die bekommt man durch doppeltes Aufrufen von

Die dabei ausgegebenen Ports merken und gleich benutzen, denn jetzt geht es an’s Einstellen in der vorhin angelegten Konfigurations-Datei. Eine Hilfe dabei war ein Artikel:

Hier im Beispiel ist der normale MQTT-Port (Standard 1833/8883) auf 61883 und zusätzlich ein Websockets-Port (Standard 9002) auf 61884 konfiguriert, beide geschützt mit TLS. Aufgelistet sind hier alle Änderungen im Verhältnis zur Standard-Konfiguration. Die müssen in der Datei jeweils an den entsprechenden Stellen vorgenommen werden. Also nicht einfach alles reinkopieren. Außerdem müssen die $HOME-Variablen manuell aufgelöst werden, also stattdessen direkt/home/username hinschreiben.

Starten und Testen

Es kann fast losgehen, dazu müssen wir aber noch das Verzeichnis, in dem die frisch kompilierte Mosquitto-Bibliothek liegt, in den LD_LIBRARY_PATH aufnehmen, damit beim Ausführen des Binarys gleich auch darin nach ihr gesucht wird:

$HOME/lib/ wird an den bisherigen Pfad angehängt und dann wieder in der Umgebungsvariablen gespeichert (der Doppelpunkt ist das Trennzeichen), danach wird sie ausgegeben. Damit das fortan automatisch beim Einloggen geschieht, ergänzen wir die erste Zeile in der .bashrc:

Und jetzt braucht man vier Konsolen-Fenster:

1. Der Broker. Hier sollten zum Start ein paar Meldungen erscheinen:

2. Das Log. Auch hier sollten bei den folgenden Aufrufen einige Meldungen erscheinen:

3. Der Subscribe-Client. Er sollte beim nächsten Aufruf die gesendete Nachricht anzeigen:

4. Der Publish-Client:

Ein  uberspace-list-ports -l  zeigt außerdem die jetzt offenen Ports mit dem horchenden Mosquitto-Server:

Als nächsten Schritt kann man jetzt die OwnTracks-App mit dem Broker verbinden. Das sollte sich ebenfalls in den Logs und im Subscribe-Client niederschlagen, außerdem müsste in Luxembug ein User angezeigt werden.

Die Websocket-Verbindung kann man direkt hier testen: http://www.eclipse.org/paho/clients/js/utility/index.html
Oder einen dieser MQTT-Websocket-Clients klonen und konfigurieren:
https://github.com/eclipse/paho.mqtt.javascript.git
https://github.com/jpmens/simple-mqtt-websocket-example
https://github.com/owntracks/contrib

Daemontools

Zur besseren Kontrolle des Brokers übergibt man ihn in die Obhut der  deamontools (die zum Testen gestartete Instanz in der „1. Konsole“ muss natürlich vorher per Strg+C beendet werden):

In dieses Skript kommt nun (den Usernamen ersetzen):

Zum Abschluss wird das Skript ausführbar gemacht, aktiviert und der Daemon gestartet:

Ein abschließendes

sollte nun den Mosquitto-Superviser und den eigentlichen Broker zeigen.

Das war’s, alles geht! 🙂

Achtung, mit dieser Konfiguration gestattet der Broker alle Verbindungen und Subscriptions! Eine ACL würde Abhilfe schaffen…

Bliebe noch,  den ot-recorder und ein Authentifikations-Backend einzurichten. Mal schauen, wann das kommt…

Update: ot-recorder

Der ot-recorder klappt auch, wegen der Nachfrage in den Kommentaren hier noch ein kleiner Hinweis dazu. Ist leider aus Zeitmangel nicht ganz so ausführlich, aber besser wie nix:

Ich habe Version 0.6.5 vom 30. Mai 2016 ans Laufen bekommen und beziehe mich daher hier auf diese, würde mich aber nicht wundern, wenn auch eine neuere Version funktionieren würde. Vielleicht einfach mal ausprobieren. Leider weiß ich nicht mehr genau den Weg, den ich damals genommen habe, und kann daher nur Hinweise geben, keine Anleitung.

Man benötigt wohl auch noch die libconfig in Version 1.5 (möglicherweise geht auch hier die neuere 1.6?). Die kann man einfach runterladen, in ein Verzeichnis entpacken (in meinem Fall /home/$USERNAME/projekte/libconfig/libconfig-1.5), dann

ausführen und hernach

Das reicht schon, dann ist die Bibliothek dort verfügbar.

Es sieht so aus, als wären die nötigen Änderungen im Ordner von owntracks-recorder allesamt in der config.mk und dessen Kompilieren sollte danach klappen. Würde mich freuen von jemandem, der es ausprobiert hat, eine Rückmeldung zu bekommen. Also, meine config.mk hat folgende Änderungen:

($USERNAME jeweils von Hand ersetzen durch den eigenen Benutzernamen, die anderen Pfade jeweils auf eigene Gegebenheiten anpassen)

Nach dem Kompilieren müsste ./owntracks-recorder funktionieren. Allerdings gab es, wenn ich mich recht erinnere, noch kleinere Probleme, die Web-Oberfläche aufzurufen, die ich nie wirklich behoben habe, weil mir die Daten in den Verzeichnissen schon gereicht haben.

Ich hoffe, das hilft schonmal?

16 Gedanken zu „Mosquitto MQTT-Broker im Uberspace installieren

    1. Ich bitte um Verzeihung für die lange Verzögerung. Vielen Dank für den Kommentar! 🙂
      Ja, eine spannende Sache, ist natürlich die Frage nach dem eigenen Anspruch und dem Nutzerkreis, was „sowas wie Latitude“ letztlich bedeutet. Aber der Broker läuft z.Zt. verschlüsselt bei uberspace und es können mehrere Leute mit OwnCloud zugreifen. Das ist auch schon ein paar Mal getestet, aber noch nicht über einen langen Zeitraum oder mit hohen Anforderungen.
      Geplant ist auch, den Beitrag hier noch zu erweitern bzw. Folgebeiträge zu schreiben.

  1. Gute Anleitung, danke!

    Ein kleiner Tippfehler: „export LD_LIBRARY_PATH=$LD_LIBRARY_PATH$HOME/lib/:“ <- da fehlt ein Doppelpunkt vor $HOME.

    Und nachdem jetzt mein Sonntag dafür draufging, TLS zum Laufen zu bringen, hier der Hinweis: mosquitto_sub (und ot-recorder) spricht offenbar nur TLSv1.2, daher muss man mosquitto zu dieser Version zwingen: In der mosquitto.conf:
    tls_version tlsv1.2
    (Quelle: http://jpmens.net/2013/09/01/installing-mosquitto-on-a-raspberry-pi/ )

    Zum erzeugen der Zertifikate kann man das Skript hier nutzen: https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh
    Vorher den Hostname am Ende des ersten Kommentarblocks eintragen.

    1. Ich bitte um Verzeihung für die lange Verzögerung. Vielen Dank für den Kommentar! 🙂
      Danke auch für den Variablen-Hinweis. Bei mir ging es zwar so, weil zufällig am Ende meiner Variable schon ein Doppelpunkt vorhanden war, aber sicherer ist es mit. Habs korrigiert.
      Das mit dem TLS ist ein guter Tipp, nach Einschalten des TLS (kommt noch als Ergänzung) hatte ich mosquitto_sub gar nicht mehr probiert. Aber mit OwnCloud klappts 🙂

    1. Ja, bei OwnTracks tut sich nach wie vor viel. Und den im verlinkten Artikel beschriebenen recorder gibt es zwar schon eine Weile, er scheint auch stabil zu funktionieren. Allerdings ist er ein MQTT-Client und kein Server/Broker (wie der hier beschriebene Mosquitto). Die Notwendigkeit für einen solchen besteht also nach wie vor. Und auch das Hosting auf einem Internet-Userspace ist ein wenig anders als das Selbst-Hosting auf einem Raspberry im Heimnetz. Den hat man zwar mehr unter Kontrolle, dafür muss man aber auch die Tür (sprich: einen Port) nach außen aufmachen und eine Lösung fürs DNS-Update finden. Ein Ansatz, der das beste aus beiden Welten kombiniert, könnte aber sein, den selbst-gehosteten Raspberry per Bridging und optional VPN zu verbinden. So weit bin ich aber leider noch nicht.
      Die am Ende des Artikels erwähnten weiteren Schritte stehen überwiegend weiterhin aus, allerdings habe ich kürzlich einen kleinen Test im Rahmen eines Geländespiels gemacht und ganz ermutigende Ergebnisse bekommen. Und ein weiteres Problem bleibt noch zu lösen: OwnTracks ist nicht im F-Droid zu finden, da es die Google-Libs verwendet. Mein funktionierender Fork (allerdings leider noch ohne Karte und ohne Geofencing) ist mitlerweile schon etwas out-of-date, weil sich eben die App gut weiterentwickelt.
      Ich habe da nach wie vor sehr viel Interesse dran, aber, aber im Moment leider nicht genug Zeit dafür.

  2. Bei mir schlägt make all fehl mit der Meldung:
    undefined reference to `clock_gettime‘

    Gibt es dafür eine Lösung? Soweit ich sehe hängt es mit der glibc zusammen, aber leider komme ich hier nicht weiter.

    mosquitto-1.4.9
    Linux norma.uberspace.de 2.6.32-642.1.1.el6.x86_64

    1. Moin Thorsten,
      an dem Fehler bin ich leider noch nicht vorbeigekommen, deswegen hab ich auch keine schnelle Lösung… 🙁
      An welcher Stelle genau kommt der bei Dir? Beim Kompilieren/make all von Mosquitto?
      Das einzige Vorkommen von „clock_gettime“ hab ich in
      mosquitto-1.4.9/lib/time_mosq.c: clock_gettime(CLOCK_MONOTONIC, &tp); gefunden.
      Hast Du vorher alle anderen Schritte gemacht, bist im richtigen Verzeichnis und hast die nötigen Umgebungsvariablen gesetzt?
      Wie bist Du auf die glibc gekommen?
      Ich habe ein paar Hinweise gefunden, dass die librt an der richtigen Stelle (ganz am Ende?) im Kommando gelinkt werden muss:
      https://ubuntuforums.org/showthread.php?t=1985452
      https://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim
      Vielleicht ist da bei Dir beim Editieren der config.mk etwas schief geraten?
      Ich hab gerade mal geschaut, welche glibc-Version auf meinem Host (Mensa) installiert ist:
      ldd –version
      ldd (GNU libc) 2.12
      Copyright © 2010 Free Software Foundation, Inc.
      Und, der Vollständigkeit halber:
      cat /proc/version
      Linux version 2.6.32-431.11.2.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Tue Mar 25 19:59:55 UTC 2014

      Vielleicht hilft das ja schon? Bin gespannt,
      Cheers!

    1. Freut mich! Hast Du es bei Dir auch zu Laufen gebracht?
      Ich habe mittlerweile auch den otrecorder, ACLs und Auth-Backend zum Laufen bekommen, aber es noch nicht geschafft, die Anleitung zu vervollständigen, außerdem auch zu wenig Zeit, an dem FLOSSen der OwnTracks-App zu arbeiten. Interesse? 🙂

      1. mich würde brennend interessieren wie du den ot-recorder auf uberspace zum laufen gebracht hast. ich hab alles was mir einfällt probiert und bin immer wieder an „GLIBC_2.17 not found“ gescheitert, egal ob mit toast oder (linux) brew. selbst kompilieren hat auch nur fehlersalat gebracht. ein paar tipps fänd ich super.

        1. Hi! Ich bin mir nicht mehr so ganz sicher wie ich es damals gemacht habe und habe es jetzt gerade auch nur ansatzweise nachvollzogen.
          Aber oben im Artikel gibt es jetzt eine Ergänzung, von der ich hoffe, dass sie hilft?
          Lass gerne nochmal was hören, wenn es geklappt hat bzw. was noch fehlt.

  3. Hallo,
    ich habe deine Anleitung genutzt um mosquitto auf meinem Uberspace zu benutzen.
    Genutzt habe ich für alles die aktuellsten Versionen:
    cmake3.8.2
    libwebsockets2.2.1
    mosquitto1.4.12

    Hier ein paar Sachen die ich anders machen musste bzw die nicht funktioniert haben:

    cmake ist nicht standardmäßig auf dem Uberspace installiert. Dies wird aber für das erstellen von libwebsockets benötigt. Also nach dieser Anleitung installiert: https://ricwein.com/ricwein/uberspacetutorial/tree/b2567d1ec193579ec796acf042b5c156db9f4183/#cmake

    Danach lies sich libwebsockets auch bauen.

    In der Datei ~/projekte/mosquitto/mosquitto-1.4.2/config.mk musste die Zeile für ‚BROKER_LIBS‘ bei mir so aussehen:

    BROKER_LIBS:=$(BROKER_LIBS) -L${HOME}/lib -lwebsockets
    statt
    BROKER_LIBS:=$(BROKER_LIBS) -L$(HOME) -lwebsockets

    Sonst wurde -lwebsockets nicht gefunden.

    Beim kopieren der mosquitto.conf musste der Befehl wie folgt aussehen:

    cp mosquitto.conf. ../etc/mosquitto.conf

    mosquitto.conf.example gab es nicht.

    TLS habe ich noch nicht eingerichtet/getestet. Allerdings ist der hier gezeigte Weg die Certs zu kopieren nicht der beste. Sie müssen sowieso alle 90 Tage erneuert werden. Also lässt man sie besser gleich da wo sie sind.

    Das Testen des Brokers hat dann geklappt.
    Ich habe in der ~/.bashrc noch PATH erweitert Aufruf der Binaries zu erleichtern.

    export PATH=$HOME/bin:$HOME/sbin:$HOME/.bin/cmake-3.8.2/bin:$PATH

    Nach Änderungen an ~/.bashrc sollte man noch folgenden Befehl aufrufen um die Änderungen zu übernehmen:

    source ~/.bashrc

    Das Einrichten des Service mit deamotools hat einwandfrei funktioniert.

    LG,
    Flow

    1. Moin Florian,
      danke für die Rückmeldung und die Hinweise!

      Gut zu wissen, dass die Anleitung mit den aktuellen Versionen auch funktioniert. Ich muss bei mir auch bald mal ein Update machen und werde Deine Anmerkungen dann einarbeiten. Hatte wohl vergessen, dass ich cmake vorher installiert habe. Aber die -L${HOME}/lib-Anmerkung steht doch schon in der Anleitung?! 🙂

      Bei dem TLS-Zertifikat hast Du auf jeden Fall recht, das habe ich bei mir mittlerweile auch so wie vorgeschlagen gelöst, also ohne Kopieren. Das funktioniert einwandfrei und ich lege jedem, der Mosquitto betreibt nachdrücklich an’s Herz, den niemals unverschlüsselt laufen zu lassen. Gar nicht erst plaintext einreißen lassen, ohne ausprobieren und das Nachrüsten auf später verschieben! 😉

      Zwischenzeitlich habe ich auch das Authentifizierungs-Backend eingerichtet, das klappt auch gut, da muss ich demnächst mal hier ein Update schreiben. Die _pub und _sub-Aufrufe muss man dafür um Parameter erweitern:
      -u user -P password

      Und für ein Geländelauf-Spiel im Verein habe ich es testweise auch schon genutzt, mit User-Registrierung und automatischer Erzeugung der .otrc-Konfigurations-Datei. Auch dazu fehlt hier noch das Update.

  4. Mit libwebsockets-3.0.0 und mosquitto-1.5 auf Uberspace 7 gab es bei mir folgende Fehlermeldungen bei
    `make all`

    websockets.c: In function ‚callback_http‘:
    websockets.c:542:27: error: ‚S_IFDIR‘ undeclared (first use in this function)
    if((filestat.st_mode & S_IFDIR) == S_IFDIR){
    ^
    websockets.c:542:27: note: each undeclared identifier is reported only once for each function it appears in
    websockets.c:554:27: error: ‚S_IFREG‘ undeclared (first use in this function)
    if((filestat.st_mode & S_IFREG) != S_IFREG){

    Hab ich gefixt, in dem ich die define Makros aus stat.h manuell in die ersten Zeilen des websocket.c Codes kopiert habe.

    #define S_IFDIR 0040000
    #define S_IFREG 0100000

Schreibe einen Kommentar zu ix Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

five × 4 =