openSUSE Leap 42.1 (und 13.2?) - watch your (/etc/)hosts

      openSUSE Leap 42.1 (und 13.2?) - watch your (/etc/)hosts

      Moinsen,

      Die ganze Geschichte, um die es hier gehen wird, könnte man als eine Art Reisebericht sehen, denn zum Einen ging ich (als Admin meines Systems) auf die Reise durch Teile des Systems, um zum Anderen heraus zu finden, warum bestimmte Pakete auf die Reise geschickt wurden, wo es keinen Sinn machte.

      Alles fing wie so oft recht harmlos an, vor ein paar Wochen wollte ich auf einer meiner Kisten, die einige Tage zuvor von 13.1 auf 42.1 upgedatet wurde, den Midnight Commander benutzen, tipperte wie es sich gehört "mc" auf einem Terminal ein und es begann das große Warten. Der Start des mc dauerte fast eine Minute, was schon seltsam genug ist, aber es ließ sich einige Male reproduzieren und dann, wie von Geisterhand, ging es auf einmal wieder so schnell wie erwartet.

      So etwas beunruhigt schon, gerade weil es sich danach nicht mehr reproduzieren ließ, aber nach einer Weile quittierte ich das Geschehen mit einem Schulterzucken und machte mir trotz angeborener und gut trainierter Paranoia zunächst mal keine weiteren Gedanken, aber zumindest wurde es als "sollte das wieder auftauchen, dann noch mal genauer nachschauen, ob beim Upgrade auf 42.1 was schiefgegangen ist" irgendwo in einer Hirnwindung abgespeichert.

      Vor ein paar Stunden war es dann wieder so weit und dieses mal ging ich der Sache etwas genauer auf den Grund.

      Ein

      Quellcode

      1. strace mc


      zeigte nach dem üblichen "ein Programm startet"-Geraffel sich ständig wiederholende und durch kurze Wartepausen unterbrochene Aufrufe eines DNS-Lookups an, das wirkte schon sehr seltsam, also mit meinem bevorzugten Werkzeug "iptraf-ng" nachgesehen, was da passiert.

      Und siehe da, ein Start von "mc" sorgte in jedem Fall für einen DNS-Lookup, wobei dies auch der Fall war, wenn keine "Verschnaufpause" beim Start auftrat, einzig das Trennen der Internetverbindung ließ diese Anfrage beim Start verstummen.

      Wie oben schon angedeutet, bin ich überzeugter Paranoiker, aber auch ohne diese Eigenschaft, schien mir dieses Verhalten zumindest mal fehlerhaft, denn welchen Hostnamen sollte denn mc beim Start auflösen wollen?

      Kurzes Nachsehen mit wireshark sorgte nicht gerade für Erleichterung, eher das Gegenteil (jaja, verdammte Paranoia), denn der DNS-Lookup suchte doch tatsächlich nach dem Hostnamen meiner Kiste, was so absolut keinen Sinn machte, denn dieser Hostname dürfte in meinem Fall keinem DNS-Server im Internet bekannt sein, das fühlte sich also noch sehr viel falscher als zuvor an.

      "Mal ehrlich, was geht irgendeinen DNS-Server im Netz an, wie meine Kiste hier im lokalen Netzwerk heißt?"

      (..... und im Hintergrund raschelte die griffbereit gelegte Alufolie für den Bau der passenden Kopfbedeckung schon im Wind, no shit ....)

      Der nächste Gedanke war dann "und selbst wenn jemand, einen Hostnamen gesetzt hat, der im Internet per DNS auflösen würde, macht das doch keinen Sinn, denn der lokale Hostname steht doch in der /etc/hosts eh drin und die wird zuerst ausgelesen, bevor DNS bemüht wird" und ich wollte eigentlich schon zur bereit gelegten Alufolie greifen, aber dann .....

      ... 21 ... 22 ... 23 (never miss a pun)

      *Pling*

      Das war der Groschen, der in diesem Moment fiel, "steht der Hostname der Kiste etwa nicht (mehr) in /etc/hosts?"

      Quellcode

      1. cat /etc/hosts
      2. #
      3. # hosts This file describes a number of hostname-to-address
      4. # mappings for the TCP/IP subsystem. It is mostly
      5. # used at boot time, when no name servers are running.
      6. # On small systems, this file can be used instead of a
      7. # "named" name server.
      8. # Syntax:
      9. #
      10. # IP-Address Full-Qualified-Hostname Short-Hostname
      11. #
      12. 127.0.0.1 localhost
      13. # special IPv6 addresses
      14. ::1 localhost ipv6-localhost ipv6-loopback
      15. fe00::0 ipv6-localnet
      16. ff00::0 ipv6-mcastprefix
      17. ff02::1 ipv6-allnodes
      18. ff02::2 ipv6-allrouters
      19. ff02::3 ipv6-allhosts


      ... 42! (seriously, NEVER EVER miss a pun)

      Was zur Hölle? Der fehlt ja tatsächlich, denn in der 13.1 sah das noch so aus (Name der Maschine von der Redaktion geändert).

      Quellcode

      1. #
      2. # hosts This file describes a number of hostname-to-address
      3. # mappings for the TCP/IP subsystem. It is mostly
      4. # used at boot time, when no name servers are running.
      5. # On small systems, this file can be used instead of a
      6. # "named" name server.
      7. # Syntax:
      8. #
      9. # IP-Address Full-Qualified-Hostname Short-Hostname
      10. #
      11. 127.0.0.1 localhost
      12. 127.0.0.2 NAME_DER_KISTE.site NAME_DER_KISTE
      13. # special IPv6 addresses
      14. ::1 localhost ipv6-localhost ipv6-loopback
      15. ::1 NAME_DER_KISTE.site NAME_DER_KISTE
      16. fe00::0 ipv6-localnet
      17. ff00::0 ipv6-mcastprefix
      18. ff02::1 ipv6-allnodes
      19. ff02::2 ipv6-allrouters
      20. ff02::3 ipv6-allhosts


      Irgendetwas musste also beim Update auf 42.1 die beiden Zeilen mit dem lokalen Hostnamen aus der /etc/hosts gelöscht haben und damit erklärten sich diese seltsamen DNS-Lookups.

      Sollte das kein Schluckauf beim Update (und Überspringen einer Version, ich weiß) von 13.1 auf 42.1 gewesen sein, dann kann ich Nutzern der Versionen 13.2 und 42.1 nur raten, sich ihre /etc/hosts und die Ausgabe von "hostname" bzw. den Inhalt der /etc/hostname mal genauer anzusehen und gegebenenfalls nachzubessern.

      Kurzes Beispiel, wie die Einträge auszusehen haben.

      1) Nehmen wir an, der Inhalt der /etc/hostname sieht so aus.

      Quellcode

      1. Kiste.dingens


      2) Eintrag für IPv4 in der /etc/hosts

      Quellcode

      1. 127.0.0.2 Kiste.dingens Kiste


      wobei hier JEDE Adresse aus 127.0.0.0/8 außer 127.0.0.1 und 127.255.255.255 passen würde, 127.0.0.2 ist nur ein (sinnvoller) Vorschlag. Der Hostname ist einmal mit angehängtem Domainnamen (hier das ".dingens") und einmal ohne einzutragen.

      3) Eintrag für IPv6

      Quellcode

      1. ::1 Kiste.dingens Kiste


      IPv6 hat nur eine Adresse für localhost, also unbedingt "::1" (=gekürzte Notation) verwenden, Rest wie bei IPv4.

      Und zu guter Letzt noch die (wahrscheinliche) Auflösung des Mysteriums anhand dessen mir das Problem aufgefallen ist. Was führte dann zum verzögerten Start in manchen Fällen?

      Ich kann nur spekulieren, aber ich bin mir ziemlich sicher, daß ich damit richtig liegen dürfte, das Zauberwort lautet sehr wahrscheinlich "24h Zwangstrennung", denn davon bekommt der Client, der am Router hängt, nichts mit, er hat immer noch ein aktives Netzwerkinterface mit einer (internen) Adresse, aber eine zu diesem Zeitpunkt (und bis zu dem Zeitpunkt, bis sich das DSL-Modem des Routers neu eingewählt hat) gestellte DNS-Anfrage ins Internet läuft logischerweise ins Leere und da keine Antwort zurück kommen kann, wird dann eben bis zum Timeout dieses Verbindungsversuch gewartet.

      Soll ich jetzt der Telekom dafür dankbar sein, weil ich dadurch erst auf dieses Problem gestoßen bin?

      Ein kurzer Blick zur Alufolie ... nee, nicht wirklich ... :)

      Merke:

      Paranoia ist vielleicht nicht immer angebracht, aber in puncto Neugierde, Forschergeist und der dazu notwendigen Hartnäckigkeit bei der Suche nach solch seltsamen Problemen, ist sie meist eine recht nützliche Gehilfin.

      Greetz,

      RM
      "Programming today is a race between software engineers striving to build better & bigger idiot-proof programs and the Universe trying to produce bigger & better idiots. So far, the Universe is winning." (Rick Cook)

      Dies ist ein _öffentliches_ Supportforum, keinerlei Support per PN, EMail oder Instant Messenger.

      openSUSE Leap 42.3 - Kernel 5.0.x - fluxbox 1.3.7

      Bitmessage: BM-2D8h8QZmvHfgbixWeiG1NDZHG1iXAhBz8K
    1