From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] Ship NTP changes Date: Mon, 20 Jun 2022 21:48:33 +0000 Message-ID: <3ddc3d69-041b-b744-65ad-98aa2a857bf0@ipfire.org> In-Reply-To: <0C86EDE4-C200-4917-B65A-E57D642A0B5B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0805977872499223828==" List-Id: --===============0805977872499223828== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Jon, as promised, I merged your patch - Patchwork should have sent you a mail rega= rding this already (though sometimes it forgets about that, so it may be that it di= d not). > Hi Peter, >=20 > No worries! You answered within a day so I would never refer to that as a = "delay"! Yes, I was thinking more about the time your patch has been laying around her= e... :-) > FWIW - I could not find any of the my submitted patches here:=20 >=20 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dsummary >=20 > So I may just be looking in the wrong spot. No, this is basically the right spot to look at, but the overview page will o= nly show you the most recent commits made to the "master" branch. As development = happens on "next", you can either use https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3D= shortlog;h=3Drefs/heads/next to display the commit history of that branch, or display all commits authored= by you via=20 https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dsearch;h=3Drefs/heads/next;s= =3DJon+Murphy;st=3Dauthor. The latter will work across all branches in this Git repository. However, pat= ches you submitted to repositories outside ipfire-2.x will not be displayed here, = as Git works repository-oriented. > Also, none of these are urgent patches so they could all wait if things are= busy. Well, the NTP one is definitely good to be fixed, particularly on systems wit= h a poor RTC. Aside from that, my business currently stems mostly from non-IPFire-rela= ted commitments, which is why I am also more quiet in the community and on actual= development or bug fixing than I like. As things usually slow down over the summer a bit, I may be able to be more a= ctive then... Thanks, and best regards, Peter M=C3=BCller >=20 >=20 > Jon >=20 >> On Jun 20, 2022, at 4:55 AM, Peter M=C3=BCller wrote: >> >> Hello Jon, >> >> thanks for your mail. >> >> No, it did not (yet), as I kind of lost track about the status of this pat= ch, due to >> the amount of other stuff on my plate during the recent days. >> >> I will have a look at it again later today and amend it for Core Update 16= 9, if >> suitable. Apologies for the delay and the silence on my end. >> >> Thanks, and best regards, >> Peter M=C3=BCller >> >> >>> Peter, >>> Did this get approved for CU 169? >>> Or is it waiting for someone A-OK? >>> Jon >>>> On Jun 1, 2022, at 4:43 AM, Michael Tremer = wrote: >>>> >>>> Okay, that is soft enough for me. >>>> >>>>> On 31 May 2022, at 17:08, Jon Murphy wrote: >>>>> >>>>> Michael, >>>>> >>>>> (see below) >>>>> >>>>> >>>>>> On May 31, 2022, at 6:49 AM, Michael Tremer wrote: >>>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I would say that it is worth to work on this change, because it is sim= ple enough that we won=E2=80=99t need to spend a week. If it is going to be r= eplaced by chronie or something else, so be it - at least we had a problem fi= xed in the meantime. >>>>>> >>>>>>> On 30 May 2022, at 22:30, Jon Murphy wrote: >>>>>>> >>>>>>> Peter, >>>>>>> >>>>>>> (see below) >>>>>>> >>>>>>> >>>>>>>> On May 30, 2022, at 2:07 PM, Peter M=C3=BCller wrote: >>>>>>>> >>>>>>>> Hello Jon, >>>>>>>> >>>>>>>> thank you for submitting this. >>>>>>>> >>>>>>>> I consent with the intention of your patch, and believe this is the = cure (or at least >>>>>>>> a medicine) to insanely high clock drifts on some IPFire installatio= ns. Based on the >>>>>>>> forum activity, there used to be more of them, but my gut feeling is= that this issue >>>>>>>> never completely went away. >>>>>>> >>>>>>> I found one system that was off by 38 seconds per day=E2=80=A6 >>>>>> >>>>>> Okay. This is really bad though. Watches from a bubble gum machine kee= p time better than this. >>>>>> >>>>>>>> >>>>>>>> Nevertheless, I would like to await Arne's feedback on this: Particu= larly on ARM systems >>>>>>>> without a battery-backed RTC, IPFire comes up with a bogus time, and= I am not sure what >>>>>>>> the implications of this patch would be for such systems. >>>>>>> >>>>>>> `ntpd` added a feature that may help: >>>>>>> " -g no panicgate Allow the first adjustment to be Big" >>>>>>> >>>>>> >>>>>> Yes, the rationale here is that if the system comes up with Jan 1st, 1= 970, ntpd refuses to change that. I don=E2=80=99t know why. It does not seem = to make sense to me. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> The change I made to the initscript ntp file does not seem very ele= gant! But I was not sure of a better way too complete the same results. >>>>>>>>> >>>>>>>>>> + echo -e "server ${NTP_ADDR_1} prefer\nserver ${NTP_ADDR_2}" > /= etc/ntp/ntpInclude.conf >>>>>>>>> >>>>>>>>> Is this OK or does it belong in a different section of code. It ne= eds to be updated when the NTP Servers are changed or when the time.cgi (Time= Server) page is updated. >>>>>>>> >>>>>>>> Hmm, I would favour a better solution as well. That file might be po= pulated, and just >>>>>>>> overwriting it seems to be a bit brutal to me. :-) >>>>>>> >>>>>>> The `/etc/ntp/ntpInclude.conf` file is intentionally over written. I= was going to do a find & replace on the `config/ntp/ntp.conf` file, but this= seemed much simpler. Barbaric but simple! >>>>>> >>>>>> I agree that this isn=E2=80=99t the most elegant solution, but it isn= =E2=80=99t far off. >>>>>> >>>>>> I would give the file a different name, because =E2=80=9CntpInclude.co= nf=E2=80=9D does not really represent what it holds - which is the servers. >>>>>> >>>>>> Is it necessary to mark one of the servers with the =E2=80=9Cprefer=E2= =80=9D keyword? I am not sure if we should rank them. Shouldn=E2=80=99t the s= ystem choose the one that is most accurate? >>>>> >>>>> >>>>> If I understand prefer correctly this helps break the "tie". >>>>> prefer >>>>> Marks the server as preferred. All other things being equal, this host = will be chosen for synchronization among a set of correctly operating hosts. = See the "Mitigation Rules and the prefer Keyword" page for further informatio= n. >>>>> >>>>> Both servers could be marked "prefer" but that just means the preferenc= e becomes the first server in the config files. >>>>> The mitigation rules are designed to provide an intelligent selection o= f the system peer from among the selectable sources of different types. >>>>> >>>>> When used with the server or peer commands, the prefer option designate= s one or more sources as preferred over all others. While the rules do not fo= rbid it, it is usually not useful to designate more than one source as prefer= red; however, if more than one source is so designated, they are used in the = order specified in the configuration file. If the first one becomes unselecta= ble, the second one is considered and so forth. >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>>> -and- >>>>>>>>> >>>>>>>>> Is chrony going to replace NTP? If so, then the change below is no= t needed. >>>>>>>> >>>>>>>> I would really like so, but don't see that happen in IPFire 2.x soon= . For the medium >>>>>>>> term at least, you patch is by no means obsolete. >>>>>>>> >>>>>>>>> Please don't hurt me! >>>>>>>> >>>>>>>> Hope I did not. :-) >>>>>>>> >>>>>>> >>>>>>> No pain! :-) >>>>>>> >>>>>>> >>>>>>>> Thanks, and best regards, >>>>>>>> Peter M=C3=BCller >>>>>>>> >>>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 26, 2022, at 7:40 PM, Jon Murphy = wrote: >>>>>>>>>> >>>>>>>>>> - Device time more accurate. (e.g., +/- 10 seconds per day to < 1= 00 ms on some devices) >>>>>>>>>> ( I know we don't need the perfect time server ) >>>>>>>>>> - NTP and time will be accurate in manual mode (setting on Time Se= rver > NTP Configuration WebGUI) >>>>>>>>>> - Change NTP "prefer" server: >>>>>>>>>> - The current preferred NTP server in an Undisciplined Local Clock. >>>>>>>>>> - This is intended when no outside source of synchronized time is = available. >>>>>>>>>> - Change the "prefer" server from 127.127.1.0 to the Primary NTP s= erver specified on >>>>>>>>>> the Time Server > NTP Configuration WebGUI page. >>>>>>>>>> - Change allows the drift file (located at /etc/ntp/drift) to be p= opulated by ntpd. >>>>>>>>>> - The drift file is updated about once per hour which helps correc= t the device time. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Jon Murphy >>>>>>>>>> --- >>>>>>>>>> config/ntp/ntp.conf | 3 ++- >>>>>>>>>> src/initscripts/system/ntp | 2 ++ >>>>>>>>>> 2 files changed, 4 insertions(+), 1 deletion(-) >>>>>>>>>> >>>>>>>>>> diff --git a/config/ntp/ntp.conf b/config/ntp/ntp.conf >>>>>>>>>> index 9e393ca8e..bcaf2ee9e 100644 >>>>>>>>>> --- a/config/ntp/ntp.conf >>>>>>>>>> +++ b/config/ntp/ntp.conf >>>>>>>>>> @@ -1,6 +1,7 @@ >>>>>>>>>> disable monitor >>>>>>>>>> restrict default nomodify noquery >>>>>>>>>> restrict 127.0.0.1 >>>>>>>>>> -server 127.127.1.0 prefer >>>>>>>>>> +server 127.127.1.0 >>>>>>>>>> fudge 127.127.1.0 stratum 10 >>>>>>>>>> driftfile /etc/ntp/drift >>>>>>>>>> +includefile /etc/ntp/ntpInclude.conf >>>>>>>>>> diff --git a/src/initscripts/system/ntp b/src/initscripts/system/n= tp >>>>>>>>>> index 74b8bc86a..6c8174d25 100644 >>>>>>>>>> --- a/src/initscripts/system/ntp >>>>>>>>>> +++ b/src/initscripts/system/ntp >>>>>>>>>> @@ -52,6 +52,8 @@ case "$1" in >>>>>>>>>> fi >>>>>>>>>> fi >>>>>>>>>> >>>>>>>>>> + echo -e "server ${NTP_ADDR_1} prefer\nserver ${NTP_ADDR_2}" > /= etc/ntp/ntpInclude.conf >>>>>>>>>> + >>>>>>>>>> boot_mesg "Starting ntpd..." >>>>>>>>>> loadproc /usr/bin/ntpd -Ap /var/run/ntpd.pid >>>>>>>>>> ;; >>>>>>>>>> --=20 >>>>>>>>>> 2.30.2 >>>> >>>> >=20 >=20 --===============0805977872499223828==--