[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problems reparenting entries
Deathly hush on this one. Am I doing something wrong, or is this just buggy
code that ought to be reported elsewhere. I'm currently shutting down the
master slapd, shutting down each of the slaves in turn and rsync'ing the
database across, which is not what you call seamless and unobtrusive ...
Should I just be deleting the old entry, and then creating the new ? I don't
like this very much, because it means there are times when the entry doesn't
exist (and therefore could get lost during an untimely bug / crash /
shutdown). Is modrdn just broken, or am I using it wrong ?
Any ideas ?
Rob
Rob McMahon writes:
> 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 sure people are doing this, can anyone hint what I'm doing wrong ?