= ELIST (2:467/888) =========================================================== Msg : 2894 of 2926 From : Elistmaint 2:25/21 01 Aug 22 00:30:00 To : All Subj : Elist Usage and Help =============================================================================== ELIST Maintenance Programs ~~~~~~~~~~~~~~~~~~~~~~~~~~ These notes are mostly for a new elistmaint administrator of the Elist system and likewise the full Elist manual that provides information for the installation and set up of the full Elist system including supporting software such as the MBSE BBS system along with the compiler for building the elist programs. These notes as a help file are also for moderators and Co-Moderators for the submission of MOD-ADD, MOD-UPD and MOD-DEL files sent direct to the elistmaintainers at 2:25/21. 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. For the echo description you can also provide the optional file ECHOgroup.Echotag.DES Note the periods / full stops. The content of this file is plain text with up to 75 characters per line and up to 15 lines and this is so that many BBS systems can operate that may still have this limitation if they use descriptions at all, as for example MBSE does not although it does support the RULes files. The .DES file replaces the need to use keyword DESC so that, can be removed from a submission file. This file can be used in any BBS system being under current development but any active programmer should advise of this to myself as the Elist programmer and I will ensure that the .DES files are also provided in the monthly archives other wise they will remain for internal Elist processing. 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. At this time, NO suitable software for this purpose has been found. 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 used for file submissions. Failure to proved one of the mandatory keyword will result in the submission being reject with the appropriate Error messages being issued. The same applies to any other errors found but for any Warning messages the processing will continue, providing no Error messages was generated. 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 these get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update. Note a space between these restrictions. Keyword Changes: ~~~~~~~~~~~~~~~ NEW Keyword that replaced 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. Note that a submission file can be sent (with adjusted FROM keyword) from any recorded moderator or co-moderator. This is to safeguard the echo in the event a moderator is ill or left Fido. For this reason it is recommended that all Moderators have at least one co-mod set up for ALL echos that they look after and have a current copy of the echotag.ECO files for Updating and if available the original for adding the echo say with the file name of echotag.ECO-ADD where the update file is echotag.ECO-MOD The extra extension after the word .ECO is ignored by the system but is useful to keep what file does what for a co-mod or mod. Contact Address =============== Formed of three elements separated by commas in the form: - Element one - - - - - - Element two - - - - - - Element three FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address} Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}. Note that Domain is no longer used as serves no purpose these days but is allowed for but, otherwise not processed. So in practice the format is : FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm} {, email@address} Example : Vince Coen, 2:250/1 The first two (name and netmail address) are required for responses posted to ELIST and if errors or expiry warnings direct to the network address to both the mod and any co-mod on record. 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 so no need for the address. Support for receiving submissions via netmail not yet available. RULES Processing: ---------------- Rules can be provided in one of two ways 1. Recommended to 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 one blank lines between other text lines for readability. (for those Bulletin Board Systems that have such restrictions). The restriction of 75 character length is not tested for but you will see the results of such, by text being chopped off after character 75 in all reports and netmails. 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 one blank line can be embedded within text lines. 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 'as is', with no checking of content. Description Processing: [ NEW ] as of v5.3. ---------------------- As the system now fully supports ALL Fido echo's for the BACKBONE using for lists of areas into BACKBONE.NA which can be used for BBS systems that support auto create echo functions, when receiving a new messages for a new Echo area and the BACKBONE.RPT that holds all FIDO areas from the ELIST system as well as all not on that facility that is considered un-moderated. This will also happens for any echo areas that expire and is deleted from the ELIST reporting in that each echo will be moved over to the backbone for those reports and files. The backbone lists will be maintained and owned by elistmaint which currently has the netmail address of 2:25/21. While it will be reported as Moderated by this person, they will in fact not be moderated at all, and will remain only as backbone echo's. As the backbone echos in the main, does not have descriptions listed, the format of the database that holds this information within the elist software has been changed so that details of echo descriptions are no longer held on it but in separate files in the same way that the rules are stored in files named as {echotag}.RUL so is description, but stored in files in the same format (as text files) but with the filename of {Group}.{echotag}.DES - more later. This along with the previous removal of rules has reduced the size of each echo record from 4500+ bytes or characters, depending on the size of the rules to 1024 bytes, a good reduction. This allows the number of echos that can be stored on a restricted storage system running the elist software, even to run on a SD card say within a Raspberry Pi computer although speed will be some what reduced - to put it mildly. As a follow on from this : ------------------------ As of version 5.3 (as used from 5th April 2022) you can also submit one additional file that holds the description text in the same format as the one for .RUL and for this optional file (mostly for the use of backbone echo's) is: This optional file (if submitted), MUST be in the format of AAA.BBB.DES Where AAA = Group name i.e., FIDO, FSXNET etc BBB = Echo Tag name i.e., ELIST followed by the fixed text '.DES' (without the quotes). 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. This extension can also have such text as -ADD or -UPD etc so you could have ELIST.ECO-ADD or ELIST.ECO-UPD (to add or update the system respectively). 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 and FIDO.MBSE.DES for the description. 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 through 4) and if all are in use just overwrite 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. Note you can also send in multiple changes to a echo with the submit files say called ELIST1.ECO, ELIST2.ECO. If needed use PASS oldpassword, newpassword to change the existing password. 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 and not be available on some keyboards. 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. This 'Assumes' that the new moderator knows the password in use. Examples for change of moderator - the current 1:345:6 or co-mod sends: Note that the FROM and MOD must be the same and as in the system record. as ECHONAME1.ECO SUBJ MOD-UPD FROM Bat Man, 1:345/6 TAG ECHONAME GROUP FIDO LANG ENGLISH PASS current-password {can also be current-password, new-password} COMOD1 new moderator Contact address, etc, Fred Blogs, 1:234/5 Note the comma separators between each segment. At the same time send : as ECHONAME2.ECO SUBJ MOD-UPD FROM Fred Blogs, 1:234/5 TAG ECHONAME GROUP FIDO LANG ENGLISH MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ] PASS password [ using the currently existing password ] or PASS old-password, new-password As the system processes all files including .ECO files, in alphabetic sorted order both submission files can be sent in, at the same time. For subsequent updates then, change PASS to reflect the new password if changed. Remove the COMOD1 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 with the current password present. 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 someone 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. Again if a co-mod gets these two files, and they are not in the format of : ECHOTAG.ECO-ADD and ECHOTAG.ECO-UPD they should change them so they are, just in case. Thse files can be submitted to the elist maintainers system at 2:25/21 in this format as the extra characters after '-MOD' or '-UPD' are ignored. Yes, I have written it twice! Expiry Warnings --------------- Updated as of v5.3: Up to ONE is issued with the first one sent to moderator on record and in ELIST after TEN months have lapsed since the last update. This is the reason why the WARN process is not run until all MOD-ADD and MOD-UPD's file processing have finished close to 23:45 on the 1st of the month. Warnings are 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. If an update has not arrived at the elist maintainers system before the end of the issued month then the echo WILL be deleted with the echo transferred to the Backbone system with elistmaint, 2:25/21 as the listed moderator. Reminder: Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file or for that matter a .DES file. Note that the content of a MOD-UPD only requires at a minimum the following keywords : FROM SUBJ TAG GROUP PASS 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. Any problems that cause only a warning message to be issued will still allow the Update or echo addition process to be completed. 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 - 48 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 (Must be first). Any other text can be mixed case. Echo Distribution - 36 characters. Any text. Echo Gateway - 36 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 ----------------------------- Elist Program: ------------- The elist program consists of three primary processes driven by one to four parameters namely - Parameter one: UPDATE Run 24 times per day at 30 minutes past the hour with the last at 23:30 This process will also run WARN and REPORT on the first of each month after any updates on or after 23:30. WARN Run monthly on first of month before REPORT - This process will delete out of time / warning echos where there has been one warnings issued over a month period after the 10 month time period since the last MOD-UPD (update) has been received. In reality, they are not deleted but transferred over to the BACKBONE listings with elistmaint as the new so called moderator. This means that no echo will be auto deleted unless there has been a minimum period of 10 + 1 months + 1 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 after 23:30 after UPDATE. REPORT Run monthly on first of the month after the 23:30 UPDATE and WARN runs. This process create two primary files - for each group under control such as FIDO (using the name ELIST) as ELIST.NA (a list of areas by Echotag name and Title), and ELIST.RPT a details report for each echo in Echo Tag order. This file ELIST.RPT for January and July a more detailed report is generated that includes a copy of any Rules for all echos in both the ELIST system as well as the Backbone with all BACKBONE areas so shown. For non ELIST and FIDO net areas a .NO file that holds deleted echo areas that are held for 12 months before being deleted. In the event that a deleted echo is reinstated the entry in the .NO file is removed. As expired echo's in the ELIST system are transferred to the Backbone and the .NO file is not created for FIDO. Any echo that is deleted by use of a submission file from a registered moderator, the echo is deleted as it is deemed inactive with no postings for a period no shorter than 12 months, it is not transferred to the backbone and not stored in the .NO file - it is gone ! Various housekeeping jobs are then run as well as creating the ELST archive for the past previous month that is then sent to all links of the BBS system. Likewise for all ELIST echo postings by the system. Various back ups are created and stored in a range of other systems when connected, for security. There are other processes that are not described as they are used for system security or testing. Emaint Program: -------------- The emaint program has only one process. Run Interactive Maintenance only as needed by the elist maintainer. This will add, update or delete an existing echo entry as needed or mark a echo as being on the BACKBONE. It also provides optional displayed listing of all echo's in the system where use of arrow down or up can move between the displayed echo's and the high-lighted one selected for examination or change. The following is a List of possible error or warning messages ------------------------------------------------------------- These can appear as a response to a MOD-ADD, MOD-UPD or MOD-DEL submission to the system and hopefully do not need explanations. Most messages are preceded by a letter/number combination however a few do not and these are used with other text messages. All error messages result in the submission being rejected. Some warnings may not, but it is recommended to fix the problem and resubmit. Error EL213 is issued if you attempt to Update a echo that does not exist. Error EL214 is issued if you attempt to Add a new echo when it already exists. These are used to protect if a Moderator was using cut and paste when building a new submission from another echo area and made a mistake with the Echo name. ==> WARNing n of n: This Echo is expiring, please Update. Expiration WARNing n. EL201 ==> WARNing: Echo has Expired & will be Deleted very shortly. EL202 Error TAGname not specified. EL203 PASSword not specified. EL204 Error Messenger (From) is missing. EL205 Error PASSword validation failed. EL206 ==> Expiration Warnings have been Reset. EL207 ==> Pending Delete has been Cleared. EL208 Error Too many COMODerators (only 4 allowed). EL209 ==> Echo has been Flagged for Deletion. EL210 ==> Rules file { TAG name } { followed by one of these 4 messages ] has been Purged. has been Created. has been Updated. Had error when creating - Deleted. ==> Echo Successfully Updated. EL212 Error Missing Mandatory Keywords (FROM, TITL, MOD or SUBJ). EL213 UPD to non existing area - Rejected. EL214 MOD-ADD to existing area - Rejected. EL215 Error Invalid or missing TITLe. EL216 Error Invalid or missing MODerator. ==> Echo successfully Added. EL218 HELP File Requested: EL219 Error Unknown keyword found: EL220 Warning Too many Description lines, Max 15 lines truncated. EL221 TAG {Tag name ] Has been deleted . migrated to backbone EL224 Error missing SUBJect. EL225 Invalid (Co)MODerator given in FROM, Echolist Update. EL228 Error INVALID contact Address in: EL229 Warning Invalid address changed to MODs Name EL230 Errors found in MOD submission, see messages: EL231 Ruletext rejected due to other reported errors EL232 Unknown Echo Group EL233 Error GROUP not specified. EL234 Error Invalid SUBJect EL235 Contact name Invalid These are warnings only but the process has still completed. They are usually preceded by the Echo tag name. Updated: 2022/04/05 Vincent Coen. 2:250/1, vbcoen=at=gmail.com Text, grammar, typo's and updates. 2022/05/05 Removed a reference to sending to 250/1. 2022/06/01 Minor corrections. 2022/07/01 Added Warning and Error messages and minor corrections for processsing steps for WARN, REPORT etc. --- MBSE BBS v1.0.8 (Linux-armv7l) * Origin: Elist Maintainer at 2:25/21 (2:25/21)