From 7a35f9f062c418f6372b1356563ff9fd5eb786d4 Mon Sep 17 00:00:00 2001 From: Art Cancro Date: Sun, 19 Mar 2000 23:26:14 +0000 Subject: [PATCH] * docs --- citadel/README.txt | 197 ----------------- citadel/{ => docs}/COPYING.txt | 0 citadel/install.txt | 380 --------------------------------- citadel/mailinglists.txt | 96 --------- citadel/netsetup.txt | 53 ----- citadel/network.txt | 255 ---------------------- citadel/room-sharing-howto.txt | 277 ------------------------ citadel/sysop.txt | 269 ----------------------- citadel/{ => techdoc}/PAM.txt | 0 citadel/upgrading.txt | 51 ----- citadel/utils.txt | 126 ----------- 11 files changed, 1704 deletions(-) delete mode 100644 citadel/README.txt rename citadel/{ => docs}/COPYING.txt (100%) delete mode 100644 citadel/install.txt delete mode 100644 citadel/mailinglists.txt delete mode 100644 citadel/netsetup.txt delete mode 100644 citadel/network.txt delete mode 100644 citadel/room-sharing-howto.txt delete mode 100644 citadel/sysop.txt rename citadel/{ => techdoc}/PAM.txt (100%) delete mode 100644 citadel/upgrading.txt delete mode 100644 citadel/utils.txt diff --git a/citadel/README.txt b/citadel/README.txt deleted file mode 100644 index eeed2c12d..000000000 --- a/citadel/README.txt +++ /dev/null @@ -1,197 +0,0 @@ - Citadel/UX release notes -- version 5.50 - - ALL FURTHER CHANGES WILL BE IN THE "ChangeLog" FILE. - - Please view that file for further information. - - - - Citadel/UX release notes -- version 5.01 ("Scooby") - - Major overhaul. The server is now multithreaded; you run one copy of it -when you bring up your system, rather than having inetd start a separate -server process for each session. - - Access level 0, which was formerly "marked for deletion," has been changed -to "deleted." When a user record is marked access level 0, it is then -considered a vacant space in the userlog rather than a user entry. When -new users are added to the system, the server first searches for these vacant -slots before appending to the end of the file. - - The setup program has been overhauled. It can now operate in three different -modes: a curses-based mode, a mode based on Savio Lam's "dialog" program, and -of course dumb-terminal mode. - - All system messages (hello, newuser, etc.) can now be edited from a client -program. We now also have support for graphics images, including graphics -tied to various system objects (such as pictures of each user). - - Much more support for server graphics is in place. This is currently used -in WebCit; expect other clients to do more with graphics in the future. - - There really is too much to list here. More documentation will be written -as time permits. - - - Citadel/UX release notes -- version 4.11 - - Smarter usage of external editors. EDITOR_EXIT is no longer needed. Instead, -the program examines temp files before and after they are edited, in order to -determine whether the user saved the file. Modified files are saved, unchanged -files are aborted. - - External editors work for Bio and Room Info files as well. - - The TCP/IP based client (citatcp, linked against ipc_c_tcp.o) now supports -connection to a Citadel server from behind a SOCKS v4 firewall without having -to "socksify" the program first. - - Added a few more commands to the chat server. - - - Citadel/UX release notes -- version 4.10 - - Floors now fully supported in both client and server. - - Now supports "bio" files for each user - free-form text files in which -users may record personal info for others to browse. - - <.G>oto and <.S>kip now have more advanced logic for partial matches. A -left-aligned match carries a heavier weight than a mid-string match. For -example, <.G> TECH would prefer "Tech Area>" over "Biotech/Ethics>". - - - Citadel/UX release notes -- version 4.03 - - There are now commands available for users with their own copy of the client -to upload and download directly to their local disk, without having to use -a protocol such as Zmodem. These commands are disabled by default, but can -easily be enabled by changing citadel.rc. - - Multiuser hat is now fully integrated into both the client and server. - - New

aging functionality allows users to send each other near-real-time -"express" messages. - - - Citadel/UX release notes -- version 4.02 - - The "rnews" program has been renamed to "rcit". Its usage has not changed; -it still accepts UseNet-style news by default. Use the -c option to read in -Citadel (IGnet) format data. - - The text client now compiles and works on systems using BSD-style -in addition to SysV-style . This should be a big help for many. - - - Citadel/UX release notes -- version 4.01 - - Remember to always run setup again when using a new version of the code, to -bring your data files up to date! No data will be lost. - - This release is primarily to clean up loose ends and fix assorted small -bug reports from the users of 4.00. Also, the code is slowly being reworked -to compile cleanly under ANSI C compilers even when warning messages are -set to the highest level. - - -> The client now sends periodic "keep-alive" messages to the server during -message entry, with both internal and external editors. This should keep -sessions from locking up when a user hits ave after typing for a long time. - - -> Stats now has a "-b" option for batch mode (see utils.doc) - It also has a "-p" option to only print the post-to-call ratios. - - - Citadel/UX release notes -- version 4.00 - - This is the long-awaited client/server version of Citadel. Feedback is -encouraged! - - NOTE: if you are upgrading to 4.00 from a 3.2x release, you should run setup -to bring your data files up to date. Setup will prompt you to run the -"conv_32_40" program; go ahead and do that. - - If you are upgrading to 4.00 from a 3.1x release, setup will not tell you -what to do! Here is the correct procedure: - 1. Run the "conv_31_32" program - 2. Run setup - 3. Run "conv_32_40" - - If you are currently running a version earlier than 3.10, you must erase your -data files and bring up a new system. - - A new series of commands to manipluate files in a room's directory: - <.A>ide ile elete -- delete it - <.A>ide ile ove -- move it to another room - <.A>ide ile end -- send it over the network - - Changed the way the main Citadel program sends network mail, both to other -Citadels and through the RFC822 gateway. Everything now gets fed through -netproc, which is responsible for figuring out the routing and doing the -actual processing. It also gets rid of quite a bit of redundant code. - - - Citadel/UX release notes -- version 3.23 - - NOTE: if you are upgrading to 3.23 from another 3.2x release, you MUST run -setup to bring your data files up to date. Run setup and answer "no" when it -asks you if you want to create the various files. It will see your old files -and bring them up to date. (If you are doing a new installation, of course, -you'll be creating all new files anyway.) - - The built-in message editor has been completely rewritten, and is now the -preferable editor to use. It generates messages that will be formatted to -the reader's screen width, as in other implementations of Citadel (and as -Citadel/UX used to do until a few versions ago -- there was a need to put -that functionality back in). - - Users are now prompted for their screen width AND height. - - We can now talk to C86NET compliant networks. Get the "cit86net" package -if you wish to do this. - - Rooms can now optionally be "read only," which means that only Aides and -utilities such as the networker and aidepost can post to the room. - - Kernel-based file locking is now fully supported for the purpose of locking -the message base during writes. If your kernel supports the flock() system -call, you can tell the compiler to use it by setting a flag in the Makefile. -If your kernel supports file locking using fcntl(), this will automatically be -detected and utilized. If your kernel supports neither, the program will use -a fully portable (but less reliable) file locking scheme. - - An external editor is no longer required for the .AI command. - - - Citadel/UX release notes -- version 3.22 - - The "setup" program is now a curses-based, full-screen utility that's very -easy to use. Of course, if you have trouble compiling curses-based programs -on your system, you can compile it to run the old way. - - - Citadel/UX release notes -- version 3.21 - - I'm now running my system under Linux, since that seems to be what everyone -is using these days. As a result, you'll find that version 3.21 will compile -very cleanly under Linux. - - - Citadel/UX release notes -- version 3.20 - - Lots of improvements and new features are here. It seems that assorted -hacks and variations of Citadel/UX have percolated around the country -- -this 3.2 release should supersede them and get everyone running (hopefully) -off the same code. I've looked around at the various mods people have made -to Citadel/UX and tried to implement the most-often-added and most-requested -features to the stock distribution. If there's a feature you want/need that -still isn't here, drop me a line and I'll see what I can do about adding it -to the next release. - - - - - For more information, visit the Citadel/UX web site at UNCENSORED! BBS - http://uncnsrd.mt-kisco.ny.us - - diff --git a/citadel/COPYING.txt b/citadel/docs/COPYING.txt similarity index 100% rename from citadel/COPYING.txt rename to citadel/docs/COPYING.txt diff --git a/citadel/install.txt b/citadel/install.txt deleted file mode 100644 index bcca34853..000000000 --- a/citadel/install.txt +++ /dev/null @@ -1,380 +0,0 @@ - Citadel/UX Installation Procedure - See copyright.doc for copyright information - - - OVERVIEW - - Citadel/UX is an advanced, multiuser, client/server, room-based BBS -program. It is designed to handle the needs of both small dialup systems and -large-scale Internet-connected systems. It was originally developed on an -Altos system running Xenix, and has been installed and tested on various -Unix and Unix-like platforms. The author's current development environment -(and BBS) is a Linux/GNU system. The current distribution includes: - - - The Citadel/UX server (this is the back end that does all processing) - - A text-based client program designed with the traditional Citadel "look - and feel" (room prompts, dot commands, and the like) - - A networker that can share rooms and email between multiple systems. - Replication can be performed via TCP/IP or any external transport. - - Setup programs - - A rich set of utilities for system administration and maintenance - - Documentation - - Some knowledge of the Unix system is necessary to install and manage the -system. It is preferable that the sysop have superuser access to the operating -system. The following are required to install Citadel/UX: - - - A Unix operating system (Linux, BSD, Solaris, DEC Unix, etc.) - - C compiler (such as gcc or egcs) and "make" - - POSIX threads - - TCP/IP - - The "gdbm" record manager - - Enough disk space to hold all of the programs and data - - If you are running Citadel/UX on a Linux system, it is STRONGLY recommended -that you use a version based on glibc v2 (also called libc6). libc5 contains -a number of thread safety problems. Furthermore, most modern Linux -distributions have libc6, pthreads, gdbm, and the compiler already installed -and integrated for you. - - - NOW AVAILABLE: - - - "WebCit", a gateway program to allow full access to Citadel/UX BBS's - via the World Wide Web. Interactive access through any Web browser. - - COMING SOON: - - - Newer and better GUI based clients. - - - - EVERYTHING IN ITS PLACE... - - Hopefully you've unpacked the distribution archive into its own directory. -This is the directory in which all Citadel files are located and in which all -BBS activity will take place. Several subdirectories have already been created -during the unpacking process, and others may be created by the software if -needed. - - Make sure you have the "gdbm" record manager installed on your system, and -that you have installed the libraries and headers required to compile gdbm -programs. Likewise, if your operating system uses a separate library to -support POSIX threads, make sure that library is installed as well. - - - THE BBS LOGIN - - There will be one account in /etc/passwd which all BBS users will use to -login to the system. This account is typically called "bbs" or "citadel" or -something to that effect. You will tell Citadel what the user-id of that -account is, and when someone logs in under that account, Citadel will prompt -for a user name. - -The BBS login should have a unique uid. The home directory should be the -one your BBS resides in (in this example we will use /usr/bbs) and the shell -should be either "citadel" in that directory, or a script that will start up -citadel (you may wish to set up an external text editor; see below). Example: - - bbs::100:1:BBS Login:/usr/citadel:/usr/citadel/citadel - - When you run setup later, you will be required to tell it what the BBS -login's numeric user ID is, so it knows what user to run as. If you create -an account called bbs, guest, or citadel, the setup program will automatically -pick up the user ID by default. - - For all other users in /etc/passwd, Citadel will automatically set up an -account using the "full name" field. No password is required, since it -assumes that if a user is logged in, he/she has already entered a password. -Note that this does have to be enabled at compile time (see ENABLE_AUTOLOGIN -in the Makefile). If such an account needs to be accessed remotely (such as -from client software), these users can use *either* their Citadel login name -or their login name on the host computer, and their password on the host -computer. - - - COMPILING THE PROGRAMS - - - You can easily compile Citadel with the following commands: - - ./configure - make - make install - - The 'configure' script will generate a Makefile from the Makefile.in, and -it will also write the file "sysdep.h" to your Citadel directory. Please do -not edit sysdep.h or Makefile.in yourself. The configure script will figure -out your system dependencies and set everything correctly. - - By default, the Citadel system will install in /usr/local/citadel. If you -wish to place it in a different directory, you can instead do: - - ./configure --prefix=/opt/citadel (or whatever) - - - File permissions are always a bother to work with. You don't want the -board to crash because someone couldn't access a file, but you also don't -want shell users peeking into the binaries to do things like reading others' -mail, finding private rooms, etc. The Citadel server needs to be started -as root in order to bind to a privileged port, but as soon as its -initialization is finished, it changes its user ID to your BBS user ID in -order to avoid security holes. - - - THE CITADEL.RC FILE - - This is a change from the way things were done before. All client-side setup -is in a "citadel.rc" file. The standard client looks for this file in: - 1. $HOME/.citadelrc - 2. /usr/local/lib/citadel.rc - 3. /citadel.rc - - The next couple of sections deal with client-side configuration. - - USING AN EXTERNAL EDITOR FOR MESSAGES - - Citadel/UX has a built-in message editor. However, you can also use your -favorite text editor to write messages. To do this you simply put a line in -your citadel.rc file like: - -editor=/usr/bin/vi - - ...would make Citadel call the vi editor when using the .nter ditor -command. You can also make it the default editor for the nter command by -editing the citadel.rc file. (WARNING: external editors on public systems -can create a security hole. Make sure there is absolutely no way for users -to drop into the shell from the editor, or save files other than the temp file -they are editing!) - - Using this mechanism, shell users can pick their favorite editor for Citadel. -BBS users can use external editors too; just have the bbs login call a script -that sets the variables and then calls citadel. I used to recommend using -an external editor as the default, but the built-in editor is now a bit more -robust, so the use of an external editor is definitely optional. By the -way, be VERY careful what editor you choose and how you set up its options. -Giving the general public to an editor like vi or emacs can open up lots of -security holes. - - - PRINTING MESSAGES - - Citadel/UX can send messages to a printer, or just about anywhere else in -your system. The variable PRINTCMD in citadel.rc specifies what command you -use to print. Text is sent to the standard input (stdin) of the print command. - - So if you did this: - -printcmd="nl|pr|lpr -dlocal" - - ...that would add line numbers, then paginate, then print on the printer -named "local". There's tons of stuff you can do with this feature. For -example, you could use a command like "cat >>$HOME/archive" to save copies -of important messages in a textfile. - - - SETUP AND LOGIN - - Before logging in for the first time, you must run the setup program. Type -"./setup" to begin this procedure. - - The setup program will ask you what directory to place your data files in. -You can use this functionality to keep your programs and data in different -directories, or to run more than one BBS on the same computer. If you don't -use the default directory (the one specified in the Makefile), remember to -specify the directory name again when you start up the server later on. - - If you've used older versions of Citadel/UX before, you'll notice that the -setup program does much less than it did before. It won't create any empty -data files; that's now done automatically by the server the first time it -starts. It also asks only a few questions; that's because the rest of the -global configuration is now done from within Citadel. - - - PREPARING TO START THE SERVER - - The files /etc/services and /etc/inittab must be modified in order to run -the Citadel server. The setup program will perform the correct modifications -for you if you allow it to. If you'd prefer to do it manually, or if you're -interested in what these modifications are, then read on... - - Before you can use Citadel, you must define the "citadel" service to your -system. This is accomplished by adding a line to your /etc/services file that -looks something like this: - - citadel 504/tcp # Citadel/UX Server - - 504 is the port number officially designated by the IANA for use by Citadel. -There should not be any need to use a different port number, unless you are -running multiple BBS's on the same computer and therefore need a different -port for each one. - - The next step is to arrange for the server to start. The "citserver" -program is the main Citadel server. Before we cover the recommended method of -starting the server, let's examine its usage options: - - citserver [-hHomeDir] [-xDebugLevel] [-tTraceFile] [-d] [-f] - - The options are as follows: - - -hHomeDir - the directory your BBS data files live in. This should, of -course, be a directory that you've run the "setup" program against to set up -some data files. If a directory is not specified, the directory name which -was specified in the Makefile will be used. - - -xDebugLevel - Set the verbosity of trace messages printed. The available -debugging levels are: - 1 - Internal errors (failed thread creation, malloc problems, etc.) - 2 - Network errors (broken sockets, failed socket creation) - 3 - Begin and end of sessions, startup/shutdown of server - 5 - Server commands being sent from clients - 7 - Entry and exit of various functions - 8 - Entry and exit of critical sections - 9 - Various debugging checkpoints (insanely verbose) - - -tTraceFile - Tell the server where to send its debug/trace output. -Normally it is sent to stdout. - - -d - Run as a daemon. This switch would be necessary if you were -starting the Citadel server, for example, from an rc.local script (which is -not recommended, because this won't allow the server to automatically restart -when it is shut down). - - -f - Defragment all the databases upon startup. This isn't -normally necessary due to the nature of the data stored in Citadel, but the -option is provided in case you need it. - - - The preferred method of starting the Citadel server is to place an entry in -your /etc/inittab file. This will conveniently bring the server up when your -system is up, and terminate it gracefully when your system is shutting down. -The exact syntax for your system may vary, but here's the entry that I use on -my Linux system: - - cit:2345:respawn:/appl/citadel/citserver -h/appl/citadel -t/dev/tty6 -x3 - - What I've done here is to set debugging level 3, and have the trace stuff -output to one of my virtual consoles. It's important to remember to turn off -any getty that is set up on that virtual console, if you do this. After -making this change, the command "init q" works on most systems to tell init -to re-read the file. If in doubt, just reboot your computer. - - - LOGGING IN FOR THE FIRST TIME - - At this point, your system is ready to run. Run the citadel program from -the shell and it will automatically create your account. NOTE: the first -user account to be created will automatically be set to access level 6 -(Aide). This overcomes some obvious logistical problems - normally, Aide -access is given by another Aide, but since there aren't any on your system -yet, this isn't possible. - - - SPACE FOR ADDING YOUR OWN FEATURES (doors) - - *** PLEASE TAKE NOTE!! *** This function really represents the "old" -way of doing things, and it doesn't fit in well with the client/server -paradigm. Please consider it "deprecated" because it may be removed at any -time. - - The "doorway" feature is just a generic way to add features to the system. -I called it "Doorway" to make it resemble the doors on non-Unix boards, but as -we all know, us Unix types don't have to write special code to access the -modem. :-) Anyway, when a user hits the <*> (doorway) command, Citadel does... - - USERNAME=; export USERNAME - ./subsystem - - ...so you can put whatever you want in there. I suggest putting in a menu -program to allow the users to pick one of a number of programs, etc. - - Do be aware that chat and door programs will only be available when two -conditions are met: - - 1. The client and server programs are running on the same computer - 2. The user is running the text-based Unix client. - - Because of these restrictions, Door programs are being utilized less and -less every day. - - - - SETTING UP CITADEL TO SEND AND RECEIVE INTERNET MAIL - - Mail programs are now elaborate enough that it is trivial to set up Citadel -to act as your system's local mail delivery agent. It couples easily with -either sendmail or qmail, or with any other mail system that is capable of -invoking a separate program to deliver local mail. - - Unlike earlier versions of Citadel/UX, there is no longer a need to play -with rmail or to patch other pieces of your system's existing mailer. Simply -make a few quick configurations, compile the Citadel/UX package "as is" and -you're ready to go. Here's how to do it: - - 1. First, open up the config file "internetmail.config" in the "network" -directory, and edit the definitions in it to your local configuration. It's -very self-documented; just go through the file making any necessary changes. - - 2. Next, you must configure your system's main mail delivery agent to -use the "citmail" program to deliver mail to local addresses. This will -change from mailer to mailer, of course. I'm using sendmail, and although -I don't know enough about sendmail to provide really good instructions on -sendmail configuration, here's what worked for me: - - I added the following mailer definition: - - Mcitadel, P=/appl/citadel/citmail, F=lsDFMoqeu9S, S=10/30, R=20/40, - D=$z:/, T=X-Unix, U=bbs, - A=/appl/citadel/citmail $u - - Then I replaced all instances of "#local" with "#citadel". This seems to -work on my system; your mileage may vary. - - 3. Some mailers will need to be killed and restarted for the changes to -take effect. Once this is done, all of your BBS users now have an Internet -e-mail address. They can use two forms of addresses: - - user_name@your.system.name - cit1234@your.system.name - - In the first form, the name portion of the user's Internet e-mail address -is the name they use on your Citadel system, with all spaces replaced by -underscores. In the second form, the name is the letters "cit" followed -by the user's user number. This is a nice shorthand that is sometimes -easier to use. Note that the help file <.H>elp MAIL is set up to tell users -what their address is. - - NOTE: I cannot and will not answer e-mails regarding the configuration of -sendmail or any other mailer. I am not a sendmail expert; what is written -above is everything I know about getting Citadel and sendmail to talk to each -other. Please refer these questions to your local sendmail wizard. - - - - THE PEANUT GALLERY - - That's just about all the information you need to install the system. - For more information, visit the Citadel/UX web site at UNCENSORED! BBS - http://uncnsrd.mt-kisco.ny.us - - Please note: if you intend to report a problem getting the Citadel server -to run, please first check the following: - - 1. Did you do ./configure && make && make install ?? - 2. Did you run setup? - 3. Did you start the server? - - To report a problem, you can log on to UNCENSORED! or any other BBS on the -Citadel network which carries the Citadel/UX> room. Please remember to mention -all of the following information: - - 1. The exact nature of your difficulty - 2. A transcript of the error message(s) if possible - 3. The version of Citadel you are running - 4. The version of GDBM present on your system - 5. Which operating system you are running, and what version - 6. If you are running a Linux system, we need to know which distribution, and -the version of the kernel, libc, and pthreads you are using (it would help to -post the output of a "ldd ./citserver" command). - - diff --git a/citadel/mailinglists.txt b/citadel/mailinglists.txt deleted file mode 100644 index 9b5e5a9e4..000000000 --- a/citadel/mailinglists.txt +++ /dev/null @@ -1,96 +0,0 @@ - BIDIRECTIONAL MAILING LIST GATEWAY INSTRUCTIONS - - Citadel/UX now has the ability to host a room on the BBS as a -bidirectional gateway to an Internet mailing list. This makes it convenient -for the entire BBS community to have reading and posting access to a mailing -list without each member having to subscribe to the list. This document -describes the procedure for setting up such functionality. - - Here's the prerequisite: you must be using Citadel as your system's local -mail delivery agent. Please refer to network.doc for information on how to -do this. Before attempting a mailing list, make sure that you can send and -receive regular Internet e-mail from your Citadel system. - - As you may or may not know, once Citadel is your e-mail system, each room -on the system has an e-mail address that may be used to post to the room -from anywhere on the Internet. That address is of the form -"room_roomname@yourhost.dom", where "roomname" is the name of the room -(spaces replaced by underscores) and "yourhost.dom" is your fully-qualified -domain name. - - The first step is to create a room for the list and then subscribe that -room to the list. The procedure for subscribing to a list depends on what -type of software the list server is running, and is beyond the scope of this -document. For the purpose of example, let us suppose that you wish to -subscribe to the "Broccoli Advocates" mailing list, and you've discovered -that the list administrator is at broccoli-request@stalks.com and messages -to be posted to the list should be mailed to broccoli@stalks.com. Let us -further suppose that your BBS is at mybbs.org. - - So you create a room called "Broccoli Advocates". Then, because you're a -conscientous system administrator, you give the room an Info file which -warns users that all messages posted to the room will be posted to the list. - - You then send e-mail to the list administrator at -broccoli-request@stalks.com requesting that the address -"room_broccoli_advocates@mybbs.org" be added to the list. Once the -administrator sets this up, the receiving end of the list is set up. Note -that if a receive-only setup is all you want, you can stop here and you're -done. - - Now you have to set things up for sending. The first thing you have to -do is set up the file "mailinglists" which resides in the "network" -subdirectory, which holds a table of list addresses associated with each -room. Each line is of the form - - list-address,Room Name - - ...one room per line. You'll use this same file to set up all mailing list -references. So for our example, the line - - broccoli@stalks.com,Broccoli Advocates - - should be added. In other words, messages originating from the "Broccoli -Advocates" room will be mailed to broccoli@stalks.com. - - The next thing to do is create a file in the "network/systems" subdirectory -which spools out new messages. Create a file "network/systems/mailinglists" -which looks like this: - - mailinglist <%s - Broccoli Advocates - 0 - - Note that one systems entry may be used for all mailing lists to which you -subscribe. Just keep adding any rooms (refer to network.doc for the -procedure) that are mapped to mailing lists. - - Now you're done! Just do a "netproc mailinglists" or "netproc all" on a -regular basis (probably using cron or a similar scheduling utility) to batch -up new messages and send them out on a regular basis. - - - NOTES ABOUT MAILING LISTS: - - Since many listservers will only accept postings from e-mail addresses -which are subscribed to the list, the mailing list gateway software sets the -sending address of each message to the address of the room. The "full name" -portion of the address will remain intact. So the posted messages will have -headers which look like this: - - From: room_broccoli_advocates@mybbs.org (Joe User) - To: broccoli@stalks.org - - This ensures that messages are properly posted, but it makes it difficult -for other members of the list to learn the correct e-mail addresses of the -users on your system. However, since there's so much spam around these -days, that's probably just as well anyway. - - To prevent loops, the mailing list gateway software only spools out -messages which originated on _your_ system. This implies that it is not -possible to carry a gatewayed room on any type of Citadel network. - - - Well, that's just about it. If you have any comments, suggestions, or -questions, please visit UNCENSORED! BBS, either on the Internet at -uncnsrd.mt-kisco.ny.us or via dialup at 914-244-3252. diff --git a/citadel/netsetup.txt b/citadel/netsetup.txt deleted file mode 100644 index f954c8ddd..000000000 --- a/citadel/netsetup.txt +++ /dev/null @@ -1,53 +0,0 @@ - NETWORK CONFIGURATION UTILITIES FOR CITADEL/UX - ---------------------------------------------- - - ABSTRACT - -------- - - The Citadel/UX system now comes with two utilities for managing room-sharing -with other systems: 'netsetup' (a command line utility) and 'dnetsetup' (a -curses-based front end to netsetup). Read on for more detail... - - - THE NETSETUP PROGRAM - -------------------- - - 'netsetup' is a program which eliminates the need to edit the files in your -network/systems directory in order to maintain the sharing of rooms on a -network. It allows you to make all changes from the command line. While the -program is quite usable and straightforward this way, the real objective is -for it to be controlled by any of several user-friendly front ends (such as -the 'dnetsetup' program, described below). The usage of 'netsetup' is as -follows: - - netsetup: usage: netsetup [arguments] - - Commands: - nodelist (Lists all neighboring nodes) - addnode [name] (Adds a new node to the list) - deletenode [name] (Deletes a node from the list) - roomlist [node] (List rooms being shared) - getcommand [node] (Show spool command) - setcommand [node] [cmd] (Set spool command) - share [node] [room] (Add a new shared room) - unshare [node] [room] (Stop sharing a room) - help (Display this message) - - The usage of each command should be quite straightforward from the -descriptions listed here. - - - THE DNETSETUP PROGRAM - --------------------- - - dnetsetup is a more user-friendly front end to netsetup. It's written in -shell-script and requires no compiling. Simply type 'dnetsetup' at the -command line and follow the menus to create, edit, and delete neighboring -network nodes, and to share and unshare rooms. - - - FEEDBACK - -------- - - By now you already know where I hang out. :) You can find me at -UNCENSORED! BBS at uncnsrd.mt-kisco.ny.us (telnet, www, citadel-client, etc.) diff --git a/citadel/network.txt b/citadel/network.txt deleted file mode 100644 index d8cca7bdf..000000000 --- a/citadel/network.txt +++ /dev/null @@ -1,255 +0,0 @@ - Citadel/UX Network Manual - See copyright.doc for copyright information - - - OVERVIEW - - The fundamental structure of the networker is fairly simple, however, it -has enough features to make it a bit complicated. This is probably the most -difficult part of the entire Citadel/UX package. So before we dive in head -first, let's look at the various network files and directories. - - netproc.c Does all of the actual network processing. - rcit.c Feeds standard input into the networker, also - has the ability to translate UseNet news format - into Citadel/UX binary format. - netmailer.c Called by the main program when a user sends a - network mail message. - citmail.c A local MDA which can allow Citadel users to - receive Internet mail. - cux2ascii.c A filter which translates Citadel/UX binary - format to UseNet news format. - network Directory in which all network files reside. - network/systems Contains network info for each neighboring system - network/systems/sysname Network file for a node called "sysname". - network/mail.aliases Aliases for the mailer. - network/rnews.xref Cross-references room names to newsgroup names. - network/mail.sysinfo Contains routing information for network mail. - network/filterlist The "kill file" for your system. - - - SETUP - - There are a few options in the Global System Configuration which pertain -to the network. They are: - - -> node name: this is the unqualified "short" node name which uniquely -identifies your system on a Citadel network. - -> fully-qualified domain name (FQDN): this identifies how your computer is -named on the Internet. - -> Human-readable node name: this is a longer, more verbose name for your -system. It is also used as your "node title" on older Cit86Net-based -networks. - - - SETTING UP SYSTEMS FILES - - Please note that it is *much* easier to use the "netsetup" (command-line) -or "dnetsetup" (curses-based) utilities to create systems files. You should -only work with these files manually if you need to do something special. - - For each of your neighboring Citadel/UX systems you must create a systems -file. The file is called network/systems/sysname, where sysname is the other -system's node name. The first line contains a command that transfers a spool -file to the network/spoolin directory on the remote system. The string "%s" -will be replaced by the name of the spool file by netproc. You may only use -%s ONCE in the command line. Usually, some sort of remote copy will be used -to do the transfer, but you may use any facility you want, *** as long as the -file ends up in the network/spoolin directory on the remote system ***. - - If you're on the Internet, or any TCP/IP network, your systems file should -contain the following copy command: - -cat %s >>./network/spoolout/remote_system_name - - This simply stores the outbound spool data in a file in the "spoolout" -directory, where it will be picked up by server-to-server transfer programs. - - After the command line you should enter the names of all the rooms you -intend to share with this system. Each room name should be followed by a -line containing a zero - this extra field is the "last message sent" (which -will be updated by netproc when it is run). Here is a sample systems file for -a node called uncnsrd: - -cat %s >>./network/spoolout/uncnsrd -Network Test -0 -Gateway -0 -The Room -0 - - The rooms "Network Test", "Gateway", and "The Room" will be spooled to -the remote system. These rooms should be designated as network rooms with -the .ide ditRoom command. - - - USING NETPROC - - - Calling netproc with no arguments causes it to look in the network/spoolin -directory for newly arrived messages, and posts them if it finds any. It then -automatically batches up new messages on your system to be sent to your net -neighbors, and exports those messages to them. It is recommended -that you use the cron program to handle your network processing on a routine -basis automatically. Arrange with your netneighbors for both of your systems -to batch new messages before actual polls take place, to guarantee that -messages travel across the network as quickly as possible. - - Calling netproc with the -i flag causes it to skip the export phase, and -handle incoming messages only. - - - USING CITADEL/UX AS YOUR LOCAL E-MAIL SYSTEM - - To use Citadel/UX as your local mail system, simply define the "citmail" -program as your *local* mail delivery agent. You can plug citmail into any -popular mail routing system, including sendmail, smail, MMDF, etc. - - Once you are using citmail as your local mail delivery agent, all users -on your BBS may receive mail. They can use addresses like -"my_user_name@yoursite.com" (note the spaces in the user's name are replaced -by underscores) or "cit1234@yoursite.com" (where 1234 is the user's user -number). - - Messages may be posted by mail if you have this program installed. Simply -use the prefix "room_" -- for example, a message addressed to -"room_hot_pink_amoebas@uncnsrd.mt-kisco.ny.us would be posted in the room "Hot -Pink Amoebas" at the target system. - - PLEASE NOTE that for your BBS users to be able to send mail, you should -check the mailer command at the top of "netmailer.c" to be sure that it is -the correct mailer command for your system. You might need a command like -"sendmail %s" or "smail %s" depending on what MTA you're using. - - - MAIL ALIASES - - The file network/mail.aliases is a simple list of aliases for the various -mailers to use. Each line takes the form - -alias,name - - Obviously, neither the alias nor the name can contain commas. The name -may also be the system name "sysop", where messages sent to sysop will -be posted in the Aide> room. - - - CITADEL/UX NETWORK MAIL - - Citadel/UX has the ability to transport mail in a simple and -transparent fashion not unlike the way public messages are sent. Users may -enter recipient names exactly as they appear on top of messages (i.e., -user name @ system name). In addition, mail routing is provided, allowing -users to send mail to systems which do not directly connect with their own. - - When entering a message in the Mail> room, a user may type a recipient -name on the local system, or on a remote system. If the recipient is not -local, citadel.c calls netmailer.c, which is a standalone program that handles -network mail. This runs in a multithreaded mode, allowing netmailer to run in -the background while the user goes on to do something else. - - - INTELLIGENT NETWORK PROCESSING AND THE MAIL.SYSINFO FILE - - There is (or soon will be) a file in your network directory called -"mail.sysinfo". In earlier releases of the network software, the system -administrator had to manually configure this file. Starting with netproc -version 2.1, the system should now create and configure the file automatically. -Note that all information may not appear in the file immediately. When a -message arrives from a system on the network, your system will attempt to -add that system to its network map. If the originating system is one of your -netneighbors, it will look for a systems file in the network/systems directory -to determine whether it is a valid neighbor. If the originating system is -not a neighbor, but the message arrived via a valid neighbor, your map will -be updated accordingly, with an entry for the new system showing the next hop -to get there. - - So, under normal circumstances you shouldn't have to configure this file at -all. But if you need to do something special, or if for some reason netproc -detects the topology wrong, here's how to configure mail.sysinfo. There -are three types of entries in this file. A "use" entry tells the system which -neighbor to route a message through to get to a particular non-neighboring -system. A "bin" entry tells the system that a particular neighbor supports -net mail. If there are systems that either do not have the netmailer or are -not running Citadel/UX, but can be reached by regular electronic mail, you -can use the "uum" command. Type "uum" followed by an address (for the user -name, use a %s which will be replaced by the user name at the remote -system. Here is a sample network map, where our system is called "myself" -and all systems have Citadel/UX EXCEPT for "gateway" and "mailsys": - - gateway---mailsys _____testbbs - / / - othersys ----- myself ----- thebox - / \_______theirsys - funboard - - In this example, our neighbors are "othersys" and "thebox". othersys -also connects to funboard, and thebox connects to testbbs and theirsys. If -everyone supports netmail, the network/mail.sysinfo file would look like this: - -funboard -use othersys - -testbbs -use thebox - -theirsys -use thebox - -othersys -bin Mail - -theirsys -bin Mail - -gateway -uum othersys!gateway!%s - -mailsys -uum othersys!gateway!mailsys!%s - - (Keep in mind that your file will contain additional system-generated -information.) - - The "bin" entries specify neighbors, the "use" entries specify routing, and -the "uum" entries specify Internet mail. The method of delivery is totally -transparent to the user, who only needs to enter the recipient as user@sysname. -Note that netproc will probably stuff lots of other info into each entry. - - - THE KILL FILE - - Tired of idiots lowering the quality of the net? You can set up a "kill -file" in ./network/filterlist that can be used to filter out messages from -any user, room, or system (or any combination). The three fields should be -separated by commas, and the name "*" may be used as a wildcard in any field. -Examples: - - # Filter out user "The Idiot" in "Idiot Room" at "idiotbbs" - # - The Idiot,Idiot Room,idiotbbs - - # Filter out the same user, but in every room - # - The Idiot,*,idiotbbs - - # Filter out all messages from a system we don't like - # - *,*,idiotbbs - - # Filter out messages in a certain room from a certain system - # - *,The Room,idiotbbs - - You could also put a "*" wildcard in all three fields, essentially -disabling all incoming messages. Obviously you don't want to do this. - - - CONCLUSION - - That should cover everything you need to get running. By the way, gateway -software for StoneHenge and NYTI FordBoard systems is available upon special -request. And, a Cit86Net gateway is now available. For the latest version -of this program, or to leave comments/suggestions, call my board - -UNCENSORED! BBS at (914) 244-3252 (modem) or uncnsrd.mt-kisco.ny.us (Internet). diff --git a/citadel/room-sharing-howto.txt b/citadel/room-sharing-howto.txt deleted file mode 100644 index fc048ce6e..000000000 --- a/citadel/room-sharing-howto.txt +++ /dev/null @@ -1,277 +0,0 @@ - Citadel/UX Networking Documentation - (A brief overview on setup) - Written by Steve Williams (Patriot @ splash) - - - Having come this far, you're ready to set up your networked rooms. In -and of itself it's not too difficult. I would suggest telnetting to -another Citadel/UX and checking out what they offer. Currently, -uncnsrd.mt-kisco.ny.us and dogpound2.citadelia.org are most likely your -best Internet bets, and splash.citadelia.org (login as test) is up, but -still in development. Login to one of the above BBS and type 'k'. Note -the roomnames with a ) after them. Here's a list of the Splash BBS rooms: - - -Lobby> Mail> General Babble> The Pet Corner> NonSeq> Bugs> -Sports> Not A Sport> Citadel> The Massage Parlor> -Vacation Ideas> Bed & Breakfast> The Elite> Random Features> Network Test) -X-files) Unix) Tech Area) Science Fiction) Netlinks) Linux) IBM) Food) -Citanews) Buy/Sell) A/V Talk) Anime/Comics) Citadel/UX) Craggy Island) -Gateway) IGnet Unlimited) Microsoft Bashing) Networking) Sysop Stuff) -TrekNet) Video Games) Dante's Inferno> Patriot Is A Twit> Hug Me Dammit!> - Movies) The House of Pork) - - - As noted above you'll see that several (in fact most) of the rooms on -my bbs are networked rooms. Basically networking your citadel is a very -good idea, because not only do you have your own userbase to add to your -rooms, you also have input from every other networked Citadel/UX and some -other varieties of Citadel as well (Citadel-86, Cit:K2NE, etc), which -dramatically increases the topical posting. So now you're saying, "Ok, I -know what it is now, how do I set the damned thing up?" Good question. -There are several steps to take. Actually setting up the networked rooms -is simple so we'll do that last. The first thing you need to do is to -find another network node to share with. The best way to do this (at this -time) is to send mail to smw@splash.citadelia.org. For the time being -I'll share my rooms with just about anyone as I have the bandwidth -currently to accomplish this. Now, for the step by step: - - - 1. Determine from the list above (I have most of the networked rooms - listed, however I have no idea or way of knowing how often new rooms - will be added) or from another networked citadel, which networked rooms - you would like. - - 2. Contact me, or the sysop on another networked citadel (login to the - bbs and send mail to recipient Sysop), asking to share those rooms with - you. - - 3. From your Citadel/UX home directory (eg. /home/citux/citadel) run the - program ./dnetsetup. Here it gets a little confusing so I'll paste - in the actual menus where possible: - - - ********************************************************************** - * Citadel/UX Network Setup * - * * - * ****************************************************************** * - * * EDIT View or change a network node * * - * * ADD Add a new network node * * - * * DELETE Delete a network node * * - * * EXIT Exit from Network Setup * * - * ****************************************************************** * - * * - ********************************************************************** - - ********************************************************************** - * < OK > * - ********************************************************************** - - - - - - As you can see above the menu choices are fairly clear. Lets go -through the steps to actually setting this up. - - First, you'll need to add your network node. A node is the other Citadel/UX -that is going to share rooms with you. - - Select A, then type in the name of your remote node, EXACTLY as that node's -administrator has given it to you. In the case of SplashBBS that would be: - - splash - - Note that the standard Citadel/UX convention is to use all lowercase. Using -uppercase in the set up of your Citadel/UX has a tendency to do weird things -like broadcast your net messages in triplicate, for example. - -Once you've added your network node, tab down to 'ok' and dnetsetup will -take you back to the main screen. From here you need to edit your -network node. Select option "E"dit and you should only have one node -listed at this point: - - Select the node you wish to edit -*********************************************** -* splash * -*********************************************** - -*********************************************** -* * -*********************************************** - - -Hit ok, at this point. You'll be given another list of options: - - - Editing splash -************************************************ -* LIST List currently shared rooms * -* SHARE Add a shared room * -* UNSHARE Stop sharing a room * -* EXIT Return to main menu * -************************************************ - - -This list is fairly self evident, but I'll explain it anyhow: - - LIST shows you all the rooms you've setup to network with - this node. - SHARE allows you to ADD a networked room to network with this - node. - UNSHARE Stops networking specified rooms with this node. - - -Simple enough, right? Ok, let's add a room. Remember that list of -networked rooms? It's a good idea to have printed that out at this -point. Here's where the fun begins. I'm only going to show how to add -one room, all the rest you can do yourself. - -Select "S"HARE: - - Enter name of room to share: -******************************************** -*House of Pork * -******************************************** - - -******************************************** -* * -******************************************** - - Select ok, and bang, you've setup up the first portion of networking. - Special note: The case of the rooms must be EXACT, so watch your - capitalization!! - - - When you're all finished adding the networked rooms that you'd like to - share, jump out to the main menu and exit. You've finished (almost) with - the networking part. Now we have to create the new rooms on the bbs - itself. - - - 4. Login to your BBS and type .er (. Enter a new Room). - We'll assume for sake of argument that you are creating a publicly - accessible, non directory, networked room: - -Lobby> . Enter a new Room -Name for new room? House of Pork (again, watch your case!) -Help -<1>Public room -<2>Guess-name room -<3>Passworded room -<4>Invitation-only room -Enter room type: 1 -"House of Pork", a public room. -Install it? (y/n) : Yes -(0 messages) -House of Pork> - - Ok great. We've created it. Now, let's make it a networked room. Note - that at the end of the roomname we've got a > instead of a ). - When editing a room all options in [] are defaults, and you can simply - hit enter to accept them. - -. Aide Edit this room -Room name [House of Pork]: -Private room [No]? -Preferred users only [No]? -Read-only room [No]? -Directory room [No]? -Permanent room [No]? Yes - (note that directory and networked rooms are ALWAYS - permanent, by default, however just to be safe, - select 'y'es here.) -Network shared room [No]? Yes -Automatically make all messages anonymous [No]? -Ask users whether to make messages anonymous [No]? - (note: This assumes that the networked rooms you're - creating is NOT an anon room) -Room aide (or 'none') [none]: - Up to you, on this one. -Save changes (y/n)? Yes -Ok. - - There. You've created and edited a network room. You'll note that the - name's changed from: House of Pork> to House of Pork). Once you see the - ) you've done it. :) - - - - There ya go. You've now successfully shared and created a node and a - network rooms. All set. - - Well no. Firstly you need to make sure that you've been shared on the - other node. Make sure and check on it, before going any farther. We'll - assume for sake of argument that everything's set up on your remote node - and you're all ready to go. - - There are two commands that are ABSOLUTELY vital for processing your - networked messages. These are: - - netproc - netpoll - - Netproc simply takes any messages that you've placed in a networked room - on your BBS and spools them to an outbound queue: - - ~bbs/network/spoolout - - netpoll is the command that actually goes out to your remote network node - and snags new messages. Once it has them it brings them back into Citadel/UX - and parses them out to their proper rooms. Simple enough. - - The command netproc runs by itself, no flags needed. To run netpoll, - you need to know a little bit about your remote node. - - What port is Citadel/UX running on? (Normally 504, but there are some strange - people out there) - What is the networking password? - - Once you have those, polling for your messages is easy, provided - everything's been set up properly. Syntax for netpoll: - - netpoll bbs.address.org Citadel/UX port # networking password - - Eg: netpoll splash.citadelia.org 504 netpswd - - (No the above is NOT my password. We'll get into that later.) - - Once you run netpoll as stated above this should happen: -200 splash Citadel/UX server ready. -Connected to: splash (Splash BBS) Indianapolis, IN -200 authenticated as network node 'yournodename' -200 483 -200 Ok -200 Ok - - What this says is that you've connected to the splash server - and that you've gotten the right password. - 483 is the byte count of the messages that are coming down to you. - The rest is stating that your messages have been uploaded and that - you've terminated connection with the server. At this point you - should check your networked rooms on the BBS and see what new messages - await. - You might want to automate this procedure by running it as a cron task. - - Here's mine: - - # Citadel/UX netprocessing tool - 0,15,30,45 * * * * /home/citux/citadel/netproc > /dev/null 2>&1 - # Citadel/UX network message sender/receiver - 5 * * * * /home/citux/citadel/netpoll dogpound2.citadelia.org 504 netpswd > /dev/null 2>&1 - - I hate having messages pop up everytime netproc/netpoll runs so I - redirect the output to /dev/null. - Every 15 minutes netproc runs and processes outbound messages. - At 5 minutes after each hour netpoll sends all messages and imports new - ones. - - At this point we're all done. Oh I admit that you might run into - some problems, and if you do you can feel free to mail - smw@splash.citadelia.org with the subject Citadel Problems. - - - Visit splash's Citadel/UX system at:splash.citadelia.org, login as test. - - -Steve Williams (Patriot) diff --git a/citadel/sysop.txt b/citadel/sysop.txt deleted file mode 100644 index 6be2b9eb2..000000000 --- a/citadel/sysop.txt +++ /dev/null @@ -1,269 +0,0 @@ - Citadel/UX Sysop/Aide Manual - See copyright.doc for copyright information - - - OVERVIEW - - Citadel/UX, when installed properly, will do most of its maintenance by -itself. The message file loops upon itself forever, scrolling off old messages -to make space for new ones. The room files work in the same way. Other types -of maintenance can be done by cron. I have left my system unattended for long -periods of time without any software failures. - - The system has seven access levels. Most users are at the bottom and have no -special privileges. Aides are selected people who have special access within -the Citadel program. Room Aides only have this access in a certain room. -Preferred users can be selected by Aides for access to preferred only rooms. A -sysop is anyone who has access to the various sysop utilities - these are in -their own executable files, which should have their permissions set to allow -only sysops to run them. I recommend either creating a sysops group in -/etc/group, or using some other existing group for this purpose. - - Aides have access to EVERY room on the system, public and private (all -types). They also have access to commands starting with .ide in addition -to being able to delete and move messages. The system room, Aide>, is -accessible only by those designated by aides. - - - AIDE COMMANDS - - Aides have the following commands available to them that are not available -to normal users. They are: - - .ide dit room Allows an aide to change certain parameters of - the current room. Lobby>, Mail>, and Aide> may - not be edited. - .ide ile elete If the current room has a directory, an Aide or - room Aide can delete files from the directory - using this command. - .ide ile ove Moves a file from the directory of the current - room to the directory of another room. If there - is a file description attached, it is moved also. - .ide ile end... This will send a copy of a file in the current - room's directory to the directory of the same - room on another system on the network. The other - system must be running Citadel/UX or another - program supporting IGnet/Open file transfers. - .ide edit nfo file Creates an info file for the current room, which - will be displayed to the user when any of three - conditions exist: the first time the user enters - the room, the next time the user enters the room - after the file has been changed, and when the - .ead nfo file command is entered. - .ide ill room Deletes the current room. Lobby>, Mail>, and - Aide> may not be deleted. - .ide essage edit: Allows you to change various system banners, such - as the 'hello' logon greeting. - .ide

ost Enter a message using any user name. - .ide oom nvite Invites a user to the room if it is private. - .ide oom ickOut Kicks a user out of the room if it is private. - .ide ystem config Edits global system configuration. - .ide serEdit Edits certain parameters of a user's account. - .ide alidate newusers Lists users who have recently registered and - prompts for new access levels. - .ide hoKnowsRoom Lists all users who have access to, and who have - not chosen to zap, the current room. - - - EDITING ROOMS - - This command allows any aide to change the parameters of a room. Go to -the room you wish to edit and enter the .AE command. A series of prompts will -be displayed. The existing parameters will be displayed in brackets; simply -press return if you want to leave any or all of them unchanged. - -Room name [IG's Fun Room]: - - ...the name of the room. - -Private room [Yes]? - - ...enter Yes if you wish to restrict access to the room, or no if the room -is to be accessible by all users. Note that Citadel doesn't bother users -about access to rooms every time they need to access the room. Once a user -gains access to a private room, it then behaves like a public room to them. -The following four questions will only be asked if you selected Private... - -Accessible by guessing room name [No]? - - ...if you enter Yes, the room will not show up in users' nown rooms -listing, but if they .oto the room (typing the room's full name), they -will gain access to the room. - -Accessible by entering a password [No]? -Room password [mypasswd]: - - ...this adds an additional layer of security to the room, prompting users -for a password before they can gain access to the room. - -If you did not select guessname or passworded, then the only way users can -access the room is if an Aide explicitly invites them to the room using the -.ide oom nvite user command. - -Cause current users to forget room [No] ? No - - Enter Yes if you wish to kick out anyone who currently has access to -the room. - -Preferred users only [No]? No - - Enter Yes if you wish to restrict the room to only users who have level 5 -(Preferred User) status (and Aides too, of course). You should make the room -public if you intend to do this, otherwise the two restrictions will be -COMBINED. - -Read-only room [No]? No - - If you set a room to Read-Only, then normal users will not be allowed to -post messages in it. Messages may only be posted by Aides, and by utility -programs such as the networker and the "aidepost" utility. This is useful -in situations where a room is used exclusively for important announcements, -or if you've set up a room to receive an Internet mailing list and posting -wouldn't make sense. Other uses will, of course, become apparent as the -need arises. - -Now for a few other attributes... - -Directory room [Yes]? Yes - - ...enter Yes if you wish to associate a directory with this room. If you -enter Yes, you will also be prompted with the following four questions: - -Directory name [mydirname]: - - ...the name of the subdirectory to put this room's files in. The name of -the directory created will be /files/. - -Uploading allowed [Yes]? Yes - - ...enter Yes if users are allowed to upload to this room. - -Downloading allowed [Yes]? Yes - - ...enter Yes if users are allowed to download from this room. - -Visible directory [Yes]? Yes - - ...enter Yes if users can read the directory of this room. - - -Network shared room [No]? No - - ...you can share a room over a network without setting this flag, and -vice versa, but what this flag does is twofold: - 1. It prevents people with no network access from entering messages here - 2. Messages are displayed with the name of their originating system in - the header. - -Permanent room [No]? No - - ...the sysop utilities have an option to purge rooms which have not been posted -in for two weeks. If you wish to keep this from happening to a particular room, you -can set this option. (Keep in mind that Lobby>, Mail>, Aide>, any network rooms, and -any directory rooms are automatically permanent.) - - -Anonymous messages [No]? No -Ask users whether to make messages anonymous [No]? No - - ...you can have rooms in which all messages are automatically anonymous, -and you can have rooms in which users are prompted whether to make a message -anonymous when they enter it. - -Room aide [Joe Responsible]: - - ...on larger systems, it helps to designate a person to be responsible for -a room. Room Aides have access to a restricted set of Aide commands, ONLY -when they are in the room in which they have this privilege. They can edit -the room, delete the room, delete and move messages, and invite or kick out -users (if it is a private room), but they cannot perform aide commands that -are not room-related (such as changing users access levels). - -Save changes (y/n)? Yes - - ...this gives you an opportunity to back out, if you feel you really -messed things up while editing. - - - FILE DIRECTORIES - - If you have created any directory rooms, you can attach file descriptions to -the filenames through a special file called "filedir". Each line contains -the name of a file in the directory, followed by a space and then a description -of the file, such as: - - myfile.txt This is a description of my file. - phluff A phile phull of phluff! - - ...this would create file descriptions for the files 'myfile.txt' and 'phluff' -which would be displayed along with the directory. It should also be noted -that when users upload files to your system, they will be prompted for file -descriptions, which will be added to the 'filedir' file. If one does not -exist, it will be created. - - - EDITING USERS - - This command allows any aide to change certain parameters of any user's -account. Entering this command will ask for the name of a user to edit, and -then prompt with the user's current access level, then ask for the new one. - 0 - Marked for deletion - 1 - New unvalidated user - 2 - Problem user - 3 - User with no network privileges - 4 - Normal user - 5 - Preferred user - 6 - Aide - - DELETING AND MOVING MESSAGES - - Aides have the ability to delete and move messages; however, they must have -message prompting turned on in order to do this. After each message, the -normal prompt appears: - gain, ext message, top -> - Entering will delete the message. A (y/n) prompt will appear to confirm -that you really want to delete the message. - Entering will prompt for a room to move the message to. - - - SYSOP UTILITIES - - There are a number of utilities which may be accessed from the shell. It -is up to the system operator to decide which should be "sysop" utilities and -which should be accessible to all shell users. Please see utils.doc for a -description of these programs. - - - CUSTOMIZING THE HELP FILES - - The subdirectory called "help" contains your system's help files. There's -nothing hard-coded into the system that dictates what files should be there. -Whenever a user types the command "<.H>elp" followed by the name of a help -file, it displays the contents of that help file. - - The help files that come with the system, of course, are enough to guide -a user through its operation. But you can add, change, or remove help files -to suit whatever is appropriate for your system. - - Now for the fun part. There are several strings that you can put in help -files that will be automatically substituted with other strings. They are: - - ^nodename = The node name of your system on a Citadel/UX network - ^humannode = Human-readable node name (also your node name on C86Net) - ^fqdn = Your system's fully-qualified domain name - ^username = The name of the user reading the help file - ^usernum = The user number of the user reading the help file - ^sysadm = The name of the system administraor (i.e., you) - ^variantname = The name of the BBS software you're running - - So, for example, you could create a help file which looked like: - - "Lots of help, of course, is available right here on ^humannode. Of -course, if you still have trouble, you could always bug ^sysadm about it!" - - - CONCLUSION - - For more information, visit the Citadel/UX web site at UNCENSORED! BBS - http://uncnsrd.mt-kisco.ny.us - diff --git a/citadel/PAM.txt b/citadel/techdoc/PAM.txt similarity index 100% rename from citadel/PAM.txt rename to citadel/techdoc/PAM.txt diff --git a/citadel/upgrading.txt b/citadel/upgrading.txt deleted file mode 100644 index 7bde7314d..000000000 --- a/citadel/upgrading.txt +++ /dev/null @@ -1,51 +0,0 @@ - - UPGRADING AN EXISTING CITADEL/UX INSTALLATION - --------------------------------------------- - - The process by which you will upgrade an older version of Citadel/UX to the -current one depends on which version you have installed. - - - - Version 1.xx, 2.xx, or 3.xx - --------------------------- - - Upgrading from these versions is no longer supported. Sorry. - - - - Version 4.xx, 5.0x, or 5.1x - --------------------------- - - Obtain the "export5" utility from any FTP site which carries Citadel. This -package contains instructions on how to 'export' your old databases, and then -'import' them into Citadel/UX 5.54. - - NOTE: if you have any of these versions installed, you must first upgrade -to Citadel/UX v5.54, and then upgrade from 5.54 to the latest version. The -file formats for 5.60 have changed drastically, and it is unfeasible to build -a one-step migration path. - - - - Version 5.5x - ------------ - - Upgrading from 5.5x to 5.60 is easy. Unpack the source and run the -configure script using "--with-prefix=/your/citadel/directory" just like you -had done for the previous version. After the compile is finished, shut down -the running copy of citserver and do a "make install-exec". This command -installs the new programs without overwriting any of your data files, system -banners, or anything else. - - - - - ALL VERSIONS - ------------ - - After you upgrade, you MUST run "setup" before starting citserver! If you do -not do so, the server will notice the older version stamp on your data files -and refuse to run. Run setup, then start citserver. - - diff --git a/citadel/utils.txt b/citadel/utils.txt deleted file mode 100644 index ead1f1eb5..000000000 --- a/citadel/utils.txt +++ /dev/null @@ -1,126 +0,0 @@ - Citadel/UX Utilities Manual - See copyright.doc for copyright information - - - OVERVIEW - - The following utilities will be discussed in this document: - aidepost Post standard input to the Aide> room - whobbs Who is on the system - stats Print the calling statistics & graph - msgform Format a binary message to the screen (stdin or in a file) - userlist Print the userlist - readlog Read the caller log - sendcommand Send a server command - - It is up to you to decide which utilities should be made accessible only -to sysops. It is important that you set the file permissions correctly. All -utilities should have access to the BBS data files. We will attempt to -address each program individually. - - - AIDEPOST - - The nature of this program is rather simple. Standard input (stdin) is -converted into a message, filed in the main message file (msgmain), and posted -in the Aide> room. This is useful for keeping transcripts of system activity -that has to do with the BBS. You might even elect to send all of your system -logs there, too. - - aidepost also accepts the usage "aidepost -rTargetRoom", where TargetRoom -is the name of a room to which you'd like the message to be sent. - - - WHOBBS - - This program is similar to the "who" command. It lists all of the users -who are currently connected to your BBS server, either locally or across a -network. Unless you're running a standalone system, "who" and "whobbs" will -probably not have a one-to-one correspondence (unlike earlier versions of the -system). - - One thing to keep in mind is that the "whobbs" utility actually opens a -connection to the server. If the server is maxed out, whobbs will still be -able to provide a listing, because it doesn't need to log in to execute the -RWHO command. Note that whobbs does not list its own session. - - Running the ho is online command from the client does *not* call this -utility. It has this functionality built in. - - - STATS - - (NOTE: this program no longer uses the "curses" library.) It prints -various statistics on the screen based on the calllog file, such as number -of connects, number of logins, number of logouts, number of disconnects, -bad password attempts, etc. All statistics are provided in three figures: -times per call, times per day, and total times. - After this screen appears, you may press return for the next screen. This -is a graphic representation of system usage, broken down into 20 minute -segments of the day. This will show you when your peak usage is. - Press return again and the stats program will list your system's top -20 callers. - The final screen lists the twenty users with the highest post per call -ratios. Unline the other screens, this statistic is extracted from the user -file itself rather than the call log. - - stats may be called with the "-b" option to run in batch mode. In this case, -it skips all the prompts and just prints everything out in one bulk output. -Or it may be called with the "-p" option to only print the Post-to-Call -ratios and nothing else. - - - MSGFORM - - On occasion, I have had messages in Citadel/UX binary format that I have -wanted to view. Or needed a way to view a network spool file. Or wanted to -directly examine parts of msgmain. This program is a simple message formatter. - msgform reads standard input, scanning for binary messages, starting -with an byte and ending after the final NULL, and print as many as it -finds until it encounters EOF. - You could use this utility along with netproc to provide printouts or -archives of certain rooms. - - - USERLIST - - This is a program to print the userlist. There are two flags that may be -set when running this program. When called without any arguments, userlist -will display all users (except those who have chosen to be unlisted), their -user numbers, times called, messages posted, screen width, and date of their -most recent call. - - userlist is simply the same user listing code that is in the client, made -into a standalone utility for convenience. - - - READLOG - - Called without any arguments, readlog dumps the contents of the calllog -file. This file records all times the Citadel/UX program has been started, and -at what baud rate, as well as logins, proper logouts, loss of carrier (SIGHUP), -bad password attempts, and new user logins. - - - SENDCOMMAND - - sendcommand will interpret its arguments (except for "-hDIRNAME") as a -server command, which is sent to the server. Commands which require textual -input will read it from stdin. Commands which generate textual output will -be sent to stdout. - - This utility is intended to be used to enable Citadel server commands to be -executed from shell scripts. Review the script called "weekly" which ships -with the Citadel distribution for an example of how this can be used. - - NOTE: be sure that this utility is not world-executable. It connects to the -server in privileged mode, and therefore could present a security hole if not -properly restricted. - - - -------------------------------------------------------------------------- - - That should cover all of the included utilities. - For more information, visit the Citadel/UX web site at UNCENSORED! BBS - http://uncnsrd.mt-kisco.ny.us - -- 2.39.2