LDAP support libraries
d8aedf8bed
- Modify the -config.patch, ldap.init, and this spec file to put the pid file and args file in an ldap-owned openldap subdirectory under /var/run. - Move back_sql* out of %{_sbindir}/openldap , which requires hand-moving slapd and slurpd to _sbindir, and recreating symlinks by hand. - Retire openldap-2.3.11-ads.patch, which went upstream. - Update the ldap.init script to run slaptest as the ldap user rather than as root. This solves bz#150172 Startup failure after database problem - Add to the servers post and preun scriptlets so that on preun, the database is slapcatted to /var/lib/ldap/upgrade.ldif and the database files are saved to /var/lib/ldap/rpmorig. On post, if /var/lib/ldap/upgrade.ldif exists, it is slapadded. This means that on upgrades from 2.3.16-2 to higher versions, the database files may be automatically upgraded. Unfortunatly, because of the changes to the preun scriptlet, users have to do the slapcat, etc by hand when upgrading to 2.3.16-2. Also note that the /var/lib/ldap/rpmorig files need to be removed by hand because automatically removing your emergency fallback files is a bad idea. - Upgrade internal bdb to db-4.4.20. For a clean upgrade, this will require that users slapcat their databases into a temp file, move /var/lib/ldap someplace safe, upgrade the openldap rpms, then slapadd the temp file. |
||
---|---|---|
.cvsignore | ||
autofs.schema | ||
guide.html | ||
ldap.init | ||
Makefile | ||
migration-tools.txt | ||
MigrationTools-26-suffix.patch | ||
MigrationTools-27-simple.patch | ||
MigrationTools-36-mktemp.patch | ||
MigrationTools-38-instdir.patch | ||
MigrationTools-45-noaliases.patch | ||
MigrationTools-46-schema.patch | ||
nptl-abi-note.S | ||
openldap-1.2.11-cldap.patch | ||
openldap-2.0.11-ldaprc.patch | ||
openldap-2.2.13-pie.patch | ||
openldap-2.2.13-setugid.patch | ||
openldap-2.2.13-tls-fix-connection-test.patch | ||
openldap-2.2.15-config.patch | ||
openldap-2.2.23-resolv.patch | ||
openldap-2.2.29-ads.patch | ||
openldap-2.3.11-ads.patch | ||
openldap-2.3.11-config.patch | ||
openldap-2.3.11-nosql.patch | ||
openldap-2.3.11-toollinks.patch | ||
openldap-ntlm.diff | ||
openldap.spec | ||
README.evolution | ||
README.nss_ldap | ||
README.upgrading | ||
sources |
Before upgrading from OpenLDAP 2.0 or 2.1 to OpenLDAP 2.2, the system administrator should dump out the contents of the the directory server's databases using the 'slapcat' utility included in the openldap-servers package and save the LDIF files which it produces. After the upgrade is complete, the data can be re-imported using the 'slapadd' utility. Some data which was exported from an OpenLDAP 2.0 server may not import directly into an OpenLDAP 2.2 server. If this happens, check for these common problems: * Missing parent entries. Entries in the directory are no longer allowed to be children of entries which are not present in the directory. For example, earlier releases would allow an entry with distinguished name (DN) "cn=foo,dc=devel,dc=example,dc=com" to be imported into a database for suffix "dc=example,dc=com" which contained neither an entry for "dc=devel,dc=example,dc=com" nor an entry for "dc=example,dc=com". * Deprecated objectclasses and attribute types. Entries of these classes should be replaced by entries of a different class. * the automountMap objectclass Use the nisMap objectclass instead, replacing these old attributes with new attributes: +====================================+ | old attribute new attribute | |------------------------------------| | ou nisMapName | +====================================+ * the automount objectclass Use the nisObject objectclass instead, replacing these old attributes with new attributes: +====================================+ | old attribute new attribute | |------------------------------------| | cn cn | | automountInformation nisMapEntry | | (no counterpart) nisMapName | +====================================+ * Missing objectclass definitions. Some objectclasses are no longer defined because they are no longer used. Remove the objectclass from the entry's list of objectclasses, and remove any values for attributes which are unique to that objectclass. These include: * the "kerberosSecurityObject" objectclass and the "krbName" attribute * the "dynamicObject" objectclass * the "LDAPsubEntry" objectclass * Missing attribute values. Some objectclass definitions mark a given attribute as both optional (MAY) and required (MUST). While such attributes may have been treated as optional before, they are now treated as required. Some examples: * the "ipProtocol" object class and its "description" attribute * the "rpcService" object class and its "description" attribute * the "oncRpc" object class and its "description" attribute * the "residentialPerson" object class and its "localityName" attribute * Structural vs. auxiliary objectclasses. The set of objectclasses which any entry lists should include exactly one STRUCTURAL class. This requirement may not have been enforced in previous releases. * The entry does not contain its own RDN as an attribute-value pair. The naming attribute and value used as the entry's relative distinguished name (RDN) must be explicitly defined for the entry. For example, an entry named "cn=contrived,dc=example,dc=com" must include "contrived" as a value for its "cn" attribute.