Quoting Richard Megginson <rmeggins@xxxxxxxxxx>:
Kevin M. Myer wrote:
Quoting David Boreham <david_list@xxxxxxxxxxx>:
Try looking in the access and error logs on the replica server (the
server that is receiving this update).
That should tell us which operation is failing. Exactly what is
going on I'm not sure, I've not seen a
problem like this before. Perhaps someone else on the list has.
Here's the action its trying to perform:
[16/Dec/2005:09:06:16 -0500] conn=900959 op=3 EXT
oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start
Session"
[16/Dec/2005:09:06:16 -0500] conn=900959 op=3 RESULT err=0 tag=120
nentries=0 etime=0
[16/Dec/2005:09:06:16 -0500] conn=900959 op=4 DEL
dn="uid=<username>,ou=people,dc=base"
[16/Dec/2005:09:06:16 -0500] conn=900959 op=4 RESULT err=1 tag=107
nentries=0 etime=0 csn=43a2c9d8000000010000
[16/Dec/2005:09:06:18 -0500] conn=900959 op=5 EXT
oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session"
The replication to the slave (garnet) did occur properly for the
account that was being deleted.
Is this the access log from one of the masters?
Yes, its from the master that the changes were sent to.
Its also not inhibiting other changes from occuring in the the same
replication session. I just made a minor modification to my account
and it replicated while the deletion of the account giving errors
failed. I restarted the server that was receiving the changes, and
now the deletion operation that was failing isn't occuring at all :/
So I guess I'll just manually delete the account, since the one
master seems to be convinced that the change went through.
So after the restart, everything is ok?
Unfortunately, no. What has stopped is the attempt to do the
replication from the master where the initial change was committed.
Further, if I try to manually delete the entry from the master the
changes were to be replicated to, I get the same operation error.
[17/Dec/2005:14:07:41 -0500] conn=471 fd=210 slot=210 connection from
XX.XX.XX.XX to XX.XX.XX.XX
[17/Dec/2005:14:07:41 -0500] conn=471 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[17/Dec/2005:14:07:41 -0500] conn=471 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[17/Dec/2005:14:07:41 -0500] conn=471 op=1 DEL
dn="uid=<username>,ou=People,dc=base"
[17/Dec/2005:14:07:41 -0500] conn=471 op=1 RESULT err=1 tag=107
nentries=0 etime=0 csn=43a461fe000000650000
[17/Dec/2005:14:07:41 -0500] conn=471 op=2 UNBIND
[17/Dec/2005:14:07:41 -0500] conn=471 op=2 fd=210 closed - U1
Now to the best of my knowledge, this server has not gone down
uncleanly, and its only this one entry that is causing problems. So
ideas on what to try next, or how I might fix it?
Kevin
--
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13 http://www.iu13.org
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
