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