Re: dynamic config replication

[Quanah Gibson-Mount]

--On Wednesday, March 07, 2018 11:46 AM -0800 Quanah Gibson-Mount 
 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 <>$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:

Re: dynamic config replication

[Quanah Gibson-Mount]

--On Tuesday, February 20, 2018 2:46 PM +0100 Gerard Ranke 
 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:

Re: dynamic config replication

[Gerard Ranke]

On 13-02-18 18:59, Dieter Klünter wrote:
> Am Fri, 9 Feb 2018 15:26:20 +0100
> schrieb Gerard Ranke :
> 
>> 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: 2
>> 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




signature.asc
Description: OpenPGP digital signature

Re: dynamic config replication

[Dieter Klünter]

Am Fri, 9 Feb 2018 15:26:20 +0100
schrieb Gerard Ranke :

> 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: 2
> 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

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

dynamic config replication

[Gerard Ranke]

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: 2
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: xx
olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple
binddn="cn=config,cn=slave" credentials=""
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