Release 1.7d of LISTSERV will introduce support for the "nodename change"
tags (':oldnode.' and ':newnode.'), to make name change, consolidation
(several small machines -> one big machine) and deletion of nodes easier
for list owners. What I have implemented does not correspond exactly to
the formal specifications, for reasons you will understand later. Since I
don't think these tags have ever been used (read, they have never
appeared in BITEARN NODES as far as I know), it is not too late to update
the specifications. In any case, the NIC and NCC should definitely review
the verification rules they might have for these tags and make sure that
a procedure exists to prevent abusive use. LISTSERV attempts to detect
the obvious cases, but it can only go so far.
NEWTAGS DESCRIPT defines a ':oldnode.' tag which one may put in the entry
of a node which has replaced, or is about to replace, the node in
question. That is, one would code ':node.NEW :oldnode.OLD' to tell the
world that node OLD has become or is going to become node NEW. OLD must
be a NJE nodeid, and may or may not be present in BITEARN NODES; if it is
present, it must contain a ':newnode.NEW' tag (see below).
LISTSERV recognize the ':oldnode.' tag and accepts more than one old
nodeid. This is necessary to make it possible to merge several machines
into a single node; I would like the specifications to be extended to
allow this. If the "old node" is not in BITEARN NODES, LISTSERV replaces
all occurences of the old node with the new node in mailing list
subscriptions, AFD, FUI and password files. If the "old node" is still
there but does not have a reciprocal ':newnode.' tag, or if several nodes
claim the same "old node" (which the specifications should clearly
disallow), LISTSERV throws away the entry and Eric Thomas posts yet
another unprofessional message to NODMGT-L, as this should in principle
never happen. If the old node still exists and has the reciprocal tag,
LISTSERV ignores it and only processes the ':newnode.' tag (see below).
NEWTAGS DESCRIPT defines a ':newnode.' tag which one puts in the entry of
a node which is going to be deleted and replaced with the node in
question. This must be an NJE nodeid, it must exist and there must be a
reciprocal ':oldnode.' tag in the entry in question.
LISTSERV accepts either an Internet hostname or a NJE nodeid in this tag.
In the case of a NJE nodeid, the cross-verifications described above are
performed and the ill-worded message is posted in case of failure, or if
more than one hostname is specified. For Internet hostnames LISTSERV has
no way to check anything, which is why the NIC/NCC's should check these
tags manually. LISTSERV performs the same one-time change to mailing
lists et al as described above and, in addition, automatically translates
the origin of future incoming commands (and the parameters to most list
owner commands), in order to prevent new entries with the old nodename
from being added anywhere. This is particularly important in the case of
Internet hostnames, which will not have the opportunity to go through
another "cleanup" operation once the node is deleted - the new name is
not in BITEARN NODES and thus cannot have a ':oldnode.' tag.
LISTSERV ignores any ':internet.' tag in the entry of a NJE node with a
':newnode.' tag, in order to avoid internal complications. Theoretically,
LISTSERV could solve these problems by internally moving the tag to the
entry of the new node. This however raises the issue of what the proper
behaviour should be if the new node also has its own ':internet.' tag. In
practice, there are only two cases:
1. Node A is being renamed to node B, same machine. The ':internet.' tag
should be moved to the entry of node B with the update that adds the
':newnode.' tag; this has to be done sooner or later, anyway.
2. The node is going away, or is being merged into a machine with a
different Internet address. In that case the ':internet.' tag is no
longer needed, as all records with NJE nodenames will be gone and
records with Internet addresses will match directly; there no longer
is a NJE nodeid the users can send commands from.
IMPORTANT: This is a BITNET node deletion and renaming facility, not a
"force all users from my node to use Internet addresses even if they
don't want to because I say so" facility. Once you place the ':newnode.'
tag in BITEARN NODES, there is no way for users to issue commands under
the old address. There is no point in cleaning up all files one month
before the deletion if you allow users to re-add obsolete entries during
the month in question. If the new address is an NJE address, all requests
will be processed under that name, and you have to consider whether this
is acceptable in case the old and new nodeids are not yet the same
physical machine. If the new address is an Internet address, the users no
longer have an NJE address and have to use mail to order files and so on.
Think twice before you use that tag for purposes it was not meant to
have.
Eric
|
