Thanks Jonathan!  That was the trick.  I had the DN of the syncprov overlay entry wrong.  I had the following:

olcOverlay={0}syncprov,olcDatabase={0}config,cn=config

I changed it to:

olcOverlay=syncprov,olcDatabase={1}bdb,cn=config

And now the replication works between my two servers.

Just another side note, when I had the invalid DN for the syncprov overlay, it caused issues when trying to delete it from cn=config.  I have another thread going discussing it (called "segmentation fault when attempting to delete olcOverlay={0}syncprov entry in cn=config").  The delete issue goes away once I get the correct DN for syncprov overlay.  I will update that thread with this information as well.

Thanks to everyone who helped.  Hopefully the next person that runs into this will find these notes helpful ;o)

J


On Fri, Jul 23, 2010 at 8:25 AM, Jonathan Clarke <jonathan@phillipoux.net> wrote:
On 23/07/2010 14:53, jon brandt wrote:
I'm getting this error when trying to get N-Way Multimaster
configuration working between two servers using cn=config (Runtime
Configuration) method:

"do_syncrep2: rid=002 got search entry without SyncState control"

 From some searching around, I found out this normally means the
provider side doesn't have the syncprov overlay configured correctly.  I
think I have the correct syncprov overlay configured in both my servers
(I get the same error on both), but I must have something messed up.  I
did find this very helpful link in the SUSE bugzilla database (bug 384787):

https://bugzilla.novell.com/show_bug.cgi?id=384787

This cleared up some confusion I had with regard to the olcModuleLoad:
syncprov.la <http://syncprov.la/> which the OpenLDAP documentation

describes as needed in cn=config.  Apparently that is out of date info
according to Ralf H. who responded to the above report.  He mentions
that the overlays are compiled into slapd now, so this isn't needed.
Thanks Ralf!

This depends on how OpenLDAP is compiled. Modules may be included statically (as seems to be the case in SUSE), or as runtime-loadable modules (as is the case in other distributions).

Either way, if you try and load an overlay who's modules is not loaded, slapd will complain and refuse to start. So if your config has the syncprov overlay and slapd doesn't complain, it's safe to say you're OK on this one.


Anyway, with or without the olcModuleLoad stuff, my
configuration still doesn't work correctly.  Here it is, and any help is
very much appreciated!  Note that I left out the schema ldif files
below, they are the following standard ones: core, cosine,
inetorgperson, nis.


*olcOverlay={0}syncprov.ldif*


dn: olcOverlay={0}syncprov
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
entryUUID: 0adcc5dc-292d-102f-8dcb-97104602b49d
creatorsName: cn=manager,cn=config
createTimestamp: 20100721160201Z
entryCSN: 20100721160201.290849Z#000000#002#000000
modifiersName: cn=manager,cn=config
modifyTimestamp: 20100721160201Z

This overlay would normally be set up on the database you want to replicate. Ie, it should probably be named olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config.

Jonathan


--
--------------------------------------------------------------
Jonathan Clarke - jonathan@phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------