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@xxxxxxxxxx> 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.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaTransportInfo) > > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
