views:

1334

answers:

4

I know this is more like a serverfault question than a stackoverflow question, but since serverfault isn't up yet, here I go:

I'm supposed to move an application from one redhat server to another, and without very good knowledge of the internal workings of the application, how would I move the OpenLDAP database from the one machine to the other, with schemas and all.

What files would I need to copy over? I believe the setup is pretty standard.

+2  A: 

Some appointments:

  • Save your personalized schemas and objectclasses definitions on your new server. You can look for your included files at slapd.conf to obtain it, for example (this is a part of my slapd.conf):

    include /etc/ldap/schema/core.schema

  • Include your personalized schemas and objectclasses in your new openLDAP installation.

  • Use slapcat command to export your full LDAP tree to a single/various ldif files.

  • Use ldapadd to import the ldif files on to your new LDAP installation.

  • Get luck :-)

SourceRebels
Thanks... the problem was that I didn't remember the name of the tool (slapcat)
elzapp
+1  A: 

I prefer copy the database through the protocol:

first of all be sure you have the same schemas on both servers.

-dump the database with ldapsearch:
ldapsearch -LLL -Wx -D "cn=admin,dc=domain" -b "dc=domain" > domain.ldif

-and import it in the new server:
ldapmodify -Wx -D "cn=admin,dc=domain" -a -f domain.ldif

in oneline:
ldapsearch -LLL -Wx -D "cn=admin,dc=domain" -b "dc=domain" | ldapmodify -w pass -x -D "cn=admin,dc=domain" -a

By using the bin/ldap* commands you are talking directly with the server while using bin/slap* commands you are dealing with the backend files

Vish
+2  A: 

The problem with SourceRebels answer is that slapcat(8) does not guarantee that the data is ordered for ldapadd(1)/ldapmodify(1). From the man page :

The  LDIF  generated  by this tool is suitable for use with slapadd(8).
As the entries are in database order, not superior  first  order,  they
cannot be loaded with ldapadd(1) without first being reordered.

Plus using a tool that use the backend files to dump the database and then using a tool that loads the ldif through the ldap protocol is not very consistent.

I'd suggest to use a combination of slapcat(8)/slapadd(8) OR ldapsearch(1)/ldapmodify(1). My preference would go to the latter as it does not need shell access to the ldap server or moving files around.

For example, dump database from a master server under dc=master,dc=com and load it in a backup server

$ ldapsearch -Wx -D "cn=admin_master,dc=master,dc=com" -b "dc=master,dc=com" -H ldap://my.master.host -LLL > ldap_dump-20100525-1.ldif
$ ldapadd -Wx -D "cn=admin_backup,dc=backup,dc=com" -H ldap://my.backup.host -f ldap_dump-20100525-1.ldif

Last hint, ldapadd(1) is a hard link to ldapmodify(1) with the -a (add) flag turned on.

sberder
A: 

ldapsearch and ldapadd are not necessarily the best tools to clone your LDAP DB. slapcat and slapadd are much better options.

Export your DB with slapcat:

slapcat > ldif

Import the DB with slapadd (make sure the LDAP server is stopped):

slapadd -l ldif
Joel