Year of the Code Monkey

At work, I’m in charge of 20 individual build systems for one of our larger software project (18 Linux systems and 2 Windows systems). Every machine is connected to a private network that cannot see the outside world. As you might expect, the occasional “clock skew” warning would be thrown by gcc, since some of the source files had date stamps in the future. To fix this, I set out to learn about configuring NTP on a private network. As is typical of the Linux world, there was little useful documentation to be found. After gleaning little bits of information from a number of sources, I figured out how to do it, and I’m writing it down for everybody’s benefit.

Creating the NTP Master Server

Our first step is to create a ’server’ machine from which all of our other machines will get the time. In this tutorial, our master machine is a Linux box. Here’s how to set things up:

Step 1: Edit ntp.conf

The first course of action is to edit the ntp.conf file in the /etc directory. Place the following lines in this file, removing any others that may exist (you may want to back up your existing ntp.conf file just in case):

# Use the local clock
server 127.127.1.0 prefer
fudge  127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights
restrict 127.0.0.1

# Give machines on our network access to query us
restrict 192.1.1.0 mask 255.255.255.0 nomodify notrap

You’ll want to replace the highlighted sections with the private network address range that should be allowed to query this server, along with the corresponding mask, respectively. In this example, any machine on the 192.1.1.xxx network can query the master server for time updates.

Step 2: Restart the NTP daemon

Once the above changes have been made, the NTP daemon needs to be restarted. How to do this unfortunately differs among Linux distributions. Here are a few commands that I figured out for the OS families I care about:

• RedHat: service ntpd restart
• SLES 8/9: /etc/init.d/xntpd restart
• SLES 10: /etc/init.d/ntp restart

Step 3: Configure NTP to start on reboot

Perhaps the most important step in this process is configuring the NTP daemon to start up on a reboot. Here’s how to do it:

• RedHat: chkconfig ntpd on
• SLES 8/9: chkconfig xntpd on
• SLES 10: chkconfig ntp on

Configuring the Client Machines

Step 1: Edit ntp.conf

Client machines must also have their ntp.conf file updated (again, in the /etc directory). Place the following lines in the configuration file:

# Point to our network's master time server
server 192.1.1.100

restrict default ignore
restrict 127.0.0.1
restrict 192.1.1.100 mask 255.255.255.255 nomodify notrap noquery

driftfile /var/lib/ntp/drift

Both of the highlighted sections above should point to the master server (in this case, with an IP address of 192.1.1.100).

Step 2: Stop running NTP daemons

Use one of the following to stop any running NTP daemons:

• RedHat: service ntpd stop
• SLES 8/9: /etc/init.d/xntpd stop
• SLES 10: /etc/init.d/ntp stop

Step 3: Force an update

We must force the client to update now, in case the offset is larger than 1000 seconds (the largest offset NTP allows). To do this, issue the following command:

ntpdate -u 192.1.1.100

Again, replace the highlighted section with the IP address of the master server. Note that you may need to do this forced update two or three times to make sure things are synchronized.

Step 4: Start the NTP daemon

Now that we’ve synced the client, we should restart the daemon:

• RedHat: service ntpd start
• SLES 8/9: /etc/init.d/xntpd start
• SLES 10: /etc/init.d/ntp start

Step 5: Configure NTP to start on reboot

Finally, we need to make sure the daemon starts up at boot time (like we did for the server):

• RedHat: chkconfig ntpd on
• SLES 8/9: chkconfig xntpd on
• SLES 10: chkconfig ntp on

Once you’ve set this up, all the client machines will keep their clocks synchronized with the master. If you update the master server time, the clients should follow (as long as the update isn’t larger than 1000 seconds). I believe you can even point Windows systems to the master, though I have yet to try that.

Leave a Reply