Sorry in advance if i'm missed something obvious (which is what the text of this error makes me think), but i've spent 2 days on this and could use another set of eyes. I hit the error in the subject when trying to set up basic refreshAndPersist replication with 2 separate BDB databases defined and populated. The error happens on only 1 of the databases (replication works fine on the other.)
(slapd.conf for Master....)
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args
####################################################################### # BDB database definitions #######################################################################
database bdb suffix "dc=exampleb1,dc=com" rootdn "cn=kingb1,dc=exampleb1,dc=com" rootpw password directory /usr/local/var/openldap-data/bdb1 index objectClass,sn,mail,street,pager eq
database bdb suffix "o=baseballs" rootdn "cn=admin,o=baseballs" rootpw password directory /usr/local/var/openldap-data/bdb2 index objectClass,sn,mail,street,pager eq
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
database monitor
(slapd.conf for Slave...)
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args
####################################################################### # BDB database definitions #######################################################################
database bdb suffix "dc=exampleb1,dc=com" rootdn "cn=kingb1,dc=exampleb1,dc=com" rootpw password directory /usr/local/var/openldap-data/bdb1 index objectClass,sn,mail,street,pager eq
database bdb suffix "o=baseballs" rootdn "cn=admin,o=baseballs" rootpw password directory /usr/local/var/openldap-data/bdb2 index objectClass,sn,mail,street,pager eq
syncrepl rid=492 provider=ldap://9.00.00.000:389 type=refreshAndPersist retry="120 +" searchbase="dc=exampleb1,dc=com" bindmethod=simple binddn="cn=kingb1,dc=exampleb1,dc=com" credentials=password
database monitor
I get the Master up and populated before starting the Slave. When i start the Slave, i get the error. Here's the output with -d 256... (line 38 is the end of the syncrepl chunk... the "credentials=password" line)
OpenLDAP 2.4.6 Standalone LDAP Server (slapd)/test/slapd_multibackendsS.conf: li ne 38: Base DN "dc=exampleb1,dc=com" is not within the database naming context.+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 failed to add syncinfo+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 slapd stopped.+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 connections_destroy: nothing to destroy.+
If i modify the syncrepl statement in the slave to replicate the other database, replication of "o=baseballs" works...
syncrepl rid=493 provider=ldap://9.00.00.000:389 type=refreshAndPersist retry="120 +" searchbase="o=baseballs" bindmethod=simple binddn="cn=admin,o=baseballs" credentials=password
The data in "dc=exampleb1,dc=com" is straight from the output of the MakeLDIF utility. I've added/searched/modified it a bunch before trying this particular replication scenario.
So... how stupid am i?? Do you see anything i'm missing? Thanks for your help...
--On Wednesday, September 10, 2008 12:18 AM -0400 Brad T Waldorf bwaldorf@us.ibm.com wrote:
So... how stupid am i?? Do you see anything i'm missing? Thanks for your help...
Your master config clearly shows that you only instantiated the syncprov overlay for the suffix "o=baseballs" database. If you want to replicate the suffix "dc=exampleb1,dc=com" database, you need to add the syncprov overlay to it instead.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, September 10, 2008 12:18 AM -0400 Brad T Waldorf bwaldorf@us.ibm.com wrote:
So... how stupid am i?? Do you see anything i'm missing? Thanks for your help...
Your master config clearly shows that you only instantiated the syncprov overlay for the suffix "o=baseballs" database. If you want to replicate the suffix "dc=exampleb1,dc=com" database, you need to add the syncprov overlay to it instead.
--Quanah
Knew it was something stupid! For some reason i was under the impression the Master only needed 1 "overlay syncprov" instance, regardless of the number of databases being replicated. Thanks Quanah
On Wednesday 10 September 2008 06:18:19 Brad T Waldorf wrote:
database bdb suffix "o=baseballs"
[...]
index objectClass,sn,mail,street,pager eq
syncrepl rid=492
[...]
searchbase="dc=exampleb1,dc=com"
dc=exampleb1,dc=com (the syncrepl searchbase) does not fit under o=baseballs (the suffix of the database which holds the syncrepl statement). If you want to replicate one base DN to another base DN, you should use back-ldap with a rewrite rule on the consumer side, or back-relay on the provider side, which will allow you to still satisfy this restriction.
If i modify the syncrepl statement in the slave to replicate the other database, replication of "o=baseballs" works...
syncrepl rid=493
[...]
searchbase="o=baseballs"
Well, the if fits inside the database that holds it ...
BTW, you don't have the indexes required for syncrepl to work adequately ... what documentation did you use as the basis for this setup?
Regards, Buchan
On Wednesday 10 September 2008 06:18:19 Brad T Waldorf wrote:
database bdb suffix "o=baseballs"
[...]
index objectClass,sn,mail,street,pager eq
syncrepl rid=492
[...]
searchbase="dc=exampleb1,dc=com"
dc=exampleb1,dc=com (the syncrepl searchbase) does not fit under
o=baseballs
(the suffix of the database which holds the syncrepl statement). If you
want
to replicate one base DN to another base DN, you should use back-ldap with
a
rewrite rule on the consumer side, or back-relay on the provider side,
which
will allow you to still satisfy this restriction.
If i modify the syncrepl statement in the slave to replicate the other database, replication of "o=baseballs" works...
syncrepl rid=493
[...]
searchbase="o=baseballs"
Well, the if fits inside the database that holds it ...
BTW, you don't have the indexes required for syncrepl to work
adequately ...
what documentation did you use as the basis for this setup?
Good point Buchan, thanks for pointing this out. I've spent a bit of time playing with indexes, mainly to see how slapindex works. For documentation, I've used the admin guide and man pages quite a bit, as well as googling all the errors i encounter. Specifically for indexes, http://www.openldap.org/doc/admin24/tuning.html#Indexes. I've found that indexes are regenerated on certain actions (slapadd, ldapadd, and even ldapsearch... maybe i'm wrong on that one, but it seems like it). Most of the time, by the time i've stopped the server to slapindex (because i've added/modified entries or whatever), the indexes are already regenerated... so slapindex is of no consequence. Not sure what i'm missing... maybe indexes are automatically generated on certain actions, and i've missed the purpose of slapindex.
But anyway, in trying all this index stuff, i settled on those index values above (index objectClass,sn,mail,street,pager eq) just for playing purposes. I gave a quick skim of the replication chapter of the admin guide and ctrl+f for "index", and i think i see that i should probably include the following indexes as well?.... index objectclass,entryCSN,entryUUID eq
Sorry for not understanding this better. Thanks for your help!
openldap-technical@openldap.org
-
Brad T Waldorf -
Buchan Milne -
Quanah Gibson-Mount