From nobody Thu Dec 7 23:56:37 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SmWQb2lRJz53qYn for ; Thu, 7 Dec 2023 23:56:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SmWQX6txWz3f8n for ; Thu, 7 Dec 2023 23:56:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=SxwLc9Az; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::531) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-54c846da5e9so1408419a12.3 for ; Thu, 07 Dec 2023 15:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1701993410; x=1702598210; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=K3XJnWMiGl7Zc1oj7YbPBc112smZ/4tfDk1mtt6tHS8=; b=SxwLc9AzvmZIWb5+BsCUNBh2asaBBqNPq3w6UvcBUgQCYolg21YXgD1SXgVT/NwO4O g8Tw9CHky2KddVqhb31U3BfuHJ3YnC0ukMX7hgbTcMB3Qh6pQR3ZTaClQM72nlQZ7GT9 ezZMYxugGlvFEmRsk2ITQoUrCaeSmEb0FKk+II33+/I8KF4xzdksZhW/E6LGf4Aaj3Wb I9n1ya2l+kqzKoEYTwpiGOrWCIsji/iCdmyKv+AnMkd3c/e4Xo3DZ3P4rrCUnj9ap16v OLK0ks1LoIdUuzsXE5hg5RT1b5Fb1fqg5oCzMNnfB9Q7tjhTVrpT9CN8DqWMwfRqN4Ki lyTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701993410; x=1702598210; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=K3XJnWMiGl7Zc1oj7YbPBc112smZ/4tfDk1mtt6tHS8=; b=EWBxU/61dt9PmvRfhNF4nlvGmlznv90z61BI0sOhc4CaED/ijMI1jUJLqQdZo+EnmV OmiVENp9yiZw1G6qbECbi9e9v2JtfN4fCC4gJOjgFpzdTSQV0VcmncNGIUWuVD4sTwwN L+w+iOSW7/3acHmQQNzP2E/g4eR9so6GN5nwni4ZZqH7GEuFY3jFkNymh+wTgriGQvME 1475Iw/3BnWZpiXeerw0+N/Yp9JhPgPy3Ia35ha7WrLzS/Lda/i4i5BgSuy0niNThZQj FfAkdKlYgy36KopYzzwbDu8xvhQ4i3DloH6YN3PpUFiL2ksJAHXDa5y55jzR9OiDDI30 bjzg== X-Gm-Message-State: AOJu0Yy/R8DeeaAYnTdRKBeo4JxJujgFmMeJr09KrOyeC/0fLnT2Gj93 Zj1WvdYGMpfFksR1MnHQnfAJ5UVlDTBVeYB2+oX4zw== X-Google-Smtp-Source: AGHT+IF+PScJn+5N4Yvb6fG7vozH+zuLq0ngr7bh2tg4okcpqqbHH65LPUJTP4ImuaJYEgP5i1elDE5ikeOozvvTVeo= X-Received: by 2002:aa7:da4d:0:b0:54c:56ae:d4df with SMTP id w13-20020aa7da4d000000b0054c56aed4dfmr2820506eds.32.1701993409290; Thu, 07 Dec 2023 15:56:49 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202312070550.3B75o8WV066387@gitrepo.freebsd.org> <389AB29C-D5C0-4091-91ED-219F33351B35@freebsd.org> <20231207222716.obSthG6r@steffen%sdaoden.eu> In-Reply-To: <20231207222716.obSthG6r@steffen%sdaoden.eu> From: Warner Losh Date: Thu, 7 Dec 2023 16:56:37 -0700 Message-ID: Subject: Re: git: b1c95af45488 - main - rc.conf: correct $ntp_leapfile_sources To: Xin Li , Philip Paeps , Warner Losh , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="00000000000092355e060bf438c7" X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; DMARC_NA(0.00)[bsdimp.com] X-Rspamd-Queue-Id: 4SmWQX6txWz3f8n X-Spamd-Bar: - --00000000000092355e060bf438c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 7, 2023 at 3:27=E2=80=AFPM Steffen Nurpmeso wrote: > Xin Li wrote in > : > |On 2023-12-06 22:34, Philip Paeps wrote: > |> On 2023-12-07 14:26:05 (+0800), Warner Losh wrote: > |>> We should point to bipm > |>> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list since > they > |>> are > |>> the source of truth, no? > |> > |> I went for the IANA copy because data.iana.org is a much shorter and > |> trustworthy looking URL. And it's also where other operating systems > |> get their copies. > | > |My understanding is that IANA's copy is part of tzdata and it's only > |updated when a new set of zone data is released, so it's sometimes > |outdated. It is actually going to be outdated really soon by the way. > > But nothing will change. > It is only about the included end-of-life tag why there is > discussion at all. > The IANA TZ data is always updated as necessary, "early enough". > Yes. TZ data updates multiple times a year. The lead time on NIST/BIPM updating the file usually is within days or weeks after the new leap is announced. But ntpd can't possibly use it for about 5 months. TZ updates are plenty fast. The bigger problem is that we have to do a EN to get a new set of zone files. If we had a way to fetch them, we could just copy this file from the updated zone files. > Also the beasts are about to get rid of leap seconds until 2035 > (and they have beaten onto the Russians which' GLONASS is capable > to deal properly, as far as the discussion was, the fact it is not > earlier). Bets can be placed whether it will happen before > a possible occurring leap second, or not. (My bet is that they > run everything against the wall, and then run away yelling about > the evil leap second, after having missed to create an appropriate > environment to deal with the reached scientific level to keep us > truly within one second of our home planet, and his star. > O tempora, o mores. But that is off-topic.) > Yea, we're years away from the next leap second. And there's still a good chance we'll have at least one more. And there's also rumblings that leaps will stop before 2035 (that's the current absolute last date, and there's several folks that want to pull that in). What will happen for sure isn't well known... ntpv5 discussions have, at times, assumed there will be no more leap seconds and so ntpv5 needn't have anything to accommodate them. > |The IERS one is more up-to-date because they publish the bulletin. > > In general i think distribution of load is a good thing, and > i find it very unfriendly to put all the load onto some jealous > institute (if it is one) and its single server. > The FreeBSD project has an established set of mirrors, and, the > way i see the excessive use of installations on clowds and such, > for example for github actions which spawn dozens of OS > installations to test a commit (doh!). > We can skew the load in time by spreading all our users out over the few months we have if there's a load issue. > Btw PHK had a thrilling idea of DNS distributing leap ticks some > years ago, and he even started to host it. As it unfortunately > did not fly i did not track it further. > Would also be an idea for the FreeBSD project: simply download the > file ones, then place a DNS record that FreeBSD installations then > can query. DNSSEC is in place i think. > Yea, that's not a thing that's happening. It was an interesting idea, but hasn't been standardized and there's little to apetite to distribute this way. > |The bundled version was from NIST ftp, but fetching from ftp for every > |FreeBSD system out there was too scary for me. > | > |There may be some security / privacy concerns if we direct users to a > |place that we do not have control, by the way. > > Interesting aspect! > There might be, but this sounds somewhat speculative. What's the anticipate= d concerns? Warner --00000000000092355e060bf438c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 7, 2023 at 3:27=E2=80=AFP= M Steffen Nurpmeso <steffen@sdaode= n.eu> wrote:
Xin Li wrote in
=C2=A0<d75b041f-05f8-44c1-8de6-1fef89b7e537@delphij.net&g= t;:
=C2=A0|On 2023-12-06 22:34, Philip Paeps wrote:
=C2=A0|> On 2023-12-07 14:26:05 (+0800), Warner Losh wrote:
=C2=A0|>> We should point to bipm
=C2=A0|>> https://hpiers.obspm.fr/i= ers/bul/bulc/ntp/leap-seconds.list since they
=C2=A0|>> are
=C2=A0|>> the source of truth, no?
=C2=A0|>
=C2=A0|> I went for the IANA copy because data.iana.org is a much shorter= and
=C2=A0|> trustworthy looking URL.=C2=A0 And it's also where other op= erating systems
=C2=A0|> get their copies.
=C2=A0|
=C2=A0|My understanding is that IANA's copy is part of tzdata and it= 9;s only
=C2=A0|updated when a new set of zone data is released, so it's sometim= es
=C2=A0|outdated.=C2=A0 It is actually going to be outdated really soon by t= he way.

But nothing will change.
It is only about the included end-of-life tag why there is
discussion at all.
The IANA TZ data is always updated as necessary, "early enough".<= br>

Yes. TZ data updates multiple times a y= ear. The lead time on NIST/BIPM
updating the file usually is with= in days or weeks after the new leap is announced.
But ntpd can= 9;t possibly use it for about 5 months. TZ updates are plenty fast.

The bigger problem is that we have to do a EN to get a ne= w set of zone
files. If we had a way to fetch them, we could just= copy this file from the updated
zone files.
=C2=A0
Also the beasts are about to get rid of leap seconds until 2035
(and they have beaten onto the Russians which' GLONASS is capable
to deal properly, as far as the discussion was, the fact it is not
earlier).=C2=A0 Bets can be placed whether it will happen before
a possible occurring leap second, or not.=C2=A0 (My bet is that they
run everything against the wall, and then run away yelling about
the evil leap second, after having missed to create an appropriate
environment to deal with the reached scientific level to keep us
truly within one second of our home planet, and his star.
O tempora, o mores.=C2=A0 But that is off-topic.)

=
Yea, we're years away from the next leap second. And there&#= 39;s still
a good chance we'll have at least one more. And th= ere's also rumblings
that leaps will stop before 2035 (that&#= 39;s the current absolute last date,=C2=A0
and there's severa= l folks that want to pull that in). What will happen
for sure isn= 't well known...

ntpv5 discussions have, at ti= mes, assumed there will be no more leap
seconds and so ntpv5 need= n't have anything to accommodate them.
=C2=A0
=C2=A0|The IERS one is more up-to-date because they publish the bulletin.
In general i think distribution of load is a good thing, and
i find it very unfriendly to put all the load onto some jealous
institute (if it is one) and its single server.
The FreeBSD project has an established set of mirrors, and, the
way i see the excessive use of installations on clowds and such,
for example for github actions which spawn dozens of OS
installations to test a commit (doh!).

= We can skew the load in time by spreading all our users out over
= the few months we have if there's a load issue.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Btw PHK had a thrilling idea of DNS distributing leap ticks some
years ago, and he even started to host it.=C2=A0 As it unfortunately
did not fly i did not track it further.
Would also be an idea for the FreeBSD project: simply download the
file ones, then place a DNS record that FreeBSD installations then
can query.=C2=A0 DNSSEC is in place i think.

Yea, that's not a thing that's happening. It was an interesti= ng idea,
but hasn't been standardized and there's little = to apetite to distribute this way.
=C2=A0
=C2=A0|The bundled version was from NIST ftp, but fetching from ftp for eve= ry
=C2=A0|FreeBSD system out there was too scary for me.
=C2=A0|
=C2=A0|There may be some security / privacy concerns if we direct users to = a
=C2=A0|place that we do not have control, by the way.

Interesting aspect!

There might be, but= this sounds somewhat speculative. What's the anticipated
con= cerns?

Warner=C2=A0
--00000000000092355e060bf438c7--