--- Begin Message ---
Adam Williams wrote:
>
> >SIZELIMIT in ldap.conf is commented out, so that's not the issue. Now the
> >problem is that when I do the directory dump, it's not hierarchal, therefore
> >I can't use it to rebuild the directory if it's required without
> >manipulating the file. Is there a way to sort the output so that I could
> >use ldapadd -f dump.ldif to rebuild a directory?
>
> One uses slapadd to rebuild a directory from an LDIF file.
>
> ldapadd/modify/delete are for working on an exiosting directory.
>
> slapcat/slapadd are the backup and restore facilities.
I too have stumbled over the same issue, needing to set a larger SIZELIMIT in slapd.conf in order to
get ldapsearch to return the full contents of the directory, and I'm grateful for the help I
received on this list in solving that problem. I do still have a question about backing up though.
When I use slapcat (I've been using "slapcat -l backup.ldif", and haven't tried "slapcat -v >
backup.ldif" yet, though i'm looking at the "slapcat -v" output right now, and it looks like the
same issue would occur), it does indeed dump the directory, but i can't use slapadd directly on that
file because it contains 4 "machine-generated" (for lack of a better term) attributes: creatorsName,
creatorTimestamp, modifiersName, and modifyTimestamp. I can (and have) used sed to remove those 4
attributes from every entry, which does allow me to reload the data with slapadd.
It seems though that the output of:
ldapsearch -D "cn=admin,dc=mydomain,dc=com" -W -b "dc=mydomain,dc=com" > backup.ldif
should be suitable for reloading with slapadd. If i trim from that file the initial 8 lines, the
trailing 7 lines, and the entries for the base and the cn=admin, is there any reason i shouldn't be
able to use slapadd to reload it into a freshly installed directory?
Actually the most simple/reliable way I've found to restore a backup is to just tar the
/var/lib/ldap directory and then (after building and configuring a "fresh" install on a different
machine) to just "mv /var/lib/ldap /var/lib/ldapfresh" and then untar the archive into /var/lib/ldap
and voila, after starting my new slapd, i have a perfectly running clone of the original directory.
Obviously I've used the exact same version (and configuration details) for openldap when I've done
this. I'd certainly not believe that this would be a reliable way to proceed if an upgrade in
version number was involved (though i suppose it's possible that it might work).
In the slapcat/slapadd method, is the removal of the four "machine-generated" attributes i mentioned
above such an obvious step that it is never really mentioned, or is there a better way to go about
the backup/restore procedure that I'm not seeing?
thank you very much for your time,
~c
--- End Message ---