Back up all the Directory Server user and configuration data. For example:
cd /usr/lib/dirsrv/slapd-instance_name
db2bak /var/lib/dirsrv/slapd-instance_name/bak/instance_name-2010_04_30_16_27_56
Get the repo name by running yum check-update. For example:
yum check-update
Loaded plugins: rhnplugin, security
rhel-x86_64-server-5-rhdirserv-8
Install or upgrade the Directory Server 8.2 packages. For example:
yum update -y
This automatically updates the Red Hat Directory Server packages as well as any other required packages.
Red Hat Directory Server 8.2 requires that all of the packages in the Red Hat Directory Server channel be updated. Running simply yum update updates all Red Hat Directory Server and Red Hat Enterprise Linux packages. To exclude packages from updating on your system, you can use --exclude packages, restrict the update to only the Red Hat Directory Server channel, or explicitly list the packages to update. Run man yum for a list of options. For example:
yum update -y --disablerepo=* --enablerepo=rhel-x86_64-server-5-rhdirserv-8
Re-run the setup-ds-admin.pl script, using the -u to update the configuration. Make sure that the Directory Server and Admin Server are running when the script is run.
setup-ds-admin.pl -u
Go through the setup process again to re-register the updated Directory Server. The upgraded server has the same configuration as the 8.1 server. It is also possible to pass information with the
setup-ds-admin.pl script, as in
Section 4.5, “Silent Setup”
The setup-ds-admin.pl script updates the Directory Server core packages and configuration and the Directory Server and Admin Server consoles.
Verify that the packages have been properly updated by checking the version number on one of the Directory Server packages. For example:
rpm -qf /usr/sbin/setup-ds-admin.pl
redhat-ds-admin-8.2.0-0.el5dsrv
Verify that the directory databases have been successfully migrated. Directory Server 8.2 normalizes DN syntax during the upgrade process from 8.1. Make sure that the upgraded database is functional and contains all the data before deleting the backups.
Check the errors log to see if any databases had upgraded DNs. Any databases which required upgrades would have already been updated as the setup script ran; checking the error logs simply highlights what data to verify.
# grep "Upgrade Dn.*complete" /var/log/dirsrv/slapd-instance_name/errors
[...] - upgradedn abcRoot: Upgrade Dn Dryrun complete. abcRoot needs upgradednformat.
[...] - upgradedn abcRoot: Upgrade Dn complete. Processed 2 entries in 1 seconds. (2.00 entries/sec)
[...] - upgradedn userRoot: Upgrade Dn Dryrun complete. Processed 0 entries in 3 seconds. (0.00 entries/sec)
[...] - upgradedn userRoot: Upgrade Dn Dryrun complete. userRoot is up-to-date.
During upgrade, the original database is written to db.orig, and an updated database is written in its place. Check the upgraded database directories and DBVERSION files against the original files. For example:
ls -R /var/lib/dirsrv/slapd-instance_name/db
db:
abcRoot abcRoot.orig DBVERSION guardian log.0000000001 userRoot
db/abcRoot:
aci.db4 DBVERSION nsuniqueid.db4 parentid.db4
ancestorid.db4 entrydn.db4 numsubordinates.db4 seeAlso.db4
cn.db4 id2entry.db4 objectclass.db4 sn.db4
db/abcRoot.orig:
aci.db4 DBVERSION id2entry.db4 objectclass.db4 sn.db4
ancestorid.db4 dnupgrade nsuniqueid.db4 parentid.db4
cn.db4 entrydn.db4 numsubordinates.db4 seeAlso.db4
db/abcRoot.orig/dnupgrade:
DBVERSION guardian
db/userRoot:
aci.db4 entrydn.db4 nsuniqueid.db4 sn.db4
ancestorid.db4 givenName.db4 numsubordinates.db4 telephoneNumber.db4
cn.db4 id2entry.db4 objectclass.db4 uid.db4
DBVERSION mail.db4 parentid.db4
# find . -name DBVERSION | xargs head
==> ./db/abcRoot/DBVERSION <==
bdb/4.7/libback-ldbm/dn-4514
==> ./db/DBVERSION <==
bdb/4.7/libback-ldbm
==> ./db/abcRoot.orig/DBVERSION <==
bdb/4.7/libback-ldbm
==> ./db/abcRoot.orig/dnupgrade/DBVERSION <==
bdb/4.7/libback-ldbm
bdb/4.7/libback-ldbm
=> ./db/userRoot/DBVERSION <==
bdb/4.7/libback-ldbm/dn-4514
Search an entry which could contain escaped characters; the DNs should be updated. For example, for a DN which was previously cn="a=abc,x=xyz":
/usr/lib64/mozldap/ldapsearch -b "dc=example,dc=com" '(cn=\"*\")' entrydn
dn: cn=a\3Dabc\2Cx\3Dxyz,dc=example,dc=com
entrydn: cn=a\3dabc\2cx\3dxyz,dc=example,dc=com
If the search results are correctly escaped, the original database backend instance directory can be removed.
Restart the Directory Server.
service dirsrv restart
Manually restarting the server should only be required for Red Hat Enterprise Linux 4 systems. Other systems should restart automatically.
The setup-ds-admin.pl script updates both the Directory Server instances and the local Admin Server instance. However, the Admin Server console shows the old version number, like 8.1.4, even though it has been successfully upgraded. Restart the Admin Server to refresh the version number.
Restart the Directory Server Console to make sure that the version and build numbers are appropriately updated.
Check the error logs to see if there are any duplicate entries in the database.
Directory Server 8.1 allowed entries with identical DNs, but slightly different DN formats, to be added to the directory. For example:
dn: cn="uid=jsmith,ou=Dev0,o=Engineering0",ou=People,dc=example,dc=com
uid: jsmith
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: smith
cn: uid=jsmith,ou=Dev0,o=Engineering0
userPassword: secret
dn: cn=uid\=jsmith\,ou\=Dev0\,o\=Engineering0,ou=People,dc=example,dc=com
uid: jsmith
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: smith
cn: uid=jsmith,ou=Dev0,o=Engineering0
userPassword: secret
When these duplicate entries are migrated and their DNs are upgraded to the new, stricter DN format, the duplicate is given a slightly differnet DN that incorporates its unique ID. After the server upgrade, these duplicate entires can be preserved (which takes up additional space) or they can be purged.
Open the error log for the instance.
vim /var/log/dirsrv/slapd-instance_name/error
Look for error messages related to duplicate entries. These messages will have the term Duplicated entrydn or Duplicated entry in them. For example:
[..] - upgradedn userRoot: Duplicated entrydn detected: "cn=uid\3djsmith1\2cou\3ddev0\2co\3dengineering0,ou=people,dc=example,dc=com": Entry ID: (10, 11)
[..] - upgradedn userRoot: WARNING: Duplicated entry cn=uid\=jsmith1\,ou\=Dev0\,o\=Engineering0,ou=People,dc=example,dc=com is renamed to cn=uid\3Djsmith1\2Cou\3DDev0\2Co\3DEngineering0+nsuniqueid=ae8c95af-8fac11df-80000000-00000000,ou=People,dc=example,dc=com; Entry ID: 11
Decide which duplicated entry to keep. One entry will have the standard DN. The other has an RDN in the format cn=cn+nsuniqueid.
Delete the duplicate entries. Each specific duplicate entry must be deleted manually. For example:
/usr/lib64/mozldap/ldapdelete -D 'cn=directory manager' -w secret
dn: cn=uid\3djsmith1\2cou\3ddev0\2co\3dengineering0,ou=people,dc=example,dc=com
If the entry which was kept has the renamed RDN format (cn=cn+nsuniqueid), then rename the entry to the original DN. For example:
/usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389
dn: cn=uid\3Djsmith1\2Cou\3DDev0\2Co\3DEngineering0+nsuniqueid=ae8c95af-8fac11df-80000000-00000000,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=uid\3djsmith1\2cou\3ddev0\2co\3dengineering0
deleteoldrdn: 0
The deleteoldrdn value must be 0 since the nsuniqueid operational attribute cannot be deleted.