Whoop! I ran that search in a hurry yesterday just to have something to paste
into the email. I had run my search and the one you suggested earlier
(correctly) but couldnt see the entry.
I did, however, manage to delete the entry which I could not see. The trick
was, I had to shut down both masters, then start only the master that had
been printing out the errors. At this point, the error-printing master was
not printing the error (no replication from the other server pushing this
change across). Then, I was able to do an ldapmodify and delete the
invisible glue entry. I then started up the other master, and replication
resumed as normal, without any error messages.
That seemed to work for me. Thanks for all of your help.
~James
[soleo@mstrldap01 ~]$ ldapsearch -MMxw xxxx -D "cn=Directory
Manager" -b "ou=people,dc=soleocommunications,dc=com" -s one -h
10.1.5.211 '(uid=soleotester)'
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=soleocommunications,dc=com> with scope one
# filter: (uid=soleotester)
# requesting: ALL
# with manageDSAit critical control
#
# search result
search: 2
result: 0 Success
# numResponses: 1
On Tuesday 25 March 2008 18:26:26 Nathan Kinder wrote:
James wrote:
> Thanks for the suggestion. I have tried searching for the glue entry in
> the database, and I cant find it:
>
> [soleo@mstrldap01 ~]$ ldapsearch -MMxw xxxxx -D "cn=Directory
> Manager" -b "ou=soleotester,ou=people,dc=soleocommunications,dc=com"
-s
> one -h 10.1.5.211
> # extended LDIF
> #
> # LDAPv3
> # base <ou=soleotester,ou=people,dc=soleocommunications,dc=com> with
> scope one # filter: (objectclass=*)
> # requesting: ALL
> # with manageDSAit critical control
> #
>
> # search result
> search: 2
> result: 32 No such object
> matchedDN: ou=people,dc=soleocommunications,dc=com
>
> # numResponses: 1
>
> When I first noticed these logs, I did find the original entry present on
> this server (and on the other master) so I deleted this entry from both
> servers (and restarted ns-slapd), but that didnt get rid of the log.
>
> Also, Ive noticed that after a while of having this error printed out,
> the server stops allowing me to bind in.
>
> Am I doing something wrong in my search? Or, is there something else I
> can try?
Your search is searching for
"ou=soleotester,ou=people,dc=soleocommunications,dc=com", but the glue
entry the server is trying to create is
"uid=soleotester,ou=people,dc=soleocommunications,dc=com". Try doing
this search instead:
ldapsearch -b "ou=people,dc=soleocommunications,dc=com" -s one
"uid=soleotester"
-NGK
> Thanks
>
> ~James
>
> On Tuesday 25 March 2008 14:46:56 Nathan Kinder wrote:
>> James wrote:
>>> Hi All,
>>>
>>> I have a set of directory servers with multi-master replicaiton. On
>>> one of the two master servers, I see this log:
>>>
>>> [25/Mar/2008:14:26:42 -0400] NSMMReplicationPlugin - conn=5 op=6
>>> csn=47cec1700000000c0000:
>>> Can't created glue entry
>>> uid=soleotester,ou=people,dc=soleocommunications,dc=com uniqueid
>>> =96a7eb81-1dd111b2-8016d669-d3980000, error 68
>>> [25/Mar/2008:14:26:42 -0400] NSMMReplicationPlugin - conn=5 op=6
>>> csn=47cec1700000000c0000:
>>> Can't created glue entry
>>> uid=soleotester,ou=people,dc=soleocommunications,dc=com uniqueid
>>> =96a7eb81-1dd111b2-8016d669-d3980000, error 68
>>>
>>> The logs is repeated once per second (there are two in this
>>> copy/paste). I have a high-level understanding of what a glue entry is,
>>> and why one would be created, but why can't this server create one in
>>> this instance? And, is there anything I can do to fix this repeated
>>> log?
>>
>> It can't create it because it already exists (error 68). Please file a
>> bug on this issue (
https://bugzilla.redhat.com/enter_bug.cgi).
>>
>> You can try to delete the existing glue entry to allow the replication
>> plug-in to re-create it and proceed.
>>
>> -NGK
>>
>>> Thanks,
>>> ~James
--
James Bushey
Software Engineer
Soleo Communications
(585) 641-4300 x0050