Config file please ? *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:02 PM *To:* hecnet at Update.UU.SE *Subject:* [HECnet] PyDECnet setup That other thread is getting out of hand so I'll start a new one. I've started getting this error: Exception in thread https: Traceback (most recent call last): ?File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner ???self.run() ?File "/usr/lib/python3.8/threading.py", line 870, in run ???self._target(*self._args, **self._kwargs) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 103, in serverstart ???httpd = DECnetMonitor (server_addr, DECnetMonitorRequest, ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 126, in __init__ ???self.socket = source_addr.create_server () ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 399, in create_server ???sock = self.bind_socket (self.listen_family) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 387, in bind_socket ???sock.bind (self.sockaddr) OSError: [Errno 98] Address already in use Neither lsof nor netstat show that port in use. Doesn't matter if I use the default 8000 or set something different, I get that every time. I didn't always though. This was running fine before I tried adding the circuit for ethernet access. Thoughts? -brian

Are you sure all PyDECnet processes are stopped at the point where you trying to start? Other thing, where is the internal argument for the ETH-0 circuit documented? Shouldn?t that be the Linux device name where you run pcap? Assuming that the error occurs when you uncomment the ?circuit? line *Wilm* *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:09 PM *To:* hecnet at Update.UU.SE *Subject:* Re: [HECnet] PyDECnet setup Oops, I knew I forgot something. Trying to rush the email out. router.conf: system --identification "PyDECnet, A52RTR - Quarteira, Portugal" routing 52.1023 --type l2router logging console @nodes.conf circuit mul-29-2 Multinet --mode connect --destination 82.70.71.174 --dest-port 9608 --cost 4 --t3 180 #circuit eth-0 Ethernet internal --mode pcap --cost 1 http.conf: http --api --insecure-api -brian On 17/11/21 13:06, Wilm Boerhout wrote: Config file please ? *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> <mailto:owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:02 PM *To:* hecnet at Update.UU.SE *Subject:* [HECnet] PyDECnet setup That other thread is getting out of hand so I'll start a new one. I've started getting this error: Exception in thread https: Traceback (most recent call last): ?File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner ???self.run() ?File "/usr/lib/python3.8/threading.py", line 870, in run ???self._target(*self._args, **self._kwargs) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 103, in serverstart ???httpd = DECnetMonitor (server_addr, DECnetMonitorRequest, ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 126, in __init__ ???self.socket = source_addr.create_server () ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 399, in create_server ???sock = self.bind_socket (self.listen_family) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 387, in bind_socket ???sock.bind (self.sockaddr) OSError: [Errno 98] Address already in use Neither lsof nor netstat show that port in use. Doesn't matter if I use the default 8000 or set something different, I get that every time. I didn't always though. This was running fine before I tried adding the circuit for ethernet access. Thoughts? -brian

I see. It is your privilege to name your network devices ? So then it must be one of the other lines, most suspect is the multinet line of course. I have no experience with that, I?m using DDCMP lines for my point-to-point connections to other areas. But you say it has worked before? New version? Then we must wait until Paul finds the time to respond. *Wilm* *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:42 PM *To:* hecnet at Update.UU.SE *Subject:* Re: [HECnet] PyDECnet setup All the processes are stopped. I don't see anything listening on those ports. internal is the name of the interface., but that line is commented out currently because I thought that was the cause (the only thing I added between it working and it not working) but even commented out that doesn't seem to have fixed it. -brian On 17/11/21 13:31, Wilm Boerhout wrote: Are you sure all PyDECnet processes are stopped at the point where you trying to start? Other thing, where is the internal argument for the ETH-0 circuit documented? Shouldn?t that be the Linux device name where you run pcap? Assuming that the error occurs when you uncomment the ?circuit? line *Wilm* *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> <mailto:owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:09 PM *To:* hecnet at Update.UU.SE *Subject:* Re: [HECnet] PyDECnet setup Oops, I knew I forgot something. Trying to rush the email out. router.conf: system --identification "PyDECnet, A52RTR - Quarteira, Portugal" routing 52.1023 --type l2router logging console @nodes.conf circuit mul-29-2 Multinet --mode connect --destination 82.70.71.174 --dest-port 9608 --cost 4 --t3 180 #circuit eth-0 Ethernet internal --mode pcap --cost 1 http.conf: http --api --insecure-api -brian On 17/11/21 13:06, Wilm Boerhout wrote: Config file please ? *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> <mailto:owner-hecnet at Update.UU.SE> *On Behalf Of *Brian Hechinger *Sent:* Wednesday, November 17, 2021 2:02 PM *To:* hecnet at Update.UU.SE *Subject:* [HECnet] PyDECnet setup That other thread is getting out of hand so I'll start a new one. I've started getting this error: Exception in thread https: Traceback (most recent call last): ?File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner ???self.run() ?File "/usr/lib/python3.8/threading.py", line 870, in run ???self._target(*self._args, **self._kwargs) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 103, in serverstart ???httpd = DECnetMonitor (server_addr, DECnetMonitorRequest, ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 126, in __init__ ???self.socket = source_addr.create_server () ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 399, in create_server ???sock = self.bind_socket (self.listen_family) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 387, in bind_socket ???sock.bind (self.sockaddr) OSError: [Errno 98] Address already in use Neither lsof nor netstat show that port in use. Doesn't matter if I use the default 8000 or set something different, I get that every time. I didn't always though. This was running fine before I tried adding the circuit for ethernet access. Thoughts? -brian

You have both http and https enabled (both are enabled by default) so it will try to bind ports 8000 and 8443. paul

I think so. ?It will obviously fail later on, but it looks like the bind happens before it realizes that it has no cert. ?If you don't want https, add --https-port 0. I suppose I should force that if no cert is specified, that would be logical. paul

Well, it's in doc/config.txt. ?And actually it says something I had forgotten. ?If you don't specify a cert it defaults to decnet.pem. ?So it has a cert name either way. I assume that file decnet.pem doesn't actually exist. ?So you should get an error message, and "cert decnet.pem doesn't exist" would be a lot clearer. Meanwhile, the configuration file details are described pretty carefully in doc/config.txt; reviewing that can be useful. On the subject of the qmax spec, yes, for the moment that's a good idea. ?I need to implement congestion control one of these days, the algorithms are documented but I haven't gotten around to that yet. paul

BTW, I'm still trying to figure out how best to construct the API. ?What's there now seems clumsy. ?The existing network application API (see decnet/application/mirror.py) feels more like what I want, but I need to go back and see how best to work that for requests initiated from the outside, as opposed to subprocesses started from PyDECnet. paul > On Nov 17, 2021, at 9:44 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: > > Read documentation? Heathen. :-P > > Got a systemd unit file written for it and it's up and running for > good now. Woo! > > Now to figure out what I can do with the API. > > -brian >

I have done a bit of work to allow "change" type NICE requests, starting

Johnny Billquist <bqt at softjar.se> wrote: Reloading the whole config is trickier, since there isn't any defined codes/commands in NICE for it. So it would be some local extension, not available from any other type of system.

Johnny Billquist <bqt at softjar.se> wrote: And how do you issue a SET EXEC STATE ON after the OFF, via NICE?

On 2021-11-17 18:20, Robert Armstrong wrote: I did actually start considering that one as well. It could be a trick here, yes. And I just did a check in RSX. Please, people, do not do this in general. But yes, I could turn off another node by just issuing that command. I wonder if I shouldn't maybe do something about that... DECnet and security? Not in the same sentence...

I think Paul was going to implement some kind of rudimentary access control. DECnet does have a privileged and a non-privileged password after all.

I wonder if you can turn off VMS DECnet remotely too? I'm a little afraid to try...

From Dune, I did an NCP TELL IX"SYSTEM password" SET EXEC STATE OFF and...

Johnny Billquist <bqt at softjar.se> wrote: And I just did a check in RSX. Please, people, do not do this in general. But yes, I could turn off another node by just issuing that command. DECnet and security? Not in the same sentence...

I wonder if I shouldn't maybe do something about that...

Op 17 nov. 2021 om 19:16 heeft Johnny Billquist <bqt at softjar.se> het volgende geschreven: ?.ncp tell pivax0 set exec sta off NCP -- Set failed, privilege violation .set /host Host=MIM RSX-11M-PLUS V4.6 BL87mP . Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On Nov 17, 2021, at 12:05 PM, Robert Armstrong <bob at jfcl.com> wrote: 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.

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 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 >> >> >> >> >> >> >> >

-----Original Message----- From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul Koning Sent: Thursday, 18 November 2021 6:12 AM To: hecnet at update.uu.se Subject: Re: [HECnet] PyDECnet setup Not really because it implies far more than just reloading the remote node name mappings. Also, "copy known nodes" is a product-specific extension. paul wrote: 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. "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. steve at davidson.net> wrote: on behalf of paulkoning at comcast.net> wrote: wrote: starting with the "zero counters" request. That isn't done yet. 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. straightforward. circuit that is off doesn't reach anyone and can't have route vector messages sent to 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". 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. 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 >>> >>> >>> >>> >>> >>> >>> >>

Paul Koning <paulkoning at comcast.net> wrote: A "reload my config" operation could be done as a sequence of "shutdown then restart", breaking all connections

Paul Koning <paulkoning at comcast.net> wrote: If your PyDECnet is run from Unix startup machinery, typically having it exit would get it restarted shortly after.

-----Original Message----- From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Keith Halewood Sent: Thursday, 18 November 2021 10:23 AM To: hecnet at update.uu.se Subject: Re: [HECnet] PyDECnet setup I use screen -c file spec to fire off what I need and then detach, from rc.local with a sudo to get the user I want. I can then attach/detach from an interactive session whenever I want. > On 17 Nov 2021, at 23:02, Robert Armstrong <bob at jfcl.com> wrote: > > >> >> Paul Koning <paulkoning at comcast.net> wrote: >> If your PyDECnet is run from Unix startup machinery, typically having >> it exit would get it restarted shortly after. > > Yeah, Upstart will do this if you want to run pyDECnet as a service. > I often find that annoying and I don't actually do that for pyDECnet. > I have my own script for running pyDECnet instead. If it exits, it > won't come back > :) > > Bob > >

On Nov 18, 2021, at 3:53 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: On 17/11/21 23:02, Robert Armstrong wrote: I think that's his point though. Having it exit is going to have non-consistent behavior depending on how it's setup. -brian

On Nov 18, 2021, at 10:50 AM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: The statement, "Proper Unix fashion", leaves me somewhat uncomfortable. Since I'm ancient, my understanding of SIGHUP is to handle a hangup detected on the controlling terminal or the death of a controlling process. A hangup started out meaning dropping carrier on a modem or DTR on a hardwired line. It came to include a broken network terminal connection. When I think of how to handle a SIGHUP, I usually think of 'gracefully' stopping a process (I.E., saving the user's work instead of ditching it) and exiting. If you don't do that, then something else has to be used to get rid of you, perhaps a SIGTERM. The problem is that if somebody wants you gone and you don't go away, you have a 9 on your hands (SIGKILL). Now that data is gone. If you usurp SIGHUP for such use, then things like NOHUP won't do the expected thing. There are certainly reasons to be NOHUP'ed. In your superior breaks, you might not want to disappear so somebody has a chance to attach a debugger to you to try to figure out what happened. I think the better thing to do would be handle a SIGUSR1/SIGUSR2 to reparse. Of course, "proper" is a very relative term in Unix. Things change and sometimes get used for no readily apparent reason, the result being that an unspoken 'standard' happens. It is not uncommon. For example, Johnny's DECnet bridge does in fact use SIGUSR1 to display some information. However, it uses a SIGHUP to do a reparse. So maybe that's the best of both worlds... I've never felt strongly enough about the matter to suggest SIGUSR2 for a reparse, but if you want to be a purist, then it probably should. > > On 11/18/21 9:58 AM, Paul Koning wrote: > > > In proper Unix fashion it could be triggered by a SIGHUP signal

configuration". That?s certainly my experience too, although ?modern? implementations have invented things (like the ?service?) command manage daemons (now ?system services?) in a more ?friendly? fashion.

Yes, I'm aware of that particular practice, yet one hesitates to call it a 'standard'.

That being said, I don't think it unreasonable to use SIGHUP for something that is never going to have carrier dropped on it. So background 'systems' processes would be an obvious candidate.

'Early' Unix to me means before it got ported off the PDP-7.? I started using it in about 1978, which I believe was in the first decade of its public release from AT&T.? In some ways, it was a significantly different beast than what you see, today. However, I didn't start doing systems programming on Unix until about 1985 when the plug got pulled on 36 bits, first Ultrix, then Sun.? This was until about 1988.? Maybe we might call that 'middle' Unix?

Being a 'purist' in Unix is really a pointless exercise.? Vendors and developers agree on things until they don't agree and when they need something, it's anybody's guess as to what might get made into an unofficial standard.? You'd be surprised (or not).

I'm not saying it's a bad idea.? I'm saying a Unix 'standard' is whatever an unofficial majority thinks it is, which may or may not be what others think (say POSIX, for example).? You also see a lot of this in the C library.? Timing functions come to mind.

It's a slippery term and what you think is a standard today may not be in a decade or two.

------------------------------------------------------------------------ On 11/18/21 12:10 PM, Dan Cross wrote: That would be quite early indeed. :-) PDP-7 Unix was fairly short lived (a year or two?) and was left behind for a long time once they got the first PDP-11 system at BTL. I would humbly submit that that might be more properly referred to as, "primordial Unix". - Dan C. > ------------------------------------------------------------------------ > On Thu, Nov 18, 2021 at 11:57 AM Thomas DeBellis<tommytimesharing at gmail.com> wrote: > > [snip] > 'Early' Unix to me means before it got ported off the PDP-7. [snip]

I?ve encountered Linux ?experts? in the past who have, without even trying, convinced me that they?ve never seen a shell command line. All UI and no undies, so to speak. *From:*owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] *On Behalf Of *Thomas DeBellis *Sent:* 18 November 2021 17:21 *To:* hecnet at Update.UU.SE *Subject:* Re: [HECnet] PyDECnet setup You know, I like "primordial Unix" more than "early Unix".? Of course, that then leaves the question of what to call the early PDP-11 releases.? Upper Devonian? I followed the resurrection of PDP-7 based Unix at the computer museum and, for some strange reason, found the assembler based stuff of more interest than the latest Ubuntu glitz. Glitz really leaves me cold if not annoyed. ------------------------------------------------------------------------ On 11/18/21 12:10 PM, Dan Cross wrote: That would be quite early indeed. :-) PDP-7 Unix was fairly short lived (a year or two?) and was left behind for a long time once they got the first PDP-11 system at BTL.? I would humbly submit that that might be more properly referred to as, "primordial Unix". ??????? - Dan C. ------------------------------------------------------------------------ On Thu, Nov 18, 2021 at 11:57 AM Thomas DeBellis<tommytimesharing at gmail.com> <mailto:tommytimesharing at gmail.com> wrote: [snip] 'Early' Unix to me means before it got ported off the PDP-7. [snip]

On Nov 18, 2021, at 1:19 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: My wife is a college professor (definitely smarter than me) and has a tutoring business on the side. Some of the kiddies are indeed idiots, but as they typically never want to pay for anything, we don't do business with them (and for other reasons). Some of them are simply misinformed or uninformed. Among other things, I tutor shell scripting. ? You should see the lightbulb go off when they realize what they've been missing ? I get paid either way Not a bad gig. A real treat is when I get to tutor assembler. It doesn't get any better than that, but it's only once or twice a year!

On Nov 18, 2021, at 1:24 PM, Johnny Billquist <bqt at softjar.se> wrote: ... Nowadays? Unix have lost its soul anyway... It's all Linux, ...

? Tom, you're describing "proper 1970s UNIX fashion".? A SIGHUP to reload/reconfigure a running process has been standard since the mid/late 1980s, perhaps even earlier. ?????????? -Dave On 11/18/21 10:50 AM, Thomas DeBellis wrote:

------------------------------------------------------------------------ On 11/18/21 12:04 PM, Dave McGuire wrote: ? Both Ultrix and SunOS do this in most of their major subsystems. Surely you've made changes to /etc/inetd.conf. ?????????? -Dave

On 11/18/21 12:12 PM, Thomas DeBellis wrote: ? Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995..

? Very true.? The only way to truly protect yourself is to have the source code and revert any poor decisions that they make.? Oh, wait, we can do that!

On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: ?On 18/11/21 17:20, Dave McGuire wrote: It's still SunOS. Solaris is a different thing. Thanks marketing twats! So I've fallen into watching old Bryan Cantrill interviews. His rants on this are FANTASTIC. -brian

On Nov 18, 2021, at 11:56 AM, Dave McGuire <mcguire at neurotica.com> wrote: ? Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an after-the-fact rebranding, but still. What you state below is the common and accepted usage. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 11/18/21 1:05 PM, August Treubig wrote: ? Well, also, not quite.? It's still a product, if only barely. ? But commercial suitware is irrelevant.? The real meat lives on in Illumos/SmartOS/etc. ????????? -Dave

OpenIndiana rocks ? running as my file server among other things for many years now. There was a DECnet thing for some ancient version of SunOS too, haven?t been able to find it. /s. > -brian > >> On 18/11/21 18:38, Dave McGuire wrote: >>> On 11/18/21 1:05 PM, August Treubig wrote: >>> Yes, ?more correctly?, Solaris 2.x is System V. Then after about 2.6, they threw away the 2. Part. Then once the evil Oracle grabbed on, it all went into the dumpster. >> Well, also, not quite. It's still a product, if only barely. >> >> But commercial suitware is irrelevant. The real meat lives on in Illumos/SmartOS/etc. >> >> -Dave >>

Yes, ?more correctly?, Solaris 2.x is System V. Then after about 2.6, they threw away the 2. Part. Then once the evil Oracle grabbed on, it all went into the dumpster. Aug AG5AT Sent from my iPad > On Nov 18, 2021, at 11:56 AM, Dave McGuire <mcguire at neurotica.com> wrote: > > ? > Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an after-the-fact rebranding, but still. What you state below is the common and accepted usage. > > -Dave > >> On 11/18/21 12:53 PM, August Treubig wrote: >> SunOS is BSD, >> Solaris is System V. >> Aug Treubig >> Sent from my iPad >>>> On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: >>> ?On 18/11/21 17:20, Dave McGuire wrote: >>>>> On 11/18/21 12:12 PM, Thomas DeBellis wrote: >>>>> They do it _today_. >>>> Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995.. >>> >>> It's still SunOS. Solaris is a different thing. Thanks marketing twats! >>> >>> >>>>> I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. >>>> Very true. The only way to truly protect yourself is to have the source code and revert any poor decisions that they make. Oh, wait, we can do that! >>> >>> So I've fallen into watching old Bryan Cantrill interviews. His rants on this are FANTASTIC. >>> >>> >>> -brian >>> > > -- > Dave McGuire, AK4HZ > New Kensington, PA

Common, accepted and STILL WRONG. -brian On 18/11/21 17:56, Dave McGuire wrote: > > Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an > after-the-fact rebranding, but still. What you state below is the > common and accepted usage. > > -Dave > > On 11/18/21 12:53 PM, August Treubig wrote: >> SunOS is BSD, >> Solaris is System V. >> >> >> Aug Treubig >> >> >> Sent from my iPad >> >>> On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> >>> wrote: >>> >>> ?On 18/11/21 17:20, Dave McGuire wrote: >>>>> On 11/18/21 12:12 PM, Thomas DeBellis wrote: >>>>> They do it _today_. >>>> >>>> Well, since the last release of SunOS (not Solaris) was in 1994, >>>> and the last release of Ultrix was in 1995.. >>> >>> >>> It's still SunOS. Solaris is a different thing. Thanks marketing twats! >>> >>> >>>> >>>>> I think you can get burnt whether it's a bunch of academics >>>>> eternally discussing purity in committees or a couple of kids just >>>>> picking something. >>>> >>>> Very true. The only way to truly protect yourself is to have >>>> the source code and revert any poor decisions that they make. Oh, >>>> wait, we can do that! >>> >>> >>> So I've fallen into watching old Bryan Cantrill interviews. His >>> rants on this are FANTASTIC. >>> >>> >>> -brian

Still doesn't make it right. ? -brian On Nov 18, 2021, 23:44 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: > > It's the standard. =) > > -Dave > > On November 18, 2021 5:39:55 PM Brian Hechinger <wonko at 4amlunch.net> wrote: >> Common, accepted and STILL WRONG. >> >> -brian >> >> On 18/11/21 17:56, Dave McGuire wrote: >>> >>> Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an >>> after-the-fact rebranding, but still. What you state below is the >>> common and accepted usage. >>> >>> -Dave >>> >>> On 11/18/21 12:53 PM, August Treubig wrote: >>>> SunOS is BSD, >>>> Solaris is System V. >>>> >>>> >>>> Aug Treubig >>>> >>>> >>>> Sent from my iPad >>>> >>>>> On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> >>>>> wrote: >>>>> >>>>> ?On 18/11/21 17:20, Dave McGuire wrote: >>>>>> > On 11/18/21 12:12 PM, Thomas DeBellis wrote: >>>>>> > They do it _today_. >>>>>> >>>>>> Well, since the last release of SunOS (not Solaris) was in 1994, >>>>>> and the last release of Ultrix was in 1995.. >>>>> >>>>> >>>>> It's still SunOS. Solaris is a different thing. Thanks marketing twats! >>>>> >>>>> >>>>>> >>>>>> > I think you can get burnt whether it's a bunch of academics >>>>>> > eternally discussing purity in committees or a couple of kids just >>>>>> > picking something. >>>>>> >>>>>> Very true. The only way to truly protect yourself is to have >>>>>> the source code and revert any poor decisions that they make. Oh, >>>>>> wait, we can do that! >>>>> >>>>> >>>>> So I've fallen into watching old Bryan Cantrill interviews. His >>>>> rants on this are FANTASTIC. >>>>> >>>>> >>>>> -brian > > > -- > Dave McGuire, AK4HZ > New Kensington, PA

Nope! On Nov 18, 2021, 23:58 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: > > Eventually it does. :) > > On November 18, 2021 6:57:34 PM Brian Hechinger <wonko at 4amlunch.net> wrote: >> Still doesn't make it right. ? >> >> -brian >> On Nov 18, 2021, 23:44 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: >>> >>> It's the standard. =) >>> >>> -Dave >>> >>> On November 18, 2021 5:39:55 PM Brian Hechinger <wonko at 4amlunch.net> wrote: >>>> Common, accepted and STILL WRONG. >>>> >>>> -brian >>>> >>>> On 18/11/21 17:56, Dave McGuire wrote: >>>>> >>>>> Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an >>>>> after-the-fact rebranding, but still. What you state below is the >>>>> common and accepted usage. >>>>> >>>>> -Dave >>>>> >>>>> On 11/18/21 12:53 PM, August Treubig wrote: >>>>>> SunOS is BSD, >>>>>> Solaris is System V. >>>>>> >>>>>> >>>>>> Aug Treubig >>>>>> >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> > On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> >>>>>> > wrote: >>>>>> > >>>>>> > ?On 18/11/21 17:20, Dave McGuire wrote: >>>>>> > > > On 11/18/21 12:12 PM, Thomas DeBellis wrote: >>>>>> > > > They do it _today_. >>>>>> > > >>>>>> > > Well, since the last release of SunOS (not Solaris) was in 1994, >>>>>> > > and the last release of Ultrix was in 1995.. >>>>>> > >>>>>> > >>>>>> > It's still SunOS. Solaris is a different thing. Thanks marketing twats! >>>>>> > >>>>>> > >>>>>> > > >>>>>> > > > I think you can get burnt whether it's a bunch of academics >>>>>> > > > eternally discussing purity in committees or a couple of kids just >>>>>> > > > picking something. >>>>>> > > >>>>>> > > Very true. The only way to truly protect yourself is to have >>>>>> > > the source code and revert any poor decisions that they make. Oh, >>>>>> > > wait, we can do that! >>>>>> > >>>>>> > >>>>>> > So I've fallen into watching old Bryan Cantrill interviews. His >>>>>> > rants on this are FANTASTIC. >>>>>> > >>>>>> > >>>>>> > -brian >>> >>> >>> -- >>> Dave McGuire, AK4HZ >>> New Kensington, PA > > > -- > Dave McGuire, AK4HZ > New Kensington, PA

Shit dude, how long have you known me? I'm as pedantic as they come. :) On Nov 19, 2021, 00:01 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: Yup. :) And since when are you a pedant?? I've always been pedantic enough for both of us. Perhaps I just know in my heart that Sun made a mistake with the naming. ;) On November 18, 2021 7:00:22 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Nope! On Nov 18, 2021, 23:58 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: Eventually it does. :) On November 18, 2021 6:57:34 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Still doesn't make it right. ? -brian On Nov 18, 2021, 23:44 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: It's the standard. =) -Dave On November 18, 2021 5:39:55 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Common, accepted and STILL WRONG. -brian On 18/11/21 17:56, Dave McGuire wrote: Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an after-the-fact rebranding, but still. What you state below is the common and accepted usage. -Dave On 11/18/21 12:53 PM, August Treubig wrote: SunOS is BSD, Solaris is System V. Aug Treubig Sent from my iPad On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: ?On 18/11/21 17:20, Dave McGuire wrote: On 11/18/21 12:12 PM, Thomas DeBellis wrote: They do it _today_. Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995.. It's still SunOS. Solaris is a different thing. Thanks marketing twats! I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. Very true. The only way to truly protect yourself is to have the source code and revert any poor decisions that they make. Oh, wait, we can do that! So I've fallen into watching old Bryan Cantrill interviews. His rants on this are FANTASTIC. -brian -- Dave McGuire, AK4HZ New Kensington, PA -- Dave McGuire, AK4HZ New Kensington, PA -- Dave McGuire, AK4HZ New Kensington, PA

Shit dude, how long have you known me? I'm as pedantic as they come. :) On Nov 19, 2021, 00:01 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: Yup. :) And since when are you a pedant?? I've always been pedantic enough for both of us. Perhaps I just know in my heart that Sun made a mistake with the naming. ;) On November 18, 2021 7:00:22 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Nope! On Nov 18, 2021, 23:58 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: Eventually it does. :) On November 18, 2021 6:57:34 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Still doesn't make it right. ? -brian On Nov 18, 2021, 23:44 +0000, Dave McGuire <mcguire at neurotica.com>, wrote: It's the standard. =) -Dave On November 18, 2021 5:39:55 PM Brian Hechinger <wonko at 4amlunch.net> wrote: Common, accepted and STILL WRONG. -brian On 18/11/21 17:56, Dave McGuire wrote: Not quite. Solaris 1.1.2 is SunOS 4.1.4. That was an after-the-fact rebranding, but still. What you state below is the common and accepted usage. -Dave On 11/18/21 12:53 PM, August Treubig wrote: SunOS is BSD, Solaris is System V. Aug Treubig Sent from my iPad On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: ?On 18/11/21 17:20, Dave McGuire wrote: On 11/18/21 12:12 PM, Thomas DeBellis wrote: They do it _today_. Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995.. It's still SunOS. Solaris is a different thing. Thanks marketing twats! I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. Very true. The only way to truly protect yourself is to have the source code and revert any poor decisions that they make. Oh, wait, we can do that! So I've fallen into watching old Bryan Cantrill interviews. His rants on this are FANTASTIC. -brian -- Dave McGuire, AK4HZ New Kensington, PA -- Dave McGuire, AK4HZ New Kensington, PA -- Dave McGuire, AK4HZ New Kensington, PA

SunOS is BSD, Solaris is System V. Aug Treubig Sent from my iPad > On Nov 18, 2021, at 11:35 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: > > ?On 18/11/21 17:20, Dave McGuire wrote: >>> On 11/18/21 12:12 PM, Thomas DeBellis wrote: >>> They do it _today_. >> Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995.. > > It's still SunOS. Solaris is a different thing. Thanks marketing twats! > > >>> I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. >> Very true. The only way to truly protect yourself is to have the source code and revert any poor decisions that they make. Oh, wait, we can do that! > > So I've fallen into watching old Bryan Cantrill interviews. His rants on this are FANTASTIC. > > > -brian >

------------------------------------------------------------------------ On 11/18/21 1:04 PM, Dan Cross wrote: The use of SIGHUP to reread a config file comes from, at least, Unix 5th Edition. I suspect that the practice originated with the `init` process (usually PID 1) which, on receipt of SIGHUP, would reread the ttys file to figure out what typewriters were attached to the system. Prior to that, I suspect they'd have to reboot to add a new terminal to the system, but things from first through 4th edition are not as well preserved as 5th onwards, so its hard to tell. By the time Berkeley was writing things like inetd, the practice was well known. Does that make it a "standard?" Not in any formal sense, but a daemon couldn't receive a SIGHUP in the usual way an interactive process might, so piggybacking some special meaning on it makes a certain amount of sense. Has it fallen out of a favor? A bit. As Doug McIllroy put it on the Unix Heritage Society list a few years ago, signal() primarily existed to support SIGKILL, not as a principled basis for IPC. It's racy and doing Real Work in the context of an upcall from the kernel like a signal handler is fraught. - Dan C. > ------------------------------------------------------------------------ > On Thu, Nov 18, 2021 at 12:20 PM Dave McGuire<mcguire at neurotica.com> wrote: > > > Well, since the last release of SunOS (not Solaris) was in 1994, and the last release of Ultrix was in 1995.. >> ------------------------------------------------------------------------ >> On 11/18/21 12:12 PM, Thomas DeBellis wrote: >> They do it _today_.

Signals is really a very poor design/implementation of what's called an AST in RSX and VMS. Whenever I have to deal with signals I just sit a wish I had RSX around me instead. But... One have to work with the tools provided. Admittedly, signals have gotten better over the years. Nowadays they actually are reliable... (But they still suck.) ? Johnny On 2021-11-18 19:38, Thomas DeBellis wrote:

They do it _today_. I can't remember what I did in 1986, honest.? Of course I've changed /etc/inetd.conf when I put up new services.? And I can't for the life of me remember what I did to poke a re-parse. If it was a SIGHUP, then I probably thought that odd.? Now I'm dissatisfied with the term Unix 'standards' because they are until they aren't, also depending on what implementation you happen to find yourself trying to execute on.? And if it needed to change, why exactly did the old interface need to get ditched, really?? Now I have a bunch of scripts to rewrite.? For what? I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. > ------------------------------------------------------------------------ > On 11/18/21 12:04 PM, Dave McGuire wrote: > > ? Both Ultrix and SunOS do this in most of their major subsystems. > Surely you've made changes to /etc/inetd.conf. > > ?????????? -Dave >> ------------------------------------------------------------------------ >> On 11/18/21 12:02 PM, Thomas DeBellis wrote: >> >> Well, I don't remember Ultrix or SunOS doing this when I was one of >> Columbia's Unix Systems Programmers.? However, that might mean >> exactly nothing more than I don't remember and that they did do it. >> I don't remember it in any daemon that I developed. Of course, I can >> barely remember any daemon I developed... >> >> My dissatisfaction is not with the practice itself so much as what >> winds up being called a standard and who says it is.? Until somebody >> says different... >> >> >>> ------------------------------------------------------------------------ >>> On 11/18/21 11:43 AM, Dave McGuire wrote: >>> >>> ? Tom, you're describing "proper 1970s UNIX fashion".? A SIGHUP to >>> reload/reconfigure a running process has been standard since the >>> mid/late 1980s, perhaps even earlier. >>> >>> ?????????? -Dave >>>> ------------------------------------------------------------------------ >>>> On 11/18/21 10:50 AM, Thomas DeBellis wrote: >>>> >>>> The statement, "Proper Unix fashion", leaves me somewhat >>>> uncomfortable. >>>> >>>> Since I'm ancient, my understanding of SIGHUP is to handle a hangup >>>> detected on the controlling terminal or the death of a controlling >>>> process.? A hangup started out meaning dropping carrier on a modem >>>> or DTR on a hardwired line.? It came to include a broken network >>>> terminal connection. >>>> >>>> When I think of how to handle a SIGHUP, I usually think of >>>> 'gracefully' stopping a process (I.E., saving the user's work >>>> instead of ditching it) and exiting.? If you don't do that, then >>>> something else has to be used to get rid of you, perhaps a >>>> SIGTERM.? The problem is that if somebody wants you gone and you >>>> don't go away, you have a 9 on your hands (SIGKILL).? Now that data >>>> is gone. >>>> >>>> If you usurp SIGHUP for such use, then things like NOHUP won't do >>>> the expected thing.? There are certainly reasons to be NOHUP'ed. >>>> In your superior breaks, you might not want to disappear so >>>> somebody has a chance to attach a debugger to you to try to figure >>>> out what happened. >>>> >>>> I think the better thing to do would be handle a SIGUSR1/SIGUSR2 to >>>> reparse. >>>> >>>> Of course, "proper" is a very relative term in Unix.? Things change >>>> and sometimes get used for no readily apparent reason, the result >>>> being that an unspoken 'standard' happens.? It is not uncommon. >>>> For example, Johnny's DECnet bridge does in fact use SIGUSR1 to >>>> display some information. However, it uses a SIGHUP to do a >>>> reparse.? So maybe that's the best of both worlds... >>>> >>>> I've never felt strongly enough about the matter to suggest SIGUSR2 >>>> for a reparse, but if you want to be a purist, then it probably >>>> should. >>>>> ------------------------------------------------------------------------ >>>>> >>>>> On 11/18/21 9:58 AM, Paul Koning wrote: >>>>> >>>>> >>>>> In proper Unix fashion it could be triggered by a SIGHUP signal >>> >>> > >

On Nov 18, 2021, at 11:49 AM, Dave McGuire <mcguire at neurotica.com> wrote: On 11/18/21 9:58 AM, Paul Koning wrote: Paul, I think the last thing you need here is yet more suggestions on how to architect the innards of that package, but.. What I would do here is have an internal configuration data structure which stores all active configuration and can be modified by different things. One such thing would be a configuration file parser for startup time use, another might be NICE messages, etc. Then serialize and store that active configuration in a non-human-readable file. Optionally, you can recreate the human-readable file (handling any user-typed comments would be left as a significant exercise for the reader ;)) instead of storing the serialized data. But the overarching idea is to add an abstraction layer around the internal configuration structure and define a small API to access it from elsewhere in the program.

Not at the moment, and it's a large change to the design to allow configuration to change at runtime. I have done a bit of work to allow "change" type NICE requests, starting with the "zero counters" request. ?That isn't done yet. A specific change that should be small and straightforward is updating the list of node name/address pairs. ?I'm thinking of doing that in the network mapper, since it already fetches the current list from MIM. ?Right now that updates the mapper data but not the main DECnet node list. ?Once it does that, you'd be able to do the NCP "copy from 28NH" request for NCPs that implement that, or an equivalent script, to get the current database. paul

The thing is, I'm assuming that any such changes via NCP would only be temporary. Unless Paul implements a way for pyDECnet to rewrite it's own config file, then the next time you reboot or restart any changes would be lost. Is that what you're expecting? That pretty much kills any utility in this feature for me.

Also, I really like the ability to put comments in the config file. I have lots of circuits and I have to keep notes to remember what's what, and that ability to add comments would be lost with an "on the fly" circuit definition.

Speaking of the API: I've gone through several iterations on that, and I'm still not happy with the current one. The first one was a custom protocol over Unix domain sockets. The current one is bolted onto HTTP, with JSON lines as the way to encode requests and responses. The JSON bit is also how the session layer API works (if you look in application/mirror.py you'll see that). There the data streams go over pipes, i.e., independent streams asynchronously flowing in either direction. The big defect with HTTP as the building block is that it's a request/response protocol, so I end up with this ugly kludge of polling for server output. So I think the right answer is (a) keep the JSON encoding, but (b) run that over a separate connection, not HTTP, but instead just a full duplex data stream. That way when the server has stuff to send it just sends it. The connection oriented (stream mode socket) connection ensures the server knows if the client goes away. Unix sockets or TCP, I don't think it matters a whole lot. The request/response bit works well enough for state queries and also for hypothetical "set" operations. But it's just wrong for the session layer API, which I want to expose. And the same problem shows up in the MOP Console request, as is rather obvious when you try to decipher the sample application and the documentation for that feature. The full duplex connection I mentioned would cure that problem. Obviously this is an incompatible change, but I figure there aren't very many API users right now and the change would be easy to implement. paul

You have both http and https enabled (both are enabled by default) so it will try to bind ports 8000 and 8443. paul

Stick it where? What does line 2 look like afterwards ? *From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On Behalf Of *Supratim Sanyal *Sent:* Wednesday, November 17, 2021 3:26 PM *To:* hecnet at Update.UU.SE *Subject:* Re: [HECnet] PyDECnet setup Hey Brian, Also stick this into line 2 - this is Paul's magic solution to big transfers like copy all nodes from MIM to something behind A52RTR. nsp --qmax=5 On 11/17/21 9:06 AM, Paul Koning wrote: You have both http and https enabled (both are enabled by default) so it will try to bind ports 8000 and 8443. paul On Nov 17, 2021, at 8:09 AM, Brian Hechinger <wonko at 4amlunch.net> wrote: Oops, I knew I forgot something. Trying to rush the email out. router.conf: system --identification "PyDECnet, A52RTR - Quarteira, Portugal" routing 52.1023 --type l2router logging console @nodes.conf circuit mul-29-2 Multinet --mode connect --destination 82.70.71.174 --dest-port 9608 --cost 4 --t3 180 #circuit eth-0 Ethernet internal --mode pcap --cost 1 http.conf: http --api --insecure-api -brian On 17/11/21 13:06, Wilm Boerhout wrote: Config file please ? *From:*owner-hecnet at Update.UU.SE<owner-hecnet at Update.UU.SE> <mailto:owner-hecnet at Update.UU.SE>*On Behalf Of*Brian Hechinger *Sent:*Wednesday, November 17, 2021 2:02 PM *To:*hecnet at Update.UU.SE *Subject:*[HECnet] PyDECnet setup That other thread is getting out of hand so I'll start a new one. I've started getting this error: Exception in thread https: Traceback (most recent call last): ?File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner ???self.run() ?File "/usr/lib/python3.8/threading.py", line 870, in run ???self._target(*self._args, **self._kwargs) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 103, in serverstart ???httpd = DECnetMonitor (server_addr, DECnetMonitorRequest, ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/http.py", line 126, in __init__ ???self.socket = source_addr.create_server () ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 399, in create_server ???sock = self.bind_socket (self.listen_family) ?File "/usr/local/lib/python3.8/dist-packages/decnet-1.0.592-py3.8.egg/decnet/host.py", line 387, in bind_socket ???sock.bind (self.sockaddr) OSError: [Errno 98] Address already in use Neither lsof nor netstat show that port in use. Doesn't matter if I use the default 8000 or set something different, I get that every time. I didn't always though. This was running fine before I tried adding the circuit for ethernet access. Thoughts? -brian --