Vor einigen Tagen habe ich meinen Web-Server im lokalen LAN aufgeräumt und viele Services, welche über eine DynDNS-Adresse gegen das Internet zugänglich waren, deaktiviert. Ab sofort können diese Web-Services nur noch mit einer privaten FQDN à la service.server.location.domain.local aus dem LAN angesprochen werden.
Diese Anpassung führte dazu, dass mein Bluetooth-Scanner, welchen ich auf meinem Raspberry Pi betreibe, seine Scan-Resultate nicht mehr an den Web-Server übermitteln konnte. Ein Python-Script führt auf dem RPi alle 5 Minuten einen Bluetooth-Scan durch, übersetzt die Resultate ins JSON-Format und versendet die Daten dann mit requests3 per HTTP an den Web-Server.
Die Fehlermeldung, die das Script ab der Umstellung ausspuckte, lautete folgendermassen:
$ /usr/bin/python /usr/local/bin/bluelog/bluetooth-scan.py --output api
Traceback (most recent call last):
File "/usr/local/bin/bluelog/bluetooth-scan.py", line 424, in <module>
response = requests.post(url, json=macs, auth=HTTPDigestAuth('user','password'))
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 110, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 487, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='service.server.location.domain.local', port=80): Max retries exceeded with url: /index.php (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x75e41b10>: Failed to establish a new connection: [Errno -2] Name or service not known',))
Auf dem RPi eingeloggt funktionierte die Namensauflösung mit dem host-Kommando aber problemlos:
$ host service.server.location.domain.local service.server.location.domain.local has address 10.1.2.3
Doch als ich die Verbindung zum Web-Server mit wget überprüfen wollte schlug auch das fehl:
$ wget http://service.server.location.domain.local/index.php --2019-02-02 15:56:22-- http://service.server.location.domain.local/index.php Resolving service.server.location.domain.local (service.server.location.domain.local)... failed: Name or service not known. wget: unable to resolve host address "service.server.location.domain.local"
Herumgooglen brachte nicht die gewünschte Lösung. Deshalb griff ich zur nächstbesten Lösung und rief wget mit strace auf. Im Trace dann der entscheidende Hinweis:
$ strace wget http://service.server.location.domain.local/index.php
...
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/avahi-daemon/socket"}, 110) = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
write(3, "RESOLVE-HOSTNAME-IPV4 service.serv."..., 55) = 55
read(3, "-15 Timeout reached\n", 4096) = 20
close(3) = 0
...
Was zum Teufel hat der Avahi-Daemon mit /var/run/avahi-daemon/socket im strace zu suchen? Jetzt hatte ich ausreichend Infos, um Google noch einmal zu befragen. Und siehe da:
Is Avahi running or installed? Avahi uses .local domain for its usage and puts its config in /etc/nsswitch.conf. My experience with it, using a .local domain name for my internal use is that it can be a little flaky (for lack of a better technical term), and would show behavior similar to what you are seeing.
Quelle: [SOLVED] resolver weirdness – avahi and .local
Die Lösung war im selben Beitrag gepostet:
/etc/nsswitch.conf
Aus …
... hosts: files mdns4_minimal [NOTFOUND=return] dns ...
… wird folgender Eintrag:
... hosts: files dns mdns4_minimal ...
Und seither lösen sich auch die .local-Adressen reibungslos auf.
