[389-users] Directory Re-population
Chun Tat David Chu
beyonddc.storage at gmail.com
Tue Jun 22 18:20:23 UTC 2010
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.html>
More information about the 389-users
mailing list