Re: Testing

[Trevor N. via devel]

From: Hal Murray
To:devel@ntpsec.org
Subject: Testing


Does anybody test our code on Apple?  Solaris?
In order to test 32 bit and 64 bit big and little endian hosts with the 
Trimble driver, I have been using:

LE32: Raspberry Pi 3B with Raspbian
LE64: Xeon with Gentoo
BE32: Power Mac G4 with FreeBSD
BE64: Sun Ultra 5 with v9os

I also did some testing on a Power Mac G5 with 10.5 using MacPorts and 
its patches, but I lost interest when I found that MacOS doesn't have 
ntp_adjtime.  I tried 14.2 on a Mac Pro 5,1 and there is still no 
ntp_adjtime support so the performance is poor. Both versions seem to 
lack a PPS line discipline. Very few serial port expansion cards are usable.


Previously I was testing the driver with Solaris 11.3 on a T5220, but I 
wanted to stay current when 11.3 "premier support" was discontinued so I 
set up 11.4 CBE on a T4-1. It was working, but the machine is so loud 
and power-hungry that I switched to a Sun Ultra 5. I couldn't get a 
build environment set up with Solaris Express (which was the last 
version that was compatible with the Ultra 5) so I had to move on to the 
OpenSolaris forks. The only one that I could get a SPARC build 
environment working with was v9os.  Neither v9os or 11.4 support 
MOD_NANO, so the performance isn't that great. For 11.4 with Solaris 
Studio, I had to make a change to V4_SIZEOF_RESTRICT_U  and 
V6_SIZEOF_RESTRICT_U to use the ALIGNED_SIZE macro because I was getting 
unaligned access errors when accessing the restrict list (a member of 
restrict_u in ntp.h was changed sometime after the 1.2.2 release).


I have added support for the Acutime 360 on my fork, but I need to 
finish up testing and clean up the documentation before I make a merge 
request. With the recent mention of a possible leap second deletion I 
may want to do a new set of tests with a simulator, but it will take a 
while before I can get to it. Some of the Trimble receivers have no 
direct indication of the leap second direction, so it could be exciting 
-- it might be best to remove leap notification support for those.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Matt Selsky via devel]

On Thu, May 02, 2024 at 02:17:18AM -0700, Hal Murray via devel wrote:
> Does anybody test our code on Apple?  Solaris?

I do some of my initial dev work on macOS, but I don't run ntpd on macOS. My 
production environment for NTPsec is Linux.  I worked with Solaris x86 a few 
years ago since I was interested to see if the SunOne Studio compiler would 
show us any interesting warnings/errors, but I haven't tested in a while.

> Does anybody use any of the fancy interface logic?
>   It's available both vie the command line and the config file.

We set:
interface listen a.b.c.d

on some of our hosts with many, many interfaces since ntpd prints errors if the 
interface count is > 1024, or on multi-homed hosts where we only want ntp 
service provided on 1 interface.

Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Testing

[Hal Murray via devel]

Does anybody test our code on Apple?  Solaris?

Does anybody use any of the fancy interface logic?
  It's available both vie the command line and the config file.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Is anybody using/testing the interface options?

[Hal Murray via devel]

There is an option in the config file and more on the command line.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Crappy testing

[Hal Murray via devel]

If you use the extra port stuff I pushed last night, port 123 stops working.

Ugh, blush.  I usually do better than that.



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing -4 and -6

[Robin H. Johnson via devel]

On Wed, Sep 20, 2023 at 08:02:51PM -0700, Hal Murray via devel wrote:
> 
> Does anybody have a recipe (or pointer to one) for how to get a system 
> running 
> without any IPv6?
net.ipv6.conf.all.disable_ipv6=1

> I want something such that isc_net_probeipv6_bool() will return false.
> 
> Do we have to build our own kernel with some config variable turned off?
> Or will just not configuring any IPv6 interfaces be good enough?
> 
> Same for IPv4.
Not possible today to my knowledge to get a kernel with strictly
v6-only at the kernel layer. I think you might be able to delete all v4
addresses, but that isn't quite the same thing.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation President & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Testing -4 and -6

[Hal Murray via devel]

Does anybody have a recipe (or pointer to one) for how to get a system running 
without any IPv6?

I want something such that isc_net_probeipv6_bool() will return false.

Do we have to build our own kernel with some config variable turned off?
Or will just not configuring any IPv6 interfaces be good enough?

Same for IPv4.

The code for isc_net_probeipv6_bool is slightly different from that for 
isc_net_probeipv4_bool.  I didn't go down that rathole.  It looks like 
somebody may be assuming that some or all of IPv4 always exists.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Gary E. Miller via devel]

;>by mx.ntpsec.org (Postfix) with ESMTPS id EF960286BBA
> >>>>for; Mon, 21 Nov 2022 23:09:39 + (UTC)
> >>>> Received: from spidey.rellim.com (rellim.com
> >>>> [IPv6:2001:470:e815::19]) by rellim.com (Postfix) with ESMTPSA id
> >>>> 9D42120001F for; Mon, 21 Nov 2022 15:09:39
> >>>> -0800 (PST) Date: Mon, 21 Nov 2022 15:09:32 -0800
> >>>> To:
> >>>> Subject: =?UTF-8?B?4pyYVGVzdGluZw==?=
> >>>> Message-ID:<20221121150932.5ed30...@spidey.rellim.com>
> >>>> Organization: Rellim
> >>>> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu)
> >>>> MIME-Version: 1.0
> >>>> X-BeenThere:devel@ntpsec.org
> >>>> X-Mailman-Version: 2.1.39
> >>>> Precedence: list
> >>>> List-Id: Developer discussion 
> >>>> List-Unsubscribe:<https://lists.ntpsec.org/mailman/options/devel>,
> >>>><mailto:devel-requ...@ntpsec.org?subject=unsubscribe>
> >>>> List-Archive:<https://lists.ntpsec.org/pipermail/devel/>
> >>>> List-Post:<mailto:devel@ntpsec.org>
> >>>> List-Help:<mailto:devel-requ...@ntpsec.org?subject=help>
> >>>> List-Subscribe:<https://lists.ntpsec.org/mailman/listinfo/devel>,
> >>>><mailto:devel-requ...@ntpsec.org?subject=subscribe>
> >>>> From: "Gary E. Miller via devel"
> >>>> Reply-To: "Gary E. Miller"
> >>>> Content-Type: multipart/mixed;
> >>>> boundary="===3697578452347589219=="
> >>>> Errors-To:devel-boun...@ntpsec.org  Sender:
> >>>> "devel"  X-Rspamd-Queue-Id: AD6252869D8
> >>>> X-Spamd-Result: default: False [-2.31 / 15.00];
> >>>>  SIGNED_PGP(-2.00)[];
> >>>>  MIME_GOOD(-0.20)[multipart/mixed,multipart/signed,text/plain];
> >>>>  MAILLIST(-0.20)[mailman];
> >>>>  RCVD_NO_TLS_LAST(0.10)[];
> >>>>  HAS_LIST_UNSUB(-0.01)[];
> >>>>  TO_DN_NONE(0.00)[];
> >>>>  ARC_NA(0.00)[];
> >>>>  TO_EQ_FROM(0.00)[];
> >>>>  RCPT_COUNT_ONE(0.00)[1];
> >>>>  FORGED_RECIPIENTS_MAILLIST(0.00)[];
> >>>>  MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
> >>>>  RCVD_COUNT_THREE(0.00)[4];
> >>>>  HAS_ORG_HEADER(0.00)[];
> >>>>  PREVIOUSLY_DELIVERED(0.00)[devel@ntpsec.org];
> >>>>  RCVD_VIA_SMTP_AUTH(0.00)[];
> >>>>  HAS_REPLYTO(0.00)[g...@rellim.com];
> >>>>  FROM_NEQ_ENVFROM(0.00)[devel@ntpsec.org,devel-boun...@ntpsec.org];
> >>>>  FROM_HAS_DN(0.00)[];
> >>>>  TAGGED_RCPT(0.00)[ntpsec];
> >>>>  FREEMAIL_ENVRCPT(0.00)[protonmail.com,rogers.com,yahoo.com];
> >>>>  REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
> >>>>  FORGED_SENDER_MAILLIST(0.00)[]
> >>>> X-Rspamd-Server: mx.ntpsec.org
> >>>> X-Spam-Score: -1.0 (-)
> >>>> X-Spam-Report: Spam detection software, running on the system
> >>>> "relay.anastrophe.com", has NOT identified this incoming email as
> >>>> spam.  The original message has been attached to this so you can
> >>>> view it or label similar future email.  If you have any
> >>>> questions, seepostmas...@anastrophe.com   for details.
> >>>> On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:  
> >>>>> Yo All!
> >>>>>
> >>>>> Testing 7-8-9
> >>>>>
> >>>>>
> >>>>> RGDS
> >>>>> GARY
> >>>>> ---
> >>>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
> >>>>> 97703...@rellim.comTel:+1   541 382 8588
> >>>>>
> >>>>> Veritas liberabit vos. -- Quid est veritas?
> >>>>>   "If you can't measure it, you can't improve it." - Lord
> >>>>> Kelvin
> >>>>>
> >>>>> ___
> >>>>> devel mailing list
> >>>>> devel@ntpsec.org
> >>>>> https://lists.ntpsec.org/mailman/listinfo/devel 
> >>>> -- 
> >>>> Paul Theodoropoulos
> >>>> anastrophe.com<https://www.anastrophe.com>
> >>>>
> >>>> ___
> >>>> devel mailing list
> >>>> devel@ntpsec.org
> >>>> https://lists.ntpsec.org/mailman/listinfo/devel 
> >>> -- 
> >>> Paul Theodoropoulos
> >>> anastrophe.com<https://www.anastrophe.com>
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@ntpsec.org
> >>> https://lists.ntpsec.org/mailman/listinfo/devel 
> >
> >
> >
> > RGDS
> > GARY
> > ---
> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
> > 97703 g...@rellim.com   Tel:+1  541 382 8588
> >
> > Veritas liberabit vos. -- Quid est veritas?
> >  "If you can't measure it, you can't improve it." - Lord Kelvin
> >
> > ___
> > devel mailing list
> > devel@ntpsec.org
> > https://lists.ntpsec.org/mailman/listinfo/devel  
> 




RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpqs90oyTFq2.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

RCPT_COUNT_ONE(0.00)[1];
FORGED_RECIPIENTS_MAILLIST(0.00)[];
MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
RCVD_COUNT_THREE(0.00)[4];
HAS_ORG_HEADER(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[devel@ntpsec.org];
RCVD_VIA_SMTP_AUTH(0.00)[];
HAS_REPLYTO(0.00)[g...@rellim.com];
FROM_NEQ_ENVFROM(0.00)[devel@ntpsec.org,devel-boun...@ntpsec.org];
FROM_HAS_DN(0.00)[];
TAGGED_RCPT(0.00)[ntpsec];
FREEMAIL_ENVRCPT(0.00)[protonmail.com,rogers.com,yahoo.com];
REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
FORGED_SENDER_MAILLIST(0.00)[]
X-Rspamd-Server: mx.ntpsec.org
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam detection software, running on the system
"relay.anastrophe.com", has NOT identified this incoming email as
spam.  The original message has been attached to this so you can
view it or label similar future email.  If you have any questions,
seepostmas...@anastrophe.com   for details.
On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:

Yo All!

Testing 7-8-9


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
97703...@rellim.comTel:+1   541 382 8588

Veritas liberabit vos. -- Quid est veritas?
  "If you can't measure it, you can't improve it." - Lord
Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel   

--
Paul Theodoropoulos
anastrophe.com<https://www.anastrophe.com>

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel   

--
Paul Theodoropoulos
anastrophe.com<https://www.anastrophe.com>

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel   




RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Gary E. Miller via devel]

Yo Paul!

Email gets into mailman, and archives, quickly.  Then mailman, on
lists.ntpsec.org, was talking directly mx.ntpsec.org, sending one email
every 75 seconds.

Now I have mailman sending email to the postfix on lists.ntpsec.org, and
that sends many emails in parallele to mx.ntpsec.org, that take time
sending them.

The next step may be to have lists.ntpsec.org stop forwaiding email to
mx.ntpsec.org and instead try to deliver directly.  I'm sure that will
also break something.

With Turkey Day coming, my testing will have to slow down.

On Mon, 21 Nov 2022 16:10:12 -0800
Paul Theodoropoulos  wrote:

> Inserted into stream:
> 
> Mon, 21 Nov 2022 15:09:32 -0800
> 
> Received here:
> 
> Mon, 21 Nov 2022 15:46:32 -0800
> 
> So, about 3 hours, down to about 90 minutes, down to about 37 minutes.
> 
> Pretty smooth line.
> 
> Return-path:
> Envelope-to:p...@anastrophe.com
> Delivery-date: Mon, 21 Nov 2022 15:46:32 -0800
> Received: from mx.ntpsec.org ([140.211.9.57]:20808)
>   by relay.anastrophe.com with esmtps  (TLS1.3) tls
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
>   (envelope-from)
>   id 1oxGUc-006XpM-2D
>   forp...@anastrophe.com;
>   Mon, 21 Nov 2022 15:46:32 -0800
> Received: from lists.ntpsec.org (lists.int.ntpsec.org [192.168.9.59])
>   by mx.ntpsec.org (Postfix) with ESMTP id AD6252869D8;
>   Mon, 21 Nov 2022 23:42:40 + (UTC)
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org;
> s=dkim; t=1669074385; bh=cqB08lDH4HOppOt+A7Z5bG0T/wmUZyy7Hsxj2M8Whb4=;
>   h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
>List-Help:List-Subscribe:From:Reply-To;
>   z=Date:=20Mon,=2021=20Nov=202022=2015:09:32=20-0800|To:=20 psec.org>|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id:
> =20Developer=20discussion=20|List-Unsubscribe:=2
> 0<https://lists.ntpsec.org/mailman/options/devel>,=0D=0A=20 :devel-requ...@ntpsec.org?subject=3Dunsubscribe>|List-Archive:=20<
> https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20<mailto:de
> v...@ntpsec.org>|List-Help:=20<mailto:devel-requ...@ntpsec.org?subj
> ect=3Dhelp>|List-Subscribe:=20<https://lists.ntpsec.org/mailman/li
> stinfo/devel>,=0D=0A=20<mailto:devel-requ...@ntpsec.org?subject=3D
> subscribe>|From:=20"Gary=20E.=20Miller=20via=20devel"=20 subscribe>sec.org>|Reply-To:=20"Gary=20E.=20Miller"=20;
> subscribe>b=zmRXPOh8RKpIrX09TcKunPhOBphrgVmqzmsJxK+ai7T825o/+xrEuHIb6fIwu+epd
> subscribe>PQR3Uh7Fo5AYQI0RD3ufw/uRocNE9Ln/PiBdKRgi+wEVV9JxXI0nYHlSFxK+pcj8do
> subscribe>9frqrzOI/2Lb0571NT1HL2SyDKrr1wCDdkN3YYBc= Received: from
> subscribe>lists.ntpsec.org (unknown [192.168.9.59]) by
> subscribe>lists.ntpsec.org (Postfix) with ESMTP id EE1A03C0CF7; Mon,
> subscribe>21 Nov 2022 23:09:43 + (UTC)
> Received: from mx.ntpsec.org (unknown [192.168.9.57])
>   by lists.ntpsec.org (Postfix) with ESMTP id E7C043C0285
>   for; Mon, 21 Nov 2022 23:09:42 + (UTC)
> Received: from rellim.com (rellim.com [204.17.205.19])
>   (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>   key-exchange X25519 server-signature RSA-PSS (2048 bits)
> server-digest SHA256) (No client certificate requested)
>   by mx.ntpsec.org (Postfix) with ESMTPS id EF960286BBA
>   for; Mon, 21 Nov 2022 23:09:39 + (UTC)
> Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815::19])
>   by rellim.com (Postfix) with ESMTPSA id 9D42120001F
>   for; Mon, 21 Nov 2022 15:09:39 -0800 (PST)
> Date: Mon, 21 Nov 2022 15:09:32 -0800
> To:
> Subject: =?UTF-8?B?4pyYVGVzdGluZw==?=
> Message-ID:<20221121150932.5ed30...@spidey.rellim.com>
> Organization: Rellim
> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu)
> MIME-Version: 1.0
> X-BeenThere:devel@ntpsec.org
> X-Mailman-Version: 2.1.39
> Precedence: list
> List-Id: Developer discussion 
> List-Unsubscribe:<https://lists.ntpsec.org/mailman/options/devel>,
>   <mailto:devel-requ...@ntpsec.org?subject=unsubscribe>
> List-Archive:<https://lists.ntpsec.org/pipermail/devel/>
> List-Post:<mailto:devel@ntpsec.org>
> List-Help:<mailto:devel-requ...@ntpsec.org?subject=help>
> List-Subscribe:<https://lists.ntpsec.org/mailman/listinfo/devel>,
>   <mailto:devel-requ...@ntpsec.org?subject=subscribe>
> From: "Gary E. Miller via devel"
> Reply-To: "Gary E. Miller"
> Content-Type: multipart/mixed;
> boundary="===3697578452347589219=="
> Errors-To:devel-boun...@ntpsec.org Sender:
> "devel" X-Rspamd-Queue-Id: AD6252869D8
> X-Spamd-Result: default: False [-2.31 / 15.00];
>   SIGNED_PGP(-2.00)[];
>   MIME_GOOD(

Re: ✘Testing

[Gary E. Miller via devel]

g/mailman/listinfo/devel>,
> >>   <mailto:devel-requ...@ntpsec.org?subject=subscribe>
> >> From: "Gary E. Miller via devel"
> >> Reply-To: "Gary E. Miller"
> >> Content-Type: multipart/mixed;
> >> boundary="===3697578452347589219=="
> >> Errors-To:devel-boun...@ntpsec.org Sender:
> >> "devel" X-Rspamd-Queue-Id: AD6252869D8
> >> X-Spamd-Result: default: False [-2.31 / 15.00];
> >>SIGNED_PGP(-2.00)[];
> >>MIME_GOOD(-0.20)[multipart/mixed,multipart/signed,text/plain];
> >>MAILLIST(-0.20)[mailman];
> >>RCVD_NO_TLS_LAST(0.10)[];
> >>HAS_LIST_UNSUB(-0.01)[];
> >>TO_DN_NONE(0.00)[];
> >>ARC_NA(0.00)[];
> >>TO_EQ_FROM(0.00)[];
> >>RCPT_COUNT_ONE(0.00)[1];
> >>FORGED_RECIPIENTS_MAILLIST(0.00)[];
> >>MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
> >>RCVD_COUNT_THREE(0.00)[4];
> >>HAS_ORG_HEADER(0.00)[];
> >>PREVIOUSLY_DELIVERED(0.00)[devel@ntpsec.org];
> >>RCVD_VIA_SMTP_AUTH(0.00)[];
> >>HAS_REPLYTO(0.00)[g...@rellim.com];
> >>FROM_NEQ_ENVFROM(0.00)[devel@ntpsec.org,devel-boun...@ntpsec.org];
> >>FROM_HAS_DN(0.00)[];
> >>TAGGED_RCPT(0.00)[ntpsec];
> >>FREEMAIL_ENVRCPT(0.00)[protonmail.com,rogers.com,yahoo.com];
> >>REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
> >>FORGED_SENDER_MAILLIST(0.00)[]
> >> X-Rspamd-Server: mx.ntpsec.org
> >> X-Spam-Score: -1.0 (-)
> >> X-Spam-Report: Spam detection software, running on the system
> >> "relay.anastrophe.com", has NOT identified this incoming email as
> >> spam.  The original message has been attached to this so you can
> >> view it or label similar future email.  If you have any questions,
> >> see postmas...@anastrophe.com  for details.
> >> On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:  
> >>> Yo All!
> >>>
> >>> Testing 7-8-9
> >>>
> >>>
> >>> RGDS
> >>> GARY
> >>> ---
> >>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
> >>> 97703 g...@rellim.com   Tel:+1  541 382 8588
> >>>
> >>>   Veritas liberabit vos. -- Quid est veritas?
> >>>  "If you can't measure it, you can't improve it." - Lord
> >>> Kelvin
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@ntpsec.org
> >>> https://lists.ntpsec.org/mailman/listinfo/devel  
> >>
> >> -- 
> >> Paul Theodoropoulos
> >> anastrophe.com <https://www.anastrophe.com>
> >>
> >> ___
> >> devel mailing list
> >> devel@ntpsec.org
> >> https://lists.ntpsec.org/mailman/listinfo/devel  
> >
> > -- 
> > Paul Theodoropoulos
> > anastrophe.com <https://www.anastrophe.com>
> >
> > ___
> > devel mailing list
> > devel@ntpsec.org
> > https://lists.ntpsec.org/mailman/listinfo/devel  
> 




RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpE6pi0epdeU.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

DOM(0.00)[];
FORGED_SENDER_MAILLIST(0.00)[]
X-Rspamd-Server: mx.ntpsec.org
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam detection software, running on the system 
"relay.anastrophe.com",
  has NOT identified this incoming email as spam.  The original
  message has been attached to this so you can view it or label
  similar future email.  If you have any questions, see
  postmas...@anastrophe.com  for details.
On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:

Yo All!

Testing 7-8-9


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

ware, running on the system 
"relay.anastrophe.com",
  has NOT identified this incoming email as spam.  The original
  message has been attached to this so you can view it or label
  similar future email.  If you have any questions, see
  postmas...@anastrophe.com  for details.
On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:

Yo All!

Testing 7-8-9


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

ew it or label
 similar future email.  If you have any questions, see
 postmas...@anastrophe.com  for details.

On 11/21/2022 15:09 PM, Gary E. Miller via devel wrote:

Yo All!

Testing 7-8-9


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

✘Testing

[Gary E. Miller via devel]

Yo All!

Testing 7-8-9


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpMpLx2bQg3O.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

Better. Dropped 18:54:41, delivered 20:22:26, so an hour thirty minutes roughly.

Return-path:
Envelope-to:p...@anastrophe.com
Delivery-date: Sun, 20 Nov 2022 20:22:26 -0800
Received: from mx.ntpsec.org ([140.211.9.57]:45636)
by relay.anastrophe.com with esmtps  (TLS1.3) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from)
id 1owyJK-006TiP-0Z
forp...@anastrophe.com;
Sun, 20 Nov 2022 20:22:25 -0800
Received: from lists.ntpsec.org (lists.int.ntpsec.org [192.168.9.59])
by mx.ntpsec.org (Postfix) with ESMTP id 9B21C286BBA;
Mon, 21 Nov 2022 04:20:18 + (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; s=dkim;
t=1669004493; bh=3/XDwWLUfwPtWqe97vyYFTtEoI6iM/UR+tnT6Vs/9OQ=;
h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
 List-Help:List-Subscribe:From:Reply-To;
z=Date:=20Sun,=2020=20Nov=202022=2018:54:41=20-0800|To:=20|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id:
 =20Developer=20discussion=20|List-Unsubscribe:=2
 0,=0D=0A=20|List-Archive:=20< 
https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20|List-Help:=20|List-Subscribe:=20,=0D=0A=20|From:=20"Gary=20E.=20Miller=20via=20devel"=20|Reply-To:=20"Gary=20E.=20Miller"=20;
b=XTdY2hTR6/gA8t4lRsvluCkoTKAf/oOmbPzg2KfXFXclo8ptotRxehYRkoI/f3RHp
 LmImWl96z2j/Girt7XR+IP0wXbwBkOKHY7+Ep6djkkYY8Fqw7JRtMWs1LnVGHqGOGi
 F9lnKz229wF+iwBCV0P85eucPBHqH9q7dONfIq+o=
Received: from mx.ntpsec.org (unknown [192.168.9.57])
 by lists.ntpsec.org (Postfix) with ESMTP id EA3603C0285
 for; Mon, 21 Nov 2022 02:54:50 + (UTC)
Received-SPF: pass (rellim.com: 204.17.205.19 is authorized to use
 'g...@rellim.com' in 'mfrom' identity (mechanism 'ip4:204.17.205.0/24'
 matched)) receiver=mx.ntpsec.org; identity=mailfrom;
 envelope-from="g...@rellim.com"; helo=rellim.com; client-ip=204.17.205.19
Received: from rellim.com (rellim.com [204.17.205.19])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by mx.ntpsec.org (Postfix) with ESMTPS id B3CEA286A05
 for; Mon, 21 Nov 2022 02:54:49 + (UTC)
Received: from spidey.rellim.com (unknown [IPv6:2001:470:e815::19])
 by rellim.com (Postfix) with ESMTPSA id 4844A20001F
 for; Sun, 20 Nov 2022 18:54:49 -0800 (PST)
Date: Sun, 20 Nov 2022 18:54:41 -0800
To:
Subject: =?UTF-8?B?4pyYVGVzdGluZw==?=
Message-ID:<20221120185441.256f7...@spidey.rellim.com>
Organization: Rellim
X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-BeenThere:devel@ntpsec.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Developer discussion 
List-Unsubscribe:,
 
List-Archive:
List-Post:
List-Help:
List-Subscribe:,
 
From: "Gary E. Miller via devel"
Reply-To: "Gary E. Miller"
Content-Type: multipart/mixed; boundary="===5048660607478689576=="
Errors-To:devel-boun...@ntpsec.org
Sender: "devel"
X-Rspamd-Queue-Id: 9B21C286BBA
X-Spamd-Result: default: False [-2.31 / 15.00];
SIGNED_PGP(-2.00)[];
MIME_GOOD(-0.20)[multipart/mixed,multipart/signed,text/plain];
MAILLIST(-0.20)[mailman];
RCVD_NO_TLS_LAST(0.10)[];
HAS_LIST_UNSUB(-0.01)[];
TO_DN_NONE(0.00)[];
ARC_NA(0.00)[];
TO_EQ_FROM(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
FORGED_RECIPIENTS_MAILLIST(0.00)[];
MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
RCVD_COUNT_THREE(0.00)[4];
HAS_ORG_HEADER(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[devel@ntpsec.org];
RCVD_VIA_SMTP_AUTH(0.00)[];
HAS_REPLYTO(0.00)[g...@rellim.com];
FROM_NEQ_ENVFROM(0.00)[devel@ntpsec.org,devel-boun...@ntpsec.org];
FROM_HAS_DN(0.00)[];
TAGGED_RCPT(0.00)[ntpsec];
FREEMAIL_ENVRCPT(0.00)[rogers.com,protonmail.com,yahoo.com];
REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
FORGED_SENDER_MAILLIST(0.00)[]
X-Rspamd-Server: mx.ntpsec.org
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam detection software, running on the system 
"relay.anastrophe.com",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 postmas...@anastrophe.com  for details.



On 11/20/2022 18:54 PM, Gary E. Miller via devel wrote:

Yo All!

Test 4-5-6

✘Testing

[Gary E. Miller via devel]

Yo All!

Test 4-5-6


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgp8kDP5Yh13E.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

Worked for me.  Thanks.

What did you do/find?  Is it likely to stay working?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Gary E. Miller via devel]

ONE(0.00)[];
>   ARC_NA(0.00)[];
>   TO_EQ_FROM(0.00)[];
>   RCPT_COUNT_ONE(0.00)[1];
>   FORGED_RECIPIENTS_MAILLIST(0.00)[];
>   MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
>   RCVD_COUNT_THREE(0.00)[4];
>   HAS_ORG_HEADER(0.00)[];
>   PREVIOUSLY_DELIVERED(0.00)[devel@ntpsec.org];
>   RCVD_VIA_SMTP_AUTH(0.00)[];
>   HAS_REPLYTO(0.00)[g...@rellim.com];
>   FROM_NEQ_ENVFROM(0.00)[devel@ntpsec.org,devel-boun...@ntpsec.org];
>   FROM_HAS_DN(0.00)[];
>   TAGGED_RCPT(0.00)[ntpsec];
>   FREEMAIL_ENVRCPT(0.00)[rogers.com,protonmail.com,yahoo.com];
>   REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
>   FORGED_SENDER_MAILLIST(0.00)[]
> X-Rspamd-Server: mx.ntpsec.org
> X-Spam-Score: -0.6 (/)
> X-Spam-Report: Spam detection software, running on the system
> "relay.anastrophe.com", has NOT identified this incoming email as
> spam.  The original message has been attached to this so you can view
> it or label similar future email.  If you have any questions, see
>   postmas...@anastrophe.com  for details.
>   
> 
> 
> 
> On 11/20/2022 12:00 PM, Gary E. Miller via devel wrote:
> > Yo All!
> >
> > Testing 1-2-3...
> >
> >
> > RGDS
> > GARY
> > ---
> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
> > 97703 g...@rellim.com   Tel:+1  541 382 8588
> >
> > Veritas liberabit vos. -- Quid est veritas?
> >  "If you can't measure it, you can't improve it." - Lord Kelvin
> >
> > ___
> > devel mailing list
> > devel@ntpsec.org
> > https://lists.ntpsec.org/mailman/listinfo/devel  
> 




RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpjuBNikFHiG.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[Paul Theodoropoulos via devel]

unning on the system 
"relay.anastrophe.com",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 postmas...@anastrophe.com  for details.
 




On 11/20/2022 12:00 PM, Gary E. Miller via devel wrote:

Yo All!

Testing 1-2-3...


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin

___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


--
Paul Theodoropoulos
anastrophe.com <https://www.anastrophe.com>___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

✘Testing

[Gary E. Miller via devel]

Yo All!

Testing 1-2-3...


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgp3GWVhyIbcf.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

✘Testing 1-2-3...

[Gary E. Miller via devel]

Yo Al;!

Testing 1-2-3...


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgp_QTtbM1Lor.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel

Re: Runtime testing, What's the CI environment like?

[Matthew Selsky via devel]

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: Runtime testing, What's the CI environment like?

[Achim Gratz via devel]

There is a slight chicken/egg problem.  You can't test a released version
until it is released.


Yes you can.  The push of the commit and the tagging/pushing of the 
release tag can easily be separate events.



--
Achim.

(on the road :-)

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Runtime testing, What's the CI environment like?

[Richard Laager via devel]

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.

I posted a couple patches, which were merged; see `git log 9a85f93a`

FWIW, I don't build that refclock in the Debian package.

-- 
Richard



signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Runtime testing, What's the CI environment like?

[Hal Murray via devel]

> Possibly, but to test some of the code paths (NTS) would take about a day.
> Who wants to donate machine time for the runner? 

We can test most of the NTS code paths in a few seconds.

What did you have in mind for "about a day"?  The NTS cookie key gets updated 
every 24 hours.  The last-update-time is stored in the file.  We could test 
the update path without waiting a long time by setting up a file that will 
expire in a few seconds.

> Linux distros work, macOS some versions work, FreeBSD yes, NetBSD sorta, MS
> no, and everyone else can check. 

What's the "sorta" for NetBSD?

What do you mean by "can check"?  The idea of this sort of data base is to 
save time on checking and/or to point out holes in our known coverage in hopes 
that somebody will test and report.

I was thinking of a file or web page with a list of known tested cases.  Maybe 
a line per case with OS/distro, version, CPU type, version/date of ntpsec, and 
date of test.

There is a slight chicken/egg problem.  You can't test a released version 
until it is released.

> All refclocks are beleived to work.

Again, some of the gear is pretty old.  I'm sure Eric would be happy to nuke a 
few more drivers.  I'd like to see somebody raise their hand and say "working 
for me" so we could add a version/date line in a file.

Anybody using the modem driver?

I don't think we need a full OS/version/driver matrix.  There are probably 
enough quirks for some drivers that some notes would be useful.  For example, 
the hpgps works with several GPSDOs.  A list of known-working would be nice.

I'm only interested in the current version of ntpsec.  Maybe latest release 
and git head.  I expect some of the reports in the collection would not get 
updated with every release.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Runtime testing, What's the CI environment like?

[Sanjeev Gupta via devel]

On Sun, Sep 6, 2020 at 11:13 PM James Browning via devel 
wrote:

> On Fri, Sep 4, 2020 at 3:59 PM Hal Murray via devel 
> wrote:
> > Can we run ntpd long enough to test the initialization and much of the
> other code?
>
> Possibly, but to test some of the code paths (NTS) would take about a
> day. Who wants to donate machine time for the runner?
>


I could set up a VM farm, a dozen low-power machines with a mix of Linux
and BSDs.  Basically a large VMWare, and we can cut machines at need.  I
can commit to IPv4/IPv6, a nearby GPSd, etc.

And when I say "I can setup", I mean I can provide the infrastructure,
someone else will have to setup or talk me through the setup :-)

--
Sanjeev
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Runtime testing, What's the CI environment like?

[James Browning via devel]

On Fri, Sep 4, 2020 at 3:59 PM Hal Murray via devel  wrote:
> Can we run ntpd long enough to test the initialization and much of the other 
> code?

Possibly, but to test some of the code paths (NTS) would take about a
day. Who wants to donate machine time for the runner?

> I'm thinking of something like start ntpd, wait a while, then kill it.  While 
> it is running, we can also test ntpq.  The idea is to take advantage of the 
> handful of environments that are readily available.

Might I also suggest running something like gpsd, ntplog* and ntpviz as well?

> Is our code running as root?  Is ntpd (or whatever) running?  If so, can we 
> turn it off?

I think it runs as root. By default I seem to recall reading that is
is a Google compute instance so maybe? No, I don't think we could turn
it off if it is.

> I got a message from gitlab today about limiting/charging for CI time.  Is 
> that CPU seconds or wall-clock seconds?

Hence the sugestion for people to provide compute time. I do not know
which, I _assume_ wall clock time.

> Should we make a list of OS/distro/version known to work?

Linux distros work, macOS some versions work, FreeBSD yes, NetBSD
sorta, MS no, and everyone else can check.

> And another for refclocks?

All refclocks are beleived to work.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Runtime testing, What's the CI environment like?

[Hal Murray via devel]

Can we run ntpd long enough to test the initialization and much of the other 
code?

I'm thinking of something like start ntpd, wait a while, then kill it.  While 
it is running, we can also test ntpq.  The idea is to take advantage of the 
handful of environments that are readily available.

Is our code running as root?  Is ntpd (or whatever) running?  If so, can we 
turn it off?

---

I got a message from gitlab today about limiting/charging for CI time.  Is that 
CPU seconds or wall-clock seconds?

--

Should we make a list of OS/distro/version known to work?
And another for refclocks?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Testing

[James Browning via devel]

On Thu, Jul 23, 2020, at 10:59 AM Gary E. Miller via devel
 wrote:
>
> Yo All!
>
> Testing 1-2-3.  This list has been down since 13 Jul...

Funny, It looks like there were a couple of posts two days ago, and
before that nobody posting for a week. I think it was just sleeping or
hunting rabbits.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

✘Testing

[Gary E. Miller via devel]

Yo All!

Testing 1-2-3.  This list has been down since 13 Jul...

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpu0vVwupW4n.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[James Browning via devel]

On Mon, Jan 13, 2020 at 10:40 PM Hal Murray  wrote:
:::snip:::
> > Any particular distro anyone wants it to run on? j/k
>
> The idea is NOT to run it as part of a normal checkin, but have something in
> addition that could be triggered manually or by the equivalent of a cron job.
> I'm thinking of weekly or monthly and before a release.
>
> In that context, we should run it on all distros.
>
> It's a very low probability of finding problems, but better that we find them
> before the users do.

I just added a rough version of them as merge request !1082 at GitLab.

Minor points worth noting are that there are no working Debian/Ubuntu runners.
The macOS and FreeBSD runners are untested. The OpenSUSE runners need
a couple of mods to option-tester.sh

There are other mods to option-tester.sh, generating a  bit slicing
number to output
in case of detected errors, and the ability to use a custom Python
binary like python3.

I would prefer feedback only on GitLab, but I know some developers do
not use it.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[Hal Murray via devel]

matthew.sel...@twosigma.com said:
> 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. 

You can run them locally rather than waiting for the CI jobs to find problems.

tests/option-tester.sh tries to test all the options to waf and some of the 
interesting combinations.

tests/python{2,3}-tester.sh is an easy way to run a minimal test of the other 
python.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[Hal Murray via devel]

> It is, I could throw together a merge request. I am not a CI expert though.
> Next close person would be Matt Selsky I think.

> Any particular distro anyone wants it to run on? j/k 

The idea is NOT to run it as part of a normal checkin, but have something in 
addition that could be triggered manually or by the equivalent of a cron job.  
I'm thinking of weekly or monthly and before a release.

In that context, we should run it on all distros.

It's a very low probability of finding problems, but better that we find them 
before the users do.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[James Browning via devel]

On Mon, Jan 13, 2020 at 5:58 PM Eric S. Raymond via devel
 wrote:
>
> Hal Murray via devel :
> > 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?
>
> I've run it once or twice, but's not easty to see how to integraste
> it into our regularr test process.
>
> > 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?
>
> I have to defer to the CI expers on that one. It sounds like something
> that should be possible.

It is, I could throw together a merge request. I am not a CI expert though.
Next close person would be Matt Selsky I think.

Any particular distro anyone wants it to run on? j/k
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[Eric S. Raymond via devel]

Hal Murray via devel :
> 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?

I've run it once or twice, but's not easty to see how to integraste
it into our regularr test process.

> 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?

I have to defer to the CI expers on that one. It sounds like something
that should be possible.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python, testing

[Matthew Selsky via devel]

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: Python, testing

[Matthew Selsky via devel]

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

Python, testing

[Hal Murray via devel]

>From Gary:
>  I find if I do not test on python2 that I quickly break code.

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)

-

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

-

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)



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: gitlab testing broken for Fedora

[Matthew Selsky via devel]

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
> section_start:1566637579:after_script
> section_end:1566637580:after_script
> section_start:1566637580:upload_artifacts_on_failure
> section_end:1566637582:upload_artifacts_on_failure
> ERROR: Job failed: exit code 1
> 

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

gitlab testing broken for Fedora

[Hal Murray via devel]

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
section_start:1566637579:after_script
section_end:1566637580:after_script
section_start:1566637580:upload_artifacts_on_failure
section_end:1566637582:upload_artifacts_on_failure
ERROR: Job failed: exit code 1



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Mark Atwood, Project Manager via devel]

I "test" buildprep for Debian for every release, because I spin up a
small minimal Debian instance for each release.

One of my todo's is to collate and add to the docs the set of packages
I have apt-get each time.


On Fri, Sep 29, 2017 at 11:18 PM Hal Murray via devel  wrote:
>
>
> Should we test buildprep?  I think that means setting up a clean minimal
> system for each distro we claim to support.  Maybe we should document what we
> setup - the ISO used to make the CD/Thumb-drive and any options selected if
> there was a choice.
>
> Can we build the binaries and install them on a bare system to see if they
> really work and/or to build a dependencies list?
>
> Should we build a matrix of distro and refclock?  Some drivers have options
> to support various devices that are similar but different enough to be worth
> testing.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel



-- 
Mark Atwood 
Project Manager, https://NTPsec.org
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

Sorry for the delay.  I got distracted on other things.

While I think of it, did TESTFRAME dump floating point numbers in ASCII or 
hex?  If ASCII, there are likely to be round off errors when you read them 
back in.  Were there any floating point numbers that were read back in?  (as 
compared to loopstats where they are written out)


> How do you tell that any given capture represents correct operation? What
> check do you apply to the captured I/O history to verify that the sync
> algorithms were functioning as intended when the cature was taken?  *That's*
> the hard part - not the mechanics of TESTFRAME  itself, which is just
> tooling. 

OK, maybe we are getting someplace.

Is this a half full vs half empty problem?  I'm willing to assume that it is 
working correctly unless we get hints otherwise.

I'm trusting the guy who collects and contributes the sample data to verify 
that things are working correctly by looking at ntpq printout and/or graphs 
from log files and/or carefully reading ntpd.log and/or maybe other sources.  
This isn't a proof, but it's what we are currently using - the best we can do 
today.

In this context, there are two types of log files.  loopstats is probably best 
checked graphically.  ntpd.log may have single events or several related 
events that indicate that something happened.


> (You still don't know how to compose captures to trigger specied corner
> cases, but there's no point in worrying about that problem until you have
> your check procedure.)

Maybe "corner case" isn't the right term for the things I've been thinking 
about.  There are lots of cases that are reasonably easy to setup, but since 
there are a lot of them it would be nice if we could automate the procedure so 
I didn't have to go through the whole list every time we do a release.  
Testing at commit/push time is just a bonus.  Examples:
  Does "pool" work?  Do all the forms of crypto work?  All OSes/distros?  Does 
a single server work?  Does local clock work?  Can 2 truechimers outvote 1 
falseticker?

There may be actual obscure corner cases that are hard to generate.  I'd be 
willing to add logging for them so we can tell if an operational system hits 
them.

Do you remember anything about performance when collecting data?  I assume it 
would be reasonable to collect data on a client.  How much would it slow down 
a server?  How much disk space would a test require?

--

Things are likely to break if we change a constant deep in the system or add a 
sanity check for an obscure case.  We haven't done that in a long time, so I'm 
not too worried about that problem.  Breaking tests may be a feature rather 
than a bug.  It will make us think twice about making that change.  If we 
decide the change is worthwhile, then we have to start the collection over.



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Achim Gratz via devel]

Hal Murray via devel writes:
> Are the specs and implementation for IEEE floating point tight enough so that 
> I should get the exact same result if I run a test on a different CPU
> chip?

Formally yes, if you aren't straying into denormals and you keep
yourself to elementary operations that actually are specified by the
standard.  In practise, every code generated for a particular FPU
deviates a little from the standard in certain ways that sometimes can
be mitigated by setting flags nobody ever uses or even knows about.

> Or is there room for things like holding extra bits in temporary results so 
> the bottom bits might be different due to round off or such?

The assumption is that the rounding happens as prescribed in the
standard after each operation.  Things like FMA, some compiler
optimizations and the extra mantissa bits on Intel throw a spanner into
this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Gary E. Miller via devel]

Yo Hal!

On Mon, 15 Jul 2019 17:15:34 -0700
Hal Murray via devel  wrote:

> Are the specs and implementation for IEEE floating point tight enough
> so that I should get the exact same result if I run a test on a
> different CPU chip?

Better than it used to be, but you will still want to use a guardband.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpUu32JSAXnl.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

OT: tolerance was Re: Testing

[James Browning via devel]

On Mon, Jul 15, 2019, 5:15 PM Hal Murray via devel  wrote:

>
> tenterl...@gmail.com said:
> > I come from a scientific background, where we compare results somewhat as
> > analog values. If the test result is off the expected by 1000%, that's
> bad.
> > If it's off 1%, better. If the error is .1%, probably within
> achievable
> > accuracy.
>
> There is a difference between running the same experiment again to get new
> data and running new software on old data.
>
> Are the specs and implementation for IEEE floating point tight enough so
> that
> I should get the exact same result if I run a test on a different CPU
> chip?
> Or is there room for things like holding extra bits in temporary results
> so
> the bottom bits might be different due to round off or such?
>

Possibly. But I would say have a tight tolerance and a not so tight one. If
the absolute difference is less than both paint it green, if only one then
yellow, and for neither red. I'm probably wrong though.

>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

tenterl...@gmail.com said:
> I come from a scientific background, where we compare results somewhat as
> analog values. If the test result is off the expected by 1000%, that's bad.
> If it's off 1%, better. If the error is .1%, probably within  achievable
> accuracy. 

There is a difference between running the same experiment again to get new 
data and running new software on old data.

Are the specs and implementation for IEEE floating point tight enough so that 
I should get the exact same result if I run a test on a different CPU chip?  
Or is there room for things like holding extra bits in temporary results so 
the bottom bits might be different due to round off or such?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Tom Enterline via devel]

Please excuse an outsider jumping into the conversation.

AIUI, the testing under discussion is what I think of as the system
programming type - if we have inputs A and B to a black box, and the
test reproduces output C exactly, bit-for-bit, then the test is a
success, otherwise it is a complete failure.

I come from a scientific background, where we compare results somewhat
as analog values. If the test result is off the expected by 1000%,
that's bad. If it's off 1%, better. If the error is .1%, probably
within  achievable accuracy.

NTP is dealing with digital approximations to real-world, analog
values. So if a test outputs a time within 1 nsec of the reference
output, maybe it's 'good'.

Also AIUI, one issue is that the there is a black box, that no one
alive really understands. I suggest creating a simplified version of
the box (level 0) that is easy to understand. Maybe all it does is
echo the last time it received -- no fancy filtering, floating point
tricks, adjtimex, etc. Then all the rest of the machinery (config file
reads, server selection, UDP, etc.) could run and have results that
are easily predictable. Then a level 1 box could add a few more
features that would exercise more of the code, etc.

I'm not saying this would be easy, I'm sure the there isn't an obvious
replaceable black box.

Eric,
If this is one of the many approaches you already considered, I
apologize for wasting your time.

Tom

On Mon, Jul 15, 2019 at 9:04 AM Eric S. Raymond via devel
 wrote:
>
> Hal Murray :
> >
> > > It's...hm...maybe a good way to put it is that the structure of the NTPsec
> > > state space and sync algorithms is extremely hostile to testing.
> >
> > I still don't have a good understanding of why TESTFRAME didn't work.  I 
> > can't
> > explain it to somebody.
> >
> > We've got
> >   code mutations
> >   hidden variables in the FSM
> >   hostile
> >
> > So what makes it hostile?  Is it more than just complexity?
>
> Once you have TESTFRAME in place, and are logging all the input state
> including things like the system clock and PLL state, and all the oput
> state too, it's just complexity.  But that "just" is a doozy.
>
> Let me refocus on the basic question here.  Let's say you've put
> TESTFRAME back in place and finished it.  You can now start ntpd up
> and make captures that include all of the input state of the FSM and
> all of its outputs.
>
> How do you tell that any given capture represents correct operation?
> What check do you apply to the captured I/O history to verify that the
> sync algorithms were functioning as intended when the cature was
> taken?  *That's* the hard part - not the mechanics of TESTFRAME
> itself, which is just tooling.
>
> If you have such a check, then TESTFRAME can be used to verify
> correctness of operation.  You do it the way I built a test suite for
> GPSD. You take a whole bunch of captures. Run your magic check on the
> relationship between input and output to verify that operation
> is correct on each.  Stash the captures in the tests directory.  Then,
> when you change the code, you rerun each of the caputures. If actual
> and expected outputs don't diverge, you're good.
>
> (You still don't know how to compose captures to trigger specied corner
> cases, but there's no point in worrying about that problem until you
> have your check procedure.)
>
> In GPSD, the magic check is just looking at a capture, because the
> correctness of the relationship between input packets and output JSON
> is pretty easy for an unaided Mark I Brain to verify.  In reposurgeon
> it's a little tricker to verify that a load/checkfile pair represents
> correct operation, but not all that diificult for small carefully
> crafted cases.  You end up crafting a lot of small cases - I have 145
> of them.
>
> I don't know how to write that check for NTPsec captures - it sure as
> hell can't be done by eyeballing the packet traffic.  That's the first part
> of I mean by "hostile to testing"; there are other issues, but until
> we know how to address this one there's little point in even
> enumerating them.
>
> In the absence of such a check procedure for captures,
> TESTFRAME is nearly useless. You can use it to test
> same-input-same-output stability over time but that's about it.
>
> > Why isn't this sort of testing even more valuable when things get complex?
>
> Of course it would be more valuable because things are complex.  If it
> were practical at all; I don't think it is.  I would be very happy if
> you were to prove me wrong.
>
> > How do we tell that it is working without TESTFRAME?  I eyeball ntpq -p 
> > and/or
> > graphs of loopstats and friends.  That's using the stats files as a sum

Re: Testing

[Eric S. Raymond via devel]

Hal Murray :
> 
> > It's...hm...maybe a good way to put it is that the structure of the NTPsec
> > state space and sync algorithms is extremely hostile to testing.
> 
> I still don't have a good understanding of why TESTFRAME didn't work.  I 
> can't 
> explain it to somebody.
> 
> We've got
>   code mutations
>   hidden variables in the FSM
>   hostile
> 
> So what makes it hostile?  Is it more than just complexity?

Once you have TESTFRAME in place, and are logging all the input state
including things like the system clock and PLL state, and all the oput
state too, it's just complexity.  But that "just" is a doozy.

Let me refocus on the basic question here.  Let's say you've put
TESTFRAME back in place and finished it.  You can now start ntpd up
and make captures that include all of the input state of the FSM and
all of its outputs.

How do you tell that any given capture represents correct operation?
What check do you apply to the captured I/O history to verify that the
sync algorithms were functioning as intended when the cature was
taken?  *That's* the hard part - not the mechanics of TESTFRAME 
itself, which is just tooling.

If you have such a check, then TESTFRAME can be used to verify
correctness of operation.  You do it the way I built a test suite for
GPSD. You take a whole bunch of captures. Run your magic check on the
relationship between input and output to verify that operation
is correct on each.  Stash the captures in the tests directory.  Then,
when you change the code, you rerun each of the caputures. If actual
and expected outputs don't diverge, you're good.

(You still don't know how to compose captures to trigger specied corner
cases, but there's no point in worrying about that problem until you
have your check procedure.)

In GPSD, the magic check is just looking at a capture, because the
correctness of the relationship between input packets and output JSON
is pretty easy for an unaided Mark I Brain to verify.  In reposurgeon
it's a little tricker to verify that a load/checkfile pair represents
correct operation, but not all that diificult for small carefully
crafted cases.  You end up crafting a lot of small cases - I have 145
of them.

I don't know how to write that check for NTPsec captures - it sure as
hell can't be done by eyeballing the packet traffic.  That's the first part
of I mean by "hostile to testing"; there are other issues, but until
we know how to address this one there's little point in even
enumerating them.

In the absence of such a check procedure for captures,
TESTFRAME is nearly useless. You can use it to test
same-input-same-output stability over time but that's about it.

> Why isn't this sort of testing even more valuable when things get complex?

Of course it would be more valuable because things are complex.  If it
were practical at all; I don't think it is.  I would be very happy if
you were to prove me wrong.

> How do we tell that it is working without TESTFRAME?  I eyeball ntpq -p 
> and/or 
> graphs of loopstats and friends.  That's using the stats files as a summary 
> of 
> the internal state.

OK, you have something resembling a check procedure.  I can't do that.  I
don't know enough about the visible signs of correct vs. incorrect 
operation to trust my ability to tell.

Now we get to the next kind of hostility to testing.  How do you compose
captures so they explore some desired set of transitions in the daemon?
I know how to do that in GPSD and reposurgeon; I haven't the faintest
clue how to do it in NTPsec.

And the next. Test-pair brittleness. Reposurgeon tests never break
once composed unless I decide to deliberately change the behavior of a
feature. In GPSD test pairs will break only when the leap offset goes
up, or on era rollover.  Those are rare events because GPSD relies on
very little hidden or retained state between packet bursts.

ntpd retains a huge amount of state (packet queues for median
filtering, etc).  That's why reasoning forward from inputs to outputs, 
or backwards from outputs to inputs, would be brutally hard
even for someone with perfect knowledge of the sync-algorithm
theory of operation.  There's sensitive dependence on that state.

> Did TESTFRAME capture the stats files?

I think they became part of the TESTFRAME capture.  If they didn't, that would
be easy to fix.  That's just mechanics, it's not the hard part.

> With a bit more logging, we could probably log enough data so that it would 
> be possible to do the manual verification of what is going on.  We would have 
> to write a memo explaining how it works, maybe that would include chunks of 
> pseudo code.

Good luck. I did not have the knowledge base to do that. If you do, more power 
to you.

> How much of the problem is that Eric didn't/doesn't understand the way the 
> inner parts of ntpd work?  I've read the descriptions many times but I still 
&g

Re: Testing

[Hal Murray via devel]

> Can you get them to specify exactly what they want?

One thing to add to the list if you are going to collect NTP data...

If you know that the clocks at both ends are accurate, rawstats will give you 
the transit times in each direction.

NTP assumes the transit times in each direction are equal.  There are two 
common reasons that isn't true.  One is asymmetric routing.  The other is 
queuing delays.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Eric S. Raymond via devel]

Mark Atwood, Project Manager :
> Oh, believe me, cloud scale devops shops know what to do with all the
> timing information.

Can you get them to specify exactly what they want?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Mark Atwood, Project Manager via devel]

> This would actually be pretty easy to do, mechanically speaking.  The
hard question is what you do with this timing information once you have it.

Oh, believe me, cloud scale devops shops know what to do with all the
timing information.


On Sun, Jul 14, 2019 at 3:19 PM Eric S. Raymond  wrote:
>
> Mark Atwood :
> > I want to encourage Hal to think of ways of cracking these problems.
> >
> > Especially the idea of verifying key parts of the state space, even if
> > we can't verify it all.
>
> I wish him the best of luck...
>
> > And especially if there was a way to usefully log the relative timing
> > of various important state transitions.  (That is something on the
> > wishlist of the AWS NTP Kronos team.)
>
> This would actually be pretty easy to do, mechanically speaking.  The
> hard question is what you do with this timing information once you have it.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
>


-- 
Mark Atwood 
Project Manager, https://NTPsec.org
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

> It's...hm...maybe a good way to put it is that the structure of the NTPsec
> state space and sync algorithms is extremely hostile to testing.

I still don't have a good understanding of why TESTFRAME didn't work.  I can't 
explain it to somebody.

We've got
  code mutations
  hidden variables in the FSM
  hostile

So what makes it hostile?  Is it more than just complexity?

Why isn't this sort of testing even more valuable when things get complex?

-

> If you try to do this kind of eyeballing in NTPsec it will make your brain
> hurt.  It's not just that the input and output packets are binary, that's
> superficial and fixable with textualization tools I can write in my sleep.
> Fine, let's say you've done that. You've got an interleaved stream of input
> and output timestamps.  How do you reason through the sync algorithms to know
> whether the relationships are correct? 

How do we tell that it is working without TESTFRAME?  I eyeball ntpq -p and/or 
graphs of loopstats and friends.  That's using the stats files as a summary of 
the internal state.

Did TESTFRAME capture the stats files?

With a bit more logging, we could probably log enough data so that it would be 
possible to do the manual verification of what is going on.  We would have to 
write a memo explaining how it works, maybe that would include chunks of pseudo 
code.

How much of the problem is that Eric didn't/doesn't understand the way the 
inner parts of ntpd work?  I've read the descriptions many times but I still 
don't understand it well enough to explain it to somebody.  Maybe I could work 
up a presentation with the code in one hand and the descriptions in the other 
hand.  It would take a while.  That is, I know the general idea and recognize 
all the pieces but don't have a good feel for how the pieces fit together to 
make up the big picture.


> Not only are there time-dependent hidden inputs to the computation from the
> kernel clock and PLL, but they're going to be qualitatively different
> depending on whether you have an adjtimex or not.

There wasn't supposed to be anything hidden.  TESTFRAME was supposed to 
intercept all the relevant calls like getting the time from the kernel.

I'm pretty sure we gave up on systems that don't support adjtimex.  OpenBSD 
doesn't have it, but does have enough to slew the clock.  We dropped support 
for OpenBSD when that shim was removed.



How far did you get with TESTFRAME?  Do you remember why you decided to give 
up?  Was there something in particular, or did you just get tired of banging 
your head against the wall?

How many lines of code went away when you removed it?

Would it be interesting for me to take a try?  Now isn't a good time and there 
may be more important things to work on, but I think we should explore and 
understand this option.



But back to the big picture.  How can we test corner cases?

Is it reasonable to look for patterns in the log file?

Is it reasonable to look for patterns in the output of ntpq -p?  Graphs?

When you do a Go port, what can you do to make testing easier?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Eric S. Raymond via devel]

Mark Atwood :
> I want to encourage Hal to think of ways of cracking these problems.
> 
> Especially the idea of verifying key parts of the state space, even if
> we can't verify it all.

I wish him the best of luck...

> And especially if there was a way to usefully log the relative timing
> of various important state transitions.  (That is something on the
> wishlist of the AWS NTP Kronos team.)

This would actually be pretty easy to do, mechanically speaking.  The
hard question is what you do with this timing information once you have it.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

> Especially the idea of verifying key parts of the state space, even if we
> can't verify it all. And especially if there was a way to usefully log the
> relative timing of various important state transitions.  (That is something
> on the wishlist of the AWS NTP Kronos team.) 

What are they looking for?

I think all the major state transitions get logged in protostats.  (if enabled)

-

Eric:  Did your work on TESTFRAME capture the calls to the stats routines?  
(or their output, if enabled)


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Eric S. Raymond via devel]

Hal Murray :
> Your writeup focuses on code mutations rather than state space.  (Or maybe I 
> didn't read what you intended.)

Perhaps I could have been clearer.  But those two problems run
together in my mind becauase of what unifies them and contrasts
with the GPSD and reposurgeon cases.

It's...hm...maybe a good way to put it is that the structure of the
NTPsec state space and sync algorithms is extremely hostile to
testing.

In reposurgeon, when I want to test a command it's generally not too
difficult to hand-craft a repository with the relevant features, run
the command, look at the output repo and verify that the
transformation is as expected.  In GPSD one of the things that makes
the test suite work so well is that by eyeballing a check file you can
actually see the correctness of the relationship between a sentence
burst fom the GPS and the JSON it's transformed into.

If you try to do this kind of eyeballing in NTPsec it will make your
brain hurt.  It's not just that the input and output packets are
binary, that's superficial and fixable with textualization tools I can
write in my sleep. Fine, let's say you've done that. You've got an
interleaved stream of input and output timestamps.  How do you reason
through the sync algorithms to know whether the relationships are
correct?

Not only are there time-dependent hidden inputs to the computation from
the kernel clock and PLL, but they're going to be qualitatively
different depending on whether you have an adjtimex or not.  Yes,
sure, you can expose all those inputs in your test loads, but now what
you have is a mess of numbers related through algorithms with an
intractably large number of moving parts. Every bit of state retained
between packet-handler invocations is a moving part. So is every
configuration option.

And there's no smoothness in the test space. In reposurgeon or GPSD I
can take an existing test, modify it, and often know with reasonable
certainty how the code path traversed will change and whee the new
check file will differ. In NTPsec it's nonlinearities and edge
triggers all the way down.

What I found out after writing almost all the mechanics of TESTFRAME
is that once you have it you slam into a wall that better tooling is
zero help with. There's no way to get enough of a causal handle on
what's going on to be sure you can test even simple features like
outlier clipping.  General verification of correctness is *completely*
out of reach; the best you can do is test for (a) same-input-same-output
stability and (b) try to cover enough code paths to smoke out the 
core dumps.

In forty-odd years of software engineering I've never seen another
testing problem this wicked.  I don't really expect to see one
if I live another forty.

> The "known to be interesting" phrase gets back to my query that
> started this thread.  I'm looking for a way to test corner cases.
> Would TESTFRAME would have done that?

Given a set of inputs that triggers a corner case, yes.  The
problem is *how do you compose that input load?*

There are simple cases in when you can do this.  An obvious one 
is writing perverse configurations to try to crash ntpd on
startup. The problem is that those aren't *interesting* cases -
testing them would be like looking for your car keys under
a streetlight because the light is good even though you
dropped them in the dark two blocks over.

> If we don't like TESTFRAME, what else can we do?

In principle? Fuzz-probe for core dumps.  *With* TESTFRAME, we could
test for same-input/same-output stability. And that's about it.

I've had four years to think about this problem. If there were 
a way over, under, or around it I do not think it would have
taken me that long to spot it.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

e...@thyrsus.com said:
> A lot of configuration options - even things like minsane - effectively
> change the FSM. 

Right.  But as you said, that's a configuration option.

> Sure, you can think of the config as part of the input state - this isn't a
> code mutation. But it also means you can only ever test very tiny parts of
> the input-state space, with no way to know when a config change might produce
> a boojum and tyically no way to have real confidence about how a test relates
> to behavior under any change in ...

Sure, but we can't currently test any of the state space.  I'd be very happy if 
we could test parts of the state space that are known to be interesting.

Your writeup focuses on code mutations rather than state space.  (Or maybe I 
didn't read what you intended.)

How do code mutations interact with the state space?  Do you have an example of 
a code mutation that would change things and that we wouldn't want to know 
about?

I expect changes in the logging would be the most common problem.  In most 
cases, I'd expect it would be a simple eyeball check on a diff and poke a 
button to accept the new version.  Did TESTFRAME have separate logging for the 
gettime call used for logging?



The "known to be interesting" phrase gets back to my query that started this 
thread.  I'm looking for a way to test corner cases.  Would TESTFRAME would 
have done that?

If we don't like TESTFRAME, what else can we do?

Can we look for patterns in the log file from a live run?This has the 
advantage of not requiring any changes to ntpd.

It gets complicated with lost packets and widely variable timing on the big bad 
internet.  A local net might be stable enough.

Suppose that works.  Can we describe the required configuration so that tests 
that start on my environment can be run on other environments?  I'm thinking of 
things like $BOB is a local stratum 2 server, $TED is local stratum 3.  ...

---

I'd like a way to test various OSes and hardware platforms.  I can think of two 
interesting areas.

One is the basic timekeeping - ntp_adjtime and friends.  Does normal ntpd work 
in some simple configuration.

The other is OpenSSL and friends.  That library gets a lot of attention, but 
it's large and we could be hitting a corner that doesn't get tested.  Various 
OSes/distros are running different versions and different patch levels and our 
code could have bugs in my attempts to dance around API changes.
 

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Eric S. Raymond via devel]

Hal Murray :
> I agree that the core FSM is complicated, but how often do we change it?

A lot of configuration options - even things like minsane - effectively change
the FSM.

Sure, you can think of the config as part of the input state - this
isn't a code mutation. But it also means you can only ever test very
tiny parts of the input-state space, with no way to know when a config
change might produce a boojum and tyically no way to have real
confidence about how a test relates to behavior under any change in
configuration at all (I note an exception below). This is a kind
of brittleness that GPSD and reposurgeon don't have,

>It would be great to be able to run regression 
> tests after adding NTS.  Yes, we would have to add new test cases in order to 
> test NTS, but all the old tests should keep on working.

NTS is, I think, special. In a good way that other forms of auth share. 
There's a kind of decomposability about it - you can say with reasonable
confidence that once you're past a certain fairly early stage in the
packet-processing pipeline nothing about auth matters any more.

So yes, that's a corner of the testing problem that can probably be
bitten off.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Hal Murray via devel]

e...@thyrsus.com said:
> https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html
> Read that and think about it for a while.  This is a very hard problem.  I
> hit it and bounced.

Thanks.

>From the blog page:
> In effect, the entire logic of the sync algorithms is a gigantic free
> parameter with no real equivalent in the simple, straight-line data
> transformations of gpsd, and only a weak analogy with the somewhat more
> complex but variable-free ones of reposurgeon. 

> Under these assumptions, there is some mutation rate threshold above which
> attempting deterministic replay simply stops being useful at all, because the
> gains from it are exceeded by the complexity costs of updating tests. GPSD
> and reposurgeon are well below that threshold; I now think ntpd is above it. 

I think I understand the ideas, but it's not making sense.

I agree that the core FSM is complicated, but how often do we change it?  I 
can't think of any changes, aka the mutation rate is close to zero.  Things 
like NTS are on the periphery.  It would be great to be able to run regression 
tests after adding NTS.  Yes, we would have to add new test cases in order to 
test NTS, but all the old tests should keep on working.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing

[Eric S. Raymond via devel]

Hal Murray via devel :
> Eric: What is the name/term for your attempt at capturing and replaying 
> things?  Is there a good writeup of why it didn't work?

https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html

Read that and think about it for a while.  This is a very hard
problem.  I hit it and bounced.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Testing

[Hal Murray via devel]

(Context is that I went to edit a config file to test something and I ran into 
some cruft leftover from testing something else.)

Handwave...

There are a zillion corner cases that I'd like to be able to test.  A typical 
example is something like: with configuration X, Y should happen.  You can 
check that by looking in the log file or using ntpq.

With something like a compiler that shouldn't be timing dependent, it's 
straightforward to setup a system for feeding a small chunk of code to the 
compiler and comparing the output to a known good pattern.  Once you have 
that, then you can collect all the small chunks used to diagnose bugs and add 
a wrapper to run the whole collection.

But NTP is all about timing.

Eric: What is the name/term for your attempt at capturing and replaying 
things?  Is there a good writeup of why it didn't work?

Anybody know anything about finding things in log files?  I think I could 
setup a fuzzy pattern to search for.  I can think of 3 results: pass, fail, 
and timeout.

Matching ntpq output gets more complicated.  I think we would need a way to 
identify slots and constrain the value.

If I had something like that working in my environment, how would we run as 
much as possible on your environment?  Maybe variables in the config file for 
server names?  So I could use my local servers and you could use yours.

Does any of that make sense?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

init for testing code

[Hal Murray via devel]

I'm adding a trap to ntplib/lib_getbuf() that needs to get initialized.

I found main() in tests/common/tests_main.c, but I can't find any similar 
initialization in the python testers.

Where should I be looking?


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

I just pushed some changes that should help your testing

[Hal Murray via devel]

I split out the ssl parts of processing in nts_server.  I didn't change 
nts_client yet.

I think I put the routines you want into nts.h



I think you can test cookies.  That will exercise the AES_SIV crypto routines.

You will need to call nts_cookie_init (to setup the crypto context)

If you call nts_cookie_init2, it will read in the "old" cookie passwords from 
a file.
You can point it at the right file by storing a filename in ntsconfig.KI,
else it uses a default.

You can avoid a file by calling  nts_make_cookie_key

To make a cookie, you have to feed nts_make_cookie
  a place to put the cookie  (NTS_MAX_COOKIELEN)
  aean - code for crypto algorithm to use.  Legal values are
  AEAD_AES_SIV_CMAC_xxx for xxx in 256, 384, and 512
  2 keys - you will have to invent them
  keylength: matches aean, values are 32, 48, and 64

unpack cookie should give you back aead, and the 2 keys and length

If you call nts_make_cookie the current key gets pushed to the old key
and the previous old key is lost.  If you call it again, the initial good key 
is lost and unpack_cookie will fail.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SSL structs and testing

[Ian Bruene via devel]

On 4/1/19 12:00 AM, Hal Murray via devel wrote:

There is some cleanup I've wanted to do in that area anyway.  I'll try to get
to it tonight.


Noted, will wait before stirring it up.


Only that it seemed reasonable at the time.  I was more interested in getting
things working than how to test things after we got it working.


That is what I expected. But there is enough I don't understand that I 
wanted to check.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SSL structs and testing

[Hal Murray via devel]

> After staring at the code for long enough I see a number of natural  cleavage
> points for solving this issue. MR in a few days. 

There is some cleanup I've wanted to do in that area anyway.  I'll try to get 
to it tonight.

> Is there any particular reason why SSL structs need to be passed all  over
> the place to functions that do not depend on SSL itself? 

Only that it seemed reasonable at the time.  I was more interested in getting 
things working than how to test things after we got it working.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: SSL structs and testing

[Ian Bruene via devel]

After staring at the code for long enough I see a number of natural 
cleavage points for solving this issue. MR in a few days.


On 3/31/19 2:33 PM, Ian Bruene wrote:


Is there any particular reason why SSL structs need to be passed all 
over the place to functions that do not depend on SSL itself?


The notable example here is nts_ke_do_recieve, which only uses the SSL 
to pass to SSL_read. I don't see any obvious reason that couldn't be 
done in the calling function and then pass the buffer instead as the 
logic doesn't depend on SSL, but on the buffer. As it is now, writing 
tests for many of the most important functions in the nts codebase is 
difficult at best because they require setting up SSL, which means 
faking a connection, which is already awkward and verbose in languages 
that make for easy shimming, let alone C.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are 
fit to occupy it."/ -- Sophia Lamb




--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

SSL structs and testing

[Ian Bruene via devel]

Is there any particular reason why SSL structs need to be passed all 
over the place to functions that do not depend on SSL itself?


The notable example here is nts_ke_do_recieve, which only uses the SSL 
to pass to SSL_read. I don't see any obvious reason that couldn't be 
done in the calling function and then pass the buffer instead as the 
logic doesn't depend on SSL, but on the buffer. As it is now, writing 
tests for many of the most important functions in the nts codebase is 
difficult at best because they require setting up SSL, which means 
faking a connection, which is already awkward and verbose in languages 
that make for easy shimming, let alone C.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Gary E. Miller via devel]

Yo Hal!

On Thu, 21 Mar 2019 21:49:31 -0700
Hal Murray via devel  wrote:

> > What's your environment?  I'm passing  "ntp" to getaddrinfo.
> > Ah, that's the bug.  Don't do that.  There is no offical tcp/ntp
> > port assigned.  So trying to look it up is not going to work
> > well...   
> 
> For "not going to work", it took a long time to fail.

A few hours seems pretty quick to me.

> Fix pushed.

Thanks!

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpzbDqx61jOC.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Hal Murray via devel]

> What's your environment?  I'm passing  "ntp" to getaddrinfo.
> Ah, that's the bug.  Don't do that.  There is no offical tcp/ntp port
> assigned.  So trying to look it up is not going to work well... 

For "not going to work", it took a long time to fail.

Fix pushed.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Sanjeev Gupta via devel]

Gary,

It works with a mix of NTS and NTP, I removed the NTP to force it to sync
with your servers.

All seems OK now.


On Fri, Mar 22, 2019, 12:20 PM Gary E. Miller  wrote:

> Yo Sanjeev!
>
> On Fri, 22 Mar 2019 08:31:34 +0800
> Sanjeev Gupta  wrote:
>
> > I removed all non-NTS servers from my config,and I am now synced!!!
>
> Weird.  I can run with a mix of plain NTPD and NTS/NTPD.
>
> > No rest for the helpful: How do I check if I am an NTS server?
>
> I like Hal's suggestions.  I also check with: nmap pi3 -p 123
>
>
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Gary E. Miller via devel]

Yo Sanjeev!

On Fri, 22 Mar 2019 08:31:34 +0800
Sanjeev Gupta  wrote:

> I removed all non-NTS servers from my config,and I am now synced!!!

Weird.  I can run with a mix of plain NTPD and NTS/NTPD.

> No rest for the helpful: How do I check if I am an NTS server?

I like Hal's suggestions.  I also check with: nmap pi3 -p 123



RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpFY4BptBwuU.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Gary E. Miller via devel]

Yo Hal!

On Thu, 21 Mar 2019 17:49:55 -0700
Hal Murray via devel  wrote:

> > 2019-03-22T03:56:32 ntpd[21039]: NTSc: nts_probe: DNS error trying
> > to contact pi3.rellim.com: -8, Servname not supported for
> > ai_socktype  
> 
> What's your environment?  I'm passing  "ntp" to getaddrinfo.

Ah, that's the bug.  Don't do that.  There is no offical tcp/ntp
port assigned.  So trying to look it up is not going to work well...

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpPHytk1bcF2.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Hal Murray via devel]

> No rest for the helpful: How do I check if I am an NTS server?

The real check is that somebody can connect to your server.

Other maybe helpful sources of info:

netstat -tl

Should show:
tcp0  0 0.0.0.0:ntp 0.0.0.0:*   LISTEN 
tcp6   0  0 [::]:ntp[::]:*  LISTEN 


There should be a few messages in the log file during initialization.

21 Mar 13:56:43 ntpd[705]: NTSs: starting NTS-KE server listening on port 123
21 Mar 13:56:43 ntpd[705]: NTSs: loaded certificate (chain) from 
/etc/ntp/hgm.example.com.cert-chain.pem
21 Mar 13:56:43 ntpd[705]: NTSs: loaded private key from 
/etc/ntp/hgm.example.com.key.pem
21 Mar 13:56:43 ntpd[705]: NTSs: Private Key OK
21 Mar 13:56:43 ntpd[705]: NTSs: OpenSSL security level is 1
21 Mar 13:56:43 ntpd[705]: NTSs: listen4 worked
21 Mar 13:56:43 ntpd[705]: NTSs: listen6 worked
21 Mar 13:56:43 ntpd[705]: NTSc: Using system default root certificates.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Hal Murray via devel]

> Been runnig for a few hours now.  ntpq -pn output:
...

> And the log is here:  https://pastebin.com/fM9uDwVi
Thanks.


> 2019-03-22T03:56:32 ntpd[21039]: NTSc: nts_probe: DNS error trying to contact
> pi3.rellim.com: -8, Servname not supported for ai_socktype

What's your environment?  I'm passing  "ntp" to getaddrinfo.

Can you try pi3.rellim.com:123?



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Sanjeev Gupta via devel]

Gary,

I removed all non-NTS servers from my config,and I am now synced!!!
root@ntpmon:~/ntpsec# ntpq -p
 remote   refid  st t when poll
reach   delay   offset   jitter
===
*pi3.rellim.com  .PPS.1 8   63   64
377 199.4428   1.5205   0.5291
+kong.rellim.com 54.165.164.242 8-   64
377 210.1074   1.5080   1.3453
-104.131.155.175 204.123.2.72 2 8   57   64
377 178.6117   6.7752   1.3341
+178.62.68.7917.253.34.2532 8   58   64
377 185.7336  -0.4399   0.4358

Thank you.  I will review the docs and add my 5-line HOWTO later today.

No rest for the helpful: How do I check if I am an NTS server?

-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane


On Fri, Mar 22, 2019 at 7:45 AM Gary E. Miller via devel 
wrote:

> Yo Sanjeev!
>
> > > Looks good.  What is your server so I can try to connect back?
> > My server is ntpmon.dcs1.biz .  It is in the pool, BTW.
>
> I can't connect to any NTS from kong now.  Not getting any cookies.
> Some of my other 3 still work in various combinations.
>
> I'm not putting NTS on my one pool server yet.
>
> I tried to connect from my backup (1.0.1r), no cookies.
>
> 2019-03-21T16:40:59 ntpd[24257]: DNS: dns_probe: ntpmon.dcs1.biz,
> cast_flags:1, flags:
> 21801
> 2019-03-21T16:41:01 ntpd[24257]: NTSc: DNS lookup of ntpmon.dcs1.biz took
> 1.749 sec
> 2019-03-21T16:41:01 ntpd[24257]: NTSc: nts_probe connecting to
> ntpmon.dcs1.biz:ntp =>
> [2405:fc00:0:1::123]:123
> 2019-03-21T16:43:12 ntpd[24257]: NTSc: nts_probe: connect failed:
> Connection timed out
> 2019-03-21T16:43:12 ntpd[24257]: DNS: dns_check: processing
> ntpmon.dcs1.biz, 1, 21801
> 2019-03-21T16:43:12 ntpd[24257]: DNS: dns_take_status: ntpmon.dcs1.biz=>error,
> 12
>
>
> > > What version of OpenSSL do you have?  I'm finding that matters.
> > >
> >
> > root@ntpmon:~/ntpsec# openssl version -a
> > OpenSSL 1.1.1a  20 Nov 2018
>
> I'm guessing version mismatch.  Try my pi3.rellim.com, or backup, which
> are on 1.0.2r.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Sanjeev Gupta via devel]

Gary,

Adding this to /etc/services seems to fix the issue:
ntp 123/tcp # Network Time Protocol

I now see:
-pi3.rellim.com  .PPS.1 84   64
37 197.8958   0.5317   0.4966
-kong.rellim.com 204.17.205.172 85   64
37 211.0267  -1.1571   0.7353
-104.131.155.175 204.123.2.72 2 83   64
37 178.6108   4.1158   0.2288
-178.62.68.7917.253.34.2532 8-   64
37 185.7613  -2.6144   0.0452

And a snip from the log file says:
2019-03-22T07:43:48 ntpd[12580]: NTSc: nts_probe connecting to
pi3.rellim.com:ntp => 204.17.205.23:123
2019-03-22T07:43:49 ntpd[12580]: NTSc: Using TLSv1.2, AES256-GCM-SHA384
(256)
2019-03-22T07:43:49 ntpd[12580]: NTSc: certificate subject name: /CN=
pi3.rellim.com
2019-03-22T07:43:49 ntpd[12580]: NTSc: certificate issuer name:
/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
2019-03-22T07:43:49 ntpd[12580]: NTSc: certificate is valid.
2019-03-22T07:43:49 ntpd[12580]: NTSc: read 880 bytes
2019-03-22T07:43:49 ntpd[12580]: NTSc: Got 8 cookies, length 104, aead=15.
2019-03-22T07:43:49 ntpd[12580]: NTSc: NTS-KE req to pi3.rellim.com took
0.863 sec, OK
2019-03-22T07:43:49 ntpd[12580]: DNS: dns_check: processing pi3.rellim.com,
1, 21801
2019-03-22T07:43:49 ntpd[12580]: DNS: Server taking: 204.17.205.23
2019-03-22T07:43:49 ntpd[12580]: DNS: Server poking hole in restrictions
for: 204.17.205.23
2019-03-22T07:43:49 ntpd[12580]: DNS: dns_take_status: pi3.rellim.com=>good,
0

-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane


On Fri, Mar 22, 2019 at 7:32 AM Sanjeev Gupta  wrote:

> On Fri, Mar 22, 2019 at 7:24 AM Gary E. Miller via devel 
> wrote:
>
>> > I have been lurking and trying to set up NTS to talk to the rellim.com
>> > servers.  This is a recent git head.
>>
>> Cool.
>>
>
> I just did a git pull and rebuilt.
>
>
>> > My ntp.conf snippet:
>> >
>> > nts enable
>> > nts cert /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem
>> > nts key /etc/letsencrypt/live/ntpmon.dcs1.biz/privkey.pem
>> > server pi3.rellim.com nts
>> > server kong.rellim.com nts
>>
>> Looks good.  What is your server so I can try to connect back?
>>
>
> My server is ntpmon.dcs1.biz .  It is in the pool, BTW.
>
> > Been runnig for a few hours now.  ntpq -pn output:
>> >  pi3.rellim.com  .NTS.   16 u   - 1024 0   0.   0.   0.0005
>> >  kong.rellim.com .NTS.   16 u-1024 0   0.   0.   0.0005
>>
>> Odd, you are not even getting the cookies.
>>
>> > And the log is here:  https://pastebin.com/fM9uDwVi
>>
>> Weird:
>>
>>  2019-03-22T03:56:32 ntpd[21039]: NTSc: nts_probe: DNS error trying to
>> contact pi3.rellim.com: -8, Servname not supported for ai_socktype
>>
>>
>> What version of OpenSSL do you have?  I'm finding that matters.
>>
>
> root@ntpmon:~/ntpsec# openssl version -a
> OpenSSL 1.1.1a  20 Nov 2018
> built on: Thu Nov 22 18:40:54 2018 UTC
> platform: debian-i386
> options:  bn(64,32) rc4(1x,char) des(long) blowfish(ptr)
> compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g
> -O2 -fdebug-prefix-map=/build/openssl-5z4Qxa/openssl-1.1.1a=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
> -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM
> -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time
> -D_FORTIFY_SOURCE=2
> OPENSSLDIR: "/usr/lib/ssl"
> ENGINESDIR: "/usr/lib/i386-linux-gnu/engines-1.1"
> Seeding source: os-specific
>
> This is debian/testing, up to date.
>
> Thanks,
> --
> Sanjeev
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Gary E. Miller via devel]

Yo Sanjeev!

> > Looks good.  What is your server so I can try to connect back?
> My server is ntpmon.dcs1.biz .  It is in the pool, BTW.

I can't connect to any NTS from kong now.  Not getting any cookies.
Some of my other 3 still work in various combinations.

I'm not putting NTS on my one pool server yet.

I tried to connect from my backup (1.0.1r), no cookies.

2019-03-21T16:40:59 ntpd[24257]: DNS: dns_probe: ntpmon.dcs1.biz, cast_flags:1, 
flags:
21801
2019-03-21T16:41:01 ntpd[24257]: NTSc: DNS lookup of ntpmon.dcs1.biz took 1.749 
sec
2019-03-21T16:41:01 ntpd[24257]: NTSc: nts_probe connecting to 
ntpmon.dcs1.biz:ntp => 
[2405:fc00:0:1::123]:123
2019-03-21T16:43:12 ntpd[24257]: NTSc: nts_probe: connect failed: Connection 
timed out
2019-03-21T16:43:12 ntpd[24257]: DNS: dns_check: processing ntpmon.dcs1.biz, 1, 
21801
2019-03-21T16:43:12 ntpd[24257]: DNS: dns_take_status: ntpmon.dcs1.biz=>error, 
12


> > What version of OpenSSL do you have?  I'm finding that matters.
> >  
> 
> root@ntpmon:~/ntpsec# openssl version -a
> OpenSSL 1.1.1a  20 Nov 2018

I'm guessing version mismatch.  Try my pi3.rellim.com, or backup, which
are on 1.0.2r.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgp7UWuZnLK66.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Sanjeev Gupta via devel]

On Fri, Mar 22, 2019 at 7:24 AM Gary E. Miller via devel 
wrote:

> > I have been lurking and trying to set up NTS to talk to the rellim.com
> > servers.  This is a recent git head.
>
> Cool.
>

I just did a git pull and rebuilt.


> > My ntp.conf snippet:
> >
> > nts enable
> > nts cert /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem
> > nts key /etc/letsencrypt/live/ntpmon.dcs1.biz/privkey.pem
> > server pi3.rellim.com nts
> > server kong.rellim.com nts
>
> Looks good.  What is your server so I can try to connect back?
>

My server is ntpmon.dcs1.biz .  It is in the pool, BTW.

> Been runnig for a few hours now.  ntpq -pn output:
> >  pi3.rellim.com  .NTS.   16 u   - 1024 0   0.   0.   0.0005
> >  kong.rellim.com .NTS.   16 u-1024 0   0.   0.   0.0005
>
> Odd, you are not even getting the cookies.
>
> > And the log is here:  https://pastebin.com/fM9uDwVi
>
> Weird:
>
>  2019-03-22T03:56:32 ntpd[21039]: NTSc: nts_probe: DNS error trying to
> contact pi3.rellim.com: -8, Servname not supported for ai_socktype
>
>
> What version of OpenSSL do you have?  I'm finding that matters.
>

root@ntpmon:~/ntpsec# openssl version -a
OpenSSL 1.1.1a  20 Nov 2018
built on: Thu Nov 22 18:40:54 2018 UTC
platform: debian-i386
options:  bn(64,32) rc4(1x,char) des(long) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g
-O2 -fdebug-prefix-map=/build/openssl-5z4Qxa/openssl-1.1.1a=.
-fstack-protector-strong -Wformat -Werror=format-security
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM
-DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time
-D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/i386-linux-gnu/engines-1.1"
Seeding source: os-specific

This is debian/testing, up to date.

Thanks,
--
Sanjeev
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing NTPSec with NTS

[Gary E. Miller via devel]

Yo Sanjeev!

On Fri, 22 Mar 2019 07:14:29 +0800
Sanjeev Gupta via devel  wrote:

> I have been lurking and trying to set up NTS to talk to the rellim.com
> servers.  This is a recent git head.

Cool.

> My ntp.conf snippet:
> 
> nts enable
> nts cert /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem
> nts key /etc/letsencrypt/live/ntpmon.dcs1.biz/privkey.pem
> server pi3.rellim.com nts
> server kong.rellim.com nts

Looks good.  What is your server so I can try to connect back?

> Been runnig for a few hours now.  ntpq -pn output:
>  pi3.rellim.com  .NTS.   16 u   - 1024 0   0.   0.   0.0005
>  kong.rellim.com .NTS.   16 u-1024 0   0.   0.   0.0005

Odd, you are not even getting the cookies.

> And the log is here:  https://pastebin.com/fM9uDwVi

Weird:

 2019-03-22T03:56:32 ntpd[21039]: NTSc: nts_probe: DNS error trying to contact 
pi3.rellim.com: -8, Servname not supported for ai_socktype


What version of OpenSSL do you have?  I'm finding that matters.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgp8W3_lxfWRK.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Testing NTPSec with NTS

[Sanjeev Gupta via devel]

Hi,

I have been lurking and trying to set up NTS to talk to the rellim.com
servers.  This is a recent git head.

My ntp.conf snippet:


nts enable
nts cert /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem
nts key /etc/letsencrypt/live/ntpmon.dcs1.biz/privkey.pem
server pi3.rellim.com nts
server kong.rellim.com nts

Been runnig for a few hours now.  ntpq -pn output:
*SHM(1)  .PPS.0 l   30   64
377   0.   0.0081   0.0096
xSHM(0)  .GPS.0 l   29   64
377   0. 244.2190  12.4769
 pi3.rellim.com  .NTS.   16 u- 1024
0   0.   0.   0.0005
 kong.rellim.com .NTS.   16 u- 1024
0   0.   0.   0.0005

And the log is here:  https://pastebin.com/fM9uDwVi

What am I missing?


-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Hal Murray via devel]

gha...@gmail.com said:
> I have a server running ntpsec git head, in the pool.  It has a valid SSL
> certificate.  I would like to turn on NTS, etc, and see what happens. 

One thing that nobody has tried/checked yet...

If the secret key file for your certificate needs a password, ntpd may have 
already detatched from the tty where it would normally read the password.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Hal Murray via devel]

gha...@gmail.com said:
> I have a server running ntpsec git head, in the pool.  It has a valid SSL
> certificate.  I would like to turn on NTS, etc, and see what happens.

Looks like you are debugging the documentation as well as the code.

Eric: Should we have a simple man page on how to setup thing for NTS?  Mostly 
it would be links to other places for the details.

Great/thanks.

> Can I start by assuming that the documentation in the subsection "== NTS-KE
> Server Configuration parameters" in devel/nts.adoc is current? 

That's a high level document that was used to collect ideas in the early 
stages of design.

You should probably look at docs/includes/auth-commands.adoc

The default for nts enable/disable is disable rather than enable.

The ask, require, noval, expire, and cert options to the server command have 
not been implemented yet.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Sanjeev Gupta via devel]

On Wed, Feb 20, 2019 at 2:04 PM Hal Murray via devel 
wrote:

>
> Testing.  Get it up and running in your local environment.  If you have a
> real
> certificate and are willing to support some testing traffic, tell me/us
> the
> host name and/or send us the root certificate.
>

I have a server running ntpsec git head, in the pool.  It has a valid SSL
certificate.  I would like to turn on NTS, etc, and see what happens.

Can I start by assuming that the documentation in the subsection "== NTS-KE
Server Configuration parameters" in devel/nts.adoc is current?

--
Sanjeev
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Richard Laager via devel]

On 2/20/19 7:26 AM, Hal Murray via devel wrote:
> For non public IP Addresses (aka behind a NAT box) you can use self signed 
> certificates.

In that scenario, you can still use Let's Encrypt. Use the DNS challenge
method. The Let's Encrypt client (on the NTS-KE server) uses nsupdate
(or similar) to update the entry on the DNS server. This only requires
1) that you setup a dynamically-updatable zone, and 2) that the Let's
Encrypt client (on the NTS-KE server) has outbound (not necessarily
inbound) network access, including via NAT.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Daniel Franke via devel]

On Wed, Feb 20, 2019 at 12:48 AM Hal Murray via devel  wrote:
> The K and I used to encrypt cookies is a hack constant so old cookies work
> over server reboots.

I assume this is temporary while you work on this code, right?
Obviously if K is a hardcoded constant you have no security.

> With the NTS flag, the client side tries NTS-KE, and drops into normal mode if
> that doesn't work.  If it does work, it sends NTS packets until it runs out of
> cookies.  Then it drops into normal mode.

Don't do that. Not even temporarily, not even as an option, not even
"opportunistically". If an adversary can force a client out of NTS
mode by dropping a few NTS packets, then NTS has no value.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Hal Murray via devel]

> If I have a real certifucate, I don't know it.

You have one on any web server that supports https.  I don't know where it 
lives.  Probably someplace in apache land.

Gary says it's easy to get them via Lets Encrypt.  Their web page says you 
need to control the domain. Gary said you only need a FQDN which makes more 
send.

For non public IP Addresses (aka behind a NAT box) you can use self signed 
certificates.  When I suggested a HOWTO, there was back pressure.  If anybody 
wants help along those lines, I'll dig out my notes.


>> If you want to write code, we need to save the current K and I to disk.
>> We also need to rotate keys occasionally.

> When sould the saves occur> After every cookie fetch?

No, only when they get rotated which is ballpark of 24 hours.

Asking that means it's time to read the draft carefully (again).

The idea is that K is used to encrypt stuff in a cookie.  You need to use that 
K to decrypt the cookie when it comes back.  If you restart your ntpd, it 
wants to use the same K so all the cookies in clients out there are still 
valid.

We also need to rotate K occasionally and remember the old one.  The cookie 
tells you which K to use.

For debugging, we can rotate them every hour and save more than one old one.  
Good clients will ramp up to 1024 seconds.  That's a bit over 2 hours, so we 
need 3 old ones.

The disk file needs to save the K/I pairs and the time it was written.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Eric S. Raymond via devel]

Hal Murray :
> > Excellent.  What's the bext thing you need from me?
> 
> Testing.  Get it up and running in your local environment.  If you have a 
> real 
> certificate and are willing to support some testing traffic, tell me/us the 
> host name and/or send us the root certificate.

If I have a real certifucate, I don't know it.

> If you want to write code, we need to save the current K and I to disk.  We 
> also need to rotate keys occasionally.

When sould the saves occur> After every cookie fetch?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Hal Murray via devel]

> Excellent.  What's the bext thing you need from me?

Testing.  Get it up and running in your local environment.  If you have a real 
certificate and are willing to support some testing traffic, tell me/us the 
host name and/or send us the root certificate.

If you want to write code, we need to save the current K and I to disk.  We 
also need to rotate keys occasionally.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTS off the ground - time for testing

[Eric S. Raymond via devel]

Hal Murray via devel :
> 
> The server side needs a cookie and private key.
> 
> The K and I used to encrypt cookies is a hack constant so old cookies work 
> over server reboots.
> 
> The client side defaults to using the system root certificates.  You can 
> provide your own.
> 
> With the NTS flag, the client side tries NTS-KE, and drops into normal mode 
> if 
> that doesn't work.  If it does work, it sends NTS packets until it runs out 
> of 
> cookies.  Then it drops into normal mode.
> 
> The code to ask for extra cookies doesn't exist yet.  If it gets started, it 
> will run in NTS mode until 8 packets get lost.

Excellent.  What's the bext thing you need from me?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

NTS off the ground - time for testing

[Hal Murray via devel]

The server side needs a cookie and private key.

The K and I used to encrypt cookies is a hack constant so old cookies work 
over server reboots.

The client side defaults to using the system root certificates.  You can 
provide your own.

With the NTS flag, the client side tries NTS-KE, and drops into normal mode if 
that doesn't work.  If it does work, it sends NTS packets until it runs out of 
cookies.  Then it drops into normal mode.

The code to ask for extra cookies doesn't exist yet.  If it gets started, it 
will run in NTS mode until 8 packets get lost.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ENABLE_MSSNTP - is anybody testing it?

[Mark Atwood, Project Manager via devel]

Don't remove it just yet, I will email someone about it.

On Thu, Jan 31, 2019 at 11:42 AM Eric S. Raymond via devel 
wrote:

> Hal Murray via devel :
> > Or does anybody know if that path has been tested?  If so, when?
> >
> > In case you don't recognize the term, it's when you get with
> --enable-mssntp
> > ntpd calls out to a Microsoft server to authenticate a response packet.
>
> I don't know ethat has ever been tested.
>
> Having looked at the code...yecch. Given the slightest excuse I'd remove
> it.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be
> your own.
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Zone file - testing outgoing mail

[Eric S. Raymond via devel]

$TTL 86400
@   IN  SOA thyrsus.com.  root.thyrsus.com. (
8 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire 
86400 ; ttl
)

;; Here is where the nameserver lives
IN  NS  thyrsus.com.

;; Expose thyrsus.com as a routable address
IN  A   71.162.243.5
IN  MX  10 thyrsus.com.

;; SPF to prevent spoofing
IN  TXT "v=spf1 a mx -all"

;; Externally, all names resolve to the one public IP address
;; Using A records here is a hack to get around the fact that some
;; oversealous spam filters get upset if they look up a HELO name
;; and it's a CNAME.
www CNAME   thyrsus.com.
mailCNAME   thyrsus.com.
dns CNAME   thyrsus.com.
snark   IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
minxIN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
grelber IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"
IN  A   71.162.243.5
IN  TXT "v=spf1 a mx -all"


-- 
http://www.catb.org/~esr/;>Eric S. Raymond

"This country, with its institutions, belongs to the people who inhabit it. 
Whenever they shall grow weary of the existing government, they can exercise
their constitutional right of amending it or their revolutionary right to 
dismember it or overthrow it."  -- Abraham Lincoln, 4 April 1861
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

ntpsnmpd testing notes

[Jason Azze via devel]

Mostly for Ian, who was trying to recall where he left off with ntpsnmpd.

I had a working ntpsnmpd instance running on a workstation which has, sadly, 
been consumed by entropy along with the rest of the assay I was using. However, 
I do recall that I had a Cacti instance collecting data from ntpsnmpd and 
drawing pretty graphs for me.

The configuration and setup documentation, IIRC, needed work (or, perhaps, to 
be written). And I was doing something crude to start the service (rc.local).

I had this in my /etc/rc.local because I was too lazy to write a systemd unit 
file.
/usr/local/bin/ntpsnmpd

Then I had a file, /etc/ntpsnmpd.conf that contained:

master-addr "/var/agentx/master"
ntp-addr "127.0.0.1"
logfile "/var/log/ntpsnmpd.log"
loglevel 8

Hope that helps the recollection process.

-- 
Jason Azze
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ENABLE_MSSNTP - is anybody testing it?

[Eric S. Raymond via devel]

Hal Murray via devel :
> Or does anybody know if that path has been tested?  If so, when?
> 
> In case you don't recognize the term, it's when you get with --enable-mssntp
> ntpd calls out to a Microsoft server to authenticate a response packet.

I don't know ethat has ever been tested.

Having looked at the code...yecch. Given the slightest excuse I'd remove it.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

ENABLE_MSSNTP - is anybody testing it?

[Hal Murray via devel]

Or does anybody know if that path has been tested?  If so, when?

In case you don't recognize the term, it's when you get with --enable-mssntp
ntpd calls out to a Microsoft server to authenticate a response packet.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Yellow alert to all hands - please intensify review and live testing

[Eric S. Raymond via devel]

The NTPsec code is, of necessity, entering a risky time.  Everyone
should go to heightened scrutiny and more frequent live testing of new
versions.

The following expands on some explanation I gave Hal Murray in a
recent reply.

While writing nts.c I realized that the NTS support is going to
require some significant changes to the packet-handling infrastructure
in the rest of the code.  These will not be safe changes; they could
easily introduce subtle and serious bugs.

Hence the need for other people to eyeball the code I will be pushing
in the near future more carefully than usual, and to stay on top of
changes to the repository head, and to do more live-testing, and to be
prepared to bisect if something breaks.

The good news is I don't expect the risky period to last long - I
expect in the not-too distant-future to be able to tell everyone they
can relax to normal levels of caution.  So that everyone understands
why, let me explain what's going on.

While working on the stub module for NTS support I got my nose rubbed
in the fact that the C code in ntpd is going to have to do real things
with NTP packet extension fields (because that's where NTS cookies are
carried).  That knocks over some dominos.

The first one to fall is that a job Daniel (wisely) ducked after the Great
Refactoring of the protocol engine has to get done.  That is unifying
the old ("insane", struct pkt) with the new ("sane", struct
parsed_pkt), because only the latter has actual support for extensions
other than the MAC field.

The second to fall is that the ugly type punning around refid fields -
sometimes treated as char refid[4], sometimes as uint32_t - has to
end.  That's a prerequisite for moving everything to the parsed-packet
representation.

I have a patch ready fixing all the refid uses - I'm rechecking it now
and expect to push it soon after I send this mail.  But doing so will
take us into the risky time.

Then I must do the rest of the spadework to unify those packet
representations.  That patch series is going to be messy
and somewhat dangerous.

Once done with that, however, we'll be back to where the *rest* of the
NTS changes are not very risky.  I'll notify the devel list when
everyone can stand down a bit. It will be days, not weeks.

What comes after:

Once I get those packet representations unified, I need to write
primitives for adding extension fields to a packet and extracting
them.

After *that*, it will be time to modify the ntpd config parser to
supply all the configuration info needed for the NTP client and server
sides.

Then I need to write everything about ntsked except the actual packet
processing.  A baby C framework for a TCP/IP listener, basically. I'm
hoping I'll be able to swipe this from somebody else's code.

You notice I'm talking about everything but the NTS packet processing
itself.  Hal Murray and James Browning and Gary Miller and others have
developed better understanding of that than I have yet - in part
because I've been preserving my ignorance in order to be able to
review the first-cut implementation with fresh eyes.

I, on the other hand, have been more intimate with the config parser
and packet-bashing and the other bits of C infrastructure NTS needs to
use than the rest of you have.  It's efficient for me to focus on
that, as well as keeping an eye on architectural simplicity.

So I'm making it my job to define the NTS code's interface to the rest
of that infrastructure, and then line up all the ducks outside nts.c
in neat rows. While that's going on, others can be filling in the
RFC-driven bits in nts.c.  My goal for what's there now was just to
define enough of it so the people who have been studying NTS more
closely than I have so far can be productive.

Have fun and stay safe out there.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined." -- Patrick Henry, speech of June 5 1788
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

git(lab) lesson please - testing merge requests

[Hal Murray via devel]

I'm setup to test things and/or can be good at proofreading, but I don't know 
how to work with merge requests.

I assume there is a simple way to pull them to my local setup.  How do I undo 
that if I don't like it?

This seems like it should be part of the main line work flow so I'm surprised 
that I don't know an easy way to do it.  I think I asked before and either 
didn't get a good answer or it fell through the cracks.



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Testing

[Hal Murray via devel]

There is a discussion on the TZ list about a screwup in medical software that 
can't handle DST changes.  It's also on RISKS.  (But not on their archives 
yet.)
  http://catless.ncl.ac.uk/Risks/

So I'm thinking about testing.

What can we do to help people test NTP?
Does anybody have a list of rough edges?

What should we test before a release to make sure our code is doing what we 
expect?
What should end users test to make sure our code is working in their setup?

Are those the same lists?  Or would priorities change?  What does priority 
mean?

Should we collect directions (or a script) to semi-automate making leap 
seconds?

One possibility would be a build option to enable a config option for 
leap-tonight.  That's a kludge, but simple for testers who aren't NTP geeks to 
understand.  Plan B would be to hack the leap seconds file.  Cleaner for the 
ntpd code, but more complicated overall.



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing merge requests

[Matthew Selsky via devel]

On Sun, Nov 04, 2018 at 09:47:14PM -0800, Hal Murray via devel wrote:
> [Was: Subject: Re: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0]
> 
> > I was working on that a little try checking out merge request !831
> 
> How do I do that?
> 
> That should be simple, but it's not in my working set.  I think I asked a 
> while ago and didn't get an answer that stuck.  There is probably an 
> interesting property in git or gitlab that I don't understand.
> 
> I need a way to back out if I don't like the change.  Work in a clone and 
> throw it away if you don't like it is a possible answer, but I expect there 
> is 
> something better.

If you click the "command line" link on 
https://gitlab.com/NTPsec/ntpsec/merge_requests/831, you'll see a pop-up with 
instructions on how to checkout that branch and play around with it:

git fetch https://gitlab.com/jamesb_fe80/ntpsec.git ntpleapfetch.sh
git checkout -b jamesb_fe80/ntpsec-ntpleapfetch.sh FETCH_HEAD

Or similar.

See also these tips for shortcuts for checkout out MRs:
https://docs.gitlab.com/ee/user/project/merge_requests/#checkout-merge-requests-locally


Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Testing tests

[John D. Bell via devel]

Replying to both Ian and the list - sent about 2018-09-14T1835Z.


On 09/14/2018 02:21 PM, Ian Bruene via devel wrote:
>
> (test)
>
> -- 
> /"In the end; what separates a Man, from a Slave? Money? Power? No. A
> Man Chooses, a Slave Obeys."/ -- Andrew Ryan
>
> /"Utopia cannot precede the Utopian. It will exist the moment we are
> fit to occupy it."/ -- Sophia Lamb
>
> I work for the Internet Civil Engineering Institute
> , help us save the Internet from Entropy!
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 



  - *John D. Bell*

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel