On Fri, Feb 28, 2020 at 3:26 AM Hal Murray via devel <devel@ntpsec.org> wrote: > > Lots of handwaving here. :::snip::: > Can we break the current ntpd blob into smaller chunks? How about: > NTP server > NTP client > NTS-KE server > ntpq client
I think you mean mode 6/7 server there. It might also be a place to configure and read/write files. > I don't have good proposals for how the ntpq client can get information from > the other chunks. The only info from the NTS-KE server is counters. Shared > memory would work fine. Same for most of the NTP server. The part of a NTP > server that isn't counters is the MRU list. If you are rotating the key, you would also need to synchronize that. > One of the interesting advantages of the one-big-blob approach is that all the > parts are using the same version of things in memory. For shared memory, we > would have to work out some sort of versioning. The ntpq client would have to > be able to read all old versions. If you hammer the bugs out of the initial release, you will likely not need as many versions. > Ignoring version problems, are there parts of the ntpq protocol (other than > mru) that won't work with shared memory? I'm assuming an array for the peer > stuff. I had a pitch I never got around to making that would enable mru in a separate process. It sent the remote addresses to the mode 6 server. > The configure options to a server are simple enough that a simple parser would > be good enough. Perhaps that's only because I'm willing to discard frills and > options from the configuration. For example, most of the log files are client > side. I'm willing to make the few the server needs be day only with default > names and link from name-without-date to the current name-with-date. Yes, we will not get any flak from the naysayers or Stenn for "throwing away perfectly good options". > I haven't thought much about ntpq. I'm willing to make a new protocol. Perhaps a mode 6 replacement over https? _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
