3.4. Renaming and Moving Entries
3.4.1. About Renaming Entries
Example 3.1. Building Entry DNs
dc=example,dc=com => root suffix ou=People,dc=example,dc=com => org unit st=California,ou=People,dc=example,dc=com => state/province l=Mountain View,st=California,ou=People,dc=example,dc=com => city ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => org unit uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => leaf entry
modrdn, operations result in changes to this tree.
220.127.116.11. Types of Rename Operations
modrdnoperations are lateral moves; the entry has the same parent, just a new name.
Figure 3.1. modrdn Operations for a Leaf Entry
modrdnoperation not only renames the subtree entry itself, but also changes the DN components of all of the children entries beneath the subtree.
Figure 3.2. modrdn Operations for a Subtree Entry
modrdnoperations also move and rename all of the child entries beneath the subtree entry. For large subtrees, this can be a time- and resource-intensive process. Plan the naming structure of your directory tree hierarchy so that it will not require frequent subtree rename operations.
modrdnoperation, which simultaneously renames the entry (even if it is the same name) and sets a
newSuperiorattribute which moves the entry from one parent to another.
Figure 3.3. modrdn Operations to a New Parent Entry
18.104.22.168. The Relationships Between Entry Keys in entryrdn.db4
entryrdn.db4index. Each entry is identified by its own key (a self-link) and then a subkey which identifies its parent (the parent link) and any children. This has a format that lays out the directory tree hierarchy by treating parents and children as attribute to an entry, and every entry is describes by a unique ID and its RDN, rather than the full DN.
dbscanoutput for the
numeric_id:RDN => self link ID: #; RDN: "rdn"; NRDN: normalized_rdn P#:RDN => parent link ID: #; RDN: "rdn"; NRDN: normalized_rdn C#:RDN => child link ID: #; RDN: "rdn"; NRDN: normalized_rdn
ou=peoplesubtree has a parent of
dc=example,dc=comand a child of
4:ou=people ID: 4; RDN: "ou=People"; NRDN: "ou=people" P4:ou=people ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com" C4:ou=people ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
entrydn.db4index, which stored entry keys according to their full DN. To upgrade to
entryrdn.db4, run the
- Add operations look at the parent given in the modify statement and check for any existing leaf entries; if none exist, the new entry is added.
- For delete operations, the server first checks the self link (the full entry key), and then deletes both the self link and then the child link in the parent entry. For example, if you deleted
ou=people,dc=example,dc=com, the server deletes the
ou=peoplekey (the self-link) and then deletes the child subkey from the
- For new superior operations, the server changes the parent link in the entry key, removes the child link from the old parent, and adds a new child link to the new superior key.
- For subtree rename operations, the server changes the self link in the subtree entry key to update its RDN, then tracks any child entry keys (based on the child links) and updates the parent link RDN.
22.214.171.124. Considerations for Renaming Entries
- You cannot rename the root suffix.
- Subtree rename operations have minimal effect on replication. Replication agreements are applied to an entire database, not a subtree within the database, so a subtree rename operation does not require re-configuring a replication agreement. All of the name changes after a subtree rename operation are replicated as normal.
- Renaming a subtree may require any synchronization agreements to be re-configured. Sync agreements are set at the suffix or subtree level, so renaming a subtree may break synchronization.
- Renaming a subtree requires that any subtree-level ACIs set for the subtree be re-configured manually, as well as any entry-level ACIs set for child entries of the subtree.
- You can rename a subtree with children, but you cannot delete a subtree with children.
- Trying to change the component of a subtree, like moving from
dc, may fail with a schema violation. For example, the
organizationalUnitobject class requires the
ouattribute. If that attribute is removed as part of renaming the subtree, then the operation will fail.
memberOfattributes managed by the MemberOf Plug-in will not be updated after a subtree-level rename operation. The MemberOf Plug-in does not check to see if parent entries change in order to initiate updates. If a subtree is renamed which contains either groups or group members, then launch a
cn=memberof tasktask or use the
fixup-memberof.plcommand to force the MemberOf Plug-in to make the changes.See Section 126.96.36.199, “Synchronizing memberOf Values” to see how to clean up
3.4.2. Renaming an Entry or Subtree
modrdnchangetype LDIF statement and use the
newrdnattribute to indicate that the naming attribute is being changed and
deleteoldrdnto set whether to retain the old RDN (0) or delete it (any non-zero integer). For example:
ldapmodify -D "cn=directory manager" -W -p 389 -h server.example.com -x dn: ou=Engineering,ou=People,dc=example,dc=com changetype: modrdn newrdn: ou=Development deleteoldrdn: 1
deleteoldrdnis set to any non-zero integer, positive or negative, then the old RDN is removed.
modrdnoperations are described in Section 3.3.2, “Renaming an Entry Using LDIF”.
3.4.3. Moving an Entry to a New Parent
newrdnto set the RDN of the moved entry. This is required even if the RDN remains the same.
newSuperiorto give the DN of the new parent entry.
ldapmodify -D "cn=directory manager" -W -p 389 -h server.example.com -x dn: uid=jsmith,l=Boston,ou=Engineering,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=jsmith deleteoldrdn: 1 newSuperior: l=Mountain View,ou=Engineering,ou=People,dc=example,dc=com
3.4.4. Disabling Subtree Rename Operations
entryrdn.db4database. Instances with subtree rename disabled store their entry information in
entrydn.db4. When disabling subtree renames, then the server needs to switch from using one database to the other, which is done by exporting and re-importing the directory entries. This is described in Section 188.8.131.52, “The Relationships Between Entry Keys in entryrdn.db4”.
- Export the directory to LDIF.
/etc/dirsrv/slapd-instance_name/db2ldif -n database1 -a /var/lib/dirsrv/slapd-instance_name/ldif/tree.ldifMore export options are covered in Section 4.2, “Exporting Data”.
- Turn off the
[root@server ~]# ldapmodify -D "cn=directory manager" -W -x dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-subtree-rename-switch nsslapd-subtree-rename-switch: off
- Import the LDIF file. This will populate the new
/etc/dirsrv/slapd-instance_name/ldif2db -D "cn=Directory Manager" -w secret -i /var/lib/dirsrv/slapd-instance_name/ldif/tree.ldif -n database1More import options are covered in Section 4.1, “Importing Data”.
3.4.5. Setting the DN Cache Size
nsslapd-dncachememsize, and setting a large cache memory size improves the performance of rename operations.
nsslapd-dncachememsizeattribute value for the LDBM plug-in instance for the database. For example:
[root@server ~]# ldapmodify -D "cn=directory manager" -W -x dn: cn=database_name,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dncachememsize nsslapd-dncachememsize: 20971520