ntpdate deprecated

Hi Buchan,

Thanks for the response. I will disable the ntp-test. it's running on three
hosts and all of them report the same WARNING-output.

However, the reason I came up with this is that in our network we have some
W2K-hosts (the Domain Controllers) who have (according to Xymon) a time that
is not accurate (I'm using the CLOCK option and Xymon thinks they are
drifting too far; above threshold of 30 seconds).

I wondered: how is this determined on the Windows side? Because when we have
a look at this system, the time is correct? It looks like the time
difference between the page generation and the send time (12:38:57 -
12:37:19) = 98 seconds off (see below).

The time on the server however IS correct. I've seen it, but since the total
MSG-size for these servers is so large (a few hundreds KB to 1 or 2 MB,
because of the domain controller function, there are hundreds of open ports
- netstat output), it does take some addiotinal time for the Xymon
client/server combination, to proces?!

Can I limit this output. For example: do NOT send UDP output? That would be
a quick fix solution?
Or better: split the output in several files, since the other (netstat) info
is valuable, but it should NOT interfere with the normal functionality of
Xymon and/of its clients. So the output should be send seperately to the
server.

Regards, Peter

*Wed Nov 11 12:38:57 2009*


    Wed Nov 11 12:37:19 2009 NOT ok

[image: yellow] System clock is 98 seconds off (max 30)

local: Wed Nov 11 12:37:19 2009
UTC: Wed Nov 11 11:37:19 2009


2009/11/11 Buchan Milne <user-9b139aff4dec@xymon.invalid>

On Wednesday, 11 November 2009 12:00:19 Peter Welter wrote:

Today, I discovered the following for the ntp-test on our Xymon server:

Service ntp on xymon is OK (up)


Command: ntpdate -u -q -p 2 132.229.84.242 2>&1

       !!!!!!!!!!!!!!  WARNING !!!!!!!!!!!!!!!!!!

The ntpdate program is deprecated and should not be used any more.  To

quote the upstream ntp developers:

  "The functionality ntpdate offered is now provided by the ntpd daemon
  itself.  If you call ntpd with the command line option -q it will
  retrieve the current time and set it accordingly."

Please check the Network Time Protocol (NTP) daemon man page and
  http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for further information.

You can replace the ntpdate call with "rcntp ntptimeset" to achieve an
inital poll of the servers specified in /etc/ntp.conf.

The program /usr/sbin/sntp offers comparable functionality to ntpdate.

Except the option flags are totally different.

Specifically
  sntp -P no -r pool.ntp.org
is equivalent to
  ntpdate pool.ntp.org

For further details please refer to the man page of sntp.

sntp: unable to write PID to /etc/sntp.pid
sntp: Permission denied

http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate#Set_the_time_before_

running_ntpd


I always thought I needed to run this ntp-test to make sure the time is
correct on the central monitor server, to make sure that the time on
other
monitored hosts is checked correctly.

Should I

- change the NTPDATE="ntpdate"-location in /etc/hobbit/hobbitserver.cfg
to
NTPDATE="sntp -u" to make it work again?

This on it's own won't be enough, as additional options are added to the
NTPDATE path:

$ grep -n -A7 NTPDATE ./bbnet/bbtest-net.c
991:    p = xgetenv("NTPDATE");
992-    strcpy(cmdpath, (p ? p : "ntpdate"));
993-    for (t=service->items; (t); t = t->next) {
994-            if (!t->host->dnserror) {
995-                    sprintf(cmd, "%s -u -q -p 2 %s 2>&1", cmdpath,
ip_to_test(t->host));
996-                    t->open = (run_command(cmd, "no server suitable for
synchronization", t->banner, 1, extcmdtimeout) == 0);
997-            }
998-    }

These options aren't supported by sntp. You could hack this by modifying
the
options, but the long-term fix (for people who don't have sntp yet) would
have
to be different.

- disable the ntp-test since because it is useless for checking the
correct
time on monitored hosts.

NTP is not that useful for monitoring the time on monitored hosts,  (the
client's built-in check is better, see the CLOCK option for
hobbit-clients.cfg
thresholds), unless you are running all your hosts as ntp servers. It is
however useful for checking whether the host believes it should be able to
provide time services to other hosts.

I only run this network test against NTP servers that other hosts use as
time
sources.

Regards,
Buchan