Aus aktuellem Anlass gibt es Heute einmal eine Geschichte über eins der ältesten Probleme seit es Server im Internet gibt. Der Uhrzeit bzw. genauer die Uhrzeiten und verschiedenen Zeitformate die einem beim Betrieb eines Rechners im Internet so auf die Füße fallen können.
Zunächst hätten wir da einmal das einfache Datum, also die Systemzeit. Unter Linux lässt sich diese Zeit mit einem einfachen Aufruf von „date“ abfragen. Das sieht dann so in etwa so aus:
root@brecht-lab:~# date Mo 17. Mär 21:35:58 CET 2014
Wie kommt ein Linuxsystem jetzt zu diesem Wert? Dafür gibt es gleich mehrere Möglichkeiten, mehrere Möglichkeiten ist an dieser Stelle dann auch direkt gleichzusetzen mit mehreren Fehlerquellen. Gehen wir das ganze doch einmal der Reihe nach durch.
Beim Einschalten des Rechners wird zunächst die Rechnerinterne Uhr verwendet um sich dort eine Uhrzeit zu besorgen. In welchem Zeitformat diese Hardwareuhr läuft ist allerdings zu diesem Zeitpunkt etwas unklar. Sinnvolle Möglichkeiten existieren an dieser Stelle eigentlich nur 2. Entweder die lokale Uhrzeit oder wenn man Rechner in mehreren Zeitzonen verwaltet UTC. Wie kommt das Betriebssystem jetzt aber zu der Information welche Uhrzeit hier benutzt wurde? Im Falle von Linux bzw. in meinem Fall Debian ab Wheezy und Kali Linux findet man diese Information in der Datei /etc/adjtime.
Auf meinem aktuellen System steht in dieser Datei folgendes:
-0.034278 1395090090 0.000000 1395090090 UTC
Interessant für unsere aktuelle Betrachtung ist dabei im Moment nur die letzte Zeile. Wie man daran unschwer erkennen kann steht meine Systemuhr aktuell auf UTC. Würde hier ein LOCAL stehen währe meine Systemuhr auf die aktuelle Uhrzeit an meinem Standort eingestellt. Woran Linux erkennt in welcher Zeitzone ich mich gerade befinde bzw. welche Uhrzeit ich gerne auf meinem System angezeigt haben möchte ist dann wiederum an einer komplett anderen Stelle geregelt. Unter /etc/timezone ist diese Einstellung aktuell bei mir zu finden. Aktuell also:
Europe/Berlin
Bevor man unter Debian und seinen Derivaten allerdings an dieser Stelle editiert sollte man sich dem Systemwerkzeug dpkg bedienen. Durch die Eingabe des folgenden Befehls erhält man eine menügesteuerte Auswahlmöglichkeit für die aktuelle lokale Zeitzone.
dpkg-reconfigure tzdata
Soviel also zur Theorie. Noch einmal kurz Zusammengefasst:
1. Bios Systemzeit.
2. In /etc/adjtime erfährt mein Sytem ob die Biosuhr auf Systemzeit oder UTC steht.
3. Gibt die aktuelle Zeitzone des Systems an.
Soweit, so kompliziert. Um das ganze noch ein wenig auf die Spitze zu treiben kommt der moderne Serverbetreiber heutzutage oft auf die Idee das man ja seine Uhr mit dem Internet synchronisieren könnte. Der hier verwendete Dienst nennt sich ntpd. Dieses kleine Helferlein synchronisiert ab dem Zeitpunkt an dem er Netz erhält, sowie in regelmäßigen Abständen, seine lokale Uhrzeit mit den in der Konfiguration angegebenen Servern. Eigentlich ganz brauchbar, wird die Abweichung zwischen Lokaler Uhrzeit und dem ntpserver allerdings zu groß verweigert der ntpd allerdings schon einmal seinen Dienst.Die andere aktuell oft beobachtete Gefahr besteht natürlich darin das man Fehler in seinen lokalen Zeiteinstellungen erst beim nächsten Neustart wirklich ins Gewicht fällt. Dann allerdings mit einigem Nachdruck.
Für ganz harte Fälle gibt es dann auch noch nette kleine Helferlein wie ntpdate. Mit diesem Tool lässt sich die Uhrzeit manuell direkt mit dem entsprechenden Zeitserver im Netz synchronisieren. Dafür nimmt der Admin von heute bzw. ein kleiner Trottel wie ich, natürlich den Zeitserver der PTB. Man möchte ja auch die amtliche Zeit auf seinen Kisten besitzen. An dieser Stelle beginnt dann auch meine aktuelle Leidensgeschichte.
Situation:
Ich bekomme mal wieder mit den Worten „Machs wieder ganz“ Zugang zu einer etwas in die Jahre gekommenen Debiankiste eingeräumt. Nach dem fast schon zum guten Ton gehörenden Updatelauf wird dann zunächst ein aktueller Systemstand hergestellt. Zu diesem Update gehörte dann auch mal wieder ein Kernel. Ja, diese Kiste war wirklich schon ein paar Monate nicht mehr angefasst worden. Alles also wie immer. Aufgrund des Kernels beschloss ich der Kiste einen sauberen Restart zu gönnen bevor ich mich an das eigentliche debuggen des Systems machen wollte.
Hier begann es dann ein wenig aus dem Ruder zu laufen. Nach dem Neustart viel mir an den Logdateien direkt auf das sich das System gerade auf direktem Weg in die Vergangenheit katapultiert hat. 3 Stunden hatte ich durch diesen Einfachen reboot verloren. Nicht schön aber auch an dieser Stelle noch nicht so wirklich ungewöhnlich, Zeit die Kiste einmal kurzzeitig mit Gewalt auf den aktuellen Zeitsand zu bringen. Also folgende Befehlsfolge:
root@random-buechse:~# /etc/init.d/ntp stop [ ok ] Stopping NTP server: ntpd. root@random-buechse:~# ntpdate ptbtime01.ptb.de Error resolving ptbtime01.ptb.de: Name or service not known (-2) ntpdate[6780]: Can't find host ptbtime01.ptb.de: Name or service not known (-2) ntpdate[6780]: no servers can be used, exiting
wtf???
Die teuer vom Steuerzahler unterhaltenen Zeitserver der PTB down, eher nicht. Die Fehlermeldung sagte mir das an dieser Stelle schon der Hostname nicht aufgelöst werden kann. Was läuft hier schon wieder aus dem Ruder? Kurz noch einmal Kontrollieren ob die Meldung so auch ihre Richtigkeit hat, dazu mal eben ein nslookup auf ptb.de abfeuern und um wirklich sicher zu gehen nimmt man dafür am besten einen Nameserver der eher selten ausfällt, Google. Die Befehlszeite der Wahl war also diese hier:
root@random-buechse:~# nslookup ptb.de Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: *** Can't find ptb.de: No answer
Ein weiteres mal wtf!!! Wie?, keine ptb.de. Da Stimmt doch etwas absolut nicht. Lokalen Browser auf und auf die Webseite der PTB. Mein Staunen war nicht schlecht als sich vor meinen Augen dann doch die Seite der PTB öffnete. Klarer Fall, auf dem Server gibt es irgendein Porblem mit dem Abfragen des Nameservers. Aus der Erfahrung ist mir bekannt das sowohl bei der NTP-Abfrage als auch bei DNS-Problemen ab und an einmal Firewalls als Problemverursacher in Frage kommen. Beides sind UDP Protokolle, beide scheinen aktuell nicht zu funktionieren (der NTP hatte ja bereits beim booten den Dienst verweigert und benutzt für seine Abfragen auch nicht den Server der PTB).Nach geschlagenen 1 1/2 Stunden Fehlersuche fand ich dann das Problem. Mich bzw. mein blindes Vertrauen in Standarts.
Der Fehler lag bereits in der ersten Abfrage: ptbtime01.ptb.de existiert nicht und löst deshalb auch auf keine bestehende IP auf. Unter normalen Umständen würde man jetzt von dem verantwortlichen DNS-Server den entsprechenden Wildcardrecord zurückbekommen. Wie z.B. hier:
brechthold@brecht-lab:~$ nslookup fuckyoutoo.contempt-it.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: fuckyoutoo.contempt-it.com Address: 69.64.40.139
Gut, contempt war jetzt eventuell ein doofes Beispiel da die Jungs hier wirklich jede Domain ins Blog ballern aber ein gleiches Verhalten zeigt sich auch bei extrem vielen anderen Domains.
Nicht so bei der PTB, dort erhält man praktischerweise bei allen nicht direkt vorhandenen Einträgen keine Rückgabe. Super Sache!!!
Bei der Eingabe im Browser hängte ich natürlich automatisch das „www.“ davor. Hätte ich direkt http://ptb.de eingegeben hätte ich auch in meinem Browser direkt erkannt das da ein Problem besteht. Gut, das man sich keine Wildcard anlegt ist für mich unter bestimmten Umständen sogar noch nachvollziehbar doch bei der direkten Domain, also ptb.de, keine Daten hinterlegt zu haben ist schon ein ordentlicher Mist.
Ich unterstelle jetzt der PTB einmal das dort auch der ein oder andere Mensch arbeitet der ein wenig mehr von Computern versteht, warum macht man also so etwas?
Die Einzige wirklich plausible Erklärung die mir für das fehlen einer Wildcard einfällt ist, das durch die vielen falsch konfigurierten NTP-Server die so durch das Internet geistern so viel Traffic in Richtung des Webservers wandern würde das dieser Server, der vermutlich deutlich schwächer angebunden ist als die Zeitserver, zusammenklappen würde. Dieses Szenario erklärt allerdings noch immer nicht das Fehlen des Domain Records für ptb.de. Wem hier ein passender Grund einfällt der möge mich bitte in den Kommentaren erleuchten.
Nachdem ich also einmal mehr bewiesen hatte wie viel Zeit man mit der Suche nach nicht vorhandenen Fehlern verbringen kann, konnte ein einfacher Aufruf des richtigen Ntpservers, ptbtime1.ptb.de alles wieder auf einen Stand heben mit dem man arbeiten konnte.
Warum der NTP jetzt allerdings bereits beim booten seinen Dienst verweigerte und was zur Hölle an der Zeitzoneneinstellung auf diesem Server so alles schief läuft bzw. lief. Das würde den Rahmen dieses kleinen Rants wohl endgültig sprengen, deshalb hierzu eventuell ein anderes Mal etwas mehr.
Als Fazit der Geschichte sehe ich eigentlich nur eins. Mehr Prüfen, weniger Vermutungen. Bereits nach der ersten gescheiterten DNS-Abfrage meinerseits ging ich automatisch davon aus das ich es an dieser Stelle mit einem Serverproblem zu tun haben musste. Hätte ich mit einer zweiten Domain gegengecheckt währe mir die Besonderheit bei ptb.de bereits viel früher aufgefallen. Hätte ich mich auf meine eigenen DNS-Einträge verlassen und diese entsprechend geprüft hätte mir das auch direkt einiges an Problemen erspart. Wir lernen also, mehrere tests und diese nur gegen bekannte Systeme. Im Idealfall nur gegen Systeme testen die unter der eigenen Kontrolle stehen.
