HomeWare 14

home *** CD-ROM | disk | FTP | other *** search

/ HomeWare 14 / HOMEWARE14.bin / bbsutils / wkly1092.arj / INSTALL.DOC < prev next >

Wrap

Text File | 1992-10-25 | 20.5 KB | 482 lines

10-25-92 Note from the author: As of this date, I am making this program totally shareware, with no crippling, no registration keys, and no hassles. Feel free to use this software for up to 30 days to evaluate it, if you continue to use it past the 30 day evaluation period, you must register it. There are no extra features that registration enables, nor will you need to call my BBS to get the latest versions - future versions will be released just as this one has. If you like this software, then please register it - it will allow me to continue improving the product. I have a number of other PCBoard related projects in the works, and the registration response to this product will determine how future products are released. The registration fee for Weekly Limits is $25 (US). Registration fees, suggestions, or comments should be addressed to: Robert Briggs c/o Bob and Kathey's BBS P.O. Box 571241 Murray, UT 84107 ----------- Robert Briggs 25 October 92 ---------------------------- ****************************************************************** * * * Weekly_Limits * * REGISTERED VERSION * * * * Copyright (c) 1992 * * Robert Briggs / Info-Tech * * * * * * Software designed to allow the PCBoard version 14.5a * * sysop to implement WEEKLY time and byte ratios. This * * is NOT shareware - do not re-distribute !! Thank you * * for supporting this product by purchasing it !! * * * * Support BBS: * * * * Bob and Kathey's BBS * * (801) 262-3822 * * 2400 - 16800 HST * * FidoNet 1:311/11 * ****************************************************************** ------------------------------------------------------------------- Upgrade installation -------------------- Be careful NOT to overwrite your current executables or config file just yet, since logon.exe, logoff.exe and weekly.cfg (or whatever you are calling it) need to be replaced simultaneously, and with no callers on-line... NOTE: These upgrade instructions ASSUME that you have the evaluation copy installed and functioning. ■ Copy your current logon.exe, logoff.exe and weekly.cfg files off to a safe place. ■ Extract the program wkconfig.exe from this archive. Place it into a directory that does NOT contain your current weekly.cfg file. ■ Run the wkconfig program. It SHOULD ask if it needs to create a new configuration file for you. If it doesn't you are in the subdirectory where your old config or some other file named weekly.cfg is located. If you DON'T get prompted to create a new file - hit ESCAPE and exit the config program. Move to a different subdirectory - you need to both create a NEW config file and NOT overwrite your old one yet. Select PATHS, and enter the fully path qualified filenames to your: - users file, - users.inf file, - log file, - reset report file, and - PCBDOOR.TXT (NO path qualifier) for the door text file name. Select SECLEVEL and set up the single security level that your current evaluation copy uses (it was set to 81 in the demo...) You need to set up that security level as: W (weekly), Answer "Yes" to preserve callers upload credits, Set the minimum baud rate for weekly limits to 0, Set the logging level to 8 (maximum verbose mode), and Enter the number of BYTES that the caller is allowed weekly. ■ At this point, you should take all nodes down, or have no callers on-line - DON'T change over the software with a caller on line using a security level that the evaluation copy handled - it MIGHT be harmless, but no sense in deliberately courting trouble.... ■ Copy your new weekly.cfg over the old evaluation copy ■ Extract the two files logon.exe and logoff.exe from this archive, and overwrite your old copies. ■ You may now bring your system back up. Operationally you are at exactly the same point with the registered version that you were with the evaluation copy. You can now change things around at your leisure..... (Snuck the logging level down to zero before you even tried it this way, didn't you Ray?) ------------------------------------------------------------------- Recent additions ---------------- ■ The logon.exe file CAN be run in $$logon.bat rather than as an auto log-on door, if you prefer. The only problem with this is that the caller does not get the settings display with his period expiration date and some other info. If you don't care about that, then feel free to run logon.exe in $$logon.bat. A config option is provided for the name of the info display file that is created - this allows you to display it to the caller in some alternate manner if you decide to go the $$logon.bat route. The text is normally output to the file PCBDOOR.txt (when run as an auto log-on door) and automatically displayed to the caller by PCBoard when it returns from executing the door. If you go the $$logon.bat route, it is up to you to display this text file to the caller, if you so desire, in some alternate manner. Running in $$logon.bat can be easier than setting up several auto log-on doors, and are no problems with a caller that discovers the name of the door executing it and getting his time limits and download byte limits reset.... ■ According to several message on SaltAir, you may have a single $$logon.bat and $$logoff.bat file somewhere on the search path. It is not necessary to have separate files in each node sub- directory. ------------------------------------------------------------------- The balance of this document is the same as the installation guide contained in the evaluation copy. See the file config.doc for more information about various configuration options that are available to you using wkconfig.exe...... ------------------------------------------------------------------- This document is little more than the notes I used during the development of weekly_limits. It presumes that the SYSOP reading it has great deal of knowledge about the workings of PCBoard in general - it is NOT for the novice. In places it pre-supposes knowledge of PCBoard utilities, like PCBSM or PCBSETUP. In any event setting up weekly_limts is NOT like setting up a game door - bang, bang, quick batch file, and two minutes later it is set up and running. If you know your way around a PCBoard system, you can probably set the entire thing up in 5 minutes........ PLEASE print out this file so that you have it available while you are going through the installation process... You may or not know that good documentation takes longer to write than the program it describes. I have been investing my efforts into the program rather than the documentation. I'll clean up my act in the near future, honest ! <sigh> Both logon.exe and logoff.exe are fairly small and load quickly - they are written in fairly optimized C code (I don't write anything else) and are optimized for SPEED. ------------------------------------------------------------------- INSTALLING WEEKLY_LIMITS ------------------------ 1. This step must be done with all nodes down. Execute PCBSM from any convenient spot. Select option D - User Info File Maintenance, then from that menu, Select option C - Add/Update Third Party Application Add the following TPA : Name : WEEKLY_LIMITS Version : 1 Static Size : 80 Dynamic Size: 0 Keyword : - leave blank - Press page down to have PCBSM install the TPA area in your users.inf file. Please check your spelling - the name must be exactly as show above, the two words "weekly" and "limits", with an underscore character between them..... Do not fill in a key-word...... 2. Back up your USERS and USERS.INF files (as long as you have everything down anyway, might as well - How long HAS it been since you did ???) At this point the system can be brought back on-line, but you may want to keep it down for just a few more minutes - you have to set up an auto log-on door and fix up your $$logoff.bat files for all your nodes at the same time before any callers use the system. 3. I personally like to keep all of my files in separate directories, so.... Create a directory to hold the weekly_limits files. Put the archive file there, change to it, and unzip the archive. Remeber where you put it - you will need to specify the path to the files logon.exe, logoff.exe, and your config file later on in the installation process. 4. Edit the file weekly.cfg with any convenient ASCII editor. As an attempt to save some time when the weekly_limits software is running, you have to specify the full location of your USERS file and USERS.INF file. Edit the item following the keyword USERS so that it points to your USERS file. Edit the item following the keyword USERSINF so that it points to your users.inf file. Both of these are typically located in a directory called MAIN Edit the item following the keyword LOG, so that it points to a fully "path qualified" file name. Weekly_limts will keep its operation log there. At the current time this log is somwhat verbose - you may want to check and delete this file from time to time..... Edit the item following the keyword REPORT so that it points to a fully "path qualified" file name. When callers set up using weekly limits "roll over" to a new week, a report of their previous weeks time used, bytes uploaded, and bytes downloaded is entered into this file. Edit the item following the keyword SEC. There are three fields following the SEC keyword - edit them to suit your needs. The first field is the security level that is to be done with weekly limits. (You will also need to set up an auto log-on door for this security level, later)... The second field is a number between 0 and 6, and specifies the day of the week that weekly limts are to be reset. I personally use Monday (1).... The third field is the number of bytes a caller at that security level is allowed to download in a week. Do not use any commas in this number. Save your edited file. Remember where it is, you will have to specify a path to it later. 5. Set up a SHELLED auto log-on door for the security level you specified in the weekly.cfg file - it does not need users.sys or door.sys. (I use the name WEEKLY for mine, which means that the file I need to edit in the next step is named "q:\doors\batch\weekly". I also hide that door from the caller - none of my auto log-on doors appear in my doors menu. 6. Edit the batch file that the auto log-on door will be executing. It will NOT have a .BAT extension, and will consist of a SINGLE LINE: path_to_where_the_file_is\LOGON.EXE name_and_path_of_config_file. The "name_and_path_of_config_file" is the fully "path qualified" name of the file that you edited in step # 4 - weekly.cfg. If you place the config file in a directory that appears on your path, such as \pcb\main, it isn't NECESSARY to specify the path to it, but DOS will spend some time searching the path for the file. Weekly limits will run a bit faster if you specify the full "path qualified" name of the config file. The "path_to_where_the_file_is" is the directory that you unzipped the weekly_limts software into back in step # 3. On my system, the file WEEKLY, stored where I have my door batch files, q:\doors\batch, looks like this: q:\doors\weekly\logon.exe q:\doors\weekly\weekly.cfg THIS IS ALL that need to be contained in the batch file, but you can end it with a line that says EXIT if you like. This is a shelled door so you MUST NOT re-invoke your board.bat batch file! Same note as for the config file - if you place the files logon.exe and logoff.exe in your "search path", you don't NEED to specify a path to them. DOS will search the path for them - but this can be a slower process than if you specify the entire path to the file, especially if you have lots of directories in your search path.... 7. OK - almost done. This last step depends a great deal on how you have your system configured. I personally have each node in a separate directory on drive q: - so on that drive I have a set of directories called "q:\node1", "q:\node2", "q:\node3", etc. Each node subdirectory contains a PCBOARD.SYS file and an EVENT.SYS file. Some of them have REMOTE.SYS files in them, and they ALL should all have a PCBOARD.DAT file in them if you run multiple nodes. In each of these node directories create a file called $$logoff.bat (if you don't already have one). The way that PCBoard operates: It will only look for a $$logoff.bat file in the directory that it finds itself in when it attempts to execute the $$logoff.bat file. It is not possible to have just a single $$logoff.bat file somewhere on the search path and have it execute, because PCBoard will NOT search the path looking for it. If you already have a $$logoff.bat file set up for each node, fine, if none at all, you can create a single one and copy it to each node directory. The $$logoff.bat file, if you are creating a new one, will look just like the batch file that you invoked when you set up the shelled door, EXCEPT that, instead of LOGON.exe, you will be running the file LOGOFF.exe. My $$logoff.bat file looks like: q:\doors\weekly\logoff.exe q:\doors\weekly\weekly.cfg ^^^^^^^^^^ Note the difference from the file "weekly" created in step 6 above. 8. Last step... You have to enter the security level you specified in the weekly.cfg file above into your PWRD file. (Rr files if you have different security levels for each node...) Do this using PCBsetup, selection B - File locations 1 - name of PWRD file. Add the level with the following "twists": In the TIME field, put the number of minutes that the caller is allowed PER WEEK. (I use 500 minutes in mine). This field has a maximum of 999 minutes - meaning you can allow your callers up to 16.7 hours per week on your system. In the K Bytes field, put 0. Yes - that IS correct - zero. The weekly_limits software will handle allowing callers the correct number of bytes according to what you entered in the weekly.cfg file. >> NOW FOR THE HARD PART : >> _____________________ (just kidding) 9. If you had your system down, you can now bring it back up. That is it. Everything from this point on is automatic. Check your log file for operational info.... A couple of last minute notes: ------------------------------ ■ To make sure that callers on my system don't go hog crazy when they first get set up, weekly_limts may cheat the caller out of two days maximum the first time that they log on using weekly_limts. If you have things set up to reset on MONDAY, for example, and the caller first uses his security level on Saturday or Sunday, weekly_limits may stretch their first expriation period out to "a week from the coming Monday". Follow that? If I upgrade a caller on Sunday, and things are set up to reset on Monday, I don't want them using an entire weeks allowance on Sunday and then end up getting another full weeks allowance the very next day. If a new caller gets initialized one or two days prior to the reset day, they get "stretched" out to 8 or 9 days - the first time only. After that ■ If you messed up one of the batch files, so that either logon or logoff can't find the configuration file, a file called either logon.err or logoff.err will be created in the current directory. Keep an eye out for these files - it will indicate that something is seriously mis-configured somewhere. DUE TO A BUG IN QMAIL, if a caller exits the qmail door by typing BYE, QMAIL executes the $$logoff.bat file with most of the PCBOARD.SYS file cleared out. Weekly_limits will leave an error message in the logon.err file complaining that the user record number could not be found. This is harmless, but somwehat annoying. ■ When the auto log-on door returns, it will display a screen similar to the VIEW USER SETTINGs display to the caller. If you have that option (display user settings) on, you probably want to turn it off using PCBSETUP. The display shown to the user is currently "hardwired" - and looks similar to what you would see on R&E.... It will be made a bit more sysop configurable in the near future. ■ If you have some catastrophe happen, and have to remove the auto log-on door, you need to remove the line (executing logoff.exe) from your $$logoff.bat files as well. Logoff.exe will be VERY UNHAPPY if it gets executed, finds the config file, gets a security level match with the SEC option in the config file for this caller, and finds that LOGON.exe hasn't been executed when this caller logged on. (as happens when a caller types BYE in the QMAIL door, and QMAIL executes $$logoff.bat with a cleared out PCBOARD.SYS file). You will find the complaints in the LOGON.ERR file if they occur. In the case of QMAIL, the error messages generated are harmless, but somewhat annoying..... ■ I have been running and tweaking this software on my system for some time now, but still consider it BETA test software. Back up your users file from time to time! ■ The binary config file will also allow you to set "file limits" - allowing a user to download "nn" files in a set period of time (say a year) and expiring the user once that level is reached. ------------------------------------------------------------------------ Both logon.exe and logoff.exe are fairly small and load quickly - they are written in highly optimized C code (I don't write anything else <g>) and are optimized for SPEED. The whole design philosophy has been to assure that they execute quickly enough to be thought of as part of PCBoard, rather than external utilities, by your callers..... I do both custom programming and door writing at reasonable hourly rates.. ===Bob Briggs 30 March 1992 ------------------------------------------------------------------------ THE LEGAL STUFF --------------- Unfortunately in these "sue crazy" days, it is necessary to include the following statements: There are no warranties, expressed or implied, for the use of this program. Neither the author, Robert Briggs, nor Info-Tech will be held liable for any direct, indirect, incidental, or consequential damages resulting from the use of this program. Your use of this program constitutes your AGREEMENT to this disclaimer and your release of the author and Info-Tech from any form of liability or litigation, regardless of cause... ### END ###