On 2011-11-26 13.13, H Vlems wrote: You may be right about MIM being used as the "master" of the HECnet nodes, even though DECnet phase IV has no such thing. Right. It's purely a voluntary convention. Actually I didn't use MIM because I notcied it ran RSX-11, not an o/s I'm familiar with. So I looked at the node databases of the area routers and just included them. You do know that the OS of the host is pretty irrelevant for DECnet? You can run NCP on your local machine and query any other machine, using the same commands, no matter what the other machine is running. NCP TELL MIM SHOW KNOWN NODES works just as well on RSX, RSTS/E, VMS, TOPS-20, Windows, or (I assume) Ultrix. Exactly how you copy the nodename database from MIM to your machine is a question for your local machine, and does not much involve MIM. For VMS, COPY KNOWN NODES does the trick. If you run RSX, there is a program called NNC, which do the work. The copy known nodes NCP command is powerful, it also allows you to mess up a node database pretty fast! Indeed. So you might want to think twice, or else you can start by just copying the nodenames to the volatile database. If things get screwed up, you can just restart and it will be reverted. (I'm talking VMS here, for other OSes, the colutions, problems, and workarounds differ.) With a little programming, the information in Datatrieve may be converted to commands that may be run by NCP. A text file filled with commands like: DEFINE NODE 63.3 NAME TEST3 The last command would then be set known nodes all (IIRC). Of course you could remove all unwanted entries first. Yes. In fact, the makefile I have on MIM to convert the Datatrieve database to nodenames looks like this: FIX.CMD: HECNET.IDX DTR @ READY HECNET FIND HECNET WITH NAME NOT EQ "$(SYSNAM)" FOR CURRENT PRINT "def nod " | NODE_ADDRESS | " name " | NODE_NAME - ON FIX.CMD ^Z sub /nonotify=FIX and FIX.BAT is essentually just running NCP, and using FIX.CMD as the input. Of course a few things are in the details, but you get the idea, I would think... Anyone else could do the same trick, using the remote datatrieve interface to access the nodename database on MIM, and setting up the local nodename database. That would also allow you to pick just certain areas, or whatnot... Johnny -----Oorspronkelijk bericht----- Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Johnny Billquist Verzonden: zaterdag, november 2011 12:48 Aan: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Integrating with the Italian network. On 2011-11-26 12.05, H Vlems wrote: I agree with Johnny. The technical problems that are DECnet related, like duplicate areas and duplicate nodenames are easily solved. Possibly a lot of work, e.g. I had to move all my machines to another area and it takes less than 5 minutes per system. Mandatory reboot included. Incidentally, I documented the required procedures for several operating systems (VMS, linux and Windows) and when appropriate for both phase IV and phase V. So a couple of simple agreements is all that is necessary to merge the two networks. "Ownership" of area 1 may possibly have ego involved though I doubt that Johnny would care much. Right. The biggest concern would perhaps be that MIM is used as (I think) the most central repository of HECnet related information, and as such, it might be a bit unfortunate to move around. But apart from that, any area is as good as any other area. Moving means some work, but it is not complicated. What I've read about the "enhancements" to the bridge program is yet another matter. First off, it ain't called bridge for nothing: like any layer 2 bridge the program moves packets between ports and is transparent to both the content of the datagrams and the functionality of the protocol. Including DNS like functionality violates that rule. I also wanted to keep the complexity and overhead down. Otherwise, yes, you could change from UDP to TCP, include SSL, and certificates, to make sure we keep it safe. But that would incur quite some costs both from an administrative point of view, as well as lots more CPU resources to run the bridge, and also more problems in porting it to other systems. In my opinion, if anyone wants a central name repository for DECnet please upgrade to DECnet phase V. Well that, or else continue with the "voluntary" system we have in place now. Which is that I keep a database on MIM, to which all can send in registrations, and anyone can cope the nodename database from MIM to their own machine to get the same view as MIM have. The actual database I have on MIM is stored in Datatrieve, with some additional information, and then the DECnet nodename database is created from that Datatrieve source. Which is my way of saying that I'm not too fond of this "enhancement"... :-) Johnny Hans -----Oorspronkelijk bericht----- Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Johnny Billquist Verzonden: zaterdag, november 2011 11:36 Aan: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Integrating with the Italian network. On 2011-11-26 08.43, Angela Kahealani wrote: On Sat, Nov 26, 2011 at 02:35:17AM -0500, Steve Davidson wrote: Well here's three reasons: 1) they use DECnet area 1 thus area collision Yes. That was an unfortunate decision of them. 2) they use some of the names we already use thus name space collision That is not really a big issue. DECnet do not have a requirement for a coherent nodename database. Every machine can have its own. I keep a nodename database on MIM, which people are welcome to register in, for us to be able to copy and keep a synched version, but anyone on HECnet can really have their own different database if they want to. 3) and from what I remember, they are entirely dynamic DNS based and thus had to make major changes to the bridge to even exist. The changes they made work just fine, BTW... Yes. That was one reason that I remember, now that you mention it. -Steve So, then do they not have a superior solution which could be adopted by the existing HECNET? Depends on your definition of "superior". They manage dynamic addresses, at the cost of either exposing to name resolution hiccups, slowness, name poisoning, and whatnot, or else a potential for security exposure if they send, and accept traffic from random nodes in some time window. The latter reasons are why I do not have such a thing in the bridge in general. DECnet is not a very secure protocol. Passwords fly through it in clear text. I am not fond of the possibility of that traffic going to some random address in general, and even less fond of opening up the virtual ethernet to any random place to inject traffic. I'm happy to discuss and explain the problems if people want to, but I seriously doubt I'll change my mind. I have given it much thought over the years. Johnny