From: Quanah Gibson-Mount Date: Mon, 27 Apr 2020 23:25:08 +0000 (+0000) Subject: 2.5 version updates X-Git-Tag: OPENLDAP_REL_ENG_2_5_0ALPHA~41^2~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=af5b31b2a77cbebf0a94c87967e583244a4244e5;p=thirdparty%2Fopenldap.git 2.5 version updates --- diff --git a/doc/guide/admin/appendix-changes.sdf b/doc/guide/admin/appendix-changes.sdf index 7fe91d13ab..3f588e8d1b 100644 --- a/doc/guide/admin/appendix-changes.sdf +++ b/doc/guide/admin/appendix-changes.sdf @@ -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. diff --git a/doc/guide/admin/appendix-common-errors.sdf b/doc/guide/admin/appendix-common-errors.sdf index d3ab3c402f..c85ec5f73d 100644 --- a/doc/guide/admin/appendix-common-errors.sdf +++ b/doc/guide/admin/appendix-common-errors.sdf @@ -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 diff --git a/doc/guide/admin/appendix-upgrading.sdf b/doc/guide/admin/appendix-upgrading.sdf index bb53f65a82..74a3f047c5 100644 --- a/doc/guide/admin/appendix-upgrading.sdf +++ b/doc/guide/admin/appendix-upgrading.sdf @@ -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: 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 diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws index 0784ab74db..43ba9c2724 100644 --- a/doc/guide/admin/aspell.en.pws +++ b/doc/guide/admin/aspell.en.pws @@ -1017,7 +1017,6 @@ slapdconfigfile modv ObjectClassDescription truelies -slurpd basename groupOfUniqueNames DHAVE diff --git a/doc/guide/admin/monitoringslapd.sdf b/doc/guide/admin/monitoringslapd.sdf index d24ab27b12..82f61ca704 100644 --- a/doc/guide/admin/monitoringslapd.sdf +++ b/doc/guide/admin/monitoringslapd.sdf @@ -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 diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf index 941906c90d..38382b5081 100644 --- a/doc/guide/admin/overlays.sdf +++ b/doc/guide/admin/overlays.sdf @@ -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 diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index b22cdb33fa..6859b563a1 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -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 diff --git a/doc/guide/preamble.sdf b/doc/guide/preamble.sdf index e93375fe53..393bac2510 100644 --- a/doc/guide/preamble.sdf +++ b/doc/guide/preamble.sdf @@ -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"