ntp - there's gotta be a correct way

schome1 · 2004-07-23 05:39:40

jak, I want to believe you, but you have to tell me why multiple examples from the NTP websites use the restrict 127.0.0.1 line. Also, when I took that line out as a test, I waited until it said I synchronized with the server, then ran the test below. I have never received that error before.

# ntpq -p
localhost.localdomain: timed out, nothing received
***Request timed out

I believe that I'm connecting to the ntp servers, but my clock is not synchronizing. It is speculation, but I know for a fact that I did not get the above error when I used restrict 127.0.0.1.

I'm trying to work with you here to sort this debate out. Please tell me how I could have synchronized when my query request timed out? That tells me that my localhost was under the influence of the default restrictions and therefore, was unable to synchronize.

:?: :?: :?:

schome1 · 2004-07-23 11:15:47

Okay, jak, I think I understand now what you've been saying. After getting some sleep and re-reading the following, I've come to understand the following (correct me if I'm wrong)...

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. A default entry is also always present, though if it is otherwise unconfigured; no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).

That statement says that a statement of the following exists by default in ntp.conf (meaning you don't have to enter it to have it in place - sort of a virtual entry - unless overridden):

restrict 127.0.0.1 ignore interface ntpport

It also says that a default restriction statement (first uncommented line in my examples) exists (again, a virtual entry) but has no restriction flags associated with it - looks like the following:

restrict default

and if left unconfigured (without flags - which is what my first uncommented line in the examples does, configures it) will allow everything into your NTP server. So it is very unsecure.

Makes sense now. As for my previous post where I couldn't use the ntpq -p command. The reason is that without specifically entering the restrict line for my localhost, I never overwrote the default restrict line for my localhost. Since the default restrict line contains the flag ignore...

ignore
    Deny packets of all kinds, including ntpq and ntpdc queries.

My query will not pass through to ntpd. However, it will still synchronize. So in this case, if I wanted to be able to query my NTP server (using ntpq -p) to see what I'm synchronizing with, I would have to insert my own restrict 127.0.0.1 statement without the ignore flag. At this point, I don't feel the need to do that, so I will leave it out. So we were both correct (you were correct because you can leave out the restrict on the localhost and I was correct because in order to query the NTP server, you must insert a restrict on the localhost without the ignore flag).

Let me know if that is correct in your way of reading it. Also thanks for your persistance. I think we now have a good foundation for anyone who wants to use NTP. I will put this information into a wiki if I can ever figure out how to log into one in order to submit it.

slackhack · 2004-07-23 11:34:38

what i don't get about the explanation jak is quoting is that my default localhost line is never written with any flags. it's always just "restrict 127.0.0.1." as i said earlier, i always just thought the first line in the config file contained global options that also applied to localhost.

when they say written to the table ("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"), do they mean it's written to the config file by default, or inserted somewhere else by default? since i've never had that in my config file, i always thought that the server is not querying itself by default either because of the nomodify noquery, etc. flags in the first line or because the flags are inserted somewhere else (an iptable-like thing somewhere, i assumed)?

MEfreak · 2004-07-23 12:11:06

Here's what I don't understand:

Why would the ntp daemon try to synch with a localhost, even if it's included in the cofig file as an unrestricted entry? To my knowledge, the ntp daemon tries to synch only with "server" entries. This belief is supported by several statements in the documentation/online resources indicating a

server <localhost>

will cause the daemon to use the localhost as a last resort fallback server for time synch.

So if the config is in the form of:

restrict default
#lines removed for space
restrict 127.0.0.1

why would it call up an access restriction line as a time server entry?

It was (is?) my belief that the config file would have to look like the following entry if the daemon was to use the localhost as a last resort time synch server:

restrict default
#lines removed for space
server 127.0.0.1

In summary, I thought the following basic rules applied:
restriction <host> = Determine what control and access a host has to the ntp daemon (and local clock). Does not tell ntp to use the host as a time synch server.
server <host> = Tells ntp which host(s) to use for time synch. Must be trusted in the corresponding restriction entry (or defaults).

@slackhack,

If you left your ntp.conf file completely empty, the following default entries would be applied by the daemon:

restrict default
restrict <localhost 1> ignore
restrict <localhost 2> ignore
#lines removed for space
restrict <localhost N> ignore
#other defaults not listed

If you start entering default restrictions and/or localhost restrictions, then the applicable daemon-applied default configuration options will be overwritten.

schome1 · 2004-07-23 14:58:05

I do agree with you, regarding the restrict 127.0.0.1. I don't think that statement tells ntpd to synchronize with itself. The only thing it does to my knowledge is remove the default restrictions placed upon it by either the default restrict line. In other words, you will synchronize with or without the restrict 127.0.0.1 line. But if you add it to your config file, you will be able to do some things that are not allowed if you don't add it to your config file.

I agree with you though. The servers that you will synchronize with are those prefixed with 'server'.

MEfreak · 2004-07-23 16:48:43

Although, now I'm wondering if when "nomodify" is removed from the localhost's restrictions, perhaps that gives the localhost the ability to force the local ntp server to synchronize with the local clock?

More succintly, the synch with the local clock could be forced by the local ntp client, not requested by the local ntp server?

jak · 2004-07-24 01:48:18

schome1 wrote:

My query will not pass through to ntpd. However, it will still synchronize. So in this case, if I wanted to be able to query my NTP server (using ntpq -p) to see what I'm synchronizing with, I would have to insert my own restrict 127.0.0.1 statement without the ignore flag

Yes, you may notice I covered that earlier in the thread:

restrict 127.0.0.1 noserve nomodify

Let me know if that is correct in your way of reading it

Correct.

regarding the restrict 127.0.0.1. I don't think that statement tells ntpd to synchronize with itself

True.

But the problem is, a naked "restrict 127.0.0.1" without any flags, ALLOWS ntp to synchronize with the local clock. Whether it actually tries to do that, or not, only the C programmer knows for sure. The ntp web site seems to suggest that it will try to, even though you don't tell it to, anywhere in the config file. For mere users like ourselves, who don't have time to read the C source code, the safest course is to construct a config file which eliminates any such possibility.

I think we now have a good foundation for anyone who wants to use NTP

Adding the line to allow ntp queries from localhost, a good minimal config file would be:

restrict default nomodify noquery
restrict 127.0.0.1 noserve nomodify
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

Just change the servers and choose some close to you, netwise; be sure to choose stratum 2 servers, never stratum 1 servers!

jak · 2004-07-24 02:07:53

slackhack wrote:

when they say written to the table ("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"), do they mean it's written to the config file by default, or inserted somewhere else by default?

No, not the config file.

The C programmer who wrote the code for the ntp daemon, constructs an internal table to hold the information. The first information he puts in the internal table, are his ideas of proper "defaults", as mentioned above, before ever looking at your config file. Then he reads your config file, merging your ideas with his own, in that internal table, which the ntp daemon uses while running, to make its decisions.

phunni · 2004-07-24 10:52:45

Bobonov wrote:

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

OK, so I guess (since I want to do this on a desktop that is often rebooted) that I want to run ntpdate on startup rather than running ntpd as a daemon

So what's the best way to go about this in arch?

jak · 2004-07-24 11:31:28

schome1 wrote:

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

When the log shows "synchronized to LOCAL(0)" as above, you are synchronizing to your local clock. You did not say what your config file looked like then, but the point is, ntp may try to synchronize to the local clock, and that's what the typical user should avoid. Experts, of course, may do as they please.

jak · 2004-07-24 11:47:22

phunni wrote:

I guess (since I want to do this on a desktop that is often rebooted) that I want to run ntpdate on startup rather than running ntpd as a daemon

Notice what http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html says about ntpdate:

After a suitable period of mourning, the ntpdate program is to be retired from this distribution

Like ntpdate, the ntpd daemon will step the time when it starts up, to make any large corrections needed. Thus ntpdate is no longer needed, and as the web site says, is considered obsolete.

Arch Linux

#26 2004-07-23 05:39:40

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

#27 2004-07-23 11:15:47

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

#28 2004-07-23 11:34:38

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

#29 2004-07-23 12:11:06

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

#30 2004-07-23 14:58:05

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

#31 2004-07-23 16:48:43

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

#32 2004-07-24 01:48:18

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

#33 2004-07-24 02:07:53

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

#34 2004-07-24 10:52:45

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

#35 2004-07-24 11:31:28

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

#36 2004-07-24 11:47:22

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

Board footer