Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :)
Sampsa
On 06/07/2012 06:24 AM, Mark Benson wrote:
So we agree security is a storm in an espresso cup.
Well put. :)
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
So we agree security is a storm in an espresso cup.
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 06/07/2012 06:15 AM, Mark Benson wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Like me being unduly upset about the additional system load incurred
by running the interface in promiscuous mode. ;)
Yes, 'practically' non-existant.
See above. =)
I think it is time for sleep!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:05, Dave McGuire <mcguire at neurotica.com> wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Yes, 'practically' non-existant.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD.
Hans
-----Original Message-----
From: Jordi Guillaumes i Pons <jg at jordi.guillaumes.name>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 07 Jun 2012 11:32:40
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: [HECnet] Introducing myself... and my little network
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce
myself and my little puppies :)
My first computer (apart from the 8-bit home stuff) was a VAX-8250
running VAX/VMS 4.7. It was back in 1987, and it was a departamental
machine which was going to replace a PDP11/60, which, regretabily, I
didn't pay a lot of attention to. I was involved professionally with DEC
machines until 1992. My "last" machine was a VAXServer 4000 mod. 200,
which eventually ended living at my home :). I did plenty of stuff at
that time, from system managing to application design (and programming).
I had the pleasure to work with the DEC development environment, which I
still miss these days: VAXSet, CDD, the consistent VAX Calling
standard... I've not seen something so well integrated since those days.
Just to complete the picture, when I left the DEC environment, and after
a short time working with DOS (fortunately it was a SHORT time) I ended
working in the mainframe world, beginning in the applications
programming area (PLI, IMS/DB-DC, DB2...) and ending in the systems
programming area (mostly in the IMS environment). Right now I'm a
"software architect", whatever that means.
As I said before, when my company got rid of that 4000/200 I toke care
of it, as well as a uVAX 3300... those two machines now live happyly at
my home, forming a DSSI cluster which I power up from time to time (too
much noisy and hot for a home environment). I've tried to keep them in
working state (had to replace a fan in the 3300 and some minor stuff),
and they indeed work.
I got some vaxStations from eBay, and some other classical stuff (2 old
sun stations). I had diverse luck with those machines. I've got a
perfectly functioning VS 4000 mod. 60, and a broken VS 4000 mod 90
(that's unfortunate). The '90 has its NIC physically broken. It boots
but I can't network it, so its utility is limited (I don't own the
graphics display, and I've just got a VT320 which I have to switch
between all my boxen...). There is also a broken VS 3100; that machine
has a cache problem and does boot VMS; however it boots NetBSD (weird!).
I don't use it a lot, to say something :)
After I learnt the existence of HECnet researching some PDP11 stuff, I
asked Johnny to join. He has been -of course- very helpful, as well as
other members of the net, to whom I want to say thanks for the support.
Right now, area 7 is formed by these nodes:
7.6 MBSERV Linux Machine, host of my simulated boxen
7.60 BITXOV SIMH 3900 running openVMS 7.3
7.70 BITXOT SIMH PDP11 running RSTS/E 10.1
7.71 BITXOR SIMH PDP11 running RSXM+ 4.6
7.64 BITXO1 4000/200 running openVMS 7.3
7.65 BITXO2 3300 running openVMS 7.3
7.68 BITXO5 4000/60 running openVMS 7.3
I've got also some emulated PDP10 which I've not networked (yet). I'm
having trouble plugging into DECNET a TOPS20/Panda machine... If someone
could point me to any docs I would appreciate it a lot. I'm trying too
to DECNETize a TOPS10 running on a KLH10 simulated machine; this one
kinda works... I get the adjacency up messages but I can't talk to the
machine (neither FROM the machine). The only docs I've found are for the
7.03 version of the monitor, but I've got 7.04. Again, any pointers to
docs will be appreciated.
I'm still working on the setup. I intend to have the virtual machines up
most of the time. The physical ones are down most of the time, with the
exception of the 4000/60 (right now, it is up). I plan to add a SIMH 780
running VMS 4.7 soon. By the way, if someone could point me to pre-5.0
software kits I'd be very happy. I've got some stuff in the usual sites,
but I'd like to find BASIC, FMS, TDMS and BLISS for pre-5.0 VMS (I've
got the full CD consolidated distribution, circa 1992, and the hobbyist
kit so I've got covered the "modern" stuff :)). Same thing for RSX
software: I'd like to get a working COBOL (C81) for RSX11MPlus, as well
as DECNET for RSX11M (NOT plus). I really love to tinker with these
classical OSes :)
Well,tha'ts all for now. I've been reading the last message interchanges
in the list, and I think you could get a real boost to solve your
networking/interface sharing issues if you used VDE for the SIMH
machines. It's really easy to set up and you can do things like hooking
to your home DECnet network when you are on the road, using NATed
networks in which you can't control the port redirctions. Right now I'm
doing just that, extending my laptop "ethernet" to home using a ssh
tunneled vde plug thru a tethered iphone (whoa!). I've got the recipes
to make it work more or less automatically on ubuntu machines. If
someone is interested just ask.
Have a nice day, and enjoy!
On 06/07/2012 06:02 AM, Mark Benson wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
Yup, we are in agreement..."practically nonexistent". ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 10:32, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 05:09 AM, Johnny Billquist wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
