--On Friday, April 12, 2013 5:48 PM +0000 [email protected] wrote: > --On Friday, April 12, 2013 5:43 PM +0000 [email protected] wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 4/12/2013 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.39.181) > > Also the following modify succeeds when it should fail: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=test zimbraID > dn: dc=test,dc=com > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=example zimbraId > dn: dc=example,dc=com > zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 > > zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra > dn: dc=example,dc=com > changetype: modify > replace: zimbraId > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > modifying entry "dc=example,dc=com"
I found it has entirely to do with brand new entries since slapd was last started. unique simply won't enforce on any data added after slapd was started. Restarting slapd results in the correct behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
