[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problems with modrdn (ITS#1379)



A fix has been applied to HEAD and OPENLDAP_REL_ENG_2 which
should resolve this problem.  Please test.


At 07:16 AM 2001-10-08, Rob.McMahon@warwick.ac.uk wrote:
>Full_Name: Rob McMahon
>Version: 2.0.14
>OS: Solaris 7
>URL: 
>Submission from: (NULL) (194.82.103.45)
>
>
>
>I've got a database of University members in an OpenLDAP 2.0.14 installation.
>The DNs are of the form
>        employeenumber=42,ou=People,o=University of Warwick,c=GB
>When people leave, rather than deleting the entries I'd like to move them to
>another container, say
>        employeenumber=42,ou=exPeople,o=University of Warwick,c=GB
>So I'm doing (perl-speak, sorry, but it should be clear).
>        $bind->moddn($direntry, newrdn => "employeeNumber=42",
>                                deleteoldrdn => 0,
>                                newsuperior => "ou=exPeople,o=University of Warwick,c=GB");
>So far so good.  This works fine on the master.
>
>Slurping it across to the slaves is not so good, though.  Every change is
>rejected with
>
>ERROR: Already exists
>replica: slave:0
>time: 1001408395.0
>dn: employeeNumber=42, ou=People, o=University of Warwick, c=GB
>changetype: modrdn
>newrdn: employeeNumber=42
>deleteoldrdn: 0
>newsuperior: ou=exPeople,o=University of Warwick,c=GB
>
>Out of interest, I tried changing deleteoldrdn to 1 in the reject file and
>re-submitting it (thinking well, yes, employeeNumber=42 does exist if it tried
>that bit of the rename first).  The slave slapd got stuck in a tight loop, and
>had to be killed unpleasantly (i.e. a simple `kill' didn't work).
>
>I'm not entirely convinced I'm not just doing something wrong, but I've had zero
>responses from the software list.