--- /dev/null
+ 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 <C>hat is now fully integrated into both the client and server.
+
+ New <P>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 <sgtty.h>
+in addition to SysV-style <termio.h>. 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 <S>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 <F>ile <D>elete -- delete it
+ <.A>ide <F>ile <M>ove -- move it to another room
+ <.A>ide <F>ile <S>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
+
+
--- /dev/null
+ 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.
--- /dev/null
+ 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 <command> [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.)
--- /dev/null
+ 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 .<A>ide <E>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).
--- /dev/null
+ Citadel/UX Networking Documentation
+ (A brief overview on setup)
+ Written by Steve Williams (Patriot @ pixel)
+
+
+ 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.citadel.org and pixel.citadel.org
+are your best bets.
+
+Below is a list of the networked rooms (most of them) that PixelBBS
+carries. Note the ) after each room name. This designates that room as a
+networked room.
+
+ Rooms with no new messages on Networked Rooms:
+A/V Talk) Creation/Evolution) babylon 5) Jokes) Networking)
+Astronomy) Books: Sci-Fi) Food) MP3 Universe) TrekNet) PaganNet)
+net.Religion) Music) Programming) Uncensored Magic) Politica) Movies)
+Video Games) Star Wars) Linux) Pets) Swagazine) Global Address Book)
+Sports) Slimies 2000) Science Fiction) Sysop Stuff) Raising Kids)
+Unix) Hot Pink Amoebas) Dreams) Buy/Sell) Tech Area) Citadel
+Development) Linux Today) Citadel/UX) Gay/Lesbian) Of the Weird)
+Magic-The Gathering) The Local Net) Books) Netlinks) Software
+Questions) SCA) Abortion) NASA News) Misheard Lyrics) Snausages)
+Macintosh) Gateway) Microsoft Bashing) IGnet Unlimited) BBS Ads)
+
+
+
+
+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@pixel.citadel.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 > <Cancel> *
+ **********************************************************************
+
+
+
+
+
+ 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 PixelBBS that would be:
+
+ pixel
+
+ 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
+***********************************************
+* pixel *
+***********************************************
+
+***********************************************
+* <OK> <Cancel> *
+***********************************************
+
+
+Hit ok, at this point. You'll be given another list of options:
+
+
+ Editing pixel
+************************************************
+* 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 *
+********************************************
+
+
+********************************************
+* <OK> <Cancel> *
+********************************************
+
+ 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 pixel.citadel.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 pixel Citadel/UX server ready.
+Connected to: pixel (PixelBBS) Christiana, DE
+200 authenticated as network node 'yournodename'
+200 483
+200 Ok
+200 Ok
+
+ What this says is that you've connected to the pixel 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.citadel.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@pixel.citadel.org with the subject Citadel Problems.
+
+
+ Visit PixelBBS at:pixel.citadel.org, login as bbs.
+ Or, if you prefer: http://pixel.citadel.org:2000
+
+ -Steve Williams (Patriot)
--- /dev/null
+ 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 .<A>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:
+
+ .<A>ide <E>dit room Allows an aide to change certain parameters of
+ the current room. Lobby>, Mail>, and Aide> may
+ not be edited.
+ .<A>ide <F>ile <D>elete If the current room has a directory, an Aide or
+ room Aide can delete files from the directory
+ using this command.
+ .<A>ide <F>ile <M>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.
+ .<A>ide <F>ile <S>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.
+ .<A>ide edit <I>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
+ .<R>ead <I>nfo file command is entered.
+ .<A>ide <K>ill room Deletes the current room. Lobby>, Mail>, and
+ Aide> may not be deleted.
+ .<A>ide <M>essage edit: Allows you to change various system banners, such
+ as the 'hello' logon greeting.
+ .<A>ide <P>ost Enter a message using any user name.
+ .<A>ide <R>oom <I>nvite Invites a user to the room if it is private.
+ .<A>ide <R>oom <K>ickOut Kicks a user out of the room if it is private.
+ .<A>ide <S>ystem config Edits global system configuration.
+ .<A>ide <U>serEdit Edits certain parameters of a user's account.
+ .<A>ide <V>alidate newusers Lists users who have recently registered and
+ prompts for new access levels.
+ .<A>ide <W>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' <K>nown rooms
+listing, but if they .<G>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
+.<A>ide <R>oom <I>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 <your BBS directory>/files/<room dir name>.
+
+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:
+ <A>gain, <N>ext message, <S>top ->
+ Entering <D> will delete the message. A (y/n) prompt will appear to confirm
+that you really want to delete the message.
+ Entering <M> 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
+
--- /dev/null
+
+ 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.
+
+
--- /dev/null
+ 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 <W>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 <FF> 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
+
projects / citadel.git / commitdiff