More SNMP dependency questions, also assertions.

assert: the daemon name should be ntpsnmpd assert: both ipv4 and ipv6 should be implemented assert: if both exist, they should be bound at the same time assert: the port(s) should be choosable = SNMP version / security

Re: Time to plan for 1.0

On 08/09/2017 01:13 AM, Gary E. Miller via devel wrote: I find leaving ntpmon running is smoking out a bunch of hard failure. In hindsight (yeah) we should have thought of this - *I* should have thought of this - a long time ago. -- In the end; what separates a Man, from a Slave? Money?

Re: Time to plan for 1.0

This morning on #ntpsec: 07:45 <@esr> ianbruene: I knew the snmpd project would lead to much yak shaving. This is actually part of the reason I viewed it it as a good training opportunity. When you're not under time pressure and can thus afford to get

Re: Time to plan for 1.0

Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I haven't merged that) is completely separate from everything else. agentx.py can be ripped out for 1.0 without problems, it could be shipped in a perfectly broken state without problems outside of being /incredibly/ bad

Re: Time to plan for 1.0

On 08/08/2017 09:01 AM, Eric S. Raymond wrote: Strictly speaking you can't do that. It's the PM's decision whether we want to drop the feature or change the schedule. We're pretty informal here, but you need to know where those lines of authority are, because many other projects (especially

Re: Time to plan for 1.0

On 08/08/2017 11:16 AM, Eric S. Raymond wrote: Thank you, that is correct procedure. Acting in Mark's absence I concur; we'll slip it if you don't have it done. Mark has the privilege to override this decision but I will be quite surprised if he does. Well now I'm increasing this to

Fwd: Re: Time to plan for 1.0

Note to self: check the reply address in the future. Forwarded Message Subject:Re: Time to plan for 1.0 Date: Mon, 7 Aug 2017 14:59:14 -0500 From: Ian Bruene To: Eric S. Raymond On 08/07/2017 11:58 AM, Eric S. Raymond

Re: possible bug: peerstats

On 08/19/2017 08:54 AM, Achim Gratz via devel wrote: I've updated to ntpsec-0.9.7+1104 ten days ago and just realized that the peerstats logging has changed format: if I use the new refclock syntax, then instead of the 127.127.. in the address field, I now get the driver name like NMEA(0). I

Fwd: Re: More SNMP dependency questions, also assertions. [FWD because reply error]

Forwarded Message Subject:Re: More SNMP dependency questions, also assertions. Date: Mon, 1 May 2017 21:08:17 -0500 From: Ian Bruene To: Matthew Selsky On 05/01/2017 08:50 PM, Matthew Selsky via devel

State of the debugging flags.

At ESRs request I've trawled through the C sources to see how debug logging is handled. First, by way of summary let me present you with a couple bits of code: # define DPRINTF(lvl, arg)\ do { \ if (debug >= (lvl))\

Proposed argument changes to ntpq (fixing bug #319)

Currently ntpq has -d and -D flags which function much like the ones for ntpd. Except that the -d flag also sets ntpq to log to a file instead of stderr because, um, reasons? Proposed interface change: -d/-D remain, but *only* affect the debug level Add flag -l / --log-file (alt: -f, etc)

Re: ntpsec | ntpq: -d -d != -D2 (#319)

On 06/08/2017 05:18 PM, Gary E. Miller via devel wrote: So, what do you think is still unresolved? At this point I think we have solved it, simply by eliminating the alternatives. It's all part of the ntpq flag discussion. -- In the end; what separates a Man, from a Slave? Money? Power?

Re: Proposed argument changes to ntpq (fixing bug #319)

On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote: NTPsec does not use Python's getopt(). It uses argparse(). So the real alternatives here are: 1. Have the dual -l/-L flags 2. Convert ntpq from getopt to argparse -- In the end; what separates a Man, from a Slave? Money? Power? No. A

New state of the debug flags

After consolidating the relevant macros into ntp_debug.h and cleaning up all of the simple if(debug)s I have done another grep through the codebase. It appears that there aren't anymore cases where it is worth creating a macro for debugging. What's left is either blocks of custom

argparse vs getopt

First: I am not considering performance here *whatsoever*, even if there were a meaningful difference, which I doubt, option parsing happens once during program startup, and ntpq doesn't need high speed anyway. Advantages of getopt getopt is simpler, it only needs argv + some definitions

Re: argparse vs getopt

On 06/14/2017 01:39 AM, Matt Selsky via devel wrote: Only new NTPsec programs use argparse. Everything that's replacing NTP Classic C code uses getopt, so that we can support python2.6 (RHEL 6 default python) Well that settles that. I'll get the getopt version up and running. -- In the

Re: argparse vs getopt

On 06/14/2017 02:30 PM, Eric S. Raymond wrote: Yeah, I thought I recalled that this was an issue. But wait! There's more! argparse works just fine on Python 2.6: pip install argparse So which is it? Is requiring argparse installation acceptable? The conversion tradeoff was marginal

Re: argparse vs getopt

Think Kobayashi Maru, and you are Captain. I concur. Time admins would not thank us for the additional dependency. Nice timing; in testing the getopt version I think there is an assumption that needs to be examined. Does there need to be a default logfile name in the first place? The

Re: argparse vs getopt

It. Is. Done. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew Ryan ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

Re: argparse vs getopt

On 06/15/2017 08:24 AM, Eric S. Raymond wrote: Good argument. The only question is whether the semantics you propose would create a confusing difference from ntpd. The only difference between ntpq -l and ntpd -l is that ntpd has a default in the system logfiles. ntpq can't have optional

Re: More SNMP dependency questions, also assertions.

assert: if both exist, they should be bound at the same time If yu bind to the IPv6, you get the IPv4 for free. No need to bind both. TIL assert: the port(s) should be choosable Yes, but default to the snmp port in /etc/services. Knew it had a specific default, TIL /etc/services

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

On 09/14/2017 11:46 PM, Eric S. Raymond via devel wrote: A fair point. But...on the other hand, a major platform. Not by our criterion, which is more or less "Are flocks of these going to be running in $J_RANDOM_HUMONGOUS_DATACENTER?" Part of our strategy is to optimize for the toughest,

Re: Testing float-valued functions

On 10/06/2017 10:15 AM, Eric S. Raymond wrote: This is why the minimal-change alternative is worth considering at this point in our release cycle. It means you don't have to do that research project. Done, functions that can be simply changed to assertAlmostEqual have been, problematic

Re: Testing float-valued functions

On 10/06/2017 06:52 AM, Eric S. Raymond wrote: In fact, all this test code is subtly wrong, and it is just blind luck nothing went sproing sooner. Any of those assertions could have gone toes-up at any time. The tests in posixize() are wrong, too. The problem here is that float

Re: Name of path for installed libraries: ntp or ntpsec

On 09/26/2017 01:21 PM, Hal Murray via devel wrote: Should we be using ntpsec rather than ntp? If so we need to know *now*. Because every python file will need its imports changed. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew

Re: Python 3 and 1.0

On 09/26/2017 03:19 PM, Eric S. Raymond wrote: Can you get enough verificaion in a week? We may have to push back the release for other reasons. I can hammer on it, if nothing serious shows up it should be fine. Post-1.0 I'd like to take a systematic look at how data is flowing through

Post-1.0 refactoring and unit documentation; a request

A few months ago when I added unit display to the python tools I created the devel/units file to document what the assorted Important Variables in NTPsec represent, and more importantly how that representation changes as the data moves through the programs. Because of my lack of knowledge of

Re: Python 3 and 1.0

On 09/26/2017 05:28 PM, Fred Wright via devel wrote: [error snipped] I have no idea whether this affects anything real or whether it's just a test artifact. If the latter, it's clearly not a release blocker. This error does not effect the program itself. It is part of a test jig which is

Re: Python 3 and 1.0

On 09/26/2017 04:20 PM, Fred Wright via devel wrote: I also notcied that test_agentx.py doesn't work with Python 3, but my impression is that the agentx stuff is still a WIP, anyway. This is true. Indeed. When I started looking at the ntpq bug, I noticed that there seemed to be some

Re: Python 3 and 1.0

On 09/26/2017 05:02 PM, Eric S. Raymond via devel wrote: Huh? If so, why has this not shown up in the results from the FreeBSD buildbot. Two reasons: 1. python tests still not run by the build script 2. subsequent reports are inconsistent on whether FreeBSD has a problem or Fred's system

Re: All hands - we need to test Fred's build changes pronto

I pushed a fix for both of these. On 09/26/2017 11:48 AM, Ian Bruene wrote: python3 build: fails, can't find ntp module, after installing p3 version it runs but crashes with a type conversion error (I'll get on this right away) python3.6 build: ditto, but also crashes with a

Python 3 and 1.0

The python 3 build appears to work. However it has a unicode bug in ntpq (but not ntpmon! Yay consistency!), and I can not say that I *trust* any of it. This is partially my fault, as I failed to test the software in Py3 as much as I should have. As an excuse I will note that I fixed

Nailing an elusive unicode bug, and a heads up

Several months ago when I added the unit display feature there was a bug that caused ntpq to crash with a unicode error for no apparent reason. The crash was never replicated, but I added some debugging statements in hope of catching it. Someday. In the last week during the release delay

Re: Python 3 and 1.0

Since my initial complaint about Py3 compatibility some bugs have been fixed, agentx tests work, and I've poked at it with a stick. Panic-mode rescinded. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew Ryan

Attn: Anyone familiar with 32 vs 64 bit time_t issues, or who can make policy decisions.

Please take a look at bug #404 at the earliest opportunity. I hate to raise such an alarm over a test bug but we are running out of hours before release. Relevant problem is my final comment on the bug thread. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man

Re: Let's get back to work

On 10/17/2017 05:37 AM, Eric S. Raymond via devel wrote: Other possibilities welcomed. Someone who understands waf: make the build run the python tests. Note to whoever does it: you need to run them directly, python discover requires pip. -- In the end; what separates a Man, from a

Re: Fixing the build to run python tests

On 11/29/2017 04:17 PM, Hal Murray via devel wrote: That link lets you test python code using the new libraries. In a previous version of that code, the link was in ntpclients and you could run things by cd-ing there. Now the link is in $build/main/ntpclients so you have to cd there. Are

Fixing the build to run python tests

First issue (blocker) I have succeeded in getting the unit testing scripts for python code to run as part of the build on my machine, however when uploaded to GitLab the pipelines fail with an import error in the test scripts. The test modules cannot import the library modules they are meant

Re: Pulling - or clawing - data out of mode 6

On 12/01/2017 08:44 PM, Hal Murray via devel wrote: The "uptime" variable is used to by snmp clients to do "count per time" calculations, and also to notice how long after boot that that that daemon started, or if its restarting. If you need to, insert into your subagent code when it first

Re: version stuff, autorevision

On 12/12/2017 08:04 PM, Hal Murray via devel wrote: Something broke in my setup and I can't figure out what's going on. Er, whoops! I broke that as part of my fix for improperly generated files. Should be fixed now. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A

Pulling - or clawing - data out of mode 6

I'm trying to fill out the MIB for ntpsnmpd and have several items that I do not know how to get data for. This also effects ntpq as so far my primary method of discovering what to poke mode 6 with to get what I need has been to see how ntpq does it. A side effect of ntpsnmpd will probably

Of MIB trees and universes with a time dimension

In my report during last night's mailing list storm I mentioned needing to change the architecture of ntpsnmpd slightly. This email is a description of how it works now for updation/clarification/documentation/sanity checkification purposes. In ntpsnmpd there is a class which manages the

Questions on SNMP TestSet validation

To process the TestSetPDU the sub-agent must validate each varbind through a series of steps detailed here https://tools.ietf.org/html/rfc1905#section-4.2.5 There are a number of steps that I do not understand, my summary/questions about the steps follow: 1 Denied access because not in

Re: Getting things moving again

On 11/04/2017 04:54 PM, Eric S. Raymond via devel wrote: * I would like us to plan on a short-cycle 1.1, to land early January, with SNMP support as the big new feature. Ian: is this a realistic timeframe? Current tasks that I see are: * Filling out the MIB. * Implementing the rest

Re: upcoming 1.0.1 release this weekend

On 12/05/2017 02:33 PM, Mark Atwood, Project Manager via devel wrote: Please make sure that whatever you have pushed to master is ready for release, andor let me know if there is any good reason not to do a release this weekend. Only thing I have in master that doesn't match the requirement

Re: upcoming 1.0.1 release this weekend

On 12/05/2017 06:47 PM, Eric S. Raymond via devel wrote: I'm OK with this plan - codebase seems to be in pretty good shape - except it might make the cooldown period after Ian lands his install-path fix a little short. Can we hold off three days or so? I have something already. WIP

Re: Testing

On 12/07/2017 07:43 AM, Eric S. Raymond via devel wrote: How important is your individual way of doing things? Would you be willing to tolerate some inconvenience if that made the rest of us more productive? In principle, yes. I'd need to be persuaded that the net was positive - that the

Re: Bite of the Buildbugs!

On 12/10/2017 04:26 PM, Ian Bruene wrote: On 12/10/2017 10:52 AM, Eric S. Raymond wrote: Do you understand the problem well enough that you could specify an upstream fix? I'm not yet certain whether python or the distributions have jurisdiction here. Earlier comments from rlaager suggest

Bite of the Buildbugs!

After reading over the discussion regarding the recent /issues/, I have come to a side: Revert Fred's fix and throughly document the import breakage. Reasoning: The standard method means that on some systems the ntp module can't be seen by python without modifying PYTHONPATH. The fix

Re: Bite of the Buildbugs!

On 12/10/2017 10:52 AM, Eric S. Raymond wrote: Ugly, but simple. I'd like to hear counterargument from Gary and Fred before we make a final decision. Keep it succint, guys. Agreed. My main concern is that trying to be clever here has many ways to go wrong, and few ways to detect them

Re: Preparing for a point release

On 12/05/2017 08:24 AM, Eric S. Raymond via devel wrote: * "Install failure on gentoo Stable" (#417) and "Python site packages installed in wrong location" (#414). Ian has a WIP patch to fix this; it needs to be finished and landed. I currently do not have any handle on #417. I know where

Re: Preparing for a point release

On 12/05/2017 11:57 PM, Richard Laager via devel wrote: From my reading of that wiki page, the distro-packaged Python uses dist-packages whenever stock Python would use site-packages. This way, if you install the distro Python package *and* Python from source, you can install modules for each

Re: Preparing for a point release

On 12/06/2017 09:11 AM, Richard Laager via devel wrote: Probably? The behavior was already correct for the distro package. Was anything else broken? For installs the only remaining problem is that for unknown reasons it sometimes doesn't follow the PREFIX when installing the python libs.

Re: ntpsnmpd

On 10/29/2017 02:13 PM, Eric S. Raymond wrote: Eric S. Raymond via devel : So what's missing? The Mode 6 transactions to get the read data? Er, I meant *real* data. Currently all of mode 6, much of the AgentX protocol. Reason for merging now is that ntpsnmpd has hit the

ntpsnmpd

I have pushed the prototype SNMP AgentX daemon to the repo. In it's current state it implements the basic data retrieval packets (get, getnext, getbulk), returning dummy values for most items. At this point others banging on it is probably more useful than preventing commit clutter. I make

Re: warning:Mime-Version: 1.0

On 06/18/2018 03:37 PM, Eric S. Raymond via devel wrote: Ah, now that's the kind of error pattern I *expect* from Bison parsers. The underlying problem is that the C in Bison parser skeletons is really archaic. It dates from times when not even the value of procedural encapsulation was fully

Initial test coverage report

I had a look through libntp/ and tests/libntp/ today. Of the 35 files that are relevant for testing * 4 are AFAICT fully tested * 11 have partial tests * 20 do not even have a test file There is undoubtedly some error in these figures as the test directory has some files in it that do not

Re: Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)

On 05/29/2018 02:15 PM, Eric S. Raymond via devel wrote: I'm inclined to think dropping this would be a good thing. There's a lot of code complexity behind that, and that bit abour interface commands being inoperative if you choose the wrong command-line option raises my shoot-self-in-foot

Re: Resuming the great cleanup

On 05/27/2018 11:31 AM, Eric S. Raymond via devel wrote: * GOPREP: Clear the path to moving the codebase to Go. We haven't committed to doing this yet, but the odds on that happening someday look high enough that I think it is good to already be factoring it into our planning. Though it is

Re: Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)

On 05/29/2018 03:54 PM, Eric S. Raymond wrote: Ian Bruene via devel : I've skimmed through some of the code associated with these features during deglobalization. It /needs/ to be cleaned up one way or another. Cleaning it with a scythe is all the better. Hmmm. You may have talked yourself

Re: SINGLESOCK - How much to strip away?

On 05/30/2018 02:45 PM, Hal Murray via devel wrote: It can be done in two steps. First is to dump the work-queue but still make each packet get a buffer from the free queue and go back there. The second is to remove the free queue. Looking at the code, I believe this is the proper action

Preliminary report on variable initialization, and when does code freeze happen?

I have done a scan over the variables that I have already structified in recent weeks to see where they get initialized. Most of the variables I have checked get initialized either at definition time, or in some sort of init_foo() function. I found three variables that are never

Re: Resuming the great cleanup

On 05/27/2018 01:56 PM, Hal Murray via devel wrote: How thread friendly is GO? Very. Easy concurrency in network software is Go's major raison d'être. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot

Re: Attn: Install path debaters

On 01/04/2018 12:54 PM, Gary E. Miller via devel wrote: [*SNIP* long description of why path embedding is Not Done] RGDS GARY Ah. This was rattling around in the back of my head but I had forgotten the details. !615's fix can be removed from consideration. -- /"In the end; what separates

Re: Attn: Install path debaters

Oy Gary! I think on a a couple of your responses we may be talking about different things. However that is moot at this point, as it is clear that we have our last solution standing: rip out the "fix" that started this whole debate and revert to the old method. -- /"In the end; what

Re: Attn: Install path debaters

On 01/04/2018 01:21 PM, Gary E. Miller via devel wrote: What are these other issues? The FHS, Gentoo, and AFAIK all distros, do not include /usr/local/XX in any enviroment PATHs. Ubuntu does. Did people just not usually use /usr/local/ much in the Eldar Days? That would explain it not

Re: Request for data / ntpsnmpd report

On 01/09/2018 11:42 AM, Eric S. Raymond wrote: Third way: there's a reference to get_resolution() ntp_systime.c at line 147 ("After default_get_precision() has set a nonzero sys_fuzz") that implies two things; (1) get_resolution() used to be called within ntpd, and (2) its role has been taken

Attn: Install path debaters

We are on track to merging the solution in !615, if you have objections please state them *soon*, together with a patch that fixes the problem. We are rapidly approaching the planned mid-January 1.1 date. To snip one large set of objections in the bud: Yes, this solution is /hideous/.

Re: Attn: Install path debaters

On 01/04/2018 10:48 PM, Richard Laager via devel wrote: Can you submit an actual merge request for review? Currently waiting for the pipeline to finish on !641. This changes the build back to how it used to work, it builds and installs on my system, it has passed the build phase of the

Concluding the install path debate

This is a summary of the last few months of intermittent arguing over the build system. I am glossing over most details as the specifics are not important to the summary, and I'm too lazy to track down every post on the matter. Just before the 1.0 release Fred Wright submitted a patch to

Python test coverage readout

How can I get a detailed report on the new python test coverage check? And how robust is it: does it only count the percentage of functions tested, or can it tell what parts of a function are being exercised? 91% is higher than I expected. -- /"In the end; what separates a Man, from a

Re: Attn: Install path debaters

On 01/04/2018 11:44 AM, Richard Laager via devel wrote: I'm not convinced it's actually bad form. Can you elaborate on why you see this as hideous? My understanding is that embedding paths into code like this is something that Shouldn't Be Done unless absolutely necessary. It also adds the

Re: Request for data / ntpsnmpd report

On 01/09/2018 09:58 AM, Jason Azze via devel wrote: At the risk of sounding like a drop-out from a Scrum Master training camp, could you explain briefly what the "story" is for this tool? I use SNMP every day to monitor the health of lots of servers and services, but, to be honest, I haven't

Re: What do I do about this? (Pipeline failed - can't find bison)

On 01/08/2018 05:30 AM, Hal Murray via devel wrote: This smells like a Gitlab glitch, probably transient. Is there a simple way to say "Please try again?" (without adding clutter to git's log) Click the pipeline icon, there will be options from there. -- /"In the end; what separates a Man,

Proposal: HAZARD tag

First proposal: For cases where a piece of code needs to embed brittle assumptions, in addition to the comment block explaining said assumptions it should also include a HAZARD tag with a one line summary (not unlike a git summary line). While this standard will only help to catch instances

Re: Request for data / ntpsnmpd report

I finally tracked down where root_distance is created. ntpd/ntp_proto.c line 2130 function root_distance. However it is a function internal to ntp_proto.c, not mentioned in header files. And as far as I can tell the values generated from it are only ever used inside the functions in that

Re: Request for data / ntpsnmpd report

Accidentally replied to ESR directly instead of the list Update on previous status. On 01/09/2018 11:42 AM, Eric S. Raymond wrote: Heads up, Hal! I'd like your opinopn on these. Ian Bruene via devel<devel@ntpsec.org>: * Time Resolution (not to be confused with Time /Precision/,

Re: Request for data / ntpsnmpd report

On 02/01/2018 11:22 AM, Mark Atwood, Project Manager wrote: The SNMP MIB RFCs are notorious for including magic blue sky values and measurements that nobody knows how to measure and that are not well defined. For things that don't make enough sense, it's ok to not implement that particular

ntpEntStatPktModeTable.... what is it? (NTPv4-MIB)

Returning to work on ntpsnmpd after a hiatus I looked through the MIB entries and discovered that I had accidentally skipped one of the tables. The table is described as "The number of packets sent and received by packet mode. One entry per packet mode.". It has 3 fields per mode:

Re: ntpEntStatPktModeTable.... what is it? (NTPv4-MIB)

On 02/13/2018 04:23 PM, Hal Murray wrote: devel@ntpsec.org said: From the possible values of ntpEntStatPktMode it would appear that the "modes" this table is talking about are not the normal NTP communication modes like mode6. What are the possibilies? From the MIB: ntpEntStatPktMode

Re: prep for 1.0.1

On 02/20/2018 08:41 PM, Mark Atwood via devel wrote: Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid

Re: prep for 1.0.1

On 02/20/2018 09:19 PM, Eric S. Raymond via devel wrote: I'll get on the tracker and swat a bunch of small issues I see. The big deal is whether we have closure on the Python installation mess. The Python installation works the way it did before that last minute 'fix' before 1.0. So the

ntpsnmpd beta

MIB implementation complete except for where explicitly not implemented. No known bugs extant, mostly due to lack of swarm attack. Packet handling implemented for all required PDU types. But not all in general. Can has testers? -- /"In the end; what separates a Man, from a Slave? Money?

Re: ntpsnmpd beta

Query: what file can/should I use for config data that ntpsnmpd needs to be able to change on the fly? -- /"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

Re: ntpsnmpd beta

On 02/16/2018 01:09 PM, Eric S. Raymond wrote: Ian Bruene via devel <devel@ntpsec.org>: Query: what file can/should I use for config data that ntpsnmpd needs to be able to change on the fly? Does a human ever set this data? If not, there's a (weak) convetion of putting the file in /v

Fwd: Re: ntpsnmpd beta

Rellim To: Ian Bruene <ianbru...@gmail.com> Yo Ian! On Fri, 16 Feb 2018 11:03:36 -0600 Ian Bruene via devel <devel@ntpsec.org> wrote: Query: what file can/should I use for config data that ntpsnmpd needs to be able to change on the fly? You think it will be that simple? :-

Re: ntpsnmpd beta

On 02/16/2018 02:17 PM, Hal Murray via devel wrote: Is there a client for ntpsnmpd? I'd expect the client side to be part of a snmp package. Do we need samples for that? How many snmp packages are there? ntpsnmpd only talks to the snmpd daemon. Various sorts of clients, including the

Re: Future projects (post release)

Future project: refactoring ntpd's system variables into a struct. I've been looking at the code around mode 6 generation and discovered that in some areas it's still globals all the way down. Translating these globals will make future refactoring/translating easier. -- /"In the end; what

Re: 1.0.1 and ntpsnmpd

On 02/25/2018 04:39 PM, Hal Murray via devel wrote: devel@ntpsec.org said: The only real blocker that I can see at this time is the need for broad testing. [reiteration of me requesting testers / reviewers goes here.] Is there a HOWTO that tells me how to set things up? I'll get to work on

1.0.1 and ntpsnmpd

Is ntpsnmpd having it's Official Release with 1.0.1, or are we punting to the next release? Right now I do not believe that it would be crazy, but there are still options that need work, and logging is not systematic and consistent yet. The missing options I've thought of are all simple to

Re: 1.0.1 and ntpsnmpd

On 02/25/2018 04:43 PM, Eric S. Raymond via devel wrote: Gary E. Miller via devel <devel@ntpsec.org>: On Sun, 25 Feb 2018 16:02:00 -0600 Ian Bruene via devel <devel@ntpsec.org> wrote: [...] OTOH, people will not test it until it is easy to test. So I'd suggest putting

SOS: SNMP/AgentX traps

I have started implementing notification support in ntpsnmpd, however I have been unable to get it working so far. I do not believe there is an error in the packet encoding, but there must be a problem somewhere in my code as the master agent only ever returns responses with error 268

Re: Attn: Install path debaters

Uh, news to me that any solution was agreed to. Last I heard this group was in no way on the same page. Rather than having me misread your code, can you put a plain summary here? It's rlaager's code, the bash sys.path in each program one. Not sure how that makes me feel better. Exactly

Re: 1.0.1 and ntpsnmpd

ntpsnmpd is now fully part of the build. Manpage installs properly. make-tarball includes it (mostly because it slurps up everything). -- /"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.

Re: Initial test coverage report

I said: On 06/19/2018 07:02 PM, Ian Bruene wrote: Also at least one test file is misnamed. I will go through these and check / patch everything to be where it should be I need to sanity check this first: Am I correct in thinking that tests should be arranged as 1 file of tests

Re: Initial test coverage report

On 06/20/2018 01:52 PM, Matthew Selsky wrote: Is there a way to have Unity spit out information on test coverage percentage? If so, tell me how and I'll take a look at wiring it into our gitlab CI. Unfortunately I know almost nothing about Unity. -- /"In the end; what separates a Man,

Re: Preparing for upcoming release

Forwarded because wrong reply target Forwarded Message Subject:Re: Preparing for upcoming release Date: Mon, 13 Aug 2018 14:36:27 -0500 From: Ian Bruene To: Eric S. Raymond On 08/13/2018 02:34 PM, Eric S. Raymond via devel wrote: So, core devs:

Re: ANNOUNCE: NTPsec version 1.1.2

Fwd due to Reply/Reply all mistake. On 08/29/2018 01:26 PM, Eric S. Raymond via devel wrote: Those projects do tend to blur tigether in my mind. You were planning to do quue removal at one point. Is that still on your list? I've poked at both of those over the last couple months, didn't

Re: Trying again: prep for 1.0.1

On 03/09/2018 12:43 PM, Mark Atwood, Project Manager via devel wrote: Ok, trying again.  We held the 1.0.1 release for a fix for a problem that Hal discovered and fixed.  Thank you, Hal! Since we have a CVE fix in this release, and also a "make it work better on AWS AMIs" fix in, I do want

Re: 1.0.1 and ntpsnmpd

On 03/15/2018 02:35 PM, Jason Azze via devel wrote: Sanjeev, was this template created in response to your bounty? I finally worked through getting ntpsnmpd up and talking to AgentX on my test machine, but all of my Cacti graphs from netniV's template come up NaN. Ian, could you recommend

  1   2   >