Re: memberOf-overlay and custom schema (slapd.logs attched)

[Marc Patermann <hans.moser@ofd-z.niedersachsen.de>]

Dora,

Am 01.12.2015 um 20:37 Uhr schrieb Dora Paula:
> #This modify operation seems to be ignored by memberOf-overlay:
> #
> cat << EOF | ldapmodify -x -H "ldap://localhost:2389/"; -D
> "cn=admin,dc=example,dc=com" -w admin
> dn: cn=device,dc=example,dc=com
> changetype: modify
> add: objectClass
> objectClass: association
> -
> add: associate
> associate: uid=myAccount,dc=example,dc=com
> -
>
> EOF

> The second approach (resetting the device and myAccount entry and split
> the above modify operation into two operations works fine. Details see
> here:
>
> #Splitting the previous modify operation into two works fine:
> #
> cat << EOF | ldapmodify -x -H "ldap://localhost:2389/"; -D
> "cn=admin,dc=example,dc=com" -w admin
> dn: cn=device,dc=example,dc=com
> changetype: modify
> add: objectClass
> objectClass: association
>
> EOF
>
> cat << EOF | ldapmodify -x -H "ldap://localhost:2389/"; -D
> "cn=admin,dc=example,dc=com" -w admin
> dn: cn=device,dc=example,dc=com
> changetype: modify
> add: associate
> associate: uid=myAccount,dc=example,dc=com
>
> EOF
>
>
> #slapd-log (loglevel -1), see attached split-modify.log
>
>
> #Checking the results:
> #
> ldapsearch -x -H "ldap://localhost:2389/"; -D
> "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one
> '(objectClass=*)'
>
> # extended LDIF
> #
> # LDAPv3
> # base <dc=example,dc=com> with scope oneLevel
> # filter: (objectClass=*)
> # requesting: ALL
> #
>
> # device, example.com
> dn: cn=device,dc=example,dc=com
> objectClass: top
> objectClass: device
> objectClass: association
> cn: device
> associate: uid=myAccount,dc=example,dc=com
>
> # myAccount, example.com
> dn: uid=myAccount,dc=example,dc=com
> objectClass: top
> objectClass: myAccount
> uid: myAccount
> associateOf: cn=device,dc=example,dc=com
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 3
> # numEntries: 2
>
> Long story, short question:
> Is this the intended behaviour? If not is it caused by a
> misconfiguration or a bug?
this is only a guess, maybe someone as a better understanding of the 
underlayings:

In your one shot operation the object is not analyzed by the overlay, 
because it is just in the process of being an object with the observed 
objectclass: memberof-group-oc association

This would explain, why your two shot approach is working as expected. 
And since it does, I don't think you made an error.


Marc