'\" t
.\" Title: cnid_dbd
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.74.3 <http://docbook.sf.net/>
-.\" Date: 21 Mar 2009
-.\" Manual: Netatalk 2.1
-.\" Source: Netatalk 2.1
+.\" Generator: DocBook XSL Stylesheets v1.78.0 <http://docbook.sf.net/>
+.\" Date: 01 Jan 2012
+.\" Manual: Netatalk 3.0
+.\" Source: Netatalk 3.0
.\" Language: English
.\"
-.TH "CNID_DBD" "8" "21 Mar 2009" "Netatalk 2.1" "Netatalk 2.1"
+.TH "CNID_DBD" "8" "01 Jan 2012" "Netatalk 3.0" "Netatalk 3.0"
+.\" -----------------------------------------------------------------
+.\" * Define some portability stuff
+.\" -----------------------------------------------------------------
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" http://bugs.debian.org/507673
+.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.SH "NAME"
cnid_dbd \- implement access to CNID databases through a dedicated daemon process
.SH "SYNOPSIS"
-.HP \w'\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR\ 'u
-\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR \fIdbdir\fR \fIctrlfd\fR \fIclntfd\fR \fIlogconfig_string\fR
+.HP \w'\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR\fBcnid_dbd\fR\fB\fR\ 'u
+\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR
+.br
+\fBcnid_dbd\fR\fB\fR \-v | \-V
.SH "DESCRIPTION"
.PP
\fBcnid_dbd\fR
\fBcnid_dbd\fR
is never started via the command line or system startup scripts but only by the
\fBcnid_metad\fR
-daemon\&. There is at most one instance of
+daemon\&. There is one instance of
\fBcnid_dbd\fR
per netatalk volume\&.
.PP
\fBcnid_dbd\fR
uses the
-\fBBerkleley DB\fR
+\fBBerkeley DB\fR
database library and uses transactionally protected updates\&. The
\fBdbd\fR
backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly\&.
.PP
\fBcnid_dbd\fR
-uses the same on\-disk database format as the
-\fBcdb\fR
-backend\&. It is therefore possible to switch between the two backends as necessary\&.
-.PP
-\fBcnid_dbd\fR
inherits the effective userid and groupid from
\fBcnid_metad\fR
on startup, which is normally caused by
\fBafpd\fR
serving a netatalk volume to a client\&. It changes to the
-\fBBerkleley DB\fR
+\fBBerkeley DB\fR
database home directory
\fIdbdir\fR
that is associated with the volume\&. If the userid inherited from
\fIctrlfd\fR\&.
.PP
\fBcnid_dbd\fR
-uses
-\fBlogconfig_string\fR
-which is passed from
-\fBcnid_metad\fR
-to configure its logging output\&.
-.PP
-\fBcnid_dbd\fR
can be configured to run forever or to exit after a period of inactivity\&. If
\fBcnid_dbd\fR
receives a TERM or an INT signal it will exit cleanly after flushing dirty database buffers to disk and closing
-\fBBerkleley DB\fR
+\fBBerkeley DB\fR
database environments\&. It is safe to terminate
\fBcnid_dbd\fR
this way, it will be restarted when necessary\&. Other signals are not handled and will cause an immediate exit, possibly leaving the CNID database in an inconsistent state (no transactions) or losing recent updates during recovery (transactions)\&.
.PP
The
-\fBBerkleley DB\fR
+\fBBerkeley DB\fR
database subsystem will create files named log\&.xxxxxxxxxx in the database home directory
-\fIdbdir\fR, where xxxxxxxxxx is a monotonically increasing integer\&. These files contain ithe transactional database changes\&. They will be removed regularily, unless the
+\fIdbdir\fR, where xxxxxxxxxx is a monotonically increasing integer\&. These files contain the transactional database changes\&. They will be removed regularly, unless the
\fBlogfile_autoremove\fR
option is specified in the
\fIdb_param\fR
-configuration file (see below)\&.
+configuration file (see below) with a value of 0 (default 1)\&.
+.SH "OPTIONS"
.PP
-Do not use
-\fBcnid_dbd\fR
-for databases on NFS mounted file systems\&. It makes the whole point of securing database changes properly moot\&. Use the dbdir: Option in the appropriate
-\fBAppleVolumes\fR
-configuration file to put the database onto a local disk\&.
+\fB\-v, \-V\fR
+.RS 4
+Show version and exit\&.
+.RE
.SH "CONFIGURATION"
.PP
\fBcnid_dbd\fR
.RS 4
If set to 0, unused Berkeley DB transactional logfiles (log\&.xxxxxxxxxx in the database home directory) are not removed on startup of
\fBcnid_dbd\fR
-and on a reqular basis\&. Default: 1\&.
+and on a regular basis\&. Default: 1\&.
.RE
.PP
\fBcachesize\fR
\fBdb_stat\fR
utility with the
\fB\-m\fR
-option that comes with Berkely DB can help you determine wether you need to change this value\&. The default is pretty conservative so that a large percentage of requests should be satisfied from the cache directly\&. If memory is not a bottleneck on your system you might want to leave it at that value\&. The
+option that comes with Berkley DB can help you determine ether you need to change this value\&. The default is pretty conservative so that a large percentage of requests should be satisfied from the cache directly\&. If memory is not a bottleneck on your system you might want to leave it at that value\&. The
\fBBerkeley DB Tutorial and Reference Guide\fR
has a section
\fBSelecting a cache size\fR
.RE
.SH "UPDATING"
.PP
-In order to update between Netatalk releases using different BerkeleyDB library versions, follow this steps:
+Note that the first version to appear
+\fIafter\fR
+Netatalk 2\&.1 ie Netatalk 2\&.1\&.1, will support BerkeleyDB updates on the fly without manual intervention\&. In other words Netatalk 2\&.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before\&. That means it can\*(Aqt upgrade a 2\&.0\&.x version because that one didn\*(Aqt prepare the database\&.
+.PP
+In order to update between older Netatalk releases using different BerkeleyDB library versions, follow this steps:
.sp
.RS 4
.ie n \{\
.\}
Start the the new version of Netatalk
.RE
-.PP
-Note that the first version to appear
-\fIafter\fR
-Netatalk 2\&.1 ie Netatalk 2\&.1\&.1, will support BerkeleyDB updates on the fly without manual intervention\&. In other words Netatalk 2\&.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before\&. That means it can\'t upgrade a 2\&.0\&.x version because that one didn\'t prepare the database\&.
.SH "SEE ALSO"
.PP
\fBcnid_metad\fR(8),