Re: Mark Atwood, checking in, and requesting checkin
On Mon, Feb 29, 2016 at 07:23:07PM +, Mark Atwood wrote: > I notice that Coverty scan has found two warnings. Can someone open bugs for > them, and then fix them? https://gitlab.com/NTPsec/ntpsec/merge_requests/23 fixes the 2 Coverity warnings. Eric already pushed my fix to master. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp_io.c:process_routing_msgs on CentOS 6.8 -- errors with rtm
On Sun, May 29, 2016 at 01:24:28PM -0400, Jason Azze wrote: > Both i686 and x86_64 compiles fail on CentOS 6.8 with the same errors. > > [131/232] Compiling ntpd/ntp_io.c > ../../ntpd/ntp_io.c: In function ‘process_routing_msgs’: > ../../ntpd/ntp_io.c:4620: error: storage size of ‘rtm’ isn’t known > ../../ntpd/ntp_io.c:4659: error: invalid application of ‘sizeof’ to > incomplete type ‘struct rt_msghdr’ > ../../ntpd/ntp_io.c:4662: error: ‘RTM_VERSION’ undeclared (first use > in this function) > ../../ntpd/ntp_io.c:4662: error: (Each undeclared identifier is > reported only once > ../../ntpd/ntp_io.c:4662: error: for each function it appears in.) > ../../ntpd/ntp_io.c:4620: warning: unused variable ‘rtm’ > > Stock CentOS 6.8 uses the following... > Kernel: 2.6.32-642.el6.i686 > GCC: 4.4.7 > glibc: 2.12 > > Yes, Gary. I know these are ancient, but CentOS 6.8 was just released > last week. :-) > > I haven't been testing NTPsec on CentOS 6 for very long, so I don't > know if it ever built successfully. > > NTPsec builds fine on CentOS 7 (gcc 4.8.5) and Fedora 23 (gcc 5.3.1). Hey Jason, There's a patch attached to https://gitlab.com/NTPsec/ntpsec/issues/63 for should work for CentOS 6. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Would you please check libntp/systime.c
On Tue, Jun 07, 2016 at 11:52:09AM -0700, Hal Murray wrote: > > The initial symptom is a warning from clang 3.8.0 on a Raspberry Pi. > > ../../libntp/systime.c:460:37: warning: variable 'tvlast' is uninitialized > when > used here [-Wuninitialized] > > Why didn't any of the other tools notice this? The code isn't particularly > complicated. clang as shipped with Xcode 7.3 did notice and an issue was raised: https://gitlab.com/NTPsec/ntpsec/issues/51 Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Use of pool servers reveals unacceptable crash rate in async DNS
On Tue, Jun 28, 2016 at 07:26:39PM -0400, Eric S. Raymond wrote: > Hal Murray : > > I think you have extrapolated from some modern systems to our whole target > > environment. I don't remember any discussion supporting memlock not being > > interesting/important. > > There were actually two threads about this attached to memlock-related bug > reports in Classic. They initially thought memlocking was important, then > figured out it wasn't. Matt Selsky has been following those bugs; he and I > discussed the issue on #ntpsec. "rlimit memlock 0" using Classic causes ntpd to died after 3 minutes with this error 2016-06-29T00:13:21.903+00:00 host.example.com ntpd[27206]: libgcc_s.so.1 must be installed for pthread_cancel to work I've attached 15 minute graphs for "rlimit memlock -1" and "rlimit memlock 128" using Classic. Locking memory seems to result in more stable graphs over the time period that I was able to collect quickly. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Kernel PPS processing
On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote: > > Can you quantify the better? I would have expected identical... > > Did you look at the graph? > http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png > > I'm not sure why you would expect performance to be identical. Dave Mills > and crew went to a lot of effort to get code into various kernels, including > writing a RFC. I'd be very surprised if it wasn't a significant improvement. > > The question in my mind is have things changed enough since 1994 so that we > can do as well without that code in the kernel? We tested booting with "nohz=off intel_idle.max_cstate=0" and it made a difference in our production clocks. I can try to get graphs if needed. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Kernel PPS processing
On Wed, Jun 29, 2016 at 12:31:56PM -0700, Gary E. Miller wrote: > Yo Matthew! > > On Wed, 29 Jun 2016 14:55:23 -0400 > Matthew Selsky wrote: > > > On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote: > > > > Can you quantify the better? I would have expected identical... > > > > > > Did you look at the graph? > > > http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png > > Yeah, your 'No kernel' was aweful. If that is your baseline then you got > something really, really, wrong. The scale on the 'kernel PLL' was too > small to really tell, but I think I get the same on my RasPi's. > > Scroll down this: > > https://pi3.rellim.com/ > > Look at the 'offset of PPS'. It shows usually better than +/- 15 microSec. > Looks like PPS is usually close to a few microSec, but frequent 20 microSec > dealsy. I'm not sure what the daily spike is. > > That is KPPS on git head of ntpsec and gpsd. > > > We tested booting with "nohz=off intel_idle.max_cstate=0" and it made > > a difference in our production clocks. > > But not kernel PPS? I can see why the max_cstate might help, but if > the KPPS is interrupt driven I'm not sure why the nohz would help. > > Can you quantify the individual effects? And is that kernel PPS, KPPS > in ntpsec, or just PPS in ntpsec? We're using a GPS PCIe card with OCXO HQ with a daemon that writes to SHM and then ntpd reads from the SHM driver. Measuring on this server via ntpq -p we were seeing offsets of +/- 3us without either of these two kernel parameters. With nohz=off, the offsets were +/- 1us. With both kernel parameters we see offsets too small for ntpq -p to measure. This was all measured while running ntpd Classic. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Use of pool servers reveals unacceptable crash rate in async DNS
On Tue, Jun 28, 2016 at 11:39:16PM -0700, Hal Murray wrote: > > matthew.sel...@twosigma.com said: > > "rlimit memlock 0" using Classic causes ntpd to died after 3 minutes with > > this error 2016-06-29T00:13:21.903+00:00 host.example.com ntpd[27206]: > > libgcc_s.so.1 must be installed for pthread_cancel to work > > What version of Classic are you running? I though they had fixed that. This lab system happens to be running 4.2.7.0p368 Super-old, I know. I'll upgrade it over the weekend. > > I've attached 15 minute graphs for "rlimit memlock -1" and "rlimit memlock > > 128" using Classic. Locking memory seems to result in more stable graphs > > over the time period that I was able to collect quickly. > > What are you plotting? Y-axis is offset as measured by ntpq -p in microseconds. X-axis is time. And the 3 lines represent 3 different remote refclocks that my ntp client is pointing at. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Kernel PPS processing
On Wed, Jun 29, 2016 at 12:31:32PM -0700, Hal Murray wrote: > matthew.sel...@twosigma.com said: > > We tested booting with "nohz=off intel_idle.max_cstate=0" and it made a > > difference in our production clocks. > > Interesting. Thanks. > > How did you decide to go there? The "nohz=off" hint is mentioned in several PTP guides. "intel_idle.max_cstate=0" is mentioned in low-latency tuning guides and we decided to try it. > Did you try those 2 changes separately? Was that with PPS or just a typical > system? Yes, I reported on the results in the other reply in this thread. I have GPS PCIe card that I'm reading via the SHM driver. > Are you using the kernel from a distro or building your own? Rolling my own kernel. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Linux capabilites check broken on NetBSD
On Wed, Jul 06, 2016 at 09:20:54PM -0400, Eric S. Raymond wrote: > Hal Murray : > > On NetBSD: > > 07-06T15:42:17 ntpd[4940]: root can't be dropped due to missing > > capabilities. > > So don't do that, then. Drop root, I mean. Without some equivalent of Linux > or Solaris fine-grained privilege control, setting the clock won't work > afterwards. > > What has NetBSD been doing before this? NetBSD should be using the clockctl interface: http://netbsd.gw.com/cgi-bin/man-cgi?clockctl+4.i386+NetBSD-7.0 This was in Classic since 2002: https://gitlab.com/NTPsec/ntpsec/commit/b707b5e4b6168bca7e5e2553a551159e3da7ab5c Looks like we just need to add a check for sys/clockctl.h to waf and pylib/configure.py and the C library will do the right thing(tm) behind the scenes. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Kernel PLL graphs
On Mon, Aug 01, 2016 at 02:40:11AM -0700, Hal Murray wrote: > > There are two parts to PPS processing in the kernel. RFC 2783 describes an > API for capturing time stamps. RFC 1589 describes a PLL that lives in the > kernel. > > Most Linux distros don't support RFC 1589. The code is in the kernel, but it > doesn't work with the shipped kernels. It requires !NO_HZ, but most distros > prefer NO_HZ. > > I pulled over the sources and built my own kernel. > > Here are the before and after graphs: > http://users.megapathdsl.net/~hmurray/ntpsec/PPS-kernel.png > The data is from two separate days so this isn't a clean comparison. I don't > know what that machine was doing on either day. > > Here is a zoom in on the Kernel PLL day. > http://users.megapathdsl.net/~hmurray/ntpsec/PPS-kernel2.png > Note that the peak offset is less than a microsecond. > > > > We should see if we can get similar results on a Raspberry Pi. I haven't > tried building an ARM kernel. > > I think we should be able to run the PLL code outside the kernel. The PPS > time stamp is key. The PLL calculations don't need to be run in the kernel. > They need to be run soon after the PPS, but not interrupt level immediately. > The API has an option to wakeup on PPS. I don't know if it is implemented on > Linux. > > The no-PLL test was run at the default maxpoll of 6. I should try faster. I > also need a standard test load. > > I remember various FreeBSD-is-better type comments from many years ago. I > don't know if the PLL was working in Linux at the time. I should setup a > test case. Hey Hal, I'm using maxpoll of 1 on my stratum 1 servers. And I have !NO_HZ set. My offsets stay belong 1 microsecond as reported by ntpq. If we switched the units to nanoseconds, that might be interesting. I don't have !NO_HZ set on my stratum 2 servers, but I'm looking at the ramifications of that. I'm curious what your results are. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Kernel PLL graphs
On Wed, Aug 03, 2016 at 02:24:01PM -0700, Hal Murray wrote: > Time to make sure I've got the right number of negatives... "I have !NO_HZ > set" means you have unset NO_HZ which probably means you had to build your > own kernel. We build our own kernels and we boot our stratum 1 clocks with "nohz=off" > Do you have flag3 turned on? If so, the kernel does all the work and maxpoll > is essentially ignored. We do not have flag3 turned on. ntpd is reading the GPS via shared memory. The GPS comes with a lightweight daemon that reads /dev/refclock0 and stuffs the time in shared memory. > I though there was a min to maxpoll so I'm a bit surprised you could set it > to 1. We had a local patch to change the minimum value of minpoll/maxpoll to 1. Eric recently committed a similar patch upstream. https://gitlab.com/NTPsec/ntpsec/commit/a3047c7a375877436d422e04a138aace7ce1bd06 > At least for the effect I'm discussing, it only matters if you have a PPS. We're using PCIe GPS receiver cards. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible abuse from fetching the leap second file
On Mon, Aug 15, 2016 at 01:40:31PM -0700, Hal Murray wrote: > Besides, as Kurt Roeckx has pointed out, there is a much much better way. > Just use the copy that gets distributed by the time zone package. It's > already there on Debian and Ubuntu and Raspberian. This file is only on some distributions: Jessie has the file: https://packages.debian.org/jessie/all/tzdata/filelist Wheezy does not have the file: https://packages.debian.org/wheezy/all/tzdata/filelist Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Finding abusive NTP clients
On Sun, Nov 20, 2016 at 12:49:32AM +0800, Sanjeev Gupta wrote: > Hal, the 'mru' command no longer works. Was this removed intentionally? Sanjeev, I implemented command shortcuts per https://gitlab.com/NTPsec/ntpsec/issues/171 Classic ntpq allowed every command to be shorten, as long as it was unique. ntpsec ntpq now has that. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Monitoring busy/pool servers
On Wed, Dec 14, 2016 at 11:12:53AM -0800, Hal Murray wrote: > The mru sort options are also reversed in some options. I'm tracking this at https://gitlab.com/NTPsec/ntpsec/issues/208 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq doesn't work on NetBSD 6.1.5
On Thu, Dec 29, 2016 at 01:14:34AM -0800, Hal Murray wrote: > It does work on 7.0.2 > > The problem is that it can't find > Shared object "libpython2.7.so.1.0" not found I'm tracking this as https://gitlab.com/NTPsec/ntpsec/issues/220 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Multiple Python imports on one line
On Thu, Jan 05, 2017 at 08:00:59AM -0500, Eric S. Raymond wrote: > Therefor, you need not fix this one category of POP8 violation. If > you think you can rearrange imports to make groups of them more > coherent, go ahead and do that. I only fixed it because it was the last of it's kind and I wanted us to be consistent. Gary had already changed the multi-import-per-line in every other python file as part of his recent pep8 clean-up kick. Thanks, Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec leap second experience
On Sat, Jan 07, 2017 at 05:36:14PM -0500, Jason Azze wrote: > > Dec 31 18:59:59 harbormaster kernel: [14461.150782] Clock: inserting > leap second 23:59:60 UTC > Dec 31 18:59:59 harbormaster systemd[1]: Time has been changed > Dec 31 18:59:59 harbormaster systemd[2163]: Time has been changed > Dec 31 18:59:59 harbormaster systemd[1]: snapd.refresh.timer: Adding > 1h 27min 14.876839s random time. > Dec 31 18:59:59 harbormaster systemd[1]: apt-daily.timer: Adding 10h > 37min 25.745ms random time. > Dec 31 18:59:59 harbormaster systemd[1459]: Time has been changed > Dec 31 18:59:59 harbormaster ntpd[6653]: SHM: stale/bad receive time, > delay=-1s > Dec 31 19:00:47 harbormaster ntpd[6653]: kernel reports leap second has > occurred > Dec 31 19:00:47 harbormaster ntpd[6653]: kernel reports leap second has > occurred Jason, Do you know the source of the SHM error message in your logs? My classic ntpd stratum-1 clocks reported the "kernel reports leap second..." line twice (maybe a bug?), but there were no SHM errors. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 01:12:34PM -0800, Gary E. Miller wrote: > My RasPi's, and other servers, have about 1 micro Second jitter > between them. Anything that makes that even a bit worse is a show > stopper for me. > > OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon > then the daemon can tolerate 'some' jitter. Hey Gary, My stratum-1 clocks and stratum-2 clients also have ~1 micro second of jitter. Anything worse would also be a show-stopper for me. The current performance level means that I don't yet have to deploy PTP. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Mon, Jan 09, 2017 at 12:31:58PM -0800, Gary E. Miller wrote: > Agreed, my software PTP has roughly similar performance to my local > NTP with PPS. I do not have PTP aware network switches, or properly > working hardware PTP to know if that would help. Hey Gary, In my lab, with PTP-aware switches/network cards, but no tuning, I'm able to get 60 nanosecond offsets as measured by the offsets of the PPS-out on my grandmaster vs my PTP-client. I don't yet understand the failure modes and falseticker-like detection options for PTP to be comfortable deploying it yet, especially since 1 microsecond vs 60 nanoseconds isn't yet important for me. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium broken on NetBSD
On Fri, Jan 20, 2017 at 03:25:44AM -0800, Hal Murray wrote:
> I'm in way over my head here, but I blundered into something that is probably
> a good hint:
>
> /usr/pkg/lib/pkgconfig/libsodium.pc says:
> Libs: -Wl,-R${libdir} -L${libdir} -lsodium
>
> The equivalent on a Fedora box says:
> Libs: -L${libdir} -lsodium
Hey Hal,
If we use check_cfg() in waf instead of check_cc(), then it should use
pkg-config to read these files and correctly set LDFLAGS. I'll take a look
over the weekend unless someone else gets to it first.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Big endian success
On Mon, Jan 23, 2017 at 12:57:44PM -0800, Gary E. Miller wrote: > Yo Hal! > > On Sun, 22 Jan 2017 19:26:37 -0800 > Hal Murray wrote: > > > e...@thyrsus.com said: > > > Hm...can we get that one, or another G4 Mini, hooked up to the > > > build farm? > > > > I don't know anything about the build farm. Something used to send > > me email when I pushed changes, but that went silent a long time > > ago. What is the current status? Is there a web page describing it? > > Build farm is working fine. To add you host as a buildbot worker > you need to do some pip: pip install buildbot-worker > > If that works I just sent you a username and password. > > It doe snot use much bandwidth and works fine behind a NAT with no > extra setup. Hey Hal, If you get this going, please let me know so that I can retire my mips64 Debian wheezy buildbot worker running under QEMU. It's fairly slow and it didn't find any of the endianness problems that your PowerPC system detected. Or was that a 32-bit vs 64-bit CPU issue? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote: > > [From gitlab] > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should > > be no problem with using the ISC version unconditionally. https://docs.ntpsec.org/latest/ntpq.html's keytype lists "SHA". Does that mean sha0 or sha1? > I though I saw something about getting rid of --enable-crypto > > We currently require libsodium. Do we require libssl? If so, we can drop > the ISC crypto code. > > Does libsodium include SHA1 and friends? Do we still need libssl? We bundle a public domain implementation of MD5 and SHA1 (in the ISC code). OpenSSL/LibreSSL's libcrypto is only needed for ntp.keys that are using a digest that's neither MD5 nor SHA1. As 2 data points (yes, not enough), my users are using MD5 internally. I also spoke to Dr Levine from NIST yesterday and of his 500 customers that use authentication, all but 2 use MD5. The other 2 customers use SHA1. None of his customers use anything fancier. Can we make OpenSSL an optional dependency? I'd prefer that we always use the public domain code for MD5 and SHA1 and then use the OpenSSL code when available, but only for digest algorithms that are exclusive to them? That will allow us to have few #ifdef branches and be better able to test the code. And there's no need to add an extra build requirement when most users won't need it. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the story on buildbot?
On Thu, Jan 26, 2017 at 01:44:22AM -0800, Hal Murray wrote: > With configure --enable-leap-smear > it gets several warnings, then crashes with: > [104/105] Linking build/main/ntpd/ntpd > ntpd/ntp_timer.c.3.o: In function `check_leapsec': > ntp_timer.c:(.text+0x989): undefined reference to `DTOLFP' > collect2: error: ld returned 1 exit status I filed an issue at https://gitlab.com/NTPsec/ntpsec/issues/235, with a proposed fix that needs to be reviewed. > With configure --enable-mssntp > [ 92/105] Compiling ntpd/ntp_timer.c > ../../ntpd/ntp_signd.c: In function â?~send_via_ntp_signdâ?T: > ../../ntpd/ntp_signd.c:212:49: error: â?~xpkt0â?T undeclared (first use in > this function) > sendpkt(&rbufp->recv_srcadr, rbufp->dstadr, xpkt0, sendlen); > ^ > ../../ntpd/ntp_signd.c:212:49: note: each undeclared identifier is reported > only once for each function it appears in I fixed this as part of https://gitlab.com/NTPsec/ntpsec/issues/236 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
On Fri, Jan 27, 2017 at 03:57:36PM -0500, Daniel Franke wrote: > On 1/27/17, Eric S. Raymond wrote: > > Daniel Franke : > >> Where is this notion coming from that OpenSSL is going to drop MD5 or > >> SHA1 > >> support any time soon? That's inconceivable to me. > > > > I think it was either Achim Gratz or Kurt Roecx (I can't easily search to > > find > > out right now). Somebody serious, anyway. > > I just checked with an OpenSSL dev to make certain: dropping MD5 and > SHA1 from libcrypto is not even remotely under consideration. LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the build on OpenBSD 6.0 Where do we get SHA-0, aka "sha", keytype support from if we remove the in-tree public domain version? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
On Fri, Jan 27, 2017 at 05:20:48PM -0800, Gary E. Miller wrote: > Yo Matthew! > > On Fri, 27 Jan 2017 20:05:14 -0500 > Matthew Selsky wrote: > > > LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the > > build on OpenBSD 6.0 > > I can only find SHA1 in ntpsec. what am I missing? Hey Gary, See NID_sha in tests/libntp/ssl_init.c See SHA in docs/authentic.txt, docs/includes/auth-commands.txt, docs/includes/ntpq-body.txt, docs/ntpkeygen.txt, ntpclients/ntpq, ntpd/ntp.keys-man.txt, and pylib/packet.py Several of these files reference "sha" and "sha1", so it would seem that "sha" means "SHA-0". Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq peers formatting needs floating point for time slots.
On Fri, Feb 03, 2017 at 04:24:58AM -0800, Hal Murray wrote: > > I just pushed a fix. Please test. > > I bumped the width from 78 to 79. If that screws up, we should document a > test case. I'm assuming the output supports an 80 character line. > > There was a space-space before the delay column. I grabbed one of them. > Those 2 extra spaces let me change the width of the last 3 columns to 8 > characters. (1 was already 8, the other 2 were 7) Hey Hal, We need some backwards compatibility for ntp classic servers. Eg, the server has only microsecond precision. We need to avoid adding trailing zeros that are not actually significant. $ /usr/bin/ntpq -p ; ./ntpclients/ntpq -p remote refid st t when poll reach delay offset jitter == +clock1 .GPSs. 1 u12 3770.4800.000 0.000 *clock2 .GPSs. 1 u12 3770.0160.000 0.000 +clock3 .GPSs. 1 u12 3770.6660.002 0.001 remote refid st t when poll reach delay offset jitter = +clock1 .GPSs. 1 u-2 377 0.4800 -0. 0. *clock2 .GPSs. 1 u-2 377 0.0160 -0. 0. +clock3 .GPSs. 1 u-2 377 0.6660 0.0020 0.0010 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq peers formatting needs floating point for time slots.
On Sat, Feb 04, 2017 at 01:39:45AM -0800, Hal Murray wrote: > Good catch. Thanks. > > I just pushed a fix. It's the sort of kludge that Eric won't like but I > don't have a better idea. Hey Hal, Looks better. $ ntpq -pn ; ./ntpclients/ntpq -pn remote refid st t when poll reach delay offset jitter == +1.1.1.1 .GPSs. 1 u12 3770.480 -0.001 0.000 *2.2.2.2 .GPSs. 1 u12 3770.017 -0.001 0.000 +3.3.3.3 .GPSs. 1 u12 3770.6670.001 0.000 remote refid st t when poll reach delay offset jitter === +1.1.1.1 .GPSs. 1 u-2 3770.480 -0.0010.000 *2.2.2.2 .GPSs. 1 u-2 3770.017 -0.0010.000 +3.3.3.3 .GPSs. 1 u-2 3770.6670.0010.000 Is the jitter column header/data supposed to have moved 1 character to the right? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq peers formatting needs floating point for time slots.
On Wed, Feb 01, 2017 at 02:22:07PM -0800, Gary E. Miller wrote: > Yo Hal! > > On Wed, 01 Feb 2017 14:06:18 -0800 > Hal Murray wrote: > > > [I tried to submit an issue, but it was reject as spam.] > > Gitlab yesterday found spammers uing their submission system. Their > cure was worse than the disease... > > > Somebody recently changed things to print out a 4th digit. That made > > things worse. > > Eric did that. Also notice the LSB is always zero, which is clearly > also wrong. > > I need it because I can now make a RasPi 3 have an offset and jitter > consistently less than 0.001. Details here: > > https://blog.ntpsec.org/2017/02/01/heat-it-up.html Hey Gary/Hal, Does the shm driver need any modifications? # ntpshmmon ntpshmmon version 1 # Name Seen@ClockReal L Prec sample NTP0 1486408132.108158719 1486408132.107249611 1486408132.107249498 0 -20 sample NTP0 1486408133.108366587 1486408133.107396038 1486408133.107395887 0 -20 My GPS card comes with a daemon that writes to SHM and it looks like it has nanosecond precision. And maybe the card's daemon needs to be updated to change -20 to -30? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Scheduling a repository outage
/me too ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: More waf confusion
On Mon, Mar 27, 2017 at 12:37:59AM -0700, Hal Murray wrote:
Hey, Hal!
> Somebody recently removed some cruft from config.h
> That reminded me that there is more junk in there.
>
> So I took a handy config.h and grep-ed the source code, looking for symbols
> that were not used by any code.
>
> First hit:
> #define NTPSEC_VERSION_MAJOR 0 /* Major version number */
> #define NTPSEC_VERSION_MINOR 9 /* Minor version number */
> #define NTPSEC_VERSION_REV 7 /* Revision version number */
> They aren't used. NTPSEC_VERSION_STRING is used.
>
> They look like they might be needed some day, so I'm tempted to comment them
> out rather than delete them. (The similar names are used internally. I'm
> just talking about the code that puts them into config.h)
> #ctx.define("NTPSEC_VERSION_MAJOR", ctx.env.NTPSEC_VERSION_MAJOR,
> # comment="Major version number")
We may use this in the future, if we move away from autorevision.sh
> Here is the interesting one:
> ##ctx.check_cc(auto_add_header_name=True,
> ## header_name="stddef.h",
> ## mandatory=False)
>
> Nobody references HAVE_STDDEF_H, but commenting out that code breaks things.
> The test for HAVE_STRUCT_TIMEX_MODES uses size_t which isn't defined.
>
> Working test code has an "#include "
> I assume that drags in something that provides size_t and it's due to the
> "auto_add_header_name=True"
>
> Does anybody understand this area? Is there any simple way to get that
> header added to the test code without cluttering up config.h?
I added this in
https://gitlab.com/NTPsec/ntpsec/commit/c03b2de16be3b8a7a73f33d4c137a782cacc6b4d
to fix warnings in the checks for structure fields and size_t not being
defined on some platforms (like Linux) without this header. The comment says:
# waf's SNIP_FIELD should likely include this header itself
ctx.check_cc(header_name="stddef.h", auto_add_header_name=True, mandatory=False)
I asked on #waf and this was the best work-around that ita provided. See
https://github.com/waf-project/waf/issues/1905 for more information. Note, the
SNIP_FIELD checks are removed in waf-2.0 so we'll need to do this ourselves
when we switch from 1.9.x to 2.0
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 03:32:40PM +0200, Udo van den Heuvel via devel wrote:
> On 01-08-19 15:24, Udo van den Heuvel via devel wrote:
> > The script will exit with nonzero exit code, rendering the build failed.
>
> When trying to work around this in my spec file, I use:
> pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
> %{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
[..]
> QUESTION:
>
>
> Can someone please fix the /usr/sbin/ntpdig error? it makes the
> workround fail...
Our code works on both Python2 and Python3. Given F30's recent changes, we
switched our CI targets to explicitly point at python3.
If you're going to mangle the shebang as a package maintainer, feel free to
change all of the shebangs to explicit python3 on Fedora.
We're going to leave the shebangs alone in the source for maximum compatibility
with upstream PEP recommendations. See also packaging/packaging.adoc in the
repo.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > The build shows otherwise, else there would not be an error. > Or did I miss a step in the build process? See https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf for the change that we made to our CI targets. > Because the shebangs are not explicit the build fails. > At least that is what I understand from the errors. The debian package replaces the shebangs. You can see how at https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ You likely want to use the RPM macro that does the equivalent. I'm not familiar enough with RPM packaging to give more specific advice. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:31:52PM +0200, Udo van den Heuvel wrote: > On 01-08-19 16:27, Matthew Selsky wrote: > > On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > > > > See > > https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf > > for the change that we made to our CI targets. > > Sure, but why then is there a complaint from the Redhat Fedora tool(s)? I don't think the Fedora tools use anything related to our CI targets so our change should have neither helped, not harmed. > > The debian package replaces the shebangs. You can see how at > > https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ > > > > You likely want to use the RPM macro that does the equivalent. I'm not > > familiar enough with RPM packaging to give more specific advice. > > > We have a tool OK, cool. I'd be happy to review what you come up with if you want. And if you have suggestions for improving packaging/packaging.adoc, I'd be happy to hear them. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 05:02:58PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 16:39, Udo van den Heuvel via devel wrote:
> > The 1.1.6 code does not.
>
> The workaround now works when I use the pathfix.py line with this
> addition: %{buildroot}%{_sbindir}/*
>
> The whole SPEC then looks like the stuff below.
Awesome.
Can you change the BuildRequires to "python3-devel" and "python3-psutil"?
>
> How can we explain the existing shebangs?
And can you change the pathfix line to:
--snip--
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" .
--snip--
And move it to the %prep section instead of the %install section.
You may need to specifically use %{__python3} when you call "waf" in the 2
places in the %build section.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 07:19:02PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 19:00, Matthew Selsky wrote:
> > You may need to specifically use %{__python3} when you call "waf" in the 2
> > places in the %build section.
>
> So maybe not use --python=%{__python3} for waf?
"--python" should not need to be passed to waf.
> Without this the rpm builds OK.
Please change these:
CFLAGS="-O2" ./waf configure \
CFLAGS="-O2" ./waf build
DESTDIR=$RPM_BUILD_ROOT ./waf install
To:
%{__python3} ./waf configure \
%{__python3} ./waf build
DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
Let's see if that helps. waf sets a reasonable CFLAGS already.
Is there a git repo for your spec file work?
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Fri, Aug 02, 2019 at 06:31:34AM +0200, Udo van den Heuvel wrote: > Builds successfully after adapting the directories in the %files section. Excellent! > URL: http://www.ntpsec.org > Requires(post): systemd-units > Requires(preun): systemd-units > Requires(postun): systemd-units > BuildRequires: systemd-units > BuildRequires: bison gcc openssl-devel > BuildRequires:libcap-devel libseccomp-devel > BuildRequires: pps-tools-devel > BuildRequires: avahi-compat-libdns_sd-devel > BuildRequires: libcap openssl-libs pps-tools > BuildRequires: python-devel libxslt asciidoc m4 > BuildRequires: python-psutil asciidoc docbook-style-xsl wget > BuildRequires: /usr/bin/pathfix.py > BuildRequires: python3-devel python3-psutil You can likely remove python-devel and python-devel. Are your RPM packages published anywhere? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘NTS and ALPN
On Mon, Aug 19, 2019 at 06:33:52PM -0700, Gary E. Miller via devel wrote: > For some reason GitLab has not allowed me to merge from their web pages > for a few weeks. I have to merge manually... Hi Gary, Sounds like you ran into https://gitlab.com/gitlab-org/gitlab-ee/issues/12686 I'm not sure why Dan's fork of the repo doesn't have jobs enabled... Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Point release of NTPSec
On Fri, Aug 23, 2019 at 02:12:21PM -0400, Eric S. Raymond via devel wrote: > Sanjeev Gupta : > > We need a point release. Significant things that have happened recently: > > > > > >- The g and G suffixes > >- Removal of neoclock4x > >- Some doc changes > >- The ALPN change > > > > The last is critical, it throws into doubt all the interop we have with > > other NTS implementations. We need a tag to describe our implementation, > > so that we can test again. > > > > Please note only the first point above is captured in the NEWS file. > > I just added notes about the neoclock removal and the ALPN change. > > I concur that a oint release is indicated. Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since we have the ALPN compatiblity fix? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: gitlab testing broken for Fedora
On Sat, Aug 24, 2019 at 02:42:08AM -0700, Hal Murray via devel wrote: > Stage: build > Name: fedora-rawhide-refclocks-gpsd > Trace: GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora- > 31-x86_64 > Public key for glibc-common-2.30.9000-1.fc32.x86_64.rpm is not installed. > Failing package is: glibc-common-2.30.9000-1.fc32.x86_64 > GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_ > 64 > Public key for glibc-minimal-langpack-2.30.9000-1.fc32.x86_64.rpm is not > installed. Failing package is: glibc-minimal-langpack-2.30.9000-1.fc32.x86_64 > GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_ > 64 > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: GPG check FAILED > section_end:1566637579:build_script > [0Ksection_start:1566637579:after_script > [0Ksection_end:1566637580:after_script > [0Ksection_start:1566637580:upload_artifacts_on_failure > [0Ksection_end:1566637582:upload_artifacts_on_failure > [0K[31;1mERROR: Job failed: exit code 1 > [0;m Likely related to https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/TNH7RJCWIILV5VYT3N3IA3VZQIOFNZ53/ Fedora seems to have fixed their repos and our Rawhide builds are succeeding again. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: %m, #614
On Mon, Aug 26, 2019 at 04:55:48PM -0700, Gary E. Miller via devel wrote: > _GNU_SOURCE should not always be defined, but it does need to be defined > in certain cases. For example, on glibc < 2.10, you need to define > it to get strnlen() and struct ifreq. > > From glibc 2.10, you instead need _POSIX_C_SOURCE >= 200809L glibc 2.10 was released 2009-05-17. Do we still need to support it? Or can add a fatal waf error for glibc < 2.10 and then use the more modern symbols? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: waf checking - fail on warnings?
On Mon, Aug 26, 2019 at 10:51:58PM -0700, Hal Murray via devel wrote: > > A relatively quick search suggests mandatory=True as an argument. > > That makes waf fail if the code chunk doesn't work. You want "mandatory=False" since this is a probe, not a requirement. And you want to pass "-Werror" (I'm not certain how off the top of my head) to the compiler so that warnings are fatal. waf sees the compiler exit zero with or without warnings, so they look the same. > I'm trying to make the code chunk not-work if it gets a warning, but then let > waf put a comment in config.h to indicate that a feature test didn't work > rather than put a #define to indicate that it did work. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Warnings on OSX
On Fri, Aug 30, 2019 at 08:01:59PM -0700, Fred Wright via devel wrote: > > On Thu, 29 Aug 2019, Gary E. Miller via devel wrote: > > > Warnings on OSX: > > > > [ 73/131] Compiling libntp/ntp_calendar.c > > ../../ntpd/ntp_control.c:2612:27: warning: format specifies type 'unsigned > > short' but the argument has type 'unsigned int' [-Wformat] > >socktoa(rmt_addr), (unsigned)SRCPORT(rmt_addr)); > > ^~~ > > 1 warning generated. > > > > > > [106/131] Compiling ntpd/ntp_dns.c > > ../../ntpd/refclock_gpsd.c:2118:6: warning: implicit declaration of > > function 'strlcpy' is invalid in C99 [-Wimplicit-function-declaration] > >strlcpy(pp->a_lastcode, tc, sizeof(pp->a_lastcode)); > >^ > > ../../ntpd/refclock_gpsd.c:2118:6: warning: this function declaration is > > not a prototype [-Wstrict-prototypes] > > 2 warnings generated. > > > > Anyone want to fix them? > > The second one, which was present on FreeBSD as well, seems to have been > caused by the definition of _XOPEN_SOURCE in refclock_gpsd.c. And in spite > of what the comment says, this definition does *not* seem to be needed to > get strptime(). So simply removing it gets rid of the warning, and doesn't > break anything AFAICT. https://linux.die.net/man/3/strptime says: "This function is available since libc 4.6.8. Linux libc4 and libc5 includes define the prototype unconditionally; glibc2 includes provide a prototype only when _XOPEN_SOURCE or _GNU_SOURCE are defined." Maybe that man page out of date? /usr/include/time.h on my Debian Stretch system (glibc 2.24) has: # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime (const char *__restrict __s, const char *__restrict __fmt, struct tm *__tp) __THROW; # endif _GNU_SOURCE implies _XOPEN_SOURCE... So we need _XOPEN_SOURCE set (or something that implies it) somewhere upstream to get this prototype on newer glibc versions. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'ntpq -c ":config"' does not work (it probably never did)
On Mon, Sep 09, 2019 at 08:46:26AM -0700, James Browning via devel wrote: >While working on a script, I stumbled across this issue. the cmd.Cmd >class does not call its precmd function from its onecmd function in >either Python 2.7 or 3.6. I see several possible paths forward. > >1. Ignore the issue and hope it goes away. >2. Report it upstream. >3. Change over to hot_config option exclusively. >4. Add a wrapper to onecmd that fixes things. >5. More extensive fixes to cmd.Cmd. >6. Change to a new command-line interpreter. >7. Another path I am not even considering. > >I would advocate for the wrapper or changing to hot_config as the least >not good options at this time. Ignoring it stacks up technical debt for >later. Upstream would probably say it works as intended. Changing to a >new interpreter would throw away all the good work on this one. More >extensive work is possible but probably beyond my capabilities. Yes, please talk to upstream and see what they recommend. And this change should be documented in our incompatible changes list until we have a compatible function (or we decide to leave the feature out) Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Sun, Sep 15, 2019 at 06:18:47PM -0700, Hal Murray via devel wrote: > > There are various #ifdefs testing RLIMIT_MEMLOCK and friends > > The Linux man page for setrlimit says: >getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. > So I think we can assume it exists and remove the #ifdefs. > > Any reason not to? getrlimit()/setrlimit() are part of POSIX, but RLIMIT_MEMLOCK is not. This symbol is Linux/BSD-specific. Can you partially revert https://gitlab.com/NTPsec/ntpsec/commit/fb0c11c9db45709448383d1963b4cdf72a442f55#f4db43d91d9d4fe0fe143a20b21c2b3cd3a01a15_3635_3625 and https://gitlab.com/NTPsec/ntpsec/commit/36128757fbb6613fc4cea2705cc3717fbd7dc7fb? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 08:42:18PM -0700, Hal Murray wrote:
> > Can you partially revert ...
>
> I thought I had fixed it. Have you done a recent pull? Is the current code
> still broken?
Only thing left to revert is missing guards near "switch (rl_what) {" near line
3630 in ntpd/ntp_config.h
> Again, thanks for catching this.
You're welcome. Friendly nudge poke for using merge requests and peer review
pre-merging into master :-)
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 09:39:15PM -0700, Hal Murray wrote:
> > Only thing left to revert is missing guards near "switch (rl_what) {"
> > near line 3630 in ntpd/ntp_config.h
>
> The whole point of this change was to get rid of ifdefs that weren't needed
> because the symbols they were checking are in POSIX. Are we running on any
> systems that don't have RLIMIT_NOFILE or RLIMIT_STACK?
I'm talking about this snippet that was removed:
<--->
switch (rl_what) {
-#ifdef RLIMIT_MEMLOCK
- case RLIMIT_MEMLOCK:
- /* ignore - for backward compatibility only */
- break;
-#endif /* RLIMIT_MEMLOCK */
<--->
>
> Is this one of those half-in-POSIX cases where they say this is how to do it,
> but it's optional?
I'm still talking about RLIMIT_MEMLOCK.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntploggps not installed by waf
On Sat, Sep 21, 2019 at 01:09:30PM -0700, Paul Theodoropoulos via devel wrote: >On 9/21/2019 13:00 PM, James Browning wrote: > > On Sat, Sep 21, 2019, 12:55 PM Paul Theodoropoulos via devel > <[1]devel@ntpsec.org> wrote: > >Just a quick note, as I'm vetting all my installations - after running >'./waf configure --refclock=all', followed by './waf install', all of >the >applications in main/ntpclients are installed - except for ntploggps. > >I don't know the magic of waf sufficiently to point to why, where, or >how >it is overlooked... > > I think it is deliberately excluded if you do not have a recent gpsd > install detected. You do have a _recent_ gpsd installed I assume? > >Yep, 3.19 release. Hi Paul, Can you attach the full output from "./waf configure"? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.8 build error
On Sun, Dec 01, 2019 at 10:45:28AM +0100, Udo van den Heuvel via devel wrote: > On 01-12-2019 10:14, Udo van den Heuvel via devel wrote: > > The macro _wrong_version_format_terminate_build can be used to work > > around this issue: > > Perhaps also in this way: > > rpmbuild -bb --define '_wrong_version_format_terminate_build 0' > SPECS/ntpsec.spec Udo, Do you have a local patch that updates SPEC/ntpsec.spec for the version information of each new release within the spec file? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's name for the gitlab thing that checks post-push and sends yes/no mail?
On Mon, Dec 09, 2019 at 11:35:05AM -0800, Hal Murray via devel wrote: > > I haven't seen that mail recently. Authors are emailed for failed pipelines See https://docs.gitlab.com/ee/ci/pipelines.html We also email specific users for failed pipelines. See https://gitlab.com/NTPsec/ntpsec/-/services/pipelines_email/edit Let me know if you need more information. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python, testing
On Mon, Jan 13, 2020 at 05:06:01PM -0800, Hal Murray via devel wrote: > How does waf tell the c compiler which Python.h to use? > My system has: > /usr/include/python2.7/Python.h > /usr/include/python3.7m/Python.h ./waf --python=/path/to/python OR /path/to/python waf > What can we do about testing things like ntpq? > > Is there a ntpd running on the gitlab build boxes? Is it worthwhile to just > run commands without checking the answers? (catch crashes but not much else) Most of the build boxes are containers. There's no persistence, or daemons that exist beyond the time that the build is running. What sort of testing would you like to do with ntpq, specifically? Test specific sub-commands? What would that test look like? Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python, testing
On Mon, Jan 13, 2020 at 05:06:01PM -0800, Hal Murray via devel wrote: > A year or 2 ago, I put together a script to test as many build time options > as > I thought reasonable. It's in ./tests/option-tester.sh > > Does anybody other than me use it? > > It's a bit of a CPU hog -- too much to run routinely. Can we set things up > to > run it on the gitlab OS collection weekly or manually when we get close to a > release? > > At the back end of each build step, it runs each of our python programs far > enough to print out their version string. That's far from a thorough test, > but a whole lot better than nothing. (Thanks to the people who put that in.) > > In particular, it does (should?) check loading the libraries. I think the > same code gets run post install. > > There is also a tests/python3-tester.sh that explicitly uses python3 > I added a clone for python2 a day or two ago. (but forgot to finish typing > this message) I'm not certain how these scripts are much different than our existing CI jobs... we already have CI jobs for both Python2 and Python3. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does cross compiling work?
On Mon, Jan 20, 2020 at 11:53:44AM -0800, Hal Murray via devel wrote: > If so, can somebody send me an example script. See https://gitlab.com/NTPsec/ntpsec/blob/master/.gitlab-ci.yml#L450 and https://gitlab.com/NTPsec/ntpsec/blob/master/INSTALL.adoc#user-content-cross-compiling Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: waf help: OPENSSL_VERSION_NUMBER from openssl/opensslv.h
On Tue, Mar 24, 2020 at 12:40:42PM -0700, Hal Murray via devel wrote: > I'd like to check the OpenSSL version number and give a sensible error > message > rather than some mumbo jumble from the compiler. I would model the check that we removed in https://gitlab.com/NTPsec/ntpsec/-/commit/6d17955b03ca65d67f2cc2ceba01bd60e07d5fd4 Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Bye bye TLS 1.2
On Thu, Mar 26, 2020 at 12:57:33PM -0700, Hal Murray via devel wrote: > I just pushed the change. Can we bring back support of older OpenSSL releases for builds that don't need NTS support? OpenSSL 1.0.2 is supported via paid extended support per https://www.openssl.org/policies/releasestrat.html Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI stuff is broken: gentoo-hardened-basic
On Tue, Apr 21, 2020 at 04:57:04PM +, Robin H. Johnson via devel wrote: > Can you please log the IP of the host you used that did not have the > file? > > distfiles.gentoo.org is a bouncer with many mirrors Hi Robin, We call "emerge-webrsync" in our CI. Are you asking us to log the output of "dig distfiles.gentoo.org", or is there a debug flag for emerge-webrsync that you want us to enable for a bit? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
BSD-4-Clause-UC license usage
Hi Hal and team, Much our of NTS code uses BSD-4-Clause-UC instead of BSD-2-Clause (our preferred license for new code). What this license selection intentional? Is BSD-4-Clause-UC intended for code owned by the University of California, or does it make sense for others to use this license as well? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: BSD-4-Clause-UC license usage
On Thu, Apr 30, 2020 at 08:03:26PM +0800, Sanjeev Gupta wrote: >Hal, >I have sent in a MR, >https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1121 >for your review. Hi Sanjeev! I submitted https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1122 before I saw this. My MR also updates ntpd/ntp_dns.c Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pre-release cleanup
On Wed, Sep 02, 2020 at 08:53:41AM -0400, Eric S. Raymond via devel wrote: > Sanjeev Gupta : > > They support *any* git repository. > > Huh. Their docs are out of date, then. I tried adding our GitLab repo today and I get an error message that new GitLab repos have been disabled by the site administrator. I previously added our GitHub mirror and it's visible via https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list But without the direct GitLab support, we don't get the benefit of recommendations during merge requests. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pre-release cleanup
I also previously setup Codacy in order to see what other SAST systems could do. See https://app.codacy.com/gl/NTPsec/ntpsec/dashboard Let me know what you think. If either are useful, I'll integrate them more tightly in our workflows. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Runtime testing, What's the CI environment like?
On Sun, Sep 06, 2020 at 06:18:40PM -0500, Richard Laager via devel wrote: > On 9/6/20 5:43 PM, Hal Murray via devel wrote: > > Anybody using the modem driver? > > I tested in November, for fun, not any practical reason. NIST's service > is still up. The USNO service was dead. I emailed them and received no > response. USNO number in DC does not answer when I tried it just now. USNO number in CO does answer. The tycho.usno.navy.mil site is down and it seems to have been temporarily replaced by https://www.usno.navy.mil/USNO/time/telephone-time (there's a note that tycho may return in Fall 2020). Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Missing build bots for tags, websites down.
Hi James, >We currently do not have builders for the tags freebsd-11, freebsd-12, and >ubuntu-1604-lts. It would appear that in the late unpleasantness that the >builders detached. This should be fixable by having the >builders admin(s) reattach them in the settings. It should be possible to >migrate the cross builder to Docker. I will work on that shortly. The FreeBSD/cross-builder images are failing due to an unrelated snafu for our GCP VMs. Moving the cross-builder to Docker would be excellent! Can you also mark all 3 CI targets as allow-to-fail in order to allow everything else to proceed? We can revert that once the GCP issues are worked through. >Also, [1]docs.ntpsec.org and [2]www.ntpsec.org still seem to be down. It >is claimed to fixable from respective settings menus, by making them >public. www.ntpsec.org was moved back to GitLab pages and it should be working now. docs.ntpsec.org is still pending some work by GitLab support. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Missing build bots for tags, websites down.
On Mon, Dec 21, 2020 at 06:48:39PM +, Matthew Selsky via devel wrote: > www.ntpsec.org was moved back to GitLab pages and it should be working now. > docs.ntpsec.org is still pending some work by GitLab support. GL support fixed docs.ntpsec.org per https://gitlab.com/gitlab-com/gl-infra/production/-/issues/3214 Let me know if you find anything else that's not working properly. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fw: New Defects reported by Coverity Scan for ntpsec
On Mon, Jan 25, 2021 at 03:21:10PM -0800, James Browning via devel wrote: >Someone twisted a knob somewhere A new client for Coverity was released and it's more picky than the old client apparently. See https://scan.coverity.com/ "Coverity Upgrade to 2020.09" Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New email address
On Mon, Jun 14, 2021 at 11:27:06PM -0700, Hal Murray via devel wrote: > > I think I've updated the mailing lists, but hmur...@ntpsec.org forwards to my > old email and I can't figure out how to change that. > > My notes include: > https://devel.ntpsec.org/settings/panel/email/ > but that host doesn't exist any more. > > How should I change it these days? I can update this for you tonight. I'll let you know when it's complete. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Using Go for NTPsec
On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote: > Well, first, the historical target for accuracy of WAN time service is > more than an order of magnitude higher than 1ms. The worst-case jitter > that could add would be barely above the measurement-noise floor at worst, > and more probably below it. Hi Eric, Our target is < 1 us, even for WAN time service. We would want to keep/improve this accuracy target. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: waf: --disable-attic
On Tue, Feb 15, 2022 at 01:16:26PM -0800, Hal Murray via devel wrote: > > I have a simple patch that will turn off building things in attic/ > > Should we make off be the default and change that to --enable-attic? Hi Hal, Are we worried about the speed of the build, lack of build support on particular platforms, or something else? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Wildcards on NTS certificates -- security
On Fri, Feb 25, 2022 at 12:02:34PM -0800, Gary E. Miller via devel wrote: > Yo Hal! > > On Tue, 22 Feb 2022 14:39:21 -0800 > Hal Murray via devel wrote: > > > They don't work. See https://gitlab.com/NTPsec/ntpsec/-/issues/729 > > > > There is a single line of code that disables them. > > > > They are less secure. But is that "less" practical or theoretical? > > > > They are deprecated in RFC 6125 > > https://datatracker.ietf.org/doc/html/rfc6125#section-7.2 > > > > Should we: > > remove or comment out that line of code > > add an option to the server line to allow wildcards > > reject the bug report > > ... > > I'd go with making it optional, not the default. > > > Anybody have any opinions? How strong? > > Not strong, but I see how some people woule need them. See https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/ section 3 which says: A technology MAY disallow the use of the wildcard character in DNS names. If it does so, then the specification MUST state that wildcard certificates as defined in this document are not supported. https://datatracker.ietf.org/doc/html/rfc8915 doesn't mention that wildcards are not supported. So we should allow wildcards once this errata is published (or now?), with the X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS flag. And this should be built-in, not optional. We don't need another config flag. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release, wildcards, etc
On Fri, Apr 22, 2022 at 12:13:25AM -0700, Hal Murray via devel wrote: > nts nowildcards at the top level to set the default > nowildcards at the server level > wildcardsOK at the server level to override the default Hi Hal, Sorry, I'm not following what you mean here. Do you have a patch or merge request that I can look at? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: devel/make-tarball broken
On Wed, Dec 14, 2022 at 03:39:29PM -0800, James Browning via devel wrote: > 'Do not apply transform to symbolic link targets' [1] Which I > got from googling 'gnu tar transform' IIRC. It is also a > gnuism, but I do not see a portable transform type option as > tar on macOS uses -s and some BSDs seem to lack even that. I'll take a look this weekend about using "gtar" on macos so we get the GNU semantics. > > I added PIVOT.h last Jan 29, so this has been broken for almost a year. > > > > Is gitlab running option-tester weekly or monthly? Can it test > > make-tarball > > too? > > I don't think we need a bunch of runners testing devel/make-tarball, > one should be sufficient. Agreed. We don't need cross-platform compatibility at this time. > > Matt: > > I have updated PIVOT.h > > Is testing make-tarball on Mark's list? > > (before doing the mechanics of the release) > > despite not being Matt... > no, but it's called in devel/release before any repo changes > are made. Thanks, James! Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Release coming, take 2
Hi all, I plan to cut a release on Thu 12/22/2022. I'm sorry about the delays in getting this release out the door. If there's anything that absolutely must be in this release and can't wait until the next release, please let me know. Otherwise, I plan to tidy up the NEWS file as needed and then ship what we have. Going forward, I'll try to make sure that I'm doing releases more regularly, maybe 6 months or so? Thanks everyone for your patience. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
On Mon, Feb 06, 2023 at 10:51:02PM -0800, Hal Murray via devel wrote: > > > Do you have a coverity account? > > https://scan.coverity.com > > Then go to "My Dashboard" and "Add project". > > Should we document that? Where? The account creation seems self-explanatory. Or did you want to document something else? > It looks like Coverity is running over on github. Yes, Coverity is pointing at the GitHub mirror. > Is our copy-to-github stuff documented? It's a 1-line checkbox in our GitLab repo. There's no documentation, per se. > I'm waiting for somebody to approve me. I approved your account. > >> Date: Thu, 02 Feb 2023 05:48:37 + (Wed 21:48 PST) > > It was detected on Feb 5. > > So the turn around is days rather than hours. No. We run the Coverity CI job weekly via a schedule, not on every commit since I was concerned about abusing the Coverity scanner minutes and other reasons. I think we can re-evaluate that decision since our merge rate is low enough and run Coverity on each commit, but after merging since it relies on a GitLab runner that not everyone may have access to (for reasons that I don't want to go into here). I'll work on running Coverity post-merge. Do you need the ability to run Coverity offline on your development host before you push? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
On Wed, Feb 08, 2023 at 11:16:53AM -0800, Gary E. Miller via devel wrote: > The coverity scans are not part of the GitLab CI. They run off the > GitHub mirror. The GitLab CI triggers the scan. See https://gitlab.com/NTPsec/ntpsec/-/pipeline_schedules Coverity then points at GitHub for some reason. But the Coverity intermediate .o files, etc, are uploaded for analysis by GitLab CI. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Does anybody use (aka test) MDNS?
Hi Hal, I do not use it. My servers are all configured directly in ntp.conf Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: [Git][NTPsec/ntpsec][master] 3 commits: Minor cleanups to restrict
Hi Hal, >• [10]libntp/pymodule-mac.c > >══ > > ... ... @@ -143,6 +143,10 @@ void do_mac(char *name, > 143 143 *maclen = 0; > 144 144 return; > 145 145 } > 146 +/* Coverity CID 462307, 2023 June 11 > 147 + * CMAC API is undocumented and deprecated in OpenSSL 3. > 148 + * See libntp/macencrypt.c */ > 149 +/* coverity[checked_return] */ > 146 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); > 147 151 CMAC_Final(cmac_ctx, mac, maclen); > 148 152 if (MAX_MAC_LENGTH < *maclen) I think this needs to be "coverity[CHECKED_RETURN]". The man pages for CMAC_Update document that the return is either 0 or 1. Do we want to check this return code? >• [12]tests/unity/unity.c > >══ > > ... ... @@ -1002,6 +1002,7 @@ void UnityAssertFloatSpecial(const >UNITY_FLOAT actual, > 1002 1002 is_trait = !isinf(actual) && !isnan(actual); > 1003 1003 break; > 1004 1004 > 1005 +case UNITY_FLOAT_INVALID_TRAIT: /* Supress warning */ > 1005 1006 default: /* including UNITY_FLOAT_INVALID_TRAIT */ > 1006 1007 trait_index = 0; > 1007 1008 trait_names[0] = UnityStrInvalidFloatTrait; > ... ... @@ -1142,6 +1143,7 @@ void UnityAssertDoubleSpecial(const >UNITY_DOUBLE actual, > 1142 1143 is_trait = !isinf(actual) && !isnan(actual); > 1143 1144 break; > 1144 1145 > 1146 +case UNITY_FLOAT_INVALID_TRAIT: /* Supress warning */ > 1145 1147 default: /* including UNITY_FLOAT_INVALID_TRAIT */ > 1146 1148 trait_index = 0; > 1147 1149 trait_names[0] = UnityStrInvalidFloatTrait; Has this fix been submitted upstream to https://github.com/ThrowTheSwitch/Unity? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Thu, Aug 03, 2023 at 11:38:25PM -0700, Hal Murray wrote: > Should that also go to users@ and devel@? I'll do this shortly. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Fri, Aug 04, 2023 at 01:47:29PM -0700, Fred Wright via devel wrote: > And for that matter, what exactly is 1.2.2a, given that there's no git tag > for that version? Hi Fred, 1.2.2a is 1.2.2 + the 2 line patch to avoid the crash. We'll release 1.2.3 in late August with all of the changes in HEAD since 1.2.2 Please use "git fetch origin --tags" to pull the https://gitlab.com/NTPsec/ntpsec/-/tags/NTPsec_1_2_2a tag Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
NTPsec 1.2.2a released
The NTPsec Project is pleased to announce the tagging of version 1.2.2a * Fix a crash in ntpd if NTS is disabled and an NTS-enabled client request (mode 3) is received. (CVE-2023-4012) #794 For other changes since the previous release, please consult the project NEWS.adoc file at https://gitlab.com/NTPsec/ntpsec/-/blob/master/NEWS.adoc Getting this release You can clone the git repo from https://gitlab.com/NTPsec/ntpsec.git and you can download the release tarballs with sums and signatures from https://ftp.ntpsec.org/pub/releases/ This release is signed with the GPG key id E57235D22764129FA4F2F4D17F52608ED0E49D76 -- Matt Selsky Release Manager NTPsec Project ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Mon, Aug 07, 2023 at 02:14:40PM -0500, Richard Laager via devel wrote: > That said, I did advocate for merging it back in to master (as a no-op). But > I don't feel particularly strongly about that. The code fix itself is already in master. I'll merge the 1.2.2a NEWS into master later this evening. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
On Mon, Sep 04, 2023 at 02:25:46PM -0700, Gary E. Miller via devel wrote: > From RHEL: > > "The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's > Python 2.7 package at June 2024." > > https://access.redhat.com/solutions/4455511 Hi Gary, Is the implication that we can safely drop python2 support after June 2024? Are there any other distributions that ship python2 that we want to maintain support for? How much does it cost us to maintain python2 support in our own code? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: I just pushed ntsstats and ntskestats
On Mon, Sep 25, 2023 at 04:29:37PM -0700, Hal Murray via devel wrote: > I have a slight preference for double, but it doesn't really matter. > > I've seen some example with double on the left bar and single on the > top/bottom. > That was probably the web version. Hi Hal, Do you have an example of something that renders the way that you want? I don't think the man page backend for asciidoc renders "delimited literal block" in a special way (see https://docs.asciidoctor.org/asciidoc/latest/verbatim/literal-blocks/ for the asciidoc description). I'll see if I can find the man page backend code for asciidoc to see what it's doing. > I thought I send in an Issue but can't find it... > > Please check the bottom few lines on the man pages. At least one of them > didn't get updated to use our trailer stuff and still has the Mills version. Which man page shows this issue? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
On Wed, Oct 18, 2023 at 09:37:06PM -0700, Hal Murray via devel wrote: > I put the samba socket in /tmp/ > ntpd couldn't see it. My test programs work fine. > > 18 Oct 20:52:00 ntpd[5671]: SIGND: can not connect socket > '/tmp/fake-samba-socket/socket': No such file or directory > > What's magic about ntpd and /tmp/? > I'm running on Fedora. > > It works when I move the socket to /home/murray/, but I was trying to keep my > name out of it so somebody else could run my hacks without any edits. Hi Hal, Are you using selinux or something that would prevent access to /tmp? You can disable selinux temporarily by following the directions at https://www.tecmint.com/disable-selinux-in-centos-rhel-fedora/ It could also be auditd and then something like "audit2why -a" might show you why auditd blocked the access. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
On Thu, Oct 19, 2023 at 02:27:56PM -0700, Hal Murray via devel wrote: > It works fine from my test program. What's different about ntpd? Hi Hal, Are you running ntpd with --jaildir (or -i) or some chroot-like functionality? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Time for a release?
On Sun, Oct 29, 2023 at 10:50:56PM -0700, Hal Murray via devel wrote: > > The last time this was suggested, I encouraged waiting until we fixed mssntp. > Well, I think we have it fixed but we haven't found anybody to test it. Sounds good. Can you please update NEWS.adoc with mssntp and other news? > Time for lots of testing. And documentation checking/cleanup. What sort of testing did you have in mind? Any specific doc cleanup? > Does anybody have any features that should or must go in or bugs we should > fix? > (I haven't looked through issues yet.) Here are the open issues the caught my eye: https://gitlab.com/NTPsec/ntpsec/-/issues/806 https://gitlab.com/NTPsec/ntpsec/-/issues/802 (is this resolved with our latest FIPS changes, and do we have an environment to test it?) Do you think these or any others should delay the release? > What is the policy on ntpq documentation? We have tuned the code for use > with our version of ntpd, but it still mostly(?) talks to the old > Mills/classic version. I noticed lots of references to multicast and > broadcast in the man page. We removed the code that supported that stuff > ages ago. The *cast references are now clutter if you are interested in our > code, but might be relevant if you are looking at an old old system. Should > we leave the *cast documentation in or clean it out? Are we able to use our ntpq to probe *cast fields on other ntp daemons that support it? If so, leave it in. > I have 3 hacks that were used to debug talking to Samba. Is a subdir under > attic a reasonable place for them? Sure. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: [Git][NTPsec/ntpsec][master] Fix mode 6 client to round up to 4 bytes (was 8)
On Sun, Nov 26, 2023 at 11:43:14PM +, Hal Murray (--- via vc wrote:
> Hal Murray pushed to branch master at [1]NTPsec / ntpsec
>
> Commits:
>
> • [2]d98ce8d7
>by Hal Murray at 2023-11-26T15:42:51-08:00
>
> Fix mode 6 client to round up to 4 bytes (was 8)
>
> 1 changed file:
>
> • [3]ntpd/ntp_control.c
>
> Changes:
>
>• [4]ntpd/ntp_control.c
>
>══
>
> ... ... @@ -879,7 +879,7 @@ process_control(
> 879 879 properlen = req_count + (int)CTL_HEADER_LEN;
> 880 880 /* round up proper len to a 8 octet boundary */
> 881 881
> 882 - properlen = (properlen + 7) & ~7;
>882 + properlen = (properlen + 3) & ~3;
> 883 883 maclen = rbufp->recv_length - (size_t)properlen;
> 884 884 if ((rbufp->recv_length & 3) == 0 &&
> 885 885 maclen >= MIN_MAC_LEN && maclen <= MAX_MAC_LEN) {
Hi Hal,
Does the comment on line 880 also need to be updated?
Cheers,
-Matt
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Sat, Dec 02, 2023 at 08:09:00PM -0800, Hal Murray wrote: > > I think you should release what we have as soon as it is convenient. > > There are many more things I would like to include but we aren't making much > progress so it's time to do it. Hi Hal, Sounds good. I'll aim to release ~15-Dec-2023. Can you and others make sure that NEWS is up-to-date, especially for user-facing changes? I'm thinking about AES becoming the new default for ntpq, etc. I'll review this as well. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote: Hi Fred, > The main issue I've found is that the "struct var" in ntp_control.c, is > relying on anonymous unions, which are a relatively new language feature. > They were originally a GNU extension, eventually becoming official in C11. > But significantly increasing the compiler requirements just for one table > doesn't seem terribly desirable. Should our use of "-std=c99" have caught this? Or is that flag not intended to catch features newer than standard X? > There are also a bunch of warnings with some compilers, which might be worth > looking at. They're often fairly easy to fix, and sometimes indicate actual > problems. Do you have specifics on distros/compilers that are showing warnings so we can run these to ground? > I also stumbled across something (which may not be new) where it appears > that if libaes_siv is installed as a system library, it's preferred over the > bundled version. That probably doesn't change the actual behavior, but may > lead to opportunistic builds. Interesting. Which distro includes libaes_siv as a system library? We don't modify libaes_siv so using the system version should be fine. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Wed, Dec 06, 2023 at 01:56:51AM +, Matthew Selsky via devel wrote: > Sounds good. I'll aim to release ~15-Dec-2023. Hi all, Sorry for the delays. I have a release candidate tarball available: https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz.asc I'll wait until late Saturday and then publish a final tarball. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 07:21:39PM -0800, Fred Wright via devel wrote: Hi Fred, > There are a couple of minor issues that I should have noticed in the RC but > didn't: > > 1) The 1.2.2a entry is missing from NEWS. This is presumably because of the > way the patch release was forked off of the master branch, though the entry > still should have been included in master. As far as the master branch > history goes, 1.2.2a never existed. This is easily fixed. I see 1.2.2a at https://gitlab.com/NTPsec/ntpsec/-/blob/master/NEWS.adoc?ref_type=heads#user-content-2023-08-02-1-2-2a Where do you see it missing? > 2) This RC version was named 1.2.3rc1 instead of 1.2.3-rc1. This screws up > the sort order and makes it look like the RC version is newer than the > release version. It didn't follow the precedent of 1.2.2-rc1, which did it > correctly. E.g.: > > MacPro:~ fw$ port livecheck ntpsec > ntpsec seems to have been updated (port version: 1.2.3, new version: 1.2.3rc1) I'm not familiar with "port livecheck". If I repack/rename the tarballs on the website to include a hyphen, will that make the port command happy? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 08:55:38PM -0800, Fred Wright via devel wrote: > That explains it. I don't subscribe to the announce list, based on the > expectation that announcements would be cross-posted here. Cross-posting > only needs to be done by the sender, while cross-subscribing would need to > be done by every subscriber. I cross-posted the message to all 3 lists, but our smtp server and/or mailman instance ate the delivery to the devel@ and user@ lists. I may dig into this at a later date. Or I'll update my docs to send to each of the 3 lists individually for the short-term. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 08:52:53PM -0800, Fred Wright via devel wrote: > It should, though if the timestamps get updated in the process it would > trade bad name ordering for bad timestamp ordering. The ideal thing would > be to fix the names but keep the original timestamps. Three of the four > files have the name(s) embedded, so a simple rename wouldn't work. That > makes it a little dishonest to keep the old timestamps, though it matches > the spirit of the timestamps. :-) I fixed the file names/contents (and re-signed) and I used the timestamps from the original files. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: More SNMP dependency questions, also assertions.
On Sun, Apr 30, 2017 at 12:34:35PM -0500, Ian Bruene via devel wrote: > Ah, ok. The info I saw made it sound as if daemonization was > something even masters > found tricky. Conveniently there is a library and PEP on how to do > it right. :-) Hey Ian, Do you intend to make this an snmp agent that would run under an existing net-snmp daemon and communicate via the AgentX (RFC2741) protocol? Or are you thinking of a stand-alone snmp daemon? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: More SNMP dependency questions, also assertions.
On Mon, May 01, 2017 at 09:50:48PM -0400, Matthew Selsky via devel wrote: > Do you intend to make this an snmp agent that would run under an existing > net-snmp daemon and communicate via the AgentX (RFC2741) protocol? Or are > you thinking of a stand-alone snmp daemon? https://github.com/pief/python-netsnmpagent looks very interesting if we go the AgentX route. Then we don't need to deal with the SNMP versions or security issues. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Building with seccomp
On Sat, May 13, 2017 at 10:10:23PM -0700, Hal Murray via devel wrote: > > If you are missing a library or header, --enable-seccomp gives a warning but > doesn't bail. Should that be changed? > > There are 3 seccomp symbols setup in config.h > #define ENABLE_SECCOMP 1 /* Enable seccomp */ > #define HAVE_SECCOMP_H 1 > #define HAVE_SECCOMP 1 > > Is there any reason for more then one? It only builds on Linux. We need > both the header and library. HAVE_SECCOMP can likely be replaced with HAVE_SECCOMP_H in the code. And we can use ENABLE_SECCOMP or another ctx variable in waf to determine if the user wants us to check for seccomp at all (since we don't check for seccomp by default). And then we won't set the other variables if ENABLE_SECCOMP is false. If that makes sense, I can update waf to do this. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Building with seccomp
On Mon, May 15, 2017 at 12:02:15PM -0700, Hal Murray wrote: > > devel@ntpsec.org said: > > HAVE_SECCOMP can likely be replaced with HAVE_SECCOMP_H in the code. > > That seems backwards. HAVE_SECCOMP_H says (to me) that you have the header. > You may not have the library and/or maybe seccomp wasn't configured. > > seccomp is only referenced by ntpd/ntp_sandbox.c I was thinking of using > only ENABLE_SECCOMP with a big comment saying that waf had checked to make > sure whatever is needed is available. > > But which symbol we use is not a big deal. > > Humm... How would that test (and similar ones) work in a cross compile? Is > anybody actually cross compiling? If so, what platform? Maybe we should > setup a test case for a Raspberry Pi. > > > > There is still the problem of should waf crash if you asked for seccomp and > it won't work. Currently, it just prints a warning that is easy to miss in > all the other printout. Just to close out this thread for those that don't watch the GitLab site.. I consolidated on a single symbol in config.h and I made waf have a fatal error if you requested seccomp, but either headers or libraries aren't found. See https://gitlab.com/NTPsec/ntpsec/commit/d22805a504e2a4066a3b22f5a100319c1f72601d Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
dns debugging messages?
Hey Hal, Is this DNS debugging intended for syslog when I build without "--enable-debug"? $ ./waf configure $ sudo ./build/main/ntpd/ntpd -g -p /run/ntpd.pid $ syslog shows: 2017-05-19T05:28:57.546+00:00 host.example.com ntpd[19012]: ntpd ntpsec-0.9.7+616 2017-05-15T08:59:02-0400: Starting 2017-05-19T05:28:57.546+00:00 host.example.com ntpd[19012]: Command line: /home/mselsky/src/ntpsec/build/main/ntpd/ntpd -g -u ntp:ntp -p /run/ntpd.pid 2017-05-19T05:28:57.546+00:00 host.example.com ntpd[19013]: close_all_beyond: closing 65536 files 2017-05-19T05:28:57.550+00:00 host.example.com ntpd[19013]: proto: precision = 0.118 usec (-23) 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: successfully locked into RAM 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: requestkey is a no-op because ntpdc has been removed. 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: authreadkeys: reading /etc/ntp.keys 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: authreadkeys: added 1 keys 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: Listen and drop on 0 v6wildcard [::]:123 2017-05-19T05:28:57.552+00:00 host.example.com ntpd[19013]: Listen and drop on 1 v4wildcard 0.0.0.0:123 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: Listen normally on 2 lo 127.0.0.1:123 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: Listen normally on 3 eth0 192.168.1.1:123 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: Listen normally on 4 lo [::1]:123 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: Listen normally on 5 eth0 [fe80::f816:3eff:fe01:2145%2]:123 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: Listening on routing socket on fd #22 for interface updates 2017-05-19T05:28:57.553+00:00 host.example.com ntpd[19013]: newpeer: addr:0.0.0.0, name:ntp1.example.com, cast_flags:1, flags:801 2017-05-19T05:28:57.554+00:00 host.example.com ntpd[19013]: newpeer: addr:0.0.0.0, name:ntp2.example.com, cast_flags:1, flags:801 2017-05-19T05:28:57.555+00:00 host.example.com ntpd[19013]: newpeer: addr:0.0.0.0, name:ntp3.example.com, cast_flags:1, flags:801 2017-05-19T05:28:57.556+00:00 host.example.com ntpd[19013]: newpeer: addr:0.0.0.0, name:ntp4.example.com, cast_flags:1, flags:801 2017-05-19T05:28:57.556+00:00 host.example.com ntpd[19013]: newpeer: addr:0.0.0.0, name:ntp5.example.com, cast_flags:1, flags:801 2017-05-19T05:28:57.557+00:00 host.example.com ntpd[19013]: Found 5 servers, suggest minsane at least 3 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec on MIPSbe
On Tue, May 23, 2017 at 11:59:24AM -0700, Hal Murray via devel wrote: > If you are keeping track... > > It builds and runs on a 32 bit PowerPC MAC-Mini, both Debian and FreeBSD. > > #define WORDS_BIGENDIAN 1 > > There are problems with the firmware setting up the time keeping parameters > incorrectly. I can patch it via Open Firmware, but haven't figured out how > to make it stick over reboots. Sanjeev/Hal, Did waf's endian-ness test not detect this properly? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
On Thu, Jun 08, 2017 at 12:26:21AM -0700, Hal Murray via devel wrote: > Can anybody confirm that Solaris really doesn't have time stamps? I thought > we decided that all modern OSes did. That's why we could rip out the SIGIO > stuff. > > I took a quick google and couldn't find any mention of anything that looked > like a time stamp in a Solaris man page for setsockopt. But some of the > stuff I was looking at was surprisingly old. > > If Solaris doesn't support time stamps, I would expect ntp_packetstamp to die > on a #error. What happened with it? If it does support time stamps, how are > we supposed to read them? There are a bunch of CMSG macros over in > ntp_packetstamp. They are useless without those missing symbols so it should > have barfed there too. Newer versions of Solaris support SO_TIMESTAMP per: https://docs.oracle.com/cd/E19957-01/820-0724/gcoqs/index.html http://www.theptpguy.net/posts/2017/05/25/ptpd-on-legacy-systems-solaris-10-part-1-how-we-got-there https://docs.oracle.com/cd/E36784_01/html/E36875/setsockopt-3socket.html#REFMAN3Bsetsockopt-3socket This matches what I see in the Solaris 11u3 VM that I have connected to Buildbot. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fw: [Git][NTPsec/ntpsec][master] Replace "uint" with "unsigned int"
On Fri, Jun 09, 2017 at 11:43:20AM -0700, Gary E. Miller via devel wrote: > Yo Matt! > > > Commits: > > 0430e6a7 by Matt Selsky at 2017-06-08T23:42:39-04:00 > > Replace 'uint' with 'unsigned int' > > I always thought 'unsigned int' was overly verbose. How about > simply 'unsigned'? Hey Gary, I used "unsigned int" so that I would match the typedef that I was replacing exactly. The codebase is not consistent about usage of "unsigned" vs "unsigned int". I'd be happy to search-and-replace everything to be consistent if we have consensus on which form we prefer. Though the time might be better spent on changing to uintX :-) Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Build failure
Hey Eric/Gary: Are there extra options we should pass to ./waf configure to catch these types of errors in our gitlab bots? I'm happy to update our .gitlab-ci.yml to do extra checking so we detect these before users do. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Prevent potential buffer overruns in the mode 6 code.
On Mon, Mar 13, 2017 at 12:11:47PM -0700, Gary E. Miller wrote: > Yo Ertic! > > > cp = buffer; > cq = tag; > - while (*cq != '\0') > + while (*cq != '\0' && cp < buffer + sizeof(buffer) - 1) > *cp++ = *cq++; > > > Why not just use strlcpy? NTPsec has its own copy if the OS does > not provide it. This sort of bit-picky C code is where problems lurk. Hey Eric, Was there an off-list answer to this? Can we switch to strlcpy() for the cases where we're copying null-terminated strings? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
