reassign 731594 openntpd retitle 731594 Please make openntpd package priority standard thanks
On 7 December 2013 23:00, Thiemo Nagel <thiemo.na...@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 <bd...@gag.com> wrote: >> Dmitrijs Ledkovs <x...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
