[Eisfair] E wie einfacher - Vorschlag zu internen Gateway/DNS/link Kontrolle.

kay kay at martinen.de
Mo Apr 17 16:44:32 CEST 2017


Hallo

Ich bin auch nicht mehr der Jüngste, kann auch mal was übersehen und
irren ist ja bekanntlich menschlich.

Darum, und weil ich mom. einen Echten und zwei virtuelle Eisfair-1 (+
anderes) am Laufen habe mein Vorschlag und/oder Frage.

Gibt es da schon was, oder wenn nicht wie kann man es dem EIS am besten
einbauen das er Änderungen am Netzsetup, den Verlust der
Internet-Verbindung besser mit bekommt?

Grund dafür: ich bekam vom echten Eis eine meckermail dieser Art

> /usr/share/eisman/eisman_update.sh: line 90: /tmp/index.txt: No such file or directory
> /usr/share/eisman/eisman_update.sh: line 71: /tmp/index.txt: No such file or directory


Nun komme mal sofort drauf das dessen Eigentliches Problem nicht bei
eisman-update.sh zu suchen ist!

Sondern:

Ich hatte bisher einen ipfire mit der ip 192.168.1.2 (+Proxy) laufen.
Der fiel aus und nun habe ich unter 192.168.1.1 einen FLI am werke
(-Proxy). Doch alle Hosts sind noch auf den Alten als DNS und Gate
(+proxy) eingerichtet und fallen nun auf die Nase wenn sie ins Internet
wollen. Der EIS insbesondere auch weil er die Proxy-umgebungs-variable
für seine Updates nutzt.

Bei den per DHCP konfigurierten Clients ist das alles kein Problem. Aber
von den akt. nun 21 HOST IPs in meiner Konfig sind nur wenige wirklich
solche Clients.

Und falls es keine eingeführte Methode gibt einem Host eine Feste IP zu
geben und ihn nur Default-gateway und DNS via DHCP beziehen zu lassen
macht es auch keinen Sinn Serversysteme komplett via DHCP zu
konfigurieren. Bis auf die (neueren) ILOs von Proliant-Servern geht das
aber m.W. nicht. Für den eigentlichen Server wäre es also sinnvoll wenn er

1. die Erreichbarkeit des Default-gateways regelmäßig prüft,
2. wenn dies erreichbar ist: die namensauflösung prüft,
3. wenn dies erfolgreich war, einen server im internet prüft.

Und bei Fehler bei einem dieser Schritte $irgendeine Warnung von sich gibt.

Das könnte z.b. ein Beep-code sein falls kein Mailzugang (nur Extern) da
ist. Wenn ein LCD angeschlossen wäre, so wäre das ein Ziel.

Aber generell wäre es wohl hilfreicher wenn z.b. eine solche Überwachung
intern eine art flag setzt und ein eisman-update dann z.b. schon gleich
abbricht ohne es erfolglos versuchen zu müssen.
Bei internem Mailserver ist natürlich der Erste Weg die Nachricht an den
Admin das der Server nicht ins Internet kommt.

Denn ich Tüddelkopp hatte zwar alle möglichen, auch die Virtuellen
Server umgestellt - aber diesen Echten Eisfair komplett vergessen. S.o.

Ich weiß wohl das es Monitoring-Lösungen (nagios u.a.) gibt die das
Leisten. Aber für den einzelnen Server ist das overkill und ich würde
mir wünschen das Jede Eisfair-installation das von sich aus intern
überwacht und dementsprechend reagieren kann.

Prinzipiell denke ich das es über einen cronjob ginge der etwas in der
art macht:

ping gate
if gate=Err
	then Set Flag
	else check DNS
	if DNS=Err
		then Set Flag
		else ping extHost
		if extHost=Err
			then Set Flag
		end
	end
end
# alles okay.


Nur müssten dann abhängig vom Ergebnis vermutlich einige andere Scripte
geändert, erweitert und mit ggf. mehreren Alternativen Reaktionen
versehen werden. Und da weiß ich nicht welche das alle sein könnten.

Der Vorteil könnte aber darin liegen das unerfahrene oder Tüddelige User
(wie $ME) nicht über Fehlermeldungen stolpern deren Ursache sie evtl.
erst nachsuchen müssten - oder hier in der Gruppe aufschlagen.

Kurz: Weniger Support-aufwand für einen an sich banalen Fehler.

Ich habe jedenfalls vor mein Internes LAN nun zumindest mit 1-2 Internen
Nameservern zu versehen und von diesen auf den jeweils aktiven Router zu
verweisen. Das hatte ich schon mal, jetzt eine ganze Zeit lang aber nicht.

Gegen Ausfall/Änderung der Defaultroute hilft auch das nicht, das wäre
aber sowieso eher ein Thema für FLI und Multi-WAN Support.


Kay


-- 
Posted via SN


Mehr Informationen über die Mailingliste Eisfair