Bonjour-Diensterkennung auf einem Cloud-Mac automatisiert testen

Dass eine Anwendung bei der Remote-Arbeit eine Verbindung über einen festgelegten Hostnamen und Port herstellen kann, bedeutet noch nicht, dass auch die Bonjour-Diensterkennung funktioniert. Druckdienste, Bildschirmübertragung, Debugging-Proxys und Werkzeuge für die Zusammenarbeit im lokalen Netzwerk sind häufig auf mDNS angewiesen. Ändert sich der Diensttyp, ein TXT-Eintrag oder eine Netzwerkschnittstelle, zeigt die Benutzeroberfläche oft lediglich an, dass Geräte in der Nähe verschwunden sind. Solche Probleme lassen sich auf einem Cloud-Mac mit Regressionstests auf Protokollebene zuverlässig untersuchen: Zunächst wird ein temporärer Dienst registriert, anschließend werden Erkennung, Auflösung und die Bereinigung beim Beenden geprüft. So muss nicht auf den sporadischen Ausfall eines realen Geräts gewartet werden.

Testgrenzen eindeutig festlegen

Bonjour sendet mDNS-Multicast üblicherweise über UDP-Port 5353 innerhalb des lokalen Links. Nur weil ein TCP-Port erreichbar ist, durchquert mDNS noch lange keine Router, gewöhnlichen SSH-Tunnel oder Remotedesktopverbindungen. Cloud-Tests sollten deshalb in zwei Ebenen aufgeteilt werden:

1. Auf demselben macOS-Knoten Registrierung, Erkennung, SRV-Auflösung und TXT-Einträge prüfen.
2. Im vorgesehenen lokalen Netzwerk einen separaten Verbindungstest mit realen Geräten durchführen, um Switches, WLAN und Multicast-Richtlinien zu validieren.

Die erste Ebene eignet sich für die CI bei jedem Commit. Sie erkennt falsch geschriebene Diensttypen, fehlerhafte Ports, fehlende Metadaten und nicht beendete Prozesse. Die zweite Ebene ist Teil der Netzwerkabnahme und kann nicht durch die Ergebnisse der ersten ersetzt werden.

Ein erfolgreicher Bonjour-Test belegt nur, dass der Vertrag zur Diensterkennung innerhalb der aktuellen Testgrenzen erfüllt ist. Er beweist nicht, dass Multicast entfernte Netzwerkgrenzen überquert.

Für das Produkt empfiehlt sich ein eigener Diensttyp, beispielsweise _myapp-test._tcp. Verwenden Sie nicht _http._tcp, da sonst weitere Dienste des Testknotens in den Ergebnissen erscheinen können. Auch der Instanzname darf nicht fest vorgegeben sein, sondern muss eine eindeutige Kennung des aktuellen Laufs enthalten.

Einen minimalen Testkreislauf mit dns-sd aufbauen

dns-sd ist in macOS bereits enthalten und erfordert keine zusätzlichen Abhängigkeiten. Das folgende Skript startet einen temporären HTTP-Dienst, beginnt zuerst mit der Diensterkennung, registriert anschließend eine Bonjour-Instanz und löst diese schließlich auf, um den Inhalt des TXT-Eintrags zu prüfen. Im Repository eignet sich dafür der Pfad ci/test-bonjour.sh.

#!/bin/bash
set -euo pipefail

RUN_ID="${CI_RUN_ID:-$(date +%s)}"
INSTANCE="vmcache-${RUN_ID}"
TYPE="_myapp-test._tcp"
PORT="${BONJOUR_TEST_PORT:-8088}"
WORK_DIR="$(mktemp -d)"
BROWSE_LOG="$WORK_DIR/browse.log"
RESOLVE_LOG="$WORK_DIR/resolve.log"

HTTP_PID=""
BROWSE_PID=""
REGISTER_PID=""
RESOLVE_PID=""

cleanup() {
  for pid in "$RESOLVE_PID" "$REGISTER_PID" "$BROWSE_PID" "$HTTP_PID"; do
    if [[ -n "$pid" ]]; then
      kill "$pid" 2>/dev/null || true
      wait "$pid" 2>/dev/null || true
    fi
  done
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT INT TERM

python3 -m http.server "$PORT" --bind 0.0.0.0 \
  >"$WORK_DIR/http.log" 2>&1 &
HTTP_PID=$!

dns-sd -B "$TYPE" local. >"$BROWSE_LOG" 2>&1 &
BROWSE_PID=$!

dns-sd -R "$INSTANCE" "$TYPE" local. "$PORT" \
  "path=/" "run=$RUN_ID" >"$WORK_DIR/register.log" 2>&1 &
REGISTER_PID=$!

sleep 4
grep -F "$INSTANCE" "$BROWSE_LOG"

dns-sd -L "$INSTANCE" "$TYPE" local. >"$RESOLVE_LOG" 2>&1 &
RESOLVE_PID=$!
sleep 3
kill "$RESOLVE_PID" 2>/dev/null || true
wait "$RESOLVE_PID" 2>/dev/null || true
RESOLVE_PID=""

grep -E "path=/|run=$RUN_ID" "$RESOLVE_LOG"
grep -E "$PORT" "$RESOLVE_LOG"
curl --fail --silent --show-error "http://127.0.0.1:$PORT/" >/dev/null

Die Diensterkennung muss vor der Registrierung gestartet werden, da kurze Jobs das Ereignis für einen neu hinzugefügten Dienst sonst verpassen können. dns-sd läuft hier nicht im Vordergrund, weil die Befehle zur Erkennung und Auflösung dauerhaft warten. Die CI muss daher ein festes Beobachtungsfenster vorgeben und die Prozesse anschließend aktiv beenden.

Assertions am Dienstvertrag ausrichten

Es genügt nicht, lediglich das Auftauchen des Instanznamens zu prüfen. Ein stabiler Regressionstest muss mindestens vier Punkte validieren: Diensttyp, Instanzname, Port und TXT-Eintrag. TXT-Einträge sollten nur wenig sensible Metadaten enthalten, die während der Erkennung tatsächlich benötigt werden, etwa die Protokollversion, Funktionsmerkmale und den Pfad für Integritätsprüfungen. Token, Passwörter oder interne Zugangsdaten gehören nicht hinein.

Die Protokollversion kann als api=2 und der Funktionsumfang als features=sync,preview angegeben werden. Die Testseite sollte jeden Wert einzeln prüfen, anstatt eine vollständige Ausgabezeile zu vergleichen. Die Ausgabe von dns-sd enthält Zeit- und Schnittstelleninformationen, weshalb Snapshots ganzer Zeilen leicht durch unterschiedliche Systemversionen beeinträchtigt werden.

Wenn die Anwendung ältere Protokollversionen ablehnen soll, kann zusätzlich eine Instanz mit api=1 registriert und geprüft werden, ob der Client sie tatsächlich ignoriert. Damit deckt der Test auch die Auswahllogik ab und nicht nur die Frage, ob ein Name sichtbar ist. Nach erfolgreicher Auflösung sollte außerdem eine minimale Anfrage an den tatsächlichen Port gesendet werden. So wird ein falscher Erfolg vermieden, bei dem die Ankündigung Port 8088 nennt, der Dienst aber auf Port 8089 lauscht.

Parallele Jobs, Rückstände und Angriffsfläche beherrschen

Wenn mehrere Jobs parallel auf demselben Knoten ausgeführt werden, müssen sowohl der Instanzname als auch der Port voneinander isoliert sein. Eine Jobnummer im Instanznamen verhindert nur die Verwechslung von Erkennungsergebnissen. Sie verhindert nicht, dass zwei HTTP-Dienste denselben Port belegen wollen. Der CI-Scheduler sollte Ports im Voraus zuweisen oder die Belegung vor dem Start mit lsof -nP -iTCP:$PORT -sTCP:LISTEN prüfen.

Alle Hintergrundprozesse müssen in trap berücksichtigt werden. Läuft der Registrierungsprozess nach einer fehlgeschlagenen Assertion weiter, kann der nächste Test die alte Instanz erkennen und einen schwer reproduzierbaren falschen Positivbefund erzeugen. Bei der Bereinigung sollten zuerst die Auflösungs- und Registrierungsprozesse und danach die Diensterkennung sowie der Testdienst beendet werden.

Für die vollständige Ende-zu-Ende-Prüfung lauscht das Beispiel auf allen Schnittstellen. Auch bei einem dedizierten Cloud-Mac sollte das Prinzip der minimalen Exposition gelten: Der Testport darf nur kurzzeitig und in einem kontrollierten Netzwerk geöffnet werden. Wenn keine Netzwerkanfrage erforderlich ist, kann der HTTP-Dienst entfallen und ausschließlich die Registrierung und Auflösung geprüft werden. Mit lsof vor und nach dem Test lässt sich bestätigen, dass kein Prozess auf dem Port zurückgeblieben ist.

Fehler anhand der Ausgaben eingrenzen

Wird bei der Suche kein Dienst gefunden, prüfen Sie zunächst, ob der Diensttyp einschließlich des führenden Unterstrichs und des Suffixes _tcp exakt übereinstimmt. Kontrollieren Sie danach, ob der Registrierungsprozess vorzeitig beendet wurde. Ist der Dienst sichtbar, lässt sich aber nicht auflösen, sollten vor allem die Maskierung des Instanznamens, der Domänenparameter und die lokale Namensauflösung untersucht werden. Funktioniert die Auflösung, aber keine Verbindung zum Port, sind die Listen-Adresse, die Portbelegung, Firewall-Richtlinien und die Startreihenfolge der Dienste zu prüfen.

Die CI sollte browse.log, resolve.log und die Ausgabe des Registrierungsprozesses speichern. Vor dem Hochladen müssen vertrauliche Daten entfernt werden. Bei einem Fehler sollten zusätzlich die Ausgaben von scutil --get LocalHostName, networksetup -listallhardwareports und lsof für die betroffenen Ports protokolliert werden. Damit lassen sich Probleme mit Namen, Schnittstellen und Listenern in der Regel zuverlässig unterscheiden.

Auch bei solchen Tests auf dedizierten physischen Knoten von VMCache darf nicht davon ausgegangen werden, dass der Remotezugriff mDNS weiterleitet. Führen Sie Regressionstests auf Protokollebene stets innerhalb des Knotens aus und prüfen Sie die Erkennung realer Geräte separat bei der Abnahme im vorgesehenen lokalen Netzwerk. Werden beide Ergebnisse getrennt erfasst, bleiben Fehlergrenzen klar und reproduzierbar.

Häufig gestellte Fragen