Re: The future of src:ntp
If you use ntp, I would appreciate if you could test the transition to ntpsec. ntpsec 1.2.1+dfsg1-5 has been uploaded to experimental and cleared the NEW queue. Bernhard Schmidt suggested and I used 1:4.2.8p15+dfsg-2~$(DEB_VERSION_UPSTREAM_REVISION) as the version for the transitional packages. The first part (before the ~) is the current src:ntp version, but with the Debian revision bumped from 1 to 2. This allows for potential security or stable fix uploads to existing Debian releases, if needed. Barring bugs, I believe the next steps are: 1. Upload to unstable. 2. Request ftpmaster removal of src:ntp? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On Mon, 2022-01-24 at 08:08:16 +0100, Guillem Jover wrote: > On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > > On 1/19/22 15:04, Bernhard Schmidt wrote: > > > On 19.01.22 20:34, Richard Laager wrote: > > > > 2. I create transitional binary packages in src:ntpsec: > > > I got to thinking about this more. This won't work, because src:ntp is > > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of > > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's > > transitional bin:ntp package to be newer than src:ntp's bin:ntp package. > > Bumping the epoch to 2 here is completely gratuitous and can make a mess > for ntpsec *and* potentially ntp iff upstream got to be improved and we > wanted to reintroduce it in the future. > > > It might be technically possible to build a binary package with different > > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > > whether that's a good idea, especially compared to the alternatives. > > Yes, this is the recommended method, that has been used in the past, > and which is mentioned in the dpkg FAQ. You can set arbitrary versions > via dpkg-gencontrol (or indirectly via dh_gencontrol). To clarify, which seems I had included initially but removed while editing. If generating the transition packages from ntpsec, then you can set the binary versions, for example, to be something like: «1:$(ntp_upstream_version)+$(ntpsec_binary_full_version)» so you'd end up with something like: 1:4.2.8p15+dfsg+1.2.1+dfsg1-2 1:4.2.8p15+dfsg+1.2.1+dfsg1-3 1:4.2.8p15+dfsg+1.2.2+dfsg1-1 … and while ugly, it serves its intended purpose quite well w/o messing with epochs and potentially muddling any package's future. Thanks, Guillem
Re: The future of src:ntp
On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > On 1/19/22 15:04, Bernhard Schmidt wrote: > > On 19.01.22 20:34, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's > transitional bin:ntp package to be newer than src:ntp's bin:ntp package. Bumping the epoch to 2 here is completely gratuitous and can make a mess for ntpsec *and* potentially ntp iff upstream got to be improved and we wanted to reintroduce it in the future. > It might be technically possible to build a binary package with different > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. Yes, this is the recommended method, that has been used in the past, and which is mentioned in the dpkg FAQ. You can set arbitrary versions via dpkg-gencontrol (or indirectly via dh_gencontrol). Thanks, Guillem
Re: The future of src:ntp
Richard Laager wrote on 23/01/2022: > On 1/19/22 15:04, Bernhard Schmidt wrote: >> On 19.01.22 20:34, Richard Laager wrote: >>> 2. I create transitional binary packages in src:ntpsec: > > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch > (of 2, since ntp already has an epoch of 1) on ntpsec in order for > src:ntpsec's transitional bin:ntp package to be newer than src:ntp's > bin:ntp package. > > It might be technically possible to build a binary package with > different versioning, but even if it is: 1) I don't know how, One way it can be done is by creating d/changelog files which are specific to the binary package, e.g. debian/ntp.changelog debian/ntpdate.changelog (no idea if it can be a symlink) ... with their own version, different from the one in debian/changelog. Paride
Re: The future of src:ntp
On Jan 23, Richard Laager wrote: > It might be technically possible to build a binary package with different > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. I did it long ago, I think for kmod taking over module-init-tools: you just need to add an appropriate Version field to debian/control. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Sun, 23 Jan 2022 at 15:12:49 -0600, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's > transitional bin:ntp package to be newer than src:ntp's bin:ntp package. > > It might be technically possible to build a binary package with different > versioning It is. > but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. 1) something like this (untested) will give you ntpsec_1.2.1+dfsg1-2 and ntp_2:1.2.1+dfsg1-2 packages: override_dh_gencontrol: dh_gencontrol -pntp -- -v2:$(DEB_VERSION_UPSTREAM_REVISION) dh_gencontrol --remaining-packages 2) If you are going to build ntp.deb from src:ntpsec, then I think this is a lot better than adding an epoch to the whole source package (i.e. d/changelog) of src:ntpsec, because it can eventually go away (when the transitional package does). I'm not sure whether building transitional packages from src:ntpsec with this technique is better or worse than having a src:ntp that only builds transitional packages. smcv
Re: The future of src:ntp
On 1/19/22 15:04, Bernhard Schmidt wrote: On 19.01.22 20:34, Richard Laager wrote: 2. I create transitional binary packages in src:ntpsec: I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package. It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives. What do you think about the other approach of having src:ntp build the transitional packages? I think that looks like this: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. 2. You (or I adopt and) create transitional binary packages in src:ntp, as 1:4.2.8p15+dfsg-2, 1:4.2.8p15+fake, 1:4.2.8p15+transitional, 1:4.2.8p16~transitional, or something else > 1:4.2.8p15+dfsg-1, with an empty upstream tarball: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Upload that to experimental. People review. 4. Upload to unstable. 5. After bookworm releases, you (or I, if I adopted src:ntp) request removal of src:ntp. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
think we as the distro need to push either over systemd-timesyncd. For
people who don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for
people who don't care about NTP)? If so, can you elaborate?
Well, could you elaborate why you didn't write "chrony is fine for
people who don't care"?
Because that question is about changing the status quo, where
systemd-timesyncd is the default.
I fail to understand why you're having a
preference on systemd-timesyncd...
Let me separate the two scenarios:
A) Imagine we had no NTP support by default and we are considering
adding NTP support to the default install.
B) systemd-timesyncd is currently the default and we are discussing
whether it should be changed.
In both scenarios, I assume that most users don't particularly care
about their NTP daemon. They don't generally interact with it. They just
want their clock to be "accurate enough". (And for people who don't
care, "accurate enough" is pretty wide. If you need extremely precise
time, you presumably know that and thus care about things like NTP or
even PTP.) This is no different than other system components: some
people have preferences (sometimes strong ones) about certain
components, but essentially nobody cares about every single one.
In scenario A, any of chrony, ntp, ntpsec, or systemd-timesyncd will
achieve the desired objective of having an accurate enough clock by
default. So we would consider other things, for example:
One might say ntpsec > ntp, because ntpsec comes from the same history
(so has the same advantages) plus the codebase has been cleaned up
(which has security and maintainability advantages). Also, the ntp
maintainer wants to discontinue maintaining it.
One might say that chrony > {ntp, ntpsec, systemd-timesyncd?} because
chrony is more accurate. FWIW, I can't personally weigh in on that
argument, as I haven't researched it well enough myself.
One might say that systemd-timesyncd > {chrony, ntp, ntpsec} because
it's part of systemd, which we're already using by default.
One might say that {chrony, ntpsec} > systemd-timesyncd because they
support NTS. Of course, there are problems with configuring NTS by
default, as I mentioned.
These, and potentially other factors, would need to be weighed.
Different individuals might come to different conclusions.
In scenario B, it's the same calculation, PLUS we need to overcome the
inertia of the current default. The new default must be sufficiently
better to be worth the change.
Personally, my take is:
It's not practical to deploy NTS by default right now. If we had
multiple operators of geo-diverse, high-capacity, non-smeared (or
consistently smeared and a consensus that this was desirable by default)
NTS servers, that'd be different. So NTS is not currently a
consideration for the default.
systemd-timesyncd is good enough for people who don't particular care
about their NTP daemon. For people that do care, they are free to
install software of their choice, be that chrony or ntpsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: The future of src:ntp
On Thu, 20 Jan 2022 at 20:09:18 +0530, Pirate Praveen wrote: > Do we really need a dummy package for upgrades to work? Yes, we do need transitional packages. > Can't ntpsec binary package just add Provides: ntp (=$source:Version) ? No, apt won't automatically replace a real package "ntp" with a package that merely Provides: ntp during upgrades. (One way to think about this is: how would that work? If more than one package provided ntp, which one would be correct for apt to choose, and why?) smcv
Re: The future of src:ntp
2022, ജനുവരി 19 5:27:28 PM IST, Paride Legovini ൽ എഴുതി >Richard Laager wrote on 19/01/2022: >> On 1/18/22 11:21 AM, Paride Legovini wrote: >> > I'd prefer making ntp a dummy package depending on ntpsec rather than >> > having src:ntpsec takeover bin:ntp. >> >> If I understand correctly, you're suggesting src:ntp builds bin:ntp that >> is a dummy package which depends on ntpsec? > >That's what I had in mind, but the other option: > >> Another option would be to have src:ntpsec build the bin:ntp dummy >> package and remove src:ntp entirely. > >also looks sensible to me after all. No strong opinion. Do we really need a dummy package for upgrades to work? Can't ntpsec binary package just add Provides: ntp (=$source:Version) ? >Paride > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The future of src:ntp
On 1/19/22 20:34, Richard Laager wrote: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? Well, could you elaborate why you didn't write "chrony is fine for people who don't care"? I fail to understand why you're having a preference on systemd-timesyncd... Cheers, Thomas Goirand (zigo)
Re: The future of src:ntp
On Jan 19, Paride Legovini wrote: > That's what I had in mind, but the other option: > > > Another option would be to have src:ntpsec build the bin:ntp dummy > > package and remove src:ntp entirely. > > also looks sensible to me after all. No strong opinion. I think that this would be better since they are close enough that ntpsec can usually be a drop-in replacement. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
Bernhard Schmidt writes: > - Since NTS leverages X.509, how does it work with a broken clock on > boot that is ticking outside of the certificate validity period? I don't know how it is intended to work, but it seems pretty obvious that NTS certificate validation must ignore the validity period. If you have a validating DNS resolver with correct time, then you might replace it with DANE validation (i.e if the certificate matches the current DNS TLSA record then it is valid regardless of current time). But I don't know if you can make that a requirement. Bjørn
Re: The future of src:ntp
On 1/19/22 3:13 PM, Bernhard Schmidt wrote: I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration. +1 that promoting NTS is orthogonal. If the bigger problems below are solved, it's also theoretically possible to add NTS support to systemd-timesyncd. - AFAIK there is no pool.ntp.org (or similar) service only containing NTS enabled timesources yet. This is the most serious problem. As the world stands right now, we'd have to do something like use CloudFlare's NTS service (and only them). I don't know how it would work either, since you need to verify the peer with a standard X.509 certificate and you don't know the expected CN from a DNS RR NTS does referrals, so it is theoretically possible for the NTS server to hand you off to a pool of NTP servers, with which it is coordinating keys. AFAIK, nobody has implemented this yet, outside of maybe CloudFlare's internal thing (but I don't recall off the top of my head). - Since NTS leverages X.509, how does it work with a broken clock on boot that is ticking outside of the certificate validity period? This is a concern too. I did some brainstorming about this on the NTPsec list a couple years ago, but neither I nor anybody else has implemented this (nor do I have plans to do so myself): https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
* Richard Laager [220119 14:34]: > On 1/19/22 9:49 AM, Bernhard Schmidt wrote: > > AFAICT other than systemd-timesyncd being installed by default we don't > > have a "default" NTP daemon in Debian. > > I'm not sure how much more "default" it can be than installed by default. So > I'd say we do have a default: systemd-timesyncd. > > > So we should most probably decide on a "default" and have all of them > > changed to $newdefault | time-daemon > > +1, except that my position is we already have that answer: > systemd-timesyncd | time-daemon This is only appropriate if the package doesn't care which time daemon is installed. If the package depends on ntp because it uses one of the provided binaries in a script, replacing the dependency as you suggest would be inappropriate. A number of the packages mentioned by Bernhard depend specifically on ntp, so the reason for that must be determined for each individual package. ...Marvin
Re: The future of src:ntp
On 19.01.22 20:44, Stephan Seitz wrote: Am Mi, Jan 19, 2022 at 13:34:13 -0600 schrieb Richard Laager: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus Well, most people will use the default NTP server of the package and don’t have a NTP server in their network. And since Debian is trying to be as secure as possible, the default NTP server should be ntpsec with as much activated NTS entries as possible. I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration. I can think of two problems with running NTS enabled by default (I have checked neither problem against any documentation, so it might be a non-issue) - AFAIK there is no pool.ntp.org (or similar) service only containing NTS enabled timesources yet. I don't know how it would work either, since you need to verify the peer with a standard X.509 certificate and you don't know the expected CN from a DNS RR - Since NTS leverages X.509, how does it work with a broken clock on boot that is ticking outside of the certificate validity period? Bernhard
Re: The future of src:ntp
On 19.01.22 20:34, Richard Laager wrote: Hi Richard, +1, except that my position is we already have that answer: systemd-timesyncd | time-daemon As default both ntpsec and chrony are challengers. For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? I tend to agree in principle. systemd-timesyncd should be enough for most use cases. I think we can nowadays assume that most, if not all, systems do have some clock sync mechanism in place, either through the default installation of systemd-timesyncd together with systemd, or through manual installation. So the question is why those packages do set an explicit dependency on ntp or another time sync daemon in the first place. Is it obsolete because you could not expect a continously synced clocked at all in the past or does it need some property of a full-fledged NTP daemon? So the "MBF" would be to check the packages and, for most cases, drop these dependencies or change them to "systemd-timesyncd | time-daemon". Sure. How do we feel about this process then: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. Maybe upload this at this step, to start the NEW process. 2. I create transitional binary packages in src:ntpsec: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Get a review from you (Bernhard) if you're willing? 4. Upload. 5. Then Bernhard requests ftpmasters remove src:ntp. Is that how that works? Sounds good, I'd like to have a few more reviewers though. ntp is aged, but according to popcon the transition could affect ~25% of the Debian installations. Bernhard
Re: The future of src:ntp
Am Mi, Jan 19, 2022 at 13:34:13 -0600 schrieb Richard Laager: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus Well, most people will use the default NTP server of the package and don’t have a NTP server in their network. And since Debian is trying to be as secure as possible, the default NTP server should be ntpsec with as much activated NTS entries as possible. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: The future of src:ntp
On 1/19/22 9:49 AM, Bernhard Schmidt wrote: AFAICT other than systemd-timesyncd being installed by default we don't have a "default" NTP daemon in Debian. I'm not sure how much more "default" it can be than installed by default. So I'd say we do have a default: systemd-timesyncd. So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon +1, except that my position is we already have that answer: systemd-timesyncd | time-daemon As default both ntpsec and chrony are challengers. For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? And then there is the migration from src:ntp. I think only ntpsec would be an option here Agreed (as I stated already; just agreeing here again). sntp could depend on on the ntpdig package from #1003966, but it would probably need to carry a compatibility symlink Good point. ntpdate and ntp could be transitional packages on the ntpsec counterparts as well, but since ntpsec/ntpsec-ntpdate has Conflicts/Replaces on the src:ntp binary packages it needs coordination. For this reason building the transitional binaries from src:ntpsec would probably be easier. Sure. How do we feel about this process then: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. Maybe upload this at this step, to start the NEW process. 2. I create transitional binary packages in src:ntpsec: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Get a review from you (Bernhard) if you're willing? 4. Upload. 5. Then Bernhard requests ftpmasters remove src:ntp. Is that how that works? Can be done in any order: N. Mass bug filing on that list of packages, that they should use: Depends: systemd-timesyncd | time-daemon If we're going to promote chrony instead, then I think we need some more discussion and there would be more work, as it seems we should then replace systemd-timesyncd with chrony in default installs too. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
Hi, However, development for ntp.org is slow, upstream still using BitKeeper is cumbersome, and even the testsuite needs to be fixes on some architectures for new releases. Both ntpsec and chrony are (from my POV) the better alternatives now. To a point where I would rather use chrony for new deployments, but I'm shying away from not using my own work anymore for the lack of real-life testing. I could just step down as a maintainer/uploader and have the ntp packaging bitrot, but this would be a large disservice to our users (unless someone else continues to maintain it). I think another option would be to migrate to one of the alternatives for Bookworm. This has sparked even less controversy than I feared, so let's use the momentum. AFAICT other than systemd-timesyncd being installed by default we don't have a "default" NTP daemon in Debian. There are a few that depend on at least one implementation (on my Bullseye workstation) Package: bwctl-server Depends: ntp Package: lava Depends: ntp | ntpdate | chrony Package: openstack-cloud-services Depends: ntp Package: openstack-compute-node Depends: ntp Package: progress-linux-host Depends: ntp Package: freeipa-server Depends: chrony Package: ceph-base Recommends: chrony | time-daemon | ntp Package: radioclk Recommends: ntp (>= 1:4.2.2+dfsg-1) | ntpsec | chrony Package: debci Recommends: ntp | time-daemon Package: openafs-fileserver Recommends: ntp | time-daemon Package: slony1-2-bin Recommends: ntp | time-daemon So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon As default both ntpsec and chrony are challengers. Both support NTS. Both appear to be active upstream and in Debian. Chrony has a higher popcon (possibly due to things like the default installation in the cloud images) and is default in Fedora/RHEL land. Feedback on this list also seems to favour chrony. My personal preference would be slightly towards chrony as well. And then there is the migration from src:ntp. I think only ntpsec would be an option here, which should be 99% compatible with the existing configuration file. ntpsec even takes over the old ntp configuration when it replaces ntp already. I guess the conffile prompt would be fine during a dist-upgrade. For the actual migration, src:ntp currently builds 4 binary packages ntp ntp-doc ntpdate sntp ntp-doc could be an easy transitional package sntp could depend on on the ntpdig package from #1003966, but it would probably need to carry a compatibility symlink ntpdate and ntp could be transitional packages on the ntpsec counterparts as well, but since ntpsec/ntpsec-ntpdate has Conflicts/Replaces on the src:ntp binary packages it needs coordination. For this reason building the transitional binaries from src:ntpsec would probably be easier. Bernhard
Re: The future of src:ntp
Am 19.01.22 um 13:07 schrieb Marc Haber: On Tue, 18 Jan 2022 21:49:53 +0100, Michael Biebl wrote: Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client which is enabled by default) doesn't fit your needs, chrony is a great alternative. The Beef I have with chrony is that they just implemented the parts of the protocol that they wanted to. Most notably, ntp request packet type 6 is missing, making it impossible to remotely monitor a chrony server with the Monitoring Plugin check_ntp_peer. Who knows which crucial parts of the protocol they didn't bother to implement either? https://lwn.net/Articles/735211/ Would be interesting to see if ntpsec has improved significantly since then. At least back then, chrony was the clear winner (also by not supporting some (legacy) cruft). Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On Tue, 18 Jan 2022 21:49:53 +0100, Michael Biebl wrote: >Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client >which is enabled by default) doesn't fit your needs, chrony is a great >alternative. The Beef I have with chrony is that they just implemented the parts of the protocol that they wanted to. Most notably, ntp request packet type 6 is missing, making it impossible to remotely monitor a chrony server with the Monitoring Plugin check_ntp_peer. Who knows which crucial parts of the protocol they didn't bother to implement either? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: The future of src:ntp
Richard Laager wrote on 19/01/2022: > On 1/18/22 11:21 AM, Paride Legovini wrote: > > I'd prefer making ntp a dummy package depending on ntpsec rather than > > having src:ntpsec takeover bin:ntp. > > If I understand correctly, you're suggesting src:ntp builds bin:ntp that > is a dummy package which depends on ntpsec? That's what I had in mind, but the other option: > Another option would be to have src:ntpsec build the bin:ntp dummy > package and remove src:ntp entirely. also looks sensible to me after all. No strong opinion. Paride
Re: The future of src:ntp
Am Di, Jan 18, 2022 at 23:16:46 +0100 schrieb Marco d'Itri: I have no objections if somebody wants to work on packaging ntpsec, but I do not think that either ntp or ntpsec should be promoted over chrony nowadays. Besides from the fact that ntpsec is already packaged: Does chrony support NTS? If no, it should be clear which package should be promoted over the other. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: The future of src:ntp
[I'm the Debian ntpsec maintainer.] On 1/18/22 11:21 AM, Paride Legovini wrote: > I'd prefer making ntp a dummy package depending on ntpsec rather than > having src:ntpsec takeover bin:ntp. If I understand correctly, you're suggesting src:ntp builds bin:ntp that is a dummy package which depends on ntpsec? Another option would be to have src:ntpsec build the bin:ntp dummy package and remove src:ntp entirely. Either seems fine to me. I don't have a strong preference. I can implement whatever is necessary on the ntpsec side. And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate -> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug #1003966, sntp -> ntpsec-ntpdig. There are some differences. For example, ntp stores its configuration file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But bin:ntpsec's postinst already handles that transition. On 1/18/22 5:03 PM, Paride Legovini wrote: > bin:ntp has always been a specific NTP implementation, I think > it's OK if it's replaced by an almost compatible fork, less OK if a > completely different implementation is brought in instead. I'm biased here, but I agree. I think it makes the most sense to transition existing ntp installs to ntpsec, not chrony, as ntpsec is a drop-in replacement with a shared code history. This is my position even if we think that chrony should be the default for new installs. On that topic, I think the current default of systemd-timesyncd is fine. [1] When I was first packaging ntpsec, I was going to have it share as many paths, service names, etc. with ntp (as upstream NTPsec does). But this lead to issues with certain tooling (e.g. around init scripts) and ultimately I decided it was better to use a different namespace. This does mean that Debian ntpsec is patched and diverges a bit from upstream NTPsec. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
Marco d'Itri wrote on 18/01/2022: > On Jan 18, Michael Biebl wrote: > >> If "ntp" the binary package would become a transitional package that >> installs chrony, that'd be fine with me if that eases the transition. > I am not sure that this would be practical since they cannot share the > same configuration. > I have no objections if somebody wants to work on packaging ntpsec, but > I do not think that either ntp or ntpsec should be promoted over chrony > nowadays. But ntpsec is already packaged and actively maintained, which is why I propose making ntp a transitional package installing ntpsec. After all bin:ntp has always been a specific NTP implementation, I think it's OK if it's replaced by an almost compatible fork, less OK if a completely different implementation is brought in instead. Dropping ntp altogether will certainly surprise some users. Paride
Re: The future of src:ntp
On Jan 18, Michael Biebl wrote: > I think Fedora prefers chrony instead of ntpsec. Fedora even uses btrfs, so who cares. :-) The interesting point is that RHEL switched to chrony for RHEL 7. Also, I want to add that chrony is not just better as a client, but also as a NTP server. https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/ offers quite some insights. > If "ntp" the binary package would become a transitional package that > installs chrony, that'd be fine with me if that eases the transition. I am not sure that this would be practical since they cannot share the same configuration. I have no objections if somebody wants to work on packaging ntpsec, but I do not think that either ntp or ntpsec should be promoted over chrony nowadays. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
Am 18.01.22 um 19:44 schrieb Moritz Mühlenhoff: Bernhard Schmidt wrote: However, development for ntp.org is slow, upstream still using BitKeeper is cumbersome, and even the testsuite needs to be fixes on some architectures for new releases. Both ntpsec and chrony are (from my POV) the better alternatives now. To a point where I would rather use chrony for new deployments, but I'm shying away from not using my own work anymore for the lack of real-life testing. Agreed, I think we should simply remove src:ntp at this point. Fedora migrated existing installs to ntpsec it seems: (https://fedoraproject.org/wiki/Changes/NtpReplacement I think Fedora prefers chrony instead of ntpsec. Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client which is enabled by default) doesn't fit your needs, chrony is a great alternative. If "ntp" the binary package would become a transitional package that installs chrony, that'd be fine with me if that eases the transition. I'd also be ok if src:ntp would just be dropped and we document that in our release notes accordingly. OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
Bernhard Schmidt wrote: > However, development for ntp.org is slow, upstream still using BitKeeper > is cumbersome, and even the testsuite needs to be fixes on some > architectures for new releases. Both ntpsec and chrony are (from my POV) > the better alternatives now. To a point where I would rather use chrony > for new deployments, but I'm shying away from not using my own work > anymore for the lack of real-life testing. Agreed, I think we should simply remove src:ntp at this point. Fedora migrated existing installs to ntpsec it seems: (https://fedoraproject.org/wiki/Changes/NtpReplacement Cheers, Moritz
Re: The future of src:ntp
Bernhard Schmidt wrote on 17/01/2022: > ntpsec and ntp should be largely configuration compatible, so even a > takeover of the binary package names might be practical. I played a bit with ntpsec some time ago, I remember being very pleased with it, and I think it can very well replace ntp in Bookworm. The incompatible changes [1] are not blockers IMHO, provided that they're documented. I'd prefer making ntp a dummy package depending on ntpsec rather than having src:ntpsec takeover bin:ntp. A dummy package will allow us to easily switch back to ntp from ntp.org if needed, and to document the incompatible changes in NEWS.Debian. Paride [1] https://docs.ntpsec.org/latest/ntpsec.html#incompatible
Re: The future of src:ntp
On 1/17/22 21:13, Marco d'Itri wrote: On Jan 17, Bernhard Schmidt wrote: What do you think? chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough. You can definitely spend your time on something more fun and more useful. +1 "chronyc tracking" r0x! :) Thomas Goirand (zigo)
Re: The future of src:ntp
On Jan 17, Bernhard Schmidt wrote: > What do you think? chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough. You can definitely spend your time on something more fun and more useful. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Mon, Jan 17, 2022 at 05:01:10PM +0100, Bernhard Schmidt wrote: > I could just step down as a maintainer/uploader and have the ntp packaging > bitrot, but this would be a large disservice to our users (unless someone > else continues to maintain it). I think another option would be to migrate > to one of the alternatives for Bookworm. The cloud team has been installing chrony by default in the images we generate since stretch and it's been a good experience for us. I'd be happy to see it become the default distro-wide. noah signature.asc Description: PGP signature
Re: The future of src:ntp
On 17.01.22 17:01, Bernhard Schmidt wrote: a couple of years ago (in 2017) I stepped up to help bring src:ntp back in shape because I needed it for work. All uploads since that time have been made by me. An RFH bug had been open the whole time and just recently got the first message for five years, which made me remember my plan. Back then cleaning up the official ntp.org package in Debian was without alternatives, because ntpsec was not born yet and chrony did not have any traction in the Debian world (as far as I could tell). However, development for ntp.org is slow, upstream still using BitKeeper is cumbersome, and even the testsuite needs to be fixes on some architectures for new releases. Both ntpsec and chrony are (from my POV) the better alternatives now. To a point where I would rather use chrony for new deployments, but I'm shying away from not using my own work anymore for the lack of real-life testing. I could just step down as a maintainer/uploader and have the ntp packaging bitrot, but this would be a large disservice to our users (unless someone else continues to maintain it). I think another option would be to migrate to one of the alternatives for Bookworm. ntpsec and ntp should be largely configuration compatible, so even a takeover of the binary package names might be practical. What do you think? Sounds good to me. Without your useful email I wouldn't even have been aware of the situation, so your email has already the useful effect of me planing migrating to ntpsec. Thank you! *t
The future of src:ntp
Hi, a couple of years ago (in 2017) I stepped up to help bring src:ntp back in shape because I needed it for work. All uploads since that time have been made by me. An RFH bug had been open the whole time and just recently got the first message for five years, which made me remember my plan. Back then cleaning up the official ntp.org package in Debian was without alternatives, because ntpsec was not born yet and chrony did not have any traction in the Debian world (as far as I could tell). However, development for ntp.org is slow, upstream still using BitKeeper is cumbersome, and even the testsuite needs to be fixes on some architectures for new releases. Both ntpsec and chrony are (from my POV) the better alternatives now. To a point where I would rather use chrony for new deployments, but I'm shying away from not using my own work anymore for the lack of real-life testing. I could just step down as a maintainer/uploader and have the ntp packaging bitrot, but this would be a large disservice to our users (unless someone else continues to maintain it). I think another option would be to migrate to one of the alternatives for Bookworm. ntpsec and ntp should be largely configuration compatible, so even a takeover of the binary package names might be practical. What do you think? Bernhard
