-The edb2ldif program is invoked like this:
-
-E: edb2ldif [-d] [-v] [-r] [-o] [-b <basedn>]
-E: [-a <addvalsfile>] [-f <fileattrdir>]
-E: [-i <ignoreattr...>] [<edbfile...>]
-
-The LDIF data is written to standard output. The arguments
-have the following meanings:
-
-E: -d
-
-This option enables some debugging output on standard
-error.
-
-E: -v
-
-Enable verbose mode that writes status information to
-standard error, such as which EDB file is being processed,
-how many entries have been converted so far, etc.
-
-E: -r
-
-Recurse through child directories, processing all EDB files
-found.
-
-E: -o
-
-Cause local .add file definitions to override the global addfile
-(see -a below)
-
-E: -b <basedn>
-
-Specify the Distinguished Name that all EDB file entries
-appear below.
-
-E: -a <addvalsfile>
-
-The LDIF information contained in this file will be appended
-to each entry.
-
-E: -f <fileattrdir>
-
-Specify a single directory where all file-based attributes
-(typically sounds and images) can be found. If this option is
-not given, file attributes are assumed to be located in the
-same directory as the EDB file that refers to them.
-
-E: -i <ignoreattr>
-
-Specify an attribute that should not be converted. You can
-include as many -i flags as necessary.
-
-E: <edbfile>
-
-Specify a particular EDB file (or files) to read data from. By
-default, the EDB.root (if it exists) and EDB files in the current
-directory are used.
-
-When {{EX: edb2ldif}} is invoked, it will also look for files named
-.add in the directories where EDB files are found and append
-the contents of the .add file to each entry. Typically, this
-feature is used to include inherited attribute values (e.g.,
-{{EX: objectClass}}) that do not appear in the EDB files.
-
-
-
-H3: Step-by-step EDB to LDIF conversion
-
-The basic steps to follow when converting your EDB format
-data to an LDIF file are:
-
-^ Locate the directory at the top of the EDB file hierarchy
-.that your QUIPU DSA masters. The EDB file located there
-.should contain the entries for the first level of your
-.organization or organizational unit. If you are using an
-.indexed database with QUIPU, you may need to create EDB
-.files from your index files (using the synctree or qb2edb
-.tools).
-.
-
-+If you do not have a file named EDB.root in the same
-.directory that contains your organizational or organizational
-.unit entry, create it now by hand. Its contents should look
-.something like this:
-.
-.{{EX: MASTER}}
-.{{EX: 000001}}
-.{{EX: }}
-.{{EX: o=OpenLDAP}}
-.{{EX: objectClass= top & organization & domainRelatedObject &\}}
-.{{EX: quipuObject & quipuNonLeafObject}}
-.{{EX: l= Redwood City, California}}
-.{{EX: st= California}}
-.{{EX: o=OpenLDAP Project & OpenLDAP Foundation & OpenLDAP}}
-.{{EX: description=The OpenLDAP Project}}
-.{{EX: associatedDomain= openldap.org}}
-.{{EX: masterDSA= c=US@cn=Woolly Monkey}}
-.{{EX: }}
-
-+ (Optional) Create a global add file and/or local .add files to
-.take care of adding any attribute values that do not appear in
-.the EDB files. For example, if all entries in a particular EDB
-.are person entries and you want to add the appropriate
-.objectClass attribute value for them, create a file called .add
-.in the same directory as the person EDB that contains the
-.single line:
-.
-.{{EX: objectClass: person }}
-.
-
-+ Run the edb2ldif program to do the actual conversion.
-.Make sure you are in the directory that contains the root of
-.the EDB hierarchy (the one where the EDB.root file resides).
-.Include a -b flag with a base DN one level above your
-.organizational entry, and include -i flags to ignore any
-.attributes that are not useful to slapd. E.g., the command:
-.
-.{{EX: edb2ldif -v -r -b "c=US" -i iattr -i acl -i xacl -i sacl}}
-.{{EX: -i lacl -i masterDSA -i slaveDSA > ldif}}
-.
-.will convert the entire EDB hierarchy to LDIF format and
-.write the result to a file named ldif. Some attributes that are
-.not useful when running slapd are ignored. The EDB
-.hierarchy is assumed to reside logically below the base DN
-."c=US".
-.
-
-+ Follow the steps outlined in section 8.2 above to produce
-.an LDBM database from your new LDIF file.
-
-
-
-H2: The ldbmtest program
-
-Occasionally you may find it useful to look at the LDBM
-database and index files directly (i.e., without going through
-slapd). The {{EX: ldbmtest}} program is provided for this purpose. It
-gives you raw access to the database itself. {{EX: ldbmtest}} should
-be run line this:
-
-E: ldbmtest [-d <debuglevel>] [-f <slapdconfigfile>]
-
-The default configuration file in the {{EX: ETCDIR}} is used if you
-don't supply one. By default, ldbmtest operates on the last
-database listed in the config file. You can specify an
-alternate database, or see the current database with the
-following commands.
-
-E: b specify an alternate backend database
-E: B print out the current backend database
-
-The {{EX: b}} command will prompt you for the suffix associated with
-the database you want. The database you select can be
-viewed and modified using a set of two-letter commands.
-The first letter selects the command function to perform.
-Possible commands and their meanings are as follows.
-
-E: l lookup (do not follow indirection)
-E: L lookup (follow indirection)
-E: t traverse and print keys and data
-E: T traverse and print keys only
-E: x delete an index item
-E: e edit an index item
-E: a add an index item
-E: c create an index file
-E: i insert an entry into an index item
-
-The second letter indicates which index the command
-applies to. The possible index selections are as follows.
-
-E: c id2children index
-E: d dn2id index
-E: e id2entry index
-E: f arbitrary file name
-E: i attribute index
-
-Each command may require additional arguments which
-ldbmtest will prompt you for.
-
-To exit {{EX: ldbmtest}}, type {{EX: control-D}} or {{EX: control-C}}.
-
-Note that this is a very raw interface originally developed
-when testing the database format. It is provided and
-minimally documented here for interested parties, but it is not
-meant to be used by the inexperienced. See the next section
-for a brief description of the LDBM database format.
-
-
-
-H2: The LDBM database format
-
-In normal operation, it is not necessary for you to know much
-about the LDBM database format. If you are going to use the
-ldbmtest program to look at or alter the database, or if you
-want a deeper understanding of how indexes are maintained,
-some knowledge of how it works could be useful. This
-section gives an overview of the database format and how
-slapd makes use of it.
-
-
-
-H3: Overview
-
-The LDBM database works by assigning a compact
-four-byte unique identifier to each entry in the database. It
-uses this identifier to refer to entries in indexes. The
-database consists of one main index file, called id2entry,
-which maps from an entry's unique identifier (EID) to a text
-representation of the entry itself. Other index files are
-maintained, for each indexed attribute for example, that map
-values people are likely to search on to lists of EIDs.
-
-Using this simple scheme, many LDAP queries can be
-answered efficiently. For example, to answer a search for
-entries with a surname of "Jensen", slapd would first consult
-the surname attribute index, look up the value "Jensen" and
-retrieve the corresponding list of EIDs. Next, slapd would
-look up each EID in the id2entry index, retrieve the
-corresponding entry, convert it from text to LDAP format, and
-return it to the client.
-
-The following sections give a very brief overview of each
-type of index and what it contains. For more detailed
-information see the paper "An X.500 and LDAP Database:
-Design and Implementation," available in postscript format
-from
-
-{{CMD[jump="ftp://terminator.rs.itd.umich.edu/ldap/papers/xldbm.ps"]ftp://terminator.rs.itd.umich.edu/ldap/papers/xldbm.ps}}
-
-
-
-H3: Attribute index format
-
-The LDBM backend will maintain one index file for each
-attribute it is asked to index. Several sets of keys must
-coexist in this file (e.g., keys for equality and approximate
-equality), so the keys are prefixed with a character to ensure
-uniqueness. The prefixes are given in the table below
-
-E: = equality keys
-E: ~ approximate equality keys
-E: * substring equality keys
-E: \ continuation keys
-
-Key values are also normalized (e.g., converted to upper
-case for case ignore attributes). So, for example, to look up
-the surname equality value in the example above using the
-ldbmtest program, you would look up the value "{{EX: =JENSEN}}".
-
-Substring indexes are maintained by generating all possible
-N-character substrings for a value (N is 3 by default). These
-substrings are then stored in the attribute index, prefixed by
-"*". Additional anchors of "^" and "$" are added at the
-beginning and end of words. So, for example the surname of
-Jensen would cause the following keys to be entered in the
-index: {{EX: ^JE, JEN, ENS, NSE, SEN, EN$}}.
-
-Approximate values are handled in a similar way, with
-phonetic codes being generated for each word in a value
-and then stored in the index, prefixed by "~".
-
-Large blocks in the index are split into smaller ones. The
-smaller blocks are accessed through a level of indirection
-provided by the original block. They are stored in the index
-using the continuation key prefix of "\".
-
-
-
-H3: Other indexes
-
-In addition to the {{EX: id2entry}} and attribute indexes, LDBM
-maintains a number of other indexes, including the {{EX: dn2id}}
-index and the {{EX: id2children}} index. These indexes provide the
-mapping between a DN and the corresponding EID, and the
-mapping between an EID and the EIDs of the corresponding
-entry's children, respectively.
-
-The {{EX: dn2id}} index stores normalized DNs as keys. The data
-stored is the corresponding EID.
-
-The {{EX: id2children}} index stores EIDs as keys. The data stored
-is a list of EIDs, just as for the attribute indexes.
-
-
-PB: