Another option is to use ntpdate to synchronize your internal NTP server with the public timeservers. Before proceeding with ntpdate, you should be aware that there is no sanity checking performed prior to time and date changes. If the synchronization source is off by several hours or even days, your system time will suddenly be off by several hours or days. To use ntpdate, simply remove the "server" arguments and public timeservers from the /etc/ntp.conf file to prevent ntpd from performing synchronization. (/etc/ntp.conf configuration is explained later).

You can tell ntpdate to synchronize time on each boot by adding the following to /etc/rc.conf:

ntpdate_enable="YES"
ntpdate_flags="[name_or_IP_of_timeserver]"

Additionally, you can add a cron job to run the following script, say maybe once a day. (ntpdate needs to run 2 times on each external synchronization source, and the script will need to bring up your link if PPP is not configured to bring it up automatically):

# update time with ntpdate
ntpdate [name_or_IP_of_1st_NTP_server]
ntpdate [name_or_IP_of_1st_NTP_server]

I have seen mention of "slicker" ways to deal with NTP and part-time connections, but have never tested them. You may want to Goggle it.

For Linux users, it is probably installed, but not always. As there are many different ways to install packages on the variety of Linux distributions, I will focus on the popular Red Hat distribution. Chances are, if you are using something different, you already know how to install it. Lets find out if ntpd is installed on a Red Hat 9.0 machine.

rpm -q ntp

If you receive zero output, then ntpd is not installed. In my case, rpm returned "ntp-4-1.1.1a-9". Yes, it is already installed. Though we may want to consider upgrading to the latest package. Either way, the following command will perform a new installation of ntpd or upgrade an existing instillation. This example assumes you downloaded ntp-4.1.2-0.rc1.2.i386.rpm.

rpm -Uvh ntp-4.1.2-0.rc1.2.i386.rpm

I have seen many, I mean many, different ways of configuring ntpd. I chose to use a fairly restrictive configuration. In the following example, NTP query and control messages from everyone are denied except those we specifically allow, though the only command that is actually required for ntpd to function is a single "server" command. The 1.1.1.1, 2.2.2.2, 3.3.3.3 represent the addresses for our synchronization sources and are fake. You should have at least 3 synchronization sources, but can add more. Our internal network for this example is assumed to be 192.168.1.0 with a subnet mask of 255.255.255.0. Obviously, these numbers may need to be change for your real configuration.

# /etc/ntp.conf 

restrict default ignore

restrict 127.0.0.1

restrict 1.1.1.1 mask 255.255.255.255 nomodify notrap noquery	
server 1.1.1.1

restrict 2.2.2.2 mask 255.255.255.255 nomodify notrap noquery
server 2.2.2.2 

restrict 3.3.3.3 mask 255.255.255.255 nomodify notrap noquery
server 3.3.3.3

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap noquery notrust 
	
driftfile /etc/ntp/drift

The restrict default ignore, ignores all NTP packets from all hosts. The restrict is a keyword followed by the arguments default and ignore. The default represents a default entry of (address 0.0.0.0, mask 0.0.0.0), which means everything. We could also write this as restrict 0.0.0.0 mask 0.0.0.0 ignore. In this example, we begin our configuration by denying everything, and later allowing specified host addresses and subnets. Without these restrictions, anyone on the Internet could use your machine as a timeserver.

Note: You must add a restriction for each timeserver IP address when you use the "ignore" argument. This will be explained more as we go, but I should tell you now that the restrict key word only works with IP addresses and not DNS names.

When opening ntp.conf with a default restriction, we must then specifically allow our own machine (localhost 127.0.0.1) to communicate with itself. We do this by adding restrict 127.0.0.1 with no arguments. Rather than using something logical like "allow", which does not exist in NTP, we instead use the "restrict" command with no arguments. Just seems odd to me, but that's how it works.

The next three groups of entries make up our chosen synchronization sources, AKA: Internet timeservers. Again, we are using the restrict keyword to override our default restriction of ignore. However, we are tagging on a few restriction arguments because we do not fully trust the Internet timeservers. In the first example, 1.1.1.1 is the IP address of a timeserver. The section mask 255.255.255.255 identifies that we are referring to the single IP address as opposed to a subnet. The nomodify, notrap, and noquery arguments deny NTP control and configuration messages from this IP address, but still allow us to query time. (Actually, I believe nomodify and notrap are redundant when we use the noquery argument, however, I have never tested it, but there is no harm in a little redundancy.)

Now, if we want our internal clients to use this machine as a synchronization source, we need to add a restriction command allowing them to query time. Rather than specify each client machine, which would be insane, we will allow queries from our entire internal subnet with restrict 192.168.1.0 mask 255.255.255.0 (This example assumes your client machines are using address range 192.168.1.1 to 192.168.1.254 with a defined subnet mask of 255.255.255.0). Just as before, the nomodify, notrap, and noquery arguments deny NTP control and configuration messages, but this time from our local subnet. Notice though, that we have added the notrust argument to prevent our timeserver from using machines on our own subnet as synchronization sources.

Finally, driftfile /etc/ntp/drift, declares the path to our optional drift file which can be created anywhere we choose. What is a drift file? In short, ntpd can calculate and predict how far your system time is prone to drift. This information is stored in the driftfile and can be used if NTP servers are unavailable for an extended period of time. I should note that you do not have to create the actual drift file, ntpd will create it after running for 1 hour, and update it every hour after that.

Note: Why use the IP addresses rather than the DNS names? While referring to DNS names in often recommended for other services, I prefer to use IP addresses for external synchronization sources for a couple of reasons. First, firewall configuration is difficult and often impossible when using DNS names with firewall rules. There are startup issues (DNS is not available until after the firewall rules have loaded) and some timeservers may have multiple addresses associated with a single name. You may open a port for one address while ntpd will attempt to contact the server on a different address and be blocked. Second, and most importantly, the restrict option does not work with DNS names. Also, while I do prefer to use IP address for external synchronization sources, I always use a DNS name(s), usually an alias, for my internal synchronization source(s). Reasons being, I can easily move my NTP server to a different machine without having to reconfigure each client; I can set the restrict keyword to identify my internal subnet(s) which will apply to all internal clients; Lastly, I do not filter UDP port 123 traffic on my internal subnets, thus, there are no firewall issues preventing clients from successfully using a DNS name.

ntpdate ntp_server.example.com
ntpdate ntp_server.example.com

The first run will display the offset, and the second run will adjust the clock. If you receive "the NTP socket is already in use" then you already have ntpd running or something else is using the NTP socket. If ntpdate is unable to contact the host, then it is likely you will need to open UDP port 123 on your firewall (or the host is down).

Note: Newer versions of ntpd provide the -g option to forgo sanity checking and zap in the correct date and time. However, I have never successfully used this option and hear tell most kernels will not allow it in multi-user mode.

Now that we have /etc/ntp.conf configured, and our time and date is in the ballpark, lets start ntpd manually to see if we have syntax errors. But first, a message from the ntp.conf man page: "The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected." Now, start ntpd with the following:

ntpd -p /var/run/ntpd.pid

If you received errors, kill the process, check your /etc/ntp.conf, and restart ntpd. (You can kill ntpd's PID or use killall ntpd to stop ntpd). If ntpd did not complain when you started it, it might be working. Lets find out by using ntpq. Note that ntpd may need to run for a minute or two before ntpq is successful.

ntpq -p (Note that this is ntpq and not ntpd)

The result is a bit cryptic, but you can refer to the NTPQ man page for explanations. The important thing is that you do not receive a LOT of zeros from your synchronization sources and the jitter is something other than 4000. The below example shows successful synchronization with "clock.example.org" and failed synchronization with "ntp1.example.com".

 remote             refid           st  t when  poll   reach   delay   offset   jitter
========================================================================================
clock.example.org   ntp0.broad.mit.  2  u  132  1024   377  152.649   -11.921   3.962
ntp1.example.com    0.0.0.0          2  u   -   64     0    0.000      0.000    4000

To start ntpd on boot, we simply need to add xntpd_enable="YES" to /etc/rc.conf. (On FreeBSD5.x, replace xntpd with ntpd ). You can check /etc/defaults/rc.conf for more details, but be sure to make your changes to /etc/rc.conf.

Note: The correct entry for FreeBSD 4.x is in fact xntpd_enable rather than ntpd_enable even though the real xntpd is an older version of NTP. Why? Lets find out. First we need to know that /etc/defaults/rc.conf is always read when FreeBSD boots and that /etc/rc.conf simply overrides these defaults. Now lets look at all lines with "xntpd" in /etc/defaults/rc.conf by using our good friend grep: grep xntpd /etc/defaults/rc.conf xntpd_enable="NO" # Run ntpd Network Time Protocol (or NO). xntpd_program="/usr/sbin/ntpd" # path to ntpd, if you want a different one. xntpd_flags="-p /var/run/ntpd.pid" # Flags to ntpd (if enabled). Notice the xntpd_program="/usr/sbin/ntpd" which points FreeBSD to ntpd rather than the older xntpd. Also notice that the pid file is declared for us in the default rc.conf file. Even though the default file states xntpd_enable="NO", we are overriding it with "YES" in /etc/rc.conf.

pgrep ntpd (If pgrep is not recognized, then use ps aux | grep ntpd)

No output indicates that it is not running and we can move on. If it is running, pgrep will have returned the process ID and you may want to kill it for now with kill process_id_number.

If your system time is a little off from the public timeservers, ntpd will gradually synchronize your clock. If there is a significant difference between your system time and the public timeservers (more than 1,000 seconds), ntpd will fail a sanity check. In this case, you will either need to manually set your system (CMOS) time to something reasonably close, or better yet, use ntpdate to force a synchronization by issuing the following command twice against the same time server: CAUTION: ntpdate is capable of making very significant time and date changes. If you clock is way off, these changes can produce some very unexpected results.

ntpdate ntp_server.example.com
ntpdate ntp_server.example.com

The first run will display the offset, and the second run will adjust the clock. If you receive "the NTP socket is already in use" then you already have ntpd running or something else is using the NTP socket. If ntpdate is unable to contact the host, then it is likely you will need to open UDP port 123 on your firewall (or the host is down).

Note: Newer versions of ntpd provide the -g option to forgo sanity checking and zap in the correct date and time. However, I have never successfully used this option and hear tell most kernels will not allow it in multi-user mode.

Now that we have /etc/ntp.conf configured, and our time and date is in the ballpark, lets start ntpd manually to see if we have syntax errors. But first, a message from the ntp.conf man page: "The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected." Now, start ntpd with the following:

service ntpd start

If you received errors, kill the process, check your /etc/ntp.conf, and restart ntpd (You can stop ntpd with service ntpd stop). If ntpd did not complain when you started it, it might be working. Lets find out by using ntpq. Note that ntpd may need to run for a minute or two before ntpq is successful.

ntpq -p (Note that this is ntpq and not ntpd)

The result is a bit cryptic, but you can refer to the NTPQ man page for explanations. The important thing is that you do not receive a LOT of zeros from your synchronization sources and the jitter is something other than 4000. The below example shows successful synchronization with "clock.example.org" and failed synchronization with "ntp1.example.com".

 remote             refid           st  t when  poll   reach   delay   offset   jitter
========================================================================================
clock.example.org   ntp0.broad.mit.  2  u  132  1024   377  152.649   -11.921   3.962
ntp1.example.com    0.0.0.0          2  u   -   64     0    0.000      0.000    4000

Now lets configure ntpd to start on boot. You will need to use the tool appropriate for your Linux distribution, or even Webmin. The following examples use chkconfig available on Red Hat, but often included on other distributions. Lets take a look at the ntpd run levels with chkconfig --list ntpd.

chkconfig --list ntpd
    ntpd    0:off   1:off   2:off    3:off    4:off    5:off    6:off

Looks like all run levels are off. Now lets configure it to start using the default runlevel:

chkconfig ntpd on

Now lets take a look at those run levels again:

chkconfig --list ntpd
    ntpd    0:off   1:off   2:on    3:on    4:on    5:on    6:off

If you are less paranoid, it is best to only allow external UDP 123 traffic between your internal NTP server(s) and your chosen external NTP public servers while denying your internal clients access to any external NTP servers. This does nothing to prevent IP spoofing, but it does provide an additional layer of security and helps to hide your NTP port from scanners.

The bottom line is that you need to consider the consequences of having your network time high-jacked. If someone else can control your time, then scheduled jobs, log files, time-based authentication, file synchronization, and more can all be effected. This is an unacceptable risk for a large company, however, the benefits of free synchronized time are probably more than worth it for home and most small businesses. While I am touching on security, I should probably mention that NTP version 4 provides symmetric-key and public-key authentication. Please refer to the NTP.CONF man page for more information.

Samba Note: Samba Note: If you have a Samba server configured to emulate a Windows Domain controller, it may be possible to configure Samba to emulate a Windows timeserver by setting time server = yes in the Samba configuration file. In theory, your Windows 2000/XP clients would then synch time from the Samba server thinking it was a Windows Domain controller. At least that is how I understand the documentation, but have yet to implement it myself. Nonetheless, if you are using Samba, you may want to investigate.

Note: Windows NT does not come with W32Time, however, The Windows NT Resource Kit contains a W32Time client that can be installed and should act much like W32Time of Windows 2000/XP.

To configure W32Time on Windows 2000/XP, we will need to set the following registry values:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Start=0x2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type="NTP"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer="ntp.domain.example"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"NtpServer"="ntp.domain.example"
"Type"="NTP"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time]
"Start"=dword:00000002