History and introduction
- From its inception in 1987 until versions 5.1x in 1988,
- Citadel/UX utilized a built-in data store loosely modelled after Jeff
+ From its inception in 1987 until versions 5.1x in 1998,
+ 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
[3]GDBM product was chosen for its simple API and its free license
(the LGPL).
- Somewhat less than trouble-free operation from 1988 through 2000,
+ Somewhat less than trouble-free operation from 1998 through 2000,
however, proved that GDBM was not the best choice. Heavily utilized
systems experienced occasional database corruption, often resulting in
repeated crashes of the Citadel server. As a result, we made the
* 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. At some point in the future, DB will become the
- default. If you are setting up a potentially busy system, we
- recommend that you use DB.
-
-
+ 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
UNIX" instructions. Make sure that you run the test suite, and
perhaps test with some of the sample applications, before moving
on.
+
+ Note that as of DB 3.1.17, DB's configure script can't check for
+ OpenBSD systems. You will need to configure DB as follows:
+
+ env CC='gcc -pthread -Di386' ../dist/configure [flags]
+
+ DB 3.3.x's configure script should not need the -Di386 flag.
+
2. Start with a clean source tree. Either unpack a fresh copy of the
source or do a "make distclean" before continuing.
3. Run the configure script: ./configure
- --with-db=/usr/local/BerkeleyDB.3.1 (Specify whatever directory
- you've actually installed DB into, of course. Also specify any
- other configure options you need at this time.)
+ (Optionally specify --with-db=DIR for whatever prefix
+ you've actually installed DB into, if you overrode DB's defaults.
+ Also specify any other configure options you need at this time.)
4. Run "make" and "make install-exec." Continue installing Citadel
as per the instructions supplied with the system.
So do you have to keep these log files around forever? No, but there
are some rules you should follow:
* Don't remove a log file if it's the only log file there.
- * Don't remove any log file that has a recent timestamp. Generally
- speaking, if it's more than a week old, and you've been running
- tape backups every day (you are doing daily backups, right?), you
- can safely remove the log file.
-
+ * If it's not listed in the output of the db_archive[9] command, it's
+ not safe to remove.
+ * After a successful backup (see below) log files listed by the
+ db_archive[9] command may be removed to conserve disk space, if
+ those log files were backed up.
+
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, and only
- delete log files that are older than your oldest backup. 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.
-
+ 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
6. http://www.sleepycat.com/
7. http://www.sleepycat.com/docs/ref/build_unix/intro.html
8. http://pixel.citadel.org/citadel/docs/export.html
+ 9. http://www.sleepycat.com/docs/utility/db_archive.html
projects / citadel.git / blobdiff