17 Nov
2021
17 Nov
'21
7:47 p.m.
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:
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
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.