Synchronizing clocks on the intranet.

GNU/Linux, DOS & Windows machines agree on what the time is.

Our own office network had computers running DOS applications, computers running Windows applications and computers running Linux applications. The servers for the network (web server, file server and print server) were all hosted on computers running one or another flavour of SuSE Linux. Just occasionally it was desirable to have them all agree, at least to within a couple of seconds, about the time of day. This article describes how it was moderately easy to synchronize the clocks on all of the DOS, Windows and GNU/Linux computers on our local network.

Content revision history:
Article first written, August 2004
Extra information added, 11th January 2006

Quick links within this article

Configuration of the primary, or master, time server

Configuration of the secondary time server and Samba file server

Configuration of the DOS and Windows client computers.

Links to information beyond this article

www.ntp.org

Background information

Three time related problems recurred on our office network.

The first and least critical problem, was that as humans we tended to look at the computer clock to see what the time was but the computer clocks would often have drifted away from national time by at least several minutes, often much more. This was merely a minor detail to trip over from time to time, so to speak.

The second problem involved websites. The website creation software had a facility whereby the files in the development directory could be compared with the files on the website server to see which, if any, had been updated and therefore needed to be uploaded to the server. Sometimes this file synchronization process would provide incorrect suggestions because of a difference between clock of the website server clock and the clock of the development computer and, as a result, the software would sometimes claim that modified files did not need to be updated or that the entire website needed to be updated even though it had only just been synchronized.

The third problem was similar to the second and involved the use of a C-compiler (software for creating computer programs). With this software the make utility would sometimes get confused about dependencies because some of the files had been time-stamped with the time according to the server, while others had been time stamped with the the time according to the development computer.

At this point a warning is in order, viz:

Our requirements were fairly simple; we did not have many people using many computers working simultaneously on a project. All we really had was one person at a time working on a particular project with files held on two or more computers. This warning is necessary because, for the situation where many computers are simultaneously working with, and updating, the same collection of files, the techniques described in this document might not be sufficient. Our aim was only to get the clocks approximately synchronized. to avoid excessive problems. If you need to get your clocks synchronized. to within a few milliseconds then you might do well to read and possibly try these techniques, but also keep in mind that you might need to research further and work harder.

Penguin & beakbrush
It's important to brush your beak after chewing over a problem.

The concept

In order to synchronize the computer clocks we merely wanted them all to occasionally copy the time from some common computer which we unimaginatively named the timeserver. This timeserver function was delegated to our web server since that machine is constantly switched on and available for access. However as well as synchronizing the computer clocks within the local intranet it was also desirable to have them set to a reasonable approximation of national time so the timeserver machine itself was then told to synchronize itself with some other computer in the wider world. This is possible because scattered across the globe is a hierarchy of computers that distribute time with those computers at the tip of the hierarchy being connected to some sort of super-wonderful-fabulously-expensive-meticulously-accurate atomic clock or similarly costly and technologically sophisticated timepiece. The hierarchical structure means that the computer connected to the expensive clock does not have to service requests from just any old Tom, Dick and Harriette, but only needs to service the computers in the layer immediately below it. This, in turn, means that those very few organizations that need a very high degree of precision for their synchronization can come to some special arrangment with an organization near the tip of the hierarchy while the masses of ordinary organizations and individuals can obtain lesser, but entirely adequate, precision by accessing a computer lower in the hierarchy.

The complete process of distributing reliable, useful time information around the www or any other network is quite complicated and if you are interested in knowing more about these things there is information available on the www and you can also begin by installing the documentation package “xntp-doc”.

From our point of view, all we needed was permission for our internal timeserver to update itself from a reasonably accurate server on the web. Fortunately various organizations around the world have made their computers available for public access in this respect.

The software

The Windows machines needed only the standard networking software that is installed when you configure the computer for networking. Likewise the DOS machines had network software that understood time requests. The only computers that needed to have software installed were the internal servers running SuSE Linux and, on them was installed the ntp software (“ntpd” — network time protocol daemon) and the documentation (“xntp-doc”). These packages were installed using SuSE's YaST tool.

The procedure

This is where we need to get a wee bit more technical:

Three groups of steps were needed:

First, it was necessary to establish a central, or master, time server for the local network.

Second, it was necessary to establish a secondary time server for the local network. This was needed in our case because of our network topology and the way that the computers were used throughout each day. In many, perhaps most cases, you could probably just have the single master time server for your network.

Third, having established a reference on the local network it was necessary to tell the DOS and Windows computers to refer to it.

Configuring the primary internal time server

On the internal timeserver machine the ntpd software was installed and the firewall modified to accept UDP requests on port 123. These tasks were done with the SuSE YaST package. The installation process created various configuration and data files, these being shown below:

/etc/ntp.conf
This is the principle configuration file and will need to be edited by hand.
/var/lib/ntp/
This directory was created as part of the install process and is the root of the “chroot jail” for the ntp process. For your confusion and intellectual taxation it then refers to itself recursively.
/var/lib/ntp/etc/
The “chroot” /etc directory.
/var/lib/ntp/etc/ntp.conf
This is the copy of the configuration file from /etc. Don't edit this file directly but, instead, edit the file /etc/ntp.conf which will then be copied to /var/lib/ntp/etc/ntp.conf by the SuSE startup script for the ntp daemon.
/var/lib/ntp/var/
The “chroot” /var directory.

This is how the configuration file ntp.conf looks. For clarity I have removed all the superfluous options that were, in any case, commented out.

###############################################################
## /etc/ntp.conf
##
## Sample NTP configuration file.
## See package 'xntp-doc' for documentation, Mini-HOWTO and FAQ.
## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany.
##
## Author of original: Michael Andres,   <ma@suse.de>
##
###############################################################


##
## Undisciplined Local Clock. This is a fake driver intended for backup
## and when no outside source of synchronized time is available.
##
server 127.127.1.0               # local clock (LCL)
fudge  127.127.1.0 stratum 10	# LCL is unsynchronized

##
## Outside source of synchronized time
##
## server xx.xx.xx.xx     # IP address of server
server   pool.ntp.org     # If your computer has routine access to DNS then
server   pool.ntp.org     # you can use the name of the computer instead of
server   pool.ntp.org     # using its IP address.


##
## Miscellaneous stuff
##

driftfile /var/lib/ntp/ntp.drift      # path for drift file
logfile   /var/log/ntp                # alternate log file

In the configuration file shown above the external server has been specified as pool.ntp.org and it has been specified three times. This domain name refers to a collection of public time servers and each time you access it your request will be routed to the next server in sequence. This means that there is both load sharing for the servers and redundancy for you. Specifying the server three times means that if one request fails, perhaps because a server has been switched off, your own ntp software will simply try again and will, ideally, be routed to a different and working server on the next request. You can see the load sharing operating by simply issuing ping requests to the host name pool.ntp.org and watching the results:

ping -c 3 pool.ntp.org

If you execute the above command five or six times you should find that you get responses from different computers in the pool.

Although the configuration file shown above makes reference to the global pool of network time servers it is possible that you might want to refer to a regional or national pool of servers and sometimes, if you have some very esoteric requirements, you might need to refer to a specific set of servers. You can obtain details of other public servers by making a visit to ntp.org and checking the information that they provide on their website.

The drift file is used by the ntp software for its own internal calculations. We did have a problem in that the drift file defined by the SuSE installation process didn't seem to correspond to the configuration file and after much fiddling and puzzlement success was achieved by creating the file by hand and modifying the configuration file to match. The confusion was exacerbated by the fact that the SuSE 9.0 installation creates a “chroot jail” for the software so the file is not referenced to the root of the filesystem but, instead, to the root as perceived by the ntpd software. The SuSE 8.1 installation, on the other hand, did not create a “chroot jail” so the locations of the data files were relative to the normal filesystem root — a little simpler but presumably less secure for publicly accessible networks. The problem was identified because the log file for the ntpd (“/var/log/ntp”) contained regular, periodic entries, complaining that the drift file was not accessible. It is possible, of course, that whatever confusion we experienced was because we messed-up somewhere but if you have similar problem keep our experience in mind.

The drift file exists at location /var/lib/ntp/var/ntp.drift relative to the real filesystem root but it is at location /var/lib/ntp/ntp.drift relative to the chroot environment. Also, it was necessary to change the access permissions for the directories before the ntp daemon could actually write to the file. The installation process allowed write access only to root:root so this had to be changed to allow anybody write access to the directory.

The ntp daemon can be started and stopped using the script that SuSE provides and which is called rcxntpd. For example, you would start the ntp daemon with the command: rcxntpd start and stop it with the command rcxntpd stop. The SuSE installation process should also arrange for the ntp daemon to be started automatically at boot time but you can verify this for yourself by using the YaST runlevel editor; you should find the ntp daemon listed as xntpd towards the bottom of the list of processes.

Attention: If you are not using SuSE Linux then you might have to create your own scripts for starting the ntp daemon when the computer starts. If this is the case then you need to be aware that when the ntpd starts its opinion about the real time could be wildly inaccurate and it might need special instructions to force it to update its own view of what the time actually is. You are earnestly encouraged to obtain and read the ntp documentation and / or visit the ntp.org web site.

The steps thus far have established a single timeserver on the local network and hosted, in our case, on the web site server computer. It was now necessary in our case to create a secondary timeserver; in your case you can quite likely skip this step and deal with the client machines. The explanation for why we had to create two time servers is this: The computer that supplies the time to the DOS and Windows workstations needed to be a machine running Samba in order that it would understand the DOS and Windows time requests. However the machine that was collecting the time from the outside world was our web site server which ran 24 hours a day and was in more or less permanent contact with the outside world but which did not have Samba installed on it.

The secondary internal time server

Our secondary server was configured almost the same as the primary; the same software and directories were created and the software was also told to run at boot time. However, whereas the primary timeserver collected the time from the ntp.org pool of computers, the secondary time server collected the time information from the primary time server. This arrangement means that only one computer within our organization places any load on the ntp.org pool of computers — this is good manners and also ensures that within our network all computers refer to the same source of time. Also, since the secondary time server was supposed to be providing the time to computers running DOS and Windows it was necessary to configure Samba to act as a time server for DOS and Windows clients. As with the primary server it was necessary to ensure that the firewall would allow UDP requests at port 123.

On the secondary time server the ntp.conf file included the following lines.

##
## Outside source of synchronized time
##
## server xx.xx.xx.xx     # IP address of server
server   192.168.0.99     # IP address of primary internal time server.

The single “server” line in the above excerpt replaces the three references to pool.ntp.org that were used in the configuration for the primary server and thereby causes the primary time server to be the solitary source of time reference for the secondary time server. Of course you will need to replace the IP address shown above with the hostname or IP address of your primary time server.

In the Samba configuration file (/etc/samba/smb.conf) it was necessary to add a single line to the global section of the file. A sample portion of the samba configuration file is shown below:

[global]
      # ... all your other global options ...
      time server = yes

The DOS and Windows client machines

Finally the users' individual workstation machines needed to be configured. This part was the easiest of all. These computers were simply told to collect their time information from our secondary timeserver which was also the Samba file server. If you only created a primary time server then, of course, you can tell them to refer to that so long as it is running Samba. A DOS or Windows machine can be told to collect time information very simply, the following command should do the trick: net time /SET /YES

In our case this command was placed in a batch file. The DOS machines simply make use of the batch file in the usual manner — a call from another batch file, for example — whenever it is appropriate. The Windows machines were told to execute the batch file every time the GUI starts and this was done by placing a link to the batch file into the startup folder. The properties of the link were then modified (right click on the link, choose properties) to tell Windows to close the window automatically when the process completes. Then, each time the Windows computer starts and shortly after the GUI starts, a DOS window will appear momentarily on the screen and then vanish again; it isn't the most elegant solution but it is quite unobtrusive and has the endearing quality of working reliably.

Summary

At the completion of this exercise we had all user DOS and Windows computers referring to a single source for their time information. Since that source was also (and was necessarily) the Samba file server for the network the access times on files were synchronized to within small and acceptable limits. The time for the internal network as a whole was synchronized to our web site server which was, in turn, synchronized. to the wider world via the ntp.org pool of time serving computers.

Navigation: (site map) learn linux home pagetechnical articles