Geräte melden Name und Adresse per POST an den Broker, der sie nach der externen IP ihrer Registrierung gruppiert. Eine Weboberfläche oder ein Skript sieht damit genau die Geräte im eigenen Netz — die Aufgabe, an der mDNS im Labor scheitert.
Das Problem
Ein Board startet im Labornetz und bezieht eine Adresse per DHCP. Es wiederzufinden wäre eigentlich Aufgabe von mDNS, und im Labor ist es das regelmäßig nicht: Der Responder fehlt im Image, das Segment leitet kein Multicast weiter, ein VPN schluckt es, oder der Resolver des Hosts fragt schlicht nicht danach. Übrig bleiben Subnetz-Scans oder ein Blick in die Leases des DHCP-Servers.
Der Ansatz
whereisit dreht die Discovery um. Statt das Netz zu fragen, was vorhanden ist,
sagt jedes Gerät selbst, wo es steckt: ein periodischer POST mit Hostname und
Adresse an den Broker.
curl -X POST http://broker:8180/api/register \
-H "Content-Type: application/json" \
-d '{"name":"gateway-07","address":"10.0.3.41"}'
Die Registrierung trägt optional eine stabile id — typischerweise eine
Seriennummer —, damit ein Gerät bei einem Adresswechsel seinen Eintrag
aktualisiert statt einen zweiten anzulegen, sowie ein tags-Objekt für
beliebige Metadaten wie Hardwarestand oder die Vorrichtung, in der das Board
sitzt.
Begrenzung auf das eigene Netz
Der Broker gruppiert Registrierungen nach der externen IP, von der die Anfrage
kam, und GET /api/devices liefert nur die Geräte, die sich von derselben
externen IP registriert haben wie der Aufrufer. Von einem Arbeitsplatz im
Labornetz sind das die Boards dieses Labors und sonst nichts — ohne
Konfiguration und ohne eine Instanz je Standort, denn derselbe Broker bedient
jedes Netz, das auf ihn zeigt. GET /api/alldevices liefert alles, wenn eine
Gesamtsicht gewünscht ist.
Einträge verfallen; --lifetime bestimmt, wie lange eine Registrierung ohne
Auffrischung bestehen bleibt, damit ein Board, das verschwindet, von selbst aus
der Liste fällt.
Betrieb
Ein einzelnes Go-Binary mit der Weboberfläche auf dem einen und der API auf dem anderen Port, veröffentlicht als Container-Image:
docker run -p 8180:8180 -p 8181:8181 ghcr.io/bitcrushtesting/whereisit:latest
Die Konfiguration kommt aus einer INI-Datei und umfasst die beiden Ports, die
Lebensdauer der Einträge und die Authentifizierung — wahlweise HTTP Basic Auth
oder ein X-API-Key-Header, beides standardmäßig aus und für den Betrieb hinter
einem TLS-terminierenden Proxy gedacht. Das Repository enthält fertige
Registrierungs-Clients als Shell-Skripte und in Python sowie einen
systemd-Timer für Geräte, die sich regelmäßig neu melden sollen. MIT.