Subj : Submission Help File To : All From : Vincent Coen Date : Sun Apr 05 2020 15:51:02 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) .