[HECnet] PyDECnet setup

On Nov 17, 2021, at 1:47 PM, Steve Davidson <steve at davidson.net> wrote: The ?reload? would be similar to ?copy known nodes from? <node> | <file> -Steve Davidson SF:iP1 > On Nov 17, 2021, at 13:43, Paul Koning <paulkoning at comcast.net> wrote: > > ?That's not a NICE operation, so it would be some sort of system-specific request. But the real issue isn't how to ask for it but how to implement it. At the moment all the configuration state is created at startup time. A bunch of it can in principle be changed or added later, that's what was behind the note I wrote earlier. Some of it would be quite problematic. > > A "reload my config" operation could be done as a sequence of "shutdown then restart", breaking all connections (briefly) in the process. That's probably doable but ugly. Anything nicer would involve comparing the old and new config and internally generating the deltas, which then would be accepted or rejected according to the rules I suggested earlier. For example, you can't change node type (router to endnode, or phase 2 to phase 4) on the fly, so a config file reload that did that would not be valid unless it were handled as an internally generated restart. > > paul > >> On Nov 17, 2021, at 1:25 PM, SA <steve at davidson.net> wrote: >> >> Actually it should look more like: >> >> ?set exec reload? [<from> <source>] >> >> -Steve, NA1T >> >> On 11/17/21, 1:23 PM, "SA" <owner-hecnet at Update.UU.SE on behalf of steve at davidson.net> wrote: >> >> Paul, >> >> How about: >> >> ?set exec reload? <from> <source> >> >> -Steve, NA1T >> >>> On 11/17/21, 1:05 PM, "Paul Koning" <owner-hecnet at Update.UU.SE on behalf of paulkoning at comcast.net> wrote: >>> >>> >>> >>>> On Nov 17, 2021, at 12:05 PM, Robert Armstrong <bob at jfcl.com> wrote: >>> >>>> I have done a bit of work to allow "change" type NICE requests, starting with the "zero counters" request. That isn't done yet. >>> >>> Personally, I?d love to see that. I?d also especially like to be able to turn individual circuits on and off via NICE and maybe even reload the entire pyDECnet config file. That?d make testing and changing things a lot easier. >> >> Some possibilities, based on VERY cursory analysis. >> >> "zero counters" should be straightforward. >> >> Adding and removing node entries (for remote nodes) also should be straightforward. >> >> Circuit state (on/off) is a bit of work because routing gets involved -- a circuit that is off doesn't reach anyone and can't have route vector messages sent to it. >> >> Changing circuit or executor parameters may be easy or not, it depends on the parameter. For example, executor parameter max cost is not hard; max nodes is much harder because some routing data structures are built based on that value. The same, only more so, applies to executor address and type. Similarly, for changing circuit parameters the answer is also "it depends". >> >> Creating new circuits (additional circuits) may not be as hard as I thought. It's difficult as a NICE operation since many of the configuration parameters in the config file are non-DECnet things like IP addresses and circuit emulation protocols. But that's what OS-dependent parameters are for :-). That also implies that it might be possible to read those settings; right now they aren't visible. I had thought of adding them to the web interface (with an ability to suppress that if desired); hadn't thought of NICE but the same reasoning applies there. >> >> As for access control, PyDECnet already supports username/password checking, so NICE "modify" actions can be tied to an ACL that specifies the user names permitted to do this. By default that might be just "root". So if you connect to NICE with the username of a permitted user and the correct password for that user, the PAM module would approve those credentials and then that would let you do the operation. >> >> paul >> >> >> >> >> >> >> >