Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1028149: bookworm: ntp has been replaced by ntpsec
201 views
Skip to first unread message
Bernhard Schmidt
Jan 7, 2023, 3:00:04 PM1/7/23
to
Package: release-notes
Severity: minor
src:ntp (the ntp suite from ntp.org, including ntpd, ntpdate and sntp) has
been dropped from bookworm and superseded by src:ntpsec, the much improved fork
from ntpsec.org . Transitional packages are in place and for 99% of the users
this should have no impact, but it should be mentioned in the release notes.
Severity: minor
src:ntp (the ntp suite from ntp.org, including ntpd, ntpdate and sntp) has
been dropped from bookworm and superseded by src:ntpsec, the much improved fork
from ntpsec.org . Transitional packages are in place and for 99% of the users
this should have no impact, but it should be mentioned in the release notes.
Richard Lewis
Mar 23, 2023, 8:20:05 AM3/23/23
to
On Sat, 07 Jan 2023 20:53:22 +0100 Bernhard Schmidt <be...@debian.org> wrote:
> src:ntp (the ntp suite from ntp.org, including ntpd, ntpdate and sntp) has
> been dropped from bookworm and superseded by src:ntpsec, the much improved fork
> from ntpsec.org . Transitional packages are in place and for 99% of the users
> this should have no impact, but it should be mentioned in the release notes.
Presumably the release notes should also say that most people should
> src:ntp (the ntp suite from ntp.org, including ntpd, ntpdate and sntp) has
> been dropped from bookworm and superseded by src:ntpsec, the much improved fork
> from ntpsec.org . Transitional packages are in place and for 99% of the users
> this should have no impact, but it should be mentioned in the release notes.
consider systemd-timesyncd as this is priority:standard (since at
least buster, but i dont remember seeing this in release notes then)?
- i assume the idea is that if you dont have any special needs beyond
"set the clock" should use systemd-timesyncd, And people who need
extra features (like running their own ntp server) should install
ntpsec / chrony / opennntpd ?
Miroslav Lichvar
Mar 27, 2023, 5:20:05 AM3/27/23
to
On Thu, 23 Mar 2023 12:12:04 +0000 Richard Lewis <richard.le...@googlemail.com> wrote:
> Presumably the release notes should also say that most people should
> consider systemd-timesyncd as this is priority:standard (since at
> least buster, but i dont remember seeing this in release notes then)?
> - i assume the idea is that if you dont have any special needs beyond
> "set the clock" should use systemd-timesyncd, And people who need
> extra features (like running their own ntp server) should install
> ntpsec / chrony / opennntpd ?
Recommending timesyncd as an NTP client to replace ntpd would not be a
> Presumably the release notes should also say that most people should
> consider systemd-timesyncd as this is priority:standard (since at
> least buster, but i dont remember seeing this in release notes then)?
> - i assume the idea is that if you dont have any special needs beyond
> "set the clock" should use systemd-timesyncd, And people who need
> extra features (like running their own ntp server) should install
> ntpsec / chrony / opennntpd ?
good idea, especially if you consider the default configuration using
servers from pool.ntp.org.
The pool is very robust as a whole, but individual servers cannot be
relied on. They are run by volunteers. Some are well maintained, some
are not. Occasionally, servers drift away or step to a distant past or
future, e.g. due to GPS firmware bugs. The pool monitoring system
detects such servers and quickly removes them from the pool DNS, but
simple clients like timesyncd cannot recover from that. Once they got
the address from DNS, they will follow the server for as long as it
claims to be synchronized, no matter how wrong it is. A full-featured
NTP client is needed to detect and replace falsetickers. With
timesyncd the only option is to restart the service when you notice
the clock is wrong. I've seen many times users complaining about that
and getting this advice over the years.
timesyncd needs to be configured with a reliable server to work well.
Canonical maintains their own NTP servers and uses them by default in
Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
recommend a proper NTP client for a reliable service.
Antoine Beaupré
Mar 28, 2023, 11:20:04 AM3/28/23
to
systemd-timesyncd package, at the very least.
Right now this is completely empty:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd-timesyncd;dist=unstable
Now I agree that timesyncd might not be the best default NTP server: my
vote goes for chrony, personnally. But if we're going to object to it,
it should be at least properly documented in that package's bug list...
(To be fair, there *were* bugs reported agains the package before:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;package=systemd-timesyncd
... just not this specific one.)
a.
--
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
- Lofofora
Miroslav Lichvar
Mar 30, 2023, 3:50:05 AM3/30/23
to
On Tue, Mar 28, 2023 at 11:08:41AM -0400, Antoine Beaupré wrote:
> On 2023-03-27 11:15:20, Miroslav Lichvar wrote:
> > timesyncd needs to be configured with a reliable server to work well.
> > Canonical maintains their own NTP servers and uses them by default in
> > Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
> > recommend a proper NTP client for a reliable service.
>
> It seems to me this should be reported as a bug against the
> systemd-timesyncd package, at the very least.
As I understand it, it's a feature, not a bug. From
> On 2023-03-27 11:15:20, Miroslav Lichvar wrote:
> > timesyncd needs to be configured with a reliable server to work well.
> > Canonical maintains their own NTP servers and uses them by default in
> > Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
> > recommend a proper NTP client for a reliable service.
>
> It seems to me this should be reported as a bug against the
> systemd-timesyncd package, at the very least.
systemd-timesyncd(8):
The systemd-timesyncd service implements SNTP only. This minimalistic
service will step the system clock for large offsets or slowly adjust
it for smaller deltas. Complex use cases that require full NTP support
(and where SNTP is not sufficient) are not covered by
systemd-timesyncd.
Richard Lewis
Apr 15, 2023, 11:40:04 AM4/15/23
to
On Mon, 27 Mar 2023 11:15:20 +0200 Miroslav Lichvar <mlic...@gmail.com> wrote:
> On Thu, 23 Mar 2023 12:12:04 +0000 Richard Lewis <richard.le...@googlemail.com> wrote:
> > Presumably the release notes should also say that most people should
> > consider systemd-timesyncd as this is priority:standard (since at
> > least buster, but i dont remember seeing this in release notes then)?
> > - i assume the idea is that if you dont have any special needs beyond
> > "set the clock" should use systemd-timesyncd, And people who need
> > extra features (like running their own ntp server) should install
> > ntpsec / chrony / opennntpd ?
>
> Recommending timesyncd as an NTP client to replace ntpd would not be a
> good idea, especially if you consider the default configuration using
> servers from pool.ntp.org.
Isnt that effectively what debian has done by setting systemd-timesync
> On Thu, 23 Mar 2023 12:12:04 +0000 Richard Lewis <richard.le...@googlemail.com> wrote:
> > Presumably the release notes should also say that most people should
> > consider systemd-timesyncd as this is priority:standard (since at
> > least buster, but i dont remember seeing this in release notes then)?
> > - i assume the idea is that if you dont have any special needs beyond
> > "set the clock" should use systemd-timesyncd, And people who need
> > extra features (like running their own ntp server) should install
> > ntpsec / chrony / opennntpd ?
>
> Recommending timesyncd as an NTP client to replace ntpd would not be a
> good idea, especially if you consider the default configuration using
> servers from pool.ntp.org.
to "standard" priority?
if that's a bad decision, you should make the case to debian to change
it i would think?
(standard = installed by default, per debian policy)
> individual servers cannot be
> relied on. They are run by volunteers. Some are well maintained, some
> are not.
> timesyncd needs to be configured with a reliable server to work well.
> Canonical maintains their own NTP servers and uses them by default in
> Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
> recommend a proper NTP client for a reliable service.
if no-one else does, i can draft some text that says
- ntp is dropped (do we know why?). ntpsec is a direct replacement,
but there is also chrony
- and, if you do not need the strong guarantees of correct clock,
systemd-timesyncd is part of a standard debian installation
thoughts?
Paul Gevers
Apr 15, 2023, 3:10:05 PM4/15/23
to
Hi,
On 15-04-2023 17:31, Richard Lewis wrote:
> if no-one else does, i can draft some text that says
> - ntp is dropped (do we know why?). ntpsec is a direct replacement,
> but there is also chrony
> - and, if you do not need the strong guarantees of correct clock,
> systemd-timesyncd is part of a standard debian installation
>
> thoughts?
IMVHO that sounds like a plan.
Paul
On 15-04-2023 17:31, Richard Lewis wrote:
> if no-one else does, i can draft some text that says
> - ntp is dropped (do we know why?). ntpsec is a direct replacement,
> but there is also chrony
> - and, if you do not need the strong guarantees of correct clock,
> systemd-timesyncd is part of a standard debian installation
>
> thoughts?
Paul
Miroslav Lichvar
Apr 17, 2023, 4:40:04 AM4/17/23
to
On Sat, Apr 15, 2023 at 04:31:45PM +0100, Richard Lewis wrote:
> Isnt that effectively what debian has done by setting systemd-timesync
> to "standard" priority?
>
> if that's a bad decision, you should make the case to debian to change
> it i would think?
> (standard = installed by default, per debian policy)
Isn't it too late to fix this in bookworm?
> Isnt that effectively what debian has done by setting systemd-timesync
> to "standard" priority?
>
> if that's a bad decision, you should make the case to debian to change
> it i would think?
> (standard = installed by default, per debian policy)
I can provide data showing problems that some pool.ntp.org servers had
in the past, but as the upstream maintainer of chrony I'm probably not
the best person to be proposing changes in the priority of NTP
packages in Debian.
Another option would be to change the default servers of timesyncd,
e.g. to time.cloudflare.com, which is very reliable and has a great
coverage around the world from what I have seen so far. I suspect
people would not find it acceptable to rely on a commercial providers.
> if no-one else does, i can draft some text that says
> - ntp is dropped (do we know why?).
number of known unfixed security issues.
> ntpsec is a direct replacement,
> but there is also chrony
(Not as a server though.)
Richard Lewis
May 1, 2023, 9:20:04 AM5/1/23
to
control: tags -1 + patch
thanks
proposed text is at
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/156
(i included openntpd as an alternative but didn't try and explain the
differences - didn't think it was easy to do so clearly!)
thanks
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/156
(i included openntpd as an alternative but didn't try and explain the
differences - didn't think it was easy to do so clearly!)
Paul Gevers
May 7, 2023, 3:11:44 PM5/7/23
to
Control: close -1
Hi,
On 01-05-2023 15:12, Richard Lewis wrote:
> proposed text is at
> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/156
This was merged two weeks ago.
Paul
Hi,
On 01-05-2023 15:12, Richard Lewis wrote:
> proposed text is at
> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/156
Paul
0 new messages