Wenn Embedded Linux-Geräte kein HTTP HEAD verstehen

Netzwerkgeräte in meinem Intranet überwache ich mit der quelloffenen Software monit. Seit ich einen meiner monit-Server auf Debian Stretch upgegradet habe, häuften sich „Geister“-Fehlermeldungen — immer in Bezug auf Checks, welche die Verfügbarkeit von Web-Oberflächen abfragen. Dies in folgender Form:

...
check host web.server.strasse.emeidi.local with address 10.10.10.10
if failed port 80 protocol http for 10 cycles then alert
...

Mit dem Upgrade auf Debian Stretch wird auch monit von Version 5.9-1+deb8u1 auf Version 5.20.0-6 aktualisiert.

Ich wartete also den Moment ab, in welchem ich per E-Mail die Fehlermeldung erhielt, loggte mich per SSH auf den Server ein und führte zu Debugging-Zwecken eine Abfrage aus — die Idee war, auf dem selben Server die Abfrage zu simulieren, die monit gegen das entfernte System laufen lässt:

$ wget --server-response "http://10.10.10.10/"
--2017-06-22 22:05:25-- http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html [ <=> ] 7,66K --.-KB/s in 0,01s

2017-06-22 22:05:25 (754 KB/s) - »index.html« gespeichert [7841]

Dies funktioniert problemlos. Was Cheibs?

Als ich mir die Dokumentation zu monit genauer anschaute, realisierte ich eine feine, aber entscheidende Option:

PROTO(COL) HTTP
[USERNAME "string"]
[PASSWORD "string"]
[REQUEST "string"]
[METHOD <GET|HEAD>]
[STATUS operator number]
[CHECKSUM checksum]
[HTTP HEADERS list of headers]
[CONTENT < "=" | "!=" > STRING]

Quelle: Monit Version 5.23.0 — HTTP

Mit [METHOD ] entscheidet man, ob man einen normalen HTTP-Request („GET“) versendet, oder aber nur einen „HEAD“-Request, der nur nach dem Header einer Web-Site frägt. Das spitzfindige an der Sache:

METHOD set the HTTP request method. If not specified, Monit prefers the HTTP HEAD request method to save bandwidth, unless a response content or response checksum is tested. As some webservers may not support the HEAD method, one may want to set the method explicitly.

Dann lass uns das doch mal so simulieren. wget verfügt über die entsprechende Option --spider, die HEAD-Requests versendet:

$ wget --spider --server-response "http://10.10.10.10/"
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:04:36-- http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
HTTP/1.1 501 Not Implemented
Server: Router Webserver
Connection: close
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Content-Type: text/html
--2017-06-22 22:04:37-- (Versuch: 2) http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: Wget HEAD request?

Et voilà, das war das Problem: Der Embedded Web Server auf dem zu überwachenden Gerät hat Probleme, wenn aus dem nichts ein HEAD-Request kommt. Beim zweiten Anlauf dann ist die Web-Seite offenbar gerendert und der HEAD-Request kann beantwortet werden.

monit scheint nun aber offenbar so programmiert zu sein, dass nach dem ersten Versuch und einer Antwort mit Fehlern kein zweiter Versuch lanciert wird. Deshalb auch die sporadischen Fehlermeldungen.

Wie löst man das Dilemma? Ich wandelte den Test folgendermassen um:

...
check host web.server.strasse.emeidi.local with address 10.10.10.10
if failed
port 80
protocol http
with content = "Willkommen"
for 10 cycles
then alert
...

Die Anweisung with content = "Zeichenkette" forciert monit, einen GET-Request abzusetzen und keinen HEAD (da nur beim GET-Request ein HTTP-Body mitgeliefert wird). Und schwup, Problem gelöst.

Erweitert

Übrigens: Wem die Ausgabe von wget noch nicht ausreicht, da sie zu wenig geschwätzig ist, kann auch die Debug-Option verwenden:

$ wget --debug --spider --server-response "http://10.10.10.10/"
Setting --spider (spider) to 1
Setting --server-response (serverresponse) to 1
DEBUG output created by Wget 1.19.1 on darwin15.6.0.

Reading HSTS entries from /Users/user/.wget-hsts
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:02:44-- http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc231e0 (new refcount 0).
Deleting unused 0x00007ff99bc231e0.

---request begin---
HEAD / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
---response begin---
HTTP/1.1 501 Not Implemented
Server: Router Webserver
Connection: close
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Content-Type: text/html

---response end---

HTTP/1.1 501 Not Implemented
Server: Router Webserver
Connection: close
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Content-Type: text/html
Closed fd 4
--2017-06-22 22:02:48-- (Versuch: 2) http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc23110 (new refcount 0).
Deleting unused 0x00007ff99bc23110.

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
---response begin---
HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"

---response end---

HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Closed fd 4
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: What headers are automatically send by wget?

Sackgassen

Initial befürchtete ich, dass der Web-Server des Zielsystems sich am User-Agent des Requests verschluckt. Doch dies war eine falsche Vermutung. Nichtdestotrotz könnte man monit so konfigurieren, dass es einen alternativen User-Agent sendet:

‚User-Agent‘ header can not be set via ‚http headers‘ array

Und noch ein anderes Beispiel: Trying to configure monit to use https protocol but it sticks with http