On Sat, Aug 23, 2008 at 6:32 PM, Johnny Billquist <bqt at softjar.se> wrote:
Bob Armstrong skrev:
All this HECnet discussion has inspired me to try and install DECnet on a
RSX-11M+ system. Man! This RSX NETGEN is only for the determined and
persistent, isn't it?
In any case, I managed to extract the PREGEN.CMD file from the tape to
[137,10] and execute it. This is what happens -
@PREGEN
.... lots of stuff deleted ....
* 02.00 Are you running on a small dual-disk system? [Y/N]: N
* 04.00 Where is the Network distribution kit loaded [S]: MS0:
* 04.01 Is the tape already loaded in MS0:? [Y/N]: Y
* 04.02 Is the tape 1600 BPI? [Y/N]: Y
...
FLX -- File not found
MS0:[137,10]NETMOV.DAT
FLX -- File not found
MS0:[137,10]NETMOV.DAT
;
; Error - The file MS0:[137,10]NETMOV.DAT could not be copied.
;
Hmmm... No file named NETMOV.DAT on the tape ...
Doing a directory of my DECNET-11M-PLUS tape, I see these files -
FLX TT:=MS0:/DI
Directory MS0:[137,10]
23-Aug-80
PREGEN.CMD 94. 13-Jun-89 <233>
DECMOV.DAT 15. 13-Jun-89 <233>
DECCFG.CMD 5. 13-Jun-89 <233>
DECPRM.CMD 7. 13-Jun-89 <233>
DECGEN.CLB 699. 13-Jun-89 <233>
DECGEN.KIT 1. 13-Jun-89 <233>
Total of 821. blocks in 6. files
Odd - there's a file DECMOV but not NETMOV. After much head scratching
and
reading of the cryptic PREGEN.CMD indirect command processor file, I've
come
to the conclusion that there are really three tapes in the RSX "DECnet"
distribution - a "generic" network tape (that's the one with NETMOV.DAT
(which unfortunately I don't have), a DECnet specific tape (which seems to
be the one tape I do have) and a PSI network tape (which I think is
optional).
Can any RSX wizard confirm this?
Hmm. You're running an "old" version of RSX are you? :-)
Yeah, it used to be two parts, and both had to be copied in, if I remember
correctly. It's been a while since I used one of those...
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
Hello!
I would comment, but Johnny did me the favor of doing so. However
there's a <BLEEP!> load of items related to what we discuss here
roosting on Trailing-Edge's sites.
For example there is the (mirrored) site for the pdp-11 (PDP-11) site,
and they also have an FTP site, ftp://ftp.trailing-edge.com in there
that's where I found enough software to make me want to find a
PDP-11/53 start doing something. (I still haven't.)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
Bob Armstrong skrev:
All this HECnet discussion has inspired me to try and install DECnet on a
RSX-11M+ system. Man! This RSX NETGEN is only for the determined and
persistent, isn't it?
In any case, I managed to extract the PREGEN.CMD file from the tape to
[137,10] and execute it. This is what happens -
>@PREGEN
> .... lots of stuff deleted ....
>* 02.00 Are you running on a small dual-disk system? [Y/N]: N
>* 04.00 Where is the Network distribution kit loaded [S]: MS0:
>* 04.01 Is the tape already loaded in MS0:? [Y/N]: Y
>* 04.02 Is the tape 1600 BPI? [Y/N]: Y
> ...
FLX -- File not found
MS0:[137,10]NETMOV.DAT
FLX -- File not found
MS0:[137,10]NETMOV.DAT
>;
>; Error - The file MS0:[137,10]NETMOV.DAT could not be copied.
>;
Hmmm... No file named NETMOV.DAT on the tape ...
Doing a directory of my DECNET-11M-PLUS tape, I see these files -
>FLX TT:=MS0:/DI
Directory MS0:[137,10]
23-Aug-80
PREGEN.CMD 94. 13-Jun-89 <233>
DECMOV.DAT 15. 13-Jun-89 <233>
DECCFG.CMD 5. 13-Jun-89 <233>
DECPRM.CMD 7. 13-Jun-89 <233>
DECGEN.CLB 699. 13-Jun-89 <233>
DECGEN.KIT 1. 13-Jun-89 <233>
Total of 821. blocks in 6. files
Odd - there's a file DECMOV but not NETMOV. After much head scratching and
reading of the cryptic PREGEN.CMD indirect command processor file, I've come
to the conclusion that there are really three tapes in the RSX "DECnet"
distribution - a "generic" network tape (that's the one with NETMOV.DAT
(which unfortunately I don't have), a DECnet specific tape (which seems to
be the one tape I do have) and a PSI network tape (which I think is
optional).
Can any RSX wizard confirm this?
Hmm. You're running an "old" version of RSX are you? :-)
Yeah, it used to be two parts, and both had to be copied in, if I remember correctly. It's been a while since I used one of those...
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
All this HECnet discussion has inspired me to try and install DECnet on a
RSX-11M+ system. Man! This RSX NETGEN is only for the determined and
persistent, isn't it?
In any case, I managed to extract the PREGEN.CMD file from the tape to
[137,10] and execute it. This is what happens -
>@PREGEN
> .... lots of stuff deleted ....
>* 02.00 Are you running on a small dual-disk system? [Y/N]: N
>* 04.00 Where is the Network distribution kit loaded [S]: MS0:
>* 04.01 Is the tape already loaded in MS0:? [Y/N]: Y
>* 04.02 Is the tape 1600 BPI? [Y/N]: Y
> ...
FLX -- File not found
MS0:[137,10]NETMOV.DAT
FLX -- File not found
MS0:[137,10]NETMOV.DAT
>;
>; Error - The file MS0:[137,10]NETMOV.DAT could not be copied.
>;
Hmmm... No file named NETMOV.DAT on the tape ...
Doing a directory of my DECNET-11M-PLUS tape, I see these files -
>FLX TT:=MS0:/DI
Directory MS0:[137,10]
23-Aug-80
PREGEN.CMD 94. 13-Jun-89 <233>
DECMOV.DAT 15. 13-Jun-89 <233>
DECCFG.CMD 5. 13-Jun-89 <233>
DECPRM.CMD 7. 13-Jun-89 <233>
DECGEN.CLB 699. 13-Jun-89 <233>
DECGEN.KIT 1. 13-Jun-89 <233>
Total of 821. blocks in 6. files
Odd - there's a file DECMOV but not NETMOV. After much head scratching and
reading of the cryptic PREGEN.CMD indirect command processor file, I've come
to the conclusion that there are really three tapes in the RSX "DECnet"
distribution - a "generic" network tape (that's the one with NETMOV.DAT
(which unfortunately I don't have), a DECnet specific tape (which seems to
be the one tape I do have) and a PSI network tape (which I think is
optional).
Can any RSX wizard confirm this?
Thanks,
Bob
On 23 Aug 2008, at 14:42, Bob Armstrong wrote:
So this means that if you had DECnet machines on your local network at
home and you wanted to bridge them into HECnet, you could do it with Linux
DECnet and a VMS host is not needed? Excellent!
That's exactly what it means. It might even be possible to connect two Linux multinet boxes to each other but I haven't tried it!
One thing that doesn't seem to work is routing on big-endian Linux boxes (eg my sparc!). But it's fine on a 'normal' system
Chrissie
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Christine Caulfield
Sent: Saturday, August 23, 2008 6:30 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] Multinet on Linux
I've got multinet working on Linux, for those that are interested.
Sourceforge appears to be sulking at the moment so I've uploaded the
latest dnprogs sources to
http://chrissie.fedorapeople.org/dnprogs-2.44.tar.gz
and to Debian.
Instructions for setting it up are here:
http://linux-decnet.wiki.sourceforge.net/multinet
Have fun, and let me know how you get on.
Chrissie
So this means that if you had DECnet machines on your local network at
home and you wanted to bridge them into HECnet, you could do it with Linux
DECnet and a VMS host is not needed? Excellent!
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Christine Caulfield
Sent: Saturday, August 23, 2008 6:30 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] Multinet on Linux
I've got multinet working on Linux, for those that are interested.
Sourceforge appears to be sulking at the moment so I've uploaded the
latest dnprogs sources to
http://chrissie.fedorapeople.org/dnprogs-2.44.tar.gz
and to Debian.
Instructions for setting it up are here:
http://linux-decnet.wiki.sourceforge.net/multinet
Have fun, and let me know how you get on.
Chrissie
Paul Koning wrote:
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Paul Koning wrote:
>> There is an "assign" syscall (which normally in RSTS means
>> "reserve this device for me even when it's not open") which binds
>> a ddcmp driver pseudo-device unit to a tty device unit number, via
>> a syscall parameter. So you could have, say, up to 8 ddcmp ports,
>> and those could be bound at runtime to any of your terminal ports.
Johnny> Way nice. In RSX, you need to reserve the whole controller at
Johnny> netgen, and no ports can be used by anything else than DECnet
Johnny> if you set it up. DECnet/RSX has its own device driver for
Johnny> the serial port cards.
For RSTS it's a connection from the regular terminal driver to the
DDCMP driver, which acts as a sort of coprocessor.
Linux has the same notion; it's called "line discipline" if I remember
right, and is nicely modular. That's where DDCMP would go if one were
to do it for Linux.
They could have done it like that in RSX as well, but I guess they didn't want the performance penalty.
Atleast in RSX, the terminal driver is rather complex. And while a lot of that complexity can be bypassed, it's still a lot of overhead. Also, it's kindof tricky to call a device driver from kernel mode. Easiest is to pass a request to a task, which then do the I/O, but that implies a lot of extra overhead as well.
So DECnet in RSX have it's own device drivers for all interfaces that it uses, and so every interface have to be dedicated to just DECnet if DECnet would use it.
Johnny
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Paul Koning wrote:
There is an "assign" syscall (which normally in RSTS means
"reserve this device for me even when it's not open") which binds
a ddcmp driver pseudo-device unit to a tty device unit number, via
a syscall parameter. So you could have, say, up to 8 ddcmp ports,
and those could be bound at runtime to any of your terminal ports.
Johnny> Way nice. In RSX, you need to reserve the whole controller at
Johnny> netgen, and no ports can be used by anything else than DECnet
Johnny> if you set it up. DECnet/RSX has its own device driver for
Johnny> the serial port cards.
For RSTS it's a connection from the regular terminal driver to the
DDCMP driver, which acts as a sort of coprocessor.
Linux has the same notion; it's called "line discipline" if I remember
right, and is nicely modular. That's where DDCMP would go if one were
to do it for Linux.
paul
Paul Koning wrote:
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> I wonder why you can't set it from NCP though? Weird if they
Johnny> have the functionality, but no "normal" way of enabling it.
>> Probably history. I created the async DDCMP driver when I was
>> doing the (unreleased) PRO port for RSTS (9.6 originally). I
>> handed it to RSTS development, and they integrated it into the
>> release. But I personally never did the NCP work. Probably
>> because it wasn't familiar code and it would have been a lot of
>> work. Instead, I just wrote a little 10 line utility to issue the
>> line on/off syscalls to the kernel.
Johnny> Way fun, and impressive. Thanks for that piece of information
Johnny> and history. I guess they didn't see much need of DDCMP
Johnny> support in RSTS/E at that point. How did you select which
Johnny> serial port it would use, by the way? Or was this only done
Johnny> for the PRO? Hmm, I guess it could have been passed in in
Johnny> the syscall...
There is an "assign" syscall (which normally in RSTS means "reserve
this device for me even when it's not open") which binds a ddcmp
driver pseudo-device unit to a tty device unit number, via a syscall
parameter. So you could have, say, up to 8 ddcmp ports, and those
could be bound at runtime to any of your terminal ports.
Way nice. In RSX, you need to reserve the whole controller at netgen, and no ports can be used by anything else than DECnet if you set it up. DECnet/RSX has its own device driver for the serial port cards.
Johnny
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> I wonder why you can't set it from NCP though? Weird if they
Johnny> have the functionality, but no "normal" way of enabling it.
Probably history. I created the async DDCMP driver when I was
doing the (unreleased) PRO port for RSTS (9.6 originally). I
handed it to RSTS development, and they integrated it into the
release. But I personally never did the NCP work. Probably
because it wasn't familiar code and it would have been a lot of
work. Instead, I just wrote a little 10 line utility to issue the
line on/off syscalls to the kernel.
Johnny> Way fun, and impressive. Thanks for that piece of information
Johnny> and history. I guess they didn't see much need of DDCMP
Johnny> support in RSTS/E at that point. How did you select which
Johnny> serial port it would use, by the way? Or was this only done
Johnny> for the PRO? Hmm, I guess it could have been passed in in
Johnny> the syscall...
There is an "assign" syscall (which normally in RSTS means "reserve
this device for me even when it's not open") which binds a ddcmp
driver pseudo-device unit to a tty device unit number, via a syscall
parameter. So you could have, say, up to 8 ddcmp ports, and those
could be bound at runtime to any of your terminal ports.
paul
Paul Koning wrote:
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Paul Koning wrote:
>> RSTS does too (for sufficiently recent versions, like V10 or so)
>> -- though the NCP bits don't seem to be there. But there's a
>> driver and it can be told to turn on if you issue the DECnet
>> control syscalls directly.
Johnny> Aha. I think I looked at RSTS/E DECnet SPD only, and didn't
Johnny> find any mention of it, back when I was playing with that.
That would make sense given that the support isn't complete.
Aha. Yes, that would explain it. :-)
Johnny> I wonder why you can't set it from NCP though? Weird if they
Johnny> have the functionality, but no "normal" way of enabling it.
Probably history. I created the async DDCMP driver when I was doing
the (unreleased) PRO port for RSTS (9.6 originally). I handed it to
RSTS development, and they integrated it into the release. But I
personally never did the NCP work. Probably because it wasn't
familiar code and it would have been a lot of work. Instead, I just
wrote a little 10 line utility to issue the line on/off syscalls to
the kernel.
Way fun, and impressive. Thanks for that piece of information and history.
I guess they didn't see much need of DDCMP support in RSTS/E at that point. How did you select which serial port it would use, by the way? Or was this only done for the PRO?
Hmm, I guess it could have been passed in in the syscall...
>> On a Pro it even works in synchronous mode (because there the
>> "UART" is actually a USART).
Johnny> I don't think you can set it to synch mode in DECnet, though,
Johnny> so that is more of a theoretical thing. But yes, RSX
Johnny> supports both synch and asynch mode.
What I meant is that I did synch mode, including for DECnet, in RSTS.
Ok. I misunderstood you. While you can use the serial port for DDCMP DECnet under P/OS, I don't think you can set it to synch mode there.
Even though the hardware supports it.
But for code that you wrote, obviously you could take advantage of all the possibilities. :-)
Johnny
Johnny Billquist wrote:
But as far as security issues goes, there are probably a bunch of them on our different systems.
After all. Apart from VMS, we all now seem to have opersting systems that have been abandoned, as far as support goes. And incomplete sources... :-(
Well, I think that TOPS-20 sources are available and complete, but as far as I know, no PDP-11 OS with DECnet have all sources available.
(Boy, what wouldn't I do to get the RSX sources complete, including layered products... :-) )
Johnny
Sampsa Laine wrote:
i was gonna bring it up here but considering the reception I got on c.o.v. I couldn't be bothered...
I would hope the people around here are a bit more humble.
But as far as security issues goes, there are probably a bunch of them on our different systems.
I know of a couple under RSX atleast...
Johnny
Sampsa
On 22 Aug 2008, at 16:54, gerry77 at mail.com wrote:
I suppose you all have read about the VMS security bug that is being discussed
since about a week on comp.os.vms. Anyway, having read nothing about it here,
I thought useful to warn all the system administrators who read this mailing
list and which have VMS nodes with guest access on HECnet and/or Internet
about potential security treats to which their systems are exposed.
All VMS versions (VAX since V5.x, AXP and I64 since their beginning) are
exposed to a local exploit that allows any unprivileged user to gain almost
any privilege! The problem lies in SYS$SHARE:SMGSHR.EXE which is used for CLI
processing in many system utilites installed with high privileges (i.e.
INSTALL.EXE, SYSMAN.EXE, SHWCLSTR.EXE, etc.).
HP has just released mandatory patches for some versions while others, notably
all the VAX and older Alpha ones, are still exposed. Look for kits named like
VMSxxx_SMGRTL-V0100 in ftp://ftp.itrc.hp.com/openvms_patches
A partial solution for those systems for which there isn't a patch appears to
be an ACL to deny access to some utilities by non trusted users. The list that
follows contains the names of those images that I think most dangerous, but I
will be "happy" to add more names if you discover them:
AUTHORIZE.EXE
INSTALL.EXE
NCP.EXE
SHWCLSTR.EXE
SYSMAN.EXE
TCPIP$FTP_CLIENT.EXE (VAX)
TCPIP$TELNET.EXE (AXP)
TCPIP$UCP.EXE
Please note that I'm NOT sure about this, i.e. there may be a workaround for
this workaround which I haven't thought of.
G.
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Paul Koning wrote:
RSTS does too (for sufficiently recent versions, like V10 or so)
-- though the NCP bits don't seem to be there. But there's a
driver and it can be told to turn on if you issue the DECnet
control syscalls directly.
Johnny> Aha. I think I looked at RSTS/E DECnet SPD only, and didn't
Johnny> find any mention of it, back when I was playing with that.
That would make sense given that the support isn't complete.
Johnny> I wonder why you can't set it from NCP though? Weird if they
Johnny> have the functionality, but no "normal" way of enabling it.
Probably history. I created the async DDCMP driver when I was doing
the (unreleased) PRO port for RSTS (9.6 originally). I handed it to
RSTS development, and they integrated it into the release. But I
personally never did the NCP work. Probably because it wasn't
familiar code and it would have been a lot of work. Instead, I just
wrote a little 10 line utility to issue the line on/off syscalls to
the kernel.
On a Pro it even works in synchronous mode (because there the
"UART" is actually a USART).
Johnny> I don't think you can set it to synch mode in DECnet, though,
Johnny> so that is more of a theoretical thing. But yes, RSX
Johnny> supports both synch and asynch mode.
What I meant is that I did synch mode, including for DECnet, in RSTS.
It successfully talked to a DMR (both in 4.0 mode and DMC mode -- I
remember digging up the details of the "DMC bugs" that DMC mode on the
later devices is meant to handle).
It was an interesting experience. The DDCMP spec is so well written
that you can simply implement what it says and it all works. That's
how it should be, but specs that good are unfortunately quite rare
(and essentially nonexistent in more recent times).
BTW, a DDCMP driver for Linux would be a pretty easy thing to do. I
started looking into it but didn't have the spare time to do the
actual coding.
paul
i was gonna bring it up here but considering the reception I got on c.o.v. I couldn't be bothered...
Sampsa
On 22 Aug 2008, at 16:54, gerry77 at mail.com wrote:
I suppose you all have read about the VMS security bug that is being discussed
since about a week on comp.os.vms. Anyway, having read nothing about it here,
I thought useful to warn all the system administrators who read this mailing
list and which have VMS nodes with guest access on HECnet and/or Internet
about potential security treats to which their systems are exposed.
All VMS versions (VAX since V5.x, AXP and I64 since their beginning) are
exposed to a local exploit that allows any unprivileged user to gain almost
any privilege! The problem lies in SYS$SHARE:SMGSHR.EXE which is used for CLI
processing in many system utilites installed with high privileges (i.e.
INSTALL.EXE, SYSMAN.EXE, SHWCLSTR.EXE, etc.).
HP has just released mandatory patches for some versions while others, notably
all the VAX and older Alpha ones, are still exposed. Look for kits named like
VMSxxx_SMGRTL-V0100 in ftp://ftp.itrc.hp.com/openvms_patches
A partial solution for those systems for which there isn't a patch appears to
be an ACL to deny access to some utilities by non trusted users. The list that
follows contains the names of those images that I think most dangerous, but I
will be "happy" to add more names if you discover them:
AUTHORIZE.EXE
INSTALL.EXE
NCP.EXE
SHWCLSTR.EXE
SYSMAN.EXE
TCPIP$FTP_CLIENT.EXE (VAX)
TCPIP$TELNET.EXE (AXP)
TCPIP$UCP.EXE
Please note that I'm NOT sure about this, i.e. there may be a workaround for
this workaround which I haven't thought of.
G.
Paul Koning wrote:
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Hmm. As far as I know, HECnet have never made use of any
Johnny> homemade hardware. However, the first links I used, were over
Johnny> serial ports talking DDCMP, that I tunneled. I could still do
Johnny> that, if needed. It's even simpler than bridging
Johnny> ethernet. The only "problem" is that asynch serial DECnet
Johnny> don't go any faster than 9600 bps. Atleast under RSX.
Johnny> Another problem is that as far as I can tell, only RSX and
Johnny> VMS supports that.
RSTS does too (for sufficiently recent versions, like V10 or so) --
though the NCP bits don't seem to be there. But there's a driver and
it can be told to turn on if you issue the DECnet control syscalls
directly.
Aha. I think I looked at RSTS/E DECnet SPD only, and didn't find any mention of it, back when I was playing with that.
Or perhaps I got the information from somewhere else. Can't remember for certain right now.
I wonder why you can't set it from NCP though? Weird if they have the functionality, but no "normal" way of enabling it.
On a Pro it even works in synchronous mode (because there the "UART"
is actually a USART).
I don't think you can set it to synch mode in DECnet, though, so that is more of a theoretical thing.
But yes, RSX supports both synch and asynch mode.
Johnny
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
Johnny> Hmm. As far as I know, HECnet have never made use of any
Johnny> homemade hardware. However, the first links I used, were over
Johnny> serial ports talking DDCMP, that I tunneled. I could still do
Johnny> that, if needed. It's even simpler than bridging
Johnny> ethernet. The only "problem" is that asynch serial DECnet
Johnny> don't go any faster than 9600 bps. Atleast under RSX.
Johnny> Another problem is that as far as I can tell, only RSX and
Johnny> VMS supports that.
RSTS does too (for sufficiently recent versions, like V10 or so) --
though the NCP bits don't seem to be there. But there's a driver and
it can be told to turn on if you issue the DECnet control syscalls
directly.
On a Pro it even works in synchronous mode (because there the "UART"
is actually a USART).
paul
gerry77 at mail.com wrote:
On Fri, 22 Aug 2008 15:04:57 +0200, you wrote:
Definitely. So, why did you pick area numbers that were already used in HEcnet? :-)
We started as a group of people with some DEC hardware, not ever thinking that
some day we would have a working DECnet. Many systems hadn't DECnet loaded and
others had addresses like 1.1, 1.2, and so on just to play with some local
link. Johnny bridge didn't existed and we didn't knew anything about Multinet.
I think a lot of places have used area 1 at one time or another... So an area change is sometimes needed. No way of avoiding that. :-)
When we first heard about HECnet it was running with some homemade hardware
and there was Magica online! :-) We were not able to do that and stopped.
Hmm. As far as I know, HECnet have never made use of any homemade hardware. However, the first links I used, were over serial ports talking DDCMP, that I tunneled. I could still do that, if needed. It's even simpler than bridging ethernet. The only "problem" is that asynch serial DECnet don't go any faster than 9600 bps. Atleast under RSX.
Another problem is that as far as I can tell, only RSX and VMS supports that.
Anyway, at that point it should have been obvious that you had a node number clash if you ever wanted to connect to HECnet. :-)
The addressing scheme was enforced but not changed and we ended with the
actual setup. Once we thought about changing our area number from 1 to 39
(because +39 is the international dialling prefix for Italy), but we didn't
need such a change so it's still only an almost forgotten idea. :-)
It would definitely be great if you were to do the number change, and then connect to the rest of us. That should be pretty easy, and shouldn't have to take that much time.
Johnny
On Fri, 22 Aug 2008 15:04:57 +0200, you wrote:
Definitely. So, why did you pick area numbers that were already used in
HEcnet? :-)
We started as a group of people with some DEC hardware, not ever thinking that
some day we would have a working DECnet. Many systems hadn't DECnet loaded and
others had addresses like 1.1, 1.2, and so on just to play with some local
link. Johnny bridge didn't existed and we didn't knew anything about Multinet.
When we first heard about HECnet it was running with some homemade hardware
and there was Magica online! :-) We were not able to do that and stopped.
Some years later we tested Multinet and TCPware tunnels, but our ADSL (and
ISDN) dynamic IP address links proved to be very troublesome. we hadn't enough
bandwith to create a central site for a star topology network and mesh
networks with Multinet were not feasible, so we stopped again. Anyway, with
Multinet we started to (very) loosely coordinate addresses among us.
Years later (autumn 2006) we started for the third time to think about a true
DECnet and we tried again either Multinet tunnels or DECnet Plus, and finally
discovered that HECnet had grown and there was Johnny's bridge available...
The addressing scheme was enforced but not changed and we ended with the
actual setup. Once we thought about changing our area number from 1 to 39
(because +39 is the international dialling prefix for Italy), but we didn't
need such a change so it's still only an almost forgotten idea. :-)
G.
I suppose you all have read about the VMS security bug that is being discussed
since about a week on comp.os.vms. Anyway, having read nothing about it here,
I thought useful to warn all the system administrators who read this mailing
list and which have VMS nodes with guest access on HECnet and/or Internet
about potential security treats to which their systems are exposed.
All VMS versions (VAX since V5.x, AXP and I64 since their beginning) are
exposed to a local exploit that allows any unprivileged user to gain almost
any privilege! The problem lies in SYS$SHARE:SMGSHR.EXE which is used for CLI
processing in many system utilites installed with high privileges (i.e.
INSTALL.EXE, SYSMAN.EXE, SHWCLSTR.EXE, etc.).
HP has just released mandatory patches for some versions while others, notably
all the VAX and older Alpha ones, are still exposed. Look for kits named like
VMSxxx_SMGRTL-V0100 in ftp://ftp.itrc.hp.com/openvms_patches
A partial solution for those systems for which there isn't a patch appears to
be an ACL to deny access to some utilities by non trusted users. The list that
follows contains the names of those images that I think most dangerous, but I
will be "happy" to add more names if you discover them:
AUTHORIZE.EXE
INSTALL.EXE
NCP.EXE
SHWCLSTR.EXE
SYSMAN.EXE
TCPIP$FTP_CLIENT.EXE (VAX)
TCPIP$TELNET.EXE (AXP)
TCPIP$UCP.EXE
Please note that I'm NOT sure about this, i.e. there may be a workaround for
this workaround which I haven't thought of.
G.
At 7:55 AM +0100 8/22/08, Christine Caulfield wrote:
Zane H. Healy wrote:
By they way, Angela, you don't need to be running dnroute if your node
is an end-node (which it seems to be). In a situation where the rest of
it doesn't seem to be working properly it's only confusing the issue I
suspect :)
Chrissie,
Am I reading this to mean that it is possible to use a Linux box as a DECnet
Area Router? If so how hard is it to setup on Ubuntu? I haven't played
with Linux DECnet in close to a decade.
It should be fairly easy, though I haven't done it for ages!
Cool! I'll keep this in mind should I have further problems with keeping a VAX online. I've never really used the VAXstation 4000/60 that I replaced my VLC with last night. So far it's still up though. Unfortunately it appears the onboard NIC is bad on my /90.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
gerry77 at mail.com wrote:
On Fri, 22 Aug 2008 08:11:37 +0200, you wrote:
Well, I would keep LAT and Infoserver traffic separate. :-)
Somewhere into the future somebody will do that too :-) One of us had just got a beautiful InfoServer 1000 in InfoTower configuration,
and we were longing to test it across the net, so we just addedd its ethertype
to the bridge and ran it. The change from [lat] to [lan] came later, when we
decided to release the update.
BTW, that bridge configuration section already controlled not only LAT but
also MOP Remote Console and Dump/Load, so we just added a protocol to the
circus and then felt that [lan] was a better choice to describe it.
Actually, the MOP Remote Console and Dump/Load is what a LAT server normally use to boot and be managed. :-) (Unless it's one of those models that don't boot remote.)
That's why there are in there bundled.
Not much fun with a LAT terminal server if it can't boot.
Johnny
On Fri, 22 Aug 2008 08:11:37 +0200, you wrote:
Well, I would keep LAT and Infoserver traffic separate. :-)
Somewhere into the future somebody will do that too :-)
One of us had just got a beautiful InfoServer 1000 in InfoTower configuration,
and we were longing to test it across the net, so we just addedd its ethertype
to the bridge and ran it. The change from [lat] to [lan] came later, when we
decided to release the update.
BTW, that bridge configuration section already controlled not only LAT but
also MOP Remote Console and Dump/Load, so we just added a protocol to the
circus and then felt that [lan] was a better choice to describe it.
The perfect solution would have been (*) to have at least three different
sections like [lat], [mop] and [infoserver], but we were to lazy to do that
much work and delaying our InfoServer tests :P
G.
Sampsa Laine wrote:
On 22 Aug 2008, at 13:06, gerry77 at mail.com wrote:
BTW, our network is a lot smaller than HECnet and we ran without any router
for almost two years. In other words, one size does not fit all and YMMV. :-)
G.
Out of curiosity I looked at your node list on your webpage and you seem to have quite a few active hosts. It's a pity you used the same area number as us, it might be fun to link the two networks together at some point.
Definitely. So, why did you pick area numbers that were already used in HEcnet? :-)
Johnny
