ntp - there's gotta be a correct way

schome1 · 2004-07-17 03:23:21

I've done a search in the arch linux forum on ntp and read everything about how to get ntpd to work correctly. I still can't get it to synchronize my time. I can, however, run ntpdate to get my time synchronized. Why does ntpdate work and ntpd not work? My time is 10 minutes fast (I purposely set it this way).

Does anyone know how to get ntp working. I think a lot of people would like to know.

Thanks

Bobonov · 2004-07-17 12:25:24

There is no particular trick.
At first what do you mean with "my time is 10 minutes fast"???

Anyway at first I suggest you to set your clock (in rc.conf) on UTC and set properly your time zone.
Then go on
http://twiki.ntp.org/bin/view/Servers/W … ime_Server
and chose a server near you, specify in the ntp.conf if you chosed one from starum 1 or stratum 2 list.
Possibly chose a server that is "near" to your location
then set properly the system time before starting ntp for the first time
you can do it by running
ntpdate <remote_ntp_server>
An example of very basic and simple ntp.conf is

server   ntp1.ien.it minpoll 6   maxpoll 14 stratum 1
server 127.127.1.0 stratum 10    # local clock
fudge  127.127.1.0 stratum 10    # local clock
driftfile /etc/ntp/ntp.drift
logfile /var/log/lntp.log

Ntp can take a long time to sincronize the clock.
The server is made to do the sync very slowly by increasing/decreasing the clock speed. In this way critical application do not have jump in timing and logs do not look weird.
The drift file save the medium speed correction needed to keep the hardware clock in line with remote server
These two line
server 127.127.1.0 stratum 10 # local clock
fudge 127.127.1.0 stratum 10 # local clock
tells to ntpd to sincronize with the local clock in case of other server failure.
There are also many other device you can use with ntp instead of netwrok server, like gps or radioclock.
I hope it is enought.
Anyway if you use your computer as desktop system , that mean that you turn it off often, you better use a ntpdate at startup to do the sincronization. ntpd is efficent onlyif it run for a long time, like on a server

jak · 2004-07-17 14:42:06

schome1 wrote:

I've done a search in the arch linux forum on ntp and read everything about how to get ntpd to work correctly

Did you see my post? http://bbs.archlinux.org/viewtopic.php? … highlight=

Does anyone know how to get ntp working

The info linked above, works for me.

schome1 · 2004-07-17 19:28:47

Thanks for the replies. What I meant by the fact that my clock is ten minutes fast is that I purposely set it that fast so I could test ntpd. I now realize that the clock should be set to the correct time using ntpdate (which I never had a problem getting to work) and then using ntpd to keep it synchronized.

So my next question is this: Why are some examples of ntp.conf files using restrict lines and some are not. I read that ntpd has had some security problems in the past. Do the restrict lines help with security? Some people set the stratum. Is this needed. See what I mean? Nowhere have I found a good document that explains what all of the options are, nor have I found a generic, secure config file that will just work.

Thanks again for explaining why ntpd was not instantly correcting my time. As for the security issue. If it is a problem with ntpd, then wouldn't it be wise just to put ntpdate in a cron job and run it as often as you feel necessary? Then there is one less daemon running on your system. So I guess what I'm asking is what benefit is there in running ntpd rather then ntpdate?

Thanks again.

jak · 2004-07-17 19:53:24

schome1 wrote:

what benefit is there in running ntpd rather then ntpdate

ntpdate may step your time backwards by a few seconds. This can be bad for some applications, possibly. Running the daemon ensures that your time is never stepped backwards (if configured and working correctly).

schome1 wrote:

Nowhere have I found a good document that explains what all of the options are, nor have I found a generic, secure config file that will just work

Use my conifig, and modify the servers as desired. Unless you want to invest the time in becoming an expert.

nkw · 2004-07-18 09:21:15

However, when i was using Jak's ntp.conf:

restrict default noquery notrust nomodify
#restrict 127.0.0.1
#restrict 24.60.16.0 mask 255.255.248.0
server tick.mit.edu
server ntp-2.vt.edu
server louie.udel.edu
server ntp-1.mcs.anl.gov
server clock.psu.edu
#server 127.127.1.0
#fudge 127.127.1.0 stratum 3
driftfile /etc/ntp.drift
logfile /var/log/ntp.log

My ntp.log file will show:
18 Jul 05:14:41 ntpd[11765]: ntpd exiting on signal 15
And time was not synchronized.

If I uncomment the commented lines. The log file will show:
18 Jul 03:58:47 ntpd[11532]: synchronized to 18.145.0.30, stratum=1
18 Jul 03:58:38 ntpd[11532]: time reset -8.797829 s
18 Jul 03:58:38 ntpd[11532]: kernel time sync disabled 0041
And time was still not synchronized.

However, if I just run ntpdate tick.mit.edu. The time will be set correctly. It 's very frustrated to set the ntpd correct, Or should I just use crond to run "ntpdate tick.mit.edut" regullarly?

Bobonov · 2004-07-18 12:17:44

Between running ntp and ntpdate there is a big difference.
As I wrote ntpd is indicate for server use or for computer that stay on contniusly or for very long time.
Under linux there are two clock, one ist the system(software) clock and the other is the hardware clock.
Basically ntp server pool the remote server and, based on the remote time, it decide how much it has to modify the drift to accellerate or slower the local system clock.
So ntpd accelerate/slow the clock untill it reach the correct time.
Example: the realtime is 17:50.00 and your local clock is 17:55.00, ntpd can take more than 24 hours to allineate correctly. Basically it will slow you system clock in the way that 1 second of your system clock is in reality 1.01 second of real time.
Once it has a very long time of statistic the drift is enought precise to have ntpd to keep a correct time.
In this way you software clock disallineate from the hardware one.
The problem is that when you switch the computer off the hardware clock goes on and the drift became wrong so ntpd have to start again.
So on short uptime period ntpd is completely unsefull, in this case is much better to add a little script that run just after network start that run ntpdate and regulate the time each time you turn on the pc.
I hope this clarify better how ntp work.
About the stratum.
ntpd is made to guarantee a very precise clock timing (in the order of microsecond) it is not only to keep the time correct. As I told you on the long period the system clock became more and more precise in the sense that 1 second of the system clock is more an more likely of one second of real time.
The stratum option is needed by ntp in order to calibrate the internal algoritm that calculate the dirft. It is not mandatory but it is no time to add it to ntp.conf

jak · 2004-07-18 12:58:07

nkw wrote:

However, when i was using Jak's ntp.conf:
restrict default noquery notrust nomodify
#restrict 127.0.0.1
#restrict 24.60.16.0 mask 255.255.248.0
server tick.mit.edu
server ntp-2.vt.edu
server louie.udel.edu
server ntp-1.mcs.anl.gov
server clock.psu.edu
#server 127.127.1.0
#fudge 127.127.1.0 stratum 3
driftfile /etc/ntp.drift
logfile /var/log/ntp.log
My ntp.log file will show:
18 Jul 05:14:41 ntpd[11765]: ntpd exiting on signal 15
And time was not synchronized.

You are misinterpreting the log messages. Let it continue running; but change your config, and DO NOT USE tick.mit.edu! See below.

If I uncomment the commented lines. The log file will show:
18 Jul 03:58:47 ntpd[11532]: synchronized to 18.145.0.30, stratum=1
18 Jul 03:58:38 ntpd[11532]: time reset -8.797829 s
18 Jul 03:58:38 ntpd[11532]: kernel time sync disabled 0041
And time was still not synchronized

Wrong again. Let it continue running. Don't worry about the "disabled" message. And DO NOT USE tick.mit.edu! See below.

However, if I just run ntpdate tick.mit.edu. The time will be set correctly. It 's very frustrated to set the ntpd correct, Or should I just use crond to run "ntpdate tick.mit.edut" regullarly?

DON'T USE tick.mit.edu! It's a stratum 1 server. You should not be using stratum 1 servers. Read the rules of engagement: http://www.eecis.udel.edu/~mills/ntp/servers.html, and always use stratum 2 servers, unless you truly have a legitimate reason to use a stratum 1 server.

:!:

schome1 · 2004-07-18 19:23:33

Hey, this is the kind of information I was looking for - thanks for all the posts!

I see now, I too was looking at the ntp.log file and was getting frustrated because of the messages. After letting it run, my messages look like this:

18 Jul 07:09:44 ntpd[10261]: synchronized to LOCAL(0), stratum=3
18 Jul 07:14:01 ntpd[10261]: synchronized to LOCAL(0), stratum=3
18 Jul 07:14:19 ntpd[10261]: ntpd exiting on signal 15
18 Jul 07:15:05 ntpd[10314]: ntpd exiting on signal 15
18 Jul 07:23:23 ntpd[10351]: synchronized to LOCAL(0), stratum=3
18 Jul 07:27:42 ntpd[10351]: synchronized to LOCAL(0), stratum=3
18 Jul 07:38:32 ntpd[10351]: kernel time sync enabled 0001

The last one is a good thing (I am hoping).

Also, thanks for the tip on not using stratum 1 servers.

Two more question regarding stratums and jak's config file. What does commenting out the lines you did gain us over not commenting them out? My ntpd appears to be running without them commented out, but I can't tell for sure because my time is still not perfect (it's only been running for 6 hours). Also, in the last post something was said about adding the stratum level in the config file. Is this referring to adding the words "stratum 2" for each server you have listed (assuming they are stratum 2 servers)?

Thanks

jak · 2004-07-18 20:52:06

schome1 wrote:

18 Jul 07:09:44 ntpd[10261]: synchronized to LOCAL(0), stratum=3
18 Jul 07:14:01 ntpd[10261]: synchronized to LOCAL(0), stratum=3
18 Jul 07:14:19 ntpd[10261]: ntpd exiting on signal 15
18 Jul 07:15:05 ntpd[10314]: ntpd exiting on signal 15
18 Jul 07:23:23 ntpd[10351]: synchronized to LOCAL(0), stratum=3
18 Jul 07:27:42 ntpd[10351]: synchronized to LOCAL(0), stratum=3
18 Jul 07:38:32 ntpd[10351]: kernel time sync enabled 0001

What does commenting out the lines you did gain us over not commenting them out? My ntpd appears to be running without them commented out, but I can't tell for sure

Look at your log. You are synchronizing to your own local clock! GET THOSE LINES OUT OF YOUR CONFIG FILE! Don't just comment them out, delete them, and forget them!

Also, in the last post something was said about adding the stratum level in the config file. Is this referring to adding the words "stratum 2" for each server you have listed (assuming they are stratum 2 servers)

Why do you want to complicate things by adding the stratum level? What advantage is that, to you? Unless you know the answer to that question, don't specify a stratum level. Just do what I told you to do. Exactly the way I told you to do it. No deviation, no improvisation. When you become an expert, then do it your way. But for now, just follow instructions and be happy.

Bobonov · 2004-07-19 09:12:09

As I wrote the stratum parameter influence the calculation of the drift and in case of more server it set a precedence between them.
lower number stratum are preferred than higer number but use the real stratum level.
Between each stratum there can be aa fraction of millisecond of difference, in this way ntpd "keep this in mind" and try to adjust the calculation consequently. The system try to be more precise as possible, ie it keep in consideration also network latency.

server 127.127.1.0 stratum 10 # local clock
fudge 127.127.1.0 stratum 10 # local clock

This allow ntpd to keep on running in case of network failure or device failure.
This setting tell to ntpd to use the localclok as reference and, since it is exaclty as it should be, the drift does not change and the polling result is not considered for statistic.
stratum 10 option ensure that is used as very last resource.
Why is usefull to poll the local clock? The main reason is that if ntpd is not able to pool any source for a certain ammount of time get stressed and feel alone in the world. I am jocking naturally, I think is a question how the statistic alghoritm is implemented.
Anyway unless you need very precise time measuring for science experiment you can jump both stratum and localclok configuration.

marin_linuxer · 2004-07-20 18:19:29

Just thought I would pipe-in a reminder of the great 'pool.ntp.org' round-robin time servers. It will help load-balance the demand on first-tier servers:

#server pool.ntp.org

More info: http://www.pool.ntp.org/

cs25x · 2004-07-21 00:03:37

Here is a script from CPAN, I made some changes to get y2k and month rollovers to work ( i think those are the changes ) However it seems to have vanished from the net.

#!/usr/bin/perl  
#        $Id: nist.pl,v 1.12 2000/02/07 07:02:18 j Exp $
#
# Nist.pl to keep your system time up to date by using time servers.
# Copyright (C) 1998, 1999, 2000 Ali Onur Cinar <root@zdo.com>
# Y2K fixes by Frank Denis aka Jedi/Sector One <j@4u.net>
#
# Latest version can be downloaded from:
#
#   http://www.zdo.com
#   ftp://hun.ece.drexel.edu/pub/cinar/nist*
#   ftp://ftp.cpan.org/pub/CPAN/authors/id/A/AO/AOCINAR/nist*
#   ftp://sunsite.unc.edu/pub/Linux/system/admin/timei/nist*
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version. And also
# please DO NOT REMOVE my name, and give me a CREDIT when you use
# whole or a part of this program in an other program.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.

use Socket qw(PF_INET SOCK_STREAM AF_INET);
use POSIX qw(mktime);

$timeserver = 'ntp.massey.ac.nz';    # time server
$timeserver = 'ntp.public.otago.ac.nz';    # time server
$timeserver = 'ntp.saard.net';    # time server
$timeserver = 'time.deakin.edu.au';    # time server
$timeserver = 'time_a.timefreq.bldrdoc.gov';    # time server
$port = '13';                    # time port (default:13)

    # time differance AUCKLAND .nz
$timediff = '+11:00:00';            # time differance
$timediff = '+13:00:00';            # time differance AUK summer
$timediff = '+12:00:00';            # time differance AUK winter

$datepr = '/bin/date';                # full path of date

open (FOO,">","/tmp/fooi");

print (FOO "local time ");

$timediff =~ /(.)(..):(..):(..)/g;

$diff = (($2*3600)+($3*60)+$4);
$diff = "$1$diff";

print (FOO " DIFF -> ");
print (FOO $diff);
print (FOO "n");y


if ($> ne 0)
{
    print STDERR "This program should run as root user to be able to update sytem date.n"; 
#    exit;
}

if ($timeserver =~ /^(d+).(d+).(d+).(d+)$/)
{
    $timeserver_addr = pack('C4', $1, $2, $3, $4);
} else {
    $timeserver_addr = gethostbyname($timeserver);
}

print FOO "Connecting to $timeserver on port $port...n";

if (!socket(NIST, AF_INET, SOCK_STREAM, getprotobyname("tcp") || 6))
{
    print "socket failed ($!)n"; exit;;
}

if (!connect(NIST, pack('Sna4x8', AF_INET, $port, $timeserver_addr)))
{
    print (FOO "connect to $timeserver failed ($!)n"); exit;
}

while (<NIST>)
{
    $time_data_raw = $_;
    last if ( /NIST/);
}
close NIST;


$time_data_raw =~ /.{6}(..).(..).(..).(..).(..).(..)/g;
print (FOO "Current UTC is $1-$2-$3 $4-$5-$6n");

&DateToSec($1,$2,$3,$4,$5,$6);

print (FOO "difference is $diffn");
print (FOO "result of DateToSec (datsec) is: <<$datsec>>n");
print (FOO "result of localtime(datesec)) is:: ");
print (FOO localtime($datsec));
print (FOO "n");

$datsec += $diff;

&SecToDate($datsec);

printf (FOO "Local time is  %04d-%02d-%02d %02d-%02d-%02dn", $year, $month, $day, $hour, $min, $sec);
print (FOO "Updating the system time.   ||");
$date_command = sprintf ("$datepr %02d%02d%02d%02d%04d.%02d",$month, $day, $hour,$min, $year, $sec);
system ($date_command);
print (FOO $date_command);
print (FOO "||  Done.n");
exit;

sub DateToSec
{
    $year = $_[0];$month = $_[1];$day = $_[2];
    $hour = $_[3];$min = $_[4];$sec = $_[5];
#    $datsec = POSIX::mktime($sec, $min, $hour, $day - 1, $month - 1, $year + 100);
    $datsec = POSIX::mktime($sec, $min, $hour, $day , $month ,  $year + 100);
}

sub SecToDate
{
#    $datsec = $_[0];

($sec, $min, $hour, $day, $month, $year, $wday, $yday, $isdst) = localtime($datsec);
#    $day++;
#    $month++;
    $year += 1900;
}

I realise this is not ntp, but it is simple and useful for a box that gets turned off, you can run it at boot time. You have to fix your own $timediff relative to UTC and you can use another $timeserver too.
It logs to /tmp/fooi, for want of a better place. Those strange comments are probably remnants of original code. It has to be run by root or su. suid is not a good idea.

slackhack · 2004-07-21 01:45:41

nkw wrote:

However, when i was using Jak's ntp.conf:
restrict default noquery notrust nomodify
#restrict 127.0.0.1
#restrict 24.60.16.0 mask 255.255.248.0
server tick.mit.edu
server ntp-2.vt.edu
server louie.udel.edu
server ntp-1.mcs.anl.gov
server clock.psu.edu
#server 127.127.1.0
#fudge 127.127.1.0 stratum 3
driftfile /etc/ntp.drift
logfile /var/log/ntp.log
My ntp.log file will show:
18 Jul 05:14:41 ntpd[11765]: ntpd exiting on signal 15
And time was not synchronized.
If I uncomment the commented lines. The log file will show:
18 Jul 03:58:47 ntpd[11532]: synchronized to 18.145.0.30, stratum=1
18 Jul 03:58:38 ntpd[11532]: time reset -8.797829 s
18 Jul 03:58:38 ntpd[11532]: kernel time sync disabled 0041
And time was still not synchronized.
However, if I just run ntpdate tick.mit.edu. The time will be set correctly. It 's very frustrated to set the ntpd correct, Or should I just use crond to run "ntpdate tick.mit.edut" regullarly?

you need to take out the "notrust" option in the first line. also, uncomment the restrict 127.0.0.1 line.

your ntp.conf should look something like this:

restrict default noquery nomodify
restrict 127.0.0.1
fudge 127.127.1.0 stratum 3
server <server 1>
server <server 2>
server <server 3>
driftfile /etc/ntp.drift
logfile /var/log/ntp.log

you also can always run # ntpq -p to see what's running.

jak · 2004-07-21 03:56:19

slackhack wrote:

uncomment the restrict 127.0.0.1 line

Notice what http://www.eecis.udel.edu/~mills/ntp/ht … t.html#cmd says about the "restrict" command:

In the current implementation ... an entry with no flags indicates that free access to the server is to be given

Using your own local clock as a time source is a bad idea. If you can't synch to any remote ntp server, you need to figure out why, and fix the problem. Letting ntp run against your own local clock gives you a false sense of having a "backup" source. Your local clock is the one that needs correcting; it's useless as a source of accuracy.

slackhack · 2004-07-21 05:47:58

it might be best to just add a server or two to the ntp.conf file and nothing else until it's working right, and then add your restricts and driftfile, etc. later. not sure about the localhost restrict, i thought that might be needed to allow the localhost to access ntpd, but i guess not. i'm going to take mine out and see how that works, thanks.

~~~~~~~~~~~~~~~~~~~~~
when i take out restrict 127.0.0.1, ntpd fails to function:

[5] root:/home/sero # ntpq -p
localhost: timed out, nothing received
***Request timed out

i that case, it looks like it is *trying* to access the localhost.

so i uncommented it again and set my clock back 10 minutes before going to bed last night, and this morning i am synched with my time servers:

21 Jul 01:49:05 ntpd[11506]: synchronized to 128.59.59.177, stratum=2
21 Jul 01:59:28 ntpd[11506]: time reset +622.955389 s
21 Jul 01:59:28 ntpd[11506]: kernel time sync disabled 0041
21 Jul 02:04:47 ntpd[11506]: synchronized to 128.59.59.177, stratum=2
21 Jul 02:12:15 ntpd[11506]: kernel time sync enabled 0001

[1] root:/home/sero # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*filbert.cc.colu 128.59.39.48     2 u  446 1024  377   14.992   -2.246   3.625
+cudns.cit.corne 192.5.41.40      2 u  457 1024  377   21.530   21.619  16.168

i'm not sure about it "falling back" to synch with local time. i think it's required to access the time servers. ntpd doesn't work for me without it, at least. i think having the first restrict line (restrict default noquery nomodify) must tell it not to use the localhost.

jak · 2004-07-22 01:34:10

slackhack wrote:

i think having the first restrict line (restrict default noquery nomodify) must tell it not to use the localhost.

As the web site says, "noquery" will "Deny ntpq and ntpdc queries. Time service is not affected." Thus ntp would still try to get time from the local clock. That's a bad thing.

See http://www.eecis.udel.edu/~mills/ntp/html/accopt.html.

"Default restriction list entries with the flags ignore, interface, ntpport, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time."

So by default, a config file with no restrict lines whatsoever, prevents ntpd from trying to synch to the local clock. That's a good thing.

slackhack wrote:

when i take out restrict 127.0.0.1, ntpd fails to function

No, ntpd does not fail. The only thing that fails is your query (via ntpq) to your local running ntpd. The typical user who only needs the correct time, and does not care to twiddle the knobs, shoud omit any and all mention of 127.0.0.1 from the config file, and just be happy.

Knob twiddlers who insist on using ntp queries to examine their local running ntpd, should use the correct specification:

restrict 127.0.0.1 noserve nomodify

But DON'T USE

restrict 127.0.0.1

because an address with no flags, will alllow all access (from that address), which means ntpd will try to use the local clock as a time source, which is a bad thing.

It helps to read the web site docs, carefully. Perhaps more than once.

To reiterate, here's a good config file for the typical user. Just modify the server lines to select stratum 2 servers (not stratum 1 servers!) close to you, netwise.

restrict default nomodify noquery
server ntp-2.vt.edu
server louie.udel.edu
server ntp-1.mcs.anl.gov
server clock.psu.edu
driftfile /etc/ntp.drift
logfile /var/log/ntp.log

slackhack · 2004-07-22 02:42:38

then it's a major case of poor design, because "restrict" in this case is completely counterintuitive. "restrict 127.0.0.1" should mean the localhost is restricted (as the command states) not allowed.

also, the documentation is so poor no one can really read it comfortably (which unfortunately in linux is the rule rather than the exception). in this case, i'm put off from the very first sentence:

"The ntpd daemon implements a general purpose address/mask based restriction list."

w-t-h does that mean? i have a master's degree in technical writing, and i still don't understand it. like that tells me anything about how it works. and the ntp documentation has been about the worst i have ever seen. it's no wonder no one wants to read any documentation but just ask the gurus. thanks to people like you to explain it to us, we can get by, but man, it is really crappy wading through all that junk just to figure out a simple config file.

jak · 2004-07-22 03:32:03

slackhack wrote:

"restrict" in this case is completely counterintuitive ... i'm put off from the very first sentence: "The ntpd daemon implements a general purpose address/mask based restriction list."

If you think of firewall rules instead of ntp config rules, the "restriction list" might drop all TCP/IP packets with any source address matched by the restriction list.

The ntp "restrict" command matches source addresses the same way, but just remember that a naked address like 127.0.0.1 without any flags, means that everything from that address is ALLOWED, not denied. You need at least one flag to convert the rule from its naked state of ALLOW into a more seemly state of DENY. Perhaps that is couterintuitive.

it is really crappy wading through all that junk just to figure out a simple config file

That's why I advised earlier: follow instructions, with no deviation or improvisation, and be happy.

schome1 · 2004-07-23 01:42:33

I have found just the opposite. Well, let me clarify...

After one week of trying to figure out what all of the mumbo jumbo is with the restrict statements I have finally figured it out. According to jak, you should remove the line

restrict 127.0.0.1

from the ntp.conf file. However, let me clarify to say that that will only work if you use the notrust statement in the first restrict line. More specifically...

The very first line of your ntp.conf file should contain a line such as the following

restrict default noquery notrust nomodify

This essentially restricts everyone from modifying anything. Following this, you need to let ntp.conf know what you want to let through into your ntp server. Here is where you would specify your localhost, and any other ip addresses you would like to synchronize on your ntp server. For example:

restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 nomodify

tells ntpd that the localhost and all ip addresses from the 192.168.0.0 range will be allowed to synchronize on this server, but will not be allowed to modify anything. All other IP addresses in the world will still obey the default restrictions (the first line in the ntp.conf).

Now, is where the stratum 2 servers that our server will synchronize to come into play. The lines in ntp.conf will be used to tell ntpd what servers we would like to use for synchronizing (these are just examples, use ntp servers that are closest to your location).

server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

If we left it alone right now, we would never connect to a server because the response from one of the three servers listed above would never be allowed back into our server due to the fact that our default restrict statement would be in use since we did not add the servers to our lesser restrictions (like we did with 127.0.0.1 and the subnet of 192.168.0.0).

To correct this, enter the following lines in ntp.conf:

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

This will allow the response from the above servers into our system so our local clock can be synchronized. The noquery restriction will not allow any of the above three servers to query for information from our server. The nomodify restriction will not allow the three servers to modify anything (synchronization will still take place).

The only thing left to do is add the drift file (which keeps track of yours clocks time deviation). and the log file location:

driftfile /etc/ntp.drift
logfile /var/log/ntp.log

The complete file will look like this:

# default restrictions
restrict default noquery notrust nomodify

# override the default restrictions here
restrict 127.0.0.1
restrict 10.1.1.0 mask 255.255.255.0 nomodify

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

Take note that this is for a client and a server ntp.conf configuration. If you just want to synchronize with a stratum server and are not concerned with other PCs synchronizing with your ntp server, then you can do something like the following (note that only 127.0.0.1 is allowed to be synchronized):

# default restrictions
restrict default noquery notrust nomodify

# override the default restrictions here
restrict 127.0.0.1

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

... or if you don't care about restrictions at all, something like this (note there are no restrictions, thus no need to reduce restrictions for 127.0.0.1 to allow your local clock to synchronize):

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

I hope this helps everyone.

All of my research was done at the following sites:
http://www.ntp.org/
http://twiki.ntp.org/bin/view/Main/WebHome
http://www.eecis.udel.edu/~mills/ntp/html/index.html

slackhack · 2004-07-23 02:17:37

excellent synopsis and explanation, thanks. maybe it should be added to the wiki.

jak · 2004-07-23 02:58:43

schome1 wrote:

According to jak, you should remove the line
restrict 127.0.0.1
from the ntp.conf file. However, let me clarify to say that that will only work if you use the notrust statement in the first restrict line

False.

You're complicating things unnecessarily. Your default line says don't trust any server as a source of time, and then for each server you list, you have to specifically trust it as a source of time. That's redundant. Just omit notrust from the default line, and you won't have to identify each server as trustworthy.

Here is where you would specify your localhost, and any other ip addresses you would like to synchronize on your ntp server. For example:
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 nomodify

Sigh. Don't allow localhost to synchronize to itself. It's already synchronized to the remote servers you said were trustworthy. That's why:

According to jak, you should remove the line
restrict 127.0.0.1
from the ntp.conf file

Exactly.

slackhack · 2004-07-23 03:45:39

jak wrote:

According to jak, you should remove the line
restrict 127.0.0.1
from the ntp.conf file
Exactly.

or add the noserve nomodify flags.

schome1 · 2004-07-23 03:51:45

That's why I included the three example config files (One server script with security, one client script with security, and one client script without security).

The fact is that security starts by making things ultra secure first, then reducing security to allow certain things in. This is the way they recommend utilizing security with Samba. First you restrict everything, then you allow those things you want in.

Yes, it is redundant. But the bottom line is that if you want security, you will have to accept a certain level of redundancy.

I still disagree with you about the localhost line. When I run the following command:

ntpq -p

I see the three servers I'm synchronizing with. My localhost never appears - which tells me that it is not on the list of servers to synchronize with (I am not querying the localhost to synchronize to). With notrust in the default restrict line, you need to add the following line in order for the local clock to synchronize.

restrict 127.0.0.1

My goal of this post was to show and briefly explain how to create an ntp config file that works. I have done that with examples of both secure and insecure config files. Use them as you wish.

jak · 2004-07-23 04:27:07

schome1 wrote:

I still disagree with you about the localhost line. When I run ntpq -p I see the three servers I'm synchronizing with. My localhost never appears - which tells me that it is not on the list of servers to synchronize with

See http://www.eecis.udel.edu/~mills/ntp/html/accopt.html, and notice where it says:

Default restriction list entries with the flags ignore, interface, ntpport, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time

What does that tell you?

With notrust in the default restrict line, you need to add the following line in order for the local clock to synchronize

restrict 127.0.0.1

When you say "local clock to synchronize" what are you actually trying to say? Do you understand the interaction between ntp and the local clock?

:?:

Arch Linux

#1 2004-07-17 03:23:21

ntp - there's gotta be a correct way

#2 2004-07-17 12:25:24

Re: ntp - there's gotta be a correct way

#3 2004-07-17 14:42:06

Re: ntp - there's gotta be a correct way

#4 2004-07-17 19:28:47

Re: ntp - there's gotta be a correct way

#5 2004-07-17 19:53:24

Re: ntp - there's gotta be a correct way

#6 2004-07-18 09:21:15

Re: ntp - there's gotta be a correct way

#7 2004-07-18 12:17:44

Re: ntp - there's gotta be a correct way

#8 2004-07-18 12:58:07

Re: ntp - there's gotta be a correct way

#9 2004-07-18 19:23:33

Re: ntp - there's gotta be a correct way

#10 2004-07-18 20:52:06

Re: ntp - there's gotta be a correct way

#11 2004-07-19 09:12:09

Re: ntp - there's gotta be a correct way

#12 2004-07-20 18:19:29

Re: ntp - there's gotta be a correct way

#13 2004-07-21 00:03:37

Re: ntp - there's gotta be a correct way

#14 2004-07-21 01:45:41

Re: ntp - there's gotta be a correct way

#15 2004-07-21 03:56:19

Re: ntp - there's gotta be a correct way

#16 2004-07-21 05:47:58

Re: ntp - there's gotta be a correct way

#17 2004-07-22 01:34:10

Re: ntp - there's gotta be a correct way

#18 2004-07-22 02:42:38

Re: ntp - there's gotta be a correct way

#19 2004-07-22 03:32:03

Re: ntp - there's gotta be a correct way

#20 2004-07-23 01:42:33

Re: ntp - there's gotta be a correct way

#21 2004-07-23 02:17:37

Re: ntp - there's gotta be a correct way

#22 2004-07-23 02:58:43

Re: ntp - there's gotta be a correct way

#23 2004-07-23 03:45:39

Re: ntp - there's gotta be a correct way

#24 2004-07-23 03:51:45

Re: ntp - there's gotta be a correct way

#25 2004-07-23 04:27:07

Re: ntp - there's gotta be a correct way

Board footer