Keys uses the assigned key for the NA file groups the link has access to. GroupHub uses the groups' shortnames for those same groups.
wouldn't it be better/easier to use the Keys values for the GroupHub values? it would be less confusing when entering them... especially when you have 10 or 15 or more groups... then only one scrap of paper with the group and key written on it would be needed when transcribing them into echocfg/sbbsecho.ini ;)
so i'm asking about using the keys for both Keys and GroupHub fields to help keep things consistent...
doesn'tso i'm asking about using the keys for both Keys and GroupHub fields to
help keep things consistent...
I don't understand. Keys and GroupHub are different things. A sysop
necessarily have a key for every group. Nor is there necessarily a "hub" for every group, nor an echolist for every group.
You could have one echolist for the fidonet NA backbone, with an
assigned access "key", yet have those areas split among multiple
message groups.
The "GroupHub" feature is *only* used for automatically adding
sub-boards to the areafile (optionally) - that's it. It has no
correlation with echolists.
You could have one echolist for the fidonet NA backbone, with an assigned access "key", yet have those areas split among multiple message groups.
hunh? i didn't know that... i import various NA files speficically to split the
areas into groups for user as well as link access separation...
The "GroupHub" feature is *only* used for automatically adding sub-boards to the areafile (optionally) - that's it. It has no correlation with echolists.
ok... since i'm connected to the other two backbone stars, i added the grouphub
data to their entries... it just seemed weird to use keys (F000, F001, F002) and short names (Fidonet, Fido NoBB, Fidonet Sysops) for the same things... ya gotta have a chart listing each group, their key and their short name to tie it
all together...
Are you clear what the GroupHub feature is doing for you? You may not (probably do not) even need it.
Re: sbbsecho.ini Keys vs GroupHub
By: Digital Man to mark lewis on Sun Sep 30 2018 15:46:43
Are you clear what the GroupHub feature is doing for you? You may not (probably do not) even need it.
my understanding is that it along with AutoAddSubs will automatically link those two systems into a message area when the first message(s) start arriving in that area and we don't already have it configured...
the goal is
to automatically tie those systems into my configuration for new areas that we pass in our backbone list...
at least that's my understanding of what those options work together to do... i just don't have AutoAddSubs turned on yet... i was waiting as i worked through things until i got to that point and then ask a few questions... i still need to set up an area for bad messages so i can catch those for areas i've missed adding in and then i can retoss them and use that new auto-add feature you have :)
Are you clear what the GroupHub feature is doing for you? You may not
(probably do not) even need it.
my understanding is that it along with AutoAddSubs will automatically
link those two systems into a message area when the first message(s)
start arriving in that area and we don't already have it configured...
That's partially right. If a sub-board is added to the specified
message group (in SCFG) and is not present in the area file
(areas.bbs), it'll be automatically added with the hub (uplink)
address. It doesn't really have anything to do with message flow (the message area could be empty). And to be clear, a GroupHub is an
*uplink* to your system.
at least that's my understanding of what those options work together to
do... i just don't have AutoAddSubs turned on yet... i was waiting as i
worked through things until i got to that point and then ask a few
questions... i still need to set up an area for bad messages so i can
catch those for areas i've missed adding in and then i can retoss them
and use that new auto-add feature you have :)
Yes, I think you have it.
But this has nothing to do with controlling access to echolists via
the area manager (which is what the "EchoList Keys" are all about). EchoList keys are really for use with your *downlinks*. It's not
expected that any of your uplinks would need to send area manager
requests to your system (so they would not need *any* EchoList keys assigned to them).
But this has nothing to do with controlling access to echolists via
the area manager (which is what the "EchoList Keys" are all about). EchoList keys are really for use with your *downlinks*. It's not expected that any of your uplinks would need to send area manager requests to your system (so they would not need *any* EchoList keys assigned to them).
hummm... we do know that areafix works both ways, right?
if you link to me
as a
"downlink" and turn on some areas, i can use the same areafix technique to turn on or off areas on your system, too... we both use the same areafix password to talk to each other's areafix... it was several years ago when ross cassell unlinked some areas from my system when they were being removed from the backbone when it hit me that the areafix was two way :lolol: i hadn't thought about my ""uplink"" being able to do that until that point...
but now that i'm one of the star systems, i would think that my ""uplinks"" (the other two stars) do need access to the groups via the keys... without the keys, messages they deliver would not be tossed into the proper areas, right?
understanding is that once i set up the keys, every connected system has to have at least one key...
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495939:03:35 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,964 |