- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page. - Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd. - The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org --- 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/ntp 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 ;;
Hello,
The change I made to the initscript ntp file does not seem very elegant! 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 needs to be updated when the NTP Servers are changed or when the time.cgi (Time Server) page is updated.
-and-
Is chrony going to replace NTP? If so, then the change below is not needed.
Please don't hurt me!
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
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 installations. Based on the forum activity, there used to be more of them, but my gut feeling is that this issue never completely went away.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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.
Hello,
The change I made to the initscript ntp file does not seem very elegant! 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.confIs this OK or does it belong in a different section of code. It needs 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 populated, and just overwriting it seems to be a bit brutal to me. :-)
-and-
Is chrony going to replace NTP? If so, then the change below is not 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. :-)
Thanks, and best regards, Peter Müller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Nevertheless, I would like to await Arne's feedback on this: Particularly 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"
Hello,
The change I made to the initscript ntp file does not seem very elegant! 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.confIs this OK or does it belong in a different section of code. It needs 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 populated, 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!
-and-
Is chrony going to replace NTP? If so, then the change below is not 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üller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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.confIs this OK or does it belong in a different section of code. It needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system choose the one that is most accurate?
-and-
Is chrony going to replace NTP? If so, then the change below is not 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üller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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.confIs this OK or does it belong in a different section of code. It needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
-and-
Is chrony going to replace NTP? If so, then the change below is not 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üller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy jcmurphy26@gmail.com wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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.confIs this OK or does it belong in a different section of code. It needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
-and-
Is chrony going to replace NTP? If so, then the change below is not 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üller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy jon.murphy@ipfire.org
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/ntp 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 ;;
-- 2.30.2
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 michael.tremer@ipfire.org wrote:
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy jcmurphy26@gmail.com wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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 needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
-and-
Is chrony going to replace NTP? If so, then the change below is not 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üller
Jon
> On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote: > > - Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on > the Time Server > NTP Configuration WebGUI page. > - Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd. > - The drift file is updated about once per hour which helps correct the device time. > > Signed-off-by: Jon Murphy jon.murphy@ipfire.org > --- > 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/ntp > 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 > ;; > -- > 2.30.2
Hello Jon,
thanks for your mail.
No, it did not (yet), as I kind of lost track about the status of this patch, 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 169, if suitable. Apologies for the delay and the silence on my end.
Thanks, and best regards, Peter Müller
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 michael.tremer@ipfire.org wrote:
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy jcmurphy26@gmail.com wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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 needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
> -and- > > Is chrony going to replace NTP? If so, then the change below is not 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üller
> > Jon > > >> On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote: >> >> - Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on >> the Time Server > NTP Configuration WebGUI page. >> - Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd. >> - The drift file is updated about once per hour which helps correct the device time. >> >> Signed-off-by: Jon Murphy jon.murphy@ipfire.org >> --- >> 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/ntp >> 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 >> ;; >> -- >> 2.30.2
Hi Peter,
No worries! You answered within a day so I would never refer to that as a "delay"!
FWIW - I could not find any of the my submitted patches here:
https://git.ipfire.org/?p=ipfire-2.x.git;a=summary https://git.ipfire.org/?p=ipfire-2.x.git;a=summary%60
So I may just be looking in the wrong spot.
Also, none of these are urgent patches so they could all wait if things are busy.
Jon
On Jun 20, 2022, at 4:55 AM, Peter Müller peter.mueller@ipfire.org wrote:
Hello Jon,
thanks for your mail.
No, it did not (yet), as I kind of lost track about the status of this patch, 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 169, if suitable. Apologies for the delay and the silence on my end.
Thanks, and best regards, Peter Müller
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 michael.tremer@ipfire.org wrote:
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy jcmurphy26@gmail.com wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote:
Peter,
(see below)
> On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
> > Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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 needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
> >> -and- >> >> Is chrony going to replace NTP? If so, then the change below is not 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üller > >> >> Jon >> >> >>> On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote: >>> >>> - Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on >>> the Time Server > NTP Configuration WebGUI page. >>> - Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd. >>> - The drift file is updated about once per hour which helps correct the device time. >>> >>> Signed-off-by: Jon Murphy jon.murphy@ipfire.org >>> --- >>> 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/ntp >>> 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 >>> ;; >>> -- >>> 2.30.2
Hello Jon,
as promised, I merged your patch - Patchwork should have sent you a mail regarding this already (though sometimes it forgets about that, so it may be that it did not).
Hi Peter,
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 here... :-)
FWIW - I could not find any of the my submitted patches here:
https://git.ipfire.org/?p=ipfire-2.x.git;a=summary https://git.ipfire.org/?p=ipfire-2.x.git;a=summary%60
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 only 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=ipfire-2.x.git;a=shortlog;h=refs/heads/next to display the commit history of that branch, or display all commits authored by you via https://git.ipfire.org/?p=ipfire-2.x.git;a=search;h=refs/heads/next;s=Jon+Mu....
The latter will work across all branches in this Git repository. However, patches 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 with a poor RTC. Aside from that, my business currently stems mostly from non-IPFire-related 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 active then...
Thanks, and best regards, Peter Müller
Jon
On Jun 20, 2022, at 4:55 AM, Peter Müller peter.mueller@ipfire.org wrote:
Hello Jon,
thanks for your mail.
No, it did not (yet), as I kind of lost track about the status of this patch, 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 169, if suitable. Apologies for the delay and the silence on my end.
Thanks, and best regards, Peter Müller
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 michael.tremer@ipfire.org wrote:
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy jcmurphy26@gmail.com wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
> On 30 May 2022, at 22:30, Jon Murphy jcmurphy26@gmail.com wrote: > > Peter, > > (see below) > > >> On May 30, 2022, at 2:07 PM, Peter Müller peter.mueller@ipfire.org 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 installations. 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…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
>> >> Nevertheless, I would like to await Arne's feedback on this: Particularly 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, 1970, ntpd refuses to change that. I don’t 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 elegant! 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 needs 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 populated, 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’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system 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 information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files. The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; 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 unselectable, the second one is considered and so forth.
>> >>> -and- >>> >>> Is chrony going to replace NTP? If so, then the change below is not 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üller >> >>> >>> Jon >>> >>> >>>> On May 26, 2022, at 7:40 PM, Jon Murphy jon.murphy@ipfire.org wrote: >>>> >>>> - Device time more accurate. (e.g., +/- 10 seconds per day to < 100 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 Server > 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 server specified on >>>> the Time Server > NTP Configuration WebGUI page. >>>> - Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd. >>>> - The drift file is updated about once per hour which helps correct the device time. >>>> >>>> Signed-off-by: Jon Murphy jon.murphy@ipfire.org >>>> --- >>>> 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/ntp >>>> 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 >>>> ;; >>>> -- >>>> 2.30.2
-
Jon Murphy -
Jon Murphy -
Michael Tremer -
Peter Müller