I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
On 08/31/2011 01:05 PM, David Hoskinson wrote:
I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: DIGEST-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110831163410
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
David Hoskinson | *DATATRAK*International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.net mailto:david.hoskinson@datatrak.net | www.datatrak.net http://www.datatrak.net/
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Not sure if there is a better way but will run through it...
Agreement name Name: xxx Description: xxx.stag.cle.us
Next
Supplier = server A:389 Consumer = server B:636
Use TLS/SSL (TLS?SSL encryption with LDAPS Simple Bind as cn=Replication Manager,cn=config Password: replication password
Next Select replication criteria.... Attributes unchecked
Next
Provide schedule Information Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:21 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote: I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
On 08/31/2011 01:30 PM, David Hoskinson wrote:
Not sure if there is a better way but will run through it...
Agreement name
Name: xxx
Description: xxx.stag.cle.us
Next
Supplier = server A:389
Consumer = server B:636
Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS
Simple
Bind as cn=Replication Manager,cn=config
Password: replication password
Next
Select replication criteria.... Attributes unchecked
Next
Provide schedule Information
Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:21 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote:
I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: DIGEST-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110831163410
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
David Hoskinson | *DATATRAK*International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.net mailto:david.hoskinson@datatrak.net | www.datatrak.net http://www.datatrak.net/
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:32 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote: Not sure if there is a better way but will run through it...
Agreement name Name: xxx Description: xxx.stag.cle.us
Next
Supplier = server A:389 Consumer = server B:636 Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS Simple Bind as cn=Replication Manager,cn=config Password: replication password
Next Select replication criteria.... Attributes unchecked
Next
Provide schedule Information Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:21 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote: I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
On 08/31/2011 01:34 PM, David Hoskinson wrote:
Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
ok, try this: /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
Could it be firewall related? You have to allow port 636 to use LDAPS (TLS/SSL encryption with LDAPS)
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:32 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote:
Not sure if there is a better way but will run through it...
Agreement name
Name: xxx
Description: xxx.stag.cle.us
Next
Supplier = server A:389
Consumer = server B:636
Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS
Simple
Bind as cn=Replication Manager,cn=config
Password: replication password
Next
Select replication criteria.... Attributes unchecked
Next
Provide schedule Information
Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:21 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote:
I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: DIGEST-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110831163410
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
David Hoskinson | *DATATRAK*International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.net mailto:david.hoskinson@datatrak.net | www.datatrak.net http://www.datatrak.net/
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[root@xxx slapd-adm302]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110830132535020110830132535 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
I see what you are trying here, but still seems to be passing
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:42 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:34 PM, David Hoskinson wrote: Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
ok, try this: /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
Could it be firewall related? You have to allow port 636 to use LDAPS (TLS/SSL encryption with LDAPS)
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:32 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote: Not sure if there is a better way but will run through it...
Agreement name Name: xxx Description: xxx.stag.cle.us
Next
Supplier = server A:389 Consumer = server B:636 Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS Simple Bind as cn=Replication Manager,cn=config Password: replication password
Next Select replication criteria.... Attributes unchecked
Next
Provide schedule Information Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:21 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote: I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
I just found this in /var/log/dirsrv/slapd-xxx/error
Is it actually binding but password is invalid on one machine or the other? I thought I created the replication manager with no password expiration but I am not totally sure how to check and if so how to change to never expire.
Just an observation, may not mean anything
[31/Aug/2011:19:54:34 +0000] NSMMReplicationPlugin - agmt="cn=adm302" (adm302:636): Successfully bound cn=Replication Manager,cn=config to consumer, but password has expired on consumer.
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of David Hoskinson Sent: Wednesday, August 31, 2011 3:49 PM To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] Setting up multi master replication error 81
[root@xxx slapd-adm302]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110830132535020110830132535 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
I see what you are trying here, but still seems to be passing
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:42 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:34 PM, David Hoskinson wrote: Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
ok, try this: /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
Could it be firewall related? You have to allow port 636 to use LDAPS (TLS/SSL encryption with LDAPS)
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:32 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote: Not sure if there is a better way but will run through it...
Agreement name Name: xxx Description: xxx.stag.cle.us
Next
Supplier = server A:389 Consumer = server B:636 Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS Simple Bind as cn=Replication Manager,cn=config Password: replication password
Next Select replication criteria.... Attributes unchecked
Next
Provide schedule Information Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:21 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote: I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
On 08/31/2011 01:59 PM, David Hoskinson wrote:
I just found this in /var/log/dirsrv/slapd-xxx/error
Is it actually binding but password is invalid on one machine or the other? I thought I created the replication manager with no password expiration but I am not totally sure how to check and if so how to change to never expire.
Just an observation, may not mean anything
[31/Aug/2011:19:54:34 +0000] NSMMReplicationPlugin - agmt="cn=adm302" (adm302:636): Successfully bound cn=Replication Manager,cn=config to consumer, but password has expired on consumer.
See http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...
*From:*389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] *On Behalf Of *David Hoskinson *Sent:* Wednesday, August 31, 2011 3:49 PM *To:* 389-users@lists.fedoraproject.org *Subject:* Re: [389-users] Setting up multi master replication error 81
[root@xxx slapd-adm302]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
namingContexts: o=netscaperoot
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110830132535020110830132535
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
I see what you are trying here, but still seems to be passing
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:42 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:34 PM, David Hoskinson wrote:
Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
ok, try this: /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
Could it be firewall related? You have to allow port 636 to use LDAPS (TLS/SSL encryption with LDAPS)
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:32 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote:
Not sure if there is a better way but will run through it...
Agreement name
Name: xxx
Description: xxx.stag.cle.us
Next
Supplier = server A:389
Consumer = server B:636
Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS
Simple
Bind as cn=Replication Manager,cn=config
Password: replication password
Next
Select replication criteria.... Attributes unchecked
Next
Provide schedule Information
Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
*From:*Rich Megginson [mailto:rmeggins@redhat.com] *Sent:* Wednesday, August 31, 2011 3:21 PM *To:* General discussion list for the 389 Directory server project. *Cc:* David Hoskinson *Subject:* Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote:
I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: DIGEST-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110831163410
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
David Hoskinson | *DATATRAK*International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.net mailto:david.hoskinson@datatrak.net | www.datatrak.net http://www.datatrak.net/
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Thanks Rich, I had already found that and set password to never expire and it at least initialize. I will do more testing today and verify it is replicating.
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 4:13 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:59 PM, David Hoskinson wrote: I just found this in /var/log/dirsrv/slapd-xxx/error
Is it actually binding but password is invalid on one machine or the other? I thought I created the replication manager with no password expiration but I am not totally sure how to check and if so how to change to never expire.
Just an observation, may not mean anything
[31/Aug/2011:19:54:34 +0000] NSMMReplicationPlugin - agmt="cn=adm302" (adm302:636): Successfully bound cn=Replication Manager,cn=config to consumer, but password has expired on consumer. See http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...
From: 389-users-bounces@lists.fedoraproject.orgmailto:389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of David Hoskinson Sent: Wednesday, August 31, 2011 3:49 PM To: 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: Re: [389-users] Setting up multi master replication error 81
[root@xxx slapd-adm302]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110830132535020110830132535 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
I see what you are trying here, but still seems to be passing
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:42 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:34 PM, David Hoskinson wrote: Yes.... Sorry should have been xxx2.stag.cle.usRe: [389-users] Setting up multi master replication error 81
ok, try this: /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -p 636 -Z -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
Could it be firewall related? You have to allow port 636 to use LDAPS (TLS/SSL encryption with LDAPS)
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:32 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:30 PM, David Hoskinson wrote: Not sure if there is a better way but will run through it...
Agreement name Name: xxx Description: xxx.stag.cle.us
Next
Supplier = server A:389 Consumer = server B:636 Are you using the FQDN for server B?
Use TLS/SSL (TLS?SSL encryption with LDAPS Simple Bind as cn=Replication Manager,cn=config Password: replication password
Next Select replication criteria.... Attributes unchecked
Next
Provide schedule Information Always keep directories in sync
Next
Select one of the following
Initialize consume now
Done
Fails with unable to contact ldap
From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 3:21 PM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81
On 08/31/2011 01:05 PM, David Hoskinson wrote: I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? Can you post your replication agreement entries?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson@datatrak.netmailto:david.hoskinson@datatrak.net | www.datatrak.nethttp://www.datatrak.net/
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
389-users@lists.fedoraproject.org