$Log$
+ Revision 580.77 2001/11/17 19:55:08 ajc
+ * Updated some of the documentation
+
Revision 580.76 2001/11/16 04:43:12 ajc
* Eliminated the sock_puts_crlf() function and ensured that all SMTP client
commands are sent out using a single sock_write() call. There are broken
Fri Jul 10 1998 Art Cancro <ajc@uncensored.citadel.org>
* Initial CVS import
-
History and introduction
From its inception in 1987 until versions 5.1x in 1998,
- Citadel/UX utilized a built-in data store loosely modelled after Jeff
+ Citadel/UX utilized a built-in data store loosely modeled after Jeff
Prothero's original Citadel-CP/M design. But as Citadel systems
scaled upwards, supporting Internet-connected systems with heavy
concurrent use, and aspirations of becoming a world-class
* Recovery utilities
It is clear that Berkeley DB is a better choice than GDBM for a
- high-utilization database that requires crash recovery. Beginning on
- December 7, 2000, Citadel/UX supports the use of either GDBM or DB as
- the data store. As of July 1, 2001, DB has become the default. We
- recommend DB in preference to GDBM wherever possible because there is
- no effective way to recover from corrupted GDBM files.
-
-
+ high-utilization database that requires crash recovery. Citadel/UX can
+ currently be built with either DB or GDBM as the data store; however,
+ THE USE OF GDBM IS DEPRECATED AND STRONGLY DISCOURAGED. If you are
+ bringing up a new site you should use Berkeley DB, period. If you are
+ maintaining an existing site using GDBM you should migrate it to Berkeley
+ DB as soon as possible.
+
+
Building Citadel/UX with DB support
Here are the steps required to get Citadel/UX running with Berkeley
You may think that it's going to keep writing to that one log file
forever, but don't panic; when the log file gets sufficiently large it
will switch over to another one. As a general rule of thumb, your
- archival procedure should be to back up to tape every day, removing log
- files after backups as described above. Berkeley DB supports "hot"
- backups; in other words, you are permitted to back up your Citadel data
- without having to first shut down the Citadel server, AS LONG AS YOU
- COPY THE DATA FILES BEFORE THE LOG FILES. One way to ensure this is to
- first copy the data files to a temporary directory, then copy the log
- files to the same temporary directory, and finally back up and remove
- the temporary directory. This temporary-directory procedure also makes
- it easy to determine which log files made it onto the backup when
- determining what is safe to remove. (See above.)
-
+ archival procedure should be to back up to tape every day. Berkeley DB
+ supports "hot" backups; in other words, you are permitted to back up your
+ Citadel data without having to first shut down the Citadel server, as long
+ as you copy the data files before the log files.
+
+ And don't worry about your system filling up with log files; the Citadel
+ server will automatically remove them when they're no longer needed.
+
+
References
1. http://uncensored.citadel.org/citadel
Nathan Bryant (build system, security, database access, and others)
Art Cancro (overall system design and lead developer)
Brian Costello (cosmetics, additional commands)
+ Andru Luvisi (troubleshooting and development assistance)
Daniel Malament (string compare function for IMAP server)
Stu Mark (IGnet/Open protocol design)
Ben Mehlman (additional client features)
-> Your computer crashed, lost power, etc. and you suspect that your
databases have become corrupted.
--> You want to switch to a different back-end data store. (Currently, the
- only data store available is the default GDBM one, but this may change
- in the not-too-distant future.)
+-> You want to switch to a different back-end data store. (For example, from
+ GDBM to Berkeley DB)
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:
+(and BBS) is an ordinary Linux 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
+ - A set of utilities for system administration and maintenance
- Documentation
Some knowledge of the Unix system is necessary to install and manage the
cycling under control.
(Uncoincidentally) the format used to transmit messages for networking
-purposes is precisely that used on disk, except that there may be any amount
-of garbage between the null ending a message and the <FF> starting the next
-one. This allows greater compatibility if slight problems crop up. The current
-distribution includes netproc.c, which is basically a database replicator;
+purposes is precisely that used on disk, serialized. The current
+distribution includes serv_network.c, which is basically a database replicator;
please see network.txt on its operation and functionality (if any).
Portability issues
- At this point, all hardware-dependent stuff has been removed from the
-system. On the server side, most of the OS-dependent stuff has been isolated
-into the sysdep.c source module. The server should compile on any POSIX
-compliant system with a full pthreads implementation and TCP/IP support. In
-the future, we may try to port it to non-POSIX systems as well.
+ Citadel/UX is 64-bit clean, architecture-independent, and Year 2000
+compliant. The software should compile on any POSIX compliant system with
+a full pthreads implementation and TCP/IP support. In the future we may
+try to port it to non-POSIX systems as well.
On the client side, it's also POSIX compliant. The client even seems to
-build ok on non-POSIX systems with porting libraries (such as the Cygnus
-Win32 stuff).
+build ok on non-POSIX systems with porting libraries (such as Cygwin).
"Room" records (quickroom)
projects / citadel.git / commitdiff