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
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
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
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
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
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
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.
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)
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.
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.
-Steve
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
On 2010-10-17 03:43, Johnny Billquist wrote:
On 2010-10-17 03:34, Johnny Billquist wrote:
Hi. As a few people are sharing LAT connections now as well, I thought
I'd make a suggestion on how to make this a bit more manageable.
If people have questions on LAT, how to set up DECservers, or something
else, you can as usual just mail me.
First of all, please note that LAT is not a safe protocol. Everything
goes in clear text, and malicious people can easily snoop your sessions.
My thoughts right now are in the area of services offered. When I list
services I notice that some machine consoles are available, as well as
some general machine logins.
The console services are nice to have (I also have a few of those),
however, they are not useful for the general public, and the hope is
that people who don't have anything to do with them don't connect to
them. But they do clutter up the list of available services anyhow.
What I'd like to propose is that for services that aren't of general use
should switch to another group. The default group is group #0, and that
group is nice to continue to use for generally available systems that
people might want to log in to.
I've been using group 1 for consoles for now, and I'd suggest that
others do that too. Or perhaps pick some other group if you want to keep
your machines separate. Notice that this does not really add anything
from a security point of view, since people can change their own port to
see services in any group if they really want to.
But if people set up their port to by default only be in group 0, and we
place consoles in group 1, they will not show up in the general case,
and you'd have to explicitly turn on group 1 when you want to play with
consoles (or if you want it on by default, feel free, but it will look
nicer to some atleast).
The same goes if you have printers, for instance, as services. Place
them also in another group. Preferably in yet another group, but atleast
not in group 0. And modems as well, if you have those.
So a suggested division of groups would be as follows:
0 General systems where people might log in.
1 Consoles
2 Modems
3 Printers
If you have all of that on the same DECserver you cannot be picky,
however, since you can only specify one group for all services offered.
Use the lowest group number for which you have a matching service in
that case.
Note that the group numbers only affect which services are visible to
users connected to a DECserver. It does not affect reverse LAT
connections, which will find the right service no matter which group it
is in.
So this is mostly just to make the list of services more convenient when
you look as an interactive user on a DECserver.
Finally a short suggestion for those of you who have consoles as
services. If you haven't found it, or set it up, I'd also suggest you
place a password on those services, which can limit the possibility of
others to wreak havoc on your machines... Just a suggestion.
It will still not prevent others from potentially DoS your console port.
I just had another idea as well.
Would people think it would be an interesting idea to have group numbers
for machines differentiate depending on OS? So that people could see
what VMS systems there are to connect to without seeing other systems?
Or maybe it would be more meaningful if we use group 0 for systems where
guest access is available, and then people use their own groups for
"local" systems?
Oh yeah, I should probably point out that all of this is only relevant to the people running my bridge program on the same segment I am. Others can obviously do as they want, since that is not visible to me anyway.
Thinking a bit more about it, it actually makes more sense to use one group (0) for all publicly available systems, and a separate group (or two) where you can place all private machines, console ports, printers, modems and so on. That way you can see all services relevant to you, without being bothered about services that you don't care about, or can use anyway...
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.
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
