ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~
This document is subject to change depending system testing and the finding
of errors within.
The following notes will be incorporated in to new manuals and help files for
both the program operation and for Moderators otherwise acts as additional
material.
All requests via MOD-ADD, MD-UPD and MOD-DEL must have keyword PASS present
followed by the password on file. This is checked for on all, and for MOD-ADD
the echo data record must not exist yet. At the current moment only files are
accepted by being dropped off at the Elist maintainer system i.e., ECHOtag.RUL
and ECHOtag.ECO the subject for the ECO file must be present (See new keywords
below). ECHOtag should match up to the content of TAG keyword.
Once processing for JAM netmail areas are set up (as used with mbse), then
this
is the file that is created for each message so that the same processing can
be
used.
The same will apply to the use of email for sending and receiving elist
updates
or warnings.
The important issue, is to find suitable C type libraries that can be utilised
for the purpose and so far none has been found.
As and when this is implemented each Email will also have a ECHOtag.ECO file
created, again to use the same processes.
New keywords: Where a * preceding is a mandatory keyword - it MUST be
provided.
------------
================================================================
NEWPASS To change an existing password. PASS oldpassword, newpassword can
also be used. This keyword was used for testing and has been left
available.
*LANG Echo language where ENGLISH is the default.
*SUBJect MOD-ADD, MOD-UPD or MOD-DEL and HELP.
COMODn See below for more information.
For HELP (to be sent via netmail, no other keywords are needed other than
FROM
but the file must have the .ECO extension but the name could be anything.
New sub keywords:
----------------
On keyword RESTrictions the following are accepted :
/REAl Real Names only
/SYS SYSops only
New:
/MOD Moderators (and Co-Mods) only
NONE or Blank - No restrictions - Use NONE to remove any others present
and make it NONE.
The restrictions can be cumulative, i.e., you could have /REL /SYS /MOD which
implies:
Only for moderators who have a registered nodelist entry and they must use
their
real names. Do not use the other additional descriptions as those get created
for the ELIST.RPT and the posted report into the ELIST echo after each echo
update.
Keyword Changes:
~~~~~~~~~~~~~~~
COMOD DELETE (or NONE) will delete ALL 4 recorded Co-Moderators.
Useful if a CoMod has become a Mod and/or wishes to clear down dead
entries or specific entries.
This is being discontinued and replaced by COMODn see below.
NEW Keyword that is replacing COMOD
This keyword gives more control for the moderator to amend or delete
a specific CoModerator entry reducing the risk of mistakes.
COMODn Where n = 1, 2, 3 or 4. followed by :
DELETE or NONE will delete specific CoMod entry
or
A valid contact address which will update a specific CoMod entry.
Hopefully this is a better way of controlling Co-Moderator entries.
Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - Element
three
FirstName LastName, Zmmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {,
email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.
The first two are required for responses posted to ELIST and if errors
or expiry warnings direct to the network address.
Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.
Support for Email is not yet available.
Support for receiving submissions via netmail not yet available.
RULES Processing:
----------------
Rules can be provided in one of two ways
1. Recommended by send a rules file with the file name of Echo Tag as upper
case plus extension of .RUL, i.e., MBSE.RUL
It can be ANY number of lines but each line must not exceed 75
characters
but can include blank lines for readability.
(for those Bulletin Board Systems that have such restrictions).
2. Sending as part of a MOD-ADD or MOD-UPD file where the rules text lines
follow immediately after the keyword RULETEXT and before the last line
which is the terminator '---' or '-+-', or the end of the file.
Again blank lines can be embedded within the text.
Note the same text block can be transferred to a ECHOtag.RUL file as is
but without the terminator line '---' or '-+-'.
In any event all RULETEXT content is transferred to a ECHOtag.RUL file
overwriting any existing file.
All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD
or
MOD-DEL.
These files must be sent as echo tag name as the filename, for example the
echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.
Note that any moderator and this includes a co-moderator can submit a MOD-UPD
or
MOD-DEL providing they are on record as one, in the echo being changed. This
is
so that if the moderator has a major system problem or leaves the network for
any reason, another can take over and send a MOD-UPD submission even as a
one off.
A moderator taking over from a previous one should get the existing moderator
to send in a MOD-UPD with their contact address as a CoMODn (1 thru 4) and if
all are in use just over write one of these entries.
After that is sent in and acknowledged, the new moderator can send in a update
MOD-UPD containing their contract address details via keywords MOD and with a
keyword COMOD1 DELETE to remove the previously created entry.
If needed use PASS oldpassword, newpassword to change the existing password or
use :
PASS oldpassword
NEWPASS anewpassword
The password, as a one word string with the letters 0 - 9, a - z, A - Z
and any standard symbol character as found on a standard keyboard using one
key
stroke (shift allowed), i.e., no key sequences using the ALT or CTL keys as
they
can interfere with file processing. Do NOT use a space character as that will
mark the end of the password.
Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.
The password is case specific so ABCD is not the same as abcd which is not the
same as AbCd.
Maximum size is 36 characters.
Note that the slash keys \ and / must not be used in case of file processing
using a database such as Mysqld or Mariadb etc and no they do not like them
for some reason.
A Reminder, a change of password can also be done using the PASS keyword i.e.,
PASS old-password, new-password Note the space after the comma ','.
Examples for change of moderator - the current moderator sends:
SUBJ MOD-UPD
FROM 1:345/6
TAG echoname
PASS current-password {can also be current-password, new-password}
GROUP FIDO
COMOD1 new moderator Contact address, etc, Fred Blogs, 2:234/5,
fboggs@gmailcom
Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged:
SUBJ MOD-UPD
FROM 1:234/5
TAG echoname
PASS password [ using the currently existing password ]
NEWPASS newpassword If needed.
or use
PASS old-password, new-password
GROUP FIDO
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]
COMOD1 DELETE [ to remove all comod details as should not have a
duplicate address if not done by previous
moderator. ]
For subsequent updates then change PASS to reflect the new password after
receiving an acknowledgement message via ELIST or netmail.
Remove the NEWPASS and COMOD entries, adding any other keywords that require
changes if any.
There is one abnormality in functions found in that in the event of a
Moderator
leaving the network (Fido or another) without having a co-moderator then
there is no simple way of changing by a new MOD-UPD file that can be used to
change the Mod to another without a security risk unless the Co-Mod has a
copy of the MOD-UPD file that acts as a back up if something occurs with the
Mods hardware or leaves the network for what ever reason.
It is recommended that all Moderators have a least one co-moderator for each
echo area along with a copy of the current MOD-ADD and MOD-UPD file.
Therefore the only other way is to send in a msg via ELIST echo to the
Elist maintainer to manually change her/him to another so that all Mods can
see
the request and if needed, object to such a request and this will help prevent
echo hi-jacking, I hope.
Again:-
This hopefully will be the only reason for using the MAINT function unless I
or
some one else can come up with another solution other than all moderators have
at least one CoMod who is given a copy of the current MOD-ADD and MOD-UPD
files
or records, so in the event of a major problem with the current moderator such
as hardware, health or left fido then another can easily take over even if
only
for a few months while the problem/s are sorted out.
Yes, I have written it twice!
Expiry Warnings
---------------
Up to four are issued with the first one sent to moderator on record and in
ELIST after six months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD UPDs
processes
have finished close to 23:45 on the 1st of the month.
Warnings 2, 3 & 4 (the final) is sent to the moderator and all Co-Moderators
on
record at their registered netmail address as well as in ELIST.
These will be issued during the WARN run, which will happen on the first of
each month close to midnight and after the last run of UPDATE has completed
say
by 23:50 on the same day or the last day of the month.
If an update has not arrived at the elist maintainer before the end of month 5
then the echo WILL be deleted with the tag and title transferred to the
ELIST.NO
file.
Reminder:
Any registered moderator including Co-moderators for a given echo can send in
MOD-UPD .ECO file and/or a Rules file.
Note that the content of a MOD-UPD only requires at a minimum the following
keywords :
FROM
SUBJ
TAG
PASS
GROUP FIDO
Providing the contact address in the FROM keyword is one of the registered
moderators then the Update will be considered valid proving there is no errors
within any keyword or secondary parameters.
Note that each MOD-ADD, UPD or DEL is validated for correctness and if any
errors are found the request is rejected with a message regarding the
problem/s
found, sent to the sender's netmail address (as on the FROM keyword) and the
ELIST echo.
System Data Limits :
==================
Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - UPPER CASE
Echo Title - 72 characters max - Mixed case.
Echo Volume - A monthly figure not exceeding 9999, please be realistic
e.g., 50.
Echo Restrictions - 72 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text.
Any other text can be mixed case.
Echo Distribution - 72 characters. Any text.
Echo Gateway - 72 characters. Any text
Echo Lang - 16 characters - any case but converted to UPPER CASE -
Default = ENGLISH
Echo PASSword - 36 characters Mixed case, A-Z, a-z, 0-9 and any symbol
using a standard 105 key keyboard, i.e., no ALT
combinations
but not \ / or space.
All sizes assume that one byte equals one character so use a standard
character
set as the software does !
elist Operations mini version
-----------------------------
The elist program consists of three primary processes driven by one to four
parameters namely -
REPORT Run monthly on first of the month 23:50
WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been four
warnings issued over a four month period after the 6 month time
period
since the last MOD-UPD (update) has been received.
This means that no echo will be auto deleted unless there has been a
minimum period of 6 + 4 + 1 months from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month 23:45
UPDATE Run one or more times per day with the last at 23:40.
There are other processes that are not described they are under test or
security
or just have not got around to it until completed.
The emaint program has only one process.
Run Interactive Maintenance only as needed.
This will add, update or delete an existing echo entry as needed.
For those that are interested or not, here is the last 20 version update
notes:
5.1.000 1st beta release. Change mbse Echo and netmail areas to
production areas.
.001 Forgot to remove the testing tag displays in FA105.
.002 During a Rules create/update WS-No-Care3 was not
cleared
after use in FA260 when used with log-Msg.
.003 Chg ELIST-NOM rec to have ELIST delete date and if
> 365 days old delete it. EA250-Produce-NO-File
.004 CREATE A ELIST DB file clean process to :
copy file recs out to temp file and reload
Do same for Elist-NOM as well - on request.
24/03/20 vbc .005 For a sub that has extension of ECOMOD-UPD or ADD
the ws-Flg-SUB flg is not been set. Fixed. Any later
SUBJ will as always over ride any previous setting
the same as any other duplicated keyword.
Change to EL212 to include the mandatory keywords.
.006 In .005 fix forgot to remove clearing WS-Subject.
.007 Rem'd out the msgs archiving as init testing complete.
Test on skip-password with old and new record wrong
in FA170
.008 In FA122 and tests for REST added extra for any other
text after tests for /SYS /REA /MOD which hopefully
will find any other sundry information text.
.010 Not reported correctly in BA032 as forgot to add the
new code in .008 to it. Nope should be a simple move.
25/03/20 vbc .011 Changed tests for .ECO content to report when none
to log file in FA098.
26/03/20 vbc .012 Test for Missing SUBJ keyword (EL224) with the
other mandatory keywords.
.013 Extra msg EL237 & chng text for EL224 for Subject
After junk in log-msg for EL224 when subj missing
in a submission.
Change display at to a log-msg need to do the others.
.014 Adjust slightly unknown keyword del on " " as well
and check for --- or -+- at unknown keyword section.
Trim out 2nd word in FA120 skipping leading spaces.
.015 At end of unknown keyword goto was wrong (FA015)
29/03/20 vbc .016 Support for sleep time in UPDATE def = 3600 if
invalid. Delete all ECO files at end of FA000-Update
from the file list records so that any fresh ones
will get processed next step run.
30/03/20 vbc .017 Program change for elist-maint now emaint.
Additional code for:
1. Support to allow param 4 P-D as a number of seconds
to sleep for a UPDATE re-run when P4 = RERUN.
and =nnn present for a count of nnn.
02/04/20 vbc .018 2. Support for UPDATE re-run for minutes past the hour
based on value in P-D adjusted at last time finished
so that the rerun will occur at the same minutes
past the hour. Default set as 30 See AA032 & prior.
Bug found when tag.ECO does not match keyword
TAG value does not update during UPDATE run.
Changed FA122 Tag process & inserted FA107-Reload.
Added extra line in ELIST.RPT for warning count
if non zero.
if param 3 = FULL-REPORT then ELIST.RPT contains
content of the rules file if present.
.019 Bug: RERUN is working without the RERUN param.
Hopefully fixed in Tag check in FA120, FA122, FA107.
03/04/20 vbc .020 Nope still reread the same data? so clear rec before
read. THIS IS GETTING very odd!
.021 Re-opening the wrong file, der.
.022 IN BA not acting on WS-Warning-Flag-Set (1) but not
really needed. Added at end of reports Warning count
message if > 0.
.023 Error in REPORT for warnings not space filled before.
04/04/20 vbc .024 Need to open elist-log in UPDATE if closed when in
Rerun mode.
Before usage of "CC:" for emails WS-Msg-Addr-Email
WS-Net-Email was not being spaced.
.025 Clean up logic of UPdate processes in AA032 with
required extra steps and running needed scripts
along with extra tests for a Friday to run build.elst.
.026 Added elist backups to weekly Friday processing adding
to first of month.
Consider converting main file processing to RDBMS (Mysql?)
would allow more group data manipulation, i.e., in SQL.
Updated 2020/04/04 Vincent Coen. 1:25/21 & 2:250/1, vbcoen=at=gmail.com
--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
|