ldif2ldbm(1M) is a way of writing LDIF data directly to the ldbm database format used by the directory provided with SIMS. ldif2ldbm(1M) must be done locally. It also bypasses certain checks (schema checking of attributes that are mandatory, for example), and therefore may be faster in certain circumstances for bulk-loading large amounts of data into the directory. For example, restoring up a damaged directory from stored LDIF data, or for initially populating a directory from a new batch of LDIF data. Users of ldif2ldbm are advised to carefully read the man pages and to practice their proposed use of this tool in an environment where any mistakes will not affect the operation of shared resources. Some important reminders about ldif2ldbm are:
|
|
ldif2ldbm truncates the existing ldbm databases when it is invoked, to ensure that no existing data can corrupt the bulk-load it is about to carry out. If you wish to use ldif2ldbm on an existing, intact, database, you should use ldbmcat(1M), with `-n' flag to first dump the existing ldbm database to LDIF, to which the new LDIF is then concatenated, before loading the entire new batch of LDIF data. |
|
|
ldif2ldbm completely bypasses the directory schema enforced by the slapd directory server. Administrators must be certain that data they are entering meets the schema which slapd enforces via it's slapd.conf, slapd.oc.conf and slapd.at.conf files.There are two ways LDIF data may be added to the directory; by using the LDAP protocol (via ldapmodify(1), or by direct modification to the ldbm database used by the directory (via ldif2ldbm(1M)). Use of the former method is recommended as it does not require you to be on the same system as the database, and automatic merging of existing entries with new values is done. However the latter method may be used by skilled system administrators who are familiar with the procedure, as it requires saving data already in the directory service to prevent data loss. |