No, you have not misunderstood. You are just not getting the full picture.
Yes, the Cisco box will transport the DECnet frames inside something. At
the
bottom there will be IP, but most likely the DECnet frames are actually
sitting
inside UDP...
So what is the difference from the bridge program, you ask.
Well, simple, the bridge program tries to be clever about which frames to
send where, but it cannot be clever enough at times, and also there are
times when it is forced to send traffic that we might want to limit.
The reason is that the bridge is not really a part of the DECnet traffic,
but is
just relaying packets back and forth, making the two ends of the bridge
appear as if they were on the same ethernet segment.
The Cisco box, on the other hand, is a DECnet routing node. It sits on the
ethernet, and participate fully in the DECnet traffic.
Thanks. Now I get it. I didn't know that anyone other than DEC ever made
something that could route actual DECnet and therefore did not realise that
"actual DECnet router" meant "actual DECnet router" :-) Until now I thought
this was something only available in a VMS router node.
It would be a fun exercise to turn the bridge into an actual DECnet router.
One day, when I have a lot of time I might even think about trying that.
Regards
Rob
As a good friend has commented to me, unless you plan on throwing a lot of money at Larry's yacht, you can forget any supposed "care" that Oracle may have. What you see is what you get... fortunately with Solaris, there may be a few souls left from the old organization that will go beyond google and a best endeavor.
Apologies... been fed up with Oracle now for quite some time...
On Mon, Jun 4, 2012 at 6:27 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-06-04 18:13, Brian Hechinger wrote:
SIMH 3.9 somehow kernel paniced my solaris server!
Wow.
-brian
ps: it's older solaris, but stil!
Wow. Now I am impressed. You have managed to trigger a bug in Solaris... :-)
Send an SPR to Oracle... If they care...
Johnny
On 2012-06-06 11:26, Peter Coghlan wrote:
No, you have not misunderstood. You are just not getting the full
picture. Yes, the Cisco box will transport the DECnet frames inside
something. At the bottom there will be IP, but most likely the DECnet
frames are actually sitting inside UDP...
My understanding of it is that GRE is another IP protocol on the same level
as TCP and UDP rather than using UDP.
You could definitely be right on GRE. It was way too long since I actually tried working with GRE to really remember much anymore...
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
No, you have not misunderstood. You are just not getting the full
picture. Yes, the Cisco box will transport the DECnet frames inside
something. At the bottom there will be IP, but most likely the DECnet
frames are actually sitting inside UDP...
My understanding of it is that GRE is another IP protocol on the same level
as TCP and UDP rather than using UDP.
Regards,
Peter Coghlan.
The Cisco box can have several point-to-point connections. Each is
considered its own interface (well, circuit I'd guess, but possibly also
line) in DECnet on the Cisco box.
In DECnet on PTP links in the DECnet architecture, like DDCMP links,
the DECnet routing protocol is spoken using incrmental updates, this
is what I beleive hapens with Multinet on VMS.
When a DECnet node speaks routing on a ETHERNET segment, it basically
dumps a "routing vector" every 3 seconds, depending on if you are area
router or just routing-4 you send all areas or just you own.
A routing vector has the area id, and then indexed with node-numbers
are 16-bit cost+hops, where 0 represent not reachable....... So
2 bytes*1024 nodes.
The cisco implemenation uses the LAN format with some optimizing
kludge.
-P
Forgive my ignorance, but when you say "actual DECnet routing", it must be
transporting it over something, what is that something? I assume it
is IP, in which case it would still need to encapsulate the DECnet
in IP wouldn't it? Have I misunderstood something here?
A bridge connects two ethernet segments together at the Ethernet
layer, they might have a learning mechanism so they knew what MAC
address is on what port, so if you have a multipoint network, all
packets are not sent everywhere.
Johnnys bridge takes a Etherent frame, puts it in a IP packet, sends
it to the other side, removes the outer iP header and sends the
Ethernet fram out on the physical ethernet on the other side.
A DECnet router is a L3 device, it will look at the packets and figure
out where it needs to go based on the DECnet address, not the MAC
address. It also speaks a routing protocol to figure out what is on
the other side, the same way IP has routing protocols. The closest IP
routing we have to DECnet is ISIS. OSPF is based on the same
principle, but (long rant..) it's backwards in many ways.
A L3 router can have many interfaces, and the interface type can be
anything, point-to-point, HDLC, DDCMP, POS (did anyone figure POS is
kludge DDCMP clone?) and the L2 header is stripped off.
Now, in DECnet on a LAN segment there is a kludge, there is no ND or
ARP, instead the DECnet node address is "hard coded" in to the MAC
address.. aa00.0400.xxxx
To get xxxx multiplie the area number by 1,024 and add the node
number to the product. The resulting 16-bit decimal address is
converted to a hexadecimal number and appended to the address
AA00.0400 in byte-swapped order, with the least significant byte
first. For example, DECnet address 12.75 becomes 12363 (base 10),
which equals 304B (base 16).
Now, so think of a L3 router with a physical Ethernet on one side and
a logical (GRE or other tunnel interface) on the other side. The
traffic across the IP network in this case will be the GRE encapsulate
Ethernet frame with address as above and ethertype 0x6003.
This is DECnet Phase 4, on DEcnet Phase 5 it's all OSI-IP/CLNP and I
have forgotten all of it as OSI died..
And dept of useless knowledge, Tops10 ANF10 uses 0x6016
--Peter
I assume you are using GRE on the Cisco box. I am not an expert in this
stuff so pardon the na=EFve question but, what is it about Cisco
that makes it better than the bridge? After all aren't they really
doing the same thing?
The bridge connects two ethernets together at L2.
The cisco router can also be configured as DECnet (area) router and
connects at L3. This is the same thing as Multinet on a VMS box does,
it just encapsulates in a different way.
The cisco box can also do "decnet NAT"...
Is it just that you don=92t need a server running the bridge (could use
a Raspberry Pi for that now) or is it the use of GRE? From a skim of RFC 2784
and 2890 GRE doesn't look too complicated, perhaps the bridge could be
changed to implement GRE if that helps in some way.
There is a Linux GRE driver. If you can make the emulator to present a
"ethernet interface" to the VMS host, and you stick that etherent
packet in a GRE packet, it should talk to the Cisco box, or you can
talk between two emulators.
An other option is to do the Multinet UDP encapsulation, the format
was posted to the HECnet mailinglist a while ago.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what
should I be looking for if I wanted to pick up something cheap on
EBay?
Any cisco that runs "enterprise IOS" after ver 9.21,
Could this work in a domestic environment with an ISP that
gives out dynamic IP addresses?
My head hurts.. Ask for a /56 of IPv6 space. -:)
If there are many users that need this, I will look in to it, I thnk
there was magic that could be applied.
-P
On 2012-06-05 03:50, Peter Lothberg wrote:
For people who don't need LAT and have a Cisco box, this is way better
than the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
You can bridge LAT with the cisco box... -:) ((It might even HELP you
with LAT over WAN....)) (And it can act as a LAT termianl server)
Nice. I did not know that. That's even better. Will it just bridge the
protocols you ask for, or will it do them all? Hmm, I assume it's using
GRE for this?
Johnny
I -think- there where special stuff to help with LAT in WAN scenarios,
at some point there might even have been a telnet/lat gw.. I have to
go and refresh my memory..
There are many ways of putting foo-in-ip, to many, but the cisco box
have two that are actually pretty RFC compliant. GRE and L2tpV3.
GRE uses the Ethernet protocol ID to demux what's in the packet, and
it can be treated as a "interface" and made part of a bridge group.
L2TPV3 basically takes a physical port and X-connects that to another
physical port on another box across a IP network. If you have a real
core that do 4470MTU or 9000MTU, 1500 byte payload is a no_brainer..
As it's IPv6 day, let me mention that in the IPv6 version of L2tpv3
we did a mode where you give IPv6 addresses to logical/physical ports
and encap/decap just becomes a push/pop "label" operation, instead as
in IPv4, there the outer IPv4 header are interfaces/loopbacks on the
endpoint and you have to look inside the packet for a session ID to
knew where it actually belongs... Okey, enough...
--P
The following areas need to change their addresses for their link to SG1
to work:
3, 52, 59 and the two area 6 nodes.
%%%%%%%%%%% OPCOM 6-JUN-2012 08:29:34.01 %%%%%%%%%%%
Message from user DECNET on STUPI
DECnet event 4.10, circuit up
By asking questions, you learn things... No reason to ask for forgiveness for wanting to learn.
On 2012-06-05 21:05, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Brian Hechinger
Sent: 05 June 2012 18:36
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
On 6/5/2012 12:53 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Johnny Billquist
Sent: 04 June 2012 23:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
FYI - Update now have a Cisco box, which will be setup within a few
days
to
be able to route DECnet over IP, so that will become another options
to
hook
into HECnet at the Update site.
For people who don't need LAT and have a Cisco box, this is way
better
than
the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
Johnny
I assume you are using GRE on the Cisco box. I am not an expert in
this stuff so pardon the na ve question but, what is it about Cisco
that makes it better than the bridge? After all aren't they really doing
the
same thing?
Is it just that you don t need a server running the bridge (could use
a Raspberry Pi for that now) or is it the use of GRE? From a skim of
RFC 2784 and 2890 GRE doesn't look too complicated, perhaps the bridge
could be changed to implement GRE if that helps in some way.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what
should I be looking for if I wanted to pick up something cheap on
EBay? Could this work in a domestic environment with an ISP that gives
out dynamic IP addresses?
The cisco isn't bridging traffic across the GRE link it's doing actual
DECnet
routing.
It's closer in function to a Multinet tunnel.
-brian
Forgive my ignorance, but when you say "actual DECnet routing", it must be
transporting it over something, what is that something? I assume it is IP,
in which case it would still need to encapsulate the DECnet in IP wouldn't
it? Have I misunderstood something here?
No, you have not misunderstood. You are just not getting the full picture. Yes, the Cisco box will transport the DECnet frames inside something. At the bottom there will be IP, but most likely the DECnet frames are actually sitting inside UDP...
So what is the difference from the bridge program, you ask.
Well, simple, the bridge program tries to be clever about which frames to send where, but it cannot be clever enough at times, and also there are times when it is forced to send traffic that we might want to limit. The reason is that the bridge is not really a part of the DECnet traffic, but is just relaying packets back and forth, making the two ends of the bridge appear as if they were on the same ethernet segment.
The Cisco box, on the other hand, is a DECnet routing node. It sits on the ethernet, and participate fully in the DECnet traffic. As such, it does *not* pass on any ethernet DECnet traffic it sees to the other end.
Instead it has two interfaces. One is the local ethernet interface. Works just like on any other machine on the local ethernet. The other interface is a point-to-point interface to the remote Cisco box. The local Cisco box then have the DECnet routing tables, whereby it knows where to send packets on, if it receives a DECnet packet not destined for itself. So it is a DECnet router.
That means any local ethernet broadcast traffic is *never* send to the remote Cisco box. The bridge always have to pass on *all* broadcast packets to all remote ends connected.
The Cisco box can have several point-to-point connections. Each is considered its own interface (well, circuit I'd guess, but possibly also line) in DECnet on the Cisco box.
So instead of the exponential growth of ethernet packets sent all around when you have an ethernet bridge, you get a linear growth of packets with the Cisco box.
And even better is the fact that DECnet have limits on how many endnodes and routers there can be on a single ethernet segment. And every machine on any bridge point will count here. As will the number of machines doing broadcasts...
There are simply some scaling problems with the bridge.
And even more funny (this have been touched on in the past), the bridge does not deal at all with loops in the topology. DECnet itself does, so with the Cisco boxes, you can form redundant paths between places without problems.
Johnny
On 5 Jun 2012, at 17:27, Johnny Billquist wrote:
On 2012-06-05 17:47, Mark Benson wrote:
NODE LIST AS FOLLOWS:
6.1 STAR69 (Area IV)
*6.2 QUIGON
*6.14
*6.15 PIVAX1
*Denotes part-time node (i.e. it's not on all the time)
PIVAX will be up a good lot of the time, although I take it down occasionally to test RasPi stuff.
So, who is 6.14? Care to present us?
Sorry, I lost track of what I was doing and sent it before I had booted the emulator :\
*6.14 RPPDP1
Stupid name.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 5 Jun 2012, at 19:54, Dave McGuire wrote:
UNIX "sucks" because you don't know how to use it, and its design
differs from the OS that you DO know how to use? Interesting logic. ;)
*poke poke*
Nooow Dave, that kind of humour has gotten you into all sorts of trouble before on ClassicCMP ;) ;)
Besides, anyone who thinks I know how to use VMS is a moron, Im a total VMS noob. I know properly 10x about Linux what I do about VMS. That said there are plenty areas I've never had to deal with and mounting without root privileges is seemingly one of them. Thing is it 'just works' in RSX and VMS it 'just don't work' in Linux, at least at a prompt using the conventional tools.
The specifics of how to accomplish this does, however, differ from
UNIX to UNIX. Under any modern-ish Linux system for example, this is
done automatically upon device insertion by a combination of udev, dbus,
and gvfs. It Just Works, I've done it five or six times since lunch
today. Of course you have to be logged into a "desktop" session in
order for it to work, but 99% of the time, that's what's going on.
Yes. Same as it works just fine in Mac OS X (except when Apple's crummy USB drivers cause another kernel panic). I appreciate that, but because my SimH emulations don't need a GUI... I don't need a GUI. To me if it doesn't work at the command prompt it doesn't work full stop. Stuff that happens in GUIs is written for GUIs, I don't consider GUIs that are often tailored to each distro part of the GNU Linux or UNIX, they are an extra. I'm old fashioned, so sue me.
If you want to do it a different way, say when nobody is logged in,
this is easily accomplished with a udev rule that matches the device
when it's inserted, and takes some action, in this case mounts the
filesystem. If you need to do that, let me know, and I may be able to help.
What I need to do is type 'mount <device> ~/usb' and have it work, without using sudo or su.
To my mind this is the equivalent of ALL DUA0: // MOU DUA0: MARKDISK1 MARK: in VMS... except you don't have top putz about in VMS, it just works.
That was my point, which in itself was kinda tongue-in-cheek anyway :)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Brian Hechinger
Sent: 05 June 2012 18:36
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
On 6/5/2012 12:53 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Johnny Billquist
Sent: 04 June 2012 23:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
FYI - Update now have a Cisco box, which will be setup within a few
days
to
be able to route DECnet over IP, so that will become another options
to
hook
into HECnet at the Update site.
For people who don't need LAT and have a Cisco box, this is way
better
than
the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
Johnny
I assume you are using GRE on the Cisco box. I am not an expert in
this stuff so pardon the na ve question but, what is it about Cisco
that makes it better than the bridge? After all aren't they really doing
the
same thing?
Is it just that you don t need a server running the bridge (could use
a Raspberry Pi for that now) or is it the use of GRE? From a skim of
RFC 2784 and 2890 GRE doesn't look too complicated, perhaps the bridge
could be changed to implement GRE if that helps in some way.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what
should I be looking for if I wanted to pick up something cheap on
EBay? Could this work in a domestic environment with an ISP that gives
out dynamic IP addresses?
The cisco isn't bridging traffic across the GRE link it's doing actual
DECnet
routing.
It's closer in function to a Multinet tunnel.
-brian
Forgive my ignorance, but when you say "actual DECnet routing", it must be
transporting it over something, what is that something? I assume it is IP,
in which case it would still need to encapsulate the DECnet in IP wouldn't
it? Have I misunderstood something here?
Regards
Rob
On 06/05/2012 12:53 PM, Rob Jarratt wrote:
I assume you are using GRE on the Cisco box. I am not an expert in this
stuff so pardon the na ve question but, what is it about Cisco that makes it
better than the bridge? After all aren't they really doing the same thing?
They are practically indestructible, and many times there's already
one sitting there doing something else.
Is it just that you don t need a server running the bridge (could use a
Raspberry Pi for that now) or is it the use of GRE? From a skim of RFC 2784
and 2890 GRE doesn't look too complicated, perhaps the bridge could be
changed to implement GRE if that helps in some way.
Pretty much all OSs implement GRE natively nowadays; you can terminate
a GRE tunnel on most any modern OS regardless of what system is at the
other end.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what should I
be looking for if I wanted to pick up something cheap on EBay?
Most any Cisco router will do the trick, but the oldest you'd probably
want to use for something like this would be a 2500 series. They can be
had all day long for $10-20/ea, they pull very little power, and their
software is...erm, "available" if you know what I mean.
There's a lot of Cisco expertise on this list; you'll have all the
help you need here should you decide to go that route.
Could this
work in a domestic environment with an ISP that gives out dynamic IP
addresses?
Of course.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 06/05/2012 11:32 AM, Paul_Koning at Dell.com wrote:
...
I am looking at trying to mount an external hard drive or SSD to handle the disk images instead of the SD card. For some ^$%^$% reason you can't mount a disk as a user in Linux (I might be missing something, admittedly) like you can in RSX and VMS (again, more demonstration that UNIX sucks ;)) so I have to futz about as root to do that.
You can set that to be allowed with the "user" option, see "man fstab". It defaults to not allowed, which is the correct security answer. (I would assume the same is true in DEC operating systems that have protection mechanisms... it certainly is in RSTS.)
That means you have to enable it for each volume? That's a pain when you are dealing with dynamic volume devices and USB. In VMS this kind of stuff is decided on the USER account, not on the OS setup. I can see why people love VMS so much now...
I believe you can do it for USB across the board, but I'm not sure of the details.
You can. This is done through the udev subsystem. It involves
writing a "udev rule" which matches the device (or device class) in
question, and then taking some action (which can be set permissions,
create a symlink, run a shell script, etc etc) when that rule is matched.
It's very flexible. Perhaps sometimes TOO flexible, but it gets the
job done in a clean way.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 06/05/2012 11:03 AM, Mark Benson wrote:
I am looking at trying to mount an external hard drive or SSD to
handle the disk images instead of the SD card. For some ^$%^$%
reason you can't mount a disk as a user in Linux (I might be
missing something, admittedly) like you can in RSX and VMS
(again, more demonstration that UNIX sucks ;)) so I have to futz
about as root to do that.
You can set that to be allowed with the "user" option, see "man
fstab". It defaults to not allowed, which is the correct security
answer. (I would assume the same is true in DEC operating systems
that have protection mechanisms... it certainly is in RSTS.)
That means you have to enable it for each volume? That's a pain when
you are dealing with dynamic volume devices and USB. In VMS this kind
of stuff is decided on the USER account, not on the OS setup. I can
see why people love VMS so much now...
UNIX "sucks" because you don't know how to use it, and its design
differs from the OS that you DO know how to use? Interesting logic. ;)
*poke poke*
The specifics of how to accomplish this does, however, differ from
UNIX to UNIX. Under any modern-ish Linux system for example, this is
done automatically upon device insertion by a combination of udev, dbus,
and gvfs. It Just Works, I've done it five or six times since lunch
today. Of course you have to be logged into a "desktop" session in
order for it to work, but 99% of the time, that's what's going on.
If you want to do it a different way, say when nobody is logged in,
this is easily accomplished with a udev rule that matches the device
when it's inserted, and takes some action, in this case mounts the
filesystem. If you need to do that, let me know, and I may be able to help.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 6/5/2012 12:53 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 04 June 2012 23:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
FYI - Update now have a Cisco box, which will be setup within a few days
to
be able to route DECnet over IP, so that will become another options to
hook
into HECnet at the Update site.
For people who don't need LAT and have a Cisco box, this is way better
than
the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
Johnny
I assume you are using GRE on the Cisco box. I am not an expert in this
stuff so pardon the na ve question but, what is it about Cisco that makes it
better than the bridge? After all aren't they really doing the same thing?
Is it just that you don t need a server running the bridge (could use a
Raspberry Pi for that now) or is it the use of GRE? From a skim of RFC 2784
and 2890 GRE doesn't look too complicated, perhaps the bridge could be
changed to implement GRE if that helps in some way.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what should I
be looking for if I wanted to pick up something cheap on EBay? Could this
work in a domestic environment with an ISP that gives out dynamic IP
addresses?
The cisco isn't bridging traffic across the GRE link it's doing actual DECnet routing.
It's closer in function to a Multinet tunnel.
-brian
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 04 June 2012 23:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
FYI - Update now have a Cisco box, which will be setup within a few days
to
be able to route DECnet over IP, so that will become another options to
hook
into HECnet at the Update site.
For people who don't need LAT and have a Cisco box, this is way better
than
the bridge program.
(If you really want LAT with other parts of HECnet, then there is no
alternative to the bridge...)
Johnny
I assume you are using GRE on the Cisco box. I am not an expert in this
stuff so pardon the na ve question but, what is it about Cisco that makes it
better than the bridge? After all aren't they really doing the same thing?
Is it just that you don t need a server running the bridge (could use a
Raspberry Pi for that now) or is it the use of GRE? From a skim of RFC 2784
and 2890 GRE doesn't look too complicated, perhaps the bridge could be
changed to implement GRE if that helps in some way.
I don't know much about "professional" routers and Cisco stuff in
particular. If there are advantages to using a Cisco router, what should I
be looking for if I wanted to pick up something cheap on EBay? Could this
work in a domestic environment with an ISP that gives out dynamic IP
addresses?
Regards
Rob
On 05/06/2012 16:19, Mark Benson wrote:
Having lost my Multinet tunnel to Steve's SG1 node a while back I have been trying sporadically to fix it with no luck. I decided hang it today and went back to using the bridge program (which works fine) so I am happy to say Area 6 is back on HECnet.
There are a few caveats however...
If Chrissie still wants machines on HECnet she need to move the off Area 6. I can no longer offer remote area routing for other people without significant extra work and testing. As I also cannot guarantee my uptime at the moment as I am on a very scrappy ADSL service I think it is for the best if the nodes outside my LAN are relocated. I am sorry for this inconvenience.
Leave that with me, I'll decide what I want to do. All of my DECnet
systems are down at the moment because of licences so I'm not in any
rush to get them back just yet anyway :/
Chrissie
As indicated by my comment above, access to my network area will as ever be sporadic, depending on power-cuts, ADSL outages and also might be disturbed by some work on my main server, which houses STAR69 and my bridge.
On 2012-06-05 17:47, Mark Benson wrote:
NODE LIST AS FOLLOWS:
6.1 STAR69 (Area IV)
*6.2 QUIGON
*6.14
*6.15 PIVAX1
*Denotes part-time node (i.e. it's not on all the time)
PIVAX will be up a good lot of the time, although I take it down occasionally to test RasPi stuff.
So, who is 6.14? Care to present us?
(6.15 registered)
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
NODE LIST AS FOLLOWS:
6.1 STAR69 (Area IV)
*6.2 QUIGON
*6.14
*6.15 PIVAX1
*Denotes part-time node (i.e. it's not on all the time)
PIVAX will be up a good lot of the time, although I take it down occasionally to test RasPi stuff.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 2012-06-05 16:50, Paul_Koning at Dell.com wrote:
On Jun 5, 2012, at 5:29 AM, Mark Benson wrote:
...
I am looking at trying to mount an external hard drive or SSD to handle the disk images instead of the SD card. For some ^$%^$% reason you can't mount a disk as a user in Linux (I might be missing something, admittedly) like you can in RSX and VMS (again, more demonstration that UNIX sucks ;)) so I have to futz about as root to do that.
You can set that to be allowed with the "user" option, see "man fstab". It defaults to not allowed, which is the correct security answer. (I would assume the same is true in DEC operating systems that have protection mechanisms... it certainly is in RSTS.)
Anyone can mount a disk in RSX, assuming you "own" the disk, which basically boils down to knowing the disk label, and have the owner field of the disk structure allowing you.
Same for tapes...
It works nothing like in Unix.
Johnny
On Jun 5, 2012, at 11:03 AM, Mark Benson wrote:
On 5 Jun 2012, at 15:50, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote:
On Jun 5, 2012, at 5:29 AM, Mark Benson wrote:
...
I am looking at trying to mount an external hard drive or SSD to handle the disk images instead of the SD card. For some ^$%^$% reason you can't mount a disk as a user in Linux (I might be missing something, admittedly) like you can in RSX and VMS (again, more demonstration that UNIX sucks ;)) so I have to futz about as root to do that.
You can set that to be allowed with the "user" option, see "man fstab". It defaults to not allowed, which is the correct security answer. (I would assume the same is true in DEC operating systems that have protection mechanisms... it certainly is in RSTS.)
That means you have to enable it for each volume? That's a pain when you are dealing with dynamic volume devices and USB. In VMS this kind of stuff is decided on the USER account, not on the OS setup. I can see why people love VMS so much now...
I believe you can do it for USB across the board, but I'm not sure of the details.
paul
Having lost my Multinet tunnel to Steve's SG1 node a while back I have been trying sporadically to fix it with no luck. I decided hang it today and went back to using the bridge program (which works fine) so I am happy to say Area 6 is back on HECnet.
There are a few caveats however...
If Chrissie still wants machines on HECnet she need to move the off Area 6. I can no longer offer remote area routing for other people without significant extra work and testing. As I also cannot guarantee my uptime at the moment as I am on a very scrappy ADSL service I think it is for the best if the nodes outside my LAN are relocated. I am sorry for this inconvenience.
As indicated by my comment above, access to my network area will as ever be sporadic, depending on power-cuts, ADSL outages and also might be disturbed by some work on my main server, which houses STAR69 and my bridge.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 5 Jun 2012, at 15:50, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote:
On Jun 5, 2012, at 5:29 AM, Mark Benson wrote:
...
I am looking at trying to mount an external hard drive or SSD to handle the disk images instead of the SD card. For some ^$%^$% reason you can't mount a disk as a user in Linux (I might be missing something, admittedly) like you can in RSX and VMS (again, more demonstration that UNIX sucks ;)) so I have to futz about as root to do that.
You can set that to be allowed with the "user" option, see "man fstab". It defaults to not allowed, which is the correct security answer. (I would assume the same is true in DEC operating systems that have protection mechanisms... it certainly is in RSTS.)
That means you have to enable it for each volume? That's a pain when you are dealing with dynamic volume devices and USB. In VMS this kind of stuff is decided on the USER account, not on the OS setup. I can see why people love VMS so much now...
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
