OARD SELECTION FLAGS This option is used to globally set the message bases for every user to turn on a message base so the user can use the global read option. The individual user can later turn off the message bases that they don't want to read in a global read. NOTE: If a message base is turned off, then the user will not see any mail in that message base during a new mail scan. So the best bet is turn them all on. Also see explanation under dit userlog/oard Select Flags LEAR ALL USERS HIGH MSG NUMBER This allows you to clear the high message pointer for each user. You should do this if your message base crashes or if you decide to start your message base over. This will set all message pointers to zero. If you wish to clear some bases for ALL users, this can be done also. The overly window that comes up will be the same as the one for Msg Pointers when diting a user except that the last-read numbers are replaced with the word "Bypass". Use the arrow keys and spacebar to mark those bases you want cleared (for everyone) and use "F1" to start it. Those marked 53 Installing Ribbs "Bypass" will not be cleared. This mode is handy when, for example, you decide to stop subscribing to one echo and want to install another echo in its place; you can now clear out just that base so your users start with reset pointers. UMP TO PRINTER Prints the userlog to your path '/p'. At the prompt enter the starting user number. It will dump from that user to the end of the userlog. It will list the username, password, last date on, user level, number of times called, time limit, upload/download count and upload/download Kbytes. DIT USERLOG This will show the first user and allow you to edit that user or select another user to edit. See below for more detailed information.
URGE LOG This will purge (delete) users that you have 'deleted'. Although you have deleted a user while in the edit mode, that user is not taken out of the userlog until you purge the userlog. This is also good for de-fragmenting the userlog. EARCH LOG You will get a prompt asking for a search string. If looking for a user named 'Wilberforce' you can enter the full name, but the first char must be a capital letter. You may enter 'force' and all names with 'force' in them will be listed. The user number will be shown and you can enter that users number to go directly to their entry for editing. 54 Installing Ribbs EDITING THE USER (Example of 'Edit userlog' selection) RiBBS v2.10 Userlog Editor by Ron Bihler +====[ n. of n.]===============================================+ | | | Name: | | | | City, State: | | | | Password: Last on: | | | | Terminal mode: Page pause: | | | | Level: Flags: -------- Time limit: D/load limit: | | | | Expert toggle: Upper case lock: Clear screen toggle: | | | +--------------------------------------------------------------+ | | | Times called: Messages posted: Time used: | | Uploads : Upload K bytes : D/L points: | | Downloads : Download K bytes : | | | +--------------------------------------------------------------+ [Add,[BoardSelect,[C]lear,unel,[Edit,[G]oto,[M]sgPtrs,[S]earch [F1] or [*] = Exit NOTE: You can select any option on the menu line above or move to next user using the right arrow key. You can backup using the (left arrow key). If you select dit, the arrow keys allow you to move through the fields. dit At this point you should change the first user to your name. If you have 'forced full name' you will use a full 2 word name. Note, when logging on as 'sysop' RiBBS will automatically select the first user name in the log. For this reason select a secret password for yourself and change periodically. Additionally if a user leaves a msg. addressed to 'sysop' it will insert your name. To proceed select 'E' to edit the user file. This will put you at the Name option. Enter in your name and enter all the other information that is changeable from the user editor. There are a few options that you are unable to change in the usereditor. For the most part, these are terminal settings the 55 Installing Ribbs user has defined for his communication and personal preferences. Be sure to set your access level to that entered in the 'Rconfig' procedure and set your flags to 255. After you finish with this users file press [F1] to exit back to the menu line. You now can select one of the options to continue or stop editing. This is basically self-explanatory. If you have deleted some users be sure to select the 'Purge log' option. Otherwise, the user will still be able to log on with the 'deleted' in his record header. sgptrs This option will display the user's last READ MESSAGE POINTERS for each Message Base you have available on your system. These pointers are updated for each user when he/she logs off your system. You'll see an overlay window which looks something like this: +--------------------------------------------------+ | --------[ General Messages ]---------- | | Base/MSG Base/MSG Base/MSG Base/MSG | | |--||----| |--||----| |--||----| |--||----| | | ->1. 779 11. 1 21. 12044 31. 2 | | 2. 11903 12. 1 22. 1 32. 1 | | 3. 0 13. 11541 23. 1 33. 1 | | 4. 1 14. 1 24. 1 34. 1 | | 5. 1 15. 11518 25. 1 35. 0 | | 6. 1 16. 0 26. 1 36. 0 | | 7. 1 17. 4908 27. 3724 37. 0 | | 8. 1 18. 1 28. 1 38. 0 | | 9. 9106 19. 331 29. 1 39. 0 | | 10. 1 20. 12634 30. 1 40. 0 | | -------------------------------------------- | | [Arrows]=Change Base [SPACE]=Toggle (un)Cleared | | [A]bort (none cleared) [R]everse All [F1]=Done | +--------------------------------------------------+ The arrow (that is currently pointed at Base #1) can be moved to any of the other 39 bases with the arrow keys. The little window at the top (showing "General Messages" in this case) will change to indicate the name of the base that is being pointed at. The numbers 1 - 40 obviously indicate your 40 message bases. The green numbers next to them indicate the highest message number that you have read in that base. 56 Installing Ribbs You may find it necessary to clear your (or some other user's) high-message pointer in one or more bases. Pressing the spacebar will mark any base number that the cyan arrow is pointing at. The green number will change to a red "Clear". You can unmark them by pressing the spacebar again. The "R" key will reverse the marked status of all bases (this can be handy if you want to clear all bases or if you want to clear all except a few... mark those few and then hit "R"). If at some point, you decide that you don't want to clear any pointers, press "A" to abort the window with no clearing taking place. Otherwise, press "F1"... all marked bases will the be cleared. oard Select Flags Now for the Board Select flags. This is to be used to compliment the feature that allows your users to turn their preferences for one or more message bases "off" so that they are not displayed in the Global Read or the initial mail scan read. Like the Message Pointers, you can edit these flags for each user individually (by using the [B]oard Select option on the Edit Menu) or globally set these flag for all users (by using the Board Select Flags option on the main title screen.) The window used to set/view these flags works almost identically to the Message Pointers window. While editing the flags of an individual user, you can turn each flag "On" or "Off". When using the 'global' version of this window, each base will have "Bypass" next to it. Pressing the spacebar will toggle a bypass setting to "Set". When the program scans through the userlog, it will turn all user's flags for "Set" bases to the "on" status. Those specified to be "Bypass"ed will not be changed. NOTE: This has caused some confusion even among the Betas. You cannot -globally- set flags to "Off"... you can only turn them on (Set) or leave them alone (Bypass). If you wish to set a board select flag to "Off" you must do it in the non-global mode (one user at a time.) Believe me, this scheme makes the most sense... there is no logical reason that a sysop should ever need to globally de-select a board for his users except by using access levels. Just like the Message Pointers, these Board Select flags will be set randomly for all your old users since that part of the userlog was not being used in the older version of RiBBS. For this reason, you should use the global Board Select Flags option when installing RiBBS 2.10 and "Set" -all- forty of the flags to an "on" status and let your users turn off the 57 Installing Ribbs ones they wish to ignore. If you do not take this step, your users may unwittingly miss some private E-mail or some other message meant for them. And (again, similar to the Message Pointers) this global feature can be used when you install a new echo or message base, or replace an old one with something else. lear This option will clear the statistics on the bottom of the screen for that user. oto This option allows you to go right to user by selecting the number for that user. earch This option woks the same as the Search from the mail menu. unel This options allows you to flag a user for deletion. It also acts as a toggle to remove the Del flag if it is set. 58 STARTING RIBBS STARTING RiBBS After you have completed all of the above steps you will be ready to boot up RiBBS and get it ready to go online. The best way to begin is by turning off your computer and re-boot OS9. After your boot-up sequence is complete. The easiest way to startup Ribbs is with a script file. Here is an example: Iniz /r0 - if using a Ramdisk Iniz /w6 - use whatever window you want Chx /dd/bbs/cmds - assuming you have a BBS Exec dir. Chd /dd/bbs/files - assuming standard data path Load RunB RiBBS RMenu - remember our merges? RiBBSMain #16k <>>>/w6& - this fires it up After a few seconds RiBBS will start, if there are any files missing or if you set your data directory wrong, you will get an error. When RiBBS is fully booted you will see a wait screen which looks like the one below. RiBBS v2.10 -- (C) 1993 by Ron Bihler and Charles R. West -- Date: 06/20 09:00 ==============================================================================: : Node : 1:147/61 | Total Calls : 25432 | No Mail this Schedule : : 300 Baud : ON | Calls Today : 1 | : : Mail : OFF | New Users : 5 | : : Chat : ON | Fido Calls : 0 | : : Event : CHAT OFF | Caller : Brian Steward | : : at : 22:00 | Schedule : 1 | : :=============================================================================: RiBBS is now waiting for carrier. NOTE: See APPENDIX A for functions available at this screen. RiBBS is very dependant on memory, and requires the full 64k available per program. RiBBS will pull in and out of memory several modules as it needs them. Multi-Line Ribbs can be started using an Alternate RiBBS.CFG (Configuration File). You simply add the Full pathname as a parameter when starting RiBBS and running Rconfig.IE RiBBSmain /d0/files/ribbs.cfg & Rconfig /d0/files/ribbs.cfg. This will allow you to use different modem, and setup parameters when running multi-line. 59 STARTING RIBBS NOTE: Fido mail programs, as well as most editors will still require you have a /dd/ribbs.cfg. NOTE: There are some problems in the record locking of the message base during a mail scan if another user is in the message areas. Keeping RiBBS in shape (maintenance) RiBBS is a fairly self-maintaining BBS. There are a couple of files that will need regular attention and updating. The most important file is the Userlog. The userlog can be maintained from OS9, or online. Make sure your pxd is the RiBBS cmds directory and the pwd is the RiBBS files directory. Type 'useredit' to begin the program. The userlog editor is fairly self-explanatory and only a few items need clarification. As time passes you will find that all those users who logged on the first time, haven't called back in the past three to six months and are just sitting there wasting disk space and causing your logon sequence to take forever! You will need to delete those users who have forgotten about your board, or haven't called back for whatever reason. First flag those users using the usereditor, then you can purge your userlog and free up those slots for new people to log on and contribute to your system. Another area is the message base(s). If you have limited disk space you will want to watch you message base(s) very close. The file 'packmsg' is what you will need to delete those messages that are flagged for deletion. Packmsg will refer to Rconfig for the amount of days old a message has to be before deleting it. If you specify zero for the number of days, packmsg will delete all messages currently in that message base. 60 PACKMSG PACKMSG The features are: * Packing when size limits are approached * Renumbering when Msg# limits are approached * Large messages copied without truncation * Faster Optimum stage & IDX building * Fast/safe message base residing * TEXT/HDR file size "watchdoging" * IDX file pre-sizing * Frivolously gaudy color display * Enhanced parameter parsing * Built-in Help * "Check Statistics" mode * System Log is updated with packing results Packmsg has a required format to run. The following is an example: You can type "packmsg" with no option flags and pack your message base. It is always best to run this from Events or from the "S"hell option of the RiBBS wait screen - this will avoid conflicts with a running BBS. Also, it is essential to have Syscall available to PackMsg, and that is taken care of if you have RiBBS loaded. The parameter parsing routines will allow you to enter up to five options in any order you wish - more options are not necessary. Extra parameters will be ignored. I don't claim that this routine is fully bulletproof, so use it right. A typical calling line might be: OS9: Packmsg -p6500 -r28000 -e -b -v ...or for non-Shellplus 2.(x) users: OS9: Packmsg ("-p6500","-r28000","-e","-b","-v") Most of you will probably run this from your EVENTS file, though, and a typical EVENTS entry might look like: 05:00PACKMSG -P6500 -R28000 -B Options -B - Backup Mode If you include this option when calling PackMsg, your current TEXT, HDR, and IDX files will be backed up before the packing starts. If for some reason no packing takes place (i.e. the Mbase has not yet reached its Pack Limit), then this option will be ignored. It is important for you to have enough space on 61 PACKMSG your drive to hold both your new MBase and its backup - otherwise, PackMsg will likely bomb out with an error. -C - Check Statistics Mode If this option is specified, then PackMsg will simply show you how large your message base is, maximum size, high message number, and number of active messages. Then the program terminates (no packing, no log update.) -E - Expanded Packing Area Display Normally, PackMsg uses an eight line scrolling window at the bottom of the screen to show you packing progress. The "-E" option doubles the size of this area. -I - Rebuild Index Only Invoking this mode bypasses the packing procedure and simply builds a new IDX file. This is helpful if your old IDX file becomes corrupted. The IDX file is presized to its maximum estimated size and will not grow in size unless you exceed the size of your base. -P(PackLimit K) - Pack When MBase Limits Are Approached. If this option flag is specified, packing will be suppressed if your "Pack Limit" has not yet been reached. To make use of this option, you need to determine what your "Pack Limit" should be. In my case, I subtracted my expected peak mail from my max message size, like this: Max Base size 8,000 K-bytes Expected daily peak - 1,500,K-bytes -------------------- Pack Limit 6,500 K-bytes Parameter format -P6500 (notice that I made my expected daily peak a few hundred thousand bytes larger than what I normally get on a good day, just in case.) So, using this insanely easy formula, I decided that I wanted PackMsg to wait until my Text Size was greater than 6,500,000 bytes before it packed the base. You should be able to use a similar method to determine how large your Pack Limit should be. 62 PACKMSG Remember, if you leave out this parameter, PackMsg will not check these sizes and will simply pack your base (unless the -C, -S, - ?, or -I options are specified.) You've probably noticed that I'm not using multiples of 1,024 bytes, but 1,000 bytes... I find this to be more, uhh... human. Yeah, huuuman! Dat's da ticket! -Q(Quiet) - Quiet Mode Using the quiet mode will save you approximately 25%-30% savings in time. -R(NumberLimit) - Renumber mode Normally, you will want to let your message numbers go as long as possible before you renumber. This option allows you to automate this procedure. You cannot use the "-R" option without specifying a NumberLimit... if you wish to force renumbering, use "-R0". Basically, this option tells PackMsg to renumber your base IF your current High Message number is greater than the NumberLimit. Otherwise, no renumbering takes place. I recommend 28000 as a good NumberLimit unless you expect to get more than 4700 messages between packings. Remember, even if this limit has been reached, nothing will happen if the PackLimit has not been reached. The renumbering scheme allows up to 32,767 messages remaining in your base after packing (and since that is the highest possible message number, there is no practical limit to renumber flags.) You'll notice when packing that after each 1000 messages have been copied, PackMsg will save off it's current renumbering array, then clear it out and start over. The data is saved to a file in your MB directory called "scratch". This gets deleted when PackMsg is done. Scratch holds up to 32 chunks of 1000 renumber pointers and can grow to a max of 66k (2k per each 1000 copied messages.) Make sure you have room for it. Even with this extra disk access, I've found the actual renumbering to take less time because far fewer comparisons have to be made when updating userlog pointers. You'll be able to watch which pointers are being updated and which renumber-array is currently loaded while in the userlog update mode. 63 PACKMSG -S(Size K) - Resize your Message Base Like in the -P option, I'm using multiples of 1,000 bytes for greater user-friendliness. This option simply resizes the TEXT file and resets the variable in HDR that defines the maximum of the TEXT file. It does it very quickly and (as far as I can tell) safely. After doing this, it will change the size of HDR and IDX to match the new size given to the TEXT file. When done residing, the program terminates with no update to the system log. The value you have after -S is multiplied by 1000 and your TEXT file's size is either expanded or shrunk to become that size. So, what happens if you try to shrink the size of your base to a size smaller than your current used area?(i.e. your TEXT file is 2,000,000 bytes long and you currently have 1,500,000 bytes worth of messages and you enter -S1000)? In that case, PackMsg leave the TEXT file at it's current size (2,000,000 bytes in this example), but will change your Max Size variable to 1,00 For example: TEXT file size - 2,000,000 bytes Current used space - 1,500,000 bytes If you enter "packmsg -S1000", attempting to resize your TEXT file would destroy messages, right? Not so... PackMSG will change your Max Size variable, but will leave the file at 2,000,000 bytes. If at any time after a packing procedure, your current used space drops below 1,000,000 bytes... THEN PackMsg will shrink the base down. More on the "watchdogging" later. By the same token, there is some protection of you enter a size too large for your file system to handle. Not only is it possible to enter a value larger than your drive space, but there is also another limitation to file size in OS-9... and that is your Segment list. You see... a file can only consist of up to 48 pieces in OS-9, if you try to expand the file after it reaches 48 "segments", you get an Error #217 (Segment List Full). PackMsg will expand your file using as few segments as possible, but if it cannot expand the TEXT file as large as you request, it will tell you so and will return it to its previous size. NOTE: If you try to re-size the message base too large, OS9's RBF routines are going to keep your system tied up for a long time, (possibly 5-10 minutes). If this happens, LEAVE the program alone! Do not attempt to break out. Eventually, control will be 64 PACKMSG returned back to Packmsg and it will recover properly - resizing the base back down to it's previous level. -V - Verify Date before Packing This is NOT a good option to use if running PackMSG unattended from your EVENTS file. If you specify this option, PackMsg will tell you what it thinks today's date is and ask you if you wish to go ahead with the packing. -? - Help Screen Invoking PackMsg with this option prints a short help screen with sample calling format. Nothing else takes place. Logging When PackMsg is run with the "-P" option (whether packing takes place or not, your system log is updated, telling you the current size of the base, whether or not a repack took place (and if so, what the size was after the pack), and whether or not the base was renumbered. Size Watchdogging Sometimes, your TEXT file is not the size it is supposed to be. This can happen if: a) You get some corrupted messages or an unexpectedly large feed - causing your TEXT file to grow beyond the Max Size that you specified for the file. b) You have specified a smaller size for the base (using -S) and PackMsg refused in order to avoid destroying messages. If after your base is packed, and PackMsg determines that the TEXT file is larger than what you specified, it will automatically resize the TEXT file (if it can do so without destroying messages.) Also, after packing, PackMsg will extrapolate the ideal size of the HDR file and make it larger/smaller to meet that size. When the IDX file is built, it too is sized to its ideal size (this is done by figuring out how many messages you can fit in our current TEXT file based on the current average message size.) This should prevent some of the fragmentation problems that some experience (made worse when the base isn't packed every day.) Packmsg will pack the message base deleting any messages flagged for deletion, such as private mail that a user has already read then deleted. Also those messages that have a date 65 PACKMSG that is older in number of days than specified in RConfig for each message base. Do NOT abort 'Packmsg' after it has started packing the message base, this will CRASH your message base! Display The field on the far left called "Prog" tells you the percentage of messages in your base that PackMsg has processed. Also, there are always numbers in the "New #" field (whether renumbering takes place or not.) If renumbering is NOT active, then the message numbers in "MSG #" and "New #" will match. The rest of the fields should be self explanatory. Endnotes I want to stress again that you should run this from the Shell option of the RiBBS Wait screen - not only does this insure the safety of your base, but it also makes the colors come out right :)! One exception to this is the -C option. I usually run this from a different shell window that has the RiBBS color set. 66 FILE TRANSFERS FILE TRANSFERS All download areas are selected by full pathnames from the menu option setup procedure. When you specify that the menu option will be for download or upload it will ask for a pathname which should be the full pathname to that particular download area. Each of those areas you must have a file called 'FILES.BBS' and 'DESC.BBS'. They must be present for the download section work. FILES.BBS - This file is a standard text file containing a listing of programs/files that can be found in a download area. It may contain any number of lines, and they can be of any nature. With the release of v2.10 there is a nice utility called 'Filedit' that will read your download directories and make the 'files.bbs' and make a listing of each file along with its file size. You can then edit the listing using the same program to give it a small description. An example 'files.bbs': +---------------------+ : Coco Term programs : +---------------------+ MTERM.BIN Mterm.Doc The doc file for MTERM.BIN As you can see, most of the lines are just descriptions and not actual files. You don't have to enter every file present. Just the ones you want the users to see. DESC.BBS - This file has a particular format that must be followed. This file is displayed when the Browse option is used. The format is: Filename Author Date File Size (in decimal) Keywords Text line 1-? - (terminating character) Filename Etc 67 FILE TRANSFERS It would look like this in use. RiBBS.DOC Paul Sweat 88/02/19 13:09:14 114809 RIBBS DOC BBS This is the Doc file for RiBBS. Be sure to read this before starting your RiBBS system. - RiBBS.MAIN Ron Bihler 88/02/19 14:24:01 9257 RIBBS MAIN BBS GREATEST SHAREWARE These are the files required to run RiBBS. - etc The Keywords are used by the Browse option to display only programs of interest to the user. The Keywords must be entered Upper case only. The Date is the Standard OS9 format. Both of these files are updated after an Upload. Uploading is available in XMODEM/YMODEM/KERMIT only. Downloading is available in XON/XOFF, straight ascii list, XMODEM, YMODEM and KERMIT. After an upload RiBBS will ask the user if the file uploaded is a private file for the sysop. For this option to work correctly you must have a 'files.bbs' and 'desc.bbs' present in the RiBBS current working directory (pwd, /h0/bbs/files). NOTE: When specifying an area for upload, you will need to input the full pathname when editing your menus. This is the same procedure as the download pathnames. 68 UTILITIES The following sections are explanations of some the Utilities and programs Ribbs uses in the course of running BUNDLE USAGE: BUNDLE [opts] [alternate.cfg] [opts] Opts: -? or -H Help -v[v....] Increase LOG reporting -o# Set output buffer size (default 6k) -i# Set Input buffer size (default 2k) Input and Output buffer sizes are assumed to be decimal. e.g. bundle -vv -i4096 -o8192 Invalid buffer sizes cause buffer to be 128 bytes (normal). 69 UTILITIES MAILIMPORT Mailimport is responsible for tossing your mail to the appropriate areas as defined in Ribbs.cfg. The command line for invoking mailimport is: MAILIMPORT [-opt] [-opt] OPTIONS: -d = Rebuild Date Field for Echo Messages -r = Rename PKTs w/ bad passwords. -rr = Rename PKTs if not in AREAS.CTL -s = Save Import Statistics to 'mistat.dat' -? = This help message. -D This option will cause the date/time field on all messages to be rebuilt in the same fashion that Echocheck does. For example: If a message was created and sent out on March 3, 1993 and received on March 5, 1993 then: "93/03/03 16:22:00" becomes "93/03/05 (93/03/03)" Since Mailin now does the filtering that Echocheck does, the -D option to mailimport makes Echocheck obsolete. You may want to keep it around in case you want to do a brute force run on the message base, but it is no longer required in Mailimport.bat. -R This flag has to do with system security. When Mailimport runs, you will notice a field in the upper right hand which looks like: Pswd/Areas: Good / Pass. The "Good" indicates that you have a packet level password established with the system you are processing mail from and this packet passed the test. If it says "Bad", then it failed the test. If it says "None", then you do not have a password set up for that system and no check was made. The "Pass" indicates that AREAS.CTL was searched to verify that the system sending you mail is listed there and it passed the test. If you see "Fail", then the system was not found in AREAS.CTL. This is usually no big deal as long as there are no public echo messages in the packet. 70 UTILITIES The security is ALWAYS in place to some extent. If the "-R" flag is not utilized, then if you receive mail packets from a system that does not exists in your AREAS.CTL file -or- if you have passwords for that system in your Password.ctl file and the packets Fail the test, Mailimport WILL still import the mail, but will NOT echo it out to any other system. There is no instance where you should want such messages passed on. There may, however, be times when you don't even want such packets to be imported. If you run Mailimport with the "-R' option then packets which fail the AREAS.CTL test will be imported, (this includes netmail from unexpected places), but if the password test fails, that packet will be renamed to something that will not be processed. For example: bad packet: FF81021E.PKT becomes FF81021E.VIO bad packet: rec.pkt becomes 04162201.VIO date/time------^^^^^^^^ "VIO" is short for "violation". Your system log will record that this action was taken. You will probably want to run in this mode most of the time, but if you use "-RR" (instead of "-R"), as a parameter, then not only will mail that fails the password test be renamed, but so will packets that fail the AREAS.CTL test. BEWARE: If you use this extra secure option, then netmail from systems not in AREAS.CTL will also be renamed. I recommend only using this option if your system is regularly bombarded with highly nasty packets from someone who is using a fake origin addresses, (a rare occurrence indeed), and you wish to inspect such packets before importing them. -S Using this option causes Mailimport to either create or append to a file named 'mistat.dat" in your main BBS work directory. The purpose of this file is to provide some raw data to a statistics program that keeps track of how much mail was received, etc... (such programs are rampant in the IBM world). In cases where Mailimport finds mail from more than one system, it will process only one systems mail, (skipping the other .PKT files), save out a record to 'mistats.dat', then go back and process the other system(s) mail. This file will continue to grow until you get an Error 217 or it is deleted. It would be a good idea to have a line in your mailimport.bat to delete this file. 71 UTILITIES RBPASS Rbpass is the password file builder/editor. The 'ctl' file is in the CFG dir in your FIDO-OUT directory. The command line is: rbpass [opts]
