Re: Python, testing
> 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
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
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
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
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
>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: Certificates
Thanks. >> Suppose you don't trust all those CAs. What can you do? > Then they shouldn't be in your trust root to begin with. It's easy enough to > remove a CA source file from the system cert store and rebuild it, although > what to do is slightly different on each system. The problem with that approach is that I don't know which one(s) to remove until it is too late. Specifying the root certificate to use for a particular server seemed like a simple way to improve security. Logically, it's removing all but one. I think i/we could write a HOWTO without a lot of work. > That's CA pinning rather than certificate pinning. It only makes sense (to > me anyway) if you expect to have multiple different certificates that refer > to that CA, so maybe if you have a local CA that you don't want to advertise > system-wide. How do I do certificate pinning? I poked around a bit and found HPKP - HTTP Public Key Pinning. That requires extra work on the server side. In particular, it needs a second public key. That doesn't seem compatible with Let's Encrypt. I assume a local CA turns into self-signed certificates. They have to be distributed somehow. We could probably use the web for that. That scales well. It's minor extra one-time work for the server. It's an extra simple step for the client. There are complications when the root certificate times out. I'm looking for something that is practical. That means it doesn't require operator intervention too often. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Certificates
Hal Murray via devel writes: > Suppose you don't trust all those CAs. What can you do? Then they shouldn't be in your trust root to begin with. It's easy enough to remove a CA source file from the system cert store and rebuild it, although what to do is slightly different on each system. > One option is to extract the appropriate certificate from the installed root > collection. That's CA pinning rather than certificate pinning. It only makes sense (to me anyway) if you expect to have multiple different certificates that refer to that CA, so maybe if you have a local CA that you don't want to advertise system-wide. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzz, Numbers
Thanks. > and without 'limited' on ~5kpps I have 8-10% CPU regardless minitoring > enabled/disabled. About 1% on 1000pps. Is that within reason or worth investigating? 1% times 5 should be 5% rather than 8-10% but there may not be enough significant digits in any of the numbers. > For those who want to process hundreds of thousands of requests per second > (like 'national standard' servers) you can use multithreading and multiply > power of server. The current code isn't setup for threads. I think with a bit of work, we could get multiple threads on the server side. On an Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz I can get 330K packets per second. 258K with AES CMAC. I don't have NTS numbers yet. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Performance tweaks
A busy ntpd is CPU limited. Simple. I'm poking around, looking for tweaks that will gain a few percent. Does anybody have a quick recipe for how to get ntpd running on one CPU and the interrupt processing running on the same or a different CPU? Any idea on how much CPU it takes to do the interrupt processing to send/recv a packet? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
