Selbst unter dem LUG-typischen Einfluss zyklischer Störungen gelingt es dem Magazin-Kolumnisten Charly zu beschreiben, wie er trotz gesperrten NTP-Ports zu einer vernünftigen Systemzeit kommt.
| Inhalt | |
|---|---|
| 62 | Sicheres Programmieren Teil 3 der Reihe beschreibt, wie der Admin seinen Programmen nahe legt, welche Daten sie abzulehnen haben. |
| 70 | Simple Security Policy Editor Mit dem SSPE behalten Admins die Kontrolle über die Sicherheitsrichtlinien mehrerer Firewalls. |
| 74 | Solaris 10 Suns Antwort auf Linux’ Popularität ist Solaris 10. Tatsächlich hat der neue Container-Mechanismus einigen Charme. |
| 78 | Admin-Workshop Manpages sind Informationsquelle Nummer eins. Wir erklären das Funktionieren der einzelnen Spielarten. |
Ich schreibe diesen Text während des LUG-Camps in Wuppertal [1]. Es ist jetzt… – egal wie spät. (Jemand von der LUG Flensburg bringt mir ein Flens. Danke!) Vorhin hatte ich ein Manuskript zum Thema Syslog-NG zur Hälfte fertig. Dann wies mich Google dezent auf die Tatsache hin, dass das Linux-Magazin dieses Thema bereits Ende 2003 behandelt hat. Super. Also schreibe ich von einer anderen Schweinerei.
Zum Thema Zeitsynchronisation per Network Time Protocol ist eigentlich genug geschrieben worden. Auch ich bekenne mich in der Hinsicht schuldig [2]. Heute geht’s um Zeitsynchronisation ohne NTP: Vorhang auf für HTPDate [3]. (Gerade dreht jemand eine Webcam in meine Richtung. Danke.) Klar, NTP ist erste Wahl beim Synchronisieren. Manchmal scheitert NTP aber; etwa wenn der auszugleichende Rechner hinter einer total zugenagelten Firewall samt vernageltem Admin steht: NTP? Kenn’ ich nicht, brauch’ ich nicht.
HTPDate reicht Port 80 nach draußen, und sei es über einen Proxy. Das geht so: Es holt per Telnet eine beliebige Seite eines Webservers (»GET / HTTP/1.0«). Dabei liefern viele Server neben dem HTML-Code zusätzliche Informationen wie die HTTPD-Versionsnummer und eben das aktuelle Datum samt Uhrzeit:
HTTP/1.1 200 OK Date: Sat, 07 May 2005 17:53:46 GMT Server: Apache/2.0.53 (Linux) X-Powered-By: PHP/4.3.10
(Ich muss niesen. Jemand sagt, ich möge bitte etwas leiser verrecken. Danke.) HTPDate kommt in zwei Varianten vor: eine ist in Perl, die andere in C geschrieben. Ich nehme die C-Variante in der Version 0.7.2, handelbar als Tarball oder als RPM-Paket.
Vorfühlen
HTPDate ist angenehm übersichtlich zu bedienen. Es gibt zwei Modi, den interaktiven und den Daemon-Modus. Im interaktiven probiere ich, ob ein Server überhaupt als Zeitquelle taugt:
htpdate -d google.com web.de yahoo.com
Das »-d« aktiviert den Debug-Modus, damit gibt HTPDate wie in Listing 1 neben dem Zeitstempel auch die Antwortzeit aus. (Jemand in der Nähe hat eine Vorliebe für Iron Maiden. Kopfhörer mag er leider vernehmlich nicht. Danke!)
| Listing 1: »htpdate -d« |
|---|
01 google.com 07 May 2005 18:18:15 GMT (0.223) => -4 02 web.de 07 May 2005 18:18:15 GMT (0.023) => -4 03 yahoo.com 07 May 2005 18:18:19 GMT (0.188) => -3 04 #: 3, mean: -4, average: -3.667 |
Der Wert in Klammern ist die Antwortzeit. Sie ist beim Web.de-Server vergleichsweise niedrig und garantiert ein präzises Zeitsignal. HTPDate akzeptiert bis zu 16 Webserver pro Anfrage. Nun kann ich als Root HTPDate im Daemon-Modus (»-D«) starten:
htpdate -D -x web.de [Server2 Server3 ...]
Der Parameter »-x« weist HTPDate an, die Zeit nicht auf einen Schlag zu aktualisieren, sondern sie nach und nach anzugleichen. Das versöhnt Applikationen mit dem Timewarp, die auf ein gleichmäßiges Zeitsignal angewiesen sind, zum Beispiel RRDTool. (jk)
| Infos |
|---|
| [1] LUG-Camp in Wuppertal: [http://www.lug-camp-2005.de]
[2] Charly Kühnast, “Aus dem Alltag eines Sysadmin: OpenNTPD”: Linux-Magazin 01/05, S. 61 [3] HTPDate: [http://www.clevervest.com/htp/]development.html] |





