mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-12-30 11:39:34 -05:00
2.5 version updates
This commit is contained in:
Quanah Gibson-Mount
parent
0578202a26
commit
af5b31b2a7
8 changed files with 13 additions and 207 deletions
|
|
@ -5,7 +5,7 @@
|
|||
H1: Changes Since Previous Release
|
||||
|
||||
The following sections attempt to summarize the new features and changes in OpenLDAP
|
||||
software since the 2.3.x release and the OpenLDAP Admin Guide.
|
||||
software since the 2.4.x release and the OpenLDAP Admin Guide.
|
||||
|
||||
H2: New Guide Sections
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ asked on the OpenLDAP mailing lists and scenarios discussed there, we have added
|
|||
* {{SECT:Tuning}}
|
||||
* {{SECT:Troubleshooting}}
|
||||
* {{SECT:Changes Since Previous Release}}
|
||||
* {{SECT:Upgrading from 2.3.x}}
|
||||
* {{SECT:Upgrading from 2.4.x}}
|
||||
* {{SECT:Common errors encountered when using OpenLDAP Software}}
|
||||
* {{SECT:Recommended OpenLDAP Software Dependency Versions}}
|
||||
* {{SECT:Real World OpenLDAP Deployments and Examples}}
|
||||
|
|
@ -36,164 +36,32 @@ asked on the OpenLDAP mailing lists and scenarios discussed there, we have added
|
|||
Also, the table of contents is now 3 levels deep to ease navigation.
|
||||
|
||||
|
||||
H2: New Features and Enhancements in 2.4
|
||||
H2: New Features and Enhancements in 2.5
|
||||
|
||||
H3: Better {{B:cn=config}} functionality
|
||||
|
||||
There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The
|
||||
original design called for auto-renaming of config entries when you insert or
|
||||
delete entries with ordered names, but that was not implemented in 2.3. It is
|
||||
now in 2.4. This means, e.g., if you have
|
||||
|
||||
> olcDatabase={1}mdb,cn=config
|
||||
> olcSuffix: dc=example,dc=com
|
||||
|
||||
and you want to add a new subordinate, now you can ldapadd:
|
||||
|
||||
> olcDatabase={1}mdb,cn=config
|
||||
> olcSuffix: dc=foo,dc=example,dc=com
|
||||
|
||||
This will insert a new back-mdb database in slot 1 and bump all following databases
|
||||
down one, so the original back-mdb database will now be named:
|
||||
|
||||
> olcDatabase={2}mdb,cn=config
|
||||
> olcSuffix: dc=example,dc=com
|
||||
|
||||
H3: Better {{B:cn=schema}} functionality
|
||||
|
||||
In 2.3 you were only able to add new schema elements, not delete or modify
|
||||
existing elements. In 2.4 you can modify schema at will. (Except for the
|
||||
hardcoded system schema, of course.)
|
||||
|
||||
H3: More sophisticated Syncrepl configurations
|
||||
|
||||
The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support
|
||||
multiple consumers within the same database, but that feature never worked and
|
||||
was removed from OpenLDAP 2.3; you could only configure a single consumer in
|
||||
any database.
|
||||
|
||||
In 2.4 you can configure multiple consumers in a single database. The configuration
|
||||
possibilities here are quite complex and numerous. You can configure consumers
|
||||
over arbitrary subtrees of a database (disjoint or overlapping). Any portion
|
||||
of the database may in turn be provided to other consumers using the Syncprov
|
||||
overlay. The Syncprov overlay works with any number of consumers over a single
|
||||
database or over arbitrarily many glued databases.
|
||||
|
||||
H3: N-Way Multimaster Replication
|
||||
|
||||
As a consequence of the work to support multiple consumer contexts, the syncrepl
|
||||
system now supports full N-Way multimaster replication with entry-level conflict
|
||||
resolution. There are some important constraints, of course: In order to maintain
|
||||
consistent results across all servers, you must maintain tightly synchronized
|
||||
clocks across all participating servers (e.g., you must use NTP on all servers).
|
||||
|
||||
The entryCSNs used for replication now record timestamps with microsecond resolution,
|
||||
instead of just seconds. The delta-syncrepl code has not been updated to support
|
||||
multimaster usage yet, that will come later in the 2.4 cycle.
|
||||
|
||||
H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
|
||||
|
||||
Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported
|
||||
in 2.4; you can use syncrepl to replicate an entire server configuration from
|
||||
one server to arbitrarily many other servers. It's possible to clone an entire
|
||||
running slapd using just a small (less than 10 lines) seed configuration, or
|
||||
you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test
|
||||
suite provide working examples of these capabilities.
|
||||
|
||||
|
||||
H3: Push-Mode Replication
|
||||
|
||||
In 2.3 you could configure syncrepl as a full push-mode replicator by using it
|
||||
in conjunction with a back-ldap pointed at the target server. But because the
|
||||
back-ldap database needs to have a suffix corresponding to the target's suffix,
|
||||
you could only configure one instance per slapd.
|
||||
|
||||
In 2.4 you can define a database to be "hidden", which means that its suffix is
|
||||
ignored when checking for name collisions, and the database will never be used
|
||||
to answer requests received by the frontend. Using this "hidden" database feature
|
||||
allows you to configure multiple databases with the same suffix, allowing you to
|
||||
set up multiple back-ldap instances for pushing replication of a single database
|
||||
to multiple targets. There may be other uses for hidden databases as well (e.g.,
|
||||
using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem).
|
||||
|
||||
|
||||
H3: More extensive TLS configuration control
|
||||
|
||||
In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For
|
||||
outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came
|
||||
from the system's ldap.conf file.
|
||||
|
||||
In 2.4 all of these sessions inherit their settings from the main slapd configuration,
|
||||
but settings can be individually overridden on a per-config-item basis. This is
|
||||
particularly helpful if you use certificate-based authentication and need to use a
|
||||
different client certificate for different destinations.
|
||||
|
||||
|
||||
H3: Performance enhancements
|
||||
|
||||
Too many to list. Some notable changes - ldapadd used to be a couple of orders
|
||||
of magnitude slower than "slapadd -q". It's now at worst only about half the
|
||||
speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available
|
||||
at {{URL:http://www.openldap.org/pub/hyc/scale2007.pdf}}
|
||||
|
||||
That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and CVS HEAD). Toward the latter end
|
||||
of the "Cached Search Performance" chart it gets hard to see the difference
|
||||
because the run times are so small, but the new code is about 25% faster than 2.3,
|
||||
which was about 20% faster than 2.2, which was about 100% faster than 2.1, which
|
||||
was about 100% faster than 2.0, in that particular search scenario. That test
|
||||
basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache)
|
||||
in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can
|
||||
search over 500 thousand entries per second. The search was on an unindexed
|
||||
attribute using a filter that would not match any entry, forcing slapd to examine
|
||||
every entry in the DB, testing the filter for a match.
|
||||
|
||||
H3: New overlays
|
||||
|
||||
* slapo-constraint (Attribute value constraints)
|
||||
* slapo-dds (Dynamic Directory Services, RFC 2589)
|
||||
* slapo-memberof (reverse group membership maintenance)
|
||||
|
||||
H3: New features in existing Overlays
|
||||
|
||||
* slapo-pcache
|
||||
- Inspection/Maintenance
|
||||
-- the cache database can be directly accessed via
|
||||
LDAP by adding a specific control to each LDAP request; a specific
|
||||
extended operation allows to consistently remove cached entries and entire
|
||||
cached queries
|
||||
- Hot Restart
|
||||
-- cached queries are saved on disk at shutdown, and reloaded if
|
||||
not expired yet at subsequent restart
|
||||
|
||||
* slapo-rwm can safely interoperate with other overlays
|
||||
* Dyngroup/Dynlist merge, plus security enhancements
|
||||
- added dgIdentity support (draft-haripriya-dynamicgroup)
|
||||
|
||||
H3: New features in slapd
|
||||
|
||||
* monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
|
||||
* session tracking control (draft-wahl-ldap-session)
|
||||
* subtree delete in back-sql (draft-armijo-ldap-treedelete)
|
||||
* sorted values in multivalued attributes for faster matching
|
||||
* lightweight dispatcher for greater throughput under heavy load and on
|
||||
multiprocessor machines. (33% faster than 2.3 on AMD quad-socket dual-core server.)
|
||||
|
||||
|
||||
H3: New features in libldap
|
||||
|
||||
* ldap_sync client API (LDAP Content Sync Operation, RFC 4533)
|
||||
|
||||
H3: New clients, tools and tool enhancements
|
||||
|
||||
* ldapexop for arbitrary extended operations
|
||||
* Complete support of controls in request/response for all clients
|
||||
* LDAP Client tools now honor SRV records
|
||||
|
||||
H3: New build options
|
||||
|
||||
* Support for building against GnuTLS
|
||||
|
||||
|
||||
H2: Obsolete Features Removed From 2.5
|
||||
|
||||
These features were strongly deprecated in 2.4 and removed in 2.5.
|
||||
|
|
|
|||
|
|
@ -585,8 +585,8 @@ H3: `make test' fails
|
|||
Some times, `make test' fails at the very first test with an obscure message like
|
||||
|
||||
> make test
|
||||
> make[1]: Entering directory `/ldap_files/openldap-2.4.6/tests'
|
||||
> make[2]: Entering directory `/ldap_files/openldap-2.4.6/tests'
|
||||
> make[1]: Entering directory `/ldap_files/openldap-2.5.0/tests'
|
||||
> make[2]: Entering directory `/ldap_files/openldap-2.5.0/tests'
|
||||
> Initiating LDAP tests for MDB...
|
||||
> Cleaning up test run directory leftover from previous run.
|
||||
> Running ./scripts/all...
|
||||
|
|
@ -607,9 +607,9 @@ Some times, `make test' fails at the very first test with an obscure message lik
|
|||
> >>>>> Test failed
|
||||
> >>>>> ./scripts/test000-rootdse failed (exit 1)
|
||||
> make[2]: *** [mdb-yes] Error 1
|
||||
> make[2]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
|
||||
> make[2]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
|
||||
> make[1]: *** [test] Error 2
|
||||
> make[1]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
|
||||
> make[1]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
|
||||
> make: *** [test] Error 2
|
||||
|
||||
or so. Usually, the five lines
|
||||
|
|
|
|||
|
|
@ -2,39 +2,15 @@
|
|||
# Copyright 2007-2020 The OpenLDAP Foundation, All Rights Reserved.
|
||||
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
||||
|
||||
H1: Upgrading from 2.3.x
|
||||
H1: Upgrading from 2.4.x
|
||||
|
||||
The following sections attempt to document the steps you will need to take in order
|
||||
to upgrade from the latest 2.3.x OpenLDAP version.
|
||||
to upgrade from the latest 2.4.x OpenLDAP version.
|
||||
|
||||
The normal upgrade procedure, as discussed in the {{SECT:Maintenance}} section, should
|
||||
of course still be followed prior to doing any of this.
|
||||
|
||||
H2: {{B:cn=config}} olc* attributes
|
||||
|
||||
Quite a few {{olc*}} attributes have now become obsolete, if you see in your logs
|
||||
entries like below, just remove them from the relevant ldif file.
|
||||
|
||||
> olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored)
|
||||
|
||||
H2: ACLs: searches require privileges on the search base
|
||||
|
||||
Search operations now require "search" privileges on the "entry" pseudo-attribute of the search
|
||||
base. While upgrading from 2.3.x, make sure your ACLs grant such privileges to all desired search
|
||||
bases.
|
||||
|
||||
For example, assuming you have the following ACL:
|
||||
|
||||
> access to dn.sub="ou=people,dc=example,dc=com" by * search
|
||||
|
||||
Searches using a base of "dc=example,dc=com" will only be allowed if you add the following ACL:
|
||||
|
||||
> access to dn.base="dc=example,dc=com" attrs=entry by * search
|
||||
|
||||
Note: The {{slapd.access}}(5) man page states that this requirement was introduced
|
||||
with OpenLDAP 2.3. However, it is the default behavior only since 2.4.
|
||||
|
||||
|
||||
|
||||
ADD MORE HERE
|
||||
|
||||
|
|
|
|||
|
|
@ -1017,7 +1017,6 @@ slapdconfigfile
|
|||
modv
|
||||
ObjectClassDescription
|
||||
truelies
|
||||
slurpd
|
||||
basename
|
||||
groupOfUniqueNames
|
||||
DHAVE
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ similar to:
|
|||
> description: This object contains information about this server.
|
||||
> description: Most of the information is held in operational attributes, which
|
||||
> must be explicitly requested.
|
||||
> monitoredInfo: OpenLDAP: slapd 2.4 (Dec 7 2006 17:30:29)
|
||||
> monitoredInfo: OpenLDAP: slapd 2.5 (Dec 7 2006 17:30:29)
|
||||
> entryDN: cn=Monitor
|
||||
> subschemaSubentry: cn=Subschema
|
||||
> hasSubordinates: TRUE
|
||||
|
|
|
|||
|
|
@ -623,7 +623,7 @@ specific database. For example, with the following minimal slapd.conf:
|
|||
> suffix "dc=example,dc=com"
|
||||
> rootdn "cn=Manager,dc=example,dc=com"
|
||||
> rootpw secret
|
||||
> directory /var/lib/ldap2.4
|
||||
> directory /var/lib/ldap2.5
|
||||
> checkpoint 256 5
|
||||
> index objectClass eq
|
||||
> index uid eq,sub
|
||||
|
|
|
|||
|
|
@ -443,43 +443,6 @@ and the syncrepl engine runs on the proxy.
|
|||
|
||||
For configuration, please see the {{SECT:Syncrepl Proxy}} section.
|
||||
|
||||
H4: Replacing Slurpd
|
||||
|
||||
The old {{slurpd}} mechanism only operated in provider-initiated
|
||||
push mode. Slurpd replication was deprecated in favor of Syncrepl
|
||||
replication and has been completely removed from OpenLDAP 2.4.
|
||||
|
||||
The slurpd daemon was the original replication mechanism inherited from
|
||||
UMich's LDAP and operated in push mode: the master pushed changes to the
|
||||
slaves. It was replaced for many reasons, in brief:
|
||||
|
||||
* It was not reliable
|
||||
** It was extremely sensitive to the ordering of records in the replog
|
||||
** It could easily go out of sync, at which point manual intervention was
|
||||
required to resync the slave database with the master directory
|
||||
** It wasn't very tolerant of unavailable servers. If a slave went down
|
||||
for a long time, the replog could grow to a size that was too large for
|
||||
slurpd to process
|
||||
* It only worked in push mode
|
||||
* It required stopping and restarting the master to add new slaves
|
||||
* It only supported single master replication
|
||||
|
||||
Syncrepl has none of those weaknesses:
|
||||
|
||||
* Syncrepl is self-synchronizing; you can start with a consumer database
|
||||
in any state from totally empty to fully synced and it will automatically
|
||||
do the right thing to achieve and maintain synchronization
|
||||
** It is completely insensitive to the order in which changes occur
|
||||
** It guarantees convergence between the consumer and the provider
|
||||
content without manual intervention
|
||||
** It can resynchronize regardless of how long a consumer stays out
|
||||
of contact with the provider
|
||||
* Syncrepl can operate in either direction
|
||||
* Consumers can be added at any time without touching anything on the
|
||||
provider
|
||||
* Multi-master replication is supported
|
||||
|
||||
|
||||
H2: Configuring the different replication types
|
||||
|
||||
H3: Syncrepl
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@
|
|||
# Preamble for all OpenLDAP SDF documents
|
||||
#
|
||||
|
||||
!default VERSION 2.4
|
||||
!default VERSION 2.5
|
||||
|
||||
#
|
||||
# Paths are relative to the main subdirectories
|
||||
#
|
||||
|
||||
!define DOC_AUTHOR "The OpenLDAP Project <{{URL:http://www.openldap.org/}}>"
|
||||
!define DOC_NAME "OpenLDAP Software 2.4"
|
||||
!define DOC_NAME "OpenLDAP Software 2.5"
|
||||
!define DOC_TYPE "Guide"
|
||||
|
||||
!define DOC_LOGO "../images/LDAPlogo.gif"
|
||||
|
|
|
|||
Loading…
Reference in a new issue