Fehlermeldungen nach Update!

[windflyer]

Hallo...
Nachdem ich soeben auf die neueste Loxberry Version ein Auto-Update gemacht habe, bekomme ich noch einem Neustart folgende Meldungen:

loxberry : Oct 29 07:17:29 : root : problem with defaults entries ; TTY=unknown ; PWD=/ ; USER=root ;

loxberry : Oct 29 07:35:05 : loxberry : unable to resolve host loxberry

Hat jemand eine Idee?
LG

[Scrati]

https://www.loxforum.com/forum/projektforen/loxberry/allgemeines-aa/174055-loxone-miniserver-von-loxberry-aus-nicht-erreichbar

[Christian Fenzl]

Scrati Bis auf den Beitrag #8 ist der Link eigentlich ein anderes Thema (Port-Feld beim Miniserver wird in 1.2.5.1 nicht mehr angezeigt).


Bezüglich problem with defaults entries : unable to resolve host loxberry

Wir sind am überlegen, auf welche Weise wir den Fehler fixen - wir haben eine Linux-Leiche begraben und dabei gleich die nächste ausgebuddelt.
Derzeit diskutieren wir noch, auf welche Weise wir das fixen, wir haben aber gesagt, dass wir definitiv heute noch ein Update nachliefern.

lg, Christian

[Scrati]

Ah. Ok. Ich hatte nur gesehen, dass in beiden Threads, die gleichen Fehlermeldungen geposted wurden.

[Christian Fenzl]

Tico
@windflyer

Habt ihr beide eine feste IP-Adresse eingestellt oder DHCP?

[Tico]

Die feste IP-Adresse ist derzeit eingestellt.

Obwohl ich leicht zu DHCP wechseln und MAC der gewünschten IP-Adresse im Router zuweisen kann?

[Gast]

Hallo,

Da dies mein erster Eintrag im Forum erst einmal ein ganz großes Lob und Dankeschön für das super Loxberry Projekt. Ist super hilfreich und nutze es seit kurzem bereits mit einigen Plugins.

Bzgl der Fehlermeldungen oben erhalte ich diese auch nach dem heutigen Update und möchte nur die Info bzgl der IP Konfig mitteilen. Habe den loxberry bei mir auf DHCP und vergebe über den DHCP Server dann immer die gleiche IP.

Viele Grüße,
Frank

[Christian Fenzl]

Gast Von dem jetzigen Fehler Mal abgesehen, ist das wirklich eine sehr ungewöhnliche, nein sogar unglückliche Konfiguration für ein Heimnetzwerk.
Wenn DNS und DCHP getrennt sind, funktioniert bei dir Zuhause wahrscheinlich gar keine Namensauflösung zwischen den LAN-Geräten?
Zumindest bestätigen diese Meldungen, dass trotz IP per DHCP deine Fritz als DNS nichts vom LoxBerry weiß.

Yep gebe ich Euch beiden recht das die Konstellation alles andere als gut ist. Bin auch dran die FritzBox (alt) ganz raus zu nehmen. Bin nur noch nicht dazugekommen, alles von dort auf den anderen Router (neu) zu übernehmen.
Nachdem der Loxberry an der FritzBox fehlerfrei lief, habe ich den Loxberry wieder umgehängt und die Fehlermeldung kommen weiterhin nicht mehr.

[Christian Fenzl]

Gast Das ändert sich wieder - derzeit ist das irgendwo im Cache, aber das kommt wieder. Lass mal die "Fehlerkonstellation", wir brauchen jemanden, der die Korrektur ausprobiert.

[windflyer]

ich verwende eine fixe IP
lg

[Tico]

Zum Testen habe ich den Loxberry an 'Assign automatically (DHCP)' zurückgegeben und den statischen Leasingvertrag gegen die MAC-Adresse beibehalten.

Ich habe keine fehlerhaften E-Mails mehr.

[Christian Fenzl]

Während svethi, Wörsty und Prof.Mobilux an der Korrektur feilen, nutze ich die Zeit, um mal kurz zu erzählen, was überhaupt die Ursache ist.

Also, wir schreiben das Jahr 2005. Der Airbus A380 absolvierte seinen Erstflug, der erste Galileo-Satelit wurde ins All geschossen, die Leute mussten damals noch 50.000 Handgriffe mehr machen, und irgendjemand der Linux-Community ist draufgekommen, dass manche Dienste Probleme verursachen, wenn der lokale Hostname nicht aufgelöst werden kann.
Deswegen hat man damals 127.0.1.1 mit dem eigenen Hostnamen in die /etc/hosts geschrieben.
Viel später, 2013, ist im Web die Rede davon, dass es die Probleme mit der Auflösung des lokalen Hostnamen nicht mehr gibt.
Jedoch wurde der Workaround, 127.0.1.1, nie aus der /etc/hosts entfernt.

Die /etc/hosts Datei ist eine Datei, die auf jedem Rechner (auch Windows, MacOS usw.) existiert, und verwendet werden kann, um Hostnamen zu IP-Adressen zuzuordnen. Die Datei wird vom Betriebssystem gelesen, noch bevor der eingetragene DNS-Server in Netzwerk zur Namensauflösung gefragt wird. In der Regel steht dort nur die lokale Loopback-Adresse localhost mit 127.0.0.1. Seit 2005 steht dort unter Linux auch 127.0.1.1 -> <hostname>, bei uns in der Regel 127.0.1.1 -> loxberry.

Nun kommt Weather4Lox- (und auch das dnsmasq)-Plugin ins Spiel - die beiden Plugins installieren einen lokalen DNS-Server, d.h. der LoxBerry löst Hostnamen zu IP-Adressen auf. Das ist nötig, um die Wetter-Requests vom Miniserver abzufangen und die Wetterdaten zu emulieren.

Das Problem stellt sich nun so dar:
Macht man auf dem LoxBerry (oder jedem Raspberry, oder Debian, usw.) einen ping loxberry, liefert dieser durch den oben genannten Eintrag die Adresse 127.0.1.1 zurück. Das funktioniert lokal auch.
Führt hingegen der Miniserver mit aktiver DNS-Umleitung einen Request http://loxberry/plugins/.... aus, sendet der LoxBerry-DNS nicht die echte IP-Adresse des LoxBerry zurück, sondern auch 127.0.1.1, damit erreicht der Miniserver nie den LoxBerry.
Das ist die Skurrilität: Der LoxBerry ist DNS-Server, und kann genau seinen eigenen Hostnamen nicht auflösen. Das Symptom ist, dass jeder, der den Wetter-Emulator verwendet, immer im Miniserver die IP-Adresse des LoxBerrys verwenden muss - eine altbackene, unflexible und fehleranfällige Konfiguration.

Unser Update hat den Eintrag für 127.0.1.1 -> loxberry entfernt. Ab diesem Zeitpunkt ist der DNS-Server (bzw. indirekt der DHCP-Server), im Heimnetzwerk meist der Internet-Router, für die Namensauflösung zuständig. Dieser kann dann ganz korrekt "loxberry" (oder den jeweiligen Hostnamen) in die richtige IP-Adresse auflösen.

So, und jetzt zum Fehler:
In Debian wird bei sudo eine Konfiguration für einen Dienst mitgeliefert, den wir gar nicht benutzen. Und diese möchte den eigenen Hostnamen auflösen.
Mit dem 127.0.1.1-Eintrag hat das funktioniert. Auch bei Verwendung von DHCP mit DNS funktioniert das.

Wird jedoch eine feste IP verwendet, ist (normalerweise) der Netzwerkadministrator dafür verantwortlich, am DNS-Server diesen Hostnamen einzutragen. Das Blöde ist: Die Router im Heimnetzwerk bieten diese Möglichkeit - zur Vereinfachung - in der Regel nicht an.
Somit kann sudo den eigenen Hostnamen nicht auflösen, und quitiert das sofort als Email an den Administrator.

So, ich muss mich sputen, der Fix ist gleich fertig...

Unser Fix wird sein:
Wir werden jetzt bei jeder Änderung der IP-Adresse - sei es manuell oder via DHCP - den Hostnamen und die IP-Adresse automatisch in die /etc/hosts eintragen.

Das löst diese Probleme:

• Alle Linux-Dienste, die diese Host-Auflösung benötigen (wie jetzt der sudo), können dann den Host auflösen.
• Wird der LoxBerry als DNS-Server verwendet (Wetter-Emulator), funktioniert dann auch der richtige Hostname (z.B. http://loxberry/...) vom Miniserver aus.

Also zusammenfassend: ALLES WIRD GUT!

Jene, die das Problem haben, bitte ich, sich bereit zu halten, den Fix zu probieren. Wir melden uns hier, wenn es soweit ist (ich denke in einer Stunde oder so)

lg, Christian

[mpeyer]

Ich möchte mich hier noch für diese Hintergrundinfos bedanken! Spannend zu lesen und aufschlussreich!

[Christian Fenzl]

Wenn ihr noch nicht schläft:
Könntet ihr auf den „Letzten Entwicklungsstand“ updaten, rebooten und schauen, ob es noch auftritt.

svethi hat den Fix implementiert - also Beschwerden wisst ihr, wohin 😛

Danke für das schnelle Update. Habe es gerade installiert und bekomme keine Fehler eMails nach einem Reboot mehr. Hatte oben aber ja geschrieben das ich auch vorher keine mehr erhalten habe. Gibt es irgendeinen Cache auf dem Loxberry den ich noch löschen soll für den Test?

[mpeyer]

Hallo alle. Ich habe das Problem auch. Seit dem Update heute morgen wurde ich bis Dato mit 220 Mails bombardiert...
Bin mir nicht mehr 100% sicher, aber ich glaube ich habe eine statische IP auf meinem Loxberry gesetzt. Zusätzlich habe ich aber in meinem DHCP-Server (Router) eine MAC-Reservierung (für dieselbe IP natürlich).
Auf der Recherche bin ich zum Glück auf diesen Thread gestossen. Ich werde mich gerade daran machen, den Fix zu testen... stay tuned.

[Wörsty]

Der Fix funktioniert soweit. Aber ich bin etwas unglücklich, dass damit DNS in Verbindung mit DHCP nicht mehr auf den eigenen Namen geht.
Wenn der DHCP Server mir eine andere IP zuweist, bekommt das Script das nicht mit und behält die alte IP bei.
Dann geht das Spiel von vorn los. Ist zwar ein sehr theoretischer Fall aber man kann es wenigstens mit einem Reboot beheben.
Danach stimmt es wieder bis der Lease sich wieder ändert (was er zugegeben normalerweise nicht tut).

Zitat: Wir werden jetzt bei jeder Änderung der IP-Adresse - sei es manuell oder via DHCP - den Hostnamen und die IP-Adresse automatisch in die /etc/hosts eintragen.

Geht nicht.

[svethi]

Weißt Du, wir haben 2 Tage über eine Lösung diskutiert. Da kam kein Input von Dir. Gestern Abend kamen dann, als ich schon fast fertig war, „Ideen“ von Dir, die aber auch alle für ein if-up Script waren.
Tut mir leid, dass es so ein Mist Lösung ist, aber hinterher so darüber herzuziehen (und ich meine nicht nur hier), ist immer einfach. Mach es bitte besser und lass mich damit zufrieden.
Übrigens, das es mit DHCP NICHT funktionieren soll ist totaler Käse. Wenn Du beim Start per DHCP eine IP zugewiesen bekommst, wird die sehr wohl eingetragen. Leider konnte ich die Fritzbox nicht dazu überreden während des Betriebs eine neue IP zuzuweisen. Daher konnte ich das nicht testen. Da nach meinen Recherchen aber das if-up auch nach dem dhcp-client aufgerufen werden sollte, hätte auch ein IP Wechsel während des Betriebes funktionieren müssen. Dem scheint nicht so. Das übrigens wäre eine wichtige Information gewesen und nicht irgend eine FQDN.

Ach ja, hätte ich es nach Deine Ideen umgesetzt, wären nach Deinen Hardcoretests mehrere falsche Zeilen in der hosts gestanden, meine Mistlösung hat Deine Mist ja wenigstens weggeräumt.

Danke für den konstruktiven Beitrag.

[mpeyer]

Also über 15 Minuten nach dem Update ists nun ruhig in der Mailbox. Der Fix funktioniert. Vielen Dank!
Auch im Apache-Log, wo ich zuvor die sudo Fehlermeldungen fand, sind die Fehler nicht mehr drin. Bestens.
Was ich aber im Apache-Log habe: das Log wächst und wächst mit 100ten von diesen zwei Log-Zeilen:
Action: plugininstall-status // Value: PhZkh7WstC.status
plugininstall-status: PhZkh7WstC.status
Kann nicht beurteilen, ob das neu ist und mit dem Upgrade zusammenhängt. Logfile anbei.
Christian Fenzl , svethi oder sonstwer?

[Christian Fenzl]

Du hast noch einen Log-Viewer einer Plugin-Installation offen.

[mpeyer]

Stimmt! in einem der Tabs war das noch offen. Das ist mir nun grad peinlich, sorry!
Aber danke für den Hinweis. Demfall alles bestens!

[Tico]

Funktioniert nun nach dem Update einwandfrei. Vielen Dank.

[Michael Rene Maurer]

Danke für den Fix, Seit ein Top Team!!!

[windflyer]

hi...
fix funktioniert! top arbeit... danke dafür!
lg