I've seen/heard of various stories about how people update their
nodename databases on their machines, hacking together scripts, and
processing files. So I figured I should write a small mail about the
topic (I should create a web-page with this information as well).
The main/basic point is that people are creating work for themselves
they really don't need.
Exactly how you update your nodename database on your machine depends on
what OS you are running, but there are basically prepared tools and
scripts already existing for pretty much any scenario. And if you happen
to have a system or need not currently covered, I can easily create one
for you as well.
But before going into the solutions, let me explain a bit about the
source of the data here.
DECnet phase IV do not have a centralized nodename system like DNS. Each
node in the DECnet network has its own nodename database, and every
machine can have its own name for another machine, independent of what
that other machine thinks its own nodename is.
However, in order to make it easier for multiple people and machines to
talk, it helps if everyone have a somewhat similar database. And here is
where the nodename database in MIM comes it. The nodename database that
I have on MIM is not the regular DECnet nodename database. Instead I'm
using DATATRIEVE to maintain a nodename database, which contains more
information than just the number and name. It contains the owner,
information about the software and hardware of the node, the location,
and when things were updated. This database is what is queried when
someone goes to http://mim.stupi.net/nodedb . And that page is generated
by just making queries in DATATRIEVE. If someone have a host with
DATATRIEVE on it, it is even possible to remotely access this DATATRIEVE
database over DECnet (you'll only have read-only access).
I have been considering possibly adding a web interface for people to
possibly be able to update their own information remotely, but so far
that's been a low priority thing. Maybe one day...
From this DATATRIEVE database I can then generate the DECnet nodename
database on MIM. This is a simple makefile actually. Whenever I run it,
it will create a bunch of different files (I'll get to that in a
moment), and detect if any changes have happened on the DECnet level of
things. If so, it will send a mail to people who have requested it,
informing them that the nodename database have been updated, and they
should update the nodename database of their own machines.
I hope this makes it apparent that creating various files based on the
nodename database is actually very simple. This is in a sense what
DATATRIEVE is good at. Creating reports is sortof what all these output
files are.
So - what files do I create today? Well, here is a short list:
FIX.CMD - This is a script file suitable for RSX systems using CFE.
However, it's sortof specially tailored for MIM, so it's not a file I
would recommend anyone else to use.
FIX.COM - This is a script for VMS systems using phase IV.
FIX.PHV - This is a script for VMS systems using phase V.
FIX.IMP - This is a script for VMS for anyone using DECdns.
FIX.T20 - This is a script for TOPS-20.
HECNET.PY - This is a definition file for PyDECnet.
FIX.RST - This is a script for RSTS/E.
NODENAMES.DAT - This is basically just the basic information is a simple
output form from DATATRIEVE. It exist mostly for historical reasons, but
I understand that lots of people actually take this file, and then write
code to process, extract and apply information from this file.
In addition, some systems can directly import nodenames from another
machine on DECnet, meaning you do not have to fetch and run any scripts
at all.
So here is the actioins you need to do on each system in a summarized form:
RSX:
In RSX, there is a tool called NNC which copies definitions from another
node. Copy over MIM::HECNET:NNC.BAT which is a batch file you can use
which does all the work of importing the latest definitions from MIM and
updating your local system. All you need to do is just "SUBMIT NNC.BAT"
and you are done.
VMS:
With phase IV, the node copy capability is build into NCP. All you need
to do is: "NCP COPY KNOWN NODES FROM MIM TO BOTH" and you are done.
With phase V, copy over FIX.PHV and run it, or just directly run it from
MIM like this: "@MIM::HECNET:FIX.PHV"
If you run DECdns, grab FIX.IMP, and run it with whatever tool is used
to manage this (sorry that I can't help more, I don't really have any
experience with DECdns).
TOPS-20:
Grab MIM::HECNET:FIX.T20 and run in in the NCP submode of OPR (if I
remember the setup correctly).
RSTS/E:
Grab MIM::HECNET:FIX.RST, and run it with "@FIX.RST".
PyDECnet:
Fetch hecnet.py by doing "wget mim.stupi.net/hecnet.py". Place that
where you have configured PyDECnet to get the nodenames from, and you
are good (not sure if you need to restart PyDECnet).
Now. If you have some other system with some specific format you need,
just let me know, and I'll create such a file as well. It's trivial for
me to do this from DATATRIEVE. If you spot something wrong/bad in some
file created today, let me know, and we'll fix it. If you see any errors
or omissions in the information in this mail, let me know, and I'll get
it corrected. I will create a web page with this information as well.
If you want to get a mail whenever the nodename database is updated,
just let me know and I'll add you to the list.
And HECnet is slowly growing. Occasionally a completely new person/site
gets connected. Occasionally people add more nodes. The online presence
seems pretty constant. At the moment 19 areas are online. In area 1,
currently there are 19 machines online. Looking at Paul's HECnet map
(http://akdesign.dyndns.org:8080/map), there are machines online in
quite different locations, covering a large part of the world. I find
this cool, and even though there isn't a lot being done, it's still fun.
Well. Have a nice weekend everyone, and I hope some people find this
information useful.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I finally got my issues with Comcast straightened out and I now have static IP addresses. They are
IPv4: 50.185.8.122
IPv6: 2603:300b:6c4:21a0:c77b:4f58:27e4:6de2
These are also always available in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>
Hopefully, this will be the last change for a while.
Mark Berryman
Area 27
Version 5.3(235)-5 incorporates all fixes since the major release of
5.3, Edit 230 in January of this year. These are as follows and can be
identified in the code with the edit number as the prefix of a comment.
<about:blank?compose#_Toc137380940>
[231] Fix RECEIVE with no file name
[232] 36 bit byte file sizes
[233] Transaction Log and Debug log fixes and enhancements
Transaction logging
Garbled Text
Write-Protection Failures
Enhancements
Debug Log Decode Fix
[234] Error messages may not be seen if displayed in remote server
[235] Properly signal and handle file errors in server mode
Additional Batch Tests
K2036P: Kermit-20 36 Bit Mode via pseudo-terminal
K2036C: Kermit-20 36 Bit Mode via pseudo-terminal with parity
Updated Help
All source, documentation, executables, control files and test data are
available for Anonymous NFT on HECnet from VENTI2::PS:<OINKY.K20MIT> and
associated subdirectories. Documentation includes more detail on the
above list. All regression tests have passed except for Tops-10 because
of some local networking issues.
Be aware that VENTI2:: is running a FAL alpha candidate, so let me know
if you get unexpected behavior.
Hi,
Is anyone testing this mailing list's recipients?
The reason I ask is:
06-02 00:07:58 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:07:59 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:34:26 NOREC SMTP OKBL DE 65.108.62.138:40994 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:45:56 NOREC SMTP OKBL DE 65.108.62.138:41946 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:57:11 NOREC SMTP OKBL DE 65.108.62.138:43082 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
Activity from cassini.dfupdate.se is valid and expected.
The other attempt(s) from static.216.112.243.136.clients.your-server.de was an attempted non-local relay to jessindewinter(a)gmail.com<mailto:jessindewinter@gmail.com>
It wasn't exactly a problem and the attempt was denied with some tar-pitting along the way.
Times in GMT+01:00 (BST) by the way.
Keith
Sometime around mid-2022 the Linux kernel developers decided to remove the DECnet code from the Linux
kernel. Kernel 6.0.x was the last release which included source code for a DECnet implementation. More
recently, there has been some discussion around removing the code from the Long Term Support kernels.
These changes mean that the repository I have been maintaining at
<https://github.com/JohnForecast/RaspbianDECnet> can no longer be installed on recent releases.
Over the past year or so, I have been working on a replacement for this repository with the following
characteristics:
- Designed to be built as an external kernel module
This simplifies and speeds up the installation since we no longer need to rebuild the entire
kernel.
- Can only be built as an ethernet endnode
Again this substantially simplifies the kernel code. The routing code was alway marked as
“experimental” and I never tried to get it running. If you need a DECnet router, pyDECnet or
Route20 are much better solutions.
- Minimize the use of Linux kernel frameworks
Many of the problems with keeping RaspbianDECnet running between Linux versions
were changes to the kernel framework APIs. By limiting the use of these APIs I am hoping
that the kernel module will need fewer changes to keep up with kernel changes. So far,
I have had to make one additional conditional code change at kernel 6.5 and that was in
the socket layer so all networking code would need to be changed.
In addition to a new kernel module there have been a number of changes to the userland code:
- What used to be “fal2” is now the default file access listener. The old “fal” is still available in the
“fal-old” directory
- What used to be “nml2” is now the default and only network management listener.
- There is now a subset implementation of “ncp” which is sufficient to support all of the requests
available from the Linux network management listener. It does implement a “tell” prefix so all
of these commands may be issued to remote systems. In addition, it implements
“ncp copy known nodes from <node name/address>” to update the local node name database.
- The new kernel module now supports node counters as defined in the Network Management
Specification and the ncp/nml combination are able to display and zero them.
- The installation procedure is no longer targeted solely at Raspberry Pi releases. The current
procedure supports installation on systems derived from Debian or Fedora although only a
limited number of distributions have been tested (see README.DECnet).
This new release is available at:
<https://github.com/JohnForecast/LinuxDECnet>
and should be considered to be in Beta test at this time. See README.DECnet in the top level directory
for more information and installation instructions.
Hey folks. I've gotten a Pro380 running at LSSM, and have just
gotten a DECNA board installed. Can anyone point me to any docs for
Pro/DECnet? I don't see much online. I'd like to get it talking to the
rest of the DECnet machines at the museum and on HECnet. And, ideally,
LAT if possible.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
