Error "got search entry without sync state control" on N-Way Multimaster cn=config Runtime Configuration
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 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! 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.
Server 1 (linux-h4bt):
*cn=config.ldif*
dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: b0a2110e-2926-102f-9fef-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z olcServerID: 3 entryCSN: 20100721160215.521297Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z contextCSN: 20100721160232.622424Z#000000#003#000000
*cn=module{0}.ldif*
dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1d89971e-292d-102f-9f46-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160232Z entryCSN: 20100721160232.622424Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160232Z
*olcDatabase={0}config.ldif*
dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: b0a2daa8-2926-102f-9ff5-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.935961Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z
*olcDatabase={1}bdb.ldif*
dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: b0a2ed7c-2926-102f-9ff7-bbe8cc5f05fe creatorsName: cn=manager,cn=config createTimestamp: 20100721151632Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://unidome88xxx bindmethod=simple timeout =0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no fil ter="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs ="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160215.966913Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z
*olcDatabase={-1}frontend.ldif*
dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: b0a2dddc-2926-102f-9ff6-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.936051Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z
*olcOverlay={0}syncprov.ldif*
dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 135f0e4a-292d-102f-9f45-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.566453Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z
Server 2 (unidome88xxx):
*cn=config.ldif*
dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 24af41c0-292c-102f-9291-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z olcServerID: 2 entryCSN: 20100721160201.051314Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z contextCSN: 20100721160215.084570Z#000000#002#000000
*cn=module{0}.ldif*
dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1315872a-292d-102f-8dcc-97104602b49d creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.084570Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z
*olcDatabase={0}config.ldif*
dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 24b12f3a-292c-102f-9297-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129218Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z
*olcDatabase={1}bdb.ldif*
dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 24b1553c-292c-102f-9299-b374f89e9aa0 creatorsName: cn=manager,cn=config createTimestamp: 20100721155535Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://linux-h4bt bindmethod=simple timeout=0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no filte r="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs=" *,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160201.689045Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z
*olcDatabase={-1}frontend.ldif*
dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 24b134a8-292c-102f-9298-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129372Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z
*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
* *
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
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.netwrote:
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
openldap-technical@openldap.org
-
jon brandt -
Jonathan Clarke