Dears,
I've 4 masters in mirror mode and I try to sort out of replication issue for config DB.
When I modify one parameter, sometimes it's replicated on all masters but for some other modification it's not.
Here is extract from logs :
Sep 21 18:14:57 obesulus prod-corp-M[3073666]: do_syncrep2: rid=003 cookie=rid=003,sid=003 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_message_to_entry: rid=003 DN: olcDatabase={0}config,cn=config, UUID: 94f2e3c6-7209-102f-9dc5-7b3f1ec29d0e Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=(none) tid 0x7f5f890fb700 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: dn_callback : entries have identical CSN olcDatabase={0}config,cn=config 20210921161430.588403Z#000000#002#000000 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 be_search (0) Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 olcDatabase={0}config,cn=config Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 entry unchanged, ignored (olcDatabase={0}config,cn=config)
I don't know why I've this "entries have identical CSN" while entry has been modified on one master.
I checked my syncrepl definition against URI and it's OK so I don't know what's the clue.
Can you help me ?
Thx, Jean-Luc.
--On Tuesday, September 21, 2021 5:28 PM +0000 bourguijl@gmail.com wrote:
Dears,
I've 4 masters in mirror mode and I try to sort out of replication issue for config DB.
You already stated you're using an OpenLDAP release that's over 6 years old. As you were already informed, numerous bug fixes in replication have been resolved in the intervening years. You need to upgrade to a supported OpenLDAP release.
I will note that Symas provides free drop-in replacements for many linux distributions for the OpenLDAP 2.4 series (https://repo.symas.com/sofl/). However, I'd strongly advise looking at migrating to 2.5. Symas provides free 2.5 packages as well (https://repo.symas.com/soldap/). Additionally, optional paid support is available for either.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello Quanah,
I already use 2.5.x version since a while and below issue is under 2.5.7 version. So I suppose that you confound me with someone else ;-)
So can you advise to sort out this issue ?
Thx, J-L.
On 21 Sep 2021, at 18:59, Quanah Gibson-Mount quanah@symas.com wrote:
--On Tuesday, September 21, 2021 5:28 PM +0000 bourguijl@gmail.com wrote:
Dears,
I've 4 masters in mirror mode and I try to sort out of replication issue for config DB.
You already stated you're using an OpenLDAP release that's over 6 years old. As you were already informed, numerous bug fixes in replication have been resolved in the intervening years. You need to upgrade to a supported OpenLDAP release.
I will note that Symas provides free drop-in replacements for many linux distributions for the OpenLDAP 2.4 series (https://repo.symas.com/sofl/). However, I'd strongly advise looking at migrating to 2.5. Symas provides free 2.5 packages as well (https://repo.symas.com/soldap/). Additionally, optional paid support is available for either.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, September 22, 2021 12:38 AM +0200 Jean-Luc Bourguignon bourguijl@gmail.com wrote:
Hello Quanah,
I already use 2.5.x version since a while and below issue is under 2.5.7 version. So I suppose that you confound me with someone else ;-)
yes, I did, my apologies. ;)
So can you advise to sort out this issue ?
What is the parameter in question that you're modifying that isn't replicating? What was the old value and what is the new value? Can you provide your configuration (minus passwords) for the cn=config db for all nodes?
I can see if I can craft a reproduction case with that information.
Thanks, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello Quanah,
no problems ;-)
Here is my config :
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 afd35345 dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=manager,cn=config olcRootPW:: secret olcSyncUseSubentry: FALSE olcMultiProvider: TRUE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 94f2e3c6-7209-102f-9dc5-7b3f1ec29d0e creatorsName: cn=config createTimestamp: 20101022092205Z olcAccess: {0}to * by dn.base="cn=replicator,o=mobistar.be" read by anonymous read by * none olcSyncrepl: {0}rid=001 provider="ldap://prodcorpldapm1.host.priv.orange.be:389/ ldaps://prodcorpldapm1.host.priv.orange.be:636/" bindmethod=simple timeout=1 network-timeout=0 binddn="cn=replicator,o=mobistar.be" credentials="secret" keepalive=0:0:0 filter="(objectclass=*)" searchbase="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 +" olcSyncrepl: {1}rid=002 provider="ldap://prodcorpldapm2.host.priv.orange.be:389/ ldaps://prodcorpldapm2.host.priv.orange.be:636/" bindmethod=simple timeout=1 network-timeout=0 binddn="cn=replicator,o=mobistar.be" credentials="secret" keepalive=0:0:0 filter="(objectclass=*)" searchbase="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 +" olcSyncrepl: {2}rid=003 provider="ldap://prodcorpldapm3.host.priv.orange.be:389/ ldaps://prodcorpldapm3.host.priv.orange.be:636/" bindmethod=simple timeout=1 network-timeout=0 binddn="cn=replicator,o=mobistar.be" credentials="secret" keepalive=0:0:0 filter="(objectclass=*)" searchbase="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 +" olcSyncrepl: {3}rid=004 provider="ldap://prodcorpldapm4.host.priv.orange.be:389/ ldaps://prodcorpldapm4.host.priv.orange.be:636/" bindmethod=simple timeout=1 network-timeout=0 binddn="cn=replicator,o=mobistar.be" credentials="secret" keepalive=0:0:0 filter="(objectclass=*)" searchbase="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 +" olcAddContentAcl: FALSE olcLastMod: FALSE entryCSN: 20210921161430.588403Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20210921161430Z
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 dc3815c8 dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /usr/app/LDAP/prod-corp-M/etc/slapd.conf olcConfigDir: /usr/app/LDAP/prod-corp-M/etc/slapd.d olcAllows: bind_v2 olcArgsFile: /usr/app/LDAP/prod-corp-M/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 3600 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPasswordHash: {SHA} olcPidFile: /usr/app/LDAP/prod-corp-M/var/run/slapd.pid olcPluginLogFile: /usr/app/LDAP/prod-corp-M/var/log/plugin.log olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcServerID: 1 ldap://prodcorpldapm1.host.priv.orange.be:389/ olcServerID: 2 ldap://prodcorpldapm2.host.priv.orange.be:389/ olcServerID: 3 ldap://prodcorpldapm3.host.priv.orange.be:389/ olcServerID: 4 ldap://prodcorpldapm4.host.priv.orange.be:389/ olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /usr/app/LDAP/prod-corp-M/etc/ssl/certs/cacert.pem olcTLSCertificateFile: /usr/app/LDAP/prod-corp-M/etc/ssl/certs/servercert.pem olcTLSCertificateKeyFile: /usr/app/LDAP/prod-corp-M/etc/ssl/keys/serverkey.pem olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0 structuralObjectClass: olcGlobal entryUUID: 94e68270-7209-102f-9db4-7b3f1ec29d0e creatorsName: cn=config createTimestamp: 20101022092205Z olcConnMaxPending: 100 olcLogLevel: 16384 entryCSN: 20210921152518.879862Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20210921152518Z contextCSN: 20210720121843.555301Z#000000#000#000000 contextCSN: 20210921161242.889633Z#000000#001#000000 contextCSN: 20210921160000.938214Z#000000#002#000000 contextCSN: 20210921160015.487325Z#000000#003#000000 contextCSN: 20210921155930.648119Z#000000#004#000000
I tried a few as :
olcLogLevel from 256 to 16384 and vice-versa olcLastMod from TRUE to FALSE and vice-versa olcAddContentAd from TRUE to FALSE and vice-versa
Sometimes, when I did it on the first member it is replicated correctly but if I checked on the last member for which it was ok and decided to change it again, then it's not replicated back on the 3 others.
Before in my olcSyncrepl agreements I had URI with only "ldap://prodcorpldapm1.host.priv.orange.be:389/" and I read on internet that URI should be exactly as -h option of slapd start so I changed it as above but it didn't help. I had the same result in both cases.
Brgds & thx for help. Jean-Luc.
--On Thursday, September 23, 2021 2:48 PM +0000 bourguijl@gmail.com wrote:
Hello Quanah,
no problems ;-)
Here is my config :
Thanks. Your configuration appears to be missing the syncprov overlay being instantiated on the config database, which is required for multi-provider replication to function.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello Quanah,
Strange because I've this for DB config on all masters.
cd /usr/app/LDAP/prod-corp-M/etc/slapd.d/cn=config/olcDatabase={0}config>
cat olcOverlay={0}syncprov.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 687dd7e7 dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpSessionlog: 1000 structuralObjectClass: olcSyncProvConfig entryUUID: 94f332d6-7209-102f-9dc6-7b3f1ec29d0e creatorsName: cn=config createTimestamp: 20101022092205Z olcSpCheckpoint: 100 10 entryCSN: 20210923181717.601000Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20210923181717Z
Brgds, J-L.
--On Thursday, September 23, 2021 7:24 PM +0000 bourguijl@gmail.com wrote:
Hello Quanah,
Strange because I've this for DB config on all masters.
cd /usr/app/LDAP/prod-corp-M/etc/slapd.d/cn=config/olcDatabase={0}config>
cat olcOverlay={0}syncprov.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 687dd7e7 dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpSessionlog: 1000 structuralObjectClass: olcSyncProvConfig entryUUID: 94f332d6-7209-102f-9dc6-7b3f1ec29d0e creatorsName: cn=config createTimestamp: 20101022092205Z olcSpCheckpoint: 100 10 entryCSN: 20210923181717.601000Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20210923181717Z
No syncprov configuration was present in what you provided.
Reminder - I asked for the *full* configuration database (i.e., the output of slapcat -n 0 -l /tmp/config.ldif) with any passwords redacted. What you provided clearly fell fall short of that and is all I have to go off of.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Dears,
This thread is solved.
Issue was to use the olcRootDN in the olcSyncrepl lines but above all is to not adapt the olcLastMod parameter (as I did) to test replication modification between masters, it'll break the replication :-(
Thx to Quanah for his help and advice.
Brgds, J-L.
Dears,
Correction, you should read :
Issue was to NOT use the olcRootDN in the olcSyncrepl lines.
Brgds, J-L.
openldap-technical@openldap.org