I'm not sure exactly what is meant by "joined" lists. Here, as I see them
are the current requirements for Peering lists.
1. All servers MUST be a part of the LISTSERV backbone. If you are not,
you may NOT host any peered lists.
2. Pick a network coordinator for the new Peered list. You can have more
than one, but if you do then they must communicate with each other before
making changes to the list. They will be owners of ALL of the peered lists.
3. All lists must have the same "List-ID". This is the same as the list
name, unless the "List-ID=" keyword is present in the list header. This
is so the list will properly be listed in the network wide LISTSERV LISTS.
To obtain this list, send the command "LIST GLOBAL" to your nearest backbone
LISTSERV.
4. All lists must have the same list password. You can ensure it is the same
at all servers at the same time you ensure that the list coordinator is an
owner at all servers.
5. We are now ready to begin the actual peering of the lists. Make a list
of all the servers who will host copies of the list. Code a 'Peers=" statement
to be included in the headers of all of the lists. They can be identical. It
doesn't matter if the local node ID appears in the local list header. If the
actual name (not the List-ID) of any remote list is not the same as the local
list name, then the name must also appear in the "Peers=" statement. Thus, if
I am peering 3 lists, LIST-L@NODEA, LIST-L@NODEB, and ABCD@NODEC then the
following Peers statement can be used at both NODEA and NODEB:
Peers= NODEA,NODEB,ABCD@NODEC
while the following Peers statement is required at NODEC:
Peers= LIST-L@NODEA,LIST-L@NODEB,NODEC
NODEC will also have to have the statement;
List-ID= LIST-L
in it's header, since the actual name, ABCD is not the same as the list name
as know to the rest of the world.
6. We can now do the actual links. This is best done by the list coordinator
to ensure that no loops occur (more on loops in a minute). Before any linking
takes place, I recommend you "HOLD" all lists. This is to ensure that no mail
is sent while the new list is in an incorrect state. After all lists are held,
the coordinator can add and delete the peer links. What destinguishes a 'Peer"
link from any other subscription? It is the magic words "Peer Distribution
List" in the subscribers name entry. So for the list we discussed above,
assuming that no links exist, the commands to make the necessary links are:
TELL LISTSERV AT NODEA QUIET ADDH LIST-L LIST-L@NODEB Peer Distribution List
TELL LISTSERV AT NODEB QUIET ADDH LIST-L LIST-L@NODEA Peer Distribution List
TELL LISTSERV AT NODEB QUIET ADDH LIST-L ABCD@NODEC Peer Distribution List
TELL LISTSERV AT NODEC QUIET ADDH ABCD LIST-L@NODEB Peer Distribution List
Please be sure and do a QUIET ADDHERE, since the subscription messages will be
sent back to the list, and will thus be forwarded to all subscribers when the
list is freed.
With only 2 or 3 lists, mail loops are not a problem. You must ensure that
one and only one path exists between any two nodes in the new linked list.
The latest version of LISTSERV will detect mail loops created by redundant
links, but the following excerpt from LINKLIST MEMO will show some correct
and incorrect configurations.
Important remark: whenever more than two servers are to be linked as
peers, it is important not to have redundant links since THESE could
cause message duplication (but not loops). For example, the two following
configurations are acceptable:
D
|
|
V
A <---> B <---> C <---> D <---> E A <---> B <---> C
|
|
V
E
...but the following would cause duplicated messages:
+-----------------------+ +-----> D
| | | |
| | | |
V V V V
A <---> B <---> C <---> D <---> E A <---> B <---> C
|
|
V
E
For more information on Linking lists, the following documents (available
from LISTSERV are recommended reading:
LISTSERV MEMO
LISTOWNR MEMO
LISTMAST MEMO
LISTLINK MEMO
Hope this helps. If anyone has any additions or correction to this, please
let me know.
Harold Pritchett
LISTSERV Coordinator
|
