Graham Seaman wrote: > Hi, > > I have an existing populated directory supporting a live application. > The next development version will have some fairly large scale changes > - changes to schema, objectClasses, attribute names and attribute > values - but I can't lose the actual data we already have. > > The approach I've been trying is: > > 1. Use db2ldif to dump the groups and users (the only bit of the data > which is 'mine') from the live directory on the live system: > > /usr/lib/dirsrv/slapd-flame/db2ldif -U -n userRoot -a > /opt/backups/original.ldif -s "dc=lse,dc=ac,dc=uk" -s "ou=My Groups" > -s "ou=My Users" That's not really the purpose of db2ldif - it really wants to operate on the entire contents of the database. If you need to edit selective parts of the tree, you'll have to use one of the following approaches: Use db2ldif to get everything, but only modify the parts you want Use ldapsearch to selectively get what you want - then, either use ldapdelete to remove entire entries and ldapmodify -a to add them back, or if you can just modify the entries in place, use ldif change statements (changetype: modify) and use ldapmodify (no -a) > > 2. Edit the ldif file with the changes I need > > 3. Load the ldif file into a new fedora directory on my development > system with ldif2db.pl: > > /usr/lib/dirsrv/slapd-dam/ldif2db.pl -D "cn=directory manager" -w > MYPASS -n userRoot -s "dc=lse,dc=ac,dc=uk" -s "ou=New Groups" -s > "ou=New Users" -i /opt/backups/new.ldif > > ldif2db.pl terminates almost immediately, clearly without having read > most of the file. The fedora log shows: > > [14/Nov/2008:11:35:54 +0000] conn=2 op=1 ADD > dn="cn=import_2008_11_14_11_35_55, cn=import, cn=tasks, cn=config" > [14/Nov/2008:11:35:54 +0000] conn=2 op=1 RESULT err=0 tag=105 > nentries=0 etime=0 This is because ldif2db.pl just invokes an internal task using a task entry. If you want to monitor the progress of the import, you'll have to look at the errors log, or use ldapsearch to query the entry that ldif2db.pl spits out (cn=import_2008_11_14_11_35_55, cn=import, cn=tasks, cn=config) > > If I repeat the operation I get 'operation error'; and if I try to > access the directory, it appears to be completely empty. Probably what happened is that you attempted to import from an LDIF file that did not contain the parent entries - the LDIF only contained your users and groups. Import (ldif2db) is a _destructive_ operation - it will completely wipe out the contents of your database before adding the new entries. In order to add an entry in LDAP, the parent entry must exist. This means that if you want to import an LDIF file, and dc=lse,dc=ac,dc=uk is your base suffix, the LDIF file must contain the entry dn: dc=lse,dc=ac,dc=uk ... and any other parent entries of the entries you want to import. > > So, two questions: > > - is this a reasonable way to go about this task, or are there other > tools I should use? > - any suggestions for debugging? > > Thanks > Graham > > > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20081114/743fafd6/attachment.bin
