Etudes 04- Private NTP
One of the common problems we have in our Case Study course is synchronizing logs and events across multiple machines.
Normally this is not a problem in a production environment, but the class poses some unusual challenges. First is the fact that the individual hosts all seem to end up with their local times all out-of-whack with one another, and so the guests end up inheriting these out-of-whack times. We could reset the times on the hosts, but that would require giving the students permissions to modify the time on the host, and that is not going to happen.
We could try to synchronize the times on the guests with an external server. Or we could, if the lab were not on a completely isolated network.
The solution? Each team can set up their own private time server- this way all of the time stamps on their internal network will agree.
In this little Etude, we are going to set up a Linux host to serve as a time server on a local private network; we will then show how to configure a Linux and a Windows host to get their time from that host.
If I find some free time later, I may come back to this and talk about using a Windows server as the time source.
Private Linux NTP Server
I learned this process some time ago by reading a wonderful blog post of Jonah Bishop on Year of the Code Monkey. Kudos to Jonah for writing such a nice piece. It is so good, I could probably just leave you with the link and be done with it, but let me add my own comments, explanations and amplifications.
We start with a Linux distribution with an installed NTP server, like the CentOS 6.2 x86-64 machine provided in the lab. Let’s verify that the NTP server,
ntpd is present on the system by determining its version:
[root@dimwell etc]# ntpd --version ntpd - NTP daemon program - Ver. 4.2.4p8
We then move on to the primary configuration file at
/etc/ntp.conf. For simplicity, we start with a blank configuration file, and then add the two lines
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10
The first line here tells NTP to use the server at 127.127.1.0 as the preferred server to get its time information. Now we know that the IP address 127.127.1.0 is a loopback interface; you can even ping it quite happily and receive replies from yourself. However, in this context it is a pseudo-IP that tells ntpd to use the system’s internal clock as a time source. The next line tells
ntpd how much confidence to put in the data from that server. Clocks are assigned to various stratum levels, with stratum 0 being the most accurate, essentially being atomic clocks. The higher the statum, the presumed less accurate the data source.
The next line we add to
In general computer clocks will run somewhat fast or slow; the ntp server can keep track of this an try to correct for these errors automatically. It does so by regularly comparing the local clock with the presumed accurate clock and storing the results in a file called a driftfile. This is the standard location for a driftfile; indeed this line is present in the default
/etc/ntp.conf file that is present in the default install.
Next, we determine which machines are allowed to access the ntp server, and what rights they have. The line
gives the local host full access to the server, while the last line
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
tells the server that any computer on 192.168.1.0/24 can receive time data, but cannot change the server state.
The completed file
/etc/ntp.conf then is
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
To complete the server setup, first start the server using e.g.
[root@shades etc]# /etc/init.d/ntpd start
Configure the daemon to start on boot, via
chkconfig or on our CentOS 6.2 by System → Administration → Services.
Finally, open the proper port in the firewall; in this case it is UDP port 123.
This completes the set up of the server.
A Linux Client
The process of setting up the client is similar, but now the corresponding file
/etc/ntp.conf on the client is
server 22.214.171.124 driftfile /var/lib/ntp/drift restrict default ignore restrict 127.0.0.1 restrict 126.96.36.199 mask 255.255.255.255 nomodify notrap noquery
where the address 192.168.1.60 is the address of the time server we created earlier.
The server line and the driftfile line are self explanatory and have the same syntax as we saw for the server. The next line,
restrict default ignore means that the default policy for this host is to ignore time requests from any host not explicitly given access. The next line,
restrict 127.0.0.1 overrides the default deny policy, and allows the localhost to monitor the server.
Lastly, we give access to the single host 192.168.1.60, our time server. The
nomodify command means that this server is not allowed to modify the ntpd settings on this host;
noquery means that the server is not allowed to ask this server for information about version numbers and the like; and the command
notrap means that the server will not be able to ask for debugging control messages from this host.
The ntp server is designed to make small corrections to the system time to slowly bring it into alignment with the time server(s) specified in the configuration file. The reason is makes the corrections slowly is that a number of processes depend on accurate time, and could be tripped up if the system time jumps too quickly. The downside of this is that it can take quite some time before the ntp synchronizes the time on the system with that of the server.
We can, however, get the process started with a bang, by running the command
ntpdate and giving the address of the server:
[root@dimwell ~]# ntpdate 192.168.1.60 1 Feb 12:51:12 ntpdate: step time server 192.168.1.60 offset 110.259640 sec
It is important to note that this command cannot be run while the ntp server is running; attempting to do so will result in a thrown error:
[root@dimwell ~]# ntpdate 192.168.1.60 1 Feb 12:52:59 ntpdate: the NTP socket is in use, exiting
Once the initial synchronization of the machine with the server is complete, you can again start the ntp service, ensure that it starts on boot, and open the firewall (UDP/123) for data.
Once your ntp server is running, you can query it for is current status. On the time server, you can see something like
[root@shades etc]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 30 64 377 0.000 0.000 0.000
On a client you will see something like
[root@dimwell ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 188.8.131.52 .INIT. 16 u - 64 0 0.000 0.000 0.000
though the values would be different. In this example, both machines are virtual machines running on the same host, which partially explains why the jitter values are zero; this is not typical of a network connection.
Linux systems will happily present date and time information in any timezone. Changing the timezone used is as simple as updating one file. Suppose for example that you have one of the Ubuntu 10.04 virtual machines set up in the lab. Running the date command, you discover
seldon@capella:~$ date Sat Apr 6 10:01:07 PDT 2013
to see that the system is set to Pacific time rather than Eastern time. The file that determines the system timezone is
/etc/localtime. All we need to do is to modify it so that it points to a different time zone- say the time zone for New York City. The different timezone files are available in the directory
/usr/share/zoneinfo and are all appropriately named. Simply set up a symbolic link between the
/etc/localtime and the appropriate time zone data:
seldon@capella:~$ sudo mv /etc/localtime /etc/localtime.bak seldon@capella:~$ sudo ln -s /usr/share/zoneinfo/America/New_York /etc/localtime seldon@capella:~$ date Sat Apr 6 13:04:44 EDT 2013
Members of a Windows domain will attempt to synchronize their time with the settings on the domain controller; to that end we simply need to set the domain controller(r) to get their time directly from out NTP server. We can do so following Microsoft’s instructions. From an administrator command prompt, run
C:\Windows\system32>w32tm /config /manualpeerlist:192.168.1.60 /syncfromflags:manual /reliable:yes /update
To explain this command, we are telling the time system to configure the time system to sync its time information manually from the system at 192.168.1.60, and that this time server should be considered reliable. Once the change is made, we can re-start the time server:
C:\Windows\system32>net stop w32time The Windows Time service is stopping. The Windows Time service was stopped successfully. C:\Windows\system32>net start w32time The Windows Time service is starting. The Windows Time service was started successfully.
It will take a few minutes for the time on the system to adjust and match the time on the server.
You can get more information about the sync process by querying the system:
C:\Windows\system32>w32tm /query /status Leap Indicator: 0(no warning) Stratum: 12 (secondary reference - syncd by (S)NTP) Precision: -6 (15.625ms per tick) Root Delay: 0.0312500s Root Dispersion: 8.7250172s ReferenceId: 0x0A000264 (source IP: 192.168.1.60) Last Successful Sync Time: 4/6/2013 1:27:47 PM Source: 192.168.1.60 Poll Interval: 6 (64s)
A Windows Client
If a Windows system is not connected to a domain, then the process is simpler. As an example, suppose we want to configure a stock Windows 7 machine to get its time from our new server. Right click on the clock in the taskbar, and select Adjust date/time. You will be presented with a dialog box with three tabs; select the “Internet Time” tab to obtain the following box:
Select the “Change Settings” button and specify the IP address of the time server; in our example this is 192.168.1.60.
Press the “Update Now” button to, well, update the time to that on the server right away. Then select “OK”, and the host will continue to synchronize its time with your server.