Hi,
On Tue, Mar 26, 2019 at 01:37:32PM -0700, Japheth Cleaver wrote:
I'm pushing for a release of 4.3.29 relatively soon. I've been trying to go through the backlog to identify un-applied patches, but I know there are some that I'm missing. If you have build fixes or runtime changes that have not yet been put in in 4.3.29 already (see: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.3.29/Changes), I'd appreciate if you could point them out.
One thing I noticed very recently which might be worth considering for 4.3.29:
xymond/etcfiles/xymonserver.cfg.DIST contains:
NTPDATEOPTS="-u -q -p 1"
If on the host running xymond, ntpdate from the ntpsec project is installed, then I just get the warning:
$ ntpdate -u -q -p 1 127.0.0.1 ntpdate: -p is no longer supported. 2019-04-11 19:22:28.524619 (-0200) +0.000002 +/- 0.000053 127.0.0.1 s4 no-leap $
So it might be an idea to drop the "-p 1" completely.
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
On 4/11/2019 9:30 AM, Axel Beckert wrote: . .. .
One thing I noticed very recently which might be worth considering for 4.3.29:
xymond/etcfiles/xymonserver.cfg.DIST contains:
NTPDATEOPTS="-u -q -p 1"
If on the host running xymond, ntpdate from the ntpsec project is installed, then I just get the warning:
$ ntpdate -u -q -p 1 127.0.0.1 ntpdate: -p is no longer supported. 2019-04-11 19:22:28.524619 (-0200) +0.000002 +/- 0.000053 127.0.0.1 s4 no-leap $
So it might be an idea to drop the "-p 1" completely.
That seems premature. The fact that ntpseq has dropped the parameter does not make it common or standard.
Dropping the "-p 1" option means ntpdate will attempt to collect more than one time sample before returning. In all man pages I've consulted the default value for "samples" is 4. Which means that each non-answering server will block that xymonnet queue for three additional seconds.
If you're using ntpsec, I don't think it is unreasonable to expect you to tweak that parameter on your own server. I don't think it is reasonable to build in a 4x longer delay for everyone.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
Hi John,
On Thu, Apr 11, 2019 at 10:33:51AM -0800, John Thurston wrote:
So it might be an idea to drop the "-p 1" completely.
That seems premature. The fact that ntpseq has dropped the parameter does not make it common or standard.
I expect ntpsec to become standard in the near future. See https://www.ntpsec.org/FAQ.html#_why_ntpsec why.
I though must admit, that we're still far away from there, at least in Debian: https://qa.debian.org/popcon-graph.php?packages=ntpsec%2Cntpsec-ntpdate%2Cnt...
But a decline of ntp installations is clearly visible in that graph (probably due to systemd also providing a time service, though).
And ntpsec is not yet available in a Debian Stable release, but will be in the upcoming Debian 10 release "buster".
And what also just became clear to me is that only the ntp-announce mailing list is dead with only a single mail since mid 2015 (c.f. http://lists.ntp.org/pipermail/announce/), but there seems to be at least about 1 security update per year: http://support.ntp.org/bin/view/Main/SecurityNotice
Maybe forking off ntpsec in 2015 was a kinda wakeup call, at least the amount of security fixes in 2016 was much high than in the years afterwards.
Dropping the "-p 1" option means ntpdate will attempt to collect more than one time sample before returning. In all man pages I've consulted the default value for "samples" is 4. Which means that each non-answering server will block that xymonnet queue for three additional seconds.
Yes, I am aware of that. This only has an impact on bigger setups with more than approx. 75 hosts to monitor. (And yes, I ran into exactly that issue previously when Xymon still had "-p 2" in there.)
If you're using ntpsec, I don't think it is unreasonable to expect you to tweak that parameter on your own server.
Yes, and that's what I did.
I nevertheless think it is as reasonable to expect you to tweak that parameter on your own server if you run a big setup. BTDT.
I don't think it is reasonable to build in a 4x longer delay for everyone.
I think Xymon should support both variants by using default settings which work with both implementations.
But maybe it should indeed do that only with a later release, when ntpsec gained more traction and is available in more stable distributions.
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
On 4/11/2019 12:12 PM, Axel Beckert wrote:
Hi John,
On Thu, Apr 11, 2019 at 10:33:51AM -0800, John Thurston wrote:
So it might be an idea to drop the "-p 1" completely. That seems premature. The fact that ntpseq has dropped the parameter does not make it common or standard. I expect ntpsec to become standard in the near future. See https://www.ntpsec.org/FAQ.html#_why_ntpsec why.
I though must admit, that we're still far away from there, at least in Debian: https://qa.debian.org/popcon-graph.php?packages=ntpsec%2Cntpsec-ntpdate%2Cnt...
But a decline of ntp installations is clearly visible in that graph (probably due to systemd also providing a time service, though).
And ntpsec is not yet available in a Debian Stable release, but will be in the upcoming Debian 10 release "buster".
And what also just became clear to me is that only the ntp-announce mailing list is dead with only a single mail since mid 2015 (c.f. http://lists.ntp.org/pipermail/announce/), but there seems to be at least about 1 security update per year: http://support.ntp.org/bin/view/Main/SecurityNotice
Maybe forking off ntpsec in 2015 was a kinda wakeup call, at least the amount of security fixes in 2016 was much high than in the years afterwards.
I don't think it is reasonable to build in a 4x longer delay for everyone. I think Xymon should support both variants by using default settings which work with both implementations.
But maybe it should indeed do that only with a later release, when ntpsec gained more traction and is available in more stable distributions.
Kind regards, Axel
It's definitely worth calling out in the notes somewhere for those platforms affected. F30 at least is still using legacy ntpdate.
Axel: Is that ending up in xymonnet.log, or is it elsewhere? And over STDERR?
-jc
Hi JC,
On Thu, Apr 11, 2019 at 01:07:11PM -0700, Japheth Cleaver wrote: [ntpsec's ntpdate dropped -p option]
Axel: Is that ending up in xymonnet.log, or is it elsewhere?
It's ending up in the report itself:
Thu Apr 11 18:40:41 2019 ntp NOT ok
Service ntp on kote5 is not OK : Service unavailable
Command: ntpdate -u -q -p 1 127.0.0.1 2>&1
ntpdate: -p is no longer supported. ntpdig: 127.0.0.1: Response dropped: stratum 0, probable KOD packet ntpdig: no eligible servers
(The last two lines are from a not fully started ntpd.)
And over STDERR?
Over STDERR, yes.
It also does seem to still exit with zero, so the only result is this warning (unrecognized by Xymon as such) in the report.
So I'd say, as of now, it's indeed safe to keep "-p 1" as it still works. The errors in the example (which actually triggered my mail initially) above were caused by other issues, i.e. the red state was legit. :-)
Later (i.e. with a fixed configuration and ntpd running for a while) it looked like this:
Thu Apr 11 18:59:44 2019 ntp ok
Service ntp on kote5 is OK (up)
Command: ntpdate -u -q 127.0.0.1 2>&1
2019-04-11 18:59:44.967208 (-0200) -0.000018 +/- 0.000064 127.0.0.1 s3 no-leap
In comparison to old ntpdate looks like this:
Fri Mar 29 13:42:50 2019 ntp ok
Service ntp on kote5 is OK (up)
Command: ntpdate -u -q -p 1 127.0.0.1 2>&1
server 127.0.0.1, stratum 2, offset -0.000018, delay 0.02570 29 Mar 13:42:53 ntpdate[25715]: adjust time server 127.0.0.1 offset -0.000018 sec
(No proper time format, no time zone, no year, duplicated information, multi-line, etc. :-)
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
It'd be nice to see support for chrony as an alternative to ntp (ntpdate or otherwise).
=G=
On Thu, Apr 11, 2019 at 5:18 PM Axel Beckert <abe at deuxchevaux.org> wrote:
Hi JC,
On Thu, Apr 11, 2019 at 01:07:11PM -0700, Japheth Cleaver wrote: [ntpsec's ntpdate dropped -p option]
Axel: Is that ending up in xymonnet.log, or is it elsewhere?
It's ending up in the report itself:
Thu Apr 11 18:40:41 2019 ntp NOT ok
Service ntp on kote5 is not OK : Service unavailable
Command: ntpdate -u -q -p 1 127.0.0.1 2>&1
ntpdate: -p is no longer supported. ntpdig: 127.0.0.1: Response dropped: stratum 0, probable KOD packet ntpdig: no eligible servers
(The last two lines are from a not fully started ntpd.)
And over STDERR?
Over STDERR, yes.
It also does seem to still exit with zero, so the only result is this warning (unrecognized by Xymon as such) in the report.
So I'd say, as of now, it's indeed safe to keep "-p 1" as it still works. The errors in the example (which actually triggered my mail initially) above were caused by other issues, i.e. the red state was legit. :-)
Later (i.e. with a fixed configuration and ntpd running for a while) it looked like this:
Thu Apr 11 18:59:44 2019 ntp ok
Service ntp on kote5 is OK (up)
Command: ntpdate -u -q 127.0.0.1 2>&1
2019-04-11 18:59:44.967208 (-0200) -0.000018 +/- 0.000064 127.0.0.1 s3 no-leap
In comparison to old ntpdate looks like this:
Fri Mar 29 13:42:50 2019 ntp ok
Service ntp on kote5 is OK (up)
Command: ntpdate -u -q -p 1 127.0.0.1 2>&1
server 127.0.0.1, stratum 2, offset -0.000018, delay 0.02570 29 Mar 13:42:53 ntpdate[25715]: adjust time server 127.0.0.1 offset -0.000018 sec
(No proper time format, no time zone, no year, duplicated information, multi-line, etc. :-)
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
participants (4)
-
abe＠deuxchevaux.org
-
cleaver＠terabithia.org
-
john.thurston＠alaska.gov
-
solitaryr＠gmail.com