@DATABASE "REVIVE" @Node Main "ReVive, v2.20 for CNet Amiga 3.05c by Dotoran of Frontiers!" ____ _____ ____ __ ____ _____ /ÿ_ÿÿ/\ /ÿÿ__/\ /ÿ/ÿ/\ /ÿ/\ /ÿ/ÿ/\ /ÿÿ__/\ /ÿÿÿ_/ÿ/ /ÿÿ__/\//ÿ/ÿ/ÿ/ /ÿ/ÿ//ÿ/ÿ/ÿ/ /ÿÿ__/\/ /_/\_/\/ /____/\/ \__/ÿ/ /_/ÿ/ \__/ÿ/ /____/\/ \_\/\\/ \____\/ \_\/ \_\/ \_\/ \____\/ Version 2.20 @{" Why Bother Using It " link WHY} @{" Installing The First Time " link INSTALL} @{" Upgrading v2.x to v2.20 " link UPGRADE} @{" How Do I Use It " link HOW} @{" What Exactly Is It Doing " link WHAT} @{" Can I Modify How It Works " link MODIFY} @{" Alternate Use For ReVive " link USE} @endnode @Node WHY "Why should you use ReVive?" Answer these questions: - Did you ever delete a user, but then wished you hadn't? - Did AutoMaint delete a user you were meaning to reevaluate? - Did your Amiga clock ever get screwed up, only to have AutoMaintenance obliterate gobs and gobs of users, because they "seemingly" hadn't called in "x" number of days? - Ever have a user gain SysOp Access on your board, who then presumed to play GOD by killing off users they had a grudge against? - How about a CoSysOp who turned on you, and decided that their way was the best way, so did away with the underlings who didn't follow their flag? If you can answer YES to any of the above questions, then this file is definately for you! Read on to find out more information as to how and why you should be using this file! @endnode @Node INSTALL "How to install ReVive, v2.20 for the First time?" To install ReVive, v2.20 into your CNet Amiga v3.05c version, follow these steps: 1: First, check to make sure you have all the files: ReVive - This is the main ReVive SysOp Utility. ReViveDBM - This is the ReVive DataBase Manager/LogOff Utility. ReVive.guide - This is the file you are viewing presently. ReVive.history - Lists changes, additions, etc. that have been made. 2: Copy both the "ReVive" and "ReViveDBM" files into your pfiles section. I recommend placing them in your "pfiles:maintenance/" path, so as to be away from those directories which may be accessable by your general user populace. 3: Set the values of the 4 variables found in the "ReViveDBM" file BEFORE continuing with the next step. (See the @{"Can I Modify How It Works" link MODIFY} section for more info). 4: Use one of those "RUN" commands to run the ARexx file "ReViveDBM" from within CNet proper. If you don't have an ARexx RUN command, then add in the file manually as a SysOp Only pfile. (You should then REMOVE the entry once you've run the file once). When run manually with no arguments, as you are doing now, the following will take place: - The initial "ReViveDB" file will be created in your "SysData:" directory. - A "mirror" image of your "mail:users/" directory can be created in the directory specified in the "users2" variable. (See the @{"Can I Modify How It Works" link MODIFY} section for more info. When the file states that it is "done.", you should then remove it from your system(if you added it as a pfile). This will make sure a user has no way of accidentally executing the file later on(nothing bad would happen if this should occur, but the process takes awhile, depending on the size of your system, upon which the user will have to wait until the process had completed, before they could continue). 5: Now, load your "cnet:bbstext" file into a text editor and go to line 99, which looks like the following(in the stock CNet 3.05c bbstext): @ Logoff complete\n1 ^ Control-Y Being as numerous other types of pfiles often locate their launching commands from this line, you'll no doubt also see some other commands located here as well. You need to add the following launch command in FRONT OF ANYTHING ELSE ON THAT LINE: {#0 pfiles:maintenance/ReViveDBM 1} ^ ^ ^ | | | Control-Q ---' `----- These are SPACES -----' So, when completed, the new line 99 should look like this: @ Logoff complete\n1{#0 pfiles:maintenance/ReViveDBM 1}... Where the "..." were any other launch commands you may have on that line. Make sure you include the two SPACES in the line. The first one isn't all that important, but you MUST include the second one, or you will be given an error message stating it can't find the file. Save your bbstext file, then exit the editor. 6: Alright, now let's add a new command to your bbsmenu file. Load your "cnet:bbsmenu" file into a text editor, then go to the BOTTOM of Menu number 2, the "Available Everywhere" menu. Add the following line: REVIVE `31 | {#0 pfiles:maintenance/ReVive} ^ ^ ^ ^ ^ | | | | | | | | | `--> This is a SPACE character. | | | | | | | `-----> This is a Control-Q character. | | | | | `---------> This "pipe" symbol is created using the | | "shift-backslash" keystroke. | | | `---------------> This is the Access Group that can use | ReVive. Use the back-apostrophe symbol, | located above the TAB key to start this | range. | `----------------------> This is the actual command name, and should appear in ALL CAPITAL LETTERS. Save your bbsmenu file, then exit the text editor. 7: Now you need to RELOAD the two text files. It is NOT neccessary for you to reboot your copy of Cnet if it's already loaded. You can simply click on the Control-Panel window(to activate it), then press the RAMIGA-T key combination. (You could also do this by selecting the "Text/menu reload" option found on the "CNet" menu of the Control-Panel screen). 8: If you choose a value of 2 for the "mail" variable in the ReViveDBM file, then you will also need to create an EVENT within CNet's Config. (See the @{"Can I Modify How It Works" link MODIFY} section for more info on the "mail" variable. Here's how the event could look: Command: RunARexx Args: pfiles:maintenance/ReViveDBM 2 (Remember the SPACE) [port(s)]: 0 (whichever works for you) Type: Immediate--force system idle Days: Check All Seven Time: 300 (This is 3AM in the morning) Valid: 100 (Tries to run between 3 and 4; 1 Hour) Interval: 0 (Only runs once, so no interval needed) Iterate: 1 (Again, run it only 1 time) 9: That's it! You're done! @endnode @Node UPGRADE "How to Upgrade v2.x to v2.20 ReVive?" If using v2.0 of ReVive, follow these steps BEFORE upgrading to v2.20: Click @{"HERE" link UPGRADE210} if presently using ReVive, v2.10. A new variable has been added to the ReVive and ReViveDBM files. If you chose to modify the "users2" variable located in these files to a path OTHER than "mail:", you will need to MOVE the "users2/" directory from your "mail:" directory into this new path you've specified. You can do this in one of two ways: - You could manually COPY, then DELETE (or MOVE) the entire directory from "mail:" to the new location using either a CLI or some other disk processing program(like Disk Master, Directory Opus, etc.) - Or, you could DELETE the "users2/" directory from within "mail:" and let the ReViveDBM file back up the directory itself(when performing the next step). Both methods work; do whichever is easier for you. One of the bug fixes involved with this version of ReVive requires you to recreate the ReVive database, so it will be neccessary for you to DELETE the "ReViveDB" file located in your SysData: directory, then recreate it using the ReViveDBM file. (Run it as an ARexx pfile from within CNet). If you chose to DELETE the "users2/" directory above, instead of COPYING or MOVING it to the new location, then this file will then backup the USERS/ directory into the USERS2/ directory at your designated path. That's all there is to updating to the 2.10 version. Click @{"HERE" link UPGRADE210} to continue the upgrade to ReVive, v2.20. @endnode @Node UPGRADE210 "Upgrading ReVive, v2.10 to ReVive, v2.20!" If using v2.10 of ReVive, follow these steps to upgrade to ReVive, v2.20: You'll need to DELETE your "ReViveDB" file(located in your SysData: directory), then run the ReViveDBM file again to recreate it. One of the bugs in v2.10 created holes in your database that resulted in MISSING user info, so you'll want to recreate the database from scratch to insure it is complete! Be sure to read the @{"Can I Modify How It Works" link MODIFY} section of this document to find out how to use an added value to the "mail" variable, as well as the new "kill" variable, which may be able to run ReVive on your system more efficiently. That's all there is to updating to the 2.20 version. @endnode @Node HOW "How do I use ReVive, v2.20 on my System?" Whenever you suspect a user account has been deleted mistakenly, you can load the ReVive file simply by typing the command REVIVE from any command prompt within CNet. After being asked if you wish to view the instructions, the file will ask you which account number(s) you wish to revive. If you're not sure of the account number, just hit ENTER/RETURN at this prompt, and ReVive will scan all your user accounts looking for deleted accounts. It will then display to you a listing of deleted account numbers and will ask you again which account you wish to revive. Typing a "Q" for this question will exit the file without attempting to revive any user accounts. Once an account ID Number has been given, the file will examine the user account in question, as well as querying the ReViveDB for info also pertaining to that account and will then display this information on the screen for your perusal. It will then be neccessary for you to make the determination as to whether or not the data in the account goes with the data found in the ReVive database. If the two data match, then it's safe to revive the user account and you can answer YES to the "ReVive this account" question, but if you see that the data between the two does NOT match, then you should NOT revive the account(else this user will inherit someone else's stats). If you enabled the "User Mail BackUp" option, and answered YES to the above question, you'll then be asked if you wish this user's mail directory contents to also be revived. Once the above has been completed, the file will either go on to the next account to revive, or will proceed to ask you the location of your POINTERS file(it defaults to "pfiles:maintenance/pointers", as this is the path most SysOps store this file). The POINTERS file needs to be run to recreate the index files that contain the active handles used on your bbs. This final step insures the bbs will be able to locate the recently ReVived user by their HANDLE, as well as by their User ID # and Real Name. Once the POINTERS program has completed, the program will exit. You can specify RANGES of user id numbers to revive directly from the inital question, so stating something like: 10,15,28,101-103 Would attempt to revive user account id numbers 10, 15, 28, 101, 102, and 103. Checks are made on each account to insure it IS a deleted account before an attempt to revive it is made as well. Lastly, if you know the account id number(s) you wish to revive BEFORE you load up the program, you can supply them as ARGUMENTS to the command as well. For instance, using the example accounts above, you could type the following at a command prompt within CNet: Main> revive 10,15,28,101-103 That's all there is to USING the program! @endnode @Node WHAT "What Exactly Is ReVive, v2.20 doing to my data?" This file modifies data stored in your "bbs.udata" and "bbs.sdata" files, both of which are located in your "SysData:" directory. Here's a breakdown of exactly what occurs during a run of this file(for those who may be curious, or weary of heart): First of all, perhaps a description of the database is in order. One of the initial installation steps you did created the file "ReViveDB", which is also located in your "SysData:" directory. This file contains three pieces of information pertaining to each user on your bbs. Their serial id number(unique), their handle, and their password. Because this file contains password data, it has been encrypted(in case someone should get ahold of this file. It will be useless to them unless they possess both a fair amount of ARexx knowledge, as well as a copy of the encryption key). Before anything else is done, the following events occur: - The total number of user accounts(current & deleted) is pulled from the CNet memory. - The current values of the "bbs.sdata" file are read into memory. It's the second item in this file we're interested in(the total number of "in-use" accounts you have). Alright, once an account id number is given to ReVive, it will undergo the following series of events: - It will pull the above mentioned three items from the DB that pertain to the id number specified. - From the actual user account, the real name, street, city & state, zip, voice phone number, data phone number, last call date, and the uucp mail directory name will be pulled. - The current year(2 digits), month and day are also pulled from memory. You are then presented with this information for approval to ReVive the account. If you state YES to revive the account, then the following will then occur: - A directory will be created in the "mail:users/" directory to hold this user's mail. The filename used will be the "uucp directory name" that was pulled from the account above. - The handle, password, and serial id number read from the ReVive database is then written directly to this user's account in memory. - Their last call date is then updated to reflect today's date. - The account is then written to disk for permanent use. - The number of "in-use" accounts is incremented by one. This new value is then placed BOTH in CNet Memory as well as being SAVED to DISK inside the "bbs.sdata" directory. (Note that you won't see the updated value appear in CNet's Control Window until AFTER you've either resized the window or collapsed it into it's icon, then reopened it. The same quirky nature occurs when you KILL a user account using CNet's built-in VDE editor) If the "Backup User Mail Dir" option is enabled, and you specify YES to the "revive mail dir" question, then this final step will be taken: - The files found in the "mirror" user directory("users2/") directory will be COPIED INTO the same directory in "mail:users/". - The file then either exits or continues on to the next user account to ReVive. Whenever a user logs off of your bbs, two things will occur: - Their serial id number, handle and password are compared to those found in the ReVive database. If any of the three are found to be different, then all three values are resaved to the database file. - The contents of the "mirror" image mail directory for this user are deleted(if the "kill" variable is set to 1), and the current contents of their mail directory are copied to the mirror directory. And THAT'S exactly what happens during usage of this file! @endnode @Node MODIFY "Can I modify how ReVive, v2.20 does it's work?" There are four variables located at the top of the "ReViveDBM" command file that will allow you to control how the file does it's work: mail - This variable can hold one of three values: 0 = No, upon which the user's mail directory would NOT be backed up into the alternately specified "users2/" directory. 1 = Yes, at Logoff. The user's mail directory will be backed up every time they log off your bbs. 2 = Yes, at AutoMaint. Your bbs will back up ALL USERS mail directories once a night, during automaintenance. If you choose to use the "mail" variable, a "mirror" image of your "mail:users/" directory will be made in a directory called "users2/". This directory will hold ALL files found in ALL user uucp directories on your system. I highly suggest using this feature if you have the room on your hard drive. Estimates as to how MUCH room you'll need on the drive will vary, depending on how many users you have, and what kinds of things you have to offer your users. Five megabytes free would be a good idea. (I use a bit over 2 MEGS for my 207 user accounts presently) Of all the pieces of information that are LOST when an account is deleted, it is the MAIL directory which can cause the most grief, as this directory holds a lot more information than just the user's mail. Things like: user signature files, their ud select buffer, network alias file, custom dictionary file, config files for other pfiles(wof, supertags, games, etc.), any files they may have SAVED (using the .PUT command in an editor, or using the SAVE command off the OLM command line), as well as the file that houses information pertaining to which message and file subbases they chose to be JOINED or DROPPED from. kill - This is a NEW variable in ReVive, v2.20. The kill variable acts as a toggle as to whether or not you wish the user's backed-up uucp mail directory to be KILLED(or DELETED), before it is backed up again: 0 = No. By NOT deleting the user's backup up mail directory each time the file runs, you'll lesson the amount of fragmentation that appears on your hard drive, however at the cost of running the possibility a user's mail directory could GROW in the number of files contained within the directory. This could result in the user obtaining "outdated" data files in their mail directory if and when it became necessary to ReVive their account. 1 = Yes. By deleting the user's backed up uucp mail directory contents before creating the new backup, you'll insure that if and when the account needs to be ReVived, that the user will regain their most recent mail contents. The drawback here, though, is that with the amount of deletions that will occur, your hard drive will become fragmented in a faster amount of time than "usual", so you'll have to get into the habit of "defragging" your drives more often than you may be used to. One possible way to avoid this might be to only run your event once a week or so, instead of daily, as given above. skip - This variable can either be a null value(using skip=""), or can contain a series of id numbers, each separated with at least one SPACE character, for instance: skip="1 2 5" This variable allows you to specify which user accounts you wish NOT to have their UUCP Mail directories backed up in. I included this variable for those who may be using other backup types of programs pertaining to backing up SysOp Info(which might also include their mail contents). If you're not sure which accounts may be getting backed up elsewhere, I suggest keeping this variable set to a null value(skip=""). If you chose a setting of "mail=2" above, this variable is moot, as ALL user accounts will be backed up in this event. users2 - This variable allows you to specify the path in which the uucp mail backup directory "users2/" will be created. In the previous version of the program, this was hard-coded to reside in the same "mail:" directory as the main "users/" directory. However, I got to thinking, "what would happen if the drive containing this mail directory should go down for some reason?" You'd lose not only the original mail contents, but the backup directories as well. It is HIGHLY RECOMMENDED that you specify a DIFFERENT PHYSICAL PATH to the "users2/" directory than is used to house the "users/" dir. NOTE: This variable ALSO APPEARS at the start of the "ReVive" file, so be sure the contents of this variable are EXACTLY the same, else the program won't be able to lock on to the directory when it needs to. @endnode @Node USE "Here's an alternate use for ReVive!" How many times have you had users send you feedback from the logon prompt asking you what their password was? Have you ever logged onto another bbs(a multi-line bbs), and had one of your users, who also happened to be online, send you an OLM asking you for their password? If you tell ReVive you wish to revive a user who has NOT been deleted, you'll be told this, as well as being shown that user's handle, real name, and PASSWORD. You can use this feature of revive for a faster way than having to manually enter the appropriate screen on the appropriate VDE screen within CNet. All it takes is: REVIVE #, where # is the user's ID Number! @endnode