Hi All,
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?
Thanks!
David
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.
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@boreham.orgwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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?
Thanks!
- David
On Fri, May 14, 2010 at 4:42 PM, Chun Tat David Chu < beyonddc.storage@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@boreham.orgwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@gmail.com mailto:beyonddc.storage@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@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
Thanks for replying.
Just making sure I'm using the right utility. To reinitialize the directory, I use the ldif2db.pl Perl script right?
- David
On Fri, Jun 18, 2010 at 3:58 PM, Rich Megginson rmeggins@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@gmail.com mailto:beyonddc.storage@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@boreham.org <mailto:david_list@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 onthe
> 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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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...)
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@redhat.com mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Thanks Rich, I'll give that a try.
On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson rmeggins@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... )
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@redhat.com mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> wrote: > > Reinitializing the directory database does the trick! I'mgoing
> to do more testing on it. > > Thanks a lot! > > - David > > > On Fri, May 14, 2010 at 1:43 PM, David Boreham > <david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@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 theldapdelete
> 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 copythe
> on-disk > database underneath a server (when it is shut down), if you > know what > you're doing. > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@gmail.com> wrote:
Thanks Rich, I'll give that a try.
On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson rmeggins@redhat.comwrote:
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... )
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@redhat.com mailto:rmeggins@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 configuredusing
> 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@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> wrote: > > Reinitializing the directory database does the trick! I'mgoing
> to do more testing on it. > > Thanks a lot! > > - David > > > On Fri, May 14, 2010 at 1:43 PM, David Boreham > <david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@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 abase
> hierarchy > > tree). > > > > Our current way of doing so is simply using theldapdelete
> 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 copythe
> on-disk > database underneath a server (when it is shut down), ifyou
> know what > you're doing. > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Chun Tat David Chu wrote:
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
I don't think it matters. I suppose you might want to keep createTimestamp and modifyTimestamp just for your own information.
My LDIF backup will be imported back to the LDAP using ldif2db.pl http://ldif2db.pl.
- David
On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu <beyonddc.storage@gmail.com mailto:beyonddc.storage@gmail.com> wrote:
Thanks Rich, I'll give that a try. On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@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> <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 <http://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@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
I did some testing and it appears to be working as you expected. The steps involve 1) Export the directory database to a LDIF 2) Reload the directory database 3) Reinitialize the consumer
I have another question. I noticed there's an ACI on the directory database LDIF. aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server Group, cn= foo.com, ou=tscei.dd-x.com, o=NetscapeRoot";)
Do I need to modify the hostname in that ACI if I want to load the same directory database into another LDAP? Essentially I want to use a basic directory database LDIF and load it to a bunch of different development LDAP we have. Some LDAPs are multi-mastered configured and most are not.
Thanks in advance
- David
On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
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
I don't think it matters. I suppose you might want to keep createTimestamp and modifyTimestamp just for your own information.
My LDIF backup will be imported back to the LDAP using ldif2db.pl http://ldif2db.pl.
- David
On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu <beyonddc.storage@gmail.com mailto:beyonddc.storage@gmail.com> wrote:
Thanks Rich, I'll give that a try. On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@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> <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... )
You can use db2ldif.pl <http://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@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > >
> > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Chun Tat David Chu wrote:
Hi Rich,
I did some testing and it appears to be working as you expected. The steps involve
- Export the directory database to a LDIF
- Reload the directory database
- Reinitialize the consumer
I have another question. I noticed there's an ACI on the directory database LDIF. aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server Group, cn= foo.com http://foo.com, ou=tscei.dd-x.com http://tscei.dd-x.com, o=NetscapeRoot";)
Do I need to modify the hostname in that ACI if I want to load the same directory database into another LDAP? Essentially I want to use a basic directory database LDIF and load it to a bunch of different development LDAP we have. Some LDAPs are multi-mastered configured and most are not.
No, you do not need to change that hostname.
Thanks in advance
- David
On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > 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 I don't think it matters. I suppose you might want to keep createTimestamp and modifyTimestamp just for your own information. > > My LDIF backup will be imported back to the LDAP using ldif2db.pl <http://ldif2db.pl> > <http://ldif2db.pl>. > > - David > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> wrote: > > Thanks Rich, I'll give that a try. > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://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 <http://db2ldif.pl> <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi
I have a 389 server working, with non-secure LDAP (port 389) ubuntu and RH5ws clients work fine....I have made self certificates and these seem OK on the client(s), yet once I kickoff ssl (636) logins dont work....For the RH5ws I have used authconfig-tui which automates the setup, its seems correct. Ubuntu it looks like I have to set it up manually...? cant find anything that that says otherwise.
So I appear to have a mis-config in the SSl or TLS part...
I have dug around and googled to no vail....so where do I start looking for issues? I cant see anything in the logs, (can they be set more verbose? would that help?)
regards
Steven
Hi,
From the logs,
The first 2 Ips are the secure ones from RH5ws's (245.105 and 81.236), the last (53.103) is ubuntu in plain txt (port 389) mode....
There is a query from ubuntu as you can see and login to the client is successful, but not from the RH boxes....so why?
regards
Steven
[root@vuwunicooimm001 slapd-vuwunicooimm001]# tail -f access [23/Jun/2010:10:43:27 +1200] conn=1490 fd=97 slot=97 SSL connection from 130.195.245.105 to 130.195.53.100 [23/Jun/2010:10:43:31 +1200] conn=1490 op=-1 fd=97 closed - B1 [23/Jun/2010:10:43:44 +1200] conn=1491 fd=97 slot=97 SSL connection from 130.195.81.236 to 130.195.53.100 [23/Jun/2010:10:43:47 +1200] conn=1491 op=-1 fd=97 closed - B1 [23/Jun/2010:10:44:16 +1200] conn=1492 fd=97 slot=97 connection from 130.195.245.103 to 130.195.53.100 [23/Jun/2010:10:44:16 +1200] conn=1492 op=0 BIND dn="" method=128 version=3 [23/Jun/2010:10:44:16 +1200] conn=1492 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [23/Jun/2010:10:44:16 +1200] conn=1492 op=1 SRCH base="dc=vuw,dc=ac,dc=nz" scope=2 filter="(uid=jonesst1)" attrs=ALL [23/Jun/2010:10:44:16 +1200] conn=1492 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [23/Jun/2010:10:44:16 +1200] conn=1492 op=2 BIND dn="uid=jonesst1,ou=People,dc=vuw,dc=ac,dc=nz" method=128 version=3 [23/Jun/2010:10:44:16 +1200] conn=1492 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=jonesst1,ou=people,dc=vuw,dc=ac,dc=nz" [23/Jun/2010:10:44:16 +1200] conn=1492 op=3 BIND dn="" method=128 version=3 [23/Jun/2010:10:44:16 +1200] conn=1492 op=3 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [23/Jun/2010:10:44:16 +1200] conn=1492 op=4 UNBIND [23/Jun/2010:10:44:16 +1200] conn=1492 op=4 fd=97 closed - U1
=================================
-----Original Message----- From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Steven Jones Sent: Wednesday, 23 June 2010 10:41 a.m. To: General discussion list for the 389 Directory server project. Subject: [389-users] Client failures
Hi
I have a 389 server working, with non-secure LDAP (port 389) ubuntu and RH5ws clients work fine....I have made self certificates and these seem OK on the client(s), yet once I kickoff ssl (636) logins dont work....For the RH5ws I have used authconfig-tui which automates the setup, its seems correct. Ubuntu it looks like I have to set it up manually...? cant find anything that that says otherwise.
So I appear to have a mis-config in the SSl or TLS part...
I have dug around and googled to no vail....so where do I start looking for issues? I cant see anything in the logs, (can they be set more verbose? would that help?)
regards
Steven
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi,
After a system reboot the Ldap admin service appears not to be running.
How do I restart it?
I tried "service dirsrv-admin start" but this just hangs / never returns to the console.
thanks
Steven
What does /var/log/dirsrv/admin-serv/error say? Should give you a good clue. Kind of sounds like an SSL instance trying to start without a pin file but just guessing there.
TC
On Tue, Jun 22, 2010 at 9:27 PM, Steven Jones Steven.Jones@vuw.ac.nz wrote:
Hi,
After a system reboot the Ldap admin service appears not to be running.
How do I restart it?
I tried "service dirsrv-admin start" but this just hangs / never returns to the console.
thanks
Steven
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi,
I eventually thought that....ie pin file.....however I am not aware Ive set the admin server for ssl.....the actual directory server is, and has a pin file and it starts....so I'll go back and make one.
However from the docs, starting it at the command line should then see it asking for the password....I dont see that.
There is nothing in the error log....
======== [root@vuwunicooimm001 admin-serv]# ls -l total 32 -rw-r--r-- 1 root root 28866 Jun 22 14:49 access -rw-r--r-- 1 root root 0 Jun 23 16:30 error [root@vuwunicooimm001 admin-serv]# tail access 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:03:44 +1200] "GET /slapd-vuwunicooimm001/Tasks/Operation/Restart HTTP/1.0" 200 2384 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:30 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 643 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:30 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1338 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:40 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1872 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:06 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 643 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:06 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1338 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:16 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1815 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:47:34 +1200] "POST /slapd-vuwunicooimm001/Tasks/Operation/ViewLog HTTP/1.0" 200 3883 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:47:58 +1200] "POST /slapd-vuwunicooimm001/Tasks/Operation/ViewLog HTTP/1.0" 200 2174 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:49:45 +1200] "GET /slapd-vuwunicooimm001/Tasks/Operation/Restart HTTP/1.0" 200 2270 [root@vuwunicooimm001 admin-serv]# ========
regards
Steve n
-----Original Message----- From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Techie Sent: Wednesday, 23 June 2010 5:30 p.m. To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] restarting the 389 after a reboot
What does /var/log/dirsrv/admin-serv/error say? Should give you a good clue. Kind of sounds like an SSL instance trying to start without a pin file but just guessing there.
TC
On Tue, Jun 22, 2010 at 9:27 PM, Steven Jones Steven.Jones@vuw.ac.nz wrote:
Hi,
After a system reboot the Ldap admin service appears not to be running.
How do I restart it?
I tried "service dirsrv-admin start" but this just hangs / never returns to the console.
thanks
Steven
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Steven Jones wrote:
Hi,
I eventually thought that....ie pin file.....however I am not aware Ive set the admin server for ssl.....the actual directory server is, and has a pin file and it starts....so I'll go back and make one.
However from the docs, starting it at the command line should then see it asking for the password....I dont see that.
There is nothing in the error log....
start the admin server like this: /usr/sbin/start-ds-admin -e debug
======== [root@vuwunicooimm001 admin-serv]# ls -l total 32 -rw-r--r-- 1 root root 28866 Jun 22 14:49 access -rw-r--r-- 1 root root 0 Jun 23 16:30 error [root@vuwunicooimm001 admin-serv]# tail access 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:03:44 +1200] "GET /slapd-vuwunicooimm001/Tasks/Operation/Restart HTTP/1.0" 200 2384 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:30 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 643 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:30 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1338 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:04:40 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1872 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:06 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 643 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:06 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1338 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:13:05:16 +1200] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 1815 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:47:34 +1200] "POST /slapd-vuwunicooimm001/Tasks/Operation/ViewLog HTTP/1.0" 200 3883 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:47:58 +1200] "POST /slapd-vuwunicooimm001/Tasks/Operation/ViewLog HTTP/1.0" 200 2174 130.195.53.100 - uid=ldapadmin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot [22/Jun/2010:14:49:45 +1200] "GET /slapd-vuwunicooimm001/Tasks/Operation/Restart HTTP/1.0" 200 2270 [root@vuwunicooimm001 admin-serv]# ========
regards
Steve n
-----Original Message----- From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Techie Sent: Wednesday, 23 June 2010 5:30 p.m. To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] restarting the 389 after a reboot
What does /var/log/dirsrv/admin-serv/error say? Should give you a good clue. Kind of sounds like an SSL instance trying to start without a pin file but just guessing there.
TC
On Tue, Jun 22, 2010 at 9:27 PM, Steven Jones Steven.Jones@vuw.ac.nz wrote:
Hi,
After a system reboot the Ldap admin service appears not to be running.
How do I restart it?
I tried "service dirsrv-admin start" but this just hangs / never returns to the console.
thanks
Steven
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
8><----
start the admin server like this: /usr/sbin/start-ds-admin -e debug
8><----
Great thanks...nice output.....
==================== [root@vuwunicooimm001 admin-serv]# /usr/sbin/start-ds-admin -e debug [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module authz_host_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module auth_basic_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module authn_file_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module log_config_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module env_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module mime_magic_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module expires_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module deflate_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module headers_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module unique_id_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module setenvif_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module mime_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module vhost_alias_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module negotiation_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module dir_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module actions_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module alias_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module rewrite_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module cache_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module disk_cache_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module cgi_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module restartd_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module nss_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module admserv_module [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2506): [18043] create_server_config [0xbogus %p for (null) [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for (null) [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2567): [18043] Set [0xbogus %p [ADMCacheLifeTime] to 600 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2585): [18043] Set [0xbogus %p [ADMServerVersionString] to 389-Administrator/1.1.10 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 0 httpd (pid 11347) already running [root@vuwunicooimm001 admin-serv]# pwd /etc/dirsrv/admin-serv =============
So I stopped it with,
"stop-ds-admin"
and restarted it,
===================== [root@vuwunicooimm001 sbin]# /usr/sbin/start-ds-admin -e debug [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module authz_host_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module auth_basic_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module authn_file_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module log_config_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module env_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module mime_magic_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module expires_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module deflate_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module headers_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module unique_id_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module setenvif_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module mime_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module vhost_alias_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module negotiation_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module dir_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module actions_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module alias_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module rewrite_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module cache_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module disk_cache_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module cgi_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module restartd_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module nss_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module admserv_module [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2506): [18668] create_server_config [0xbogus %p for (null) [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for (null) [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2567): [18668] Set [0xbogus %p [ADMCacheLifeTime] to 600 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2585): [18668] Set [0xbogus %p [ADMServerVersionString] to 389-Administrator/1.1.10 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 0 [root@vuwunicooimm001 sbin]# ====================
So I try the console, and I get a pop up box saying,
"Cannot logon because of an incorrect User ID, incorrect password or directory problem"
"java.io.InterruptedIOException: HTTP response timeout"
It appears to disappear on the second or tenth attempt, the admin server seems to take 2 to 7 minutes to get ready to answer.......
Then I get cannot connect to the directory server blah:389.
Now I have some error messages,
=========== [Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases [Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz] [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(1910): [18934] cache entry not found for user [ldapadmin] [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(1918): [18934] user [ldapadmin] not cached - reason user not in cache [Thu Jun 24 14:05:46 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Thu Jun 24 14:05:46 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null) [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz] [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(1910): [18934] cache entry not found for user [ldapadmin] [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(1918): [18934] user [ldapadmin] not cached - reason user not in cache [Thu Jun 24 14:52:25 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Thu Jun 24 14:52:25 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null) [root@vuwunicooimm001 admin-serv]# ====================
regards
Steven
Steven Jones wrote:
8><----
start the admin server like this: /usr/sbin/start-ds-admin -e debug
8><----
Great thanks...nice output.....
==================== [root@vuwunicooimm001 admin-serv]# /usr/sbin/start-ds-admin -e debug [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module authz_host_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module auth_basic_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module authn_file_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module log_config_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module env_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module mime_magic_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module expires_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module deflate_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module headers_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module unique_id_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module setenvif_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module mime_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module vhost_alias_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module negotiation_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module dir_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module actions_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module alias_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module rewrite_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module cache_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module disk_cache_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module cgi_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module restartd_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module nss_module [Thu Jun 24 13:44:55 2010] [debug] mod_so.c(246): loaded module admserv_module [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2506): [18043] create_server_config [0xbogus %p for (null) [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for (null) [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2567): [18043] Set [0xbogus %p [ADMCacheLifeTime] to 600 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2585): [18043] Set [0xbogus %p [ADMServerVersionString] to 389-Administrator/1.1.10 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2494): [18043] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ [Thu Jun 24 13:44:55 2010] [debug] mod_admserv/mod_admserv.c(2519): [18043] adminsdk [0xbogus %p flag 0 httpd (pid 11347) already running [root@vuwunicooimm001 admin-serv]# pwd /etc/dirsrv/admin-serv =============
So I stopped it with,
"stop-ds-admin"
and restarted it,
===================== [root@vuwunicooimm001 sbin]# /usr/sbin/start-ds-admin -e debug [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module authz_host_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module auth_basic_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module authn_file_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module log_config_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module env_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module mime_magic_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module expires_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module deflate_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module headers_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module unique_id_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module setenvif_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module mime_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module vhost_alias_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module negotiation_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module dir_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module actions_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module alias_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module rewrite_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module cache_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module disk_cache_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module cgi_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module restartd_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module nss_module [Thu Jun 24 13:56:59 2010] [debug] mod_so.c(246): loaded module admserv_module [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2506): [18668] create_server_config [0xbogus %p for (null) [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for (null) [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2567): [18668] Set [0xbogus %p [ADMCacheLifeTime] to 600 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2585): [18668] Set [0xbogus %p [ADMServerVersionString] to 389-Administrator/1.1.10 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 1 [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2494): [18668] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ [Thu Jun 24 13:56:59 2010] [debug] mod_admserv/mod_admserv.c(2519): [18668] adminsdk [0xbogus %p flag 0 [root@vuwunicooimm001 sbin]#
Note that more debug output will go to the /var/log/dirsrv/admin-serv/error file.
====================
So I try the console, and I get a pop up box saying,
"Cannot logon because of an incorrect User ID, incorrect password or directory problem"
"java.io.InterruptedIOException: HTTP response timeout"
It appears to disappear on the second or tenth attempt, the admin server seems to take 2 to 7 minutes to get ready to answer.......
Then I get cannot connect to the directory server blah:389.
Now I have some error messages,
=========== [Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases [Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz] [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(1910): [18934] cache entry not found for user [ldapadmin] [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(1918): [18934] user [ldapadmin] not cached - reason user not in cache [Thu Jun 24 14:05:46 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4
This is the real problem I think - looks like you've told the console/admin server to use SSL to connect to the directory server, but you haven't specified to use port 636
http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
see also the configuration directory ldap url - ldapurl in /etc/dirsrv/admin-serv/adm.conf
[Thu Jun 24 14:05:46 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Thu Jun 24 14:05:46 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:05:46 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null) [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz] [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(1910): [18934] cache entry not found for user [ldapadmin] [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(1918): [18934] user [ldapadmin] not cached - reason user not in cache [Thu Jun 24 14:52:25 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:52:25 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Thu Jun 24 14:52:25 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 389: 4 [Thu Jun 24 14:52:25 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null) [root@vuwunicooimm001 admin-serv]# ====================
regards
Steven
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
8><-----
This is the real problem I think - looks like you've told the
console/admin server to use SSL to connect to the directory server, but
you haven't specified to use port 636
8><-----
Im not aware I did....
8><-----
http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
see also the configuration directory ldap url - ldapurl in
/etc/dirsrv/admin-serv/adm.conf
8><-----
Ok, I fixed the latter by editing the adm.conf to point at 636....however I now have a SSL error...
============
[root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
============
Ive tried using this syntax but with no joy...
ldapmodify -x -D "cn=directory manager" -w password
dn: dn of your server instance entry
changetype: modify
replace: nsServerSecurity
nsServerSecurity: on
so my command is,
ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace: nsServerSecurity nsServerSecurity on
which fails......
Doing a,
[root@vuwunicooimm001 admin-serv]# certutil -d . -L
===============
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
VUW CA cert CT,,
==============
So I dont know if cutting and pasting the errors work, anyway, attempting to restart the console I get,
[cid:image001.png@01CB1448.03A1B040]
So I put in the details,
[cid:image002.png@01CB1448.58B30840]
Which fails,
error log for adminserv....
==========================
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz]
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(1910): [25584] cache entry not found for user [ldapadmin]
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(1918): [25584] user [ldapadmin] not cached - reason user not in cache
[Fri Jun 25 09:19:22 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 636: 4
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
[Fri Jun 25 09:19:22 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 636: 4
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null)
=========================
regards
Steven Jones wrote:
8><-----
This is the real problem I think - looks like you've told the
console/admin server to use SSL to connect to the directory server, but
you haven't specified to use port 636
8><-----
Im not aware I did....
8><-----
http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
see also the configuration directory ldap url - ldapurl in
/etc/dirsrv/admin-serv/adm.conf
8><-----
Ok, I fixed the latter by editing the adm.conf to point at 636....however I now have a SSL error...
============
[root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSLroutines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Why is /usr/bin/ldapsearch attempting to use SSL by default? What's in your /etc/openldap/ldap.conf or ~/.ldaprc?
============
Ive tried using this syntax but with no joy...
ldapmodify -x -D "cn=directory manager" -w password
dn: dn of your server instance entry
changetype: modify
replace: nsServerSecurity
nsServerSecurity: on
so my command is,
ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace: nsServerSecurity nsServerSecurity on
? this is all on one command line? I guess it's not clear from the example, but ldapmodify by default wants to read the LDIF input from stdin - so after you type in $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX it will wait for you to type in the rest on stdin, followed by a blank line (i.e. hit Enter twice) followed by Ctrl-C or Ctrl-D to "get out" of ldapmodify
you could also dump those commands in a file and run $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX -f /path/to/file.ldif
which fails......
Doing a,
[root@vuwunicooimm001 admin-serv]# certutil -d . -L
===============
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
VUW CA cert CT,,
==============
So I dont know if cutting and pasting the errors work, anyway, attempting to restart the console I get,
So I put in the details,
Which fails,
Is the directory server listening for TLS/SSL requests on port 636? That is, have you configured the directory server for TLS/SSL and have you confirmed that it is listening?
error log for adminserv....
==========================
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host [localhost.localdomain] did not match pattern [*.vuw.ac.nz] -will scan aliases
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: host alias [localhost] did not match pattern [*.vuw.ac.nz]
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(2762): admserv_check_user_id
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(1910): [25584] cache entry not found for user [ldapadmin]
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(1918): [25584] user [ldapadmin] not cached - reason user not in cache
[Fri Jun 25 09:19:22 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 636: 4
[Fri Jun 25 09:19:22 2010] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
[Fri Jun 25 09:19:22 2010] [crit] buildUGInfo(): unable to initialize TLS connection to LDAP host vuwunicooimm001.vuw.ac.nz port 636: 4
[Fri Jun 25 09:19:22 2010] [debug] mod_admserv/mod_admserv.c(2609): userauth, bind (null)
=========================
regards
Before you do anything else, confirm that the directory server is indeed listening for TLS/SSL requests on port 636.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Steven Jones wrote:
8><-----
see also the configuration directory ldap url - ldapurl in
/etc/dirsrv/admin-serv/adm.conf
8><-----
Ok, I fixed the latter by editing the adm.conf to point at 636....however I now have a SSL error...
============
[root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSLroutines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Why is /usr/bin/ldapsearch attempting to use SSL by default? What's in your /etc/openldap/ldap.conf or ~/.ldaprc?
Ok, fixed
ldaps changed to ldap
============
Ive tried using this syntax but with no joy...
ldapmodify -x -D "cn=directory manager" -w password
dn: dn of your server instance entry
changetype: modify
replace: nsServerSecurity
nsServerSecurity: on
so my command is,
ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace: nsServerSecurity nsServerSecurity on
? this is all on one command line?
Yes...
I guess it's not clear from the example, but ldapmodify by default wants to read the LDIF input from stdin - so after you type in
OK.......
$ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX it will wait for you to type in the rest on stdin, followed by a blank line (i.e. hit Enter twice) followed by Ctrl-C or Ctrl-D to "get out" of ldapmodify
=================== [root@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed [root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXX ldap_bind: No such object (32) [root@vuwunicooimm001 admin-serv]# ===================
um?
you could also dump those commands in a file and run $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX -f /path/to/file.ldif
=================== [root@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" -w cvbrty542 -f file.ldif ldap_bind: No such object (32) [root@vuwunicooimm001 admin-serv]# ===================
8><----------
Is the directory server listening for TLS/SSL requests on port 636? That is, have you configured the directory server for TLS/SSL and have you confirmed that it is listening?
8><-----
Before you do anything else, confirm that the directory server is indeed listening for TLS/SSL requests on port 636.
============= [root@vuwunicooimm001 admin-serv]# netstat -a -n |grep :636 tcp 0 0 127.0.0.1:49186 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:49185 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35428 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35429 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35430 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35424 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35425 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35426 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35427 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35412 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35413 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35414 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35415 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35408 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35409 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35410 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35411 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35420 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35421 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35422 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35423 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35416 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35417 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35418 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35419 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35404 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35405 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35406 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35407 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35403 127.0.0.1:636 TIME_WAIT tcp 0 0 :::636 :::* LISTEN [root@vuwunicooimm001 admin-serv]# ============
regards
On 06/24/2010 03:49 PM, Steven Jones wrote:
Steven Jones wrote:
8><-----
see also the configuration directory ldap url - ldapurl in
/etc/dirsrv/admin-serv/adm.conf
8><-----
Ok, I fixed the latter by editing the adm.conf to point at 636....however I now have a SSL error...
============
[root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSLroutines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Why is /usr/bin/ldapsearch attempting to use SSL by default? What's in your /etc/openldap/ldap.conf or ~/.ldaprc?
Ok, fixed
ldaps changed to ldap
============
Ive tried using this syntax but with no joy...
ldapmodify -x -D "cn=directory manager" -w password
dn: dn of your server instance entry
changetype: modify
replace: nsServerSecurity
nsServerSecurity: on
so my command is,
ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace: nsServerSecurity nsServerSecurity on
? this is all on one command line?
Yes...
I guess it's not clear from theexample, but ldapmodify by default wants to read the LDIF input from stdin - so after you type in
OK.......
$ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX it will wait for you to type in the rest on stdin, followed by a blank line (i.e. hit Enter twice) followed by Ctrl-C or Ctrl-D to "get out" of ldapmodify
=================== [root@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed [root@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXX ldap_bind: No such object (32) [root@vuwunicooimm001 admin-serv]# ===================
um?
You need to specify a password with the "-w" option to ldapmodify. Supplying a bind DN with no password is considered an "unauthenticated" bind, which is not allowed by default.
I believe the ldapsearch error is saying that the "cn=ldapadmin" entry does not exist. This does not appear to be a full DN. You can check what your ldap "superuser" account is by looking at your nsslapd-rootdn setting /etc/dirsrv/slapd-<foo>/dse.ldif. The default is "cn=Directory Manager". If you actually created a "cn=ldapadmin" user in your database, you need to specify the rest of the DN when binding as that user.
you could also dump those commands in a file and run $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX -f /path/to/file.ldif
=================== [root@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" -w cvbrty542 -f file.ldif ldap_bind: No such object (32) [root@vuwunicooimm001 admin-serv]# ===================
8><----------
Is the directory server listening for TLS/SSL requests on port 636? That is, have you configured the directory server for TLS/SSL and have you confirmed that it is listening?
8><-----
Before you do anything else, confirm that the directory server is indeed listening for TLS/SSL requests on port 636.
============= [root@vuwunicooimm001 admin-serv]# netstat -a -n |grep :636 tcp 0 0 127.0.0.1:49186 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:49185 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35428 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35429 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35430 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35424 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35425 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35426 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35427 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35412 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35413 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35414 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35415 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35408 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35409 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35410 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35411 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35420 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35421 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35422 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35423 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35416 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35417 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35418 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35419 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35404 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35405 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35406 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35407 127.0.0.1:636 TIME_WAIT tcp 0 0 127.0.0.1:35403 127.0.0.1:636 TIME_WAIT tcp 0 0 :::636 :::* LISTEN [root@vuwunicooimm001 admin-serv]# ============
regards
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Thanks Rich,
I did more experiment, and I noticed one of my database didn't get reload after I ran ldif2db.pl script
My DIT has a root database and then a sub database under the root database. When I did the export, I exported from the root database. When I ran the ldif2db.pl script, only the root database get reloaded but not the sub database.
Do you have any ideas?
Thanks in advance
- David
On Tue, Jun 22, 2010 at 5:30 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
Hi Rich,
I did some testing and it appears to be working as you expected. The steps involve
- Export the directory database to a LDIF
- Reload the directory database
- Reinitialize the consumer
I have another question. I noticed there's an ACI on the directory database LDIF. aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server Group, cn= foo.com http://foo.com, ou=tscei.dd-x.com http://tscei.dd-x.com, o=NetscapeRoot";)
Do I need to modify the hostname in that ACI if I want to load the same directory database into another LDAP? Essentially I want to use a basic directory database LDIF and load it to a bunch of different development LDAP we have. Some LDAPs are multi-mastered configured and most are not.
No, you do not need to change that hostname.
Thanks in advance
- David
On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > 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 I don't think it matters. I suppose you might want to keep createTimestamp and modifyTimestamp just for your own information. > > My LDIF backup will be imported back to the LDAP using ldif2db.pl <http://ldif2db.pl> > <http://ldif2db.pl>. > > - David > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> wrote: > > Thanks Rich, I'll give that a try. > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://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 serverto
> 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... )
> > You can use db2ldif.pl <http://db2ldif.pl> <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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 oneLDAP,
> 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 othermaster
> (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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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 okaybut
> 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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > >
> > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > >
> > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Chun Tat David Chu wrote:
Thanks Rich,
I did more experiment, and I noticed one of my database didn't get reload after I ran ldif2db.pl http://ldif2db.pl script
My DIT has a root database and then a sub database under the root database. When I did the export, I exported from the root database. When I ran the ldif2db.pl http://ldif2db.pl script, only the root database get reloaded but not the sub database.
Do you have any ideas?
Yes. You need an LDIF for each database.
Thanks in advance
- David
On Tue, Jun 22, 2010 at 5:30 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Hi Rich, > > I did some testing and it appears to be working as you expected. > The steps involve > 1) Export the directory database to a LDIF > 2) Reload the directory database > 3) Reinitialize the consumer > > I have another question. I noticed there's an ACI on the directory > database LDIF. > aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) > groupdn = "l > dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server Group, cn= > foo.com <http://foo.com> <http://foo.com>, ou=tscei.dd-x.com <http://tscei.dd-x.com> <http://tscei.dd-x.com>, > o=NetscapeRoot";) > > Do I need to modify the hostname in that ACI if I want to load the > same directory database into another LDAP? Essentially I want to use > a basic directory database LDIF and load it to a bunch of different > development LDAP we have. Some LDAPs are multi-mastered configured > and most are not. No, you do not need to change that hostname. > > Thanks in advance > > - David > > On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > Chun Tat David Chu wrote: > > 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 > I don't think it matters. I suppose you might want to keep > createTimestamp and modifyTimestamp just for your own information. > > > > My LDIF backup will be imported back to the LDAP using > ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> > > <http://ldif2db.pl>. > > > > - David > > > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> wrote: > > > > Thanks Rich, I'll give that a try. > > > > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://ldif2db.pl> > <http://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 <http://db2ldif.pl> <http://db2ldif.pl> > <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
Thanks for helping. I followed your direction and exported another LDIF for my 2nd database but whenever I try to load it I get an error message "ldap_add: Operations error".
Here's a little information on my DIT hierarchy. Database 1: dc=foo,dc=com Database 2: dc=new_foo,dc=foo,dc=com
I ran the ldif2db.pl using the verbose switch and here's the output. ldapmodify: started Wed Jun 23 17:11:34 2010
ldap_init( <hostname>, 389 ) add objectclass: top extensibleObject add cn: import_2010_6_23_17_11_34 add nsInstance: userRoot add nsFilename: /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif add nsImportChunkSize: 0 add nsUniqueIdGenerator: time adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, cn=config ldap_add: Operations error
At this point, I am stuck. Do you have any idea what went wrong? The reload of the root database does work but when I reload the 2nd database that sits underneath in the root database in the DIT it doesn't work.
Thanks in advance!
- David
On Tue, Jun 22, 2010 at 6:58 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
Thanks Rich,
I did more experiment, and I noticed one of my database didn't get reload after I ran ldif2db.pl http://ldif2db.pl script
My DIT has a root database and then a sub database under the root database. When I did the export, I exported from the root database. When I ran the ldif2db.pl http://ldif2db.pl script, only the root database get reloaded but not the sub database.
Do you have any ideas?
Yes. You need an LDIF for each database.
Thanks in advance
- David
On Tue, Jun 22, 2010 at 5:30 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Hi Rich, > > I did some testing and it appears to be working as you expected. > The steps involve > 1) Export the directory database to a LDIF > 2) Reload the directory database > 3) Reinitialize the consumer > > I have another question. I noticed there's an ACI on the directory > database LDIF. > aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) > groupdn = "l > dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server Group, cn= > foo.com <http://foo.com> <http://foo.com>, ou=tscei.dd-x.com <http://tscei.dd-x.com> <http://tscei.dd-x.com>, > o=NetscapeRoot";) > > Do I need to modify the hostname in that ACI if I want to load the > same directory database into another LDAP? Essentially I want to use > a basic directory database LDIF and load it to a bunch of different > development LDAP we have. Some LDAPs are multi-mastered configured > and most are not. No, you do not need to change that hostname. > > Thanks in advance > > - David > > On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > Chun Tat David Chu wrote: > > 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 > I don't think it matters. I suppose you might want to keep > createTimestamp and modifyTimestamp just for your own information. > > > > My LDIF backup will be imported back to the LDAP using > ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> > > <http://ldif2db.pl>. > > > > - David > > > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> wrote: > > > > Thanks Rich, I'll give that a try. > > > > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> <http://ldif2db.pl> > <http://ldif2db.pl> > > <http://ldif2db.pl> Perl script right? > > Yes, if you need to restore _all_ servers from anLDIF
> 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... )
> > > > You can use db2ldif.pl <http://db2ldif.pl> <http://db2ldif.pl> > <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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 LDIFfile.
> 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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > >
> > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > >
> > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Chun Tat David Chu wrote:
Hi Rich,
Thanks for helping. I followed your direction and exported another LDIF for my 2nd database but whenever I try to load it I get an error message "ldap_add: Operations error".
What's in the errors log?
Here's a little information on my DIT hierarchy. Database 1: dc=foo,dc=com Database 2: dc=new_foo,dc=foo,dc=com
I ran the ldif2db.pl http://ldif2db.pl using the verbose switch and here's the output. ldapmodify: started Wed Jun 23 17:11:34 2010
ldap_init( <hostname>, 389 ) add objectclass: top extensibleObject add cn: import_2010_6_23_17_11_34 add nsInstance: userRoot add nsFilename: /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif add nsImportChunkSize: 0 add nsUniqueIdGenerator: time adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, cn=config ldap_add: Operations error
At this point, I am stuck. Do you have any idea what went wrong? The reload of the root database does work but when I reload the 2nd database that sits underneath in the root database in the DIT it doesn't work.
Thanks in advance!
- David
On Tue, Jun 22, 2010 at 6:58 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Thanks Rich, > > I did more experiment, and I noticed one of my database didn't get > reload after I ran ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> script > > My DIT has a root database and then a sub database under the root > database. When I did the export, I exported from the root database. > When I ran the ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> script, only the root > database get reloaded but not the sub database. > > Do you have any ideas? Yes. You need an LDIF for each database. > > Thanks in advance > > - David > > On Tue, Jun 22, 2010 at 5:30 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > Chun Tat David Chu wrote: > > Hi Rich, > > > > I did some testing and it appears to be working as you expected. > > The steps involve > > 1) Export the directory database to a LDIF > > 2) Reload the directory database > > 3) Reinitialize the consumer > > > > I have another question. I noticed there's an ACI on the directory > > database LDIF. > > aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) > > groupdn = "l > > dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server > Group, cn= > > foo.com <http://foo.com> <http://foo.com> <http://foo.com>, ou=tscei.dd-x.com <http://tscei.dd-x.com> > <http://tscei.dd-x.com> <http://tscei.dd-x.com>, > > o=NetscapeRoot";) > > > > Do I need to modify the hostname in that ACI if I want to load the > > same directory database into another LDAP? Essentially I want > to use > > a basic directory database LDIF and load it to a bunch of different > > development LDAP we have. Some LDAPs are multi-mastered configured > > and most are not. > No, you do not need to change that hostname. > > > > Thanks in advance > > > > - David > > > > On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> wrote: > > > > Chun Tat David Chu wrote: > > > 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 > > I don't think it matters. I suppose you might want to keep > > createTimestamp and modifyTimestamp just for your own > information. > > > > > > My LDIF backup will be imported back to the LDAP using > > ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> <http://ldif2db.pl> > > > <http://ldif2db.pl>. > > > > > > - David > > > > > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > > > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>>> wrote: > > > > > > Thanks Rich, I'll give that a try. > > > > > > > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > > > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> > <http://ldif2db.pl> <http://ldif2db.pl> > > <http://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 <http://db2ldif.pl> <http://db2ldif.pl> > <http://db2ldif.pl> > > <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> > > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>>> > > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>>> > > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>> > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>>> > > > > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > -- > > > > > 389 users mailing list > > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
I looked at both access log and error log. The access log has an addition of ldap_add failure but the error log doesn't say anything about the failure on loading the 2nd database.
- David
Access Log [23/Jun/2010:18:37:09 -0400] conn=12180 fd=118 slot=118 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=tscei ldap directory manager" [23/Jun/2010:18:37:09 -0400] conn=12180 op=1 ADD dn="cn=import_2010_6_23_18_37_9, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12180 op=1 RESULT err=0 tag=105 nentries=0 etime=2 [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 UNBIND [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 fd=118 closed - U1 [23/Jun/2010:18:37:11 -0400] conn=12181 fd=119 slot=119 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=tscei ldap directory manager" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 ADD dn="cn=import_2010_6_23_18_37_12, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 RESULT err=1 tag=105 nentries=0 etime=0 [23/Jun/2010:18:37:11 -0400] conn=12181 op=2 UNBIND
Error Log [23/Jun/2010:18:37:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [23/Jun/2010:18:37:11 -0400] - import userRoot: Beginning import job... [23/Jun/2010:18:37:11 -0400] - ldbm: 'userRoot' is already in the middle of another task and cannot be disturbed. [23/Jun/2010:18:37:11 -0400] - import userRoot: Index buffering enabled with bucket size 19 [23/Jun/2010:18:37:11 -0400] - import userRoot: Processing file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" [23/Jun/2010:18:37:11 -0400] - import userRoot: Finished scanning file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" (97 entries) [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers finished; cleaning up... [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers cleaned up. [23/Jun/2010:18:37:12 -0400] - import userRoot: Cleaning up producer thread... [23/Jun/2010:18:37:12 -0400] - import userRoot: Indexing complete. Post-processing... [23/Jun/2010:18:37:12 -0400] - import userRoot: Flushing caches... [23/Jun/2010:18:37:12 -0400] - import userRoot: Closing files... [23/Jun/2010:18:37:12 -0400] - import userRoot: Import complete. Processed 97 entries (91 entries were skipped because they don't belong to this database) in 1 seconds. (97.00 entries/sec)
On Wed, Jun 23, 2010 at 6:34 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
Hi Rich,
Thanks for helping. I followed your direction and exported another LDIF for my 2nd database but whenever I try to load it I get an error message "ldap_add: Operations error".
What's in the errors log?
Here's a little information on my DIT hierarchy. Database 1: dc=foo,dc=com Database 2: dc=new_foo,dc=foo,dc=com
I ran the ldif2db.pl http://ldif2db.pl using the verbose switch and here's the output. ldapmodify: started Wed Jun 23 17:11:34 2010
ldap_init( <hostname>, 389 ) add objectclass: top extensibleObject add cn: import_2010_6_23_17_11_34 add nsInstance: userRoot add nsFilename: /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif add nsImportChunkSize: 0 add nsUniqueIdGenerator: time adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, cn=config ldap_add: Operations error
At this point, I am stuck. Do you have any idea what went wrong? The reload of the root database does work but when I reload the 2nd database that sits underneath in the root database in the DIT it doesn't work.
Thanks in advance!
- David
On Tue, Jun 22, 2010 at 6:58 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Thanks Rich, > > I did more experiment, and I noticed one of my database didn't get > reload after I ran ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> script > > My DIT has a root database and then a sub database under the root > database. When I did the export, I exported from the rootdatabase.
> When I ran the ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> script, only the root > database get reloaded but not the sub database. > > Do you have any ideas? Yes. You need an LDIF for each database. > > Thanks in advance > > - David > > On Tue, Jun 22, 2010 at 5:30 PM, Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > Chun Tat David Chu wrote: > > Hi Rich, > > > > I did some testing and it appears to be working as you expected. > > The steps involve > > 1) Export the directory database to a LDIF > > 2) Reload the directory database > > 3) Reinitialize the consumer > > > > I have another question. I noticed there's an ACI on the directory > > database LDIF. > > aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) > > groupdn = "l > > dap:///cn=slapd-foo, cn=Red Hat Directory Server, cn=Server > Group, cn= > > foo.com <http://foo.com> <http://foo.com> <http://foo.com>, ou=tscei.dd-x.com <http://tscei.dd-x.com> > <http://tscei.dd-x.com> <http://tscei.dd-x.com>, > > o=NetscapeRoot";) > > > > Do I need to modify the hostname in that ACI if I want to load the > > same directory database into another LDAP? Essentially Iwant
> to use > > a basic directory database LDIF and load it to a bunch of different > > development LDAP we have. Some LDAPs are multi-mastered configured > > and most are not. > No, you do not need to change that hostname. > > > > Thanks in advance > > > > - David > > > > On Tue, Jun 22, 2010 at 2:43 PM, Rich Megginson > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> wrote: > > > > Chun Tat David Chu wrote: > > > 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 > > I don't think it matters. I suppose you might want to keep > > createTimestamp and modifyTimestamp just for your own > information. > > > > > > My LDIF backup will be imported back to the LDAP using > > ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> <http://ldif2db.pl> > > > <http://ldif2db.pl>. > > > > > > - David > > > > > > On Fri, Jun 18, 2010 at 4:40 PM, Chun Tat David Chu > > > <beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>>> wrote: > > > > > > Thanks Rich, I'll give that a try. > > > > > > > > > On Fri, Jun 18, 2010 at 4:20 PM, Rich Megginson > > > <rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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> > <http://ldif2db.pl> <http://ldif2db.pl> > > <http://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 arestore
> 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... )
> > > > > > You can use db2ldif.pl <http://db2ldif.pl> <http://db2ldif.pl> > <http://db2ldif.pl> > > <http://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@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>>> > > > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>> > > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com> <mailto:rmeggins@redhat.com <mailto:rmeggins@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@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>>> > > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>>> > > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>>> > > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com>> > > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@gmail.com> > <mailto:beyonddc.storage@gmail.com <mailto:beyonddc.storage@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@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>>> > > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>>> <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> <mailto:david_list@boreham.org <mailto:david_list@boreham.org>>> > > > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@boreham.org> > <mailto:david_list@boreham.org <mailto:david_list@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 sois
> simply > > using > > > the ldapdelete > > > > > command to > > > > > > remove all existing data and use > > ldapadd to > > > re-create > > > > the base > > > > > > hierarchy tree. Thisapproach
> 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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>>> > > > > > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > -- > > > > > 389 users mailing list > > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > > >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>>> > > > > > >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > > > > > > > > > > > > > > > > >
> > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>>> > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > > > > > >
> > > > > > -- > > > 389 users mailing list > > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>>> > >https://admin.fedoraproject.org/mailman/listinfo/389-users
> > > > > > >
> > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > >
> > -- > 389 users mailing list > 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
I looked at both access log and error log. The access log has an addition of ldap_add failure but the error log doesn't say anything about the failure on loading the 2nd database.
- David
Access Log [23/Jun/2010:18:37:09 -0400] conn=12180 fd=118 slot=118 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:09 -0400] conn=12180 op=1 ADD dn="cn=import_2010_6_23_18_37_ 9, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12180 op=1 RESULT err=0 tag=105 nentries=0 etime=2 [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 UNBIND [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 fd=118 closed - U1 [23/Jun/2010:18:37:11 -0400] conn=12181 fd=119 slot=119 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 ADD dn="cn=import_2010_6_23_18_37_12, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 RESULT err=1 tag=105 nentries=0 etime=0 [23/Jun/2010:18:37:11 -0400] conn=12181 op=2 UNBIND
Error Log [23/Jun/2010:18:37:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [23/Jun/2010:18:37:11 -0400] - import userRoot: Beginning import job... [23/Jun/2010:18:37:11 -0400] - ldbm: 'userRoot' is already in the middle of another task and cannot be disturbed. [23/Jun/2010:18:37:11 -0400] - import userRoot: Index buffering enabled with bucket size 19 [23/Jun/2010:18:37:11 -0400] - import userRoot: Processing file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" [23/Jun/2010:18:37:11 -0400] - import userRoot: Finished scanning file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" (97 entries) [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers finished; cleaning up... [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers cleaned up. [23/Jun/2010:18:37:12 -0400] - import userRoot: Cleaning up producer thread... [23/Jun/2010:18:37:12 -0400] - import userRoot: Indexing complete. Post-processing... [23/Jun/2010:18:37:12 -0400] - import userRoot: Flushing caches... [23/Jun/2010:18:37:12 -0400] - import userRoot: Closing files... [23/Jun/2010:18:37:12 -0400] - import userRoot: Import complete. Processed 97 entries (91 entries were skipped because they don't belong to this database) in 1 seconds. (97.00 entries/sec)
On Wed, Jun 23, 2010 at 6:34 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
Hi Rich,
Thanks for helping. I followed your direction and exported another LDIF for my 2nd database but whenever I try to load it I get an error message "ldap_add: Operations error".
What's in the errors log?
Here's a little information on my DIT hierarchy. Database 1: dc=foo,dc=com Database 2: dc=new_foo,dc=foo,dc=com
I ran the ldif2db.pl http://ldif2db.pl using the verbose switch and here's the output. ldapmodify: started Wed Jun 23 17:11:34 2010
ldap_init( <hostname>, 389 ) add objectclass: top extensibleObject add cn: import_2010_6_23_17_11_34 add nsInstance: userRoot add nsFilename: /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif add nsImportChunkSize: 0 add nsUniqueIdGenerator: time adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, cn=config ldap_add: Operations error
At this point, I am stuck. Do you have any idea what went wrong? The reload of the root database does work but when I reload the 2nd database that sits underneath in the root database in the DIT it doesn't work.
Thanks in advance!
- David
Chun Tat David Chu wrote:
Hi Rich,
I looked at both access log and error log. The access log has an addition of ldap_add failure but the error log doesn't say anything about the failure on loading the 2nd database.
What were the exact command line arguments you passed to ldif2db.pl? It looks as though you specified "userRoot" as the name of both databases - the database for your sub-suffix must have a different name - or you can use the -s "suffix" argument instead of -n databaseName
- David
Access Log [23/Jun/2010:18:37:09 -0400] conn=12180 fd=118 slot=118 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:09 -0400] conn=12180 op=1 ADD dn="cn=import_2010_6_23_18_37_ 9, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12180 op=1 RESULT err=0 tag=105 nentries=0 etime=2 [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 UNBIND [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 fd=118 closed - U1 [23/Jun/2010:18:37:11 -0400] conn=12181 fd=119 slot=119 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 ADD dn="cn=import_2010_6_23_18_37_12, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 RESULT err=1 tag=105 nentries=0 etime=0 [23/Jun/2010:18:37:11 -0400] conn=12181 op=2 UNBIND
Error Log [23/Jun/2010:18:37:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [23/Jun/2010:18:37:11 -0400] - import userRoot: Beginning import job... [23/Jun/2010:18:37:11 -0400] - ldbm: 'userRoot' is already in the middle of another task and cannot be disturbed. [23/Jun/2010:18:37:11 -0400] - import userRoot: Index buffering enabled with bucket size 19 [23/Jun/2010:18:37:11 -0400] - import userRoot: Processing file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" [23/Jun/2010:18:37:11 -0400] - import userRoot: Finished scanning file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" (97 entries) [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers finished; cleaning up... [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers cleaned up. [23/Jun/2010:18:37:12 -0400] - import userRoot: Cleaning up producer thread... [23/Jun/2010:18:37:12 -0400] - import userRoot: Indexing complete. Post-processing... [23/Jun/2010:18:37:12 -0400] - import userRoot: Flushing caches... [23/Jun/2010:18:37:12 -0400] - import userRoot: Closing files... [23/Jun/2010:18:37:12 -0400] - import userRoot: Import complete. Processed 97 entries (91 entries were skipped because they don't belong to this database) in 1 seconds. (97.00 entries/sec)
On Wed, Jun 23, 2010 at 6:34 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Hi Rich, > > Thanks for helping. I followed your direction and exported another > LDIF for my 2nd database but whenever I try to load it I get an error > message "ldap_add: Operations error". What's in the errors log? > > Here's a little information on my DIT hierarchy. > Database 1: dc=foo,dc=com > Database 2: dc=new_foo,dc=foo,dc=com > > I ran the ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> using the verbose switch and > here's the output. > ldapmodify: started Wed Jun 23 17:11:34 2010 > > ldap_init( <hostname>, 389 ) > add objectclass: > top > extensibleObject > add cn: > import_2010_6_23_17_11_34 > add nsInstance: > userRoot > add nsFilename: > /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif > add nsImportChunkSize: > 0 > add nsUniqueIdGenerator: > time > adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, > cn=config > ldap_add: Operations error > > At this point, I am stuck. Do you have any idea what went wrong? The > reload of the root database does work but when I reload the 2nd > database that sits underneath in the root database in the DIT it > doesn't work. > > Thanks in advance! > > - David >
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
d'oh! My bad...
You're absolutely correct! It is now working properly. Thanks!
- David
On Wed, Jun 23, 2010 at 6:48 PM, Rich Megginson rmeggins@redhat.com wrote:
Chun Tat David Chu wrote:
Hi Rich,
I looked at both access log and error log. The access log has an addition of ldap_add failure but the error log doesn't say anything about the failure on loading the 2nd database.
What were the exact command line arguments you passed to ldif2db.pl? It looks as though you specified "userRoot" as the name of both databases - the database for your sub-suffix must have a different name - or you can use the -s "suffix" argument instead of -n databaseName
- David
Access Log [23/Jun/2010:18:37:09 -0400] conn=12180 fd=118 slot=118 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:09 -0400] conn=12180 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:09 -0400] conn=12180 op=1 ADD dn="cn=import_2010_6_23_18_37_ 9, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12180 op=1 RESULT err=0 tag=105 nentries=0 etime=2 [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 UNBIND [23/Jun/2010:18:37:11 -0400] conn=12180 op=2 fd=118 closed - U1 [23/Jun/2010:18:37:11 -0400] conn=12181 fd=119 slot=119 connection from 138.125.205.65 to 138.125.205.65 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [23/Jun/2010:18:37:11 -0400] conn=12181 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 ADD dn="cn=import_2010_6_23_18_37_12, cn=import, cn=tasks, cn=config" [23/Jun/2010:18:37:11 -0400] conn=12181 op=1 RESULT err=1 tag=105 nentries=0 etime=0 [23/Jun/2010:18:37:11 -0400] conn=12181 op=2 UNBIND
Error Log [23/Jun/2010:18:37:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [23/Jun/2010:18:37:11 -0400] - import userRoot: Beginning import job... [23/Jun/2010:18:37:11 -0400] - ldbm: 'userRoot' is already in the middle of another task and cannot be disturbed. [23/Jun/2010:18:37:11 -0400] - import userRoot: Index buffering enabled with bucket size 19 [23/Jun/2010:18:37:11 -0400] - import userRoot: Processing file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" [23/Jun/2010:18:37:11 -0400] - import userRoot: Finished scanning file "/home/chud/OLAY/LDAP_REPOPULATION_TEST/dit.ldif" (97 entries) [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers finished; cleaning up... [23/Jun/2010:18:37:12 -0400] - import userRoot: Workers cleaned up. [23/Jun/2010:18:37:12 -0400] - import userRoot: Cleaning up producer thread... [23/Jun/2010:18:37:12 -0400] - import userRoot: Indexing complete. Post-processing... [23/Jun/2010:18:37:12 -0400] - import userRoot: Flushing caches... [23/Jun/2010:18:37:12 -0400] - import userRoot: Closing files... [23/Jun/2010:18:37:12 -0400] - import userRoot: Import complete. Processed 97 entries (91 entries were skipped because they don't belong to this database) in 1 seconds. (97.00 entries/sec)
On Wed, Jun 23, 2010 at 6:34 PM, Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
Chun Tat David Chu wrote: > Hi Rich, > > Thanks for helping. I followed your direction and exported another > LDIF for my 2nd database but whenever I try to load it I get an error > message "ldap_add: Operations error". What's in the errors log? > > Here's a little information on my DIT hierarchy. > Database 1: dc=foo,dc=com > Database 2: dc=new_foo,dc=foo,dc=com > > I ran the ldif2db.pl <http://ldif2db.pl> <http://ldif2db.pl> using the verbose switch and > here's the output. > ldapmodify: started Wed Jun 23 17:11:34 2010 > > ldap_init( <hostname>, 389 ) > add objectclass: > top > extensibleObject > add cn: > import_2010_6_23_17_11_34 > add nsInstance: > userRoot > add nsFilename: > /home/chud/OLAY/LDAP_REPOPULATION_TEST/second_dit.ldif > add nsImportChunkSize: > 0 > add nsUniqueIdGenerator: > time > adding new entry cn=import_2010_6_23_17_11_34, cn=import, cn=tasks, > cn=config > ldap_add: Operations error > > At this point, I am stuck. Do you have any idea what went wrong? The > reload of the root database does work but when I reload the 2nd > database that sits underneath in the root database in the DIT it > doesn't work. > > Thanks in advance! > > - David >
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Chun Tat David Chu -
David Boreham -
Nathan Kinder -
Rich Megginson -
Steven Jones -
Techie