Removing traps feature
fallenpegasus at gmail.com
Thu Sep 8 13:23:01 UTC 2016
Ok. Thank you Hal and Eric.
Eric, remove the existing traps code from NTPsec.
We will build a snmp subagent later, when we see user need..
On Thu, Sep 8, 2016 at 4:23 AM Eric S. Raymond <esr at thyrsus.com> wrote:
> Hal Murray <hmurray at megapathdsl.net>:
> > I don't know of any reason not to remove it, especially if it is broken.
> > I think we need a plan to support SNMP if anybody gets interested. I
> > we will do that with some translation code running as a separate job.
> Agreed. I think this can and should be accomplished by plugging together
> three components:
> (1) the Mode 6 Python client code I wrote to replace ntpq with.
> (2) The Python SNMP library
> (3) The Python socketserver library
> I don't think this will be difficult - I'd actually be surprised if a
> basic SNMP daemon made from these pieces runs much over 100 LOC and
> I'm pretty sure I could write and test it in a day. Data flow: when
> you access an SNMP resource at the daemon, this gets translated to a
> Mode 6 query, with the response updating the MIB and posted back to
> your SNMP client.
> > I assume we will want traps. We could either do that by polling at some
> > rate, or by re-implementing a trap feature that the translation job
> could use.
> > Traps are slightly ugly. We probably don't want to process them when
> > happen due to opportunities for traps within traps and such. I think it
> > would work to set a flag and process traps later similar to the way we
> > process flags from signals.
> There's an SNMP trap feature. I could speculate further but I don't think
> there's much point to doing so before we have evidence of some user demand.
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> devel mailing list
> devel at ntpsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel