- HECnet - lists @ Update

dnroute segfaults when starting Multinet...

by christine.caulfield＠googlemail.com

On 12 Nov 2010, at 04:43, Bob Armstrong wrote: Chrissie Caulfield wrote: The thing to do is to upgrade dnprogs. Thanks, Chrissie - good point. I downloaded the latest source tarball from http://packages.debian.org/source/sid/all/dnprogs and recompiled everything under lenny. [I must say that the recompile was pretty painless as these things go.] Now I have ziti:/home/bob# dnroute -V dnroute from dnprogs version 2.55 A few things appear different, but sadly dnroute still segfaults after starting Multinet ziti:/home/bob# dmesg | grep -i dnroute [ 94.112034] dnroute[2996]: segfault at 0 ip 0804ac18 sp bfc40f70 error 4 in dnroute[8048000+6000] I notice that the Multinet daemon no longer prints the address of the adjacent node as it did before - don't know if that's significant or if that behavior was just removed. And I also notice that the Multinet daemon now exits (silently, without any message, good, bad or indifferent) shortly after it's started (and presumably shortly after dnroute goes Tango Uniform). Is there a plan B? I don't have a plan B sorry. As I mentioned some time ago, I don't have the resources to maintain DECnet any more :-( Chrissie

14 years, 8 months

1
0
0 0

dnroute segfaults when starting Multinet...

by bob＠jfcl.com

Chrissie Caulfield wrote: The thing to do is to upgrade dnprogs. Thanks, Chrissie - good point. I downloaded the latest source tarball from http://packages.debian.org/source/sid/all/dnprogs and recompiled everything under lenny. [I must say that the recompile was pretty painless as these things go.] Now I have ziti:/home/bob# dnroute -V dnroute from dnprogs version 2.55 A few things appear different, but sadly dnroute still segfaults after starting Multinet ziti:/home/bob# dmesg | grep -i dnroute [ 94.112034] dnroute[2996]: segfault at 0 ip 0804ac18 sp bfc40f70 error 4 in dnroute[8048000+6000] I notice that the Multinet daemon no longer prints the address of the adjacent node as it did before - don't know if that's significant or if that behavior was just removed. And I also notice that the Multinet daemon now exits (silently, without any message, good, bad or indifferent) shortly after it's started (and presumably shortly after dnroute goes Tango Uniform). Is there a plan B? Thanks again, Bob

14 years, 8 months

1
0
0 0

dnroute segfaults when starting Multinet...

by christine.caulfield＠googlemail.com

Hiya The thing to do is to upgrade dnprogs. Version 2.45 has a changelog entry that says "fix crash in dnroute daemon" ;-) The latest version is 2.55 Chrissie On 11 Nov 2010, at 19:12, Bob Armstrong wrote: I've used Linux DECnet successfully with local Ethernet connections, but now I'm trying to set up a Multinet link and dnroute segfaults every time I start the Multinet link. Of course, Multinet may have nothing to do with it - all the hosts in on my local network are in the same area and so when Multinet starts it's also the first time dnroute ever sees another level 2 routing node. The host is Debian/Lenny - bob at ziti:~$ uname -a Linux ziti 2.6.29.3-ziti.4 #1 Sun Nov 7 20:38:06 PST 2010 i586 GNU/Linux The dnprogs package is v2.44 bob at ziti:~$ /usr/sbin/dnroute -V dnroute from dnprogs version 2.44 The /etc/default/decnet file says bob at ziti:~$ cat /etc/default/decnet # DECnet configuration for ZITI - RLA [8-Nov-2010] DNET_INTERFACES="eth0" DNET_DAEMONS="dnetd dnroute" dnroute_FLAGS="-v -2" ROUTING=2 PRIORITY=16 (Note that Multinet is not started in here - for the time being, I'm starting it manually...) ziti:/home/bob# ps aux | grep -i dnroute root 2993 0.0 0.2 1672 548 ? Ss 10:42 0:00 /usr/sbin/dnroute -v -2 ziti:/home/bob# dnetinfo Addr Dev 2.1 LEGATO eth0 2.16 ziti! lo ziti:/home/bob# multinet 2.16 192.108.200.211 & using tun device tap0 Remote address = 59.58 (60474) ziti:/home/bob# dmesg | grep -i dnroute [ 383.364356] dnroute[2997]: segfault at 0 ip 0804ac18 sp bfaa3ca0 error 4 in dnroute[8048000+6000] Any ideas what I'm doing wrong? Hopefully it's something easy :-) Thanks, Bob Armstrong

14 years, 8 months

1
0
0 0

dnroute segfaults when starting Multinet...

by bob＠jfcl.com

I've used Linux DECnet successfully with local Ethernet connections, but now I'm trying to set up a Multinet link and dnroute segfaults every time I start the Multinet link. Of course, Multinet may have nothing to do with it - all the hosts in on my local network are in the same area and so when Multinet starts it's also the first time dnroute ever sees another level 2 routing node. The host is Debian/Lenny - bob at ziti:~$ uname -a Linux ziti 2.6.29.3-ziti.4 #1 Sun Nov 7 20:38:06 PST 2010 i586 GNU/Linux The dnprogs package is v2.44 bob at ziti:~$ /usr/sbin/dnroute -V dnroute from dnprogs version 2.44 The /etc/default/decnet file says bob at ziti:~$ cat /etc/default/decnet # DECnet configuration for ZITI - RLA [8-Nov-2010] DNET_INTERFACES="eth0" DNET_DAEMONS="dnetd dnroute" dnroute_FLAGS="-v -2" ROUTING=2 PRIORITY=16 (Note that Multinet is not started in here - for the time being, I'm starting it manually...) ziti:/home/bob# ps aux | grep -i dnroute root 2993 0.0 0.2 1672 548 ? Ss 10:42 0:00 /usr/sbin/dnroute -v -2 ziti:/home/bob# dnetinfo Addr Dev 2.1 LEGATO eth0 2.16 ziti! lo ziti:/home/bob# multinet 2.16 192.108.200.211 & using tun device tap0 Remote address = 59.58 (60474) ziti:/home/bob# dmesg | grep -i dnroute [ 383.364356] dnroute[2997]: segfault at 0 ip 0804ac18 sp bfaa3ca0 error 4 in dnroute[8048000+6000] Any ideas what I'm doing wrong? Hopefully it's something easy :-) Thanks, Bob Armstrong

14 years, 8 months

1
0
0 0

Running E11 inside a virtual system

by gregg.drwho8＠gmail.com

Hello! November question time. I have here a virtual system, running Windows Server 2003, naturally its biggest problem is that of its also running on top of an OS from the same firm as the virtual system frame, but that's besides the point. (We can trade those insults off list later.) Now the question, "Has anyone managed to get the latest release of E11 running that way with, any of the operating systems who support Ethernet?", and then following that, "What suggestions are available for making it available via a dynamically assigned name and IP address to the network?". My ISP seems to want to deliver an IP address to me via PPPoE for normal commercial DSL, I once asked about a static IP address, but the service hid behind some outlandish reason at the time that it wasn't possible. I suspect its because the ISP, then Covad behind AT&T, never considered such a method of delivery for its commercial, read household, customers, and hence went ahead with what it believed to be an easy method. Then in March I migrated from that method of having a ISP to work with to just Covad. Same other e-mail addresses naturally. To supply the occasional access method for the systems, for when I was away from here, and needed to do so, I went ahead and used the services of DDNS to make a hostname available. I chose the vendor http://www.dyndns.com/ simply because it would be an easy configuration step, then, or so I thought. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

14 years, 8 months

1
0
0 0

gcc for pdp11

by davidson＠declab.net

Paul Koning On Oct 24, 2010, at 8:07 PM, Steve Davidson wrote: Paul Koning =20 Does anyone here use gcc for the pdp11? =20 I've been doing some work on it to clean it up. For one thing, it = now =3D builds, which certainly is a useful start... :-) =20 I've been playing with the idea of writing an 82586 driver (UGH!) for = =3D the Pro for RSTS, and seeing how disgustingly sick that chip is, = doing =3D it from scratch, or even seriously transforming existing assembly =3D language drivers, is an unpleasant notion. On the other hand, doing = it =3D in C (more precisely, borrowing from, say, the NetBSD driver, changed = as =3D needed) seems more palatable. =20 I *think* gcc is close to being able to handle that job. So I'll =3D probably be using it for that purpose. Am I the only user of that =3D compiler or are there others? =20 paul =20 =20 =20 Paul, =20 Will "gcc" build for the VAX (or Alpha) so it can be used as a cross = compiler for the 11's on those platforms? I'm pretty sure the answer is yes to both, but I don't know from = personal experience. paul Paul, STARS:: has the RSX AME installed. It would be very easy to test this. -Steve

14 years, 8 months

1
0
0 0

gcc for pdp11

by davidson＠declab.net

Paul Koning On Oct 24, 2010, at 8:07 PM, Steve Davidson wrote: Paul Koning =20 Does anyone here use gcc for the pdp11? =20 I've been doing some work on it to clean it up. For one thing, it = now =3D builds, which certainly is a useful start... :-) =20 I've been playing with the idea of writing an 82586 driver (UGH!) for = =3D the Pro for RSTS, and seeing how disgustingly sick that chip is, = doing =3D it from scratch, or even seriously transforming existing assembly =3D language drivers, is an unpleasant notion. On the other hand, doing = it =3D in C (more precisely, borrowing from, say, the NetBSD driver, changed = as =3D needed) seems more palatable. =20 I *think* gcc is close to being able to handle that job. So I'll =3D probably be using it for that purpose. Am I the only user of that =3D compiler or are there others? =20 paul =20 =20 =20 Paul, =20 Will "gcc" build for the VAX (or Alpha) so it can be used as a cross = compiler for the 11's on those platforms? I'm pretty sure the answer is yes to both, but I don't know from = personal experience. paul If you wish to push it to STARS:: we can sure find out soon enough! -Steve

14 years, 8 months

1
0
0 0

gcc for pdp11

by paul_koning＠dell.com

On Oct 24, 2010, at 8:07 PM, Steve Davidson wrote: Paul Koning Does anyone here use gcc for the pdp11? I've been doing some work on it to clean it up. For one thing, it now = builds, which certainly is a useful start... :-) I've been playing with the idea of writing an 82586 driver (UGH!) for = the Pro for RSTS, and seeing how disgustingly sick that chip is, doing = it from scratch, or even seriously transforming existing assembly = language drivers, is an unpleasant notion. On the other hand, doing it = in C (more precisely, borrowing from, say, the NetBSD driver, changed as = needed) seems more palatable. I *think* gcc is close to being able to handle that job. So I'll = probably be using it for that purpose. Am I the only user of that = compiler or are there others? paul Paul, Will "gcc" build for the VAX (or Alpha) so it can be used as a cross compiler for the 11's on those platforms? I'm pretty sure the answer is yes to both, but I don't know from personal experience. paul

14 years, 8 months

1
0
0 0

gcc for pdp11

by davidson＠declab.net

Paul Koning Does anyone here use gcc for the pdp11? I've been doing some work on it to clean it up. For one thing, it now = builds, which certainly is a useful start... :-) I've been playing with the idea of writing an 82586 driver (UGH!) for = the Pro for RSTS, and seeing how disgustingly sick that chip is, doing = it from scratch, or even seriously transforming existing assembly = language drivers, is an unpleasant notion. On the other hand, doing it = in C (more precisely, borrowing from, say, the NetBSD driver, changed as = needed) seems more palatable. I *think* gcc is close to being able to handle that job. So I'll = probably be using it for that purpose. Am I the only user of that = compiler or are there others? paul Paul, Will "gcc" build for the VAX (or Alpha) so it can be used as a cross compiler for the 11's on those platforms? -Steve

14 years, 8 months

1
0
0 0

gcc for pdp11

by ahling＠eadc.se

What a pity you didn't mention the Texas MSP430 single-chip system instead ;-) Quote from: http://www.eg3.com/msp430.htm "The MSP430 is a micro-controller family from Texas Instruments. Built around a 16-bit CPU, the MSP430 is designed for low cost, low power consumption embedded applications. The architecture is reminiscent of the DEC PDP-11. " My first views upon this architecture makes me wonder where quite some of the addressing modes went, but this is certainly closer to a real PDP than any AVR! All my best' to all PDP fan s /G ran On 2010-10-23 17:36, Paul Koning wrote: GCC is way too big to fit on a PDP11. But it makes a fine cross-compiler. In fact, it can cross-compile for lots of smaller things, like AVR single chip microcontrollers (things that cost only a dollar or two). paul On Oct 23, 2010, at 10:47 AM, Pontus Pihlgren wrote: On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote: Does anyone here use gcc for the pdp11? No, but I'm curious. Do you mean to run in on a PDP-11 or would you use it to cross compile stuff?. /P

14 years, 8 months

1
0
0 0

gcc for pdp11

by paul_koning＠dell.com

GCC is way too big to fit on a PDP11. But it makes a fine cross-compiler. In fact, it can cross-compile for lots of smaller things, like AVR single chip microcontrollers (things that cost only a dollar or two). paul On Oct 23, 2010, at 10:47 AM, Pontus Pihlgren wrote: On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote: Does anyone here use gcc for the pdp11? No, but I'm curious. Do you mean to run in on a PDP-11 or would you use it to cross compile stuff?. /P

14 years, 8 months

1
0
0 0

gcc for pdp11

by pontus＠Update.UU.SE

On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote: Does anyone here use gcc for the pdp11? No, but I'm curious. Do you mean to run in on a PDP-11 or would you use it to cross compile stuff?. /P

14 years, 8 months

1
0
0 0

gcc for pdp11

by paul_koning＠dell.com

Does anyone here use gcc for the pdp11? I've been doing some work on it to clean it up. For one thing, it now builds, which certainly is a useful start... :-) I've been playing with the idea of writing an 82586 driver (UGH!) for the Pro for RSTS, and seeing how disgustingly sick that chip is, doing it from scratch, or even seriously transforming existing assembly language drivers, is an unpleasant notion. On the other hand, doing it in C (more precisely, borrowing from, say, the NetBSD driver, changed as needed) seems more palatable. I *think* gcc is close to being able to handle that job. So I'll probably be using it for that purpose. Am I the only user of that compiler or are there others? paul

14 years, 8 months

1
0
0 0

hecnet.eu website is back up

by mark＠wickensonline.co.uk

On 22/10/10 13:31, Johnny Billquist wrote: On 10/22/10 14:20, Mark Wickens wrote: Greetings Following the hard disk tragedy earlier this month BUBBLE has risen again like a Phoenix from the flames, and as a consequence the website is now back up and, apart from the WALL, working much is it did pre-crash. There is now a robust backup schedule in place to make sure this situation never arises again. I was thinking about Sampsa's phone directory program again - is there a way to implement this so that it doesn't cause network issues? Do it from VMS? :-) It is only the Linux DECnet that causes my (and others?) logs to fill with data about not reached nodes. Johnny Ah OK I couldn't remember the exact problem, but that now has jogged my memory. VAX/VMS is the obvious choice for me ;) Thanks, Mark.

14 years, 8 months

1
0
0 0

hecnet.eu website is back up

by bqt＠softjar.se

On 10/22/10 14:20, Mark Wickens wrote: Greetings Following the hard disk tragedy earlier this month BUBBLE has risen again like a Phoenix from the flames, and as a consequence the website is now back up and, apart from the WALL, working much is it did pre-crash. There is now a robust backup schedule in place to make sure this situation never arises again. I was thinking about Sampsa's phone directory program again - is there a way to implement this so that it doesn't cause network issues? Do it from VMS? :-) It is only the Linux DECnet that causes my (and others?) logs to fill with data about not reached nodes. Johnny

14 years, 8 months

1
0
0 0

hecnet.eu website is back up

by mark＠wickensonline.co.uk

Greetings Following the hard disk tragedy earlier this month BUBBLE has risen again like a Phoenix from the flames, and as a consequence the website is now back up and, apart from the WALL, working much is it did pre-crash. There is now a robust backup schedule in place to make sure this situation never arises again. I was thinking about Sampsa's phone directory program again - is there a way to implement this so that it doesn't cause network issues? Regards, Mark.

14 years, 8 months

1
0
0 0

Suggestions for LAT.

by bqt＠softjar.se

On 2010-10-17 05:54, Steve Davidson wrote: Let's take this off-line and figure something out. It looks like we are pretty close anyway. How does that sound? If we come up with a mapping then everyone could be on the right page with minimal confusion. This will have to wait for a few hours - I need to get some sleep. No problem. Take some sleep (I should too), and we can talk tomorrow. Maybe someone else have some opinion or views as well? Right now I'm using the groups I mentioned earlier, but it would take me about five minutes to change it all, if I need to. So I guess it's just to decide how we'll do this, and I'll fix my end. If you can think of some algorithmic way to set up a mapping, fine. Otherwise we'll just grab numbers out of the blue and "assign" them. 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

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by davidson＠declab.net

Johnny Billquist On 2010-10-17 05:44, Steve Davidson wrote: Johnny Billquist On 2010-10-17 05:16, Steve Davidson wrote: Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 Johnny, The way I do it around here is use group 0 for public access. It is the default group anyway. I use group 19, which is also my DECnet area for my private use. This allows us to have 63 private areas if we map to DECnet area numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to combine my group with someone else. Nice that we agree on group 0. :-) However, I see very little need to combine groups. If you want to combine groups, just set the port to access both groups instead. I would suggest that group 0 be public group 1 through 63 be private based on DECnet area # (self managed) groups 64-255 be managed (and reserved) (each area could have 4 such #s) I see a problem with that. Areas are not a good separation here. There are several different people in area 1, for instance, which don't really match the groups of systems that might be public or private. I am (as you might have noticed) separating me (BQT) from Update, even though we're both in area 1. There are more people in area 1 as well, which I would believe it would make more sense to place in other groups as well. Also, I have further separated my groups into two parts. General access systems and special services. So, for me and Update, it now looks like this: 0 General public access 1 General public access for Update users 2 Consoles for Update machines 3 General access for my systems 4 Consoles for my systems So, for Update terminal servers, I have set them to see machines in group 0 and 1. For my terminal servers, I see group 0,1 and 3 by default (since I'm also using Update machines regularly). When I need to fool around with systems, I also add group 2 and 4. When Update people would need to fool around, they would add group 2, they don't have access to my systems in general, and there is no point for them to see those (my console) services. I hope you see the point here. Because I am already using group 64 I am reserving it. I make it available to others when it makes sense for me to "share" as it were. Reserved groups should be by invitation only because as you point out the list does get cluttered. No problem with that. I'm definitely no where near group 64 so far. But I also think that people should not set their machines to be in other groups than their own unless it is very obvious that the machines actually belong in several groups. But (as you probably know), there is no way to prevent anyone from setting up any group numbers they want, so this will be very much by voluntary participation. The use of passwords is a great idea for the DECservers we have in HECnet. Some of mine have it, some do not - personal choice. Just making suggestions. :-) 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 When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of machines and group 19 so that we could go back and forth as necessary. This was prior to your announcement of groups you proposed to use. I just made a proposition because I started thinking that the list when I do a "SHOW SERVICE" starts to look a bit long and cluttered with machines that really are irrelevant for me to see. However, I have absolutely no problem using other groups for me and Update, so it's not about the numbers as such. But I definitely can't work with a mapping to area numbers, since area numbers don't reflect any division as such. It's more of a connectivity issue, with different levels of routers. Also, since LAT is not routed, this numbering scheme is very local to the machines connected to this specific bridge segment, and is not global for HECnet as a whole. So I'll happily move myself to another LAT group. I just want two groups for Update, and two for myself, so I can make a sensible separation between different groups of services. And it would be nice to not have a bunch of services in group 0 which are private, and possibly even not general connections to login services. 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 Let's take this off-line and figure something out. It looks like we are pretty close anyway. How does that sound? If we come up with a mapping then everyone could be on the right page with minimal confusion. This will have to wait for a few hours - I need to get some sleep. -Steve

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by bqt＠softjar.se

On 2010-10-17 05:44, Steve Davidson wrote: Johnny Billquist On 2010-10-17 05:16, Steve Davidson wrote: Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 Johnny, The way I do it around here is use group 0 for public access. It is the default group anyway. I use group 19, which is also my DECnet area for my private use. This allows us to have 63 private areas if we map to DECnet area numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to combine my group with someone else. Nice that we agree on group 0. :-) However, I see very little need to combine groups. If you want to combine groups, just set the port to access both groups instead. I would suggest that group 0 be public group 1 through 63 be private based on DECnet area # (self managed) groups 64-255 be managed (and reserved) (each area could have 4 such #s) I see a problem with that. Areas are not a good separation here. There are several different people in area 1, for instance, which don't really match the groups of systems that might be public or private. I am (as you might have noticed) separating me (BQT) from Update, even though we're both in area 1. There are more people in area 1 as well, which I would believe it would make more sense to place in other groups as well. Also, I have further separated my groups into two parts. General access systems and special services. So, for me and Update, it now looks like this: 0 General public access 1 General public access for Update users 2 Consoles for Update machines 3 General access for my systems 4 Consoles for my systems So, for Update terminal servers, I have set them to see machines in group 0 and 1. For my terminal servers, I see group 0,1 and 3 by default (since I'm also using Update machines regularly). When I need to fool around with systems, I also add group 2 and 4. When Update people would need to fool around, they would add group 2, they don't have access to my systems in general, and there is no point for them to see those (my console) services. I hope you see the point here. Because I am already using group 64 I am reserving it. I make it available to others when it makes sense for me to "share" as it were. Reserved groups should be by invitation only because as you point out the list does get cluttered. No problem with that. I'm definitely no where near group 64 so far. But I also think that people should not set their machines to be in other groups than their own unless it is very obvious that the machines actually belong in several groups. But (as you probably know), there is no way to prevent anyone from setting up any group numbers they want, so this will be very much by voluntary participation. The use of passwords is a great idea for the DECservers we have in HECnet. Some of mine have it, some do not - personal choice. Just making suggestions. :-) 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 When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of machines and group 19 so that we could go back and forth as necessary. This was prior to your announcement of groups you proposed to use. I just made a proposition because I started thinking that the list when I do a "SHOW SERVICE" starts to look a bit long and cluttered with machines that really are irrelevant for me to see. However, I have absolutely no problem using other groups for me and Update, so it's not about the numbers as such. But I definitely can't work with a mapping to area numbers, since area numbers don't reflect any division as such. It's more of a connectivity issue, with different levels of routers. Also, since LAT is not routed, this numbering scheme is very local to the machines connected to this specific bridge segment, and is not global for HECnet as a whole. So I'll happily move myself to another LAT group. I just want two groups for Update, and two for myself, so I can make a sensible separation between different groups of services. And it would be nice to not have a bunch of services in group 0 which are private, and possibly even not general connections to login services. 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

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by davidson＠declab.net

Steve Davidson Johnny Billquist On 2010-10-17 05:16, Steve Davidson wrote: Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 Johnny, The way I do it around here is use group 0 for public access. It is the default group anyway. I use group 19, which is also my DECnet area for my private use. This allows us to have 63 private areas if we map to DECnet area numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to combine my group with someone else. Nice that we agree on group 0. :-) However, I see very little need to combine groups. If you want to combine groups, just set the port to access both groups instead. I would suggest that group 0 be public group 1 through 63 be private based on DECnet area # (self managed) groups 64-255 be managed (and reserved) (each area could have 4 such #s) I see a problem with that. Areas are not a good separation here. There are several different people in area 1, for instance, which don't really match the groups of systems that might be public or private. I am (as you might have noticed) separating me (BQT) from Update, even though we're both in area 1. There are more people in area 1 as well, which I would believe it would make more sense to place in other groups as well. Also, I have further separated my groups into two parts. General access systems and special services. So, for me and Update, it now looks like this: 0 General public access 1 General public access for Update users 2 Consoles for Update machines 3 General access for my systems 4 Consoles for my systems So, for Update terminal servers, I have set them to see machines in group 0 and 1. For my terminal servers, I see group 0,1 and 3 by default (since I'm also using Update machines regularly). When I need to fool around with systems, I also add group 2 and 4. When Update people would need to fool around, they would add group 2, they don't have access to my systems in general, and there is no point for them to see those (my console) services. I hope you see the point here. Because I am already using group 64 I am reserving it. I make it available to others when it makes sense for me to "share" as it were. Reserved groups should be by invitation only because as you point out the list does get cluttered. No problem with that. I'm definitely no where near group 64 so far. But I also think that people should not set their machines to be in other groups than their own unless it is very obvious that the machines actually belong in several groups. But (as you probably know), there is no way to prevent anyone from setting up any group numbers they want, so this will be very much by voluntary participation. The use of passwords is a great idea for the DECservers we have in HECnet. Some of mine have it, some do not - personal choice. Just making suggestions. :-) 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 When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of machines and group 19 so that we could go back and forth as necessary. This was prior to your announcement of groups you proposed to use. -Steve Make that group 4 for his local machines and group 64 as a shared group with my systems. - It's too late and I probably should be in bed. Sorry... -Steve

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by davidson＠declab.net

Johnny Billquist On 2010-10-17 05:16, Steve Davidson wrote: Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 Johnny, The way I do it around here is use group 0 for public access. It is the default group anyway. I use group 19, which is also my DECnet area for my private use. This allows us to have 63 private areas if we map to DECnet area numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to combine my group with someone else. Nice that we agree on group 0. :-) However, I see very little need to combine groups. If you want to combine groups, just set the port to access both groups instead. I would suggest that group 0 be public group 1 through 63 be private based on DECnet area # (self managed) groups 64-255 be managed (and reserved) (each area could have 4 such #s) I see a problem with that. Areas are not a good separation here. There are several different people in area 1, for instance, which don't really match the groups of systems that might be public or private. I am (as you might have noticed) separating me (BQT) from Update, even though we're both in area 1. There are more people in area 1 as well, which I would believe it would make more sense to place in other groups as well. Also, I have further separated my groups into two parts. General access systems and special services. So, for me and Update, it now looks like this: 0 General public access 1 General public access for Update users 2 Consoles for Update machines 3 General access for my systems 4 Consoles for my systems So, for Update terminal servers, I have set them to see machines in group 0 and 1. For my terminal servers, I see group 0,1 and 3 by default (since I'm also using Update machines regularly). When I need to fool around with systems, I also add group 2 and 4. When Update people would need to fool around, they would add group 2, they don't have access to my systems in general, and there is no point for them to see those (my console) services. I hope you see the point here. Because I am already using group 64 I am reserving it. I make it available to others when it makes sense for me to "share" as it were. Reserved groups should be by invitation only because as you point out the list does get cluttered. No problem with that. I'm definitely no where near group 64 so far. But I also think that people should not set their machines to be in other groups than their own unless it is very obvious that the machines actually belong in several groups. But (as you probably know), there is no way to prevent anyone from setting up any group numbers they want, so this will be very much by voluntary participation. The use of passwords is a great idea for the DECservers we have in HECnet. Some of mine have it, some do not - personal choice. Just making suggestions. :-) 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 When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of machines and group 19 so that we could go back and forth as necessary. This was prior to your announcement of groups you proposed to use. -Steve

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by bqt＠softjar.se

On 2010-10-17 05:29, Steve Davidson wrote: Could the owner of PSILOCYBE not enable all groups 1-255 please? That would be me, and I did that accidentally for a short while. It should already have been fixed. Is it not? It should currently be only in group 1 (it's not a machine people in general have any interest in, but Update people is using it in general). 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

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by bqt＠softjar.se

On 2010-10-17 05:16, Steve Davidson wrote: Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 Johnny, The way I do it around here is use group 0 for public access. It is the default group anyway. I use group 19, which is also my DECnet area for my private use. This allows us to have 63 private areas if we map to DECnet area numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to combine my group with someone else. Nice that we agree on group 0. :-) However, I see very little need to combine groups. If you want to combine groups, just set the port to access both groups instead. I would suggest that group 0 be public group 1 through 63 be private based on DECnet area # (self managed) groups 64-255 be managed (and reserved) (each area could have 4 such #s) I see a problem with that. Areas are not a good separation here. There are several different people in area 1, for instance, which don't really match the groups of systems that might be public or private. I am (as you might have noticed) separating me (BQT) from Update, even though we're both in area 1. There are more people in area 1 as well, which I would believe it would make more sense to place in other groups as well. Also, I have further separated my groups into two parts. General access systems and special services. So, for me and Update, it now looks like this: 0 General public access 1 General public access for Update users 2 Consoles for Update machines 3 General access for my systems 4 Consoles for my systems So, for Update terminal servers, I have set them to see machines in group 0 and 1. For my terminal servers, I see group 0,1 and 3 by default (since I'm also using Update machines regularly). When I need to fool around with systems, I also add group 2 and 4. When Update people would need to fool around, they would add group 2, they don't have access to my systems in general, and there is no point for them to see those (my console) services. I hope you see the point here. Because I am already using group 64 I am reserving it. I make it available to others when it makes sense for me to "share" as it were. Reserved groups should be by invitation only because as you point out the list does get cluttered. No problem with that. I'm definitely no where near group 64 so far. But I also think that people should not set their machines to be in other groups than their own unless it is very obvious that the machines actually belong in several groups. But (as you probably know), there is no way to prevent anyone from setting up any group numbers they want, so this will be very much by voluntary participation. The use of passwords is a great idea for the DECservers we have in HECnet. Some of mine have it, some do not - personal choice. Just making suggestions. :-) 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

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by davidson＠declab.net

Could the owner of PSILOCYBE not enable all groups 1-255 please? Thanks. -Steve

14 years, 9 months

1
0
0 0

Suggestions for LAT.

by davidson＠declab.net

Johnny Billquist On 2010-10-17 04:01, Johnny Billquist wrote: So here is a new suggestion for the bridge which is "hubbed" around Update. 0 Publicly available systems 1 Update 2 BQT Let me know, and I'll happily assign LAT groups for others as well. Small correction to that list: 0 Public systems 1 Update 2 Update 3 BQT 4 BQT 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 I forgot to mention in my last mail that only one of my machines makes use of group 0. That is the RSTS/E system. I let it broadcast group 0 because it appears to be the only active RSTS/E system on the network. This way anyone in HECnet (with LAT access) may get to it (if they have an account that is). -Steve

14 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet