Hello list,
Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach relevant parts of the configuration at the end of this message. ) Following the scripts from test059, I configured the producer to serve up a cn=config backend for the consumers. This seems to work nicely at first: When you start a consumer from a minimal config, it loads the producers schemafiles and the cn=config, and replication of the main database is fine. Also, when fi. changing the loglevel on the producers cn=config,cn=slave, the consumers pick up this change in their cn=config. However, when I modify an olcAccess line on the producers cn=config,cn=slave database, I get these errors on the consumer:
slapd[26324]: syncrepl_message_to_entry: rid=002 DN: olcDatabase={1}mdb,cn=config,cn=slave, UUID: 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry: rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 be_search (0) slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config slapd[26324]: null_callback : error code 0x43 slapd[26324]: syncrepl_entry: rid=002 be_modify olcDatabase={1}mdb,cn=config (67) slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67) slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
From the error code ox43, it seems that the replication is somehow
trying to change the rdn, olcDatabase{1}mdb, on the consumer, which makes no sense to me.
From the producer, cn=config,cn=slave:
( This is identical to the consumer's cn=config )
dn: cn=config,cn=slave objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: slaveconfig cn: config olcArgsFile: /var/run/slapd/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d/ olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogFile: none olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: 20000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/ssl/certs olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 2
I'll leave the rest PM, except for:
dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config olcRootDN: cn=root,cn=config olcRootPW: xxxxxxxxxxxxxx olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple binddn="cn=config,cn=slave" credentials="xxxx" tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key" tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none searchbase="cn=config,cn=slave" schemachecking=off type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config" olcSyncUseSubentry: FALSE
This is identical to the consumers olcDatabase={0}config,cn=config entry.
Hopefully somebody can point me in the right direction! Many thanks in advance,
gerard
Am Fri, 9 Feb 2018 15:26:20 +0100 schrieb Gerard Ranke gerard.ranke@hku.nl:
Hello list,
Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach relevant parts of the configuration at the end of this message. ) Following the scripts from test059, I configured the producer to serve up a cn=config backend for the consumers. This seems to work nicely at first: When you start a consumer from a minimal config, it loads the producers schemafiles and the cn=config, and replication of the main database is fine. Also, when fi. changing the loglevel on the producers cn=config,cn=slave, the consumers pick up this change in their cn=config. However, when I modify an olcAccess line on the producers cn=config,cn=slave database, I get these errors on the consumer:
slapd[26324]: syncrepl_message_to_entry: rid=002 DN: olcDatabase={1}mdb,cn=config,cn=slave, UUID:
^^^^^^^^^^^^^^^^^^^^^^^^^
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry: rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 be_search (0) slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
slapd[26324]: null_callback : error code 0x43 slapd[26324]: syncrepl_entry: rid=002 be_modify olcDatabase={1}mdb,cn=config (67)
^^^^^^^^^^^^^^^^
slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67) slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
From the error code ox43, it seems that the replication is somehow trying to change the rdn, olcDatabase{1}mdb, on the consumer, which makes no sense to me.
From the producer, cn=config,cn=slave: ( This is identical to the consumer's cn=config )
dn: cn=config,cn=slave objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: slaveconfig cn: config olcArgsFile: /var/run/slapd/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d/ olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogFile: none olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: 20000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/ssl/certs olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 2
I'll leave the rest PM, except for:
dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config
^^^^^^^^^^^^^^^^^^^^^^^ [...]
Hopefully somebody can point me in the right direction! Many thanks in advance,
check your configuration, distinguished names differ.
-Dieter
On 13-02-18 18:59, Dieter Klünter wrote:
Am Fri, 9 Feb 2018 15:26:20 +0100 schrieb Gerard Ranke gerard.ranke@hku.nl:
Hello list,
Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach relevant parts of the configuration at the end of this message. ) Following the scripts from test059, I configured the producer to serve up a cn=config backend for the consumers. This seems to work nicely at first: When you start a consumer from a minimal config, it loads the producers schemafiles and the cn=config, and replication of the main database is fine. Also, when fi. changing the loglevel on the producers cn=config,cn=slave, the consumers pick up this change in their cn=config. However, when I modify an olcAccess line on the producers cn=config,cn=slave database, I get these errors on the consumer:
slapd[26324]: syncrepl_message_to_entry: rid=002 DN: olcDatabase={1}mdb,cn=config,cn=slave, UUID:
^^^^^^^^^^^^^^^^^^^^^^^^^7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry: rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 be_search (0) slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
^^^^^^^^^^^^^^^^^^^^^^^^^^^^slapd[26324]: null_callback : error code 0x43 slapd[26324]: syncrepl_entry: rid=002 be_modify olcDatabase={1}mdb,cn=config (67)
^^^^^^^^^^^^^^^^
I believe this is correct: The consumers have a different configuration than the producer, so it's set up as cn=config,cn=slave on the producer. The consumers have a suffixmassage option in their olcSyncrepl line that changes the suffix to cn=config, so the {1}mdb section should land in the right place.
slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67) slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
From the error code ox43, it seems that the replication is somehow trying to change the rdn, olcDatabase{1}mdb, on the consumer, which makes no sense to me.
From the producer, cn=config,cn=slave: ( This is identical to the consumer's cn=config )
dn: cn=config,cn=slave objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: slaveconfig cn: config olcArgsFile: /var/run/slapd/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d/ olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogFile: none olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: 20000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/ssl/certs olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 2
I'll leave the rest PM, except for:
dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config
^^^^^^^^^^^^^^^^^^^^^^^ [...]
It's the same here, the producers cn=config,cn=slave is changed in replication to become just cn=config on the consumer. This actually works: I can change fi olcLogLevel or schemas on cn=config,cn=slave on the producer, and they get replicated to the consumers. Just when I try to change things on the {1}mdb section, like an olcAccess line, I get the 0x43 errors... Thanks a lot for answering! Best,
gerard
--On Tuesday, February 20, 2018 2:46 PM +0100 Gerard Ranke gerard.ranke@hku.nl wrote:
It's the same here, the producers cn=config,cn=slave is changed in replication to become just cn=config on the consumer. This actually works: I can change fi olcLogLevel or schemas on cn=config,cn=slave on the producer, and they get replicated to the consumers. Just when I try to change things on the {1}mdb section, like an olcAccess line, I get the 0x43 errors... Thanks a lot for answering! Best,
Hm, error code 67 is:
67: Not Allowed on RDN
This indicates that the requested operation is not allowed because it would have altered the entry to remove an attribute value used in the entry's RDN.
Which seems an odd error to get for an ACL change.
I'll see if I can reproduce via tweaking test059.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, March 07, 2018 11:46 AM -0800 Quanah Gibson-Mount quanah@symas.com wrote:
Hi Gerard,
I'll see if I can reproduce via tweaking test059.
I changed test059 to modify an ACL in the cn=config,cn=slave DB, and it works (replicates to the slave) without issue.
Diff is:
diff --git a/tests/scripts/test059-slave-config b/tests/scripts/test059-slave-config index ece5738..a349670 100755 --- a/tests/scripts/test059-slave-config +++ b/tests/scripts/test059-slave-config @@ -319,6 +319,8 @@ olcSuffix: $BASEDN ${nullExclude}olcDbDirectory: $DBDIR1B olcRootDN: $MANAGERDN olcRootPW: $PASSWD +olcAccess: {0}to attrs=userPassword by * manage +olcAccess: {1}to * by * manage olcSyncRepl: rid=002 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" $SYNCTYPE retry="3 5 300 5" timeout=3 @@ -338,7 +340,9 @@ olcSuffix: $BASEDN ${nullExclude}olcDbDirectory: $DBDIR2A olcRootDN: $MANAGERDN olcRootPW: $PASSWD -olcSyncRepl: rid=002 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple +olcAccess: {0}to attrs=userPassword by * manage +olcAccess: {1}to * by * manage +olcSyncRepl: {0}rid=002 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" $SYNCTYPE retry="3 5 300 5" timeout=3 olcUpdateRef: $URI1 @@ -367,6 +371,22 @@ EOF fi fi
+$LDAPMODIFY -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >>$TESTOUT 2>&1 +dn: olcDatabase={1}$BACKEND,cn=config,cn=slave +changetype: modify +delete: olcAccess +olcAccess: {0} +- +add: olcAccess +olcAccess: {0}to attrs=userPassword by * write +EOF +RC=$? +if test $RC != 0 ; then + echo "ldapadd modify for database config ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit $RC +fi + echo "Using ldapadd to populate provider..." $LDAPADD -D "$MANAGERDN" -H $URI1 -w $PASSWD -f $LDIFORDERED \ >> $TESTOUT 2>&1
You would need to provide significantly more detailed information on the state of your database (i.e., what the ACL was you were changing and how you were attempting to change it, etc) to really pursue this further. All I can say at the moment is "works for me".
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Dieter Klünter -
Gerard Ranke -
Quanah Gibson-Mount