login
Search
What is the most "efficient" and "secure" way to keep the clocks of servers on a network in sync? Because OpenNTPD was designed with security in mind from the start, I was thinking about using ntpd only on all systems. One system would get time from the NTP pool and all other servers on the network would sync to the local server. Is this the best way? Then I discovered timed. Does anybody use it? Is it as secure? What are the (dis)advantages/differences compared to ntpd? I was was reading timed(8) and it states the following: "One way to synchronize a group of machines is to use an NTP daemon to synchronize the clock of one machine to a distant standard or a radio receiver and -F hostname to tell its timed daemon to trust only itself." I assume that all the other machines on the network would run timed only? How do you guys keep your clocks in-sync? -pachl
I don't have the time or electrons to compile that list :) in short, there is about zero value in timed for new installs. It is pretty much obsolete. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Hello Clint, Tuesday, October 23, 2007, 5:42:47 AM, you wrote: CP> One system would get time from the NTP pool and all other servers on CP> the network would sync to the local server. You don't really need ntpd on all systems. One (timeserver) runs ntpd, and others use rdate, called from cron (once a day is usually enough). -- Best regards, Boris mailto:boris@twopoint.com
While your suggestion would work, it would also entail more work without adding benefit. Upon install, you get the question of whether you want to use ntpd. Starting with 4.2, it even asks for a specific NTP server. Using ntpd gets you better synchronisation without the need of setting something up with cron. Rdate will work, but the work developers put into (further integrating) ntpd makes rdate appear rather ... outdated. Cheers, Rogier -- If you don't know where you're going, any road will get you there.
Rdate provides a single valuable service: the ability to poll a device to see what time it thinks it is (ie. probing the health of my time servers). For everything else, i just let openntpd take care of it. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Good point; I should probably add that to my monitoring setup. Thanks for the suggestion, Rogier. -- If you don't know where you're going, any road will get you there.
Hello Rogier, Tuesday, October 23, 2007, 9:01:32 AM, you wrote: RK> While your suggestion would work, it would also entail more work RK> without adding benefit. Upon install, you get the question of whether RK> you want to use ntpd. Starting with 4.2, it even asks for a specific RK> NTP server. It's always better to don't run a demon if you don't have to. :) Talking about a "more work" - I don't think that someone avoiding small "after install" tuning like this should be taking care of any network besides his home one. ;) Anyway, for the last five years no version of OBSD (including 4.2) worked for me without tuning a kernel, so an extra line in a crontab is nothing. :) -- Best regards, Boris mailto:boris@twopoint.com
That sort of remark has often started endless debates. :) For me, trusting rdate to provide time or using ntpd for it is pretty much the same, but feel free to disagree. There are no risk-free activities. In my book, ntpd gets the job done with less administrative work and it's made by the same people I trust to provide me with a sensible and If you haven't already, it might be wise to track the issue and report it. Most of my things requiring post-install kernel config got fixed over the next release, so I'm a happy camper. Cheers, Rogier -- If you don't know where you're going, any road will get you there.
I hope nobody takes what you say seriously. Running rdate instead of ntpd like you describe is wrong for many reasons which have been stated over and over in the last few years. Please do not spread wrong information around, and do your homework before giving others advice on what you think is good sysadmin practice.
Hello Pierre-Yves, PYR> I hope nobody takes what you say seriously. Running rdate instead of PYR> ntpd like you describe is wrong for many reasons which have been stated PYR> over and over in the last few years. Please do not spread wrong PYR> information around, and do your homework before giving others advice PYR> on what you think is good sysadmin practice. The ntpd from OBSD is raw and lame yet. It takes days (!) to really synchronize, adjusting time and clock frequency back and forth (even if you start with -s) so it's too early to say that using it is "right". It will be "right" after it matures, gets more useful synchronization algorithm and it's own ntpdate (or a parameter to synchronize and exit). -- Best regards, Boris mailto:boris@twopoint.com
On Tue, Oct 23, 2007 at 12:05:58PM -0500, Boris Goldberg wrote:
| The ntpd from OBSD is raw and lame yet. It takes days (!) to really
| synchronize, adjusting time and clock frequency back and forth (even if you
| start with -s) so it's too early to say that using it is "right". It will
| be "right" after it matures, gets more useful synchronization algorithm and
| it's own ntpdate (or a parameter to synchronize and exit).
Without -s, you are right. Adjusting time will take a long time if
your clock is off by a large margin. Luckily, OpenNTPD starts if that
is the case, unlike some other ntp daemon. The adjusting of time and
clock frequency is to be somewhat expected with todays low quality
clockchips on peecee motherboards. However, I've found my clocks to
sync up pretty fast, no problems there as far as I can see.
And we dont need 'ntpdate'. Why would you synchronize and exit ? An
important thing about timekeeping is to provide monotonuously
incrementing time, making sure not to skip timepoints and even more
importantly, not to jump back in time. If there is a large adjustment
to be made, ntpd has -s which will sync it at boot (before other, time
sensitive, programs are run). This is the most important argument
against running rdate from a cron. And if you really, really need the
sync-and-exit behaviour of ntpdate, run rdate, it has the -n switch.
I think the synchronization algorithm in ntpd is pretty good as it is.
All my machines are in sync, they all agree on the same time when I
compare it. This is within second boundaries, yes. It has been said
before that if you need picosecond precision, then perhaps OpenNTPD is
maybe not for you (although I believe that using one of the newer time
sensors available in OpenBSD can bring pretty accurate time to your
machine too).
Cheers,
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
[demime 1.01d removed an attachment of type ...Hello Paul, Tuesday, October 23, 2007, 12:38:43 PM, you wrote: PdW> ... run rdate, it has the -n switch. Here we go! :D -- Best regards, Boris mailto:boris@twopoint.com
Blah blah blah. time1 and time2.srv.ualberta.ca are both running openntpd driven by nmea(4) sensors. As is my home workstation. They wibble around within a microsecond or two of the sensor's time, probably due to a) interrupt handling and b) temperature changes caused by the air conditioner or cats sleeping on the case. If you have some reasonable, well-designed suggestions on how to better discipline the clock, we're all ears. Other wise, quit babbling - openntpd is doing exactly what it's supposed to: be a simple, lightweight daemon for keeping your clocks "close enough". If that's not good enough for you, the ntp.org daemon is in ports. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
And my servers are in a windowless room under a lot of concrete and steel, so there's no good way to get GPS or radio data, and I'm using other time servers on the internet to sync. They keep time very well, on sparc64 and amd64, and both are in pool.ntp.org and score quite well. In fact, they compare favorably to servers running the more "heavyweight" ntp daemons. -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
That is a very interesting anecdote. That has got to make Henning proud; hell I'm proud of him. The amazing thing is that the ntpd binary on my i386 is only 34.4K. The ntpd binary (non-OpenNTPD) on my i386 FreeBSD media center is 263K, not to mention all of the other ntp* binaries, which bring total size to 426K. Plus, OpenNTPD has privilege separation!
Try statically linking them, and then look at the numbers again.
Well, I'm not going to do that, but I think I understand the point that
Theo is making.
(OpenBSD)
pachl@morpheus$ ldd /usr/sbin/ntpd
/usr/sbin/ntpd:
Start End Type Open Ref GrpRef Name
00000000 00000000 exe 1 0 0 /usr/sbin/ntpd
05c18000 25c4c000 rlib 0 1 0 /usr/lib/libc.so.40.3
0334b000 0334b000 rtld 0 1 0 /usr/libexec/ld.so
(FreeBSD)
pachl@htx$ ldd /usr/sbin/ntpd
/usr/sbin/ntpd:
libm.so.4 => /lib/libm.so.4 (0x280b0000)
libmd.so.3 => /lib/libmd.so.3 (0x280c9000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x280d6000)
libc.so.6 => /lib/libc.so.6 (0x281cd000)
There is one thing I really miss in OpenBSD's ntpd, and that is some way of asking the status. It need not be something like ntpq for "standard" ntpd. Sending it e.g SIGUSR1 so it would dump current servers, their status and ntpd's general status would be nice. When there is nothing for a while in the syslogs it gets tedious to find out if and what is going on with ntpd on OpenBSD... -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
While we are talking about ntpd: Is there hope of an update of the portable version? The debian port is still at 3.9... Best Martin PS: http://www.openntpd.org is also still at 3.9...
I can't nor want to do the portable, and the portable maintainer vanished. If you wanna do the work and be the -stable guy, pick ntpd due to exactly that. I'll fix it for 4.2 (if I don't forget again) -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
It's always better to not write a nonsense mail if you don't have to. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
This is a bad advice. If you want your machines to be synchronized, use ntpd. The bad advice given above will not synchronize your machines time.
that is bad advice. it is not only much more work to set up, it also doesn't remotely yield the same results. ntpd is much much better, since it doesn't rely on a single answer from soem server to set the clock, and because it adjusts the clock frequency over time. there is not much point in using rdate at all. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
From what I have read in this thread, it looks like only one guy prefers the old timed and rdate tools. A few are even telling him he is giving bad advice when promoting the usage of these tools. Henning mentioned that rdate and timed are pretty much useless and others have said that timed is obsolete. So why don't we remove them from the source tree? Last night when I was researching a way to sync my clocks I became confused as to what I should be using. This thread and Henning's OpenNTPD presentation at http://www.openbsd.org/papers/ntpd_sucon04/index.html definitely cleared things up and answered all my questions. Thanks to all that replied and Henning for leading the OpenNTPD project. -pachl
rdate has an ntp mode, that is useful for checking/monitoring/debugging ntp servers, so it'll stay. timed might indeed be a candidate for the Attic. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Hello Clint, Tuesday, October 23, 2007, 5:36:15 PM, you wrote: CP> From what I have read in this thread, it looks like only one guy CP> prefers the old timed and rdate tools. A few are even telling him he is CP> giving bad advice when promoting the usage of these tools. Henning CP> mentioned that rdate and timed are pretty much useless and others have CP> said that timed is obsolete. So why don't we remove them from the source CP> tree? I've never suggested (or mentioned) the timed. Of course I was talking about the "-n" mode of rdate (as a replacement to ntpdate like Paul de Weerd was suggesting in this thread). May be it makes sense to set "-ncv" as a default behavior of rdate, but there is should be a way to synchronize time without running a demon (don't understand why are people so aggressive about that) if you don't need up-to-second synchronization (in my case modern hardware goes less than a second off per day, and really old hardware - less than 10 seconds). -- Best regards, Boris mailto:boris@twopoint.com
On Wed, Oct 24, 2007 at 10:47:45AM -0500, Boris Goldberg wrote:
| May be it makes sense to set "-ncv" as a default behavior of rdate, but
| there is should be a way to synchronize time without running a demon (don't
| understand why are people so aggressive about that) if you don't need
| up-to-second synchronization (in my case modern hardware goes less than a
| second off per day, and really old hardware - less than 10 seconds).
The problem here is the jump in time. You repeat a second or more (if
you have to jump back) or skip some (if you jump forward). This may
not be a problem for you in particular, but is considered bad in
general.
Another issue is the fact that the server you're syncing to may not be
perfectly sync'ed itself. Or maybe there's some (assymmetrical) delay
in the network. This may make time on your machine somewhat off (this
isn't as big a problem as the previous, IMO).
And it's totally unneccessary, simply run ntpd and be done
with it. It solves all the problems with syncing every once in a
while, and as I indicated in my earlier mail, I don't see any of the
problems with running another daemon on my machines that you
described. It's small, uses proven security techniques and is still
reasonably simple.
But hey, if using rdate from a cron is your thing, dont let me get in
your way. I used to do this before we had OpenNTPD too, since I wasn't
really happy with ntp.org's daemon. If you're not really happy with
OpenNTPD, more power to you ! But I dont think it's a good practice to
do so, so suggesting it to others on this mailinglist will get you
some replies from opponents of your solution...
Cheers,
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
this is the key. rdate sets/skews the clock based on a single reply. which might get affected badly by network issues or whatever, or be spoofed, or... ntpd doesn't have that problem at all - last not least it never uses less than 8 packets to form a single update (just picking that one as example, there is more it can do, because it can develop thing over TIME instead of a single one-shot update & exit. and it fixes the clock frequency permanently using adjtick. rdate exactly. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
You don't understand the implications of changing the time of a computer at runtime. Time can be seen a continuum whos axis can be stretched or compressed or as series of time units with fixed length. In the first case the computer clock runs faster or slower, but no time unit is lost. In the second case the computer runs at constant speed, but time units can be lost. If either case is acceptable depends on the software that runs on the computer. A computer that controls an insulin pump probably should run at constant speed whereas a computer that does a task at a certain time should not skip time units. If a cronjob runs at 17:10 and at 17:00 your wise cronjob sets the time to 17:20, cron will not start that job. See?
bad example, since cron is the worst example you could pick, it is reasonably smart trying to deal with time jumps. but it DOES NOT in the first place using rdate -a. yet, ntpd is STILL a way better solution, but don't spread fud to push it either, it doesn't need that. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Hello Marc, MB> You don't understand the implications of changing the time of a computer MB> at runtime. I believe I do. :) There are pros and cons in the "demon" and in the "cron" schema. I decided to use cron and I know why. Every sysadmin/architect should make that decision for *his* systems (and know why). "Home users" should probably stay with the default (ntpd), but they are usually using Windows and cheap "hardware" firewalls anyway. ;) MB> If either case is acceptable depends on the software that runs on the MB> computer. Exactly. And I believe that "usual" case is not a cluster, monetary transaction server or traffic control system. MB> A computer that controls an insulin pump probably should run at MB> constant speed whereas a computer that does a task at a certain time MB> should not skip time units. Have you seen an insulin pump ran by OpenBSD system? ;) Give me some *real* examples (if you want to). MB> If a cronjob runs at 17:10 and at 17:00 your wise cronjob sets the time MB> to 17:20, cron will not start that job. First of all, this is not a *real* case again. I was talking about 10 seconds a day, not 20 minutes. If your *production* hardware goes 20 minutes off a day you will probably replace it (I believe, for new hardware it's a "warranty" case). Second of all, I've seen that behavior (with much smaller time adjustments) on SCO, but OpenBSD handles it pretty good - my cron doesn't repeat itself after adjusting time back. -- Best regards, Boris mailto:boris@twopoint.com
Boris Goldberg wrote: [snip] I hate beating a dead horse, but this one needs one more whack. OpenNTPD runs as a 'daemon,' yes, but it does so using privilege separation and other goodies. The network code runs as a normal user, isolated from other users. This is superior to running rdate AS ROOT from a cronjob. OpenNTPD does not open any TCP or UDP ports by default. It is true that rdate has about 63% less lines of code than ntpd and is older, and may have had more code audits performed; However, ntpd is new code, written with security in mind, runs as a normal user (privilege separated for the most part) and has superior time keeping ability. Your advice about not running a daemon if it's possible to do the task otherwise may be true with a (bloated) daemon such as ntp.org ntpd, however, with OpenNTPD the tables are turned. It is far safer to run the 'daemon' than to perform the task otherwise. That being said, it is up to the individual users to decide what to do. Hopefully this above explanation will help those who don't necessarily understand the risks of running programs as root vice daemons which execute code with proper separation of privileges. -Brian [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Hello Brian, Wednesday, October 24, 2007, 3:28:36 PM, you wrote: B> OpenNTPD runs as a 'daemon,' yes, but it does so using privilege B> separation and other goodies. The network code runs as a normal user, B> isolated from other users. This is superior to running rdate AS ROOT B> from a cronjob. OpenNTPD does not open any TCP or UDP ports by default. B> It is true that rdate has about 63% less lines of code than ntpd and is B> older, and may have had more code audits performed; However, ntpd is new B> code, written with security in mind, runs as a normal user (privilege B> separated for the most part) and has superior time keeping ability. B> Your advice about not running a daemon if it's possible to do the task B> otherwise may be true with a (bloated) daemon such as ntp.org ntpd, B> however, with OpenNTPD the tables are turned. It is far safer to run B> the 'daemon' than to perform the task otherwise. B> That being said, it is up to the individual users to decide what to do. B> Hopefully this above explanation will help those who don't necessarily B> understand the risks of running programs as root vice daemons which B> execute code with proper separation of privileges. Thank you very much for that (valuable) reply! BTW, this is an argument for making an OpenNTPD ntpdate tool or adding one_time_synchronization functionality into ntpd. :) -- Best regards, Boris mailto:boris@twopoint.com
no, it's not making an argument for a one-shot sync attempt in ntpd. that's what "rdate -na" is for. ntpd is for those who care that their clock remains close to an authoritative source of time. synchronization isn't a one-time thing. it's an ongoing process. a peecee isn't a terribly controlled environment - you have electrical noise, temperature changes, processor loads, interrupts ... all of which make it very difficult to keep time on a free-running clock. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
well, it is already there, it is called rdate. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
From ntpd(8):
-s Set the time immediately at startup if the local clock is off
by more than 180 seconds. Allows for a large time correc-
tion, eliminating the need to run rdate(8) before starting
ntpd.
Or is that not what you meant?
Just put ntpd_flags="-s" into /etc/rc.conf.local.
-- Mark
Hello Mark, Thursday, October 25, 2007, 4:13:09 PM, you wrote: MZ> From ntpd(8): MZ> -s Set the time immediately at startup if the local clock is off MZ> by more than 180 seconds. Allows for a large time correc- MZ> tion, eliminating the need to run rdate(8) before starting MZ> ntpd. MZ> Or is that not what you meant? MZ> Just put ntpd_flags="-s" into /etc/rc.conf.local. No, I mean synchronize_and_exit - like rdate -ncav, but more secure (with a privilege separation, like Brian explained above in a thread). -- Best regards, Boris mailto:boris@twopoint.com
ntpd -s; sleep 300; pkill ntpd Piotr Kapczuk