I think I solved this just before hitting "send". :) I'll post it
anyway in the hopes of helping to prevent (or delay) baldness. See the
[SOLUTION] below.

Platform: Slackware Linux 10.0, kernel 2.6.6 (custom but inclusive)
NTP: 4.2.0
ntp.conf:
    server us.pool.ntp.org.
    server us.pool.ntp.org.
    server us.pool.ntp.org.
    driftfile /etc/ntp/drift
    multicastclient
    broadcastdelay  0.008
    restrict default noquery nomodify
    restrict 127.0.0.1
    restrict 192.168.0.0 mask 255.255.0.0  # my LAN and VPN sites
    restrict 10.1.0.0 mask 255.255.0.0     # VPN sites

The problem is the "restrict default" line. I have tried it with
numerous permutations, both more and less restrictive.

It works when I take out the restrict lines. Otherwise, ntpq shows the
servers as unreachable. I have not found a "restrict default" set of
flags which allows the pool servers in.

I wrote a shell script, which I will post in a reply in this thread,
which addresses some of the problems with pool servers and access
controls: it builds a list of IP addresses for "server" lines and
"restrict" lines. Using several "server $IP_ADDR" lines with matching
"restrict $IP_ADDR" lines in ntp.conf *does* work.

Can you suggest other "restrict default" flag combinations? I have
thoroughly RTFM accopt.html. Could we have encountered a subtle ntpd
bug here?

[SOLUTION]
I think it may have been my iptables firewall causing this. I use SNAT:
    $IPT -t nat -A POSTROUTING -o $EXT_IF -j SNAT --to-source $EXT_IP
(EXT_I{F,P}: external interface, IP). When I add this to ntp.conf:
    restrict $EXT_IP
it works. (The firewall machines is also running the external ntpd.)

I don't know exactly why this might be happening, but I guess it's in
the Linux netfilter ip_conntrack module. It's still a mystery in that
the "restrict default" line should not prevent synchronisation with a
server, but who am I to argue with results? :)
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

On Sat, 28 Aug 2004 10:47:40 -0500, I wrote:
> I wrote a shell script, which I will post in a reply in this thread,
> which addresses some of the problems with pool servers and access
> controls: it builds a list of IP addresses for "server" lines and
> "restrict" lines.

As promised. This script is useful for those who would use a
    restrict default ignore
line in their static section.

Upon further discussion with Steve in IRC it appears that I was
incorrect in the belief that the order of lines in ntp.conf has an
effect on the access controls, so this could have been much simpler,
using only a single loop to write interspersed server and restrict
lines, and only one dynamic section in the resulting ntp.conf.

The script, complete with plenty of comments which illustrate the
author's ignorance of NTP:
#v+
#!/bin/sh
# swimming - /dev/rob0 <rob0@gmx.co.uk>, 2004/08/28
#     A simple shell script to build /etc/ntp.conf from pool servers
#     (see http://www.pool.ntp.org/ for information on the pool.)

# The issues: first, the way DNS resolution works, you often get the
#    same server twice. This approach ensures that you get the pool
#    servers in your server list, with no duplicates. If your pool is
#    big enough and you ask for 7 servers, you get 7 servers.
# Second, and more likely to be a problem, is that you cannot use NTP
#    access control commands in your configuration file without blocking
#    access to your selected pool servers. The "restrict" directive in
#    ntp.conf, which in fact *allows* access, must have an IP address.
# My request of the NTP developers is that the "server" or "peer"
#    directive be expanded to also override any access controls such as
#    "restrict default ignore". In the meantime I offer this as a
#    workaround to facilitate the use of pool servers with tight access
#    controls.

# Requirements:
# 1. A POSIX-compatible operating system. MS-Windows people: try Cygwin
#    or figure out how to do it yourself.
# 2. BIND host(1) in your $PATH. I don't care to mess with non-
#    compliant DJBDNS tools to try to get this working. Tested with BIND
#    9.2.3 and a named server running on the same host.
# 3. A bourne-compatible shell at /bin/sh. Tested with GNU bash version
#    2.05b.0(1)-release.
# 4. GNU coreutils or shutils/textutils or equivalent.
# 5. Oh yeah: this whole thing is pointless without NTP. :)

### Variables
#
# POOL: set this to the pool.ntp.org hostname you wish to use. I'm in
#    the USA, so I'm distributing this with us.pool.ntp.org. Substitute
#    your own country code if you have a national pool; otherwise try a
#    continental or regional pool. You could even use the main pool,
#    pool.ntp.org., but that is not recommended if you can fine-tune it.
POOL=us.pool.ntp.org.
# NOW: used for temporary filenames and to date the generated file. You
#    should not need to change this, but if you don't like my way of
#    formatting date strings, have fun.
NOW=`date +%F_%T%z`
# NUMBER: the number of servers against which you wish to synchronise.
#    The pool Web site recommends 3. Good arguments at twiki.ntp.org
#    recommend at least 5. If your chosen $POOL is small enough,  this
#    won't matter. I'll bet it won't hurt anything to set a very high
#    number. Ask the NTP gurus about that. If NUMDER is unset
#    (commented) GNU head(1) defaults to 10.
NUMBER=7
#RFLAGS='\tnomodify noquery'    ### IMPORTANT: MUST HAVE LEADING SPACE
# RFLAGS: flags to the "restrict" lines you will have for each server.
#    Set these only if you have RTFM.
#SFLAGS='\tburst'               ### IMPORTANT: MUST HAVE LEADING SPACE
# SFLAGS: flags to the "server" lines you will have for each server.
#    Likewise, set these only if you have RTFM.

# WKDIR: working directory. We'll use /etc/ntp as the directory in
#    which to construct our file. Recent versions of NTP want this
#    directory to be there anyway. You could change this to any
#    directory you like.
###
### IMPORTANT:
### Any static section you wish to have in your ntp.conf files must be
### in a file "ntp.conf.in" in this directory! Without that, ntpd will
### probably work anyway, but you'll have no access controls. Remember,
### that was why we decided to do this! :)
###
WKDIR=/etc/ntp
#WKDIR=$PWD                     # left here for testing
# If you don't have write/execute permissions to $WKDIR we'll bail out.
if [ ! -w $WKDIR -o ! -x $WKDIR ] ; then
  echo "Check permissions on $WKDIR: aborting."
  exit 65
fi
STATIC=ntp.conf.in
# STATIC: The name of the file containing your static ntp.conf content,
#    such as your access controls. This must be located in $WKDIR and
#    readable by the user who runs this script. (You can run this as a
#    non-root user if you wish.)

# The following generates your list of server IP addresses. Do not
#    change this unless you know what you are doing.
POOL_IP=(`host $POOL | head -$NUMBER | cut -f4 -d\ `)
#
### /Variables

### Action
#
cd $WKDIR                       # change to working directory
# I'm NOT a NTP guru, so I don't know much about this, but in my own
#    testing it seemed that the order of ntp.conf directives is
#    significant. "restrict default ignore" at the end of the file
#    overrides any prior "restrict" lines you put in. So this script
#    does two passes: it prepends the "server" lines to your static
#    content, and then it appends the "restrict" lines.
# This is for the first section, "server" lines:
echo -e "# ntp.conf - dynamic section 1 $NOW\n# $POOL servers:" \
  >> "$NOW"
for IP in ${POOL_IP[@]} ; do
  echo -e "server ${IP}$SFLAGS" >> "$NOW"
done
echo '# /dynamic 1' >> "$NOW"

# Next we add the static content.
if [ -r $STATIC ] ; then
  cat $STATIC >> "$NOW"
else
  echo "File $STATIC does not exist or is not readable by you."
  # If you want this to be an interactive script you could add a step to
  # ask for confirmation before continuing. I didn't do that because I
  # will run mine from crond.
fi

# Now we append the "restrict" lines to open access for each server.
echo -e "# ntp.conf - dynamic section 2 $NOW
# Allowing access for pool servers:\n" >> "$NOW"
for IP in ${POOL_IP[@]} ; do
  echo -e "restrict ${IP}$RFLAGS" >> "$NOW"
done
echo '# /dynamic 2' >> "$NOW"

# That's it, our file is complete. We'll save the last version of it and
#    overwrite ntp.conf.
mv ntp.conf ntp.conf.previous
mv "$NOW" ntp.conf

# If you run this as root we can overwrite /etc/ntp.conf and restart
#    ntpd using the new ntp.conf file. A "restart" argument does this;
#    "replace" merely replaces /etc/ntp.conf without restarting ntpd.
if [ $UID = 0 ] ; then
  function Replace() {
    cd /etc ; rm ntp.conf
    ln $WKDIR/ntp.conf
  }
  select case "$1" in
    "restart" )
      Replace ; killall ntpd ; ntpd
      ;;
    "replace" )
      Replace
     ;;
    * )
      true
      ;;
  esac
fi

# Footnote: yes, we could have used an "includefile" in the middle
#    rather than reading in $STATIC, and we could run ntpd with a -c
#    argument to specify an alternate configuration file ... yes, I can
#    RTFM. But I didn't want to do it that way. :)
#
# Thanks: to the people on freenode IRC #ntp for comments and guidance,
#    and to those who conceived, maintain, and participate in the NTP
#    pool, and of course to all the people who developed the free
#    software on which this runs.
#v-

Here's a sample of what you might have in ntp.conf.in:
#v+

# ntp.conf - static section - 2004/08/26
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

# Don't serve time or stats or trust anyone else by default (more secure)
restrict default noquery nomodify nopeer kod notrap
# Trust ourselves.  :-)
restrict 127.0.0.1

### local section 2: allow local and VPN clients
restrict 192.168.0.0 mask 255.255.0.0
restrict 10.1.0.0 mask 255.255.0.0
### /local

#v-

Another problem addressed by this script is that pool servers might
quit or change IP. I thought I might run this thing weekly or monthly
from crond. Perhaps it also helps distribute the load among more pool
servers?

A possible use for this, with minor modification, is for a pool server
operator to have an entirely automatic configuration. The modification
would be to check the list of IP's ($POOL_IP array) and avoid the
server's own IP address. To ensure the selected "NUMBER" of external
servers, I'd pipe the "host $POOL" output through a "grep -v $MY_IP"
before doing the "head -$NUMBER".

The only problem with this is the periodic downtime, or at least lack
of synchronisation, for pool users. Is that a problem? FWIW I am a
potential pool operator, myself. I might soon add one or more pool
servers in the DFW-metroplex (Texas, USA) area.

Steve suggested a script using ntpdc to manage configuration without
rewriting ntp.conf and restarting ntpd, but I don't have time to get
into that right now. :)

Enjoy, comments appreciated. I'll modify it as guided by Those Who Know
NTP and donate it to the project.
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

"/dev/rob0" <rob0@gmx.co.uk> wrote in message news:<pan.2004.08.28.15.47.39.183783@gmx.co.uk>...
> I think I solved this just before hitting "send". :) I'll post it
> anyway in the hopes of helping to prevent (or delay) baldness. See the
> [SOLUTION] below.
> 
> Platform: Slackware Linux 10.0, kernel 2.6.6 (custom but inclusive)
> NTP: 4.2.0
> ntp.conf:
>     server us.pool.ntp.org.
>     server us.pool.ntp.org.
>     server us.pool.ntp.org.
>     driftfile /etc/ntp/drift
>     multicastclient
>     broadcastdelay  0.008
>     restrict default noquery nomodify
>     restrict 127.0.0.1
>     restrict 192.168.0.0 mask 255.255.0.0  # my LAN and VPN sites
>     restrict 10.1.0.0 mask 255.255.0.0     # VPN sites
> 
> The problem is the "restrict default" line. I have tried it with
> numerous permutations, both more and less restrictive.
> 
> It works when I take out the restrict lines. Otherwise, ntpq shows the
> servers as unreachable. I have not found a "restrict default" set of
> flags which allows the pool servers in.
> 
> I wrote a shell script, which I will post in a reply in this thread,
> which addresses some of the problems with pool servers and access
> controls: it builds a list of IP addresses for "server" lines and
> "restrict" lines. Using several "server $IP_ADDR" lines with matching
> "restrict $IP_ADDR" lines in ntp.conf *does* work.
> 
> Can you suggest other "restrict default" flag combinations? I have
> thoroughly RTFM accopt.html. Could we have encountered a subtle ntpd
> bug here?
> 
> [SOLUTION]
> I think it may have been my iptables firewall causing this. I use SNAT:
>     $IPT -t nat -A POSTROUTING -o $EXT_IF -j SNAT --to-source $EXT_IP
> (EXT_I{F,P}: external interface, IP). When I add this to ntp.conf:
>     restrict $EXT_IP
> it works. (The firewall machines is also running the external ntpd.)
> 
> I don't know exactly why this might be happening, but I guess it's in
> the Linux netfilter ip_conntrack module. It's still a mystery in that
> the "restrict default" line should not prevent synchronisation with a
> server, but who am I to argue with results? :)

We really need to change the code to automatically allow in
packets from the designated servers so that we don't have to
play with restrict.

Danny

"/dev/rob0" <rob0@gmx.co.uk> wrote:

> Another problem addressed by this script is that pool servers might
> quit or change IP.

The pool is being changed constantly (well, currently hourly), due to the
load-balancing algorithms being used to manage the pool.ntp.org DNS space.

So, this kind of script could cause a significant imbalance.

>                             I thought I might run this thing weekly or
> monthly from crond. Perhaps it also helps distribute the load among more
> pool servers?

No, you just create the same load on more servers.

> Steve suggested a script using ntpdc to manage configuration without
> rewriting ntp.conf and restarting ntpd, but I don't have time to get
> into that right now. :)

If you want to do it, ntpdc is the way to do it right.  Hook that into your
DHCP client configuration, and every time you get a new IP address you will
also update your list of time servers -- otherwise you'd be cut off from
them.

Of course, if you go through a SOHO router that does NAT, then you've got
this problem every time the box gets a new IP address itself, which is why
we recommend using a hierarchical solution -- sync the SOHO router/NAT box
to upstream time servers and then use it as a local time server, then sync
the local clients to the local server.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

On Tue, 31 Aug 2004 01:44:11 +0000, brad wrote:
>> Another problem addressed by this script is that pool servers might
>> quit or change IP.
> 
> The pool is being changed constantly (well, currently hourly), due to the
> load-balancing algorithms being used to manage the pool.ntp.org DNS space.

What happens when my three "server pool.ntp.org." lines pull up IP's
A, B, and A ... then A goes down and B is unreachable?

> So, this kind of script could cause a significant imbalance.

Are you suggesting greater balance occurs when clients use the
aforementioned configuration, restarting ntpd maybe once a year or
less? I don't see your point at all. Please elabourate.

In what I have described, once a week (or month) my client will build a
new list of 7 ($NUMBER) distinct IP addresses from the pool, and then
restart using that list.

I don't question that you know far more about NTP than I do or ever
will, but I am not sure you understand my script. You could try
uncommenting the "WKDIR=$PWD" line to test it as a non-root user.

>>                             I thought I might run this thing weekly or
>> monthly from crond. Perhaps it also helps distribute the load among more
>> pool servers?
> 
> No, you just create the same load on more servers.

If I have seven "server pool.ntp.org." lines, and it happens to resolve
to 5 distinct IP addresses, how does that differ from having NUMBER=5
in the script?

The difference as I see it is that with the script I *know* I have
$NUMBER of servers, whereas by using raw DNS resolution I could end up
with 0-7 servers. (Using broken resolvers such as DJB's dnscache
neither approach works: you only get one IP.)

ISTM the end user (that's me) has an interest in having a diversified
server base, because sometimes parts of the 'net are unreachable,
sometimes servers go bad, and sometimes servers quit serving.

Am I correct in understanding that ntpd evaluates the numerous
configured servers, chooses the best based on stratum and distance, and
maintains communications only with the selected ones? If so how is the
load being put on more servers?

>> Steve suggested a script using ntpdc to manage configuration without
>> rewriting ntp.conf and restarting ntpd, but I don't have time to get
>> into that right now. :)
> 
> If you want to do it, ntpdc is the way to do it right.  Hook that into your

Agreed, but as indicated *I* am not going to be the one to do it; at
least not very soon.

> DHCP client configuration, and every time you get a new IP address you will
> also update your list of time servers -- otherwise you'd be cut off from

Sure, but I'm doing this mostly on static IP clients. My home IP is
technically "dynamic" but it's the kind of dynamic that never changes.
:)

> Of course, if you go through a SOHO router that does NAT, then you've got
> this problem every time the box gets a new IP address itself, which is why
> we recommend using a hierarchical solution -- sync the SOHO router/NAT box
> to upstream time servers and then use it as a local time server, then sync
> the local clients to the local server.

This is what I do. I only synchronise externally from a single client
at any given site, and it's generally the one which is doing the NAT.
(I even ran ntpd on my old 386 when it was my home router. :) )
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

"/dev/rob0" <rob0@gmx.co.uk> wrote:

> What happens when my three "server pool.ntp.org." lines pull up IP's
> A, B, and A ... then A goes down and B is unreachable?

Well, ntpd will continue to track all the servers that it is configured to
know about, and when one of them goes away, it will note that fact.  If it
was using that server as it's chosen upstream truechimer, then it will have
to find another.

This is a completely normal and automatic process.

> Are you suggesting greater balance occurs when clients use the
> aforementioned configuration, restarting ntpd maybe once a year or
> less? I don't see your point at all. Please elabourate.

The load caused by ntpd is much higher during startup.  If you restart too
often, you will significantly increase the load on the listed servers.  In
addition, a lot of very useful data that is normally kept by ntpd during
operations is lost during a restart.  Moreover, ntpd has been designed to
handle the problem of multiple servers configured, but one or more of them
being unreachable or unreliable.  A great deal of work has gone into ntpd
to make sure that it deals with these kinds of problems in a sensible and
robust way -- and in a way that helps to minimize the additional load
created on the upstream servers.

You should keep an eye on your ntpd operation, and if you get to the point
where multiple upstream servers are unreachable or unreliable, then you
might want to consider dropping them from your configuration and adding
others.  But that doesn't require a restart.

Even having your IP address change out from underneath you doesn't require
a restart.  Much better would be to drop the old associations and add the
new ones (even if they are theoretically the same ones).

> I don't question that you know far more about NTP than I do or ever
> will, but I am not sure you understand my script. You could try
> uncommenting the "WKDIR=$PWD" line to test it as a non-root user.

I understand the script quite well.  I have debated with myself many times
as to whether or not I should write a script to monitor ntpd peer
performance and to automatically drop and re-add servers based on the
configuration file, using ntpdc.

I'm still thinking about doing that, but with some additional work, your
script could also be useful along those lines.

> If I have seven "server pool.ntp.org." lines, and it happens to resolve
> to 5 distinct IP addresses, how does that differ from having NUMBER=5
> in the script?

Right now, ntpd will only ever see the first IP address -- it won't even
try the others.  It's up to the DNS resolver routines to handle round-robin
rotation, so that the top IP address that is returned is different each
time.  Even listing the same "server pool.ntp.org" line may result in the
same IP address being returned each time, if the resolver routines don't do
round-robin rotation.

We're looking at ways that this process can be improved in the future, but
this is the way things are right now.


On the flip side, letting Adrian decide how the round-robin should be
handled on the server side will at least leave us with a situation that is
no worse than it is today, which is an improvement over the way things
were.  Any attempt by you to second guess how that should work could create
significant additional problems on these servers, and it could result in
situations that are very difficult for anyone outside of your network to
debug.

> The difference as I see it is that with the script I *know* I have
> $NUMBER of servers, whereas by using raw DNS resolution I could end up
> with 0-7 servers. (Using broken resolvers such as DJB's dnscache
> neither approach works: you only get one IP.)

We're working on a much better resolution to this issue, but in the
meanwhile your script causes way too many other problems for this benefit
to be dominant.

> ISTM the end user (that's me) has an interest in having a diversified
> server base, because sometimes parts of the 'net are unreachable,
> sometimes servers go bad, and sometimes servers quit serving.

Right, and ntpd is designed to handle those kinds of problems.  Just list
multiple servers in your /etc/ntp.conf file.

> Am I correct in understanding that ntpd evaluates the numerous
> configured servers, chooses the best based on stratum and distance, and
> maintains communications only with the selected ones? If so how is the
> load being put on more servers?

It continues to monitor all the servers it is configured to know about,
because which ones are/are not reachable could change on a moment-by-moment
basis, or their quality of service could change, etc....

> Agreed, but as indicated *I* am not going to be the one to do it; at
> least not very soon.

Just keep in mind the load you will be putting on these servers that you
are being allowed to use, and if you encourage others to use your scripts,
the knock-on effect that will result.


As I said, if you want to do it right, you need to use ntpdc.

Now, if you do actually acknowledge that I understand more about this
process than you do, why are you arguing?

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

brad@shub-internet.org writes:
> In addition, a lot of very useful data that is normally kept by ntpd
> during operations is lost during a restart.

Could this be considered a bit of a bug?

We already have the drift file, but that doesn't record all the other
state that would be nice to have at startup.

Right now a lot of packets are sent out at startup as ntpd works its
polling time back up to 1024 seconds.  It also has to slowly gather
the delays, offsets, jitters to the various peers/servers.  In
reality, the world really probably didn't change that much between the
killing the old ntpd and starting a new one.  Checkpointing the old
data and saving it on shutdown would make ntpd a bit better of an
internet citizen and should also ease some of the startup pains.

Of course the downside is that some user could royally muck things up
by putting random trash into the checkpoint/state file.

-wolfgang
-- 
Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/
New toy:  Voice over ip phone.  Sounds much better than an analog phone.
               http://www.wsrcc.com/wolfgang/voip.html

> Using broken resolvers such as DJB's dnscache neither approach works:
> you only get one IP.

You're violating RFC 1123, Requirements for Internet Hosts, Section 2.3,
by mindlessly discarding everything past the first address.

This violation does less damage when it's combined with a nonstandard
BIND option, but it's still irresponsible client behavior.

dnscache is handling the protocol correctly.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

On Thu, 02 Sep 2004 20:15:47 +0000, brad wrote:
>> What happens when my three "server pool.ntp.org." lines pull up IP's
>> A, B, and A ... then A goes down and B is unreachable?
> 
> Well, ntpd will continue to track all the servers that it is configured to
> know about, and when one of them goes away, it will note that fact.  If it
> was using that server as it's chosen upstream truechimer, then it will have
> to find another.
> 
> This is a completely normal and automatic process.

But you have not answered the question. Three server lines, two IP's
resolved; neither one can be reached.

Where will it find another server? Is it going to reresolve the
"pool.ntp.org." hostname? Perhaps you are assuming that I have some
familiarity with the NTP code; unfortunately I do not.

>> Are you suggesting greater balance occurs when clients use the
>> aforementioned configuration, restarting ntpd maybe once a year or
>> less? I don't see your point at all. Please elabourate.
> 
> The load caused by ntpd is much higher during startup.  If you restart too
> often, you will significantly increase the load on the listed servers.  In

Okay. But my thought here is that I'm using the same servers unless or
until ntpd reresolves the pool hostname. If I restart, the new set of
servers gets the restarting load, but some of the old servers might be
off the hook.

> addition, a lot of very useful data that is normally kept by ntpd during
> operations is lost during a restart.  Moreover, ntpd has been designed to
> handle the problem of multiple servers configured, but one or more of them

Has Wolfgang's suggestion of saving this data to disk been considered?

The thing I saw was that with 3 pool server lines, as recommended at
the pool Web site, I usually didn't get 3 servers. On 3 systems served
by DJB's dnscache I had only one (an apparent violation of RFC 1123,
Requirements for Internet Hosts, Section 2.3, or so I hear. :) ) Where
BIND served DNS, I had 2-3 servers listed in ntpq.

> You should keep an eye on your ntpd operation, and if you get to the point
> where multiple upstream servers are unreachable or unreliable, then you
> might want to consider dropping them from your configuration and adding
> others.  But that doesn't require a restart.

But for me this is a BIG problem. I'm running at least 12 sites with
ntpd. With other responsibilities, like it or not, I am looking for a
fix-it-and-forget-it solution.

>> If I have seven "server pool.ntp.org." lines, and it happens to resolve
>> to 5 distinct IP addresses, how does that differ from having NUMBER=5
>> in the script?
> 
> Right now, ntpd will only ever see the first IP address -- it won't even

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+wdc.phisolution 216.162.200.152  2 u  423 1024  377   34.934   -0.427   4.354
xtime.niconet2k. 192.43.244.18    2 u  428 1024  377  211.829   49.481   7.780
+ntp1.jrc.us     18.103.0.198     2 u  427 1024  377   47.584   -0.990   2.111
-carbon.sd.dream 204.123.2.5      2 u  407 1024  377   97.417   -6.650   0.799
*clock1.redhat.c .CDMA.           1 u  354 1024  377   23.702   -1.909   0.812
-nimda.mailworx. 18.103.0.198     2 u  442 1024  377   61.213    0.444   5.141
+canon.xyonet.co 18.145.0.30      2 u  457 1024  377   46.583   -2.188   4.081
 LOCAL(0)        LOCAL(0)        10 l   35   64  377    0.000    0.000   0.001

$ grep ^server /etc/ntp.conf
server 65.84.5.162              burst
server 65.110.41.44             burst
server 65.211.109.11            burst
server 66.33.206.5              burst
server 66.187.233.4             burst
server 69.1.200.68              burst
server 69.49.141.146            burst
server  127.127.1.0     # local clock

Looks to me as if all 7 servers have been checked and evaluated? What
am I not understanding here? This seems to contradict what you say
below.

> try the others.  It's up to the DNS resolver routines to handle round-robin
> rotation, so that the top IP address that is returned is different each
> time.  Even listing the same "server pool.ntp.org" line may result in the
> same IP address being returned each time, if the resolver routines don't do
> round-robin rotation.

This was the problem I encountered and tried to fix. The fact that you
repeat it back to me shows that "what we have here, is a failure to
communicate."

> We're looking at ways that this process can be improved in the future, but

Glad to hear it.

> On the flip side, letting Adrian decide how the round-robin should be
> handled on the server side will at least leave us with a situation that is
> no worse than it is today, which is an improvement over the way things
> were.  Any attempt by you to second guess how that should work could create
> significant additional problems on these servers, and it could result in

How significant would this problem be with a weekly restart? Monthly?
If it's going to anger or cause problems for the pool server operators,
I certainly won't want to do it. I want my machines to be good netizens
as much as I can make them so.

> situations that are very difficult for anyone outside of your network to
> debug.

This makes no sense to me. I don't ask for outside help. I run ntpq and
can see if I've synchronised. The only potential problem I can imagine
is that a server will give me the K'o'D, but ntpq would show that.

>> The difference as I see it is that with the script I *know* I have
>> $NUMBER of servers, whereas by using raw DNS resolution I could end up
>> with 0-7 servers. (Using broken resolvers such as DJB's dnscache
> 
> We're working on a much better resolution to this issue, but in the
> meanwhile your script causes way too many other problems for this benefit
> to be dominant.

The problems you have explained are that of the startup load and the
temporary loss of state data following the restart. The startup load
issue is ameliorated by reducing the frequency of restarts. (Hey, I'm
sure some home users restart ntpd every day or more! When I was running
ntpd on dialup, the ISP hung up on me every 4 hours, so I had to resync
several times a day. And before I got a decent UPS, my computer at home
crashed at least once a month, usually more.)

The loss of state data doesn't worry me much. Once every $INTERVAL I
might not have as high a degree of clock accuracy for about 30 minutes.
I don't see this as a problem. I'm still a lot better off than with the
old ntpdate cron jobs we had in the past.

>> ISTM the end user (that's me) has an interest in having a diversified
>> server base, because sometimes parts of the 'net are unreachable,
>> sometimes servers go bad, and sometimes servers quit serving.
> 
> Right, and ntpd is designed to handle those kinds of problems.  Just list
> multiple servers in your /etc/ntp.conf file.

And the script automates that process! So we're only in dispute on the
question of restarting ntpd, and how often is too much? Annually?

> It continues to monitor all the servers it is configured to know about,

This is what I thought, and here is the aforementioned contradiction.

> Now, if you do actually acknowledge that I understand more about this
> process than you do, why are you arguing?

That comes across as an odd thing to say. "Arguing" is a loaded term.

I'm continuing this discussion (or argument, if you prefer) because 1.)
I suspect I have not adequately communicated my concerns (from an
admitted lack of understanding of NTP); and because 2.) You have not
adequately gotten your points across to me: I am even more confused by
your explanations, with what appear to contain contradictions.

If the discussion is causing a problem for you in some way, I will
understand if you do not respond. But I do hope someone will explain
what's wrong with my plan, so I stop before implementing it at a dozen
or more sites.
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

On Fri, 03 Sep 2004 21:17:33 +0000, D. J. Bernstein wrote:
>> Using broken resolvers such as DJB's dnscache neither approach works:
>> you only get one IP.
> 
> You're violating RFC 1123, Requirements for Internet Hosts, Section 2.3,
> by mindlessly discarding everything past the first address.
> [snip]
> dnscache is handling the protocol correctly.

Thank you for the reply. I will research this further, but as posted
elsewhere in this thread, it was at the dnscache-served sites where I
encountered this issue. At those sites, only one IP was returned for
ntpd's 3 or more queries to resolve "us.pool.ntp.org." This was seen
across several restarts of ntpd (sorry, Brad. :) )

At BIND-served sites I saw that multiple IP's had been returned for
these queries. BIND host(1) gets me the entire pool.
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

Why are you using "burst" as opposed to iburst?

Without permission and a very good reason, that is just plain unfriendly.

At the moment, the most useful piece of information to save across a
restart of ntpd is the drift value, and we do that.

If there are other pieces of information that would be useful to save,
let's discuss it.  My vote would be to have this discusison on the twiki
(or at least summarized there).

H

Harlan Stenn wrote:
[]
> If there are other pieces of information that would be useful to save,
> let's discuss it.  My vote would be to have this discusison on the
> twiki (or at least summarized there).
>
> H

Please have the actual discussion here where we can all follow it, thanks.

David 

This is a multi-part message in MIME format.
--------------060802060800000100020701
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Harlan Stenn wrote:

>Why are you using "burst" as opposed to iburst?
>
>Without permission and a very good reason, that is just plain unfriendly.
>
>At the moment, the most useful piece of information to save across a
>restart of ntpd is the drift value, and we do that.
>
>If there are other pieces of information that would be useful to save,
>let's discuss it.  My vote would be to have this discusison on the twiki
>(or at least summarized there).
>
>H
>  
>
Harlan,

The documentation for the burst keyword could use a little 
clarification.  In fact, both burst and iburst could use a little 
clarification.

Iburst starts out with "When the server is unreachable,. . ."  If the 
server is not reachable, what's the point of sending anything to it?   
Suggested rewording:  "Use iburst to initialize quickly.  Iburst causes 
ntpd to send eight packets at two second intervals during startup. . . ."

For burst we have "When the server is reachable, send a burst of eight 
packets instead of the usual one. The packet spacing is normally 2 s; 
however, the spacing between the first and second packets can be changed 
with the calldelay command to allow additional time for a modem or ISDN 
call to complete. This is designed to improve timekeeping quality with 
the server command and s addresses." 

This doesn't  say or imply that it's a bad or unfriendly thing to do 
unless you think carefully about what it says.  If I understand it, 
burst is going to cause ntpd to send eight packets at two second 
intervals every time it queries the server!   This is definitely an 
unfriendly thing to do!  The documentation should probably be altered to 
point this out and to better define the circumstances under which it 
might properly be used.


--------------060802060800000100020701
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Harlan Stenn wrote:<br>
<blockquote type="cite" cite="midchc0bv$489$1@dewey.udel.edu">
  <pre wrap="">Why are you using "burst" as opposed to iburst?

Without permission and a very good reason, that is just plain unfriendly.

At the moment, the most useful piece of information to save across a
restart of ntpd is the drift value, and we do that.

If there are other pieces of information that would be useful to save,
let's discuss it.  My vote would be to have this discusison on the twiki
(or at least summarized there).

H
  </pre>
</blockquote>
Harlan,<br>
<br>
The documentation for the burst keyword could use a little
clarification.&nbsp; In fact, both burst and iburst could use a little
clarification.<br>
<br>
Iburst starts out with "When the server is unreachable,. . ."&nbsp; If the
server is not reachable, what's the point of sending anything to it?&nbsp;&nbsp;
Suggested rewording:&nbsp; "Use iburst to initialize quickly.&nbsp; Iburst causes
ntpd to send eight packets at two second intervals during startup. . .
.."<br>
<br>
For burst we have "When the server is reachable, send a burst of eight
packets instead of
the usual one. The packet spacing is normally 2 s; however, the spacing
between the first and second packets can be changed with the <tt>calldelay</tt>
command to allow additional time for a modem or ISDN call to complete.
This is designed to improve timekeeping quality with the <tt>server</tt>
command and <tt>s</tt> addresses."&nbsp; <br>
<br>
This doesn't&nbsp; say or imply that it's a bad or unfriendly thing to do
unless you think carefully about what it says.&nbsp; If I understand it,
burst is going to cause ntpd to send eight packets at two second
intervals <i><b>every time it queries the server!</b></i>&nbsp;&nbsp; This is
definitely an unfriendly thing to do!&nbsp; The documentation should
probably be altered to point this out and to better define the
circumstances under which it might properly be used.<br>
<br>
</body>
</html>

--------------060802060800000100020701--

On Sat, 04 Sep 2004 09:02:55 +0000, Harlan Stenn wrote:
> Why are you using "burst" as opposed to iburst?

A misunderstanding, as was well explained by Richard. :)

> Without permission and a very good reason, that is just plain unfriendly.

Changed. Thanks for the pointer.
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply

"/dev/rob0" <rob0@gmx.co.uk> wrote in message news:<pan.2004.09.04.06.19.14.622737@gmx.co.uk>...
> On Fri, 03 Sep 2004 21:17:33 +0000, D. J. Bernstein wrote:
> >> Using broken resolvers such as DJB's dnscache neither approach works:
> >> you only get one IP.
> > 
> > You're violating RFC 1123, Requirements for Internet Hosts, Section 2.3,
> > by mindlessly discarding everything past the first address.
> > [snip]
> > dnscache is handling the protocol correctly.
> 
BIND is handling the protocol properly. BIND will return all of the
A records that fit into one UDP packet and if they don't all fit it
will set the TC bit. BIND, however, does round-robin where possible.
That means you will get a different address first in the list every
time you ask. dnscache apparently does not do that. That are both right.

DJB is right in that if you only take the first address you lose a
lot of the benefit. There are, however, very few application will
will take more than just the first address.

Danny

mayer@gis.net (Danny Mayer) wrote in message news:<3a2a0492.0409062000.210ac70c@posting.google.com>...
> "/dev/rob0" <rob0@gmx.co.uk> wrote in message news:<pan.2004.09.04.06.19.14.622737@gmx.co.uk>...
> > On Fri, 03 Sep 2004 21:17:33 +0000, D. J. Bernstein wrote:
> > >> Using broken resolvers such as DJB's dnscache neither approach works:
> > >> you only get one IP.
> > > 
> > > You're violating RFC 1123, Requirements for Internet Hosts, Section 2.3,
> > > by mindlessly discarding everything past the first address.
> > > [snip]
> > > dnscache is handling the protocol correctly.
> > 
> BIND is handling the protocol properly. BIND will return all of the
> A records that fit into one UDP packet and if they don't all fit it
> will set the TC bit. BIND, however, does round-robin where possible.
> That means you will get a different address first in the list every
> time you ask. dnscache apparently does not do that. That are both right.
> 
> DJB is right in that if you only take the first address you lose a
> lot of the benefit. There are, however, very few application will
> will take more than just the first address.
> 
> Danny

It occurs to me that it might be worth changing the config options
to allow you to specify the number of addresses you want to use
out of the addresses returned by the query. We'd also need to modify
the restrict defaults since you wouldn't know which addresses you'd
get.

Danny