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

[Dmitrijs Ledkovs]

reassign 731594 openntpd
retitle 731594 Please make openntpd package priority standard
thanks

On 7 December 2013 23:00, Thiemo Nagel <thiemo.nagel at gmail.com> wrote:
> Hi Bdale,
>
> thank you for your input! Using openntpd sounds very good. Who is the
> person to make the decision?
>

reassigning to openntpd package.

Regards,

dmitrijs.

> 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