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 <[email protected]>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 - [email protected]
> --------------------------------------------------------------
> Ldap Synchronization Connector (LSC) - http://lsc-project.org
> --------------------------------------------------------------
>
