[389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Dustin Rice]

My guess would be it's failing to validate the SSL certificate. Are you
using a self-signed cert? If so, you'll need to import that CA cert across
all of your servers.

You also could check serverc's error log when you start the server to see
if it says that the server started up on 636 successfully.

You could try to switch it to not use SSL temporarily just to see if it
works.


On Sun, May 4, 2014 at 9:59 AM, Graham Leggett <minfrin at sharp.fm> wrote:

> Hi all,
>
> Some more digging reveals that when an attempt is made for serverb to try
> and commence replication with serverc, I get the following in the error log:
>
> [04/May/2014:17:46:55 +0100] NSMMReplicationPlugin - Beginning total
> update of replica "agmt="cn=Agreement serverc.example.com" (serverc:636)".
> [04/May/2014:17:47:02 +0100] NSMMReplicationPlugin - agmt="cn=Agreement
> serverc.example.com" (serverc:636): Failed to send extended operation:
> LDAP error -1 (Can't contact LDAP server)
> [04/May/2014:17:47:02 +0100] NSMMReplicationPlugin - agmt="cn=Agreement
> serverc.example.com" (serverc:636): Received error -1 (Can't contact LDAP
> server):  for total update operation
> [04/May/2014:17:47:03 +0100] NSMMReplicationPlugin - agmt="cn=Agreement
> serverc.example.com" (serverc:636): Warning: unable to send
> endReplication extended operation (Can't contact LDAP server)
> [04/May/2014:17:47:04 +0100] NSMMReplicationPlugin - agmt="cn=Agreement
> serverc.example.com" (serverc:636): Replication bind with SIMPLE auth
> resumed
>
> Unfortunately the error message "Failed to send extended operation: LDAP
> error -1 (Can't contact LDAP server)" is too vague to be useful because
> there is no clear and unambiguous indication of *which* server it is unable
> to connect to and on what port. The "(serverc:636)" would imply that it is
> trying to connect to "serverc", but "serverc" is the name of the instance,
> it is not the name of the server, so any attempt to connect to this will
> fail. The server is called serverc.example.com, and this name appears
> exclusively in the replication agreement:
>
> dn: cn=Agreement serverc.example.com,cn=replica,cn=o\3DFoo\,c\3Dza,cn=mapping
> tr
>  ee,cn=config
> objectClass: nsDS5ReplicationAgreement
> objectClass: top
> cn: Agreement serverc.example.com
> description: Replication agreement between serverb.example.com and
> serverc.example.com
> nsds5BeginReplicaRefresh: start
> nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
> nsDS5ReplicaBindMethod: SIMPLE
> nsds5replicaChangesSentSinceStartup:
> nsDS5ReplicaCredentials:: xxx
> nsDS5ReplicaHost: serverc.example.com
> nsds5replicaLastInitEnd: 0
> nsds5replicaLastInitStart: 20140504164654Z
> nsds5replicaLastInitStatus: 0
> nsds5replicaLastUpdateEnd: 20140504164652Z
> nsds5replicaLastUpdateStart: 20140504164652Z
> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
> u
>  pdate started
> nsDS5ReplicaPort: 636
> nsDS5ReplicaRoot: o=Foo,c=ZA
> nsDS5ReplicaTransportInfo: SSL
> nsds5replicaUpdateInProgress: FALSE
>
> At the same time, ssldump reveals that serverb.example.com and
> serverc.example.com are successfully speaking to one another, and have a
> lot to say - data seems to be constantly flowing between them, but not to
> any successful end.
>
> Does any of this behaviour look familiar to anybody?
>
> Regards,
> Graham
> --
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20140504/d9759eaf/attachment.html>