<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>General Database Directives</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="LDAP Linux HOWTO"
HREF="index.html"><LINK
REL="UP"
TITLE="Configuring the LDAP Server"
HREF="config.html"><LINK
REL="PREVIOUS"
TITLE="General Backend Directives"
HREF="generalbedirect.html"><LINK
REL="NEXT"
TITLE="BDB Database Directives"
HREF="bdbdirect.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>LDAP Linux HOWTO</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="generalbedirect.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. Configuring the LDAP Server</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="bdbdirect.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="GeneralDBDirect"
></A
>3.4. General Database Directives</H1
><P
>Directives in this section apply only to the database in which they are
defined. They are supported by every type of database.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>database <type></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive marks the beginning of a new database instance definition.
<type> should be one of the backend types listed on the previous item.</P
><P
>Example:</P
><P
>database bdb</P
><P
>This marks the beginning of a new BDB backend database instance definition.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>readonly { on | off }</PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive puts the database into "read-only" mode. Any attempts to modify
the database will return an "unwilling to perform" error.</P
><P
>Default:</P
><P
>readonly off</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
> replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
[bindmethod={simple|kerberos|sasl}]
["binddn=<DN>"]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<password>]
[srvtab=<filename>]
</PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive specifies a replication site for this database. The uri= parameter
specifies a scheme, a host and optionally a port where the slave slapd instance can be found.
Either a domain name or IP address may be used for <hostname>. If <port> is not given,
the standard LDAP port number (389 or 636) is used.</P
><P
><B
CLASS="command"
>Note: </B
>host is deprecated in favor of the uri parameter.</P
><P
>uri allows the replica LDAP server to be specified as an LDAP URI such as
ldap://slave.example.com:389 or ldaps://slave.example.com:636 </P
><P
>The binddn= parameter gives the DN to bind as for updates to the slave slapd.
It should be a DN which has read/write access to the slave slapd's database. It must
also match the updatedn directive in the slave slapd's config file. Generally, this DN
<EM
>should not</EM
> be the same as the rootdn of the master database. Since DNs are likely to
contain embedded spaces, the entire "binddn=<DN>" string should be enclosed
in double quotes.</P
><P
>The bindmethod is simple or kerberos or sasl, depending on whether simple
password-based authentication or Kerberos authentication or SASL authentication
is to be used when connecting to the slave slapd.</P
><P
>Simple authentication should not be used unless adequate integrity and privacy
protections are in place (e.g. TLS or IPSEC). Simple authentication requires
specification of binddn and credentials parameters.</P
><P
>Kerberos authentication is deprecated in favor of SASL authentication
mechanisms, in particular the KERBEROS_V4 and GSSAPI mechanisms. Kerberos
authentication requires binddn and srvtab parameters.</P
><P
>SASL authentication is generally recommended. SASL authentication requires
specification of a mechanism using the saslmech parameter. Depending on the
mechanism, an authentication identity and/or credentials can be specified using
authcid and credentials respectively. The authzid parameter may be used to
specify an authorization identity.</P
><P
>Check this URL for additional details: <A
HREF="http://www.openldap.org/doc/admin22/replication.html"
TARGET="_top"
>Replication with Slurpd</A
>.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>replogfile <filename></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive specifies the name of the replication log file to which slapd
will log changes. The replication log is typically written by slapd and read by slurpd.
Normally, this directive is only used if slurpd is being used to replicate the database.
However, you can also use it to generate a transaction log, if slurpd is not running.
In this case, you will need to periodically truncate the file, since it will grow indefinitely
otherwise.</P
><P
>Check this URL for additional details: <A
HREF="http://www.openldap.org/doc/admin22/replication.html"
TARGET="_top"
>Replication with Slurpd</A
>.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>rootdn <dn></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive specifies the DN that is not subject to access control or
administrative limit restrictions for operations on this database. The DN
need not refer to an entry in the directory. The DN may refer to a SASL
identity.</P
><P
>Entry-based Example:</P
><P
>rootdn "cn=Manager, dc=example, dc=com"</P
><P
>SASL-based Example:</P
><P
>rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>rootpw <password></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive can be used to specify a password for the rootdn (when the
rootdn is set to a DN within the database).</P
><P
>Example:</P
><P
>rootpw secret</P
><P
>It is also permissible to provide hash of the password in RFC 2307 form.
slappasswd may be used to generate the password hash.</P
><P
>Example:</P
><P
>rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN</P
><P
>The hash was generated using the command slappasswd -s secret.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>suffix <dn suffix></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive specifies the DN suffix of queries that will be passed to this
backend database. Multiple suffix lines can be given, and at least one is
required for each database definition.</P
><P
>Example:</P
><P
>suffix "dc=example, dc=com"</P
><P
>Queries with a DN ending in "dc=example, dc=com" will be passed to this
backend.</P
><P
><B
CLASS="command"
>Note:</B
> When the backend to pass a query to is selected, slapd looks at the
suffix line(s) in each database definition in the order they appear in the
file. Thus, if one database suffix is a prefix of another, it must appear after
it in the config file. </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>syncrepl</PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive is used to keep a replicated database synchronized with the master database,
so that the replicated database content will be kept up to date with the master content.</P
><P
>This document doesn't cover in details this directive, because we're configuring a single
LDAP Server. For more informations about this directive, please visit :
<A
HREF="http://www.openldap.org/doc/admin22/syncrepl.html"
TARGET="_top"
>LDAP Sync Replication</A
>.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>updatedn <dn></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive is only applicable in a slave slapd. It specifies the DN allowed
to make changes to the replica. This may be the DN slurpd binds as when
making changes to the replica or the DN associated with a SASL identity.</P
><P
>Entry-based Example:</P
><P
>updatedn "cn=Update Daemon, dc=example, dc=com"</P
><P
>SASL-based Example:</P
><P
>updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"</P
><P
>Check this URL for additional details: <A
HREF="http://www.openldap.org/doc/admin22/replication.html"
TARGET="_top"
>Replication with Slurpd</A
>.</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>updateref <URL></PRE
></FONT
></TD
></TR
></TABLE
><P
>This directive is only applicable in a slave slapd. It specifies the URL to
return to clients which submit update requests upon the replica. If specified
multiple times, each URL is provided.</P
><P
>Example:</P
><P
>updateref ldap://master.example.net</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="generalbedirect.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="bdbdirect.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>General Backend Directives</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="config.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>BDB Database Directives</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
