* Updated some of the documentation

diff --git a/citadel/ChangeLog b/citadel/ChangeLog
index 02d05150279aa6c746a9d9e8bfbff1997a2d7194..08bd1563d18762df7eef90e40b4b6b8620382137 100644 (file)
--- a/citadel/ChangeLog
+++ b/citadel/ChangeLog
@@ -1,4 +1,7 @@
  $Log$
  $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
  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


@@ -2868,4 +2871,3 @@ Sat Jul 11 00:20:48 EDT 1998 Nathan Bryant <bryant@cs.usm.maine.edu>
 
 Fri Jul 10 1998 Art Cancro <ajc@uncensored.citadel.org>
        * Initial CVS import 
 
 Fri Jul 10 1998 Art Cancro <ajc@uncensored.citadel.org>
        * Initial CVS import 

-

diff --git a/citadel/docs/citadel-with-berkeley-db.txt b/citadel/docs/citadel-with-berkeley-db.txt
index 6ce13fe90bbdec7e37bcf7ee91d1cc90049dab6d..b7fefdd98c3154cbb960871551c0d5f14065cf48 100644 (file)
--- a/citadel/docs/citadel-with-berkeley-db.txt
+++ b/citadel/docs/citadel-with-berkeley-db.txt
@@ -10,7 +10,7 @@ Abstract
 History and introduction
 
    From its inception in 1987 until versions 5.1x in 1998,
 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
    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


@@ -32,13 +32,14 @@ History and introduction
      * Recovery utilities
        
    It is clear that Berkeley DB is a better choice than GDBM for a
      * 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
 Building Citadel/UX with DB support
 
    Here are the steps required to get Citadel/UX running with Berkeley


@@ -100,17 +101,15 @@ Care and feeding of your DB-powered Citadel
    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
    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
 References
 
    1. http://uncensored.citadel.org/citadel

diff --git a/citadel/docs/copyright.txt b/citadel/docs/copyright.txt
index add38c061528c1d31ef4e6026977414ad1a954ed..88ce5de3cc8f8af8c691682571c4ecaadacc3076 100644 (file)
--- a/citadel/docs/copyright.txt
+++ b/citadel/docs/copyright.txt
@@ -9,6 +9,7 @@
      Nathan Bryant      (build system, security, database access, and others)
      Art Cancro         (overall system design and lead developer)
      Brian Costello     (cosmetics, additional commands)
      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)
      Daniel Malament    (string compare function for IMAP server)
      Stu Mark           (IGnet/Open protocol design)
      Ben Mehlman        (additional client features)

diff --git a/citadel/docs/import-export.txt b/citadel/docs/import-export.txt
index 9a332e6d263fca2841b896f1d9d57e3219b2c406..a34ceae6176728884093e8e2ef5b9dc7d4001e0e 100644 (file)
--- a/citadel/docs/import-export.txt
+++ b/citadel/docs/import-export.txt
@@ -17,9 +17,8 @@ load" to some database gurus.)
 -> Your computer crashed, lost power, etc. and you suspect that your
    databases have become corrupted.
  
 -> 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)

  
 
  
  
 
  

diff --git a/citadel/docs/install.txt b/citadel/docs/install.txt
index be1743726300209b0ae86fc1b3fe2956db26828d..174026b9417f013d55950f1626c936d36801e25b 100644 (file)
--- a/citadel/docs/install.txt
+++ b/citadel/docs/install.txt
@@ -10,15 +10,13 @@ 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
 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)
   
     - 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
     - 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
     - Documentation
  
  Some knowledge of the Unix system is necessary to install and manage the

diff --git a/citadel/techdoc/hack.txt b/citadel/techdoc/hack.txt
index 649efa5260a625093ba7319d2a926ddf23886429..90bbe404adc93d9f3453f27771ac62035071a8f5 100644 (file)
--- a/citadel/techdoc/hack.txt
+++ b/citadel/techdoc/hack.txt
@@ -170,23 +170,19 @@ The above discussion should make the function of the fields reasonably clear:
     cycling under control.
 
 (Uncoincidentally) the format used to transmit messages for networking
     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
  
 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
  
  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)
   
 
                    "Room" records (quickroom)