NTP

On 2007-06-02, Bruno Campanini wrote:
> "Per Hedeland" wrote in message
>
>> In article "Bruno
>> Campanini" writes:
>>>
>>>Ok then, ntpd creates its driftfile by itself when needed!
>>>Is it only necessary to touch ntpd.pid file?
>>
>> That's not necessary (or even a good idea) either.
>>
>>>ntpq -p check produces the right output, but the clients
>>>are still out of sync.
>>
>> Are you sure you can determine that it is the "right" output? Maybe just
>> post it.
>
> My actual ntpq -p output:
>
> remote refid st t when poll
> reach delay offset jitter
>============================================================
> *merkur2.baulogi 192.53.103.104 2 u 40 64 377 136.536
> 27.766 0.551
> time.nist.gov .ACTS. 1 u 488 256 2
> 243.551 42.770 0.008
> time.windows.com .INIT. 16 u 102m 1024 0 0.000
> 0.000 4000.00

It's difficult to interpret the output since it's so mangled however if
your time is too skewed then ntpd will /not/ adjust it. Manually adjust
your time and then see how ntpd goes.

--
Russell Wood <http://www.dynode.net/~rjw/>
 >> Stay informed about: NTP 

"Bruno Campanini" wrote in message


> My actual ntpq -p output:
>
> remote refid st t when poll
> reach delay offset jitter
> ============================================================
> *merkur2.baulogi 192.53.103.104 2 u 40 64 377 136.536
> 27.766 0.551
> time.nist.gov .ACTS. 1 u 488 256 2
> 243.551 42.770 0.008
> time.windows.com .INIT. 16 u 102m 1024 0 0.000
> 0.000 4000.00
>
> Waiting for your response.
> Bruno

Sorry, input was ok but output unreadable.

st t when poll reach delay offset jitter
============================================================
*merkur2.baulogi
192.53.103.104
2 u 40 64 377 136.536 27.766 0.551

time.nist.gov
..ACTS.
1 u 488 256 2 243.551 42.770 0.008

time.windows.com
..INIT.
16 u 102m 1024 0 0.000 0.000 4000.00

Bruno
 >> Stay informed about: NTP 

In article "Bruno
Campanini" writes:
>
>Sorry, input was ok but output unreadable.

Hm, yes, and I'm not sure the second attempt was an improvement - maybe
you should try a newsreader that doesn't garble your posts... Anyway
properly formatted it looks like this:

remote refid st t when poll reach delay offset jitter
==============================================================================
*merkur2.baulogi 192.53.103.104 2 u 40 64 377 136.536 27.766 0.551
time.nist.gov .ACTS. 1 u 488 256 2 243.551 42.770 0.008
time.windows.com .INIT. 16 u 102m 1024 0 0.000 0.000 4000.00

This is certainly not good, but it does indicate that your server has
found something to sync to at least. I'd suggest that you drop those
last two servers and add two or three more from the pool instead -
choose some that are reasonably close network-wise (there are
geographical "subdomains" that increase the probability of that).

But this *should* be enough for clients to sync to - so the problem is
likely at the Windows end. My knowledge of Windows and NTP is basically
that it (modern versions at least) has something semi-broken called
w32time - it's fully-broken if you try to use it as a server, but for
client functionality it should at least be in the area of periodic
ntpdate. I assume that you have to configure it somehow, but I've really
no idea how, let alone how you go about debugging it.

Of course there is also ntpd for windows available, see
http://support.ntp.org/bin/view/Main/ExternalTimeRelatedLinks

--Per Hedeland
per DeleteThis @hedeland.org
 >> Stay informed about: NTP 

"Per Hedeland" wrote in message


> This is certainly not good, but it does indicate that your server has
> found something to sync to at least. I'd suggest that you drop those
> last two servers and add two or three more from the pool instead -

Any names?

> choose some that are reasonably close network-wise (there are
> geographical "subdomains" that increase the probability of that).
>
> But this *should* be enough for clients to sync to - so the problem is
> likely at the Windows end. My knowledge of Windows and NTP is basically
> that it (modern versions at least) has something semi-broken called
> w32time - it's fully-broken if you try to use it as a server, but for
> client functionality it should at least be in the area of periodic
> ntpdate. I assume that you have to configure it somehow, but I've really
> no idea how, let alone how you go about debugging it.

Winserver 2003 works correctly with its own time server
anx XP / Vista clients work ok with Winserver 2003's time server.
Problems arise with BSD / Windows: two different families...
Well, for me it is only an academic question.

I thank you and all other people who gave me suggestions
in this thread. Now my ntpd is working on the server and one
of these days I'll install another BSD to act as client, in order
to verify it's working also as such.

Bruno
 >> Stay informed about: NTP 

In article "Bruno
Campanini" writes:
>"Per Hedeland" wrote in message
>
>
>> This is certainly not good, but it does indicate that your server has
>> found something to sync to at least. I'd suggest that you drop those
>> last two servers and add two or three more from the pool instead -
>
>Any names?

Uh, you don't use names for the pool servers, that's the whole point...
As your ntp.conf included "server pool.ntp.org", I assumed that you were
familiar with the concept (btw you should drop the "prefer" from that
line and let ntpd decide on its own what to prefer). See
http://www.pool.ntp.org/ and maybe specifically
http://www.pool.ntp.org/zone/it .

>Winserver 2003 works correctly with its own time server
>anx XP / Vista clients work ok with Winserver 2003's time server.
>Problems arise with BSD / Windows: two different families...

Again AFAIK, Windows currently uses (S)NTP (though of course they don't
*quite* follow the standard), so it should certainly be possible to make
them work together, just that the quality of the result may not be
ideal.

The brokenness in server mode on Windows is primarily that it claims to
be synced to a perfect time reference such as GPS even when it's just
using the free-running local clock of the host - which of course won't
make clients unhappy, just make them believe in a lie.

If your Windows clients can't sync at all to your FreeBSD/Unix server,
it cannot be due to BSD vs Windows incompatibility. But as I said, some
configuration is likely necessary on the Windows side for this, while
they may find a Windows server automatically based on some proprietary
mechanism. Another possibility is that you have some firewalling on the
BSD box that is blocking the requests from the Windows clients. Having
'restrict' lines in ntp.conf can have a similar effect of course, but
the one you quoted earlier in the thread should be OK, though pretty
pointless on its own.

--Per Hedeland
per.DeleteThis@hedeland.org
 >> Stay informed about: NTP 

"Per Hedeland" wrote in message


> Uh, you don't use names for the pool servers, that's the whole point...
> As your ntp.conf included "server pool.ntp.org", I assumed that you were
> familiar with the concept (btw you should drop the "prefer" from that
> line and let ntpd decide on its own what to prefer). See
> http://www.pool.ntp.org/ and maybe specifically
> http://www.pool.ntp.org/zone/it .

Ok Per. I just followed a suggestion somebody gave me on this thread.
>
>>Winserver 2003 works correctly with its own time server
>>anx XP / Vista clients work ok with Winserver 2003's time server.
>>Problems arise with BSD / Windows: two different families...
>
> Again AFAIK, Windows currently uses (S)NTP (though of course they don't
> *quite* follow the standard), so it should certainly be possible to make
> them work together, just that the quality of the result may not be
> ideal.
[...]

When Windows clients are in a Domain they are not allowed to
sync to something else but to the Windows Domain Controller.
When they are not a tab appears with a combo box to select
the server for syncing the clock.
The problem is that Windows doesn't recognise BSD as a
Domain Controller and you can stay under a BSD server
as a member of a Workgroup, not as a member of a Domain.
As a conseguence you can access the tab and the combo box for
selecting/writing your time server.
If you write there the BSD server as time server you are
ok with Windows.
But then Windows client syncs at its own rate and not
when ntpd sends sync signals.

Bruno
 >> Stay informed about: NTP 

On Sun, 3 Jun 2007 12:52:03 +0200, "Bruno Campanini"
wrote:

>"Per Hedeland" wrote in message
>
>
>> Uh, you don't use names for the pool servers, that's the whole point...
>> As your ntp.conf included "server pool.ntp.org", I assumed that you were
>> familiar with the concept (btw you should drop the "prefer" from that
>> line and let ntpd decide on its own what to prefer). See
>> http://www.pool.ntp.org/ and maybe specifically
>> http://www.pool.ntp.org/zone/it .
>
>Ok Per. I just followed a suggestion somebody gave me on this thread.
>>
>>>Winserver 2003 works correctly with its own time server
>>>anx XP / Vista clients work ok with Winserver 2003's time server.
>>>Problems arise with BSD / Windows: two different families...
>>
>> Again AFAIK, Windows currently uses (S)NTP (though of course they don't
>> *quite* follow the standard), so it should certainly be possible to make
>> them work together, just that the quality of the result may not be
>> ideal.
>[...]
>
>When Windows clients are in a Domain they are not allowed to
>sync to something else but to the Windows Domain Controller.
>When they are not a tab appears with a combo box to select
>the server for syncing the clock.
>The problem is that Windows doesn't recognise BSD as a
>Domain Controller and you can stay under a BSD server
>as a member of a Workgroup, not as a member of a Domain.
>As a conseguence you can access the tab and the combo box for
>selecting/writing your time server.
>If you write there the BSD server as time server you are
>ok with Windows.
>But then Windows client syncs at its own rate and not
>when ntpd sends sync signals.
>
>Bruno

If your domain is a Samba 3 domain (or just possibly a Windows NT4
domain), the set time tab is presented and you can successfully sync
an XP client to a BSD ntpd server (or at least I can). I haven't tried
Vista.

If you have an AD domain with 2003 Server DCs (I've never used Win2000
server) your clients will sync to a DC. You can however, sync your PDC
emulator to a BSD ntp server (but I forget how). Then all DCs can sync
to the PDC emulator and clients to a local DC. There is a white paper
on Microsoft's support site if you need to do that.

Both these methods work for me, Samba at home and Windows 2003 at
work.

Steve.
 >> Stay informed about: NTP 

In article , Per Hedeland wrote:
>In article Russell Wood
> writes:
>>On 2007-06-02, Per Hedeland wrote:
>>> In article "Bruno
>>> Campanini" writes:
>>>>"Russell Wood" wrote in message
>>>>news:slrnf628lu.20tu.bitbucket@union.lab.dynode.net...
>>>>> On 2007-06-02, Warren Block wrote:
>>>>>> Russell Wood wrote:
>>>>>>> On 2007-06-02, Russell Wood wrote:
>>>>>>>>
>>>>>>>> You may need to touch the drift file (#touch /etc/ntp.drft).
>>>>>>>
>>>>>>> Sorry, that's `drift' (#touch /etc/ntp.drift).
>>>>>>
>>>>>> FreeBSD default is /var/db/ntpd.drift (from /etc/defaults/rc.conf).
>>>>>
>>>>> It's being set as a parameter to the ntpd command:
>>>>>
>>>>> ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift"
>>>>>
>>>>> In your /etc/ntp.conf file just put:
>>>>>
>>>>> driftfile /etc/ntp.drift
>>>>>
>>>>> Then I'm sure it'll work.
>>>
>>> Why do you think it will work better if you put the drift file in the
>>> wrong place?
>>
>>The default location is actually /etc (man ntpd):

>It's ntpd's default, but it's wrong for FreeBSD (and most other modern
>Unices).

Well when I checked 'man ntpd' on a 4.11 machine it just says
that -f driftfile "Specify the name and path of the drift file"

In my 6.2 machines it is changed and there is the line
that says "... default /etc/ntp.drift"

However the /etc/rc.d/ntpd script does show that the default
there is /var/db/ntp.drift.

I'd guess from that the docs in 6.2 [or perhaps earlier] need to be
updated, or the /etc/rc.d/ntpd script should be changed. Is this
something that needs to be submitted in a PR?

>>I have seen ntpd issues in the past when a drift file has not been
>>present. Once it's been touched things magically being to work. Just
>>/my/ experience.

>And often our experience is wrong, because we did something (or
>more frequently multiple things) and something else happened, and
>we incorrectly concluded that one was the cause of the other. But
>of course bugs happen, and I obviously can't say that no version
>of (x)ntpd ever had such a bug.

Such is the life of human beings

Bill
--
Bill Vermillion - bv @ wjv . com
 >> Stay informed about: NTP 

In article "Bruno
Campanini" writes:
>
>>
>>>Winserver 2003 works correctly with its own time server
>>>anx XP / Vista clients work ok with Winserver 2003's time server.
>>>Problems arise with BSD / Windows: two different families...

>When Windows clients are in a Domain they are not allowed to
>sync to something else but to the Windows Domain Controller.
>When they are not a tab appears with a combo box to select
>the server for syncing the clock.
>The problem is that Windows doesn't recognise BSD as a
>Domain Controller and you can stay under a BSD server
>as a member of a Workgroup, not as a member of a Domain.
>As a conseguence you can access the tab and the combo box for
>selecting/writing your time server.
>If you write there the BSD server as time server you are
>ok with Windows.

OK, so it doesn't seem to be the case that any NTP-specific "problems
arise".

>But then Windows client syncs at its own rate and not
>when ntpd sends sync signals.

This is standard with other NTP clients too - ntpd doesn't "send sync
signals" unless you specifically configure it to do so (e.g. broadcast
mode). Standard ntpd with standard config will query its server(s) at
intervals that dynamically range from 64 to 1024 seconds.

--Per Hedeland
per RemoveThis @hedeland.org
 >> Stay informed about: NTP 

In article bv.TakeThisOut@wjv.com (Bill Vermillion) writes:
>In article , Per Hedeland wrote:
>>In article Russell Wood
>> writes:
>>>
>>>The default location is actually /etc (man ntpd):
>
>>It's ntpd's default, but it's wrong for FreeBSD (and most other modern
>>Unices).
>
>Well when I checked 'man ntpd' on a 4.11 machine it just says
>that -f driftfile "Specify the name and path of the drift file"
>
>In my 6.2 machines it is changed and there is the line
>that says "... default /etc/ntp.drift"
>
>However the /etc/rc.d/ntpd script does show that the default
>there is /var/db/ntp.drift.

Well, generally speaking I'd expect the man page for a daemon to
describe only the defaults that are compiled into the binary, and
consider what rc scripts might do to be a separate issue - but that's
just me. The NTP man pages are a special problem since the project
doesn't distribute man pages, but some kind soul translates the html
docs into man pages for FreeBSD. The change above probably just reflects
a change in the html docs, at least the current version (at
http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html) does say that
/etc/ntp.drift is the default for -f. And btw, the FreeBSD 4.11 man page
does list it as default under FILES.

Funny thing is though that when I actually checked the sources, (a
variety of versions), there doesn't seem to *be* a compiled-in default
for the drift file - if you don't specify one via -f or 'driftfile' in
the config, ntpd simply won't use one. Which certainly makes you wonder
why someone saw fit to add the mention of the non-existing default to
the html page...

>I'd guess from that the docs in 6.2 [or perhaps earlier] need to be
>updated, or the /etc/rc.d/ntpd script should be changed. Is this
>something that needs to be submitted in a PR?

Per above, I wouldn't bother - it's difficult to say how the man page
should be fixed if at all, and /var/db is definitely the right place for
the file on FreeBSD. What the script does is just for when you run ntpd
chrooted though, and it doesn't actually *make* the file be
/var/db/ntp.drift - that comes from the default flags in
/etc/defaults/rc.conf.

--Per Hedeland
per.TakeThisOut@hedeland.org
 >> Stay informed about: NTP 

Per Hedeland wrote:
>
> Funny thing is though that when I actually checked the sources, (a
> variety of versions), there doesn't seem to *be* a compiled-in default
> for the drift file - if you don't specify one via -f or 'driftfile' in
> the config, ntpd simply won't use one. Which certainly makes you wonder
> why someone saw fit to add the mention of the non-existing default to
> the html page...

I'm glad you said this, because I spent a while trying to find it, too.
Just figured it was some magical make-fu.

--
Warren Block * Rapid City, South Dakota * USA
 >> Stay informed about: NTP 

In article Warren Block
writes:
>Per Hedeland wrote:
>>
>> Funny thing is though that when I actually checked the sources, (a
>> variety of versions), there doesn't seem to *be* a compiled-in default
>> for the drift file - if you don't specify one via -f or 'driftfile' in
>> the config, ntpd simply won't use one. Which certainly makes you wonder
>> why someone saw fit to add the mention of the non-existing default to
>> the html page...
>
>I'm glad you said this, because I spent a while trying to find it, too.
>Just figured it was some magical make-fu.

It should still show up with 'strings' on the binary in that case, but
it doesn't. Anyway, to make 110% sure, I ran it (the FreeBSD 5.3
version, called 4.2.0-a - seems to still be the same in 6.2) overnight
without either -f or 'driftfile' - worked fine, but touched neither
/etc/ntp.drift nor /var/db/ntp.drift (when ntpd is running normally, the
drift file is updated every hour).

--Per Hedeland
per DeleteThis @hedeland.org
 >> Stay informed about: NTP 

>>>>> "Per" == Per Hedeland writes:

Per> Again AFAIK, Windows currently uses (S)NTP (though of course
Per> they don't *quite* follow the standard), so it should
Per> certainly be possible to make them work together, just that
Per> the quality of the result may not be ideal.

Windows Server 2003 and Windows XP both support NTP, though there are
some questions as to the quality of the implementation. Computers
running Windows 2000 only support SNTP. I configured all of my
FreeBSD servers to synchronize their clocks via NTP with my domain
controller (Windows Small Business Server 2003), which in turn is
configured to synchronize with 0-2.us.pool.ntp.org (see "How to
configure an authoritative time server in Windows Server 2003" at
http://support.microsoft.com/kb/816042). My network is so small that
it isn't an ideal implementation, but it works for me:

xenophon@cinep010bsdmx:~>cat /etc/ntp.conf
server irtnog.org
xenophon@cinep010bsdmx:~>ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*svr1.irtnog.org 66.17.184.119 3 u 233 1024 377 33.364 26.773 0.887
ntpq> assoc
ind assID status conf reach auth condition last_event cnt
===========================================================
1 48212 b614 yes yes none sys.peer reachable 1
ntpq> pstatus 48212
status=b614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=svr1.irtnog.org, srcport=123, dstadr=10.63.128.10, dstport=123,
leap=00, stratum=3, precision=-6, rootdelay=90.591,
rootdispersion=89.935, refid=66.17.184.119, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0,
offset=26.773, delay=33.364, dispersion=30.406, jitter=0.887,
reftime=ca0e9052.d4e73604 Mon, Jun 4 2007 9:21:22.831,
org=ca0e926f.2cf79852 Mon, Jun 4 2007 9:30:23.175,
rec=ca0e926f.2a62473b Mon, Jun 4 2007 9:30:23.165,
xmt=ca0e926f.21d7bb9b Mon, Jun 4 2007 9:30:23.132,
filtdelay= 33.36 1.71 1.74 1.59 1.65 1.61 1.54 1.55,
filtoffset= 26.77 25.89 18.54 23.49 12.77 30.36 41.04 31.94,
filtdisp= 15.63 31.02 46.38 61.77 77.11 92.49 107.83 123.19

(One of these days I'm going to get Zenoss running so I can chart
meaningless data on my home network like bandwidth utilization and
clock accuracy.)

I suspect that Microsoft wasn't aiming for sub-millisecond accuracy in
their NTP implementation, especially since the default settings for
Active Directory's Kerberos 5 implementation allow up to a five-minute
clock skew between an KDC and the Kerberos client. I suppose that if
I really needed it, I could replace W32time with ntpd or openntp
easily enough. A native (pure win32, not cygwin) port of ntpd used to
be available from somewhere.

(I probably need to add some ACLs or something to my stock NTP
configuration, so that attackers can't mess with the clocks on my UNIX
servers.)

Best wishes,
Matthew

--
"Rogues are very keen in their profession, and know already much more
than we can teach them respecting their several kinds of roguery."
- A. C. Hobbs in _Locks and Safes_ (1853)
 >> Stay informed about: NTP