In article David Van Cleef writes:
>Tony Fischer wrote:
>> In reading the FreeBSD handbook about time synchronization I'm not sure what
>> to put in my rc.conf file. If I understand correctly, NTPDate will only
>> synchronize when a machine is rebooted while NTPD will periodically check
>> the computer's time as long as it's on. So to cover all of my bases I'm
>> considering setting up an rc.conf file with the following entries...
>>
>> ntpdate_enable="YES"
>> ntpdate_flags="time.server.goes.here"
>> ntpd_enable="YES"
>> ntpd_flags="time.server.goes.here"
>>
>> I'm operating off of the assumption that the "ntpdate" entries will take
>> care of synching when I reboot the machine and "ntpd" will take over to
>> check periodically when the machines up. Is this overkill or even correct?
As already explained, the combination is a good idea - note though that
ntpd doesn't take time server names on the commandline (ntpd_flags), you
need to have a config file to specify those. The default ntpd_flags in
/etc/defaults/rc.conf has some parameters that *can* be used on the
commandline, then again those can also be set in the config file, and if
you need one anyway...
You really should set those parameters though, and set them to the
values in /etc/defaults/rc.conf (which are not the "builtin" defaults),
unless you have some very good reason to do otherwise - i.e. if you
overrride ntpd_flags in /etc/rc.conf, make sure they are either still
included in the setting or specified in the config file.
If you're really paranoid you could have '-g' on the ntpd commandline -
this doesn't have a config file equivalent AFAIK. It tells ntpd that
it's OK to do a huge correction once after startup, and would get your
system time back to sanity in the case where it both was *really* way
off initially, and the ntpdate run failed (e.g. because none of the time
servers could be reached). In that pathological case, ntpd will just
exit (after syslogging the problem) if -g isn't used.
>No, that's common practice. If you have a system clock that got WAY out
>of sync, running ntpdate at boot time will significantly reduce the
>amount of time for ntpdate to reach steady-state.
Yes - and perhaps even more importantly, it will avoid the stepping of
the system clock that will otherwise happen some time after boot if the
system clock is more than 128 ms off initially (and I guess most
non-NTP-geeks wouldn't consider 128 ms "WAY out of sync"
. Some things
will be very unhappy if the clock is stepped backwards.
It should perhaps also be noted that the developers of the "NTP
reference implementation" have been trying to get rid of ntpdate for
quite a while (it's "officially deprecated"), in favor of having ntpd do
also this initial "quick sync/step", or possibly using a simpler SNTP
client instead of ntpdate. Personally I can't say that I find either
alternative satisfactory - and in any case, even if the removal of
ntpdate from the reference implementation ever comes about, it doesn't
necessarily mean that it has to be removed from the FreeBSD base system.
--Per Hedeland
per.RemoveThis@hedeland.org
>> Stay informed about: NTPDate v. NTPD 
FAQ
Search
Profile
Private Messages
Log in
