Re: ntpsec | Extra precision for avgint field in ntpmon (#247)
I can't figure out what's going on. I claim the issue was bogus. The code as it was before your change was correct. We (at least I) want the extra precision so we can tell how bad abusive clients are. I sent something saying that, but it didn't make it to the issue tracker. Subject: Re: ntpsec | Extra precision for avgint field in ntpmon (#247) From: Hal Murray Date: Tue, 14 Feb 2017 23:41:33 -0800 To: NTPsec / ntpsec Cc: hmur...@megapathdsl.net > avgint should be an integer, not a float. That change is a feature, not a bug. Otherwise you can't tell how abusive the bad guys are. The first part is in classic, but the extra digit for under 1 sec isn't there yet. ``` $ ntpq -nc "mrulist mincount=1000 sort=avgint" | more Ctrl-C will stop MRU retrieval and display partial results. lstint avgint rstr r m v count rport remote address == = 31563 0.054 90 . 3 4 1278 51028 73.95.129.213 56670 0.055 90 . 3 4 2606 50692 96.248.118.203 73116 0.056 90 . 3 3 2692 57520 190.147.121.223 41847 0.068 90 . 3 3 2199 41144 73.189.35.160 ... ``` -- Eric said: > I pushed rthis change. It tracks a post-fork revision in Classic. I can't figure out what that is supposed to mean. My first reading was that "this change" meant you were copying the code from Classic. But that doesn't make sense since it was already there. You seem to have removed the code I want, so maybe "this change" means a change implementing the request in the subject of the issue (which I claim is bogus). -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Need moar blog content!
I just published "TESTFRAME: The epic failure" on the NTPsec blog. I have only one entry left in my queue, on our documentation practice. So far I've written about 75% of the content. I'd like the blog not to be mostly the ESR show. This means it's time for others to step up. -- http://www.catb.org/~esr/";>Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer."-- Thomas Paine ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Gary E. Miller writes: > Mark was thinking of a separate ntp-tools package or option. Many > distros has a X package and a matching X-tools package. We could make > that easy with a build option. > > I see the vast majority of users only using ntpd. > > But seriously, do you really need to save USD$0.001 of disk space? I'm pretty sure that Hal was more concerned about not putting stuff on a public-facing server that wasn't absolutely necessary. You'd want that for an audited system, like the "sec" part in NTPsec implies should be possible. 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: DCF77 driver seems to be broken
Achim Gratz writes: […] > Just out of curiosity, why have you defined the lfp access macros in > such an overly redundant manner? […] The lack of responses makes me wonder if it was a bad idea to tuck that section after the patch… any insights? :-) 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: DCF77 driver seems to be broken
Achim Gratz : > Achim Gratz writes: > […] > > Just out of curiosity, why have you defined the lfp access macros in > > such an overly redundant manner? > […] > > The lack of responses makes me wonder if it was a bad idea to tuck that > section after the patch… any insights? :-) Sorry, please r-send the question. Preferably under a new title. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
l_fp access macros (was: DCF77 driver seems to be broken)
Just out of curiosity, why have you defined the l_fp access macros in such an overly redundant manner? I realize that the compiler will optimize most of that away, but it seems odd to do that in the first place unless you're expecting to support a platform that has a non-conforming compiler that doesn't implement conversions between types of different rank correctly. Your reliance on C99 and standard types in other places seems to preclude that. So how about: #define lfpfrac(n) ((uint32_t)(n)) #define lfpsint(n) ((int32_t)((n) >> 32)) #define lfpuint(n) ((uint32_t)((n) >> 32)) #define bumplfpsint(n, i) ((n) += ((int64_t)(i) << 32)) #define bumplfpuint(n, i) ((n) += ((uint64_t)(i) << 32)) I'm sitting on the fence with the last two (there actually would not need to be two forms either as the result is the same either way). There could be processors where the compiler infers a multiply-add in the explicit multiplication and not recognize the shift-add form. But there's no real need for the "BUMP" constant otherwise and a compiler on a processor that supports halfword access should have no trouble just loading the upper word directly and not do a shift at all. Another argument against using a multiply is that a number of processors have 32x32 multiplication in hardware, but not 64x32 or 64x64. Even the HIGH and LOW masking could be replaced by nested casts: #define setlfpfrac(n, v)((n) = (uint64_t)uint64_t)(lfpuint(n)))<< 32) | lfpfrac(v))) #define setlfpsint(n, v)((n) = (int64_t)int64_t)(v)) << 32) | lfpfrac(n))) #define setlfpuint(n, v)((n) = (uint64_t)uint64_t)(v)) << 32) | lfpfrac(n))) The comment about the signed and unsigned version producing the same result applies again. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: l_fp access macros (was: DCF77 driver seems to be broken)
Achim Gratz : > Just out of curiosity, why have you defined the l_fp access macros in > such an overly redundant manner? I realize that the compiler will > optimize most of that away, but it seems odd to do that in the first > place unless you're expecting to support a platform that has a > non-conforming compiler that doesn't implement conversions between types > of different rank correctly. It was something like that, though not as specific. I have old habits from pre-ANSI days that might be excessively cautious in a C99-conforming environment. Fortunately, we have good regression tests for those macros. So if you want to submit a simplification MR, feel free. Just be sure you still get this afterwards. $ ./waf check Waf: Entering directory `/home/esr/software/ntp-rescue/ntpsec/build/main' [190/231] Processing build/main/tests/test_libntp [198/231] Processing build/main/tests/test_ntpd Waf: Leaving directory `/home/esr/software/ntp-rescue/ntpsec/build/main' Wrote test log to: /home/esr/software/ntp-rescue/ntpsec/build/main/test.log execution summary tests that pass 2/2 /home/esr/software/ntp-rescue/ntpsec/build/main/tests/test_ntpd /home/esr/software/ntp-rescue/ntpsec/build/main/tests/test_libntp tests that fail 0/2 -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Extra precision for avgint field in ntpmon (#247)
Yo Hal! On Wed, 22 Feb 2017 04:09:13 -0800 Hal Murray wrote: > We (at least I) want the extra precision so we can tell how bad > abusive clients are. I sent something saying that, but it didn't > make it to the issue tracker. +1 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 pgpeYz94A94v4.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Achim! On Wed, 22 Feb 2017 18:21:01 +0100 Achim Gratz wrote: > Gary E. Miller writes: > > Mark was thinking of a separate ntp-tools package or option. Many > > distros has a X package and a matching X-tools package. We could > > make that easy with a build option. > > > > I see the vast majority of users only using ntpd. > > > > But seriously, do you really need to save USD$0.001 of disk space? > > I'm pretty sure that Hal was more concerned about not putting stuff > on a public-facing server that wasn't absolutely necessary. Then 90% of your distro is probably also not absolutely necessary. If your attacker can run things on your CLI then it is long past game over. > You'd > want that for an audited system, like the "sec" part in NTPsec > implies should be possible. I've never had that come up in an audit. Every open port gets thorughly looked at, but not miscellaneous programs in /usr/bin. 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 pgpQIKgYr7h96.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
On Wed, Feb 22, 2017 at 11:30 AM, Gary E. Miller wrote: > > Yo Achim! > > On Wed, 22 Feb 2017 18:21:01 +0100 > Achim Gratz wrote: > > > Gary E. Miller writes: > > > Mark was thinking of a separate ntp-tools package or option. Many > > > distros has a X package and a matching X-tools package. We could > > > make that easy with a build option. > > > > > > I see the vast majority of users only using ntpd. > > > > > > But seriously, do you really need to save USD$0.001 of disk space? > > > > I'm pretty sure that Hal was more concerned about not putting stuff > > on a public-facing server that wasn't absolutely necessary. > > Then 90% of your distro is probably also not absolutely necessary. > > If your attacker can run things on your CLI then it is long past game over. The attack surface isn't binary. IMO, it's better for the ecosystem to let each admin decide which things to install or to leave out. If it's an easy split to make, I'd rather that admins have the option. > > You'd > > want that for an audited system, like the "sec" part in NTPsec > > implies should be possible. > > I've never had that come up in an audit. Every open port gets thorughly > looked at, but not miscellaneous programs in /usr/bin. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Royce! On Wed, 22 Feb 2017 11:38:04 -0900 Royce Williams wrote: > On Wed, Feb 22, 2017 at 11:30 AM, Gary E. Miller > wrote: > > > > Yo Achim! > > > > On Wed, 22 Feb 2017 18:21:01 +0100 > > Achim Gratz wrote: > > > > > Gary E. Miller writes: > > > > Mark was thinking of a separate ntp-tools package or option. > > > > Many distros has a X package and a matching X-tools package. > > > > We could make that easy with a build option. > > > > > > > > I see the vast majority of users only using ntpd. > > > > > > > > But seriously, do you really need to save USD$0.001 of disk > > > > space? > > > > > > I'm pretty sure that Hal was more concerned about not putting > > > stuff on a public-facing server that wasn't absolutely > > > necessary. > > > > Then 90% of your distro is probably also not absolutely necessary. > > > > If your attacker can run things on your CLI then it is long past > > game over. > > The attack surface isn't binary. Agreed 100%. Things like CLI tools with no special permissions or capabilities are way at the bottom of the worry scale. Lost in the noise floor. > IMO, it's better for the ecosystem to let each admin decide which > things to install or to leave out. If it's an easy split to make, I'd > rather that admins have the option. Nothing we do says an admin can't "rm /usr/bin/XXX". I often have that in my build scripts. No need to clutter the build options for that. 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 pgpE10_6Kt0v7.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Information lost when switching to buildprep
Gary said: >> 2) It drags in a big pile of stuff, starting with gnuplot. > No. At least one of us is confused. buildprep installs gnuplot unconditionally. Perhaps you mean that it doesn't need to do that. But currently it does. What does ntpviz do without gnuplot and/or why would I want to do that? If I have to move the processed data to another system to view it, why not copy the raw log files and do all the processing there? The old text in INSTALL had comments about something being needed at run time or only at build tiime. That information is no longer in buildprep. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Generic doesn't log into clockstat
strom...@nexgo.de said: > Like the NMEA clock: day, time of day, clock ID, timecode (optionally maybe > the decoded time and flags from the timecode). There are two approaches to logging clockstats info. As background, the assumption is that you don't want to log everything. You can log stuff from the receive procedure. That gets good timing. You can get the bandwidth reduction by setting a flag on logging something and clearing it in the poll procedure. That gives you the sample right after the previous poll which is likely to be similar. (I suppose you could keep a counter and just log every Nth sample. I don't know of any drivers that do that.) The other approach is to do the logging from the poll procedure. That looses the timing info, but lets you also log counters before they get reset. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
g...@rellim.com said: > I'm unaware of anything in NTPsec that does things behind anyone's back. >> Does it start a server? Does it run a cron job? Does it install >> hooks that some code I do need might call? > Now I'm really lost. I'm unaware of anything in NTPsec does any of that > without explicit user intervention. What exactly do you want changed here? It's not ntpsec that I'm interested in, it's the stuff it drags in. Reducing our exposure seems like the right approach. [Messages crossing in the night - moving stuff from INSTALL to buildprep lost the run vs build info.] -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Information lost when switching to buildprep
Yo Hal! On Wed, 22 Feb 2017 13:26:54 -0800 Hal Murray wrote: > Gary said: > >> 2) It drags in a big pile of stuff, starting with gnuplot. > > No. > > At least one of us is confused. > > buildprep installs gnuplot unconditionally. Perhaps you mean that it > doesn't need to do that. But currently it does. buildprep is optional. We already agreed to make gnuplot optional in buildprep. Next? > What does ntpviz do without gnuplot and/or why would I want to do > that? It makes plot files and dumps statistics summaries. The plots can then be plotted elsewrhere. I forsee a future option where it just outputs the text summaries. Just way down on my list. > If I have to move the processed data to another system to view > it, Some will, some will not. Some might use ssh to run a server copy of gnuplot from the ntpd host. Do with it as you wish. > why not copy the raw log files and do all the processing there? The plot files are potentially a lot smaller. > The old text in INSTALL had comments about something being needed at > run time or only at build tiime. That information is no longer in > buildprep. Yeah. Patches welcome. 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 pgp8nWm9uDHlQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
On Wed, Feb 22, 2017 at 12:17 PM, Gary E. Miller wrote: > Yo Royce! > > On Wed, 22 Feb 2017 11:38:04 -0900 > Royce Williams wrote: > >> On Wed, Feb 22, 2017 at 11:30 AM, Gary E. Miller >> wrote: >> > >> > Yo Achim! >> > >> > On Wed, 22 Feb 2017 18:21:01 +0100 >> > Achim Gratz wrote: >> > >> > > Gary E. Miller writes: >> > > > Mark was thinking of a separate ntp-tools package or option. >> > > > Many distros has a X package and a matching X-tools package. >> > > > We could make that easy with a build option. >> > > > >> > > > I see the vast majority of users only using ntpd. >> > > > >> > > > But seriously, do you really need to save USD$0.001 of disk >> > > > space? >> > > >> > > I'm pretty sure that Hal was more concerned about not putting >> > > stuff on a public-facing server that wasn't absolutely >> > > necessary. >> > >> > Then 90% of your distro is probably also not absolutely necessary. >> > >> > If your attacker can run things on your CLI then it is long past >> > game over. >> >> The attack surface isn't binary. > > Agreed 100%. Things like CLI tools with no special permissions or > capabilities are way at the bottom of the worry scale. Lost in the > noise floor. Fair. :) >> IMO, it's better for the ecosystem to let each admin decide which >> things to install or to leave out. If it's an easy split to make, I'd >> rather that admins have the option. > > Nothing we do says an admin can't "rm /usr/bin/XXX". I often have that > in my build scripts. No need to clutter the build options for that. Bespoke downstream file removal has its place -- but there's a break-even point. IMO, it's better for projects to provide a reasonable baseline client/server split. It allows the project to express a broad, informed recommendation about where the split should occur. It also allows the project to change that split in a controlled and long-term-ecosystem-friendly manner if the need arises. In other words: if something is added to the client side, it's inefficient for X number of admins to go update their "rm /usr/bin/XXX" scripts. As soon as the value of "X" gets above just a few people, having the project advise and update the split is a superior force multiplier. Splitting client and server is also very appliance- and embedded-friendly. IMO, anything reasonable that we can do to make it easier -- even just to reduce the cognitive load on the developers -- is a technical and PR win. Royce ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Royce! On Wed, 22 Feb 2017 12:50:39 -0900 Royce Williams wrote: > > Nothing we do says an admin can't "rm /usr/bin/XXX". I often have > > that in my build scripts. No need to clutter the build options for > > that. > > Bespoke downstream file removal has its place -- but there's a > break-even point. > > IMO, it's better for projects to provide a reasonable baseline > client/server split. It allows the project to express a broad, > informed recommendation about where the split should occur. It also > allows the project to change that split in a controlled and > long-term-ecosystem-friendly manner if the need arises. In the NTPsec case, the client is the server. So not a good cleave point. Ditto the tools NTPsec ships are for both client and server. So not a good cleave point. We have already imagining a split into an ntpd package and an ntpd-tools package. So just a matter of what goes where. > Splitting client and server is also very appliance- and > embedded-friendly. Anyone doing an appliance or embedded server will already be making their own install scripts. I expect 99% of NTPsec installs to not be done with our scripts, but with distro specific scripts. Just for starters most people install binary packages and NTPsec does not go there, that is for the distros to do. Our scripts are just for developers and for packagers to get a start. 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 pgpeQqYsEUTzr.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
