[pkg-ntp-maintainers] Bug#731594: Bug#731594: debian-installer: time synchronisation should be installed by default

[Thiemo Nagel]

Hi Bdale,

thank you for your input! Using openntpd sounds very good. Who is the
person to make the decision?

Best,
Thiemo

On Sat, Dec 7, 2013 at 6:22 PM, Bdale Garbee <bdale at gag.com> wrote:
> Dmitrijs Ledkovs <xnox at debian.org> writes:
>
>> Servers that rarely (re)configure network or boot, can also setup cron
>> to call to ntpdate or install an NTP client daemon when they are first
>> configured.
>
> FWIW, calling ntpdate from cron is a *horrible* idea.
>
> Since I agree that having time sync be a default part of a Debian
> installation would be a good idea, let me put a few thoughts down here
> and articulate what I think we should do.
>
> On a system like a server with at least one fixed-configuration network
> interface, unless the hardware clock has completely failed, the initial
> system time won't be grossly off, and just installing an ntp daemon is a
> better plan.  Even if the hardware clock *has* failed, Debian's ntp
> packaging uses the -g option to the daemon by default, so that once the
> daemon has talked to enough peers/servers to know what time it is, it
> will always slew the clock one time no matter how far off it is at
> daemon launch.
>
> On a client system like a notebook that only has dynamic network
> connectivity, and may not be on the net at all at boot, the best
> strategy seem to be to rely on the hardware clock at boot and only worry
> about network time sync when there's networking available.  For the past
> couple years, I've been using the openntpd package on my notebook, which
> has an if-up.d script that does a force-reload on each network interface
> up event, and in practice I've been quite happy with the results.
>
> I looked at chrony briefly several years ago and wasn't impressed, but
> I'm peripherally aware that it has been worked on quite a bit since then
> and probably deserves another look.  It claims to have been specifically
> written to handle well the case of a system that's not always on the net.
>
> Looking at the size of the packages, ntp is largest due to the inclusion
> of drivers for various reference clocks, etc.  Chrony is also a very
> large package, ntpdate is much larger than you'd expect, and openntpd is
> quite small by comparison to either ntp or chrony.  Here are the Size:
> and Installed-Size: values for each based on the current sid packages:
>
>       ntp      559578 1226
>       chrony   395400   743
>       ntpdate   81930   227
>       openntpd  64068   103
>
> I care a lot about the size of our base install, and openntpd seems to
> do everything I need just fine as far as I can tell.  So, without going
> off to study chrony which I really don't know at all, if I were making
> this decision, I'd be inclined to make openntpd standard, avoid ntpdate
> entirely, and assume users who really want to run stratum-1 NTP servers
> know how to install and optimally configure ntp.
>
> Bdale