Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
126 views

Basic NTP Configuration

This well help you to have each step by step of configuring NTP configuration in all unix flavours. This is containing screenshot of each and every step output. Definitely will help you any person to wanted to become master in NTP configuration.

Uploaded by

raajuece
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
126 views

Basic NTP Configuration

This well help you to have each step by step of configuring NTP configuration in all unix flavours. This is containing screenshot of each and every step output. Definitely will help you any person to wanted to become master in NTP configuration.

Uploaded by

raajuece
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

Basic NTP configuration

The NTP program is configured using either the /etc/ntp.conf or /etc/xntp.conf file depending on what distribution of Linux you have. I won't go into too much detail on how to configure NTP. Instead I'll just cover the basics. An example of a basic ntp.conf file would look like:
# --- GENERAL CONFIGURATION --server aaa.bbb.ccc.ddd server 127.127.1.0 fudge 127.127.1.0 stratum 10 # Drift file. driftfile /etc/ntp/drift

The most basic ntp.conf file will simply list 2 servers, one that it wishes to synchronize with, and a pseudo IP address for itself (in this case 127.127.1.0). The pseudo IP is used in case of network problems or if the remote NTP server goes down. NTP will synchronize against itself until the it can start synchronizing with the remote server again. It is recommended that you list at least 2 remote servers that you can synchronize against. One will act as a primary server and the other as a backup. You should also list a location for a drift file. Over time NTP will "learn" the system clock's error rate and automatically adjust for it. The restrict option can be used to provide better control and security over what NTP can do, and who can effect it. For example:
# Prohibit general access to this service. restrict default ignore # Permit systems on this network to synchronize with this # time service. But not modify our time. restrict aaa.bbb.ccc.ddd nomodify # Allow the following unrestricted access to ntpd restrict aaa.bbb.ccc.ddd restrict 127.0.0.1

It is advised that you wait until you have NTP working properly before adding the restrict option. You can accidental restrict yourself from synchronizing and waste time debugging why.

NTP slowly corrects your systems time. Be patient! A simple test is to change your system clock by 10 minutes before you go to bed and then check it when you get up. The time should be correct. Many people get the idea that instead of running the NTP daemon, they should just setup a cron job job to periodically run the ntpdate command. There are 2 main disadvantages of using using this method. The first is that ntpdate does a "brute force" method of changing the time. So if your computer's time is off my 5 minutes, it immediately corrects it. In some environments, this can cause problems if time drastically changes. For example, if you are using time sensitive security software, you can inadvertently kill someones access. The NTP daemon slowly changes the time to avoid causing this kind of disruption. The other reason is that the NTP daemon can be configured to try to learn your systems time drift and then automatically adjust for it.

14.7. NTP Toolkit


There are a number of utilities available to check if NTP is doing it's job. The ntpq -p command will print out your system's current time status.
# ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================== ====== *cudns.cit.corne ntp0.usno.navy. 2 u 832 1024 377 43.208 0.361 2.646 LOCAL(0) LOCAL(0) 10 l 13 64 377 0.000 0.000 0.008

The ntpdc -c loopinfo will display how far off the system time is in seconds, based upon the last time the remote server was contacted.
# ntpdc -c loopinfo offset: frequency: poll adjust: watchdog timer: -0.004479 s 133.625 ppm 30 404 s

ntpdc -c kerninfo will display the current remaining correction.


# ntpdc -c kerninfo pll offset: pll frequency: -0.003917 s 133.625 ppm

maximum error: estimated error: status: pll time constant: precision: frequency tolerance: pps frequency: pps stability: pps jitter: calibration interval: calibration cycles: jitter exceeded: stability exceeded: calibration errors:

0.391414 s 0.003676 s 0001 pll 6 1e-06 s 512 ppm 0.000 ppm 512.000 ppm 0.0002 s 4 s 0 0 0 0

A slightly more different version of ntpdc -c kerninfo is ntptime


# ntptime ntp_gettime() returns code 0 (OK) time c35e2cc7.879ba000 Thu, Nov 13 2003 11:16:07.529, (.529718), maximum error 425206 us, estimated error 3676 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -3854.000 us, frequency 133.625 ppm, interval 4 s, maximum error 425206 us, estimated error 3676 us, status 0x1 (PLL), time constant 6, precision 1.000 us, tolerance 512 ppm, pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.

Yet another way to see how well NTP is working is with the ntpdate -d command. This will contact an NTP server and determine the time difference but not change your system's time.
# ntpdate -d 132.236.56.250 13 Nov 14:43:17 ntpdate[29631]: ntpdate 4.1.1c-rc1@1.836 Thu Feb 13 12:17:20 EST 2003 (1) transmit(132.236.56.250) receive(132.236.56.250) transmit(132.236.56.250) receive(132.236.56.250) transmit(132.236.56.250) receive(132.236.56.250) transmit(132.236.56.250) receive(132.236.56.250) transmit(132.236.56.250) server 132.236.56.250, port 123 stratum 2, precision -17, leap 00, trust 000 refid [192.5.41.209], delay 0.06372, dispersion 0.00044 transmitted 4, in filter 4 reference time: c35e5998.4a46cfc8 Thu, Nov 13 2003 14:27:20.290 originate timestamp: c35e5d55.d69a6f82 Thu, Nov 13 2003 14:43:17.838

transmit timestamp: c35e5d55.d16fc9bc Thu, Nov 13 2003 14:43:17.818 filter delay: 0.06522 0.06372 0.06442 0.06442 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000036 0.001020 0.000527 0.000684 0.000000 0.000000 0.000000 0.000000 delay 0.06372, dispersion 0.00044 offset 0.001020 13 Nov 14:43:17 ntpdate[29631]: adjust time server 132.236.56.250 offset 0.001020 sec

If you want actually watch the system synchronize you can use ntptrace.
# ntptrace 132.236.56.250 cudns.cit.cornell.edu: stratum 2, offset -0.003278, synch distance 0.02779 truetime.ntp.com: stratum 1, offset -0.014363, synch distance 0.00000, refid 'ACTS'

If you need your system time synchronized immediately you can use the ntpdate remote-servername to force a synchronization. No waiting!
# ntpdate 132.236.56.250 13 Nov 14:56:28 ntpdate[29676]: adjust time server 132.236.56.250 offset -0.003151 sec

You might also like