sorry to take you away from discussing spam with an actual tech note, but twice this morning i have hit incidents where much needed ntp clients were blown. so, as i was gonna have to write it up, i figured i would bore you all with it. --- ntp config hint 2004.05.20 ntpd will not work if your clock is off my a few minutes. it just sits there forever with its finger in its ear. so, at boot, before you start ntpd, use ntpdate to whack your system's time from a friendly low-numbered strat chimer. do not background ntpdate with -b, because, if it is slow to complete, ntpd can't get the port when you try to start it next in the boot sequence. if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it. in case your dns resolver is slow, servers are in trouble, etc. have an entry for your ntpdate chimer in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd. once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ... and then, if having accurate time on this host is critical, cron a script which runs `ntpq -c peers` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems. --- now back to your regular spam discussion. /* yes, spam is an important issue. but, if your local organization, this mailing list, ... gets swamped with discussions of spam, then the spammers have won. you have to compartmentalize it, in your organization and in the general net culture. that's why there are separate mailing lists for spam, ddos, and other net crap with which we have to deal. that's why we have more than one mailing list in the world, to compartmentalize so we can focus. */ randy
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. Tony On May 20, 2004, at 12:27 PM, Randy Bush wrote:
sorry to take you away from discussing spam with an actual tech note, but twice this morning i have hit incidents where much needed ntp clients were blown. so, as i was gonna have to write it up, i figured i would bore you all with it.
---
ntp config hint 2004.05.20
ntpd will not work if your clock is off my a few minutes. it just sits there forever with its finger in its ear. so,
at boot, before you start ntpd, use ntpdate to whack your system's time from a friendly low-numbered strat chimer.
do not background ntpdate with -b, because, if it is slow to complete, ntpd can't get the port when you try to start it next in the boot sequence.
if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it.
in case your dns resolver is slow, servers are in trouble, etc. have an entry for your ntpdate chimer in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd.
once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ...
and then, if having accurate time on this host is critical, cron a script which runs `ntpq -c peers` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems.
---
now back to your regular spam discussion. /*
yes, spam is an important issue. but, if your local organization, this mailing list, ... gets swamped with discussions of spam, then the spammers have won.
you have to compartmentalize it, in your organization and in the general net culture. that's why there are separate mailing lists for spam, ddos, and other net crap with which we have to deal.
that's why we have more than one mailing list in the world, to compartmentalize so we can focus.
*/
randy
More modern copies of ntpd have a '-g' option that will allow the clock to jump once at boot time.
Saku Ytti <saku+nanog@ytti.fi> also told me this. have you tested. i remember a bad experience with it some years back, and, being a normally supersitious hacker, have avoided ever since. (yes, i still walk around that crack in the sidewalk where i tripped in the third grade:-). randy
On Thu, May 20, 2004 at 01:14:32PM -0700, Randy Bush wrote:
More modern copies of ntpd have a '-g' option that will allow the clock to jump once at boot time.
Saku Ytti <saku+nanog@ytti.fi> also told me this. have you tested. i remember a bad experience with it some years back, and, being a normally supersitious hacker, have avoided ever since. (yes, i still walk around that crack in the sidewalk where i tripped in the third grade:-).
randy
it works here. --bill
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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
"Kevin Oberman" <oberman@es.net> writes:
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? ---Rob
On Thu May 20, 2004 at 05:12:31PM -0400, Robert E. Seastrom wrote:
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?
Or, maybe, as he alluded to in his email, he's just trying to get us to talk about something other than spam ;-) Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x(01)37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x(01)37701) | non sit, noli BBC Internet Ops | Email: Simon.Lockhart@bbc.co.uk | id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
It's not clear to me why Randy considered this newsworthy enough to post to NANOG
two reasons o add some non-spam content o to see who would contribute good tech info (nothing like posting old habits to get new education) and to see who would just mouth off. thanks for playing randy
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..? - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Thu, 2004-05-20 at 15:33, Jared Mauch wrote:
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..?
- jared
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). -- James H. Edwards Routing and Security Administrator At the Santa Fe Office: Internet at Cyber Mesa jamesh@cybermesa.com noc@cybermesa.com
On Thu, 20 May 2004, Jared Mauch wrote:
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...
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.
On Thu, May 20, 2004 at 06:37:23PM -0400, C. Jon Larsen wrote:
On Thu, 20 May 2004, Jared Mauch wrote:
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...
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. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Thu, May 20, 2004, C. Jon Larsen wrote:
On Thu, 20 May 2004, Jared Mauch wrote:
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...
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.
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. Adrian -- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
On Fri, 21 May 2004, Adrian Chadd wrote:
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.
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.
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 ... according to: http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html 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.
On Thu, May 20, 2004, C. Jon Larsen wrote:
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 ...
according to: http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html
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. :) adrian -- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
you ask do folk run ntpd on every server. i wonder if folk run ntpd on every router. i did and do. randy
On Thu, 20 May 2004, Randy Bush wrote:
you ask do folk run ntpd on every server.
i wonder if folk run ntpd on every router. i did and do.
randy
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.
On 5/20/2004 10:57 PM, Randy Bush wrote:
you ask do folk run ntpd on every server.
i wonder if folk run ntpd on every router. i did and do.
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 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 20 May 2004, Randy Bush wrote:
you ask do folk run ntpd on every server.
i wonder if folk run ntpd on every router. i did and do.
We use ntp on every router for setting time. We don't run ntpd on every server due to security concerns based on the idea that you can't have a hole in a daemon you aren't running. This is relatively unnecessary I suppose since ntpd is probably most commonly configured nowdays not to listen on an exposed port by default. Just out of curiosity... do you run bind on every server? Mike. ps. We run dedicated ntp boxes that don't have hard drives (thanx for the recommendation a few years ago), again with the idea somebody can't install a rootkit on box that doesn't have a hard drive. It's not perfect or even necessary, just an optional precaution. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
C. Jon Larsen wrote: [snip]
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.
After the last "big" xntpd vulnerability a few years ago, I went through and made sure that I had the permissions set appropriately, restrict <server1> noquery nomodify restrict <server2> noquery nomodify ... restrict 127.0.0.1 nomodify restrict default ignore On UNIXen servers. Of course, I upgraded my daemons where possible, but the vulnerability occurred late enough in the message processing that the approprate restrictions prevented exploit (the packet was dropped before the vulernable code was reached). Of course, there still is the potential for vulnerabilities very, very early in message processing, or in spoofed query responses if someone knows what servers I use and is behind the firewall. But overall, I like it much better than what the UNIX admin here used to do, 0 2 * * * rdate timehost -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
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.
Well, present NTP drops to a nonroot user after it sets the time & proprer use of the very flexable ACL lists in your ntp.conf should help midigate non-local NTP exploits, ie, don't offer NTP service to the world or anyone else for that matter. I need better than one second resolution for syslog and other loging info to be useful in debugging problems across multiple hosts. -- James H. Edwards Routing and Security Administrator At the Santa Fe Office: Internet at Cyber Mesa jamesh@cybermesa.com noc@cybermesa.com (505) 795-7101
On Fri, 21 May 2004, Adrian Chadd wrote:
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.
Close enough? http://www.onlamp.com/pub/a/bsd/2003/02/13/chroot.html?page=1 I don't know if the other *BSDs have followed or not... Charles
Adrian
-- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
On Fri, 21 May 2004, Adrian Chadd wrote:
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.
Yes, for example in Linux. 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thu, 20 May 2004 17:33:22 -0400 Jared Mauch <jared@puck.nether.net> wrote:
I'm also wondering, how many people are using the ntp.mcast.net messages to sync their clocks? what about providing ntp
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. John
Jared Mauch wrote:
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. michael
On Thu, 20 May 2004 21:08:43 -0700 Michael Sinatra <michael@rancid.berkeley.edu> wrote:
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. John
Hi John: John Kristoff wrote:
On Thu, 20 May 2004 21:08:43 -0700 Michael Sinatra <michael@rancid.berkeley.edu> wrote:
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.
Yep, sorry.
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.
Yes it is. Session breakage doesn't seem to be a problem, as long as you're per-flow traffic sharing for equal-cost routes across your backbone. I can see where per-packet switching would make a mess of things, but that's true with any anycast service. Also, if the flow table entry ages out before the next NTP poll, I can see how a client running a full-blown ntpd would probably perceive an otherwise transparent switch back and forth between two servers as excess jitter. If you're worried about this, then one way around it would be to adjust the costs of your injected routes so that one server is always preferred over another. In that case, you're not buying load-distribution across servers, but backup for clients where ease of configuration is more important that accuracy, but where reliability (ability to poll at least one server all the time) is still important, and multicast may or may not provide the level of reliability that you need. (I am a fan of multicast, BTW.) In our case it's useful, as you note, for pointing an increasing number of SNTP clients (including network equipment) to one address that's reliable and redundant. I know there are others who have experience in doing NTP anycast, at least within an enterprise, and perhaps as service provider, who can probably comment.
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. The main "buy" is ease of configuration, and that holds for multicast, manycast, and anycast. I get a lot of requests for providing NTP in such a way that sysadmins and users can use a really simple bootstrap configuration in clients that they can replicate across their enterprise. I'll also note that some OS vendors ship a stock multicast config for their (x)ntpd. I have found that load can get higher when you start hammering servers with thousands of SNTP clients; it can be something of an issue considering that NTP servers tend to be hand-me-down hardware. (BTW: Is rackety.udel.edu still a Sun IPC?) So, my "problem" is, how can I properly distribute the load across servers, increase reliability, and still give users simplicity in their configuration? Each of the three solutions has its own set of pros and cons: manycast - probably the best solution; solves authentication and possible session issues with anycast, more accurate than multicast, since true associations are established with (hopefully) several participating servers. Downside is that it's only supported in v4, which not all vendor OSes have as their stock daemon; doesn't work with SNTP. anycast - probably best solution for SNTP clients, may also be useful for not v4 clients that can't do manycast. May break authentication, depending on how keys are managed, but I haven't actually tested this. (If all anycast servers have the same key pair, will authentication break if a client switches servers due to a routing change? I haven't tested this yet.) multicast - Still a good solution for v3 clients that want simple configuration. A lot of people still *ask* about multicast NTP, since that's the config some OS vendors ship. Then of course, there's the good old configure-4+-ntp-servers-manually, which is good for important boxes that really need good time. (I have one box that does all three of the above, plus has manually configured servers.) Any thoughts or comments on the advantages and disadvantages of the above techniques are welcome, as well as corrections. michael
I would be very worried about forcing an unchecked clock sync against a single time source in this way.. if your source is broken you can break a lot.. i think the limit is 1000s so you shouldnt be slipping by that much unless something is broken? Steve On Thu, 20 May 2004, Jared Mauch wrote:
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..?
- jared
It needs to be set of trusted time sources that is as reliable as you feel is necessary. If you're feeling extremely paranoid, then you can use the -g flag to peer with a number of your private stratum 1 sources and then let the sanity checking do its job to avoid any bogochimers. Tony On May 23, 2004, at 1:37 PM, Stephen J. Wilcox wrote:
I would be very worried about forcing an unchecked clock sync against a single time source in this way.. if your source is broken you can break a lot..
i think the limit is 1000s so you shouldnt be slipping by that much unless something is broken?
Steve
On Thu, 20 May 2004, Jared Mauch wrote:
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..?
- jared
From: Randy Bush <randy@psg.com> Date: Thu, 20 May 2004 12:27:48 -0700 Sender: owner-nanog@merit.edu
ntp config hint 2004.05.20
ntpd will not work if your clock is off my a few minutes. it just sits there forever with its finger in its ear. so, at boot, before you start ntpd, use ntpdate to whack your system's time from a friendly low-numbered strat chimer.
For the initial ntpdate, I recommend that you use fairly local, highly reliable hosts. Low numbered stratum is not very relevant. If your clock is off by 600 ms, ntpd will fix it just fine.
do not background ntpdate with -b, because, if it is slow to complete, ntpd can't get the port when you try to start it next in the boot sequence.
Huh? On every system I have worked on (Unix types), -b is the "boot" option and does exactly what you want to do at boot time. It sets the clock immediately by stepping and never slews the time. This is what you want at boot time as you want the time to be correct ASAP, not in a few minuted.
if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it.
If you use '-b' and have a list of reachable servers, it should take less than a second.
in case your dns resolver is slow, servers are in trouble, etc. have an entry for your ntpdate chimer in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd.
Rather than put the servers in my hosts file (which would screw up everything should they move), I just five ntpdate a list of servers by IP address. This does everything putting a systems into hosts without the possibility of impacting other stuff.
once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ...
and then, if having accurate time on this host is critical, cron a script which runs `ntpq -c peers` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems.
I use 'ntpq -p', but I'm just lazy enough to save a few keystrokes. Both commands produce identical output. Randy, what version of ntpdate are you running that ntpdate backgrounds on '-b'? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
note that ntpdate is actually depreciated. and at some point you'll have to run ntpd to set the time (with the -q flag) then run it again. joelja On Thu, 20 May 2004, Randy Bush wrote:
sorry to take you away from discussing spam with an actual tech note, but twice this morning i have hit incidents where much needed ntp clients were blown. so, as i was gonna have to write it up, i figured i would bore you all with it.
---
ntp config hint 2004.05.20
ntpd will not work if your clock is off my a few minutes. it just sits there forever with its finger in its ear. so,
at boot, before you start ntpd, use ntpdate to whack your system's time from a friendly low-numbered strat chimer.
do not background ntpdate with -b, because, if it is slow to complete, ntpd can't get the port when you try to start it next in the boot sequence.
if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it.
in case your dns resolver is slow, servers are in trouble, etc. have an entry for your ntpdate chimer in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd.
once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ...
and then, if having accurate time on this host is critical, cron a script which runs `ntpq -c peers` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems.
---
now back to your regular spam discussion. /*
yes, spam is an important issue. but, if your local organization, this mailing list, ... gets swamped with discussions of spam, then the spammers have won.
you have to compartmentalize it, in your organization and in the general net culture. that's why there are separate mailing lists for spam, ddos, and other net crap with which we have to deal.
that's why we have more than one mailing list in the world, to compartmentalize so we can focus.
*/
randy
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
with constructive criticism/input from a number of net folk, version .0002! randy --- an ntpd config hint 2004.05.20 executive summary o if you have a recent ntpd, use `ntpd -g`, and be sure to start it before you go multiuser if you have clock lock security in multiuser o if the above does not work for you, sorry, you need to read on; you may want to anyway many applications need to be run in host environments where an accurate clock is needed. this is why most hosts today chime with ntp. but, ntpd will not work if your clock is off by a few minutes. it quits or just sits there forever with its finger in its ear. so, newer versions of ntpd have the -g parameter, which allows for a big first step. this obviates the use of ntpdate in the next paragraphs. but, this will not work if you have told the kernel to refuse to change the time when the system is in multiuser mode for security reasons. at boot, before you start ntpd, you can use ntpdate to whack your system's time from a list of friendly nearby and very sure to be connected chimers. if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it. in case your dns resolver is slow, servers are in trouble, you're running ntpdate before dns resolution is up [0], etc. have an entry for your ntpdate chimer(s) in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd. run ntpdate -b with a list of servers. this will help if one or more are unreachable. once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ... the 'iburst' keyword for servers listed in ntp.conf will cause ntpd toperform an initial sync (defined as any synchronization after a transition out of an unsynchronized state) with a short burst of packets in a small interval. so, you get a faster clock update for a small tradeoff in accuracy. not considered polite to public servers, but if you have local boxes that keep pretty good time, it's may be worth the minute amount of extra traffic. and then, if having accurate time on this host is critical, cron a script which runs `ntpq -p` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems. for more info, see <http://twiki.ntp.org/>. Thanks to Rob Foehl Brad Knowles Peter Lothberg Kevin Oberman Saku Ytti --- [0] - if dnssec is deployed, somewhat accurate time will be needed before name resolution will work. so, if you are an optimimst, expect to see ntpd up before named more and more in the future -30-
In message <16557.19293.173699.685625@ran.psg.com>, Randy Bush writes:
with constructive criticism/input from a number of net folk, version .0002!
I'll add my .02 currency units: if you can, make one of your ntp peers XX.pool.ntp.org, where XX is your country code. Obviously, not all values of XX work -- among the surprising failures are il.pool.ntp.org, jp.pool.ntp.org, and kr.pool.ntp.org -- but it's worth looking for your country or a neighboring one. This will give you a selection among many different choices, if you aren't concerned with picking a specific one (say, for security reasons). --Steve Bellovin, http://www.research.att.com/~smb
Steven M. Bellovin wrote:
I'll add my .02 currency units: if you can, make one of your ntp peers XX.pool.ntp.org, where XX is your country code. Obviously, not all values of XX work -- among the surprising failures are il.pool.ntp.org, jp.pool.ntp.org, and kr.pool.ntp.org -- but it's worth looking for your country or a neighboring one. This will give you a selection among many different choices, if you aren't concerned with picking a specific one (say, for security reasons).
I seem to get always the same answer, even from the authorative servers of the zone; ;; ANSWER SECTION: ntp.pool.org. 2H IN CNAME sd3.mailbank.com. sd3.mailbank.com. 30M IN A 64.15.175.6 Pete
Petri Helenius wrote:
;; ANSWER SECTION: ntp.pool.org. 2H IN CNAME sd3.mailbank.com. sd3.mailbank.com. 30M IN A 64.15.175.6
;; ANSWER SECTION: pool.ntp.org. 1h30m IN A 64.44.160.38 pool.ntp.org. 1h30m IN A 65.39.134.11 pool.ntp.org. 1h30m IN A 80.85.129.25 pool.ntp.org. 1h30m IN A 80.254.168.209 pool.ntp.org. 1h30m IN A 81.174.128.183 pool.ntp.org. 1h30m IN A 130.60.7.43 pool.ntp.org. 1h30m IN A 130.60.7.44 pool.ntp.org. 1h30m IN A 193.140.151.9 pool.ntp.org. 1h30m IN A 202.49.159.9 pool.ntp.org. 1h30m IN A 209.162.205.202 pool.ntp.org. 1h30m IN A 209.204.172.153 pool.ntp.org. 1h30m IN A 212.13.201.101 pool.ntp.org. 1h30m IN A 217.125.14.244 pool.ntp.org. 1h30m IN A 217.127.32.90 pool.ntp.org. 1h30m IN A 217.127.249.18 -- suresh ramasubramanian suresh@outblaze.com gpg EDEDEFB9 manager, security and antispam operations, outblaze ltd
Suresh Ramasubramanian wrote:
;; ANSWER SECTION: pool.ntp.org. 1h30m IN A 64.44.160.38 pool.ntp.org. 1h30m IN A 65.39.134.11 pool.ntp.org. 1h30m IN A 80.85.129.25 pool.ntp.org. 1h30m IN A 80.254.168.209 pool.ntp.org. 1h30m IN A 81.174.128.183 pool.ntp.org. 1h30m IN A 130.60.7.43
Whoops, too early, my bad. Pete
participants (23)
-
Adrian Chadd -
bmanning＠vacation.karoshi.com -
C. Jon Larsen -
Charles Sprickman -
Crist Clark -
Eric A. Hall -
james edwards -
James Edwards
-
Jared Mauch -
Joel Jaeggli -
John Kristoff -
Kevin Oberman -
Michael Sinatra -
Mike Leber -
Pekka Savola -
Petri Helenius -
Randy Bush -
Robert E. Seastrom -
Simon Lockhart -
Stephen J. Wilcox -
Steven M. Bellovin -
Suresh Ramasubramanian -
Tony Li