1# $OpenLDAP$ 2# Copyright 2007-2021 The OpenLDAP Foundation, All Rights Reserved. 3# COPYING RESTRICTIONS APPLY, see COPYRIGHT. 4 5H1: Upgrading from 2.4.x 6 7The following sections attempt to document the steps you will need to take in order 8to upgrade from the latest 2.4.x OpenLDAP version. 9 10The normal upgrade procedure, as discussed in the {{SECT:Maintenance}} section, should 11of course still be followed prior to doing any of this. 12 13H2: {{B:cn=config}} olc* attributes 14 15H2: ppolicy overlay 16 17The overlay now implements version 10 of the ppolicy draft in full. This includes the notion of a password 18administrator where applicable (as determined by having a {{manage}} permission to the {{userPassword}} attribute) 19and skips certain processing when there is no valid policy in effect or where the operation is initiated by 20a password administrator. Many attributes are now tagged with {{NO-USER-MODIFICATION}} in the schema, requiring 21the use of {{relax}} control to modify them. 22 23In OpenLDAP 2.4 the {{slapo-ppolicy}}(5) overlay relied on a separate schema file to be included for it to function. 24This schema is now implemented internally in the slapo-ppolicy module. When upgrading {{slapd.conf}}(5) deployments 25the include statement for the schema must be removed. For {{slapd-config}}(5) deployments, the config database 26must be exported via slapcat and the old ppolicy schema removed from the export. The resulting config database 27can then be imported. 28 29H2: unique overlay 30 31In OpenLDAP 2.4 it was possible to bypass {{slapo-unique}}(5) checks by using the manageDSAIT control as a part of the 32request. This is no longer possible. To achieve the same functionality the relax control must be used instead, and the 33binding identity must have manage permissions on the entry being modified. 34 35With OpenLDAP 2.5 a new keyword "serialize" has been added as a part of the unique_uri configuration parameter. This 36will cause all write operations requiring uniqueness to be serialized so as to avoid the scenario where multiple 37concurrent updates can prevent uniqueness from being enforced. See the {{slapo-unique}}(5) man page for further details. 38 39H2: ldap and meta backends 40 41Several deprecated configuration directives for {{slapd-ldap}}(5) and {{slapd-meta}}(5) have been removed. Configurations 42using those directive must be updated to use supported directives prior to upgrade. See the {{slapd-ldap}}(5) and 43{{slapd-meta}}(5) man pages from OpenLDAP 2.4 for a list of deprecated directives. 44 45H2: shell backend 46 47This deprecated backend has been removed from OpenLDAP 2.5. Configurations making use of this backend must remove it 48prior to upgrade. The {{slapd-sock}}(5) backend is recommended as an alternative. 49 50H2: perl and sql backends 51 52The {{slapd-perl}}(5) and {{slapd-sql}}(5) backends are now deprecated and no longer automatically enabled with 53the --enable-backends configure flag. 54 55H2: hdb and bdb backends 56 57The Berkeley DB based slapd-bdb and slapd-hdb backends have been removed from OpenLDAP 2.5. Deployments making use 58of these backends must migrate their configurations to use {{slapd-mdb}}(5) prior to upgrade. 59 60H2: mdb backend 61 62Due to database format changes between OpenLDAP 2.4 and OpenLDAP 2.5 it is mandatory for existing {{slapd-mdb}}(5) databases 63to be exported via an OpenLDAP 2.4 slapcat prior to upgrade. They must then be reloaded via an OpenLDAP 2.5 slapadd after 64the binaries are updated. It is also advised to determine if the new {{slapd-mdb}}(5) idlexp backend directive and/or 65the multival database directive should be added to the OpenLDAP 2.5 configuration prior to import. 66