Time for a release?

Hal Murray halmurray at sonic.net
Tue Oct 31 09:28:36 UTC 2023


> What sort of testing did you have in mind?

Nothing in particular.  We haven't had a release in a while so I hope 
everybody will run git head and keep an eye out for glitches, make sure their 
favorite toys work as expected, double check log files, etc...

> Any specific doc cleanup?

Our doc always seems to need work.

On my list was making sure it mentioned mssntpinfo.  When I took a quick look 
at the man page, I got distracted with multicast/broadcast stuff.

> Here are the open issues the caught my eye:
> https://gitlab.com/NTPsec/ntpsec/-/issues/806

I think we should fix that.  Or at least try.  It sounds like a bug in 
ntp_control.  I just tried rv xxx for some xxx that was a reasonable assid.  
It didn't print any garbage.  Anybody got a handy test case?

Looking at the code...
It fills a buffer with 8 " %.2f", then calls the routine that prints that as 
name=value.
That won't work with spaces in there -- well, maybe it will, but it depends on 
what the parser in ntpq does.  I'd expect it to call the routine that prints 
it as name="value".  But I don't know what ntpq is doing...  We should print 
that stuff in a nice table.


> https://gitlab.com/NTPsec/ntpsec/-/issues/802 (is this resolved with our
> latest FIPS changes, and do we have an environment to test it?) 

I think it is fixed.  I don't think we have any way to test it.
Google says maybe we can get CentOS into FIPS mode, but maybe that only works 
for a particular version of CentOS...


> Are we able to use our ntpq to probe *cast fields on other
> ntp daemons that support it? If so, leave it in.

If you point ntpq -p at a Mills/classic box, it might be configred with a 
*cast slot or a peer slot.  If so, our ntpq would print something in the t 
column that you can't get from our servers.

Plan 1 is to move the stuff I don't like to a footnote.

Plan 2 is to fix the codes in the t column to be sensible for our use.  The 
old use is "s" for symmetric (aka peer) and "u" for unicast (aka normal 
server).  I'd like to see "s" for server and "p" for a pool host.  (That would 
make the footnote a bit bigger.)  But "p" is already used for the pool slot.  
We could change that to P or people could notice the POOL in the refid slot.



-- 
These are my opinions.  I hate spam.





More information about the devel mailing list