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.. ..m On Thu, Sep 8, 2016 at 4:23 AM Eric S. Raymond <[email protected]> wrote: > Hal Murray <[email protected]>: > > 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 > assume > > 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 > TBD > > 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 > they > > 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 > [email protected] > http://lists.ntpsec.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
