Commit 4c44e350 authored by Quanah Gibson-Mount's avatar Quanah Gibson-Mount
Browse files

ITS#9200 -- 2.4 to 2.5 upgrade documentation and updates

parent eafcc405
......@@ -109,10 +109,6 @@ target entry does not support the given operation.
The password backend is only willing to perform searches. It will return an
unwilling to perform error for all other operations.
The shell backend is configurable and may support a limited subset of operations.
Check for other errors indicating a shortage of resources required by the
directory server. i.e. you may have a full disk etc
H3: ldap_*: Insufficient access
This error occurs when server denies the operation due to insufficient access.
......
......@@ -12,5 +12,48 @@ of course still be followed prior to doing any of this.
H2: {{B:cn=config}} olc* attributes
ADD MORE HERE
H2: ppolicy overlay
In OpenLDAP 2.4 the {{slapo-ppolicy}}(5) overlay relied on a separate schema file to be included for it to function.
This schema is now implemented internally in the slapo-ppolicy module. When upgrading {{slapd.conf}}(5) deployments
the include statement for the schema must be removed. For {{slapd-config}}(5) deployments, the config database
must be exported via slapcat and the old ppolicy schema removed from the export. The resulting config database
can then be imported.
H2: unique overlay
In OpenLDAP 2.4 it was possible to bypass {{slapo-unique}}(5) checks by using the manageDSAIT control as a part of the
request. This is no longer possible. To achieve the same functionalty the relax control must be used instead, and the
binding identity must have manage permissions on the entry being modified.
With OpenLDAP 2.5 a new keyword "serialize" has been added as a part of the unique_uri configuration parameter. This
will cause all write operations requiring uniqueness to be serialized so as to avoid the scenario where multiple
concurrent updates can prevent uniqueness from being enforced. See the {{slapo-unique}}(5) man page for further details.
H2: ldap and meta backends
Several deprecated configuration directives for {{slapd-ldap}}(5) and {{slapd-meta}}(5) have been removed. Configurations
using those directive must be updated to use supported directives prior to upgrade. See the {{slapd-ldap}}(5) and
{{slapd-meta}}(5) man pages from OpenLDAP 2.4 for a list of deprecated directives.
H2: shell backend
This deprecated backend has been removed from OpenLDAP 2.5. Configurations making use of this backend must remove it
prior to upgrade. The {{slapd-sock}}(5) backend is recommended as an alternative.
H2: perl and sql backends
The {{slapd-perl}}(5) and {{slapd-sql}}(5) backends are now deprecated and no longer automatically enabled with
the --enable-backends configure flag.
H2: hdb and bdb backends
The Berkeley DB based slapd-bdb and slapd-hdb backends have been removed from OpenLDAP 2.5. Deployments making use
of these backends must migrate their configurations to use {{slapd-mdb}}(5) prior to upgrade.
H2: mdb backend
Due to database format changes between OpenLDAP 2.4 and OpenLDAP 2.5 it is mandatory for existing {{slapd-mdb}}(5) databases
to be exported via an OpenLDAP 2.4 slapcat prior to upgrade. They must then be reloaded via an OpenLDAP 2.5 slapadd after
the binaries are updated. It is also advised to determine if the new {{slapd-mdb}}(5) idlexp backend directive and/or
the multival database directive should be added to the OpenLDAP 2.5 configuration prior to import.
......@@ -404,7 +404,7 @@ H3: Further Information
{{slapd-passwd}}(5)
H2: Perl/Shell
H2: Perl
H3: Overview
......@@ -413,17 +413,13 @@ into {{slapd}}(8). Any perl database section of the configuration file
{{slapd.conf}}(5) must then specify what Perl module to use. Slapd then creates
a new Perl object that handles all the requests for that particular instance of the backend.
The Shell backend to {{slapd}}(8) executes external programs to implement
operations, and is designed to make it easy to tie an existing database to the
slapd front-end. This backend is primarily intended to be used in prototypes.
H3: back-perl/back-shell Configuration
H3: back-perl Configuration
LATER
H3: Further Information
{{slapd-shell}}(5) and {{slapd-perl}}(5)
{{slapd-perl}}(5)
H2: Relay
......@@ -475,7 +471,7 @@ ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes
may use, so it may be used for integration and distribution of data on different
RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environments.
This backend is experimental.
This backend is experimental and deprecated.
H3: back-sql Configuration
......@@ -553,7 +549,7 @@ only for PostgreSQL and IBM db2.
Using {{F: sql-test000}}, files in {{F: servers/slapd/back-sql/rdbms_depend/pgsql/}}
and the man page, you should be set.
Note: This backend is experimental.
Note: This backend is experimental and deprecated.
H3: Further Information
......
......@@ -403,7 +403,6 @@ tags.
{{B:Choice of database backends}}: {{slapd}} comes with a variety
of different database backends you can choose from. They include
{{TERM:MDB}}, a hierarchical high-performance transactional database backend;
{{SHELL}}, a backend interface to arbitrary shell scripts;
and PASSWD, a simple backend interface to the {{passwd}}(5) file.
The MDB backend utilizes {{TERM:LMDB}}.
......@@ -422,7 +421,7 @@ well-defined {{TERM:C}} {{TERM:API}}, you can write your own
customized modules which extend {{slapd}} in numerous ways. Also,
a number of {{programmable database}} modules are provided. These
allow you to expose external data sources to {{slapd}} using popular
programming languages ({{PRD:Perl}}, {{shell}}, and {{TERM:SQL}}).
programming languages ({{PRD:Perl}}, and {{TERM:SQL}}).
{{B:Threads}}: {{slapd}} is threaded for high performance. A single
multi-threaded {{slapd}} process handles all incoming requests using
......
......@@ -45,24 +45,9 @@ For back-mdb this command may be ran while slapd(8) is running.
H2: Checkpointing
MORE/TIDY
If you put "checkpoint 1024 5" in slapd.conf (to checkpoint after 1024kb or 5 minutes,
for example), this does not checkpoint every 5 minutes as you may think.
The explanation from Howard is:
'In OpenLDAP 2.1 and 2.2 the checkpoint directive acts as follows - *when there
is a write operation*, and more than <check> minutes have occurred since the
last checkpoint, perform the checkpoint. If more than <check> minutes pass after
a write without any other write operations occurring, no checkpoint is performed,
so it's possible to lose the last write that occurred.''
In other words, a write operation occurring less than "check" minutes after the
last checkpoint will not be checkpointed until the next write occurs after "check"
minutes have passed since the checkpoint.
This has been modified in 2.3 to indeed checkpoint every so often; in the meantime
a workaround is to invoke "db_checkpoint" from a cron script every so often, say 5 minutes.
Setting a checkpoint is only necessary when back-mdb has the dbnosync flag set. Otherwise
it has no effect. With back-mdb the kbyte option is not implemented, meaning it will only
run a checkpoint based on the elapsed amount of minutes flag.
H2: Migration
......@@ -87,8 +72,6 @@ type are:
.{{S: }}
+{{B: Start the server}}
Obviously this doesn't cater for any complicated deployments like {{SECT: Mirror mode}} or {{SECT: N-Way Multi-Provider}},
Obviously this doesn't cater for any complicated deployments with {{SECT: N-Way Multi-Provider}},
but following the above sections and using either commercial support or community support should help. Also check the
{{SECT: Troubleshooting}} section.
......@@ -19,6 +19,13 @@ corresponding
.BR slapd\-<backend> (5)
manual pages.
.TP
.B asyncmeta
This backend performs basic LDAP proxying with respect to a set of
remote LDAP servers. It is an enhancement of the
.B ldap
backend that operates asynchronously, to prevent tying up slapd threads
while waiting for operations to complete.
.TP
.B config
This backend is used to manage the configuration of slapd at run-time.
Unlike other backends, only a single instance of the
......@@ -61,7 +68,7 @@ daemon. Only a single instance of the
backend may be defined.
.TP
.B ndb
This backend is experimental.
This backend is experimental, incomplete, and deprecated.
It uses the transactional database interface of the MySQL Cluster Engine
(NDB) to store data. Note that Oracle, which now owns MySQL, has withdrawn
support for NDB and this backend is unlikely to be developed any further.
......@@ -80,6 +87,7 @@ This backend embeds a
.BR perl (1)
interpreter into slapd.
It runs Perl subroutines to implement LDAP operations.
This backend is deprecated.
.TP
.B relay
This backend is experimental.
......@@ -93,13 +101,13 @@ for details) to rewrite the naming context of the request.
It is primarily intended to implement virtual views on databases
that actually store data.
.TP
.B shell
This backend executes external programs to implement LDAP operations.
It is primarily intended to be used in prototypes.
.TP
.B sql
This backend is experimental.
This backend is experimental and deprecated.
It services LDAP requests from an SQL database.
.TP
.B wiredtiger
This backend is experimental.
It services LDAP requests from a wiredtiger database.
.SH FILES
.TP
ETCDIR/slapd.conf
......@@ -109,6 +117,7 @@ ETCDIR/slapd.d
default slapd configuration directory
.SH SEE ALSO
.BR ldap (3),
.BR slapd\-asyncmeta (5),
.BR slapd\-config (5),
.BR slapd\-dnssrv (5),
.BR slapd\-ldap (5),
......@@ -121,8 +130,8 @@ default slapd configuration directory
.BR slapd\-passwd (5),
.BR slapd\-perl (5),
.BR slapd\-relay (5),
.BR slapd\-shell (5),
.BR slapd\-sql (5),
.BR slapd\-wt (5),
.BR slapd.conf (5),
.BR slapd.overlays (5),
.BR slapd (8).
......
......@@ -30,6 +30,12 @@ This overlay records changes on a given backend database to an LDIF log
file.
By default it is not built.
.TP
.B autoca
Automatic Certificate Authority overlay.
This overlay can generate X.509 certificate/key pairs for
entries in the directory if slapd is linked to OpenSSL.
By default it is not built.
.TP
.B chain
Chaining.
This overlay allows automatic referral chasing when a referral would
......@@ -53,6 +59,11 @@ Dynamic Directory Services.
This overlay supports dynamic objects, which have a limited life after
which they expire and are automatically deleted.
.TP
.B deref
Dereference Control.
This overlay implements the draft Dereference control. The overlay can be
used with any backend or globally for all backends.
.TP
.B dyngroup
Dynamic Group.
This is a demo overlay which extends the Compare operation to detect
......@@ -66,7 +77,8 @@ This overlay allows expansion of dynamic groups and more.
.B memberof
MemberOf.
This overlay maintains automatic reverse group membership values,
typically stored in an attribute called memberOf.
typically stored in an attribute called memberOf. This overlay
is deprecated and should be replaced with dynlist.
.TP
.B pbind
Proxybind.
......@@ -95,6 +107,10 @@ This overlay can be used with a backend database such as
to maintain the cohesiveness of a schema which utilizes reference
attributes.
.TP
.B remoteauth
Remote Authentication.
This overlay delegates authentication requests to remote directories.
.TP
.B retcode
Return Code.
This overlay is useful to test the behavior of clients when
......@@ -147,10 +163,12 @@ default slapd configuration directory
.BR ldap (3),
.BR slapo\-accesslog (5),
.BR slapo\-auditlog (5),
.BR slapo\-autoca (5),
.BR slapo\-chain (5),
.BR slapo\-collect (5),
.BR slapo\-constraint (5),
.BR slapo\-dds (5),
.BR slapo\-deref (5),
.BR slapo\-dyngroup (5),
.BR slapo\-dynlist (5),
.BR slapo\-memberof (5),
......@@ -158,6 +176,7 @@ default slapd configuration directory
.BR slapo\-pcache (5),
.BR slapo\-ppolicy (5),
.BR slapo\-refint (5),
.BR slapo\-remoteauth (5),
.BR slapo\-retcode (5),
.BR slapo\-rwm (5),
.BR slapo\-sssvlv (5),
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment