On Mon, Aug 18, 2014 at 6:14 PM, Justin Edmands <shockwavecs(a)gmail.com> wrote:
Forgive me if you have this already configured...In my setup the
supplier has to sending on 389 and consumer has to be receiving on
636. It's somewhere in the docs I believe.
On Mon, Aug 18, 2014 at 6:03 PM, Noriko Hosoi <nhosoi(a)redhat.com> wrote:
> You mentioned hosts test-ds1 and test-ds2. What is test-ds3? Is it another
> consumer?
>
> Does this command line work on the host test-ds1?
>
> ldapsearch -LLL -x -H ldaps://test-ds3 -s sub -b
> dc=infinityhealthcare,dc=com uid=jdetert
>
> If yes, what happens if you add this to your agreement?
>
> nsDS5ReplicaTransportInfo: SSL
>
>
(
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9....)
>
> If it still does not work, could you try replacing the replica host like
> this?
>
> nsDS5ReplicaHost: test-ds3
>
>
> Jon Detert wrote:
>
> Hello,
>
> I'm failing to make replication work over SSL. Hoping one of you can see
> what I'm missing:
>
> My test involves one supplier (named test-ds1) and one consumer (named
> test-ds2), both running version 1.3.2.16.
>
> Both supplier and consumer are listening to tcp 389 and 636. I can query
> each over ldaps (e.g. like this:
> ldapsearch -LLL -x -H ldaps://test-ds2 -s sub -b
> dc=infinityhealthcare,dc=com uid=jdetert)
>
> Replication works fine when I don't try to use ssl: a change on test-ds1 is
> automatically made on test-ds2 as well.
>
> To try to use ssl, I delete the replication agreement and then recreate it,
> but specify nsDS5ReplicaPort as 636 instead of 389. Here's how the
> agreement looks when I've tried to use ssl:
>
> dn:
> cn=dc-ihc-dc-com-to-ds3,cn=replica,cn=dc\3Dinfinityhealthcare\2Cdc\3Dcom,c
> n=mapping tree,cn=config
> objectClass: top
> objectClass: nsDS5ReplicationAgreement
> description: agreement to replicate dc=ihc,dc=com tree from ds1 to ds3
> cn: dc-ihc-dc-com-to-ds3
> nsDS5ReplicaRoot: dc=infinityhealthcare,dc=com
> nsDS5ReplicaHost:
test-ds3.infinityhealthcare.com
> nsDS5ReplicaPort: 636
> nsDS5ReplicaBindDN: uid=replica-manager,cn=config
> nsDS5ReplicaBindMethod: SIMPLE
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
> authorityRevocationLis
> t memberof
> nsDS5ReplicaCredentials: {DES}Nz0qsqM5nShesnQPldsB7vYKQXOj2azjan8bTsUWxNM=
> nsds5replicareapactive: 0
> nsds5replicaLastUpdateStart: 0
> nsds5replicaLastUpdateEnd: 0
> nsds5replicaChangesSentSinceStartup:
> nsds5replicaLastUpdateStatus: 0 No replication sessions started since server
> s
> tartup
> nsds5replicaUpdateInProgress: FALSE
> nsds5replicaLastInitStart: 20140818205749Z
> nsds5replicaLastInitEnd: 0
> nsds5replicaLastInitStatus: -5 - LDAP error: Timed out
>
> The supplier's error log says this:
>
> [18/Aug/2014:15:57:49 -0500] NSMMReplicationPlugin -
> agmt="cn=dc-ihc-dc-com-to-ds3" (test-ds3:636): Replication bind with
SIMPLE
> auth failed: LDAP error -5 (Timed out) ()
> [18/Aug/2014:16:07:49 -0500] slapi_ldap_bind - Error: timeout after [600.0]
> seconds reading bind response for [uid=replica-manager,cn=config]
> authentication mechanism [SIMPLE]
>
> The consumer's error log says nothing about the replication attempt.
> However, I know the supplier has spoken to the consumer over ssl, because:
>
> a) the consumer's access log shows that the supplier connected over SSL:
> [18/Aug/2014:16:07:50 -0500] conn=11 fd=64 slot=64 SSL connection from
> 192.168.190.9 to 192.168.190.13
>
> and
>
> b) packet sniffing on the supplier shows the same.
>
> aTdHvAaNnKcSe for any help you lend,
>
> Jon Detert
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users