Another question about directory re-population. If I want to create a generic LDIF backup for a bunch of test directory servers, in the exported LDIF file, should I remove the following attributes? or it doesn't really matter? nsUniqueId: 795dca00-5fa011df-8de2866b-a65dc74a creatorsName: modifiersName: cn=directory manager createTimestamp: 20100514213428Z modifyTimestamp: 20100514213430Z My LDIF backup will be imported back to the LDAP using ldif2db.pl. - David On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu < beyonddc.storage at gmail.com> wrote: > Thanks Rich, I'll give that a try. > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson <rmeggins at redhat.com>wrote: > >> Chun Tat David Chu wrote: >> > Hi Rich, >> > >> > Thanks for replying. >> > >> > Just making sure I'm using the right utility. To reinitialize the >> > directory, I use the ldif2db.pl <http://ldif2db.pl> Perl script right? >> Yes, if you need to restore _all_ servers from an LDIF backup. The >> reason I say _all_ is that when you do a restore from a "raw" LDIF file, >> this wipes out all of the replication state information and changelog >> information. This means you will have to use this server to re-init >> other masters and consumers - (I mean re-init in the sense of >> Initializing Consumers - >> >> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Initializing_Consumers.html >> ) >> >> You can use db2ldif.pl -r to create an LDIF file suitable for offline >> replica init >> > >> > - David >> > >> > On Fri, Jun 18, 2010 at 3:58 PM, Rich Megginson <rmeggins at redhat.com >> > <mailto:rmeggins at redhat.com>> wrote: >> > >> > Chun Tat David Chu wrote: >> > > Hi all, >> > > >> > > I am hitting an issue with reinitializing the directory database. >> > > >> > > Basically I have two directory servers and they're configured >> using >> > > multi-master replication scheme. >> > > >> > > When I reinitialize the directory database, the directory became >> > > inaccessible. I think it is related with my multi-master >> > replication >> > > setup because when I use only reinitialize one LDAP, it would work >> > > just fine >> > > >> > > My question is if multi-master replication is enabled on two LDAPs >> > > then do I need to reinitialize both LDAPs at the same time or >> > just one >> > > LDAP? >> > If you use one master (m1) to re-init the other master (m2), you >> > do not >> > need to then use m2 to re-init m2. >> > > >> > > Thanks! >> > > >> > > - David >> > > >> > > On Fri, May 14, 2010 at 4:42 PM, Chun Tat David Chu >> > > <beyonddc.storage at gmail.com <mailto:beyonddc.storage at gmail.com> >> > <mailto:beyonddc.storage at gmail.com >> > <mailto:beyonddc.storage at gmail.com>>> wrote: >> > > >> > > Reinitializing the directory database does the trick! I'm >> going >> > > to do more testing on it. >> > > >> > > Thanks a lot! >> > > >> > > - David >> > > >> > > >> > > On Fri, May 14, 2010 at 1:43 PM, David Boreham >> > > <david_list at boreham.org <mailto:david_list at boreham.org> >> > <mailto:david_list at boreham.org <mailto:david_list at boreham.org>>> >> > wrote: >> > > >> > > On 5/14/2010 11:40 AM, Chun Tat David Chu wrote: >> > > > >> > > > We use 389 Directory as part of our development lab. >> > Every >> > > time when >> > > > we do a new test, we need to repopulate our 389 >> > directory to >> > > a clean >> > > > slate (i.e. delete all existing data and re-create a >> base >> > > hierarchy >> > > > tree). >> > > > >> > > > Our current way of doing so is simply using the >> ldapdelete >> > > command to >> > > > remove all existing data and use ldapadd to re-create >> > the base >> > > > hierarchy tree. This approach is okay but sometime it >> > could >> > > take up >> > > > to 20 to 30 minutes to delete all existing data >> > depending on the >> > > > amount of data saved in the directory. >> > > > >> > > > Is there a more efficient way to repopulate the 389 >> > Directory? >> > > >> > > Yes. Import an almost empty LDIF file. You can also copy >> the >> > > on-disk >> > > database underneath a server (when it is shut down), if >> you >> > > know what >> > > you're doing. >> > > >> > > -- >> > > 389 users mailing list >> > > 389-users at lists.fedoraproject.org >> > <mailto:389-users at lists.fedoraproject.org> >> > > <mailto:389-users at lists.fedoraproject.org >> > <mailto:389-users at lists.fedoraproject.org>> >> > > >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > >> > > >> > > >> > > >> > >> ------------------------------------------------------------------------ >> > > >> > > -- >> > > 389 users mailing list >> > > 389-users at lists.fedoraproject.org >> > <mailto:389-users at lists.fedoraproject.org> >> > > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > >> > -- >> > 389 users mailing list >> > 389-users at lists.fedoraproject.org >> > <mailto:389-users at lists.fedoraproject.org> >> > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > >> > >> > ------------------------------------------------------------------------ >> > >> > -- >> > 389 users mailing list >> > 389-users at lists.fedoraproject.org >> > https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> -- >> 389 users mailing list >> 389-users at lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100622/93ac2f16/attachment-0001.html
