Dumping the entire thing, editing, and restoring worked fine. Thank you!
Graham
Rich Megginson wrote:
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
