From: Tony Li <tony.li@tony.li>
Date: Thu, 20 May 2004 13:06:37 -0700
Sender: owner-nanog@merit.edu
One minor (operational! -- gasp) addition:
More modern copies of ntpd have a '-g' option that will allow
the clock to jump once at boot time.
OK. Am I in a alternate universe? I have run ntpdate for years on a
variety of systems, almost all of the BSD family. (I count the VMS
implementation in TGV software as BSD.) I have never seen '-g' and have
always had '-b' as the boot option. I have confirmed the '-b' with the
official sources at Deleware.
OK. Am I in a alternate universe? I have run ntpdate for years on a
variety of systems, almost all of the BSD family. (I count the VMS
implementation in TGV software as BSD.) I have never seen '-g' and have
always had '-b' as the boot option. I have confirmed the '-b' with the
official sources at Deleware.
According to the current man page for ntpd, the ntpdate is "to be
retired", hence the incorporation of the functionality of ntpdate(8)
into the ntpd(8) program.
It's not clear to me why Randy considered this newsworthy enough to
post to NANOG, nor why he feels the need to "write it up" rather than
just sending his internal customer an excerpt of the man page, where
this behavior is clearly documented (and has been since at least xntp3
circa 1997). Is it possible he's decided to compete with the guys who
discovered last week that CSMA networks are vulnerable to jabber?
I've found it useful on older machines (PCs with cheap clocks and
oscilators) to cron ntpdate once an hour to prevent the clock from
getting too far off by itself. I've found the daemon doesn't do good enough
of a job to sync on it's own...
I'm also wondering, how many people are using the ntp.mcast.net
messages to sync their clocks? what about providing ntp
to your customers via the "ntp broadcast" command on
serial links, etc..?
I have used NTP mcast for some time, most of my gear sets it's time this way.
I run mcast on the "inside" network, ie customer and internet edge interfaces
don't run it. There is no customer interest in mcast, here. Plus it is allot more to
consider if I let customers join my mcast network. Dr. Mills suggested
looking at manycast so clients select the closest NTP server (I have 1 strat1
and 3 strat2).
Isn't that a lot safer anyway than running a daemon (ntpd) as root ? I do
this on my systems (run ntpdate from cron), even though the xntpd
docs IIRC specifically advised against this hack. One less
vulnerability waiting to be exploited ... is the way I see it.
well, it does help if your clock goes nicely (or poorly) askew.
problem is any timestamps you may have on that host (radius, smtp, etc..)
that you use to track down the (l)users on your network can cause a problem.
all you have to be concerned with is "am i doing ntpdate from something
that can be poisoned". that's amongst many reasons to have the "your clock is
too far off, you must reset manually" log messages.
We have had one user that I know of who was receiving time sync info
via multicast announcements, but personally I don't care for doing NTP
this way. In my experience systems/users don't bother to do any sort
of authentication or filtering on NTP sources. Most server admins and
some implementations do not support authentication either. I'm pretty
sure I don't want to get time from just anyone who sends to 224.0.1.1
especially on networks connected to the multicast-enabled Internet.
That group address I might note is one I tend to scope at admin
boundaries for just that reason.
Kind of. ntpdate just sets the time. ntpd will actually notice your clock
running fast/slow and slowly step your kernel time to deal with your
bad clock frequency.
man ntpd. Its quite fascinating.
RE the "ntpd as root" thing, is there a capability in some UNIXen
which lets you fudge with the kernel time/timecounter frequency without
being root? I think thats all it really needs root privilege for.
I know what ntpd is supposed to do. Its what its *not* supposed to do that
worries me - i.e. when someone finds that next flaw and exploits it.
My personal feeling was that for most systems its better to not have the
daemon running - i.e. the benefit of smaller more frequent clock
adjustments does not outweigh the cost of another service running,
especially as root or even as a jailed non-root user.
I checked and the cron job usually adjusts the clock by about 0.2 to 0.3
sec every hour. Sure thats probably more than ntpd would adjust it in any
one iteration were ntpd running ...
its not too kooky or dangerous to use ntpdate + cron rather than ntpd;
0.5 sec is given as a cutoff for it being less disruptive when making
clock adjustments.
Its interesting to hear what other folks are doing. I had assumed folks
normally don't run ntpd on each and every server and that ntpdate + cron
was much preferred; maybe I am off-base.
ntpdate can set my clock backwards. ntpd, after you've first run it, won't.
If you're using this to combine logs between machines you may not
appreciate an hourly backwards step in time.
I've found it useful on older machines (PCs with cheap clocks and
oscilators) to cron ntpdate once an hour to prevent the clock from
getting too far off by itself. I've found the daemon doesn't do good enough
of a job to sync on it's own...
I'm also wondering, how many people are using the ntp.mcast.net
messages to sync their clocks? what about providing ntp
to your customers via the "ntp broadcast" command on
serial links, etc..?
I run two stratum-1 servers and a few stratum-2s and I provide time via multicast (224.0.0.1), but I don't use it for my servers, except for testing and verification. I am also providing anycast ntp, and, if the belt and suspenders weren't enough, I am experimenting with manycast. That's an NTPv4 feature where the *client* sends a multicast message to an administratively-scoped group soliciting servers and then the servers respond and set up associations. From a client-configuration standpoint, it's about as convenient as multicast or anycast, but it's more accurate than multicast (since the servers set up true associations with the client) and it allows you to do NTP authentication (which I think breaks with anycast). It seems to work pretty well--the client builds up several associations as if they were all configured manually.
RE the "ntpd as root" thing, is there a capability in some UNIXen
which lets you fudge with the kernel time/timecounter frequency without
being root? I think thats all it really needs root privilege for.
I run two stratum-1 servers and a few stratum-2s and I provide time via
multicast (224.0.0.1), but I don't use it for my servers, except for
Presumably you meant 224.0.1.1.
testing and verification. I am also providing anycast ntp, and, if the
belt and suspenders weren't enough, I am experimenting with manycast.
Noting that NTP uses more than a reply response message exchange. No
concerns about session breakage? SNTP would certainly be a very
viable candidate for anycast.
Except in the extreme case such as wisc.edu's unfortunate experience,
does multicast buy much? Traffic loads for properly running clients
and distributed servers tend to be relatively low in my experience.
Yes, running ntp on every router makes sense, but for those of us that
have clients with cisco 17xx as edge routers its *very* irritating that
ntp support is missing in some of those images.
I've run ntpd chrooted and setuid'ed with special clock change
privileges for 3+ years now. The code has been shipping for about
three years in Red Hat Linux, for example.
every server, router, switch, and workstation that supports it
PCs are the hardest part. you can net put "time \\source /yes" in the
login script to smack them into synch but they'll drift if you don't have
a real listener. win2k also has listeners but a little rough to config.
there are third party widgets too.
mcast/bcast where possible too, and dhcp config as well
ntp is one of the easier services to globally config
