The Sysadmin's Daily Grind: HTPDate

Time Games


Despite the cyclical disruptions so typical of LUG meetings, our intrepid columnist, Charly, reveals how he set the system time in spite of a blocked NTP port.

By Charly Kühnast

I am writing this article from the LUG Camp at Wuppertal Germany, and the time is... - er, I have no idea. A kind person from the LUG Flensburg hands me a bottle of Flensburg beer, and I say "Thanks"...

Enough has already been said about NTP (Network Time Protocol) based time synchronization, and in fact, I confess to having written about NTP in the past. But today, I will discuss how to time sync without NTP. Up curtain and welcome to HTPDate [1]

Of course, NTP is the tool of choice if you need to sync the system clock across a network. But there are times when network synchronization is not possible. For example, if the machine you need to sync is hiding behind a totally hardened firewall maintained by a totally hardened admin who says things like "NTP? Never heard of it, so it must be something bad!"

HTPDate allows HTTP to escape, using a proxy if it needs to do so. This lean tool uses Telnet over port 80 to get a page from a web server (GET / HTTP/1.0). Many servers provide additional information with the HTML code; this could be the HTTPD version number, along with the current date and time:

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

I just had to sneeze. Somebody asked me if I could suffer in silence, please. Thanks again.

There are two HTPDate variants: one is written in Perl and the other in C. Let's have a look at the C variant, version 0.7.2, which is available as a tar archive or RPM package.

First Steps

HTPDate is surprisingly easy to use. There are two modes: interactive mode and daemon mode. In interactive mode, I first check if a server is suitable for use as a time source:

htpdate -d google.com web.de yahoo.com

The -d flag enables debug mode, which in turn tells HTPDate to output the raw timestamp and the response time, as shown in Listing 1.

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

Somebody nearby seems to like Iron Maiden. Unfortunately, he has never heard of earphones. Thanks again...

The value in the parentheses following the timestamp is the response time. As you can see, web.de`s server gives me a far faster response than the other two. I'm putting my money on web.de because the quick response time shown for web.de in Listing 1 guarantees that web.de will lead to a more precise time signal. This said, HTPDate will accept up to 16 web servers on request. Working as root, I can now launch HTPDate in daemon mode (-D):

htpdate -D -x web.de [Server2 Server 3 ...]

The -x parameter in the preceding command tells HTPDate not to synchronize the time all at once but, instead, to gradually approach the correct time. This method of gradual time synchronization makes applications that need a regular time signal, RRDTool for example, more responsive to the timewarp.

INFO
[1] HTPDate: http://www.clevervest.com/htp/development.html
THE AUTHOR

Charly Kühnast is a Unix System Manager at the data-center in Moers, near Germany's famous River Rhine. His tasks include ensuring firewall security and availability and taking care of the DMZ (demilitarized zone).